It means that the person who wrote the story doesn't know what he's talking about. It's "Debian GNU/Linux 4.0" (or "Debian 4.0") -- 4.0 is the version of the Debian release, and not the Linux release.
As I pointed out, faking changelogs is just an inconvenience to an attacker, but it is more than "nothing".
It may be slightly better than nothing, but it isn't that much better that it's worth mentioning. Any attacker who knows enough to build a fake.deb package will know enough to put something in the changelog, and it may add maybe a minute to the attack.
If you were less smug about the apt features you might be more interested in the lack of their implementation in Ubuntu
Ubuntu uses apt for updates. apt will not upgrade a package if the signature/hash doesn't verify properly, and it currently complains if the signature doesn't exist, and asks the user to confirm. I highly doubt that checking the signature is not done at all in Ubuntu Update Manager, because if that were the case, Ubuntu would have to specifically tell apt to ignore the security features.
Note that the security features will only be noticeable when a check fails. If all the checks pass, then you'll never notice the features at all (unless you notice that it downloads the Release.gpg files, if Ubuntu shows what files it downloads).
Changelogs don't provide any form of security, and package changelogs have been standard in Debian since many, many years ago. (Long before Ubuntu was a gleam in Mark Shuttleworth's eye.) Changelogs should only be treated as a convenience to the user.
And apt supports GPG signing of the Release file, which contains an MD5 and SHA-1 hash of the Packages file, which contains MD5 hashes of the packages. (In other words, apt already does package integrity checking.)
The "web gadget" isn't just the text. It is also a link that takes you to the irrepressible.info page that will give you more information on the text, including where it came from, and where it is being censored.
Sorry, photo in vCard is not the standard for avatars. In fact, there is no standard for avatars. (There are about three different "historical" JEPs for avatars.) In fact, vCard was only a temporary measure (temporary for the last five years), and this is going to be replaced.
Yes, you can always gateway no matter what protocol you use. It's just a question of which protocol is easier to gateway. Apparently, the people who tried to use a combined XMPP/SIP protocol hated it and wanted a native XMPP protocol.
The Jabber philosophy is to make the client simple, and push complexity to the server. SIP is a more complicated protocol.
Jabber originally tried to create a protocol (TINS) that would be a light wrapper around SIP. Google looked at it for their voice chat, at first, but found problems with it, and came up with their own protocol instead. You can look at Peter Saint Andre's blog for more history on Jingle.
Using XMPP also allows the use of transports, which will allow Jabber to connect to SIP and IAX networks, as well as supporting voice connections with MSN, Yahoo, etc.
Actually, the Neuros3 firmware will be based on Rockbox, which is an open source firmware originally written for the Archos. http://open.neurosaudio.com/node/118
I have no idea where you got the idea that Neuros isn't doing anything for ogg support. They were the first portable player to support ogg vorbis. I can't imagine that the N3 will ship without ogg support.
Reiser4 is very stable, except for the recent releases. The recent releases became unstable due to the changes requested by lkml, but I believe that it's getting back to its previous level of stability. (When you make large scale design changes like what was requested on lkml, you're bound to get some bugs.) But before those changes, Reiser4 was extremely stable. The developers stopped being able to find bugs, and users stopped being able to crash it. I've been running Reiser4 since last February, and several people have been running it for longer than that, and I've never had any problems with it. When the current users have stopped being able to crash it (and it's already been in the -mm tree for some time), it's time to put it into the mainline kernel, so that other users can start pounding on it.
No, I think that the last sentence of that paragraph in the problem makes it clear that c is fixed in advance: "But eventually we may be certain that each prisoner will be called in ten times, or twenty times, or any number you choose."
The king can make the required c arbitrarily large compared to k, but he cannot delay c to infinity.
Did you read what I wrote before? The king isn't trying to delay c to infinity. In fact, it's in the king's interest for c to be small. The king's strategy is to get c over with early, in a strategic manner.
But the only requirement is that the king keeps on calling prisoners, and that he call each prisoner at least c times. So he can call the first prisoner c times, then the second prisoner c times, etc. Then when he has called everyone c times, then he just keeps calling the same person over and over. In this way, the king fulfills the requirements, but they never get free.
Same thing with if the king calls the counter c times at the very beginning, and then he can call the other prisoners as many times as he wants, for infinitely long. The counter has been called c times already, and doesn't have to be called any more.
The solution to the problem must assume that the counter is called a sufficient number of times after the other prisoners, and that each prisoner is given enough opportunity to set the count. It is not sufficient to say that each prisoner is simply called a certain number of times.
Slashdot Mirror
It means that the person who wrote the story doesn't know what he's talking about. It's "Debian GNU/Linux 4.0" (or "Debian 4.0") -- 4.0 is the version of the Debian release, and not the Linux release.
See also this posting on debian-project for more technical details.
Note that the security features will only be noticeable when a check fails. If all the checks pass, then you'll never notice the features at all (unless you notice that it downloads the Release.gpg files, if Ubuntu shows what files it downloads).
Changelogs don't provide any form of security, and package changelogs have been standard in Debian since many, many years ago. (Long before Ubuntu was a gleam in Mark Shuttleworth's eye.) Changelogs should only be treated as a convenience to the user.
And apt supports GPG signing of the Release file, which contains an MD5 and SHA-1 hash of the Packages file, which contains MD5 hashes of the packages. (In other words, apt already does package integrity checking.)
I'd like to see his magical truck, where you can dump stuff on it ad infinitum.
It may also be worth looking at ejabberd (which is what jabber.org now uses).
The "web gadget" isn't just the text. It is also a link that takes you to the irrepressible.info page that will give you more information on the text, including where it came from, and where it is being censored.
Sorry, photo in vCard is not the standard for avatars. In fact, there is no standard for avatars. (There are about three different "historical" JEPs for avatars.) In fact, vCard was only a temporary measure (temporary for the last five years), and this is going to be replaced.
Yes, you can always gateway no matter what protocol you use. It's just a question of which protocol is easier to gateway. Apparently, the people who tried to use a combined XMPP/SIP protocol hated it and wanted a native XMPP protocol.
Jabber originally tried to create a protocol (TINS) that would be a light wrapper around SIP. Google looked at it for their voice chat, at first, but found problems with it, and came up with their own protocol instead. You can look at Peter Saint Andre's blog for more history on Jingle.
Using XMPP also allows the use of transports, which will allow Jabber to connect to SIP and IAX networks, as well as supporting voice connections with MSN, Yahoo, etc.
If you read the Jabber.org press release, you'll see that Digium, the main sponsor of Asterisk, has pledged support for Jingle.
re: NAT, Jabber already has a specification (JEP-0065) for bytestream proxying. My guess is that's what will be used to get around NAT.
I assume that it's an averaged quantity. So 24mb/s means that it would take 1000 seconds to send 24 bits.
I have no idea where you got the idea that Neuros isn't doing anything for ogg support. They were the first portable player to support ogg vorbis. I can't imagine that the N3 will ship without ogg support.
Watch your capitalization, there. 24mbit/sec (with a lower-case m) is 24 millibits/second (0.024 bits per second), which is just a tad slow.
Reiser4 is very stable, except for the recent releases. The recent releases became unstable due to the changes requested by lkml, but I believe that it's getting back to its previous level of stability. (When you make large scale design changes like what was requested on lkml, you're bound to get some bugs.) But before those changes, Reiser4 was extremely stable. The developers stopped being able to find bugs, and users stopped being able to crash it. I've been running Reiser4 since last February, and several people have been running it for longer than that, and I've never had any problems with it. When the current users have stopped being able to crash it (and it's already been in the -mm tree for some time), it's time to put it into the mainline kernel, so that other users can start pounding on it.
Same thing with if the king calls the counter c times at the very beginning, and then he can call the other prisoners as many times as he wants, for infinitely long. The counter has been called c times already, and doesn't have to be called any more.
The solution to the problem must assume that the counter is called a sufficient number of times after the other prisoners, and that each prisoner is given enough opportunity to set the count. It is not sufficient to say that each prisoner is simply called a certain number of times.