It isn't hard to create a key, upload it to the keyservers, and sign your backdoored glibc.
So unless you can trust the entity who signed the package, it's all moot.
Obviously, the debian project could sign the package using the Debian Package Signing Key, but you've just changed the problem from "how can an end user know that this key is worth trusting" to "how can debian know that this key is worth trusting". This is (probably) solvable, but still quite hard.
Note that the technology is easy, but the processess to back it up aren't.
OSS leaves just as much to "chance" as a closed source model.
How does a closed-source shop know that one of their developers hasn't cut'n'pasted something from glib? Same was as OSS: ask the developer, and assume that they're not out to screw you.
Finally, your solution would be expensive - who would pay for it?
Another thing I wonder about is the FSF policy of only accepting patches when the author transfers copyright to the FSF (fun question: why is the GPL not good enough for them?).
Because only the copyright holder can sue over the licence. You don't have a couple of lawyers on staff, but the FSF does.
Some BIOSes don't set up HyperThreading on CPUs that support it, so the OS has to. HyperThreading works on FreeBSD 4.x (with an SMP kernel) if the BIOS waves the approprate magic wand.
Expanding the size of today's simple data structures. Consider, for example, a simple bi-directional linked list of 32-bit integers using a forwards and backwards pointer. A 32 bit arch has a 200% overhead, but 64 bit ach has 400% which should somewhat diminish expectations for magical performance!
This is a non-problem - memory is cheap, and if it is not cheap enough to store your linked list of a bazillion ints then you need to change your data structure or algorythms.
However, the biggest performance disbenifit from going 32->64 bits will cache misses. The major performance bottleneck on CPU intensive apps these days is how often you get a cache miss as opposed to a cache hit; by making things twice as big, you're cache will only hold half as many of them.
On those platforms which let you choose if you want to be 32 bit or 64 bit app on a per-application basis, I'm using this rule of thumb: "32 bits unless benchmarks prove me wrong, or I need the address space".
I must admit, I gave into the hype and bought the first Harry Potter book. It was... okay, I guess. I was expecting something a lot more complex, though, and I was disappointed - it reminded me more of Enid Blyton than anything else.
Yes, the first HP books are written in a fairly simplistic way; but as the series progresses they get more complex, both in terms of the the plot and the language used.
The series doen't get really good, IMO, until book 3 (Prisoner of Azkaban); GoF is really excellent.
I'm still not sure it deserves a Hugo, though, and I'm a Potterphile.
Speed of light: 3*10^8 m/s (approx)
Clock tick: 1*10^-9 s (1 GHz)
Distance traveled: 3*10^8*10^-9 = 0.3 m
crank it up to 10GHz and it's 0.03 m ('bout an inch and a half for all you unmetricified folk).
I think it was cray that made sure all the wires in one of their supercomputers were multiples of a clock tick in length.
Then you just go home, look at your database, and work out where they've taken your factoid:) After all, it'd still be transmitting it's data back to YOUR home. Hmm, it'd probably even tell you the address of the person who had it when they walked into their house..
You're assuming that the thief is after stealing the hardware, not the data. Borrow the device, suck the data out, replace the device. The victim doesn't know a theft has happened - until the blackmail demand rolls in). Or get a court order to force you to hand it over, whichever is easier in the situation.
The problem with these kinds of technologies is how they can be abused, both technical and legal safeguards need to be in place.
'course, I've got no idea what technical safeguards are in place with the currant crop, I'll bet it's not enough, though. It never is.
Slashdot Mirror
It isn't hard to create a key, upload it to the keyservers, and sign your backdoored glibc.
So unless you can trust the entity who signed the package, it's all moot.
Obviously, the debian project could sign the package using the Debian Package Signing Key, but you've just changed the problem from "how can an end user know that this key is worth trusting" to "how can debian know that this key is worth trusting". This is (probably) solvable, but still quite hard.
Note that the technology is easy, but the processess to back it up aren't.
OSS leaves just as much to "chance" as a closed source model.
How does a closed-source shop know that one of their developers hasn't cut'n'pasted something from glib? Same was as OSS: ask the developer, and assume that they're not out to screw you.
Finally, your solution would be expensive - who would pay for it?
Because only the copyright holder can sue over the licence. You don't have a couple of lawyers on staff, but the FSF does.
Some BIOSes don't set up HyperThreading on CPUs that support it, so the OS has to. HyperThreading works on FreeBSD 4.x (with an SMP kernel) if the BIOS waves the approprate magic wand.
Apparently.
Expanding the size of today's simple data structures. Consider, for example, a simple bi-directional linked list of 32-bit integers using a forwards and backwards pointer. A 32 bit arch has a 200% overhead, but 64 bit ach has 400% which should somewhat diminish expectations for magical performance!
This is a non-problem - memory is cheap, and if it is not cheap enough to store your linked list of a bazillion ints then you need to change your data structure or algorythms.
However, the biggest performance disbenifit from going 32->64 bits will cache misses. The major performance bottleneck on CPU intensive apps these days is how often you get a cache miss as opposed to a cache hit; by making things twice as big, you're cache will only hold half as many of them.
On those platforms which let you choose if you want to be 32 bit or 64 bit app on a per-application basis, I'm using this rule of thumb: "32 bits unless benchmarks prove me wrong, or I need the address space".
The bbc has a story about a Robot hand for the disabled. Doesn't look like it's available yet, and it'll probably cost $BIGNUM, though.
I must admit, I gave into the hype and bought the first Harry Potter book. It was... okay, I guess. I was expecting something a lot more complex, though, and I was disappointed - it reminded me more of Enid Blyton than anything else.
Yes, the first HP books are written in a fairly simplistic way; but as the series progresses they get more complex, both in terms of the the plot and the language used.
The series doen't get really good, IMO, until book 3 (Prisoner of Azkaban); GoF is really excellent.
I'm still not sure it deserves a Hugo, though, and I'm a Potterphile.
Speed of light: 3*10^8 m/s (approx)
Clock tick: 1*10^-9 s (1 GHz)
Distance traveled: 3*10^8*10^-9 = 0.3 m
crank it up to 10GHz and it's 0.03 m ('bout an inch and a half for all you unmetricified folk).
I think it was cray that made sure all the wires in one of their supercomputers were multiples of a clock tick in length.
ftp://ftp.opengroup.org/pub/open motif/R2.1.30/tars
You'll probably be better off using a command line ftp client while the server is slahdotted.
You're assuming that the thief is after stealing the hardware, not the data. Borrow the device, suck the data out, replace the device. The victim doesn't know a theft has happened - until the blackmail demand rolls in). Or get a court order to force you to hand it over, whichever is easier in the situation.
The problem with these kinds of technologies is how they can be abused, both technical and legal safeguards need to be in place.
'course, I've got no idea what technical safeguards are in place with the currant crop, I'll bet it's not enough, though. It never is.