If it's the TPM chip they're talking about (likely) then it'll work with any OS : the specification is open and there are Linux drivers in the kernel already.
There is no useful purpose for a technology designed to "protect" a machine from its owner.
Online gamers who suffer from cheaters would disagree. Movie producers who have a $10 million film to finance and want to make it available for download would also disagree.
People are so paranoid about TCPA, it's funny. Hello people, go read the specs like I did. You'll come away with a different impression.
The TPM chip is a tool just like encryption is. Like encryption it can be used for both bad and good. Just like PGP can protect criminal communication as easily as it protects commerce, the TPM can be used in many ways.
Let's clear up a few misconceptions:
No, the TPM cannot stop you booting Debian. That's a dumb idea based on zero knowledge of what the technology does.
Yes, it can stop you accessing certain content if you are running Debian, because the TPM prevents you from lying about the configuration of your computer.
If the content provider (online music store or whatever) doesn't want you use Linux to access their content, tough cookies. But this already happens today: there are no DRM implementations for Linux and the only way to play back music bought from iTMS is to either run iTunes under Wine or strip the encryption. And that's only possible because FairPlay is not a terribly good implementation of DRM - try playing back music bought from the Yahoo! Music Store, which uses Windows Media and you'll find you can't.
Obviously, this "remote attestation" feature has the potential to be abused! For instance, Microsoft could (theoretically) lock non-Windows users out from microsoft.com.... but the behaviour may not be legal, and the law has the final say in what the technology can be used for.
And equally obviously, remote attestation has legitimate uses as well: it can be used to do more robust anti-cheating programs like the Warden that protects WoW, and it can be used to prove to a remote computer that you are rootkit clean which would be useful for detecting spyware at the university/corporate network level.
It's not particularly obvious, but * * Beatles Beatles keeps submitting (legitimate) stories where his username links to random websites that apparently have nothing to do with him or the story. The domains in question are pretty clearly designed to spam Google by leveraging the enormous PageRank that Slashdot has.
The domains are all registered to the same guy, Carl Fogle, who like all search engine spammers is a premier-league asshole who was apparently never taught that enlightened self interest is supposed to make the world a better place for everybody, not be an excuse for screwing over friends and neighbours who rely on a shared resource.
Haha, I like that, the presenter goes off on a tangent about her own page claiming it makes her look like a "right wing commie". WTF? Not only is that mostly irrelevant, but the actual page says
She has been accused by liberals of showing a right-wing bias, particularly by the organization Media Matters for America. [2] In one instance, Nancy Pelosi accused her of asserting the position of the Bush administration during an interview with Pelosi following Hurricane Katrina.
I fail to see how this information is not interesting or relevant. What, she expects everything published about her on the web to be shiny pearls of marketing-filtered lovelyness? Some people say she's biased and have called her on it - big deal. She was free to add something to the discussion page explaining her take, or even better, publish a webpage somewhere rebutting the accusations and then linking to it. Instead she chooses to bitch on live TV - classy.
You're assuming there's no complexity difference between 1 dependency and 100 - but this defies common sense and actual experience. If the "complete solution" were so great, how comes there are so many articles and posts from people wishing for MacOS type software management on Linux?
Right, and what exactly is autopackage going to do about these dependencies once it has found that they don't match up?
If a required dependency can't be found the install fails, same as with a source tarball. It's the developers job to ensure their dependencies are reasonable and widespread: projects like AbiWord or Inkscape haven't had an issue with doing this. There are various techniques you can use like static linking obscure/rare/unstable libraries or using relaytool/dlopen to access features which might not be present.
Of course, all of that isn't to say that autopackage may not do something useful in the future, but it sure looks like some of the fundamental problems of developing and distributing packages which other packaging systems have already dealt with still remain to be solved.
I would disagree that they've solved anything, all they did was add a massive amount of complexity to try and wallpaper over the underlying chaos. Systems like Debian don't solve the actual problem "there is no platform", they just bandaid the symptoms and you end up with weird artifacts of this approach like out of date packages, version freezes, broken packages, painful library transitions and so on. All of these things are stop-problems for end users.
It clearly isn't, as Windows and MacOS X - in fact, every commercial OS ever made - did not require the central repository scheme. They use things called "platforms" and we've been saying for a long time that Linux should have one.
Until then, autopackages - which are basically the binary equivalent of source tarballs with extra features - are the next best thing for end users who just want to click in a web page and get what they expect (as opposed to some randomly patched, out of date, potentially broken package uploaded by Mr. J Random)
This particular hack takes advantage of the fact that a person with Google Desktop installed will send a special cookie when they request most pages from Google. That cookie will cause a "desktop" link to be sent back to them somewhere on the page. This desktop link contains a secret password.
That's not how it works. Go back and read the article again, they use a browser plugin to rewrite the web page as it's downloaded - probably a BHO.
I think the rationale behind the project has been explained clearly enough time and time again. What's more, often it's end users asking for this distro support, not us. Shouldn't what end users want be a pretty big hint?
Huh? Programs that use epoll can either use relaytool, direct dlsym or embed the syscalls directly (as Wine does). This is a non-issue, why is it even being debated? Programs don't grow dependencies by magic, developers add them, and it's up to the developers to decide what the minimum requirements are of their app. The lower they are, the larger their userbase can potentially be.
Yeah exactly. John is totally shooting the messenger here. Assuming this isn't a case of a well meaning but misinformed person adding "facts", he seems to be avoiding the actual cause of his woe, which is that somebody somewhere must really hate his guts to imply he's a murderer.
This dude isn't Bush, Hitler or God, he's just some old man. I know I never heard of him, maybe he's well known in the USA, but the world is full of old men who used to be famous. Not every article about such men on Wikipedia contains such inflammatory accusations. Somebody had to put them there - the question is, why?
I suspect, given the attitude displayed in the article, that he's annoyed a lot of people in the past. One of them found wikipedia and presumably couldn't help themselves...
There's work under way to replace the Linux standalone installer with autopackage for Firefox 2. Only time will tell if that works is completed or not, but it has the support of Mozillians.
Even statically linked binaries have stopped working before due to linker, toolchain and kernel changes. And like I said, statically linking glibc itself is very dangerous. If you get it wrong DNS lookups will crash, and various other things will break in obscure ways.
You can still "leak" in Java, for instance by forgetting to null object references that then keep a huge section of the heap graph lying around without realising it. Common ways to do that include not disconnecting event listeners, and having an object provided by a library refer to one of your objects, not realising that the library object is being tracked in some global variable somewhere.
You really can't LD_PRELOAD glibc with any degree of confidence, it's not like other libraries. In fact I'd be amazed if you can even build glibc from the sources yourself, its build system is notiorusly arcane and undocumented - often requiring CVS builds of binutils/gcc, at some points it's even required custom patches not available to the public.
And I'm afraid static linking doesn't solve the problem either. You can't statically link everything, the NSS doesn't like it and will crash, and if you statically link libraries but not glibc you get the same problem.
Believe me. I've looked at this problem in depth. The best way to fix it is to build on the oldest version of the distro you want to support or to use apbuild. Neither of these are obvious solutions, and it's entirely the fault of the glibc designers.
Go read up on the versioning scheme glibc uses - it's unique and defies both logic and common sense.
Basically, and this is coming from somebody who has a lot of experience of dealing with binary software on Linux:
Yes, it's entirely believable that a glibc upgrade was required, because when you compile a program that binary is usually locked to the version of glibc it was compiled with. Newer versions are OK, older versions aren't.
This locking process is automatic and independent of what the source code actually does. Most of the time the developer isn't even aware it's happened.
RPM understands it and will refuse to let you install a binary that requires a newer glibc, even though recompiling the software would allow it to be installed on your existing system just fine.
There is typically zero benefit to be had from this scheme, it's a badly thought out backwards compatibility system, and systems designed explicitly with binary distribution in mind like autopackage work around it automatically.
We can blame the admins, or the people who set the conditions of the test, or whatever, but the real problem is that Linux is crap at handling binaries. It requires an extremely precise knowledge of a million things that don't actually matter.
Whether it's supported by Sun or not is mostly irrelevant, Windows does allow for this sort of thing. Binary compatibility certainly isn't an issue which mostly affects closed source software, the exact opposite is true, binary compatibility problems are worst in an open source system like Linux (because developers have dumb attitudes towards binaries).
Uh, you're assuming admins understand the baroque and unique API versioning system glibc uses, in which a binary can require a new version of glibc yet also somehow not require it when rebuilt from the sources.
This system is incredibly unintuitive, extremely silly and I am not surprised that admins do not understand it given that most Linux users don't either.
Not really. If Google News was crap, nobody would use it, "beta" or not. I am totally not convinced slapping a word on your logo makes people more accepting of rubbish.
I really don't know why GN is still labelled as beta given that it's not particularly buggy, probably they just forgot to remove it?
Theoretically, it's technically possible yes. In practice, it is unsafe - a crashed thread could have done quite literally anything before triggering the exception. For instance, it may have trashed the heap arena. So, swallowing the crash in one place would just cause another one somewhere else.
Now, you could run the plugin in a new thread AND a new heap. But then you may as well use a totally different process, the code involved would be mostly the same. And *that* is quite a complex undertaking, not worth the overhead when it's better to just fix the crashes.
Re:Masters of understatement
on
GCC 4.1 Released
·
· Score: 2, Interesting
No, IIRC this is called Mudflap and generates calls to special glibc APIs which check buffer sizes for calls like read(). It's another layer of security added into Linux lately: on top of exec-shield and SELinux things are feeling pretty secure round here... too bad not every distro has these things (basically on Red Hat distros have them all).
That said, on operating systems like OS X or Linux where the user is prompted for their password to make routine configuration changes, password fatigue is a common issue. I'm sure many people would enter it regardless ("oh jeez, another damn password prompt? go away....").
Also, for what it's worth OS X is hardly the pinnacle of security. There have been enough scary instant-code-execution problems in Safari (one within days of 10.4 being released) that I see no reason to believe Apple are more competent than Microsoft when it comes to security.
1) A lot of the work involved in maintaining a driver is keeping up with in-kernel API changes.
Right, so if the kernel API changed less often, there'd be less work involved. The Windows kernel API changes too you know, but as it only releases every few years, there's less work involved.
2) If you can't see the code for the module, you don't know what the module did.
This is no different to Windows programs running on Wine. You can use tracing, debuggers and disassembly to figure it out, but the easier approach is simply to say "boot without the module loaded. Does it fix it? If so, not our problem". Obviously you can't do that in Wine...
3) Getting the end-user to build and install a kernel module is not hard.
Yes, it is. You need packages which are usually not installed by default - gotta know that. You need the right compiler installed - got to know that. The compile may fail if your kernels API has changed - what do you do then? It can be extremely slow - it's not on Windows.
Asking end users to compile software is a nasty disease Linux is afflicted with, and it really has poor usability compared to a 5-second binary install that is guaranteed to work.
Uh, have you ever tried to debug or reverse engineer a BINARY program? If so then you'd actually understand what I'm talking about, which apparently you don't.
Slashdot Mirror
If it's the TPM chip they're talking about (likely) then it'll work with any OS : the specification is open and there are Linux drivers in the kernel already.
Online gamers who suffer from cheaters would disagree. Movie producers who have a $10 million film to finance and want to make it available for download would also disagree.
People are so paranoid about TCPA, it's funny. Hello people, go read the specs like I did. You'll come away with a different impression.
The TPM chip is a tool just like encryption is. Like encryption it can be used for both bad and good. Just like PGP can protect criminal communication as easily as it protects commerce, the TPM can be used in many ways.
Let's clear up a few misconceptions:
- No, the TPM cannot stop you booting Debian. That's a dumb idea based on zero knowledge of what the technology does.
- Yes, it can stop you accessing certain content if you are running Debian, because the TPM prevents you from lying about the configuration of your computer.
Obviously, this "remote attestation" feature has the potential to be abused! For instance, Microsoft could (theoretically) lock non-Windows users out from microsoft.comIf the content provider (online music store or whatever) doesn't want you use Linux to access their content, tough cookies. But this already happens today: there are no DRM implementations for Linux and the only way to play back music bought from iTMS is to either run iTunes under Wine or strip the encryption. And that's only possible because FairPlay is not a terribly good implementation of DRM - try playing back music bought from the Yahoo! Music Store, which uses Windows Media and you'll find you can't.
And equally obviously, remote attestation has legitimate uses as well: it can be used to do more robust anti-cheating programs like the Warden that protects WoW, and it can be used to prove to a remote computer that you are rootkit clean which would be useful for detecting spyware at the university/corporate network level.
The domains are all registered to the same guy, Carl Fogle, who like all search engine spammers is a premier-league asshole who was apparently never taught that enlightened self interest is supposed to make the world a better place for everybody, not be an excuse for screwing over friends and neighbours who rely on a shared resource.
I fail to see how this information is not interesting or relevant. What, she expects everything published about her on the web to be shiny pearls of marketing-filtered lovelyness? Some people say she's biased and have called her on it - big deal. She was free to add something to the discussion page explaining her take, or even better, publish a webpage somewhere rebutting the accusations and then linking to it. Instead she chooses to bitch on live TV - classy.
You're assuming there's no complexity difference between 1 dependency and 100 - but this defies common sense and actual experience. If the "complete solution" were so great, how comes there are so many articles and posts from people wishing for MacOS type software management on Linux?
If a required dependency can't be found the install fails, same as with a source tarball. It's the developers job to ensure their dependencies are reasonable and widespread: projects like AbiWord or Inkscape haven't had an issue with doing this. There are various techniques you can use like static linking obscure/rare/unstable libraries or using relaytool/dlopen to access features which might not be present.
I would disagree that they've solved anything, all they did was add a massive amount of complexity to try and wallpaper over the underlying chaos. Systems like Debian don't solve the actual problem "there is no platform", they just bandaid the symptoms and you end up with weird artifacts of this approach like out of date packages, version freezes, broken packages, painful library transitions and so on. All of these things are stop-problems for end users.
It clearly isn't, as Windows and MacOS X - in fact, every commercial OS ever made - did not require the central repository scheme. They use things called "platforms" and we've been saying for a long time that Linux should have one.
Until then, autopackages - which are basically the binary equivalent of source tarballs with extra features - are the next best thing for end users who just want to click in a web page and get what they expect (as opposed to some randomly patched, out of date, potentially broken package uploaded by Mr. J Random)
That's not how it works. Go back and read the article again, they use a browser plugin to rewrite the web page as it's downloaded - probably a BHO.
I think the rationale behind the project has been explained clearly enough time and time again. What's more, often it's end users asking for this distro support, not us. Shouldn't what end users want be a pretty big hint?
Huh? Programs that use epoll can either use relaytool, direct dlsym or embed the syscalls directly (as Wine does). This is a non-issue, why is it even being debated? Programs don't grow dependencies by magic, developers add them, and it's up to the developers to decide what the minimum requirements are of their app. The lower they are, the larger their userbase can potentially be.
This dude isn't Bush, Hitler or God, he's just some old man. I know I never heard of him, maybe he's well known in the USA, but the world is full of old men who used to be famous. Not every article about such men on Wikipedia contains such inflammatory accusations. Somebody had to put them there - the question is, why?
I suspect, given the attitude displayed in the article, that he's annoyed a lot of people in the past. One of them found wikipedia and presumably couldn't help themselves ...
There's work under way to replace the Linux standalone installer with autopackage for Firefox 2. Only time will tell if that works is completed or not, but it has the support of Mozillians.
Even statically linked binaries have stopped working before due to linker, toolchain and kernel changes. And like I said, statically linking glibc itself is very dangerous. If you get it wrong DNS lookups will crash, and various other things will break in obscure ways.
You can still "leak" in Java, for instance by forgetting to null object references that then keep a huge section of the heap graph lying around without realising it. Common ways to do that include not disconnecting event listeners, and having an object provided by a library refer to one of your objects, not realising that the library object is being tracked in some global variable somewhere.
And I'm afraid static linking doesn't solve the problem either. You can't statically link everything, the NSS doesn't like it and will crash, and if you statically link libraries but not glibc you get the same problem.
Believe me. I've looked at this problem in depth. The best way to fix it is to build on the oldest version of the distro you want to support or to use apbuild. Neither of these are obvious solutions, and it's entirely the fault of the glibc designers.
Basically, and this is coming from somebody who has a lot of experience of dealing with binary software on Linux:
We can blame the admins, or the people who set the conditions of the test, or whatever, but the real problem is that Linux is crap at handling binaries. It requires an extremely precise knowledge of a million things that don't actually matter.
Whether it's supported by Sun or not is mostly irrelevant, Windows does allow for this sort of thing. Binary compatibility certainly isn't an issue which mostly affects closed source software, the exact opposite is true, binary compatibility problems are worst in an open source system like Linux (because developers have dumb attitudes towards binaries).
This system is incredibly unintuitive, extremely silly and I am not surprised that admins do not understand it given that most Linux users don't either.
I really don't know why GN is still labelled as beta given that it's not particularly buggy, probably they just forgot to remove it?
Now, you could run the plugin in a new thread AND a new heap. But then you may as well use a totally different process, the code involved would be mostly the same. And *that* is quite a complex undertaking, not worth the overhead when it's better to just fix the crashes.
No, IIRC this is called Mudflap and generates calls to special glibc APIs which check buffer sizes for calls like read(). It's another layer of security added into Linux lately: on top of exec-shield and SELinux things are feeling pretty secure round here ... too bad not every distro has these things (basically on Red Hat distros have them all).
That said, on operating systems like OS X or Linux where the user is prompted for their password to make routine configuration changes, password fatigue is a common issue. I'm sure many people would enter it regardless ("oh jeez, another damn password prompt? go away ....").
Also, for what it's worth OS X is hardly the pinnacle of security. There have been enough scary instant-code-execution problems in Safari (one within days of 10.4 being released) that I see no reason to believe Apple are more competent than Microsoft when it comes to security.
Right, so if the kernel API changed less often, there'd be less work involved. The Windows kernel API changes too you know, but as it only releases every few years, there's less work involved.
2) If you can't see the code for the module, you don't know what the module did.
This is no different to Windows programs running on Wine. You can use tracing, debuggers and disassembly to figure it out, but the easier approach is simply to say "boot without the module loaded. Does it fix it? If so, not our problem". Obviously you can't do that in Wine ...
3) Getting the end-user to build and install a kernel module is not hard.
Yes, it is. You need packages which are usually not installed by default - gotta know that. You need the right compiler installed - got to know that. The compile may fail if your kernels API has changed - what do you do then? It can be extremely slow - it's not on Windows.
Asking end users to compile software is a nasty disease Linux is afflicted with, and it really has poor usability compared to a 5-second binary install that is guaranteed to work.
Uh, have you ever tried to debug or reverse engineer a BINARY program? If so then you'd actually understand what I'm talking about, which apparently you don't.