Not necessarily true. Just because I've read the discrete wavelet transformation written in Numerical Recipes does *not* mean my implementation is a derivative work. Just because I've read Nash & Sofer's (and NRC, and...) discussions and codes for the conjugate gradient method does *not* mean my implementation is a derivative work. I do not have to assign copyright (and in fact, am not allowed to) to the NRC authors for my work; that copyright is owned by my university.
Just because I've read the Linux startup code doesn't mean my bootstrapping code is a derivative work. Just because I've read the code for a GPL'd text-based menuing system doesn't mean every text-based menuing system I write is a derivative work.
Your statement "GPLed code cannot be used as a reference implementation... derivative work and would be infected by the GPL" is not only clearly biased, but plainly wrong. It simply requires that people "roll their own" or accept restrictions on redistribution.
I think you might be confused by patents, which do not allow independent implementations under any circumstances. Copyright doesn't work that way.
The TCP/IP stack is the example everyone likes to use as a BSD success story in standardization. Are there other examples? Incidently, I've been told (by a BSD guy) that the TCP/IP stack in Linux was written independently; that said, the author(s) probably had read W. Richard Stevens. =-)
I think that GPL'd code could be used as a reference implementation, too. The recipients would have to write their own version, but could check the GPL version just as easy as they could check the BSD version.
As for academic code, the BSD and GPL licenses both give the recipient more rights than typical university licenses. As a Ph.D. student I'd love to release my code under the GPL, but there is no way my advisor and/or my university would allow that. You used the term "strict" to describe the rules of the GPL relative to the BSD license; compared to typical academic rules, the GPL and the BSD are more-or-less equivalent.
By "free as in anarchy", I meant "freedoms without conditions". As I understand the BSD license, you don't have to give anything up to enjoy more-or-less complete freedom with the code. This seems somewhat in line with anarchist, or possibly libertarian, ideals (few or no rules, irrespectively).
In contrast, the GPL gives you freedoms you wouldn't enjoy under fair-use provisions, but certain freedoms (redistribution) are only granted under certain conditions. Thus the GPL is much like the First Amendment to the American Constitution in trying to achieve some balance of order and legal-infrastructure and individual rights (quite unlike the current American government;-).
That's what I meant by my comment. What did you mean by yours? While I appreciate the irony of the statement "free as in Fascism", I don't understand at all how the GPL is anything like fascism. Are you suggesting that Mussolini's style of governance provided more freedoms to the Italian people than was the default, or that Hitler was working on balanced legislation for the good of all Germans?
I expect that this "freer" stuff is semantic. Maybe it would be appropriate to say that the BSD license is "free as in anarchy", while the GPL is more like social freedoms (freedoms which require balance). I've never been an anarchist or libertarian, and prefer the freedom-infrastructure built by the GPL.
We use soft updates on our FreeBSD fileserver. As you say, they're not the same as journaling, and I'll add that the end result is not the same when your server crashes and you fsck on boot.
The idea of a "single user computer" is a little strange, unless you're referring to a palmtop or live alone. If you have a girlfriend, spouse, or kids, or have family and other guests visiting, it seems unlikely only one person will use the computer.
When guests come, I open an account for them and let them know that they can't do anything to hurt the system (except hit the power button). I think it helps them feel more comfortable.
Completely unrelated: when I see guests using Mozilla to check their outlook mail from my GNU/Linux machines, I realize just how dangerous Netscape might have been to Microsoft. A few minutes after logging in, they appear to have forgotten they're not running Windows.
Slightly more seriously, I think the "cowboy" attitude of the linux community has helped.
Example: Don't like slow NFS? Just change the defaults (in older kernels) to async.
The BSD "folks" seem (to me) as very conservative compared to the fast-and-footloose anything-for-a-thrill linux "folks". They seem "ivory tower"-ish compared to the "real world" linux people.
Also different between the two communities is that Linus pulled in all the GNU project tools to create and operating system. Since the GNU tools were already popular in the early 1990s, people could move to a GNU/Linux system and feel right at home. The BSD-derived operating systems come with BSD baggage that makes them hard to use for non-BSD folks
Summary: GNU/Linux systems make better use of existing software and trends than BSD systems, which increasese popularity and effiency.
Now I'll hit post, read what I wrote, and see if I believe it.;-)
I've had driver problems on FreeBSD. For instance, KeySpan apparently offered to help the FreeBSD folks implement a driver for their USB-to-serial port devices, so long as a liason was appointed. Nobody responded on the mailing lists, and AFAIK (true in early summer) there is still no support for USB-serial devices.
Not exactly a "device", but FreeBSD is still lacking journaling filesystems. On the other hand, several vendors are working on them simultaneously for linux-based systems: IBM, SGI, and Reiser. This is outside of the "core" journaling filesystem, ext3.
I can't comment on OpenBSD -- I don't use it and it doesn't have the same kernel as FreeBSD. But that's probably part of the device driver problem -- each BSD has it's own kernel. Not to mention that the BSD folks have heavy (IMO unnecessary) overlap with the GNU project.
One nice thing about gaming under GNU/Linux is that preferences and saved games are stored in the user's home directory. That means several people can play on the same computer (at different times, of course!), each with their own settings automagically. However, I play under GNU/Linux because Microsoft lost my support around 1995, and hasn't done anything to win me back.
As a scientific user of commodotized x86 hardware, this has me a little worried. We've been happily riding the x86 performance-per-dollar wave on the backs of video gamers. If gamers and other large groups of users quit underwriting high-performance cpus, the scientific community may find itself back in the old "big-bucks workstation land".
You can't believe how much I agree with you. I'm very tired of having to wade through "server" literature just to find a good workstation. OTOH, if you think of the workstation as a "cycle server", well.... =-)
From what I understand, the integer performance is stinky, and that it's going to take a *long* time before gcc really produces good code for Itanium, and that the Itanium is *really* expensive. Is Itanium really outdoing Alpha or PA-RISC on Spec? I haven't seen news of such a result.
And in the end, I'm interested in price/performance. As I replied to another poster, the Itanium only seems to make price/performance sense if your lucky enough to have Intel give you one for free.
I haven't tried the ppc yes, but we've considered ppc machines. Vector processing could really improve parts of our algorithms. However we can't afford to spend time on things like altivec and sse, and must remain portable.
I may be able to give the testing code away; I'm waiting for a response from my advisor (GMT-5, so it will be a few more hours before he's even awake =-). Send me an email if you'd like the code.
The P4 used gcc 3x, while the Alpha and Athlon XP used gcc 2.96. =-) If anything, this should give the P4 an advantage.
The Athlon C and P-III results were all msvc. I don't know which version was used, because I didn't do the tests.
If you'd like my test code, email me (my address is in my user info). We've already compared gcc's asm on Alpha, Athlon, and P4, and found nothing particularly strange. The stall seems to come from memory fetches. It's possible that blocking our matrix could really improve cache behavior, but it would be fairly painful to implement in this case.
Your repsonse is not particularly well-related to my post. I hope for the Hammer to replace our Alphas in providing big memory per process. I didn't claim that the P4 performs 80 times slower. In fact, the P4 Xeon 1.7GHz generally outperforms my Athlon XP 1900+; of course, it also costs more. But on a bit of code I wrote for my research, it goes 80 times slower.
I can't spend all my research time optimizing for one silly cpu. My code is run on about 4 different cpus (only two different instruction sets, though) at present. Another cpu (with another instruction set) will be added soon. If Intel wants my code to run fast on the P4 Xeon, they can contribute to GCC; but I don't care. I'm happy to recommend that users of my code buy Athlons or Alphas.
If you weren't anonymous, I might take you more seriously. =-) I'm very interested in price/performance and maintainability. I think the Itaniums will lose on price/performance for a long time. Since Itanium(2) is so far from being a commodity processor (like our Alphas), we'd have to expend extra effort to maintain them and train others to maintain them.
The bottom line is that Itaniums only seem to make sense for people who get them for free.
We've sort of considered IA-64, but don't really want to make that expensive of leap into that performance mess. We're not going to buy into a *radically* new architecture weeks after its release, either. And we can't afford to spend lots of time tuning our code for one platform or another -- portability is key. gcc is our compiler of choice because we don't have to screw with (as many) platform-specific issues.
"But judging from the benchmarks you posted further below, I question your know-how. You compare a GCC-compiled program running on a Pentium 4 to MSVC-compiled programs running on Athlons?"
I could snottily retort that I question your reading know-how, since msvc was for P-III and Athlon C, while gcc was for all the rest; but I won't.;-) The Windows tests were done by a different person, on his own time, 2500 miles from me. I did the P4, Athlon XP, and Alpha tests using gcc. You can at least compare those numbers. And in the end, the compiler (in general) should not make a 200% to 8000% performance difference.
For the tests, I used the same compilers we use for development and distrobution. We don't have time to screw with the industry's popularity contests. We do algorithmic and data structure work, aiming for 10000% speed-ups that just aren't available through compiler cleverness. The Intel compiler won't help us when compiling on Alpha, MIPS, or PA-Risc.
Price/performance on the Alphas is low for most of our applications, making the only Alpha selling point it's 64-bitness for big memory. Many of our apps don't need that much space and can run on x86. The few apps that do need 64-bitness will be run on our existing Alphas. If we could get dual Alpha 1GHz machines for the same price as dual P4 Xeons, we would.
There's also the issue that finding replacement sysadmins for the Alphas isn't as easy as it is for the x86 machines. Alphas aren't much different to admin, but it can be a bit of a speedbump.
Slashdot Mirror
Not necessarily true. Just because I've read the discrete wavelet transformation written in Numerical Recipes does *not* mean my implementation is a derivative work. Just because I've read Nash & Sofer's (and NRC, and ...) discussions and codes for the conjugate gradient method does *not* mean my implementation is a derivative work. I do not have to assign copyright (and in fact, am not allowed to) to the NRC authors for my work; that copyright is owned by my university.
... derivative work and would be infected by the GPL" is not only clearly biased, but plainly wrong. It simply requires that people "roll their own" or accept restrictions on redistribution.
Just because I've read the Linux startup code doesn't mean my bootstrapping code is a derivative work. Just because I've read the code for a GPL'd text-based menuing system doesn't mean every text-based menuing system I write is a derivative work.
Your statement "GPLed code cannot be used as a reference implementation
I think you might be confused by patents, which do not allow independent implementations under any circumstances. Copyright doesn't work that way.
-Paul Komarek
The TCP/IP stack is the example everyone likes to use as a BSD success story in standardization. Are there other examples? Incidently, I've been told (by a BSD guy) that the TCP/IP stack in Linux was written independently; that said, the author(s) probably had read W. Richard Stevens. =-)
I think that GPL'd code could be used as a reference implementation, too. The recipients would have to write their own version, but could check the GPL version just as easy as they could check the BSD version.
As for academic code, the BSD and GPL licenses both give the recipient more rights than typical university licenses. As a Ph.D. student I'd love to release my code under the GPL, but there is no way my advisor and/or my university would allow that. You used the term "strict" to describe the rules of the GPL relative to the BSD license; compared to typical academic rules, the GPL and the BSD are more-or-less equivalent.
-Paul Komarek
By "free as in anarchy", I meant "freedoms without conditions". As I understand the BSD license, you don't have to give anything up to enjoy more-or-less complete freedom with the code. This seems somewhat in line with anarchist, or possibly libertarian, ideals (few or no rules, irrespectively).
;-).
In contrast, the GPL gives you freedoms you wouldn't enjoy under fair-use provisions, but certain freedoms (redistribution) are only granted under certain conditions. Thus the GPL is much like the First Amendment to the American Constitution in trying to achieve some balance of order and legal-infrastructure and individual rights (quite unlike the current American government
That's what I meant by my comment. What did you mean by yours? While I appreciate the irony of the statement "free as in Fascism", I don't understand at all how the GPL is anything like fascism. Are you suggesting that Mussolini's style of governance provided more freedoms to the Italian people than was the default, or that Hitler was working on balanced legislation for the good of all Germans?
-Paul Komarek
I expect that this "freer" stuff is semantic. Maybe it would be appropriate to say that the BSD license is "free as in anarchy", while the GPL is more like social freedoms (freedoms which require balance). I've never been an anarchist or libertarian, and prefer the freedom-infrastructure built by the GPL.
-Paul Komarek
We use soft updates on our FreeBSD fileserver. As you say, they're not the same as journaling, and I'll add that the end result is not the same when your server crashes and you fsck on boot.
-Paul Komarek
The idea of a "single user computer" is a little strange, unless you're referring to a palmtop or live alone. If you have a girlfriend, spouse, or kids, or have family and other guests visiting, it seems unlikely only one person will use the computer.
When guests come, I open an account for them and let them know that they can't do anything to hurt the system (except hit the power button). I think it helps them feel more comfortable.
Completely unrelated: when I see guests using Mozilla to check their outlook mail from my GNU/Linux machines, I realize just how dangerous Netscape might have been to Microsoft. A few minutes after logging in, they appear to have forgotten they're not running Windows.
-Paul Komarek
It's all about the penguin. ;-)
;-)
Slightly more seriously, I think the "cowboy" attitude of the linux community has helped.
Example: Don't like slow NFS? Just change the defaults (in older kernels) to async.
The BSD "folks" seem (to me) as very conservative compared to the fast-and-footloose anything-for-a-thrill linux "folks". They seem "ivory tower"-ish compared to the "real world" linux people.
Also different between the two communities is that Linus pulled in all the GNU project tools to create and operating system. Since the GNU tools were already popular in the early 1990s, people could move to a GNU/Linux system and feel right at home. The BSD-derived operating systems come with BSD baggage that makes them hard to use for non-BSD folks
Summary: GNU/Linux systems make better use of existing software and trends than BSD systems, which increasese popularity and effiency.
Now I'll hit post, read what I wrote, and see if I believe it.
-Paul Komarek
I've had driver problems on FreeBSD. For instance, KeySpan apparently offered to help the FreeBSD folks implement a driver for their USB-to-serial port devices, so long as a liason was appointed. Nobody responded on the mailing lists, and AFAIK (true in early summer) there is still no support for USB-serial devices.
Not exactly a "device", but FreeBSD is still lacking journaling filesystems. On the other hand, several vendors are working on them simultaneously for linux-based systems: IBM, SGI, and Reiser. This is outside of the "core" journaling filesystem, ext3.
I can't comment on OpenBSD -- I don't use it and it doesn't have the same kernel as FreeBSD. But that's probably part of the device driver problem -- each BSD has it's own kernel. Not to mention that the BSD folks have heavy (IMO unnecessary) overlap with the GNU project.
-Paul Komarek
Hey, that's the same combination I use for my luggage!
-Paul Komarek
"Rockets" are hard to get right. If they weren't, everyone would have ICBMs by now.
-Paul
One nice thing about gaming under GNU/Linux is that preferences and saved games are stored in the user's home directory. That means several people can play on the same computer (at different times, of course!), each with their own settings automagically. However, I play under GNU/Linux because Microsoft lost my support around 1995, and hasn't done anything to win me back.
-Paul Komarek
You can order from tuxgames. I just placed my order!
-Paul Komarek
As a scientific user of commodotized x86 hardware, this has me a little worried. We've been happily riding the x86 performance-per-dollar wave on the backs of video gamers. If gamers and other large groups of users quit underwriting high-performance cpus, the scientific community may find itself back in the old "big-bucks workstation land".
;-)
Well, it was fun while it lasted.
-Paul Komarek
Thanks for that link! I'm going to try to watch that thread; there seems to be at least a handful of sharp people posting there.
-Paul Komarek
I've received a lot of email about my test code. I obtained permission to distribute my test code, and have made a web page with it. For those who are interested, please see http://www.andrew.cmu.edu/~komarek/work/RobustChol eskyPerf/RobustCholeskyPerf.html.
-Paul Komarek
I now have permission to send the code, but I don't have an email address for you.
-Paul Komarek
You can't believe how much I agree with you. I'm very tired of having to wade through "server" literature just to find a good workstation. OTOH, if you think of the workstation as a "cycle server", well .... =-)
-Paul Komarek
From what I understand, the integer performance is stinky, and that it's going to take a *long* time before gcc really produces good code for Itanium, and that the Itanium is *really* expensive. Is Itanium really outdoing Alpha or PA-RISC on Spec? I haven't seen news of such a result.
And in the end, I'm interested in price/performance. As I replied to another poster, the Itanium only seems to make price/performance sense if your lucky enough to have Intel give you one for free.
-Paul Komarek
I haven't tried the ppc yes, but we've considered ppc machines. Vector processing could really improve parts of our algorithms. However we can't afford to spend time on things like altivec and sse, and must remain portable.
-Paul Komarek
I may be able to give the testing code away; I'm waiting for a response from my advisor (GMT-5, so it will be a few more hours before he's even awake =-). Send me an email if you'd like the code.
The P4 used gcc 3x, while the Alpha and Athlon XP used gcc 2.96. =-) If anything, this should give the P4 an advantage.
The Athlon C and P-III results were all msvc. I don't know which version was used, because I didn't do the tests.
-Paul Komarek
If you'd like my test code, email me (my address is in my user info). We've already compared gcc's asm on Alpha, Athlon, and P4, and found nothing particularly strange. The stall seems to come from memory fetches. It's possible that blocking our matrix could really improve cache behavior, but it would be fairly painful to implement in this case.
-Paul Komarek
Your repsonse is not particularly well-related to my post. I hope for the Hammer to replace our Alphas in providing big memory per process. I didn't claim that the P4 performs 80 times slower. In fact, the P4 Xeon 1.7GHz generally outperforms my Athlon XP 1900+; of course, it also costs more. But on a bit of code I wrote for my research, it goes 80 times slower.
I can't spend all my research time optimizing for one silly cpu. My code is run on about 4 different cpus (only two different instruction sets, though) at present. Another cpu (with another instruction set) will be added soon. If Intel wants my code to run fast on the P4 Xeon, they can contribute to GCC; but I don't care. I'm happy to recommend that users of my code buy Athlons or Alphas.
-Paul Komarek
If you weren't anonymous, I might take you more seriously. =-) I'm very interested in price/performance and maintainability. I think the Itaniums will lose on price/performance for a long time. Since Itanium(2) is so far from being a commodity processor (like our Alphas), we'd have to expend extra effort to maintain them and train others to maintain them.
The bottom line is that Itaniums only seem to make sense for people who get them for free.
-Paul Komarek
We've sort of considered IA-64, but don't really want to make that expensive of leap into that performance mess. We're not going to buy into a *radically* new architecture weeks after its release, either. And we can't afford to spend lots of time tuning our code for one platform or another -- portability is key. gcc is our compiler of choice because we don't have to screw with (as many) platform-specific issues.
;-) The Windows tests were done by a different person, on his own time, 2500 miles from me. I did the P4, Athlon XP, and Alpha tests using gcc. You can at least compare those numbers. And in the end, the compiler (in general) should not make a 200% to 8000% performance difference.
"But judging from the benchmarks you posted further below, I question your know-how. You compare a GCC-compiled program running on a Pentium 4 to MSVC-compiled programs running on Athlons?"
I could snottily retort that I question your reading know-how, since msvc was for P-III and Athlon C, while gcc was for all the rest; but I won't.
For the tests, I used the same compilers we use for development and distrobution. We don't have time to screw with the industry's popularity contests. We do algorithmic and data structure work, aiming for 10000% speed-ups that just aren't available through compiler cleverness. The Intel compiler won't help us when compiling on Alpha, MIPS, or PA-Risc.
-Paul Komarek
Price/performance on the Alphas is low for most of our applications, making the only Alpha selling point it's 64-bitness for big memory. Many of our apps don't need that much space and can run on x86. The few apps that do need 64-bitness will be run on our existing Alphas. If we could get dual Alpha 1GHz machines for the same price as dual P4 Xeons, we would.
There's also the issue that finding replacement sysadmins for the Alphas isn't as easy as it is for the x86 machines. Alphas aren't much different to admin, but it can be a bit of a speedbump.
-Paul Komarek