Thu, 17 Feb 2005
And hot on it's heels, zsync 0.2.3
A trivial bug in zsyncmake that crept in with the changes for 0.2.x was reported, and this version fixes it. It will not segfault on files smaller than one block anymore (not that there's much use in partial file transfer if your file is only 1 block!).
This version also includes a new optimisation for locating matching blocks. A "negative" hash table is now used to speed up processing of non-matching sections in files. This puts zsync in the lead over rsync (which, it seems, does not have an equivalent optimisation) in speed in my test setup. It also makes smaller block sizes for ISO files practical.
[20:31] | [/computers/zsync] | #
Sat, 12 Feb 2005
zsync-0.2.2 released
A third release within 7 days. There is very little changed in this release, but since it completes the work started in 0.2.1 to make gzip support work properly (which turned out to be easier than I expected), I thought it worth putting out immediately.
I have also updated the technical paper. The details of the optimisations in zsync-0.2.x are now included, and I have refreshed all the empirical data to reflect the new version. We are comparing very favourably with rsync now, with only rsync's -z option able to really beat zsync — but if I get mod_gzip installed, we shall see if zsync can match that, too.
[17:39] | [/computers/zsync] | #
Tue, 08 Feb 2005
Reminiscences of a Stock Operator
I just finished reading this, and I can understand why it is a classic book. It's a great story of the ebb and flow of fortune, in both senses of the word. The story is apparently very true to life of real stock market behavior, albeit regulation is better these days.
I particularly liked the comment by the expert investor who is the subject of the book, talking about the strange asymmetry in the law when it comes to positive and negative remarks. You can be sued for libel or defamation for making a baseless negative remark that harms someone; but you can make any kind of positive remark about a share, a company, a product, and there's little that can be done about it. Obviously the trade descriptions act and no doubt similar stock legistlation is around these days, but fundamentally there is not that much that can be done to prevent people making upbeat claims about things.
The book if full of clever stories illustrating how blindly most people invest — in fact, how they are even more eager to follow tips when they are anonymous and baseless. Give people a detailed reason why soemthing will happen, and their eyes glaze over; give them a "hot tip", and they get excited. There's a great story in there about an investor following a tip without knowing where it comes from; when he later finds out that the tip came from his father-in-law, he says "Why on Earth didn't you say it was him?" — an anonymous tip was thought better than a tip from someone he actually knew, when clearly the reverse should be true in all circumstances.
I would recommend this book as the perfect cure for anyone foolish enough to believe they can beat the stock market, or any game that they know less about than the experts and insiders. But as Lefèvre says himself in the book, people reading it were only encouraged to invest all the more, because they, like everyone else, believed they would be the one person smart enough to beat the system. People are fools, and never change.
[21:09] | [/books] | #
zsync 0.2.1 released
Sorry about that, but zsync-0.2.0 had a paper-bag bug. It would go into an infinite loop when more than one local source file was supplied. This is now fixed; in fact I have taken the chance to clean up the hashing code a little.
I have also improved compressed stream support; zsync now has the beginnings of support for gzip files containing stored blocks. These typically occur when compressing binary or other files that contain sections that do not compress well. Without supporting these, I can't really claim that zsync can transfer gzip files — at the moment, it just happens to work on must compressed text files. There is more work to do, but this is the first 90% that takes 10% of the work, and it brings us closer at least.
[20:45] | [/computers/zsync] | #
Konichiwa
It seems I have been slashdotted — by slashdot.jp, at least. Or so I assume, based on the sudden list of Japanese blogs, news sites and such in the referrer log for yesterday. But since I have no idea what any of these sites say, I am none the wiser.
[20:31] | [/misc] | #
Sun, 06 Feb 2005
0.2.0 released
zsync 0.2.0 is now released. This is a major overhaul of the underlying rsync algorithm, using ideas taken from Improved Single-Round Protocols for Remote File Synchronization. Changes to the control file have cut it by around 60-70% in size. I think this will significantly improve the effectiveness of zsync, as it is now very close to rsync for efficiency, and this change enables smaller blocksizes to be used where they were prohibitive before. Even a blocksize of 512 bytes is practical for many files now.
I have updated the technical paper with new figures for uncompressed transfers, and I have increased the comparison with rsync too. I have yet to update the section on compressed transfers. It is likely that this improvement will have significantly changed the picture for compressed transfers; it would not surprise me is the look-inside method is no longer better than simply using rsyncable gzip files, because the overhead of transmitting a map of the compressed data starts to look much larger relative to the other metadata now.
The client is backward compatible with older control files. Old clients are not forward compatible with newer control files, though. I will leave the streams on this site int eh old format for a week or two before I switch over.
[19:32] | [/computers/zsync] | #
Tue, 01 Feb 2005
Wrecked my / partition
Well, that was fun. I was using cdparanoia to rescue the content off of some old audio CDs, and Linux completely died. It managed to corrupt the root partition so badly, that after an e2fsck the only files were in /lost+found. There must be a problem with DMA and CD-audio data on this SiS IDE chipset? It must be a while since I last ripped an audio CD, so perhaps I have really never tried it on this machine before.
Fortunately /home was unaffected, so I have reinstalled Debian and am already almost back to where I started. I am glad I had a backup rfom only a couple of weeks ago — and even more glad that I wasn't forced to test it :-).
[21:02] | [/computers/linux] | #