For example, just sending the audio to the "Trusted" (i.e. restricted) output devices will work, but "faking" the hardware so as to capture the digital stream to use for Fair Use won't (this is exactly why they're requiring all drivers to be cryptographically signed).
It's not just that. There is all sorts of common and cool things which require access to the raw audio. Wanted to try out that cool new audio visualization plugin? Sorry. A cross-fade plugin? Nope, can't do it. Normalize the volume? That's a no-no now. Because the only way for restricted audio to work is if you make sure that no third-party code ever gets access to the raw audio. They are now basically restricted to writing glorified remotes.
Didn't Microsoft's mantra used to be "Developers! Developers! Developers!"? Not any more apparently. Which I think is great. If MS want's to tell all the small developers to fuck off and go to a different platform, great. That just means all the cool audio apps will be on Linux and OSX in the future.
Re:I don't think many people too Gibson seriously.
on
WMF Flaw not a Backdoor
·
· Score: 2, Insightful
[i]I would have assumed that computers in five years time would be using real-time EPS (that's embeddable PostScript, the initials standing for Encapsulated Post Script, for you young'uns, that's what we were all talking about then as being the future of vector formats)[/i]
And lest everyone forget, the PostScript language includes file operation commands (reading and writing). Which of course could be use for all sorts of nastiness by overwriting various important files (.login,.rhosts, authorized_keys,.Xsession, etc.) It wasn't even all that long ago that support for those commands was removed from ghostscript and it's decendants (xpdf, etc.). But last I checked, nobody has accused Adobe of trying to backdoor all of our computers.
Or a number of standard Unix terminal emulators which have had some pretty iffy functions added to them which can lead to system compromises: TERMINAL EMULATOR SECURITY ISSUES. Has anybody accused Rasterman (or whomever wrote Eterm) of trying to backdoor everybodies computer? Of course not.
What's my point? I don't know. Maybe that, as much fun as it is to kick around Microsoft for dangerous programming choices, they aren't the only ones to design systems and API's that have holes. In hindsight, both the PS and terminal issues I mentioned above are pretty obvious. I mean, slap your forehead obvious that you probably shouldn' do that. But they did.
I can see two ways to try and dig more deeply into this. Wasn't there a big leak of M$ source code a while back? I never bothered to snag a copy, but lots of folks did. There is a small chance that the relevant code was leaked. Somebody who had a copy could check. There are also non-Microsoft folks who have access via NDA. They could also check out the source, and probably leak the relvant code if they wanted to. If this is really an intentional back-door, Microsoft would have everybody so pissed at them they wouldn't really be able to go after the leaker.
Second, disassembly of the relevant binary should also reveal some clues. It would be easy to code a back door like this. It would be a bit trickier to make it look innocent. The easy way to code it would be with an explicit compare for a length of value 1. Something like
if (length == 1) { // Fire off evil thread } else { // Proceed with normal processing }
This would stand out like a sore thumb to anybody taking a close look at the assembly. Various amounts of obfuscation could be added, but in the end the nature of this particular vulnerability sounds like it should be able to get a good feel for whether it's a bug or intentional from looking at the assembly. Hopefully somebody who knows more about Windows than I do will take the time. I'm sure some security researcher will want to make a name for themselves.
That's the question for me. I'd be much more interested in having a laptop which could run Linux and OSX. I know I can use Fink and the OSX X11 server, but I just haven't managed to get that to be as comfortable to me as an Ubuntu install. Both in terms of package management (fink vs. apt) nor in terms of managing screen real estate (OSX looks pretty, but sometimes I just want a bunch of terminal windows and not a bunch of eye candy).
Those URLs are what you get for submitting a story to Slashdot. We selected it. The submission braved the Gauntlet. A hundred submissions died, and this one made the cut. I don't think it's fair that we strip creds from someone just because they choose to squander that URL on something stupid. Who am I to judge that after all?
Pffft. Your submission doesn't even have a URL. Jeez, what kind of self respecting geek doesn't have some sort of web site they can link to these days.
Apache copied (literally) the NCSA web server. Sure, these projects did not copy commercial, closed-source software, but that does not make Perl and Apache paragons of innovation.
Apache may not be a good example. The NCSA web server was basically open source. I don't recall the exact license, but the source was always available. As was the source to NCSA's web browser Mosaic. I'm fairly certain that Tim Berners-Lee original web software was open source as well. So while Apache may have copied from others, I think the web as a whole can certainly be considered to be an example open source innovation.
Part of me thinks e-paper is going to be really cool and will allow us to make some neat gadgets. But at the same time, I'm terrified of what the marketing folks are going to do with it. We are already at a point where advertising pervades our environment everywhere we go. When it all starts flashing and jumping and pointing and demanding our attention at all times I think I'm going to go totally insane. I really think I might just snap and actually go crazy. And I suspect I'm not alone.
And that is why media companies are losing it. Copy protection and usage restrictions are nothing more than hassles for actual paying customers. And every time the content providers, whether it is music, movies, or videogames try to introduce another technological solution to their market problem, they only alienate paying customers. The actual people who are unwilling, uninterested, or unable to pay for the content just go out and get versions without the protection.
Yeah, it just boggles the mind. They go out of their way to ensure that pirated content is superior in every way to purchased content. The pirated stuff is easier to get. It's more flexible and can be played everywhere. It doesn't break my machine. It doesn't disable the controls on my player. It costs less. The only advantage purchased content has is that in theory it's the "right thing to do". But really, with the asshats running the media companies and their lawsuits and lobbying for offensive laws and the way they rape the actual artists, I'm not even sure that giving them money is "the right thing to do".
I found a link to RIAA Radar in a slashdot post a week or two ago. It's pretty cool and gives you a way to find those artists and labels who aren't part of the problem. Or at least not as much as RIAA members are.
I don't think it's that bad. If you want to publish the changed software and have it used by the public over the web, you publish your changes.
But what does that really mean? You can't say "publish" because that is not what's happening. What does "used by the public" mean? If I make a local modification to Apache do I have to publish that modification? What about if I make a change to Sendmail (or some other MTA)? I mean really, the way the public interacts with my web server is logically very much like they interact with my mail server. What about if I make a local change to GCC and distribute the binaries? What if I make a local modification to OpenOffice or Gnumeric and then use those versions to exchange documents with customers? What if I make local modifications to MySQL and use that to keep my customer database in? Where exactly to you draw the line for where software is being "used by the public"?
What this type of change will boil down to is that the GPL taints the output of GPL licensed programs. And I can absolutely guarantee that closed-source vendors will hammer on that point mercilessly. And it's going to be a very hard accusation to counter because it will be accurate. If you want to kill adoption of GPL software, this is a great way to do it. As I said, it's cutting off your nose to spite your face. I don't see any problem with the current license that requires this kind of drastic change.
I understand the sentiment, but I think the community needs to be very, very careful when considering this type of change. Because in many ways it is a massive structural change in the very nature of GPL software. Currently, as a user, I don't really have to worry much about the GPL. It doesn't really impose anything at all for most people. And even though technically I have to accept the GPL to modify the code, that's currently trivial if I don't distribute the code.
But if the GPL is changed so that somehow modification without distribution is restricted then suddenly I have a whole new host of worries with GPL software. I think this is basically cutting off your nose to spite your face. I don't think anybody can actually point to a real example of the problem this solution is trying to solve. But I can guarantee that adding this type of restriction is going to be seen as a big negative for companies wanting to deploy GPL software. Note I'm not talking about companies who want to distribute the software, but those that just want to use it.
You are only talking about compatability of older software on newer OS versions. Linux supports this, as does Windows, and pretty much every major OS in existence. But this study was trying to get compatability in the other direction. They were trying to run something which required a new GLIBC under an old OS. This would be like trying to run a binary compiled for Solaris 8 under Solaris 7. You might be able to make it work, but depending on the application it might be quite difficult. And it would certainly not be supported by Sun.
As others have pointed out, the root problem was a GLIBC incompatability with a closed-source binary-only application which was one of the requirements. For unknown reasons, upgrading to SLES9 was ruled out. As was running the closed-source application on a separate server. As was choosing a compatable product instead of the incompatable one. Moreover, the selection of the "requirement" applications was made solely on "market share" with no consideration as to the actual compatability with existing IT infrastructure. Basically, a series of poor techincal decisions which no competent IT organization would make. The only valid conclusion you can draw from this study is that choosing applications based on market share alone with no thought as to technical considerations can lead to unfavorable outcomes. Is that enough of a refutation for you?
Many 3rd party commercial vendors only provide the binary RPMs and that was the case here too. Again, let me say that we chose components based on market share without knowing that these issues would crop up.
Let's be honest here. You should have known that those issues might crop up. Binary incompatability is a well known problem with closed-source software, and not just on Linux. It's one of the major advantages of open-source software over closed-source. Having the source means I can rebuild the software for my system to avoid exactly this issue. Or more commonly, my distro can rebuild the software and provide me with an easy to use and fully compatable binary package.
Any project which goes out and chooses what software to use exclusively based on "market share" deserves any problems they run into. That should be the conclusion of your study. When I go looking for applications to use, compatability is primary consideration. Having a maintained version included in my distro of choice (Debian for me) is a huge plus. If I do have to use closed-source, putting it into it's own isolated OS will probably end up a requirement as well since that's the easiest and most direct way of avoiding binary compatability issues.
To compare Windows and Linux by forcing one of the biggest weaknesses of closed-source software onto the open-source solution is quite disingenous I think. It may be that the closed-source software is well and truely required and has no open-source competetor. But you never actually name the software, so no one can come along and say "hey, why not use GNU Mailman to handle the mailing" for example. Both mailing lists and search have many many open source options. Data mining has perhaps not so many, but in all liklihood that application can run on an indepenent server and connect to MySQL over the network. That would eliminate all the GBLIC problems.
Really, not to sound snide, but the strongest conclusion I can make from this study is that I should not hire you to design my IT infrastructure. I can't say if it was ignorace or malice, but it sounds like you pretty much set the Linux side up for failure.
If the OS is looking for a returned value that matches a checksum, is it that easy to trap and emulate an encrypted value that matches the checksum?
You just take the entire check out. Or you change it so that the value it wants is all zeros instead of the checksum. Or change the check so that it succeeds if the values don't match. You act like the OS is some static thing. It isn't. You don't try to imitate a valid TPM chip. You modify the OS itself so it never bothers checking. Much, much easier.
Perhaps you can hack the OS so that it doesn't look for that value in hardware, but if Apple can do a reasonably good job of burying that check in the kernel and having the TPM verify the kernel's boot process itself, you won't be able to do that either.
Actually, it will be trivial to pull the check out. The underground community has literally decades of experience removing that stuff. The hardware isn't going to do anything to prevent a cracked version of MacOS from running. After all, we aren't even talking about Apple hardware, remember? All it's going to take is running the OS in an emulator and having it break every time it tries to access the TPM chip. Look at what it's doing, and what it wants for a value, and replace whatever part is easiest. No need to crack any crypto or anything.
What Apple will be able to do if they like is detect such a hacked OS if it tries to connect to their Update Server. That's exactly the type of thing remote attestation is for. But they won't be able to keep people from modifying the OS to run on commodity PC hardware.
I know you can disable auto-run and such to get around this type of crap. But what happens if you just 'disagree' or whatever on the EULA? I assume that Sony will then not install the rootkit and you can rip the CD with whatever tool you normally use? Or does Sony install the rootkit anyway, setting themselves up for criminal prosecution? Does anybody have a copy of this thing to try and answer that question?
It just seems kind of silly to have DRM which is totally dependant on the user to request it be installed. Or can refusing an EULA be considered a violation of the DMCA?
This is easier said than done. There already are easy to use installation systems which require only a few clicks. Apt with the Synaptic front end certainly meets this requirement. But how do you get rid of the installers (or lack therof) on other distro's? That's what you are really asking for. Not for an easy to use installer, but for the other ones to go away. How do you get rid of Gentoo and Slackware? Or the BSD ports? Or Fink? In many respects, the package management defines the distribution. That's certainly the case with Gentoo. So should Gentoo just close shop? What we need is for Joe Sixpack to know that if he wants to try Linux he should use Ubuntu (or Linspire, or FC, or whatever) and should not try to use Slackware, or Gentoo, or whatever.
All EULA software can share the blame
on
PCs Posted No Trespass
·
· Score: 1, Interesting
I think all software which includes an EULA can share in the blame. The EULAs offer little to no benefit to the legitimate companies which use them. They offer no benefit to the users of the software. But they offer legal cover for the spyware / adware folks. By training all the users of commercial software that click through EULA's are just a normal and expected thing, it helps ensure that it's easy for the slime to slide through nasty stuff in them.
It's one of the things that makes me appreciate free software. So much commercial software is total crap, yet you have to jump through all these hoops to use it. Like it's such a fricken privledge. Buy the software. Click through some obnoxious 'license'. Fill out the 'registration' form. Wait for it to phone home. If you are really lucky, install a "license server" just to prove you aren't a crook. And in the end, struggle with some bloated and buggy piece of crap. With proprietary file formats to ensure that you don't really control your own data. Commercial software houses don't treat their customers like customers. They treat them like serfs.
But also consider that a fiberless link can get (or is, in the case of WiFi) ridiculously cheap compared to a fiber. And with FSO, anyone that sees any other one can form a link. Two cheap devices (with the proper economy of scale) on each end, ready. With fiber, you have do invest a lot in digging up the streets, the fibers itself etc.
Sure, I agree with that. I don't think I ever said a good fiber backbone is cheaper than some sort of mesh using wireless and FSO. Or even in the same ballpark for cost. I can go 10 miles across town with gige LX on fiber optic for just a few hundred buck on either end. Oh, and after spending a half a million dollars trenching fiber.;-)> But my original point was that it isn't feasable to replace current fiber backbones with wireless (or FSO) and expect to get anywhere near the performance.
Well, then let's use free space optical wireless mesh networks. Practically no interference, no broad antenna beams etc.
The Ronja looks like a neat piece of equipment. But it's still running at 1/1000 the speed of a real high speed fiber link. As I said, mesh networking is cool, and you can do some neat things with it. But perform the same as a high speed fiber backbone isn't one of them. You never even really addressed my main points. Having a lot of hops increases latency, wireless or not. Complicated and overly dynamic routing will result in lost packets. Multiplexing traffic over multiple links will cause out of order packets. Replacing 11Mbps 802.11b gear with 10Mbps Ronja gear doesn't change the fundamental problem. Physics favors fiber optic cables over free space optics for all the same reasons it favors cables over wireless except one (FSO and fiber optic run at the same frequencies). Fiber optic cables will still have less noise, less loss and the ability to put a bunch of them into a conduit to increase capacity.
It is possible on a mesh network to route sequential packets via different routes, as long as your router is powerful enough to keep up with huge routing tables that may change frequently.
Are you going to get a thousand paths? Not likely. Each one of those hops is going to introduce latency as well, which hampers TCP performance. Lots of changes in the routing table? If the topology is too dynamic you're going to lose packets in the various transient loops and dead-ends that occur. And your packets are going to be effectively shuffled when they get to their final destination, greating increasing the load that needs to be done on the TCP stream to put it back together. End result? Poor TCP performance. A working mesh network is an engineering problem. A mesh network with performance comparable to a well engineered high speed fiber backbone? Fantasty.
I know there's been talk of wireless mesh networks where everybody is both an end point and a router. This would work in populated areas but I'm not sure how well it would work for "long haul" connections which is what the issue is here.
If by "work in populated areas" you mean "slow the network to a crawl" then yes, it would work. Mesh networking is cool stuff, but you aren't going to build a backbone out of it. Wireless is really fast compared to your DSL line or cable modem. But it isn't even in the same ballpark as what you can do on fiber. Backbone links are running at 10Gbps or even 40Gbps. Full duplex, so that is 20Gbps or 80Gbps of "marketing bandwidth". Compared to what, 22Mbps or 54Mbps half-duplex for your wireless? You aren't going to build a comparable backbone out of wireless links running at roughly 1/1000th of the speed. Physics pretty much guarantees that fiber links will always be faster than wireless.
Level 3 would be getting Cogents route through somebody. It's pretty much inconceivable that Cogent could somehow advertise it's route so selectively as to allow everyone but Level 3 to get it. BGP does a pretty good job of getting routes everywhere, even if by a poor or long path. For Level 3 to not have a Cogent route at all would require either a) cogent to be entirely offline or b) L3 to filter it out. Since I know a) is false due to receiving the Cogent route through our two other providers, that leaves only b).
Slashdot Mirror
For example, just sending the audio to the "Trusted" (i.e. restricted) output devices will work, but "faking" the hardware so as to capture the digital stream to use for Fair Use won't (this is exactly why they're requiring all drivers to be cryptographically signed).
It's not just that. There is all sorts of common and cool things which require access to the raw audio. Wanted to try out that cool new audio visualization plugin? Sorry. A cross-fade plugin? Nope, can't do it. Normalize the volume? That's a no-no now. Because the only way for restricted audio to work is if you make sure that no third-party code ever gets access to the raw audio. They are now basically restricted to writing glorified remotes.
Didn't Microsoft's mantra used to be "Developers! Developers! Developers!"? Not any more apparently. Which I think is great. If MS want's to tell all the small developers to fuck off and go to a different platform, great. That just means all the cool audio apps will be on Linux and OSX in the future.
[i]I would have assumed that computers in five years time would be using real-time EPS (that's embeddable PostScript, the initials standing for Encapsulated Post Script, for you young'uns, that's what we were all talking about then as being the future of vector formats)[/i]
.rhosts, authorized_keys, .Xsession, etc.) It wasn't even all that long ago that support for those commands was removed from ghostscript and it's decendants (xpdf, etc.). But last I checked, nobody has accused Adobe of trying to backdoor all of our computers.
And lest everyone forget, the PostScript language includes file operation commands (reading and writing). Which of course could be use for all sorts of nastiness by overwriting various important files (.login,
Or a number of standard Unix terminal emulators which have had some pretty iffy functions added to them which can lead to system compromises: TERMINAL EMULATOR SECURITY ISSUES. Has anybody accused Rasterman (or whomever wrote Eterm) of trying to backdoor everybodies computer? Of course not.
What's my point? I don't know. Maybe that, as much fun as it is to kick around Microsoft for dangerous programming choices, they aren't the only ones to design systems and API's that have holes. In hindsight, both the PS and terminal issues I mentioned above are pretty obvious. I mean, slap your forehead obvious that you probably shouldn' do that. But they did.
The meetings will continue until we discover why no work is getting done around here! Am I clear!
-The Boss
That's the question for me. I'd be much more interested in having a laptop which could run Linux and OSX. I know I can use Fink and the OSX X11 server, but I just haven't managed to get that to be as comfortable to me as an Ubuntu install. Both in terms of package management (fink vs. apt) nor in terms of managing screen real estate (OSX looks pretty, but sometimes I just want a bunch of terminal windows and not a bunch of eye candy).
Those URLs are what you get for submitting a story to Slashdot. We selected it. The submission braved the Gauntlet. A hundred submissions died, and this one made the cut. I don't think it's fair that we strip creds from someone just because they choose to squander that URL on something stupid. Who am I to judge that after all?
Pffft. Your submission doesn't even have a URL. Jeez, what kind of self respecting geek doesn't have some sort of web site they can link to these days.
Apache copied (literally) the NCSA web server. Sure, these projects did not copy commercial, closed-source software, but that does not make Perl and Apache paragons of innovation.
Apache may not be a good example. The NCSA web server was basically open source. I don't recall the exact license, but the source was always available. As was the source to NCSA's web browser Mosaic. I'm fairly certain that Tim Berners-Lee original web software was open source as well. So while Apache may have copied from others, I think the web as a whole can certainly be considered to be an example open source innovation.
Part of me thinks e-paper is going to be really cool and will allow us to make some neat gadgets. But at the same time, I'm terrified of what the marketing folks are going to do with it. We are already at a point where advertising pervades our environment everywhere we go. When it all starts flashing and jumping and pointing and demanding our attention at all times I think I'm going to go totally insane. I really think I might just snap and actually go crazy. And I suspect I'm not alone.
first post
And that is why media companies are losing it. Copy protection and usage restrictions are nothing more than hassles for actual paying customers. And every time the content providers, whether it is music, movies, or videogames try to introduce another technological solution to their market problem, they only alienate paying customers. The actual people who are unwilling, uninterested, or unable to pay for the content just go out and get versions without the protection.
Yeah, it just boggles the mind. They go out of their way to ensure that pirated content is superior in every way to purchased content. The pirated stuff is easier to get. It's more flexible and can be played everywhere. It doesn't break my machine. It doesn't disable the controls on my player. It costs less. The only advantage purchased content has is that in theory it's the "right thing to do". But really, with the asshats running the media companies and their lawsuits and lobbying for offensive laws and the way they rape the actual artists, I'm not even sure that giving them money is "the right thing to do".
I found a link to RIAA Radar in a slashdot post a week or two ago. It's pretty cool and gives you a way to find those artists and labels who aren't part of the problem. Or at least not as much as RIAA members are.
I don't think it's that bad. If you want to publish the changed software and have it used by the public over the web, you publish your changes.
But what does that really mean? You can't say "publish" because that is not what's happening. What does "used by the public" mean? If I make a local modification to Apache do I have to publish that modification? What about if I make a change to Sendmail (or some other MTA)? I mean really, the way the public interacts with my web server is logically very much like they interact with my mail server. What about if I make a local change to GCC and distribute the binaries? What if I make a local modification to OpenOffice or Gnumeric and then use those versions to exchange documents with customers? What if I make local modifications to MySQL and use that to keep my customer database in? Where exactly to you draw the line for where software is being "used by the public"?
What this type of change will boil down to is that the GPL taints the output of GPL licensed programs. And I can absolutely guarantee that closed-source vendors will hammer on that point mercilessly. And it's going to be a very hard accusation to counter because it will be accurate. If you want to kill adoption of GPL software, this is a great way to do it. As I said, it's cutting off your nose to spite your face. I don't see any problem with the current license that requires this kind of drastic change.
I understand the sentiment, but I think the community needs to be very, very careful when considering this type of change. Because in many ways it is a massive structural change in the very nature of GPL software. Currently, as a user, I don't really have to worry much about the GPL. It doesn't really impose anything at all for most people. And even though technically I have to accept the GPL to modify the code, that's currently trivial if I don't distribute the code.
But if the GPL is changed so that somehow modification without distribution is restricted then suddenly I have a whole new host of worries with GPL software. I think this is basically cutting off your nose to spite your face. I don't think anybody can actually point to a real example of the problem this solution is trying to solve. But I can guarantee that adding this type of restriction is going to be seen as a big negative for companies wanting to deploy GPL software. Note I'm not talking about companies who want to distribute the software, but those that just want to use it.
You are only talking about compatability of older software on newer OS versions. Linux supports this, as does Windows, and pretty much every major OS in existence. But this study was trying to get compatability in the other direction. They were trying to run something which required a new GLIBC under an old OS. This would be like trying to run a binary compiled for Solaris 8 under Solaris 7. You might be able to make it work, but depending on the application it might be quite difficult. And it would certainly not be supported by Sun.
As others have pointed out, the root problem was a GLIBC incompatability with a closed-source binary-only application which was one of the requirements. For unknown reasons, upgrading to SLES9 was ruled out. As was running the closed-source application on a separate server. As was choosing a compatable product instead of the incompatable one. Moreover, the selection of the "requirement" applications was made solely on "market share" with no consideration as to the actual compatability with existing IT infrastructure. Basically, a series of poor techincal decisions which no competent IT organization would make. The only valid conclusion you can draw from this study is that choosing applications based on market share alone with no thought as to technical considerations can lead to unfavorable outcomes. Is that enough of a refutation for you?
Many 3rd party commercial vendors only provide the binary RPMs and that was the case here too. Again, let me say that we chose components based on market share without knowing that these issues would crop up.
Let's be honest here. You should have known that those issues might crop up. Binary incompatability is a well known problem with closed-source software, and not just on Linux. It's one of the major advantages of open-source software over closed-source. Having the source means I can rebuild the software for my system to avoid exactly this issue. Or more commonly, my distro can rebuild the software and provide me with an easy to use and fully compatable binary package.
Any project which goes out and chooses what software to use exclusively based on "market share" deserves any problems they run into. That should be the conclusion of your study. When I go looking for applications to use, compatability is primary consideration. Having a maintained version included in my distro of choice (Debian for me) is a huge plus. If I do have to use closed-source, putting it into it's own isolated OS will probably end up a requirement as well since that's the easiest and most direct way of avoiding binary compatability issues.
To compare Windows and Linux by forcing one of the biggest weaknesses of closed-source software onto the open-source solution is quite disingenous I think. It may be that the closed-source software is well and truely required and has no open-source competetor. But you never actually name the software, so no one can come along and say "hey, why not use GNU Mailman to handle the mailing" for example. Both mailing lists and search have many many open source options. Data mining has perhaps not so many, but in all liklihood that application can run on an indepenent server and connect to MySQL over the network. That would eliminate all the GBLIC problems.
Really, not to sound snide, but the strongest conclusion I can make from this study is that I should not hire you to design my IT infrastructure. I can't say if it was ignorace or malice, but it sounds like you pretty much set the Linux side up for failure.
If the OS is looking for a returned value that matches a checksum, is it that easy to trap and emulate an encrypted value that matches the checksum?
You just take the entire check out. Or you change it so that the value it wants is all zeros instead of the checksum. Or change the check so that it succeeds if the values don't match. You act like the OS is some static thing. It isn't. You don't try to imitate a valid TPM chip. You modify the OS itself so it never bothers checking. Much, much easier.
Perhaps you can hack the OS so that it doesn't look for that value in hardware, but if Apple can do a reasonably good job of burying that check in the kernel and having the TPM verify the kernel's boot process itself, you won't be able to do that either.
Actually, it will be trivial to pull the check out. The underground community has literally decades of experience removing that stuff. The hardware isn't going to do anything to prevent a cracked version of MacOS from running. After all, we aren't even talking about Apple hardware, remember? All it's going to take is running the OS in an emulator and having it break every time it tries to access the TPM chip. Look at what it's doing, and what it wants for a value, and replace whatever part is easiest. No need to crack any crypto or anything.
What Apple will be able to do if they like is detect such a hacked OS if it tries to connect to their Update Server. That's exactly the type of thing remote attestation is for. But they won't be able to keep people from modifying the OS to run on commodity PC hardware.
I know you can disable auto-run and such to get around this type of crap. But what happens if you just 'disagree' or whatever on the EULA? I assume that Sony will then not install the rootkit and you can rip the CD with whatever tool you normally use? Or does Sony install the rootkit anyway, setting themselves up for criminal prosecution? Does anybody have a copy of this thing to try and answer that question?
It just seems kind of silly to have DRM which is totally dependant on the user to request it be installed. Or can refusing an EULA be considered a violation of the DMCA?
This is easier said than done. There already are easy to use installation systems which require only a few clicks. Apt with the Synaptic front end certainly meets this requirement. But how do you get rid of the installers (or lack therof) on other distro's? That's what you are really asking for. Not for an easy to use installer, but for the other ones to go away. How do you get rid of Gentoo and Slackware? Or the BSD ports? Or Fink? In many respects, the package management defines the distribution. That's certainly the case with Gentoo. So should Gentoo just close shop? What we need is for Joe Sixpack to know that if he wants to try Linux he should use Ubuntu (or Linspire, or FC, or whatever) and should not try to use Slackware, or Gentoo, or whatever.
I think all software which includes an EULA can share in the blame. The EULAs offer little to no benefit to the legitimate companies which use them. They offer no benefit to the users of the software. But they offer legal cover for the spyware / adware folks. By training all the users of commercial software that click through EULA's are just a normal and expected thing, it helps ensure that it's easy for the slime to slide through nasty stuff in them.
It's one of the things that makes me appreciate free software. So much commercial software is total crap, yet you have to jump through all these hoops to use it. Like it's such a fricken privledge. Buy the software. Click through some obnoxious 'license'. Fill out the 'registration' form. Wait for it to phone home. If you are really lucky, install a "license server" just to prove you aren't a crook. And in the end, struggle with some bloated and buggy piece of crap. With proprietary file formats to ensure that you don't really control your own data. Commercial software houses don't treat their customers like customers. They treat them like serfs.
But also consider that a fiberless link can get (or is, in the case of WiFi) ridiculously cheap compared to a fiber. And with FSO, anyone that sees any other one can form a link. Two cheap devices (with the proper economy of scale) on each end, ready.
;-)> But my original point was that it isn't feasable to replace current fiber backbones with wireless (or FSO) and expect to get anywhere near the performance.
With fiber, you have do invest a lot in digging up the streets, the fibers itself etc.
Sure, I agree with that. I don't think I ever said a good fiber backbone is cheaper than some sort of mesh using wireless and FSO. Or even in the same ballpark for cost. I can go 10 miles across town with gige LX on fiber optic for just a few hundred buck on either end. Oh, and after spending a half a million dollars trenching fiber.
Well, then let's use free space optical wireless mesh networks. Practically no interference, no broad antenna beams etc.
The Ronja looks like a neat piece of equipment. But it's still running at 1/1000 the speed of a real high speed fiber link. As I said, mesh networking is cool, and you can do some neat things with it. But perform the same as a high speed fiber backbone isn't one of them. You never even really addressed my main points. Having a lot of hops increases latency, wireless or not. Complicated and overly dynamic routing will result in lost packets. Multiplexing traffic over multiple links will cause out of order packets. Replacing 11Mbps 802.11b gear with 10Mbps Ronja gear doesn't change the fundamental problem. Physics favors fiber optic cables over free space optics for all the same reasons it favors cables over wireless except one (FSO and fiber optic run at the same frequencies). Fiber optic cables will still have less noise, less loss and the ability to put a bunch of them into a conduit to increase capacity.
It is possible on a mesh network to route sequential packets via different routes, as long as your router is powerful enough to keep up with huge routing tables that may change frequently.
Are you going to get a thousand paths? Not likely. Each one of those hops is going to introduce latency as well, which hampers TCP performance. Lots of changes in the routing table? If the topology is too dynamic you're going to lose packets in the various transient loops and dead-ends that occur. And your packets are going to be effectively shuffled when they get to their final destination, greating increasing the load that needs to be done on the TCP stream to put it back together. End result? Poor TCP performance. A working mesh network is an engineering problem. A mesh network with performance comparable to a well engineered high speed fiber backbone? Fantasty.
I know there's been talk of wireless mesh networks where everybody is both an end point and a router. This would work in populated areas but I'm not sure how well it would work for "long haul" connections which is what the issue is here.
If by "work in populated areas" you mean "slow the network to a crawl" then yes, it would work. Mesh networking is cool stuff, but you aren't going to build a backbone out of it. Wireless is really fast compared to your DSL line or cable modem. But it isn't even in the same ballpark as what you can do on fiber. Backbone links are running at 10Gbps or even 40Gbps. Full duplex, so that is 20Gbps or 80Gbps of "marketing bandwidth". Compared to what, 22Mbps or 54Mbps half-duplex for your wireless? You aren't going to build a comparable backbone out of wireless links running at roughly 1/1000th of the speed. Physics pretty much guarantees that fiber links will always be faster than wireless.
Level 3 would be getting Cogents route through somebody. It's pretty much inconceivable that Cogent could somehow advertise it's route so selectively as to allow everyone but Level 3 to get it. BGP does a pretty good job of getting routes everywhere, even if by a poor or long path. For Level 3 to not have a Cogent route at all would require either a) cogent to be entirely offline or b) L3 to filter it out. Since I know a) is false due to receiving the Cogent route through our two other providers, that leaves only b).