EE Times article. Today SRAM is used for processor caches, but new multicore chips need massive (i.e. expensive) cache. Because eDRAM is much denser than SRAM, it allows chip designers to fit much more cache in the same size chip, increasing overall performance. IBM and AMD use silicon-on-insulator (SOI) technology, while the rest of the industry uses bulk CMOS; eDRAM for bulk has been available for a while (it's used in Xbox 360 and BlueGene/L for example), but now IBM has developed SOI eDRAM that can be used in IBM's future processors (and maybe AMD's).
It's all done with trees of keys. "The other obvious alternative, having a unique key for each device, would mean that the media key block would be far too large. There will be one billion DVD players built over the life of the system, and if each one needed a separate encryption, there would be no room for the movie. The secret is for each device to have a set of keys rather than a single key. Many of those keys are shared with other devices, but no two devices have exactly the same set of keys."
but how easy do you believe it is to update all those specialized video players, all offline?
Every player has a different key. The key from a software player has been extracted, so only that player needs to be updated. Software players run on Windows PCs that are connected to the Internet, so updating keys should be easy.
One way to accommodate Windows-only apps is to create a version of WINE tailored to run that app (like Crossover). It's not pretty, but it has worked in the past.
The author of this paper thinks that all the programming headaches of supercomputers will have to be brought down to desktop level, but that's probably not going to happen. What problem would it solve?
It would solve the problem of software actually being able to run faster on computers that will be produced in the near future. If the status quo continues, desktop software simply won't get any faster, even when computers get faster; this seems like a real waste.
In my experience Azureus (and presumably other BT clients) will only open about 10 new connections per second, which should be much less than the threshold for a worm detector.
In contrast, when Bitfrost throws away the ability of programs to talk to other programs, it is intrinsically encouraging a monolithic approach to program design
But a program and a process are not the same thing. If an OLPC app is structured as several processes, then they will all run in the same jail and will all be able to communicate with each other.
Also, it's not correct to say that Bitfrost doesn't allow programs to communicate at all. Obviously programs communicate with the X server. And the document mentions D-BUS, so programs are probably allowed to communicate that way.
This article has little to do with BitLocker; it's just repeating what should be a well-known fact: unless a security mechanism is used perfectly, it is vulnerable. People rarely use security perfectly.
...it is completely wrong to say software development requires no capital. This is true even for open source software. Computers, electricity, shelter (for the programmer), food, etc are not free.
True, but most volunteer OSS programmers already have these things (paid for by the day job), so the marginal capital cost of participating in OSS is negligible.
You're behind the times; the BSA already uses these tactics. In particular, I've heard of BSA member companies convincing customers to buy redundant site licenses because it's cheaper than tracking individual licenses in case of an audit.
Net Neutrality is not about the type of traffic, its about the source of the traffic.
Says who? I think treating different protocols equally is necessary to allow innovation in new protocols and applications. Likewise, clients and servers should be treated equally IMO.
QoS that is controlled by customers is neutral, but QoS that is controlled by ISPs is non-neutral. Throttling BitTorrent traffic when customers are asking for the opposite sounds pretty non-neutral to me.
I am assuming that the bloat will mostly be in applications (or user-level frameworks, which amounts to the same thing), not in OS kernels. My impression is that OSes are actually getting more efficient over the years.
OTOH, maybe bloat will not increase as quickly if it actually has a cost.
The average consumer uses an Office product, e-mail, and a browser. None of these use anywhere close to 100% of the CPU for very long even on a Pentium 3, let alone on a 2GHz+ core in a multi-core processor.
Sounds like you haven't tried Vista, Office 2007, and IE7.
It's still mostly true. Going from a 3.0 GHz Conroe to ~3.7 GHz Penryn is only a 30-40% performance increase, but we want a 100% increase. So we can expect that the number of cores and frequency will both increase.
IBM patents everything it can. If IBM doesn't patent something that they create, then another company will, and that company might not be friendly to open source developers. Most newer open source licenses include an explicit grant of patent rights which should eliminate most of these problems.
They don't generate unique decryption keys for each and every player.
My interpretation of the spec is that every individual player has unique keys. Software players may be a little more relaxed, though.
It is at least a class of players (in this case we're only dealing with software players as a sibling post has pointed out) and I wouldn't be surprised if they keys were only unique on the manufacturer level (i.e. Sony has one key for all the players it makes).
The software players may have one set of keys for each app, but then it's easy to update software to change out keys. After several such updates, the software player developers may end up implementing individual keys using online activation to reduce the hassle. Either way, the collateral damage would appear to be minimal.
Even if each player did have a unique decryption key though, they would have no way of knowing which key to revoke.
IMO it's only a matter of time until someone releases a DeCSS-style crack with player keys included....the person who decrypted the data hasn't said "I used player X" since he doesn't want to make it easy for them to revoke the key for "player X".
Plenty of people on the Doom9 forums have admitted to using WinDVD 8 Japanse edition. Besides, there are only two software HD-DVD/Blu-ray players anyway, so AACS LA could just revoke both.
Slashdot Mirror
EE Times article. Today SRAM is used for processor caches, but new multicore chips need massive (i.e. expensive) cache. Because eDRAM is much denser than SRAM, it allows chip designers to fit much more cache in the same size chip, increasing overall performance. IBM and AMD use silicon-on-insulator (SOI) technology, while the rest of the industry uses bulk CMOS; eDRAM for bulk has been available for a while (it's used in Xbox 360 and BlueGene/L for example), but now IBM has developed SOI eDRAM that can be used in IBM's future processors (and maybe AMD's).
It's all done with trees of keys. "The other obvious alternative, having a unique key for each device, would mean that the media key block would be far too large. There will be one billion DVD players built over the life of the system, and if each one needed a separate encryption, there would be no room for the movie. The secret is for each device to have a set of keys rather than a single key. Many of those keys are shared with other devices, but no two devices have exactly the same set of keys."
Each individual player is supposed to have a different key, so if one PS3 gets revoked it doesn't affect the millions of other PS3 owners.
but how easy do you believe it is to update all those specialized video players, all offline?
Every player has a different key. The key from a software player has been extracted, so only that player needs to be updated. Software players run on Windows PCs that are connected to the Internet, so updating keys should be easy.
One way to accommodate Windows-only apps is to create a version of WINE tailored to run that app (like Crossover). It's not pretty, but it has worked in the past.
The author of this paper thinks that all the programming headaches of supercomputers will have to be brought down to desktop level, but that's probably not going to happen. What problem would it solve?
It would solve the problem of software actually being able to run faster on computers that will be produced in the near future. If the status quo continues, desktop software simply won't get any faster, even when computers get faster; this seems like a real waste.
In my experience Azureus (and presumably other BT clients) will only open about 10 new connections per second, which should be much less than the threshold for a worm detector.
This isn't hard to understand; a worm sends thousands of packets per second, each to a different IP address and most legitimate applications don't.
In contrast, when Bitfrost throws away the ability of programs to talk to other programs, it is intrinsically encouraging a monolithic approach to program design
But a program and a process are not the same thing. If an OLPC app is structured as several processes, then they will all run in the same jail and will all be able to communicate with each other.
Also, it's not correct to say that Bitfrost doesn't allow programs to communicate at all. Obviously programs communicate with the X server. And the document mentions D-BUS, so programs are probably allowed to communicate that way.
The OLPC poject gave up on existing software years ago. All OLPC applications must be written (or ported) specifically for OLPC.
The difference is that MS did not create and does not control OpenID. But don't let the facts of the situation get in the way of your rant.
This article has little to do with BitLocker; it's just repeating what should be a well-known fact: unless a security mechanism is used perfectly, it is vulnerable. People rarely use security perfectly.
Can anyone comment on whether KVM is a reasonable alternative to the VMWare Server product?
It will be once the userspace management tools (e.g. virt-manager) catch up.
...it is completely wrong to say software development requires no capital. This is true even for open source software. Computers, electricity, shelter (for the programmer), food, etc are not free.
True, but most volunteer OSS programmers already have these things (paid for by the day job), so the marginal capital cost of participating in OSS is negligible.
You're behind the times; the BSA already uses these tactics. In particular, I've heard of BSA member companies convincing customers to buy redundant site licenses because it's cheaper than tracking individual licenses in case of an audit.
Or is it power used while idle? Does a 1000 device comsume more power idling in that mode than a 10 device would?
Yes and Yes. 1000base-T PHYs are DSPs; IIRC they use about 500mW. Since 100base-T is so much simpler, it should be implementable with less power.
Net Neutrality is not about the type of traffic, its about the source of the traffic.
Says who? I think treating different protocols equally is necessary to allow innovation in new protocols and applications. Likewise, clients and servers should be treated equally IMO.
QoS that is controlled by customers is neutral, but QoS that is controlled by ISPs is non-neutral. Throttling BitTorrent traffic when customers are asking for the opposite sounds pretty non-neutral to me.
I think you mean it's all just part of the game. I'll bet the game uses real bullets, too...
I am assuming that the bloat will mostly be in applications (or user-level frameworks, which amounts to the same thing), not in OS kernels. My impression is that OSes are actually getting more efficient over the years.
OTOH, maybe bloat will not increase as quickly if it actually has a cost.
But software bloat increases faster than single-thread performance, thus making software run slower.
The average consumer uses an Office product, e-mail, and a browser. None of these use anywhere close to 100% of the CPU for very long even on a Pentium 3, let alone on a 2GHz+ core in a multi-core processor.
Sounds like you haven't tried Vista, Office 2007, and IE7.
It's still mostly true. Going from a 3.0 GHz Conroe to ~3.7 GHz Penryn is only a 30-40% performance increase, but we want a 100% increase. So we can expect that the number of cores and frequency will both increase.
IBM patents everything it can. If IBM doesn't patent something that they create, then another company will, and that company might not be friendly to open source developers. Most newer open source licenses include an explicit grant of patent rights which should eliminate most of these problems.
They don't generate unique decryption keys for each and every player.
...the person who decrypted the data hasn't said "I used player X" since he doesn't want to make it easy for them to revoke the key for "player X".
My interpretation of the spec is that every individual player has unique keys. Software players may be a little more relaxed, though.
It is at least a class of players (in this case we're only dealing with software players as a sibling post has pointed out) and I wouldn't be surprised if they keys were only unique on the manufacturer level (i.e. Sony has one key for all the players it makes).
The software players may have one set of keys for each app, but then it's easy to update software to change out keys. After several such updates, the software player developers may end up implementing individual keys using online activation to reduce the hassle. Either way, the collateral damage would appear to be minimal.
Even if each player did have a unique decryption key though, they would have no way of knowing which key to revoke.
IMO it's only a matter of time until someone releases a DeCSS-style crack with player keys included.
Plenty of people on the Doom9 forums have admitted to using WinDVD 8 Japanse edition. Besides, there are only two software HD-DVD/Blu-ray players anyway, so AACS LA could just revoke both.