I have been using Debian-amd64 for bit over a year now. In my benchmarks, the 64-bitness definitely helps performance; e.g. LAME (the mp3 encoder) is 50 % faster when compiled for amd64 than the x86 version.
I'm running Debian unstable, and I think things break a bit more often for 64-bit architectures than 32-bit. For example, recently apt-get source broke on 64-bit architectures. I think there are enough people however running 64-bit Debian to ensure no such flaws ever get to testing or stable. If you don't like to tinker with things like these, you obviously shouldn't run unstable.
There are some issues you might want to consider. I think there still is no Flash plugin, should you want that (I wouldn't install it on my computer if I could). Wine doesn't work, neither does MPlayer support win32 codecs. Also OpenOffice was for years very badly broken on 64-bit architechures (apparently it had so much hardcoded 32-bitisms). Debian unstable (and possibly testing?) has recently gained a 64-bit OpenOffice. I would assume it's still not quite as stable as a 32-bit version, but it's definitely getting there. I run MPlayer from a 32-bit chroot, that works nicely but is a bit of a hassle. I also run OpenOffice from the chroot, but that's just a relic from the times when there was no working 64-bit OO, so I can't comment on the stability of the 64-bit version.
But this patch would stop me using binary modules if that's what I needed to do something I want to do, for no reason other than pure pettyness.
Obviously you did not read the postings by Greg and Linus.
The issue is not pettyness. It's support nightmare. And it's the thing that you just can't take what is not yours, and that's what the companies releasing binary modules are doing. They are doing things the people that actually wrote the system don't want them to do, and arguably have the right to forbid (granted by the copyright law).
Why do you think the people who have spent years of their time even before they got employed by RH or IBM or such should inconvenience themselves and abandon their ideologies just because you, who most probably have not written a single line of code for the kernel, happen to care?
1a) were accepted, then Microsoft would have the legal right to dictate which programs (or drivers, if you really think kernel versus userspace makes a difference) a user runs on his Windows system.
I believe they would have the legal right, had they clearly not given up that right.
That's just not true. When you link A and B into a single binary thing (the compiled kernel, either a image in disk or in memory), the thing is a derived work of them both. That means that someone who has created, say, a driver for a network card, indeed has his copyright violated if someone links something not allowed by the GPL into the kernel.
If people object to binary only drivers, the sollution is for those people to refuse to use them, not for them to try to game the system to prevent other people from using them.
And the solution for those whose code is in the kernel, licensed under GPL, and being linked to binary-only code in violation of copyright?
Obviously suing the perpetrators would be a way to go. But it would be expensive.
I hate the binary only drivers enough to put my money where my mouth is. Start a fund to enable the core people like Greg to sue the violators and I, and many others, will donate. I am well willing to donate something like 100 (132 USD at the moment) to this cause.
I think that based on what I know I would rather choose to live in the US than in China. However, both have their good sides. In a sense I would prefer to live in a country where people know they are being indoctrinated than in one where the news sources are as ridiculously biased as they seem to be in the US and where the people think they are getting the truth because they feel they live in the most free and best and almost perfect society.
It's not very common with e-mail (and that makes me sad), but it's very common in WWW. Every time you access a https-URL you use public key cryptography.
This is actually one of the things where I think Microsoft has implemented security in a better way than the OSS competition (and I dislike Windows quite a lot, so I don't like to say this very much). As far as I know (and I might be wrong since I've never administered a Windows machine) the way Windows implements things an administrator can never hide the fact that he has accessed some file, which is the way it should be.
Another thing (which is somewhat off-topic but I want to complain anyway;) is that Windows implements a Secure Access Key (SAK) - it's the much laughed at Ctrl-Alt-Del. In any Linux distribution I have seen I can't be sure when I see a graphical login screen that it is the real thing and not a fake run by some user who is logged in (there is a SAK key usable for console logins if SysRq magic has been enabled when building the kernel). However in Windows you can be sure that the login screen you see is the real thing because no application can catch Ctrl-Alt-Del.
Of course if the administrator has physical access to the computer or some kind of access to the kernel code (ie. some central DLLs I think) he can always at least in theory get around these, but at least MS tried to make it difficult (and when talking about there being no SAK in Linux, at least in Windows it really takes an administrator and a lot of work to be able to run a fake login screen). I think the Windows model, where the operating system somehow tries to limit what the administrator can do, is actually quite clever.
She did not get jailed for reporting, or out of retribution for anything she printed. She got jailed for refusing to testify before a grand jury: something any one can be jailed for. Last time I checked, reporters were not in a special class to have a "get out of grand jury" card.
Arguably they should have the right to keep their sources secret. It's actually considered pretty fundamental in freedom of press. In many (perhaps most) other democracies they do. And in 33 of the US states. But the rest of the states and the federal courts don't recognize this right.
To me it seems SVG could have become a good standard, but then they decided to make it Turing complete. Like they didn't learn the lesson from PostScript that a document rendering language need not be Turing complete (and that there are several drawbacks to it being).
I wonder why Americans seem to think that their country is so wonderful that everybody would want to come there. I've seen this thing mentioned at least 10 times in this story already.
To me it doesn't seem slow at all. I use Konqueror, though, and only bothered to try D2 now so maybe I haven't just had time to notice the slowness.
To me it seems that if some browser is so slow with Javascript (BTW usually Konqueror's Javascript implementation is really slow, so I don't know why it works so well in this case), it's the browser that should be fixed.
I am curious about how this "derivative work" applies to the Linux kernel, since it is under the GPL. I am not completely familiar with the kernel's behaviour, but doesn't it mean that if I were to make any calls to the Linux kernel, this could be seen as similar to linking into a dynamic library? And anything up the call tree is also under the GPL. How can commecial software be created without using the LGPL for the Linux kernel?
The commonly accepted (but untested) theory is that the API provided by the kernel is so narrow and well defined that using it doesn't create a derivative work of the kernel. I too can see that this might be a problem, even more so in the case of embedded devices where essentially the "software" is the kernel + a binary. To me it seems that it shouldn't make much difference (legally) in that case whether you hard code your application in the kernel or use a binary; it seems to me that the result is in any case a binary "firmware", essentially a single program that controls the device, not two very separate things (the kernel and the userland).
Another common argument is that the kernel developers themselves have stated that merely using the provided syscalls is not creating derived works. If they were the sole owners of the copyrights, it would of course be in their power to make that decision. However incorporating 3rd party GPL code that didn't originate from the kernel makes this case more interesting, as the kernel developers no longer have the authority to make such "exceptions" to GPL.
Re:Publicly traded companies and their spam
on
Buy Low, Spam High
·
· Score: 1
Though I don't know what the usual sentences for these cases are, I found a story of a lawyer (in the US) that did pump and dump sentenced to 8 years in prison. However that apparently also included tax fraud related to the pump and dump scheme.
Linus himself has repeatedly said that loading closed source kernel modules is not a violation of his license.
Actually that's not quite what Linus has said. But even assuming it is, you make a common mistake here, thinking that Linus somehow magically has more say over it than the rest of the community. The license is what it is and Linus cannot decide what it means without the explicit permission of each and every contributor.
I repeat, the license is what it is and even Linus will just have to live with it. If it forbids binary modules, they are forbidden, no matter what Linus says he considers the license to mean. It's for courts, not for Linus, to decide.
What the GPLv2 actually says is that if you distribute derivatives of the GPL'ed product you have to make your modifications open source. In no way shape or form is a GPU driver a "derivative" of the Linux kernel. That's like saying Slashdot is a derivative of the glibc project because the Apache server it runs on uses it.
Perhaps it seems that way only because you haven't thought very much about this.
The fact is that Apache is a derivative of glibc when running on Linux. That's pretty well established, almost nobody who knows anything about both software and law would claim otherwise. It's just that the licensing terms of glibc allow this derivation.
If the said binary driver made a lot of calls to the kernel and extensively used kernel macros and complex structures internal to the kernel, it's a very grey area. Even with less complex interaction with the rest of the kernel it's a grey area, to be determined by the courts (and by the courts only, since 'derived work' is a legal term).
Unfortunately, linus decided to use a different definition of the word 'derivitive' to everyone else & created a grey legal area (and lets face it, its not like anyone is going to press for a GPL violation case involving the linux kernel without linus's support).
I wouldn't be that sure that no one of the thousands of people whose code there is in Linux, including probably a few who didn't originally write the code for Linux kernel but released it under GPL, is going to press charges. I think it's very realistic that there would be such a contributor who doesn't like what nVidia and ATI (among others) are doing.
But you have a very good point here. Many people seem to think that Linus has the say over whether there can be binary drivers or not. The reality is that the license is what it is and if it doesn't allow binary drivers, there's *nothing* Linus or anyone else in the kernel community can do about it (save for the theoretical case where each and every kernel contributor actively give a permission for a license change).
By the way, the term 'derivative' is a legal term and its precise meaning wrt software still pretty much remains to be determined in court in pretty much everywhere in the world, including the US. Loadable binary modules are a grey area to which only the courts have the final say. I like to think myself that they make a derivative work, but who knows.
By a literal reading of this, were I a judge, I might very well rule that any output of the program is, therefore, a derivative work.
No, you still misunderstand the issue. A license, be it GPL or some other, has no say in whether something is a derived work or not. Either it is a derived work, regardless of what the license says, or it is not. If it is not, the license saying it is won't make it so. If it is not a derived work, the license cannot restrict its distribution because it is an independent work, legally unrelated to the program.
It sounds vague only because it has to be so. A "work based on the Program" is a legal term, it cannot be defined by the GPL. If the output isn't one, GPL cannot consider it a derivative work.
Interesting. Unpredictability and inconsistency were the reasons why I originally (way back) moved to Linux. I found that with Windows I always had to think about what the developers might have thought when making Windows and how it might try to outguess me this time. It seemed as if Windows applied some heuristic to guess what it was I wanted to do and did that instead of what I told it to do, often without asking me first.
Slashdot Mirror
I for one am more than happy to see that license issues are being taken seriously in projects other than Debian.
I have been using Debian-amd64 for bit over a year now. In my benchmarks, the 64-bitness definitely helps performance; e.g. LAME (the mp3 encoder) is 50 % faster when compiled for amd64 than the x86 version.
I'm running Debian unstable, and I think things break a bit more often for 64-bit architectures than 32-bit. For example, recently apt-get source broke on 64-bit architectures. I think there are enough people however running 64-bit Debian to ensure no such flaws ever get to testing or stable. If you don't like to tinker with things like these, you obviously shouldn't run unstable.
There are some issues you might want to consider. I think there still is no Flash plugin, should you want that (I wouldn't install it on my computer if I could). Wine doesn't work, neither does MPlayer support win32 codecs. Also OpenOffice was for years very badly broken on 64-bit architechures (apparently it had so much hardcoded 32-bitisms). Debian unstable (and possibly testing?) has recently gained a 64-bit OpenOffice. I would assume it's still not quite as stable as a 32-bit version, but it's definitely getting there. I run MPlayer from a 32-bit chroot, that works nicely but is a bit of a hassle. I also run OpenOffice from the chroot, but that's just a relic from the times when there was no working 64-bit OO, so I can't comment on the stability of the 64-bit version.
Overall I'm very happy with amd64-Debian.
But this patch would stop me using binary modules if that's what I needed to do something I want to do, for no reason other than pure pettyness.
Obviously you did not read the postings by Greg and Linus.
The issue is not pettyness. It's support nightmare. And it's the thing that you just can't take what is not yours, and that's what the companies releasing binary modules are doing. They are doing things the people that actually wrote the system don't want them to do, and arguably have the right to forbid (granted by the copyright law).
Why do you think the people who have spent years of their time even before they got employed by RH or IBM or such should inconvenience themselves and abandon their ideologies just because you, who most probably have not written a single line of code for the kernel, happen to care?
1a) were accepted, then Microsoft would have the legal right to dictate which programs (or drivers, if you really think kernel versus userspace makes a difference) a user runs on his Windows system.
I believe they would have the legal right, had they clearly not given up that right.
That's just not true. When you link A and B into a single binary thing (the compiled kernel, either a image in disk or in memory), the thing is a derived work of them both. That means that someone who has created, say, a driver for a network card, indeed has his copyright violated if someone links something not allowed by the GPL into the kernel.
That should be 100 euros, but the stupid slashdot system ate the euro sign.
And no, I'm not rich (in fact I'm a student). I'm just fed up.
If people object to binary only drivers, the sollution is for those people to refuse to use them, not for them to try to game the system to prevent other people from using them.
And the solution for those whose code is in the kernel, licensed under GPL, and being linked to binary-only code in violation of copyright?
Obviously suing the perpetrators would be a way to go. But it would be expensive.
I hate the binary only drivers enough to put my money where my mouth is. Start a fund to enable the core people like Greg to sue the violators and I, and many others, will donate. I am well willing to donate something like 100 (132 USD at the moment) to this cause.
As an European, I'll try to answer.
I think that based on what I know I would rather choose to live in the US than in China. However, both have their good sides. In a sense I would prefer to live in a country where people know they are being indoctrinated than in one where the news sources are as ridiculously biased as they seem to be in the US and where the people think they are getting the truth because they feel they live in the most free and best and almost perfect society.
It's not very common with e-mail (and that makes me sad), but it's very common in WWW. Every time you access a https-URL you use public key cryptography.
Well, that's then a case of the Constitution not being up to what is commonly considered the standard in the free world, isn't it?
This is actually one of the things where I think Microsoft has implemented security in a better way than the OSS competition (and I dislike Windows quite a lot, so I don't like to say this very much). As far as I know (and I might be wrong since I've never administered a Windows machine) the way Windows implements things an administrator can never hide the fact that he has accessed some file, which is the way it should be.
;) is that Windows implements a Secure Access Key (SAK) - it's the much laughed at Ctrl-Alt-Del. In any Linux distribution I have seen I can't be sure when I see a graphical login screen that it is the real thing and not a fake run by some user who is logged in (there is a SAK key usable for console logins if SysRq magic has been enabled when building the kernel). However in Windows you can be sure that the login screen you see is the real thing because no application can catch Ctrl-Alt-Del.
Another thing (which is somewhat off-topic but I want to complain anyway
Of course if the administrator has physical access to the computer or some kind of access to the kernel code (ie. some central DLLs I think) he can always at least in theory get around these, but at least MS tried to make it difficult (and when talking about there being no SAK in Linux, at least in Windows it really takes an administrator and a lot of work to be able to run a fake login screen). I think the Windows model, where the operating system somehow tries to limit what the administrator can do, is actually quite clever.
She did not get jailed for reporting, or out of retribution for anything she printed. She got jailed for refusing to testify before a grand jury: something any one can be jailed for. Last time I checked, reporters were not in a special class to have a "get out of grand jury" card.
Arguably they should have the right to keep their sources secret. It's actually considered pretty fundamental in freedom of press. In many (perhaps most) other democracies they do. And in 33 of the US states. But the rest of the states and the federal courts don't recognize this right.
To me it seems SVG could have become a good standard, but then they decided to make it Turing complete. Like they didn't learn the lesson from PostScript that a document rendering language need not be Turing complete (and that there are several drawbacks to it being).
Huh? If you don't have any specific reason to trust it, it's untrusted. I would have thunk that's Internet 101.
I wonder why Americans seem to think that their country is so wonderful that everybody would want to come there. I've seen this thing mentioned at least 10 times in this story already.
To me it doesn't seem slow at all. I use Konqueror, though, and only bothered to try D2 now so maybe I haven't just had time to notice the slowness.
To me it seems that if some browser is so slow with Javascript (BTW usually Konqueror's Javascript implementation is really slow, so I don't know why it works so well in this case), it's the browser that should be fixed.
I am curious about how this "derivative work" applies to the Linux kernel, since it is under the GPL. I am not completely familiar with the kernel's behaviour, but doesn't it mean that if I were to make any calls to the Linux kernel, this could be seen as similar to linking into a dynamic library? And anything up the call tree is also under the GPL. How can commecial software be created without using the LGPL for the Linux kernel?
The commonly accepted (but untested) theory is that the API provided by the kernel is so narrow and well defined that using it doesn't create a derivative work of the kernel. I too can see that this might be a problem, even more so in the case of embedded devices where essentially the "software" is the kernel + a binary. To me it seems that it shouldn't make much difference (legally) in that case whether you hard code your application in the kernel or use a binary; it seems to me that the result is in any case a binary "firmware", essentially a single program that controls the device, not two very separate things (the kernel and the userland).
Another common argument is that the kernel developers themselves have stated that merely using the provided syscalls is not creating derived works. If they were the sole owners of the copyrights, it would of course be in their power to make that decision. However incorporating 3rd party GPL code that didn't originate from the kernel makes this case more interesting, as the kernel developers no longer have the authority to make such "exceptions" to GPL.
Though I don't know what the usual sentences for these cases are, I found a story of a lawyer (in the US) that did pump and dump sentenced to 8 years in prison. However that apparently also included tax fraud related to the pump and dump scheme.
And that's exactly why GPL contains an exception for system libraries.
Linus himself has repeatedly said that loading closed source kernel modules is not a violation of his license.
Actually that's not quite what Linus has said. But even assuming it is, you make a common mistake here, thinking that Linus somehow magically has more say over it than the rest of the community. The license is what it is and Linus cannot decide what it means without the explicit permission of each and every contributor.
I repeat, the license is what it is and even Linus will just have to live with it. If it forbids binary modules, they are forbidden, no matter what Linus says he considers the license to mean. It's for courts, not for Linus, to decide.
What the GPLv2 actually says is that if you distribute derivatives of the GPL'ed product you have to make your modifications open source. In no way shape or form is a GPU driver a "derivative" of the Linux kernel. That's like saying Slashdot is a derivative of the glibc project because the Apache server it runs on uses it.
Perhaps it seems that way only because you haven't thought very much about this.
The fact is that Apache is a derivative of glibc when running on Linux. That's pretty well established, almost nobody who knows anything about both software and law would claim otherwise. It's just that the licensing terms of glibc allow this derivation.
If the said binary driver made a lot of calls to the kernel and extensively used kernel macros and complex structures internal to the kernel, it's a very grey area. Even with less complex interaction with the rest of the kernel it's a grey area, to be determined by the courts (and by the courts only, since 'derived work' is a legal term).
Unfortunately, linus decided to use a different definition of the word 'derivitive' to everyone else & created a grey legal area (and lets face it, its not like anyone is going to press for a GPL violation case involving the linux kernel without linus's support).
I wouldn't be that sure that no one of the thousands of people whose code there is in Linux, including probably a few who didn't originally write the code for Linux kernel but released it under GPL, is going to press charges. I think it's very realistic that there would be such a contributor who doesn't like what nVidia and ATI (among others) are doing.
But you have a very good point here. Many people seem to think that Linus has the say over whether there can be binary drivers or not. The reality is that the license is what it is and if it doesn't allow binary drivers, there's *nothing* Linus or anyone else in the kernel community can do about it (save for the theoretical case where each and every kernel contributor actively give a permission for a license change).
By the way, the term 'derivative' is a legal term and its precise meaning wrt software still pretty much remains to be determined in court in pretty much everywhere in the world, including the US. Loadable binary modules are a grey area to which only the courts have the final say. I like to think myself that they make a derivative work, but who knows.
By a literal reading of this, were I a judge, I might very well rule that any output of the program is, therefore, a derivative work.
No, you still misunderstand the issue. A license, be it GPL or some other, has no say in whether something is a derived work or not. Either it is a derived work, regardless of what the license says, or it is not. If it is not, the license saying it is won't make it so. If it is not a derived work, the license cannot restrict its distribution because it is an independent work, legally unrelated to the program.
It sounds vague only because it has to be so. A "work based on the Program" is a legal term, it cannot be defined by the GPL. If the output isn't one, GPL cannot consider it a derivative work.
Interesting. Unpredictability and inconsistency were the reasons why I originally (way back) moved to Linux. I found that with Windows I always had to think about what the developers might have thought when making Windows and how it might try to outguess me this time. It seemed as if Windows applied some heuristic to guess what it was I wanted to do and did that instead of what I told it to do, often without asking me first.