Of course, if the dominant web browser weren't vulnerable to installing trojan software on a user's computer in the first place this would be a moot point.
Yes, but I don't think a web browser other than MSIE, Safari, or Mozilla is likely to become dominant in the near future.
There was a bug in the vBuild component of InstallShield last summer which could result in an accidental `rm -rf ~`. After being bitten by it once (fortunately I noticed the disk activity before it deleted anything for which I didn't have backups), I helped to track down the problem; apparently at one point there was a "mkdir/cachedir; cd/cachedir; rm -rf *" (or rather, the equivalent in C) and they never checked the return codes of the first two operations.
So, to everyone who is asking "what if he made a mistake?": Mistakes can result in data loss even if you don't intend to delete anyone's data.
but I worry about the psychological impact of making computers look less like computers. People have been taught for the past few years that they have to keep their computers up to date with security patches, that they should have a firewall and a virus scanner... but this doesn't look like what people recognize as a "computer". It isn't even advertised as a computer; it's called a "web pad".
Combining the innate cluelessness of most of the people who will buy these, the fact that these don't "look like computers", the fact that these are wireless-only as far as networking is concerned, and the lack of apparent infrastructure for distributing security patches... I have to wonder how well these machines will fare once they reach the real (insecure) world.
Second rule (for advanced readers): Don't, unless you can find something which absolutely everybody will enjoy.
Buy everyone beer? What about the guy who doesn't drink (either by choice, or for medical reasons)? Take everyone to the football game? What about the guy who doesn't like football, or the guy who has to stay home to look after his kids? Throw a really expensive Christmas party? What about the people who don't celebrate Christmas, or who celebrate it a couple weeks later? Have everybody play Unreal Tournament? What about the guy who gets motion sick?
"Team building" sounds great, but paying for 90% of people to do something together that they really enjoy doesn't help build a team; rather, it makes the other 10% of people feel even more isolated.
Teams build themselves. People form friendships, and find activities on their own. Let this happen naturally; don't try to push it forwards prematurely.
RPM can support this. You need to package the rpm with rsync friendly gzip then on the target box assemble the bits you have on disk from the original and rsync the two.
As I've noted several times already, rsync does a really horrible job of synchronizing compiled binaries. Your rsync-friendly-deflate will allow you to effectively avoid retransmitting unmodified files (which, as also noted here, SuSE achieves simply by creating "patch" rpms with only the modified files), but it won't help you take advantage of the similarity between the old and new versions of any individual binary.
rsync tends to perform very poorly on compiled binaries, due to artifacts introduced in the linking process.
Then so will the delta compression. I think most of the delta programs you see are children of rsync.
Yes and no. Most delta compression programs suffer from the same difficulty which plagues rsync, but to a lesser extent because smaller block sizes are used when building a patch between two local files. bsdiff avoids that problem entirely by using a more sophisticated encoding method.
It isn't unusual for bsdiff to provide 50-fold compression, xdelta to provide 10-fold compression, and rsync to save only 50% (ie, 2-fold compression).
65 times smaller? So a patch that's normally 100k is now 1.5k?
Maybe sometimes, but I don't see that happening on average.
Look at the statistics yourself. The average patch compression ratio (ie, [size of new file] / [size of patch file]) for FreeBSD Update is 66.404 right now. (Ignore the "Speedup due to patching" line -- that includes files which were downloaded before delta compression support was added.)
In fact, my current development code produces patches around 30% smaller than that, but I haven't released it yet.
Rsync is certainly good, but it has limitations. First, it is a protocol, which means that you need to be running a daemon (possible security issue), and it needs to be accessible (offline patching is impossible). Second, rsync tends to perform very poorly on compiled binaries, due to artifacts introduced in the linking process.
He should perhaps be more correctly asking when one of the 'binary' distributions of Linux (or of a Linux 'based' OS to be exact) will plan on offering this.
I asked about Linux vendors... isn't that clear enough? Certainly when I hear "Linux vendors" I think "Redhat, SuSE, Mandrake, and other companies which make money by distributing operating systems built around the Linux kernel".
One advantage of gzip is that it requires less memory to decompress. It probably doesn't matter if someone's old Pentium 90 with 16MB of RAM takes a while to decompress a file, but that machine will probably *never* successfully extract an archive compressed with bzip2 (at least with the default 900kB block size).
Nope. SuSE's "patches" are created by packaging all the files which are affected by a security fix; those files are packaged intact, without any delta compression.
Now, this is certainly a step forward from the common (eg, Debian, RedHat) approach of having people download a complete new package, including copies of files which haven't changed at all, but SuSE's approach is still suboptimal by more than an order of magnitude.
Binary diffs only really make sense when you have huge packages that require a whole new package for upgrade
Binary diffs make sense any time you've got large files being updated. On my system, libssl (library archive + shared object file + profiled library) is 600kB; that's large enough to justify using a 10kB binary diff instead.
I bet the average RPM is about the same size as the minium binary diff from MS.
I can't say anything about Microsoft's patches directly, but the patches used by FreeBSD Update are on average 65 times smaller than the individual files being updated. As little faith as I have in Microsoft, I still doubt that they could produce patches which were sub-optimal by more than a factor of 50.
Sorry, the writeup was a bit unclear. Windows XP SP2 contains a new version of Windows Installer (or whatever they're calling it today). This new version includes support for downloading updates via binary diffs, and most updates to XP after this point should be done that way.
The worst nuclear disaster in history, Cherynobl, killed a total of 3,000 people. That includes long term deaths attributed to radiation poisoning and increased cancer rates. Coal mining on the other hand kills around 30,000 people every year in mining accidents alone.
Not only that, but coal power plants release more radioactivity into the athmosphere each year than nuclear power; almost all coal deposits contain small quantities of uranium, which goes up into the air amidst the rest of the coal smoke.
Are there any tricks to installing just the very basics?
That depends upon how minimal an install you want to get. If you avoid installing man pages, cat pages, profiled libraries, compat libraries, and the src/ and ports/ trees, you'll get down to around 100MB. If you want to get the system smaller than that, you have two options: Perform surgery (ie, run around with rm -f) on a binary installation, or build with custom make flags (eg, NO_CVS, NO_CXX, NO_BIND, NO_FORTRAN...) and install onto a clean filesystem.
Personally, I prefer to do a complete install and then remove unwanted files; if you remove/usr/bin/{c++ g++ CC gcc cc yacc byacc f77 addr2line ar as gasp gdb gdbreplay ld nm objcopy objdump ranlib readelf size strip},/usr/lib/*.a,/usr/libexec/cc1*, and/usr/libexec/f771, you'll save 45MB (at the expense of being unable to build anything, but you're going to be using binary security updates and building packages on a different machine, right?)
I also have an experimental patch which "packages" the base system, making it simpler to remove components (eg, Sendmail), but I wouldn't recommend this for anyone unfamiliar with FreeBSD.
Recent benchmarks have demonstrated that, once running, a well-coded Java program is about as fast as a well-coded C program.
However, the "once running" issue is a big problem. Java startup time is slow, simply by virtue of the time it takes to load everything off of disk. And, unless you're running a server -- which most people aren't -- the startup time is by far the most important performance criterion in determining subjective performance.
Give me back my <20kB executables, and I'll consider using Java.
For all of those who have been complaining about the large update size (90MB for a single online system; 250MB for everything), there is good news in SP2: Future updates will be much smaller. One of the new features in WMI 3.0 (which is bundled in SP2) is Microsoft's "Binary Delta Compression".
Now, while I know how BDC works, I don't know exactly how effective Microsoft's implementation is; however, my own binary diff code is providing an average 67-fold compression for the security updates used by FreeBSD Update right now. (In fact, the security patches for any supported FreeBSD release can fit onto a floppy disk.)
Microsoft's a year behind FreeBSD here, but I sure hope everybody else isn't a year behind Microsoft... otherwise, Windows users will be downloading 100-200 kB security patches once a month while they laugh at Linux users who have to download 10 MB patches.
Anyone know if vinum_geom will be stable in time for 5.3-RELEASE? Or if there's a native GEOM raid solution?
Quoth the status report:
Contact: Pawel Jakub Dawidek
I'm working on various GEOM classes. Some of them are already committed and ready for use (GATE, CONCAT, STRIPE, LABEL, NOP). The MIRROR class is finished in 90% and will be committed in very near future. Next I want to work on RAID3 and RAID5 implementations. Userland utility to control GEOM classes (geom(8)) is already in the tree.
The article is co-written by Robert Watson, a DARPA principal investigator in the Host Intrusion Protection (HIP) Research Group at McAfee Research... and three-term FreeBSD core team member, guy mostly responsible for FreeBSD network stack locking right now, president of the FreeBSD Foundation, and otherwise generally cool guy.
Slashdot and Other Style [...]
Kincaid: 7.7
ARI: 8.0
Coleman-Liau: 9.7
Flesch Index: 72.4
Fog Index: 10.7
Lix: 37.1 = school year 5
SMOG-Grading: 9.8
For comparison, here are the statistics for the article itself:
Kincaid: 7.1
ARI: 7.3
Coleman-Liau: 11.3
Flesch Index: 69.0
Fog Index: 9.8
Lix: 36.7 = school year 5
SMOG-Grading: 9.7
Mac users may or may not be smarter than PC users, but Paul Murphy is evidently not any smarter than the average slashdot poster.
Slashdot Mirror
Of course, if the dominant web browser weren't vulnerable to installing trojan software on a user's computer in the first place this would be a moot point.
Yes, but I don't think a web browser other than MSIE, Safari, or Mozilla is likely to become dominant in the near future.
There was a bug in the vBuild component of InstallShield last summer which could result in an accidental `rm -rf ~`. After being bitten by it once (fortunately I noticed the disk activity before it deleted anything for which I didn't have backups), I helped to track down the problem; apparently at one point there was a "mkdir /cachedir; cd /cachedir; rm -rf *" (or rather, the equivalent in C) and they never checked the return codes of the first two operations.
So, to everyone who is asking "what if he made a mistake?": Mistakes can result in data loss even if you don't intend to delete anyone's data.
but I worry about the psychological impact of making computers look less like computers. People have been taught for the past few years that they have to keep their computers up to date with security patches, that they should have a firewall and a virus scanner... but this doesn't look like what people recognize as a "computer". It isn't even advertised as a computer; it's called a "web pad".
Combining the innate cluelessness of most of the people who will buy these, the fact that these don't "look like computers", the fact that these are wireless-only as far as networking is concerned, and the lack of apparent infrastructure for distributing security patches... I have to wonder how well these machines will fare once they reach the real (insecure) world.
Second rule (for advanced readers): Don't, unless you can find something which absolutely everybody will enjoy.
Buy everyone beer? What about the guy who doesn't drink (either by choice, or for medical reasons)?
Take everyone to the football game? What about the guy who doesn't like football, or the guy who has to stay home to look after his kids?
Throw a really expensive Christmas party? What about the people who don't celebrate Christmas, or who celebrate it a couple weeks later?
Have everybody play Unreal Tournament? What about the guy who gets motion sick?
"Team building" sounds great, but paying for 90% of people to do something together that they really enjoy doesn't help build a team; rather, it makes the other 10% of people feel even more isolated.
Teams build themselves. People form friendships, and find activities on their own. Let this happen naturally; don't try to push it forwards prematurely.
a brilliant criminal is just someone who's skills are being expressed in the right forum, but in the wrong direction...
Sure, but where's this brilliant criminal of whom you're writing? It doesn't take brilliance to write something like Sasser.
RPM can support this. You need to package the rpm with rsync friendly gzip then on the target box assemble the bits you have on disk from the original and rsync the two.
As I've noted several times already, rsync does a really horrible job of synchronizing compiled binaries. Your rsync-friendly-deflate will allow you to effectively avoid retransmitting unmodified files (which, as also noted here, SuSE achieves simply by creating "patch" rpms with only the modified files), but it won't help you take advantage of the similarity between the old and new versions of any individual binary.
Yes and no. Most delta compression programs suffer from the same difficulty which plagues rsync, but to a lesser extent because smaller block sizes are used when building a patch between two local files. bsdiff avoids that problem entirely by using a more sophisticated encoding method.
It isn't unusual for bsdiff to provide 50-fold compression, xdelta to provide 10-fold compression, and rsync to save only 50% (ie, 2-fold compression).
Come to think of it, it would be nice if tar just detected compression and you did not have to give it -z either! Can this be done?
Yes. bsdtar does this.
65 times smaller? So a patch that's normally 100k is now 1.5k?
Maybe sometimes, but I don't see that happening on average.
Look at the statistics yourself. The average patch compression ratio (ie, [size of new file] / [size of patch file]) for FreeBSD Update is 66.404 right now. (Ignore the "Speedup due to patching" line -- that includes files which were downloaded before delta compression support was added.)
In fact, my current development code produces patches around 30% smaller than that, but I haven't released it yet.
Rsync is certainly good, but it has limitations. First, it is a protocol, which means that you need to be running a daemon (possible security issue), and it needs to be accessible (offline patching is impossible). Second, rsync tends to perform very poorly on compiled binaries, due to artifacts introduced in the linking process.
He should perhaps be more correctly asking when one of the 'binary' distributions of Linux (or of a Linux 'based' OS to be exact) will plan on offering this.
I asked about Linux vendors... isn't that clear enough? Certainly when I hear "Linux vendors" I think "Redhat, SuSE, Mandrake, and other companies which make money by distributing operating systems built around the Linux kernel".
One advantage of gzip is that it requires less memory to decompress. It probably doesn't matter if someone's old Pentium 90 with 16MB of RAM takes a while to decompress a file, but that machine will probably *never* successfully extract an archive compressed with bzip2 (at least with the default 900kB block size).
SUSE already does this.
Nope. SuSE's "patches" are created by packaging all the files which are affected by a security fix; those files are packaged intact, without any delta compression.
Now, this is certainly a step forward from the common (eg, Debian, RedHat) approach of having people download a complete new package, including copies of files which haven't changed at all, but SuSE's approach is still suboptimal by more than an order of magnitude.
Binary diffs only really make sense when you have huge packages that require a whole new package for upgrade
Binary diffs make sense any time you've got large files being updated. On my system, libssl (library archive + shared object file + profiled library) is 600kB; that's large enough to justify using a 10kB binary diff instead.
I bet the average RPM is about the same size as the minium binary diff from MS.
I can't say anything about Microsoft's patches directly, but the patches used by FreeBSD Update are on average 65 times smaller than the individual files being updated. As little faith as I have in Microsoft, I still doubt that they could produce patches which were sub-optimal by more than a factor of 50.
Sorry, the writeup was a bit unclear. Windows XP SP2 contains a new version of Windows Installer (or whatever they're calling it today). This new version includes support for downloading updates via binary diffs, and most updates to XP after this point should be done that way.
The worst nuclear disaster in history, Cherynobl, killed a total of 3,000 people. That includes long term deaths attributed to radiation poisoning and increased cancer rates. Coal mining on the other hand kills around 30,000 people every year in mining accidents alone.
Not only that, but coal power plants release more radioactivity into the athmosphere each year than nuclear power; almost all coal deposits contain small quantities of uranium, which goes up into the air amidst the rest of the coal smoke.
Are there any tricks to installing just the very basics?
...) and install onto a clean filesystem.
/usr/bin/{c++ g++ CC gcc cc yacc byacc f77 addr2line ar as gasp gdb gdbreplay ld nm objcopy objdump ranlib readelf size strip}, /usr/lib/*.a, /usr/libexec/cc1*, and /usr/libexec/f771, you'll save 45MB (at the expense of being unable to build anything, but you're going to be using binary security updates and building packages on a different machine, right?)
That depends upon how minimal an install you want to get. If you avoid installing man pages, cat pages, profiled libraries, compat libraries, and the src/ and ports/ trees, you'll get down to around 100MB. If you want to get the system smaller than that, you have two options: Perform surgery (ie, run around with rm -f) on a binary installation, or build with custom make flags (eg, NO_CVS, NO_CXX, NO_BIND, NO_FORTRAN
Personally, I prefer to do a complete install and then remove unwanted files; if you remove
I also have an experimental patch which "packages" the base system, making it simpler to remove components (eg, Sendmail), but I wouldn't recommend this for anyone unfamiliar with FreeBSD.
Recent benchmarks have demonstrated that, once running, a well-coded Java program is about as fast as a well-coded C program.
However, the "once running" issue is a big problem. Java startup time is slow, simply by virtue of the time it takes to load everything off of disk. And, unless you're running a server -- which most people aren't -- the startup time is by far the most important performance criterion in determining subjective performance.
Give me back my <20kB executables, and I'll consider using Java.
For all of those who have been complaining about the large update size (90MB for a single online system; 250MB for everything), there is good news in SP2: Future updates will be much smaller. One of the new features in WMI 3.0 (which is bundled in SP2) is Microsoft's "Binary Delta Compression".
Now, while I know how BDC works, I don't know exactly how effective Microsoft's implementation is; however, my own binary diff code is providing an average 67-fold compression for the security updates used by FreeBSD Update right now. (In fact, the security patches for any supported FreeBSD release can fit onto a floppy disk.)
Microsoft's a year behind FreeBSD here, but I sure hope everybody else isn't a year behind Microsoft... otherwise, Windows users will be downloading 100-200 kB security patches once a month while they laugh at Linux users who have to download 10 MB patches.
... with this, and Linux gets to join the "visit a malicious website and get rooted" crowd.
That's funny given that apache uses one task per connection...
The grandparent was referring to apache 2.0, which can use a single process for more than one connection.
Quoth the status report:
The article is co-written by Robert Watson, a DARPA principal investigator in the Host Intrusion Protection (HIP) Research Group at McAfee Research ... and three-term FreeBSD core team member, guy mostly responsible for FreeBSD network stack locking right now, president of the FreeBSD Foundation, and otherwise generally cool guy.
Slashdot and Other Style
[...]
Kincaid: 7.7
ARI: 8.0
Coleman-Liau: 9.7
Flesch Index: 72.4
Fog Index: 10.7
Lix: 37.1 = school year 5
SMOG-Grading: 9.8
For comparison, here are the statistics for the article itself:
Kincaid: 7.1
ARI: 7.3
Coleman-Liau: 11.3
Flesch Index: 69.0
Fog Index: 9.8
Lix: 36.7 = school year 5
SMOG-Grading: 9.7
Mac users may or may not be smarter than PC users, but Paul Murphy is evidently not any smarter than the average slashdot poster.
So in theory cracker has to crack at least two servers...
Or at least one machine on the same network segment as you.