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...
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.
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.
Honda also has a hydrogen prototype -- the FCX Clarity. What does that have to do with not developing hybrids? A smart car manufacturer would be developing multiple new technologies, and not tie themselves to one.
German car manufacturers were actually even more hydrogen-fixated than the Detroit 3 for a while, but even they are moving to produce hybrids now (Mercedes Benz has a new S-class hybrid coming out, and BMW has models with regenerative braking).
Don't forget being able to completely shut off the gas engine when idling, and the better torque provided by electric motors when accelerating from standstill. Oh, and regenerative braking.
Now, a diesel engine is still more efficient than gasoline-powered hybrids, but Volkswagen is coming up with an interesting hybrid diesel -- it should get around 100 mpg.
RPMfusion follows Fedora's policy of only supporting the 2 most recent releases (i.e. 10 and 11). I just looked at their repository and indeed, the packages for Fedora 8 and 9 have been removed.
A private company "developed" the Green Dam software. Granted that the Chinese government obviously did not screen them properly, but why is this not Shanzai?
âoeWe had no idea who it was,â said Mr. Wales, who said there was no indication the person had ill intent. âoeThere was no way to reach out quietly and say âDude, stop and think about this.â(TM) â
What they should have done is to disallow anonymous editing for that page, and then if the would-be editor actually has a username, and log in to make an edit, they can use his e-mail address to contact him privately.
The South African law is even more bizarre: there it's purely proportional, but there are "transfer windows" where MPs can move across the aisle carrying their seats with them.
Though over there, it's benefited the ruling party more often than note.
This already happens. You think all those wedding parties in Afghanistan are accidentally bombed? The warlords are framing each other to the US military, and the US takes the blame.
There are only so many routers that lead into the US. Set these up to monitor email traffic (is it port 22? 25? I don't remember)... and look for patterns
But an email message might be cut into multiple packets, and the router might not see the entire message. This poses several problems:
- dropping a packet means it will be re-sent, probably through a different, non-filtering router
- the sender might readjust its MTU repeatedly to make sure that the spam messages get cut up differently each time, thus reducing substantially the number of exact matches
- even without these countermeasures, and simplifying to 1-packet short emails, this is expensive in both space (amount of memory needed to store suspect packets) and time (having to parse every inbound packet).
Slashdot Mirror
``No American soldier has been killed by an enemy aircraft since 1951.''
I'm quite sure not all the pilots shot down by MiG-21s over Vietnam managed to bail out. Unless pilots don't count as soldiers...
David Hasselhoff doesn't look nearly as cool as we remember him to be either...
Unless you're German...
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
Who knows; perhaps, if OpenBSD didn't exist, NetBSD would be better?
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)
Honda also has a hydrogen prototype -- the FCX Clarity. What does that have to do with not developing hybrids? A smart car manufacturer would be developing multiple new technologies, and not tie themselves to one.
German car manufacturers were actually even more hydrogen-fixated than the Detroit 3 for a while, but even they are moving to produce hybrids now (Mercedes Benz has a new S-class hybrid coming out, and BMW has models with regenerative braking).
Don't forget being able to completely shut off the gas engine when idling, and the better torque provided by electric motors when accelerating from standstill. Oh, and regenerative braking.
Now, a diesel engine is still more efficient than gasoline-powered hybrids, but Volkswagen is coming up with an interesting hybrid diesel -- it should get around 100 mpg.
RPMfusion follows Fedora's policy of only supporting the 2 most recent releases (i.e. 10 and 11). I just looked at their repository and indeed, the packages for Fedora 8 and 9 have been removed.
... or Microsoft. Remember FoxPro?
A private company "developed" the Green Dam software. Granted that the Chinese government obviously did not screen them properly, but why is this not Shanzai?
Quoting the article:
What they should have done is to disallow anonymous editing for that page, and then if the would-be editor actually has a username, and log in to make an edit, they can use his e-mail address to contact him privately.
The South African law is even more bizarre: there it's purely proportional, but there are "transfer windows" where MPs can move across the aisle carrying their seats with them.
Though over there, it's benefited the ruling party more often than note.
This already happens. You think all those wedding parties in Afghanistan are accidentally bombed? The warlords are framing each other to the US military, and the US takes the blame.
But an email message might be cut into multiple packets, and the router might not see the entire message. This poses several problems:
- dropping a packet means it will be re-sent, probably through a different, non-filtering router
- the sender might readjust its MTU repeatedly to make sure that the spam messages get cut up differently each time, thus reducing substantially the number of exact matches
- even without these countermeasures, and simplifying to 1-packet short emails, this is expensive in both space (amount of memory needed to store suspect packets) and time (having to parse every inbound packet).