Unless you're German...

I guess it really depends on the details. The two bottlenecks are certainly worrisome: 1) the need for analysts familiar with both the system, and domain experts, to classify the data; 2) that the data is made available to a a wide range of users.

Let's hope the trial is realistic enough to bring up potential problems before real people get pulled in because of an overreliance on technology...

You could say the same thing about search engines back in the mid-90s, before Google's PageRank. What's the point of indexing more and more information if it's impossible to find the relevant page? Necessity is the mother of all inventions. The only regret here is that whatever they come up with, probably won't see daylight until someone outside reimplements it.

Thanks for the reply. Both options certainly are valid, and it's not as if Apple has a clear-cut policy w.r.t. ebooks on the App Store (though Jobs is known to have a rather bizarrely dismissive attitude towards reading). I guess it boils down to two separate issues: usability, and ease-to-publish.

Usability-wise, for light reading having individual book "apps" might save time. Then again, for heavy readers, or for readers who like organizing their book collection (sort by author name, sort by title, by year etc.) individual apps can't cut it. Also, different ebook apps will inevitably have different interfaces.

This ties it to the second point. As long as Apple acts as a gatekeeper, and with its current byzantine approval process, any bugfix, as you pointed out in the article, cannot be pushed in a timely manner. Worse -- say you have n books, all prepared in the same way. You'd have to push n updates, all of them might have to be resubmitted if they get rejected!

Both suggests that, while yes, Apple's App Store poses commercial risks (wasn't there a commercially-developed emulator that got rejected too), it might not be an effective conduit for books anyway. Between Stanza (for free books) and Kindle (for paid books), there are ways to publish digitally without running afoul of the censors.

... this example is not necessarily the best way to publish electronic books. Wouldn't it be better to put the book (both editions) up on Amazon Kindle, and let people use the Kindle app for the iPhone?

Imagine the horror of having a 1,001 authors all packaging their books as separate apps...

It's a modified bsdiff algorithm; it does not actualy reuse the original bsdiff

Or would be better faster: the current version's performance appears to be quite impressive, matching FreeBSD and Linux.

Binaries should, with rare occasion, not be under source control anyway.

Ah, delta RPM turns out to use normal compression, no binary diffing is involved:

$ rpm -q deltarpm --requires
libbz2.so.1()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
librpm.so.0()(64bit)
librpmio.so.0()(64bit)
rpmlib(CompressedFileNames) = 3.0.4-1
rpmlib(FileDigests) = 4.6.0-1
rpmlib(PayloadFilesHavePrefix) = 4.0-1
rtld(GNU_HASH)

Ah, that is indeed correct. A bit disappointing, but upon reflection, going binary->assembly code->diff would likely result in a larger patch anyway, even if the diff is then compressed efficiently.

There is no need to weaponize the moon -- anything you launch for there would have to clear the lunar gravitation field, and then travel hundreds of thousands of miles. The goal during Reagan's Star Wars era is to militarize near space -- lasers achieve greater intensities at a nearer distance, projectiles get accelerated "for free" by the earth's gravitational field, and below geostationary orbit, you can position a satellite anywhere on the planet within hours.

The cool thing is, one can easily extend this to other executable formats, as long as the assembler is readily available client-side: Windows users could relate to those pesky, resource-hogging Java updates, and .NET and Mono applications could similarly benefit.

This is, interestingly, the second binary diffing innovation that affects me in the past few months. Fedora just turned on delta updates with Fedora 11, a feature borrowed from the openSUSE folks.

By your definition, OS X is not an operating system. It's specifically not licensed to third-parties.

One possibility is if it's taken up by OS vendors (Linux distributions, Apple) as their remote windowing solution. Red Hat/Fedora is heavily VNC-focused -- with the installation process doable over VNC, and both full desktops (GNOME and KDE) coming with their own VNC servers. Apple's OS X also has a VNC server, AFAIR. Microsoft, naturally, has their own solutions...

Google will most likely use this in some way within Chrome OS -- if it shares many innards with Android, the graphics obviously won't be X11-based, and so if their NeatX can be adapted to that, it will make the OS much more usable than just running web apps.

You mean NoProduct(TM)