Was the "objective" of Linux ever world domination?
I thought it was a bunch of people working in their spare time (and more recently, for corporations) to produce a Free operating system that they would enjoy using/developing, and, in many cases, that other people would enjoy using as well.
Many people have some political agenda when they work on Free/Open Source Software. Many people don't. Asking "what is [Linux] trying to achieve," isn't a very well-defined question, because "Linux" is not a single sentient entity. It's a community of people with many different goals and ideas.
Some things in LaTeX are a little less structured than XHTML, I suppose. For instance, you delineate paragraphs with \paragraph at the beginning, but there's no closing tag. It's more of a "new paragraph begins here" marker (like people used to use in the old days of HTML).
Of course, that's just the default way to do it. You can make macros in LaTeX that will let you structure things almost any way you want.
All optimizations that can apply to higher level programming languages can apply to C++ too.
Can it? There are no techniques that optimize things in functional languages that C++ doesn't even deal with (lazy evaluation and garbage collection for example)? In addition, since, as you say, much more money and time has been put into optimizing C++, there may be optimizations that are in C++ that haven't been worked on for functional languages yet.
As for lisp/scheme they are a different paradigm... functional programming is inherently incomparable to a procedural language like C++.
You can write imperative code in scheme and lisp. They both have assignment, loops, and the ability to sequentially execute expressions.
I'm not sure what that was in relation to, though. All the languages I mentioned are primarily functional (although many people would argue that Common Lisp is a multi-paradigm language, like C++). Only Haskell is purely functional (since you can't do any imperative programming).
Suppose I have a widget toolkit X, that contains a widget foo, that every good X-based application uses.
I also have a widget toolkit Y, that has a widget bar, that's similarly included in all good Y-based applications.
X doesn't contain a direct analog to bar, and Y doesn't contain a direct analog to foo. In either case, you have to use a totally different widget, or combination of widgets in the opposite toolkit.
How do I make one meta-toolkit such that when I compile against a Y backend, it correctly uses bar in all the correct places, while against an X backend, it's done in some completely different way? And the same for foo. How is inheritance going to solve that?
How is inheritance and recompiling going to solve the difference between all sorts of different interface guidelines that differ from platform to platform?
What makes you think these languages will be significantly slower than C++? There are benchmarks out there that put Ocaml code on equal or better footing than C++. And people have been working on optimizing compilers for Lisp for a very long time.
Any gap will likely shrink in the future, too, as more work gets put into optimizing compilers for the more modern functional languages. By contrast, it seems unlikely that C++ will catch up as far as the simplicity factor is concerned, so saying that C++ will always be around for compilers seems inaccurate to me.
Qt is an autonomous toolkit, though. Qt is analogous to Swing or Cocoa. You can theme it to look like a Mac application, but it's not taking advantage of the native toolkit, so you won't get integration with the target system.
wxWidgets is more like SWT, in that it presents a uniform API that's implemented underneath by a native toolkit. So, you could make a Qt implementation of wxWidgets, and your wxWidgets app would look like a Qt app (that doesn't exist, although a GTK version does).
However, I'm skeptical that a wxWidgets application will fit in as well as anything written in the native toolkit itself. There's stuff in the Mac gui that isn't in GTK, and there's stuff that Qt/KDE can do that Gnome/GTK can't, and so on. I'm not sure I see how this can be reconciled by a library that has to provide a common interface to all of them.
The only thing I can come up with is some high level UI description language, where, for example, you say: "This is an accessory window for this other window," and the system automatically knows uses a drawer on OS X, and an extra top-level window on GTK or Qt, or something like that. But I'm not sure that's even feasible, and that really has nothing to do with the C++ standard library.
But, if I were proven wrong, I wouldn't be unhappy.
A few weeks back, I recall reading a thread on comp.lang.functional that had lots of argument about C++ (I think the thread is disguised by being called "Generic Programming and Functional Languages," if you care to look it up, though I could be wrong about it being that one; the C++ debate is buried several levels down in the thread). Naturally, the functional guys don't like C++ too much for many different reasons. However, there was an actual C++ language designer (I guess he's on the committee or something) there debating with them, so it turned into a nice flamewar.:)
In short, the C++ guy argued that it was a pretty good language given all the constraints Bjarne had, including C compatibility and so on. Of course, the functional guys argued that no matter what the circumstances, that didn't make C++ an actual good language (and I agree). The history might explain why C++ is bad, but that's not an acceptable reason to use a bad language.
Now, the C++ guy seemed enamored with the idea that he could eventually "fix" C++ into a good language. However, one constraint he had was that it had to be compatible with C++ as it exists now. In other words, you're unlikely to ever see features removed from C++ to make it better; the only option is adding to it.
The people on the newsgroup argued (and I quite agree with them), that no matter how much you add to C++, it's not going to become "good." In fact, as you mentioned, one of its problems is that it has too much stuff already. Anything that "fixes" C++ isn't going to be C++ anymore, because it's going to have to get rid of a lot of stuff that's there. And at that point, why not model your new language off of one of the ones that is already far better than C++?
How do you make something that looks and works like a Windows application into something that looks and works like a Mac application (which has some distinctly different UI elements, like drawers and so on), with just a recompile?
Building a meta-toolkit front-end for several different, incompatible toolkits restricts you to supporting the lowest common denominator between them all, which probably means it will act poorly on them all. That was the problem with AWT. Swing tried to solve it by rolling its own GUI, which won't ever blend in as well as a native application.
Has SWT solved this? Will an SWT application work like a first-class Windows application on Windows, and a first-class cocoa application on Mac, and so on for Gnome and KDE? Will it automatically integrate wonderfully without any special work by the programmer?
Functional languages are neat, but most programmers are more comfortable designing a large system in an imperative, object-oriented language. Functional idioms can be rather unintuitive, even to those with decent CS educations.
Perhaps, but I think that's largely a problem of education rather than some intrinsic difficulty that functional languages possess. Most programmers are trained to use imperative, object-oriented languages from the get go, so switching to functional languages is a significant shift from everything they've learned before. However, I don't see why functional programming would be significantly more difficult if people learned it from the start.
In essence, such an argument reduces to something like, "everyone knows C++ now, so it's easier to keep using C++ like languages, so everyone will continue to know C++,...." I don't find that sort of argument a compelling reason why people should continue using C++.
Ocaml does have an object system, and you can write imperative code in it, so you could likely even write code that's rather similar to C++ in it, too, although that would not be the best way to solve most problems with it.
Haskell is written in Haskell; Lisp is written in Lisp; ML is written in ML; Et cetera.
Those are all better languages for writing compilers than C++, as well as being higher level languages (in fact, they're all higher level than C++). C++ is not a great language for compiler writing.
Oh, and incidentally, the Java compiler from Sun is written in Java, but I imagine you meant the virtual machine (which is probably written in C).:)
The vast majority of "modern" languages are not compiled to machine code.
No, the vast majority of modern mainstream languages aren't compiled to machine code. Haskell, ML, Ocaml, Lisp, Mercury, etc. all compile to machine code.
For the moment, C++ is a good balance between the efficiency of C and the user-friendliness of higher-level languages.
That may be true if you equate "higher-level languages" with "Java, C#, Perl and Python," but that's not even close to the full spectrum.
It fills a niche (resource-gobbling 3D games, operating systems, compatibility with C/C++ libraries, etc) that no other language does.
Almost any language can interface with C libraries, because they're the de facto standard.
Do you know of C++ being used in the kernels of any mainstream operating systems (or even many non-mainstream ones)? C is still king here, as far as I know, because when people write operating systems, they want to be as close to the metal as possible, and don't want all the abstraction that C++ provides.
Please explain why you couldn't write 3D games in, say, Ocaml.
So, after it takes them 10 years or more (according to the zlib site, it's been around since 1995) to iron out all the buffer overflows in their small library, they'll be glad they wrote it in C?
His point was that there are a lot of people in the US that don't freak out at that point. The Sopranos does have nudity, does it not?
I don't know which group is larger, but I do know which group you're going to hear: the one's that have a problem with nudity. They're the ones that are going to whine in a bunch of newspapers and television shows about the stuff. The people who are okay with it have no motivation to make a big stink every time it happens. So it's entirely possible that a minority of Americans are giving the rest a bad name (although I'm not optimistic enough to believe it is an actual minority).
Well, Sixteen Candles came out in 1984. According to this, PG-13 was invented that year, because people were upset with the rating Gremlins got (PG). So it's entirely possible that when Sixteen Candles was rated, PG-13 didn't exist, so the choices were R or PG. According to IMDB, it initially received an R, and then received PG on appeal, so that seems plausible.
Oh, and it's also an extremely violent game with heads and limbs being ripped off, just no human-on-human violence.
Dragging a cage with a Roman soldier in it up a hill to be sacrificed by burning him alive while he pleads for you not to kill him doesn't count as human-on-human violence?:)
And you missed one level of replies, in which the person below the original, long post seriously advocates doing what the person in the original is jokingly suggesting.
No, it's not irrelevant, because other people don't believe that everyone has a right to see the code, thus the GPL is necessary to protect that right of the people.
Personally, I like the GPL because it, as you say, forces companies to pay for your code with code. However, it also has a side effect of requiring more and more code to be licensed under the GPL. In that case, that code is also freely viewable and modifiable by everyone (as are the subsequent modifications), which is exactly what its intent is: to gain back/protect that freedom of the people with respect to all code, not just the code produced by the people who initially GPL their code. The BSD license most definitely fails to ensure this.
I'm sure if RMS could, he would dissolve copyright. The GPL simulates that as long as we still have copyright. The BSD doesn't. Is it your opinion that there would be more freedom with or without copyright?
The BSD license allows you more freedom of action.
The GPL protects more freedoms than the BSD license does.
By exercising the additional freedom that the BSD allows (that the GPL prevents), you take away the freedom of many other people.
The freedom of a company to co-opt a piece of software, make changes, and sell it as proprietary software is not necessarily more important than the right of people to see the code that they are using. The choice between those two things is what distinguishes the two licenses.
If there were no copyright, the GPL would be unnecessary, because there would be no incentive to keep the source secret. The GPL uses the copyright system to try and ensure as much code as possible is able to be seen by people.
So, as I said repeatedly, the GPL restricts one freedom to ensure another. Conversely, the BSD fails to protect one freedom in exchange for allowing another, the result of which probably has less net freedom for everybody (because more people can exercise the right to view the source than can differentiate the source and make money by selling it, based solely on factors other than licensing).
I don't know how I can present this any more clearly. While preventing an action that denies people freedom can itself be seen as a form of denying freedom, one has to look at which end is more important. As I said earlier, I could make your exact same argument about murder, the major difference is that most people see that as a black and white issue, rather than the shades of gray that is software licensing. The meta-argument is not compelling in itself; you need to look at what's actually going on underneath.
As an addendum: you said earlier that there is no inherent right of people to see the source they run. If that's true, then there is also no inherent right for people to take my open code without opening up their code. Nobody has any right to any code they don't write, except as the author chooses. So, the BSD isn't protecting any natural rights that the GPL isn't, if you take copyright law as your basis.
I'm sorry, I thought I said, "The GPL is more concerned with the freedom of everyone on the whole than it is with maximizing individual freedoms." The analogy was an illustration that the GPL is not the only document that does so (and, of course, a side effect that more unintelligent readers would say to themselves, "he's pro-murder!").
All analogies are flawed. That's why extrapolating from them alone is a logical fallacy. Your analogy is one where you expect "freedom" to be "freedom to do whatever you want" (on the code side, not the KKK side). That is not the freedom that the GPL protects.
The GPL protects the freedom of people to see the code for the software they're running. In fact, I'm relatively sure that RMS does, in fact, believe this is a pre-existing right that people have, so you're wrong on that account. The GPL is designed to chip away at proprietary software and eventually take back and protect this right of the people. Its intentions are very much like that of the constitution.
Now, in the last paragraph, you're dangerously close to collapsing the whole "more freedom" line of reasoning. In fact, the constitution doesn't ensure that people have "more" freedom. If we took away everyone's right to life, and replaced it with a right to murder, there would, clearly, be the same amount of freedom. However, you have to prioritize things, of course, and the right to life is more important than the right to kill.
RMS believes the right of people to see the code is more important than the right of a company to use the code however they want. People who follow the BSD believe the opposite. Of course, we don't have John Locke telling us what to think in this case, so it's a judgment call that each person has to make. However, your argument that "the BSD license is more free than the GPL" is flawed for this reason. Neither one is more free than the other; they're both free with different emphasis.
As far as benefit is concerned, I believe that it's (basically) always beneficial for people to have access to the source code for what they're running. You may, of course, disagree on this point, and it may be why you prefer the BSD license, but don't let that fool you into thinking that the BSD license is somehow "more free" than the GPL. That is not the case.
Yes, but there's more freedom and benefit in general if they can see and build off of your improvements, than if you kept your code to yourself. So the analogy stands.
Slashdot Mirror
You don't think there's any open source developers working on software usability?
I wouldn't recommend forming your opinion on anything based on what the majority of people on Slashdot say.
Was the "objective" of Linux ever world domination?
I thought it was a bunch of people working in their spare time (and more recently, for corporations) to produce a Free operating system that they would enjoy using/developing, and, in many cases, that other people would enjoy using as well.
Many people have some political agenda when they work on Free/Open Source Software. Many people don't. Asking "what is [Linux] trying to achieve," isn't a very well-defined question, because "Linux" is not a single sentient entity. It's a community of people with many different goals and ideas.
Some things in LaTeX are a little less structured than XHTML, I suppose. For instance, you delineate paragraphs with \paragraph at the beginning, but there's no closing tag. It's more of a "new paragraph begins here" marker (like people used to use in the old days of HTML).
Of course, that's just the default way to do it. You can make macros in LaTeX that will let you structure things almost any way you want.
All optimizations that can apply to higher level programming languages can apply to C++ too.
Can it? There are no techniques that optimize things in functional languages that C++ doesn't even deal with (lazy evaluation and garbage collection for example)? In addition, since, as you say, much more money and time has been put into optimizing C++, there may be optimizations that are in C++ that haven't been worked on for functional languages yet.
As for lisp/scheme they are a different paradigm... functional programming is inherently incomparable to a procedural language like C++.
You can write imperative code in scheme and lisp. They both have assignment, loops, and the ability to sequentially execute expressions.
I'm not sure what that was in relation to, though. All the languages I mentioned are primarily functional (although many people would argue that Common Lisp is a multi-paradigm language, like C++). Only Haskell is purely functional (since you can't do any imperative programming).
No, you're missing the point.
Suppose I have a widget toolkit X, that contains a widget foo, that every good X-based application uses.
I also have a widget toolkit Y, that has a widget bar, that's similarly included in all good Y-based applications.
X doesn't contain a direct analog to bar, and Y doesn't contain a direct analog to foo. In either case, you have to use a totally different widget, or combination of widgets in the opposite toolkit.
How do I make one meta-toolkit such that when I compile against a Y backend, it correctly uses bar in all the correct places, while against an X backend, it's done in some completely different way? And the same for foo. How is inheritance going to solve that?
How is inheritance and recompiling going to solve the difference between all sorts of different interface guidelines that differ from platform to platform?
What makes you think these languages will be significantly slower than C++? There are benchmarks out there that put Ocaml code on equal or better footing than C++. And people have been working on optimizing compilers for Lisp for a very long time.
Any gap will likely shrink in the future, too, as more work gets put into optimizing compilers for the more modern functional languages. By contrast, it seems unlikely that C++ will catch up as far as the simplicity factor is concerned, so saying that C++ will always be around for compilers seems inaccurate to me.
Qt is an autonomous toolkit, though. Qt is analogous to Swing or Cocoa. You can theme it to look like a Mac application, but it's not taking advantage of the native toolkit, so you won't get integration with the target system.
wxWidgets is more like SWT, in that it presents a uniform API that's implemented underneath by a native toolkit. So, you could make a Qt implementation of wxWidgets, and your wxWidgets app would look like a Qt app (that doesn't exist, although a GTK version does).
However, I'm skeptical that a wxWidgets application will fit in as well as anything written in the native toolkit itself. There's stuff in the Mac gui that isn't in GTK, and there's stuff that Qt/KDE can do that Gnome/GTK can't, and so on. I'm not sure I see how this can be reconciled by a library that has to provide a common interface to all of them.
The only thing I can come up with is some high level UI description language, where, for example, you say: "This is an accessory window for this other window," and the system automatically knows uses a drawer on OS X, and an extra top-level window on GTK or Qt, or something like that. But I'm not sure that's even feasible, and that really has nothing to do with the C++ standard library.
But, if I were proven wrong, I wouldn't be unhappy.
Heh, okay, then. What is a good example?
A few weeks back, I recall reading a thread on comp.lang.functional that had lots of argument about C++ (I think the thread is disguised by being called "Generic Programming and Functional Languages," if you care to look it up, though I could be wrong about it being that one; the C++ debate is buried several levels down in the thread). Naturally, the functional guys don't like C++ too much for many different reasons. However, there was an actual C++ language designer (I guess he's on the committee or something) there debating with them, so it turned into a nice flamewar. :)
:)
In short, the C++ guy argued that it was a pretty good language given all the constraints Bjarne had, including C compatibility and so on. Of course, the functional guys argued that no matter what the circumstances, that didn't make C++ an actual good language (and I agree). The history might explain why C++ is bad, but that's not an acceptable reason to use a bad language.
Now, the C++ guy seemed enamored with the idea that he could eventually "fix" C++ into a good language. However, one constraint he had was that it had to be compatible with C++ as it exists now. In other words, you're unlikely to ever see features removed from C++ to make it better; the only option is adding to it.
The people on the newsgroup argued (and I quite agree with them), that no matter how much you add to C++, it's not going to become "good." In fact, as you mentioned, one of its problems is that it has too much stuff already. Anything that "fixes" C++ isn't going to be C++ anymore, because it's going to have to get rid of a lot of stuff that's there. And at that point, why not model your new language off of one of the ones that is already far better than C++?
In short, I agree.
How do you make something that looks and works like a Windows application into something that looks and works like a Mac application (which has some distinctly different UI elements, like drawers and so on), with just a recompile?
Building a meta-toolkit front-end for several different, incompatible toolkits restricts you to supporting the lowest common denominator between them all, which probably means it will act poorly on them all. That was the problem with AWT. Swing tried to solve it by rolling its own GUI, which won't ever blend in as well as a native application.
Has SWT solved this? Will an SWT application work like a first-class Windows application on Windows, and a first-class cocoa application on Mac, and so on for Gnome and KDE? Will it automatically integrate wonderfully without any special work by the programmer?
Functional languages are neat, but most programmers are more comfortable designing a large system in an imperative, object-oriented language. Functional idioms can be rather unintuitive, even to those with decent CS educations.
...." I don't find that sort of argument a compelling reason why people should continue using C++.
Perhaps, but I think that's largely a problem of education rather than some intrinsic difficulty that functional languages possess. Most programmers are trained to use imperative, object-oriented languages from the get go, so switching to functional languages is a significant shift from everything they've learned before. However, I don't see why functional programming would be significantly more difficult if people learned it from the start.
In essence, such an argument reduces to something like, "everyone knows C++ now, so it's easier to keep using C++ like languages, so everyone will continue to know C++,
Ocaml does have an object system, and you can write imperative code in it, so you could likely even write code that's rather similar to C++ in it, too, although that would not be the best way to solve most problems with it.
Haskell is written in Haskell; Lisp is written in Lisp; ML is written in ML; Et cetera.
:)
Those are all better languages for writing compilers than C++, as well as being higher level languages (in fact, they're all higher level than C++). C++ is not a great language for compiler writing.
Oh, and incidentally, the Java compiler from Sun is written in Java, but I imagine you meant the virtual machine (which is probably written in C).
The vast majority of "modern" languages are not compiled to machine code.
No, the vast majority of modern mainstream languages aren't compiled to machine code. Haskell, ML, Ocaml, Lisp, Mercury, etc. all compile to machine code.
For the moment, C++ is a good balance between the efficiency of C and the user-friendliness of higher-level languages.
That may be true if you equate "higher-level languages" with "Java, C#, Perl and Python," but that's not even close to the full spectrum.
It fills a niche (resource-gobbling 3D games, operating systems, compatibility with C/C++ libraries, etc) that no other language does.
Almost any language can interface with C libraries, because they're the de facto standard.
Do you know of C++ being used in the kernels of any mainstream operating systems (or even many non-mainstream ones)? C is still king here, as far as I know, because when people write operating systems, they want to be as close to the metal as possible, and don't want all the abstraction that C++ provides.
Please explain why you couldn't write 3D games in, say, Ocaml.
So, after it takes them 10 years or more (according to the zlib site, it's been around since 1995) to iron out all the buffer overflows in their small library, they'll be glad they wrote it in C?
That sounds like a good time frame to you?
Yeah, you're right. Fuck that free speech bullshit! Satire has no place in a free society! Let's lynch them!
His point was that there are a lot of people in the US that don't freak out at that point. The Sopranos does have nudity, does it not?
I don't know which group is larger, but I do know which group you're going to hear: the one's that have a problem with nudity. They're the ones that are going to whine in a bunch of newspapers and television shows about the stuff. The people who are okay with it have no motivation to make a big stink every time it happens. So it's entirely possible that a minority of Americans are giving the rest a bad name (although I'm not optimistic enough to believe it is an actual minority).
Well, Sixteen Candles came out in 1984. According to this, PG-13 was invented that year, because people were upset with the rating Gremlins got (PG). So it's entirely possible that when Sixteen Candles was rated, PG-13 didn't exist, so the choices were R or PG. According to IMDB, it initially received an R, and then received PG on appeal, so that seems plausible.
Oh, and it's also an extremely violent game with heads and limbs being ripped off, just no human-on-human violence.
:)
Dragging a cage with a Roman soldier in it up a hill to be sacrificed by burning him alive while he pleads for you not to kill him doesn't count as human-on-human violence?
The uncensored version was AO.
And you missed one level of replies, in which the person below the original, long post seriously advocates doing what the person in the original is jokingly suggesting.
No, it's not irrelevant, because other people don't believe that everyone has a right to see the code, thus the GPL is necessary to protect that right of the people.
Personally, I like the GPL because it, as you say, forces companies to pay for your code with code. However, it also has a side effect of requiring more and more code to be licensed under the GPL. In that case, that code is also freely viewable and modifiable by everyone (as are the subsequent modifications), which is exactly what its intent is: to gain back/protect that freedom of the people with respect to all code, not just the code produced by the people who initially GPL their code. The BSD license most definitely fails to ensure this.
I'm sure if RMS could, he would dissolve copyright. The GPL simulates that as long as we still have copyright. The BSD doesn't. Is it your opinion that there would be more freedom with or without copyright?
The BSD license allows you more freedom of action.
The GPL protects more freedoms than the BSD license does.
By exercising the additional freedom that the BSD allows (that the GPL prevents), you take away the freedom of many other people.
The freedom of a company to co-opt a piece of software, make changes, and sell it as proprietary software is not necessarily more important than the right of people to see the code that they are using. The choice between those two things is what distinguishes the two licenses.
If there were no copyright, the GPL would be unnecessary, because there would be no incentive to keep the source secret. The GPL uses the copyright system to try and ensure as much code as possible is able to be seen by people.
So, as I said repeatedly, the GPL restricts one freedom to ensure another. Conversely, the BSD fails to protect one freedom in exchange for allowing another, the result of which probably has less net freedom for everybody (because more people can exercise the right to view the source than can differentiate the source and make money by selling it, based solely on factors other than licensing).
I don't know how I can present this any more clearly. While preventing an action that denies people freedom can itself be seen as a form of denying freedom, one has to look at which end is more important. As I said earlier, I could make your exact same argument about murder, the major difference is that most people see that as a black and white issue, rather than the shades of gray that is software licensing. The meta-argument is not compelling in itself; you need to look at what's actually going on underneath.
As an addendum: you said earlier that there is no inherent right of people to see the source they run. If that's true, then there is also no inherent right for people to take my open code without opening up their code. Nobody has any right to any code they don't write, except as the author chooses. So, the BSD isn't protecting any natural rights that the GPL isn't, if you take copyright law as your basis.
I'm sorry, I thought I said, "The GPL is more concerned with the freedom of everyone on the whole than it is with maximizing individual freedoms." The analogy was an illustration that the GPL is not the only document that does so (and, of course, a side effect that more unintelligent readers would say to themselves, "he's pro-murder!").
All analogies are flawed. That's why extrapolating from them alone is a logical fallacy. Your analogy is one where you expect "freedom" to be "freedom to do whatever you want" (on the code side, not the KKK side). That is not the freedom that the GPL protects.
The GPL protects the freedom of people to see the code for the software they're running. In fact, I'm relatively sure that RMS does, in fact, believe this is a pre-existing right that people have, so you're wrong on that account. The GPL is designed to chip away at proprietary software and eventually take back and protect this right of the people. Its intentions are very much like that of the constitution.
Now, in the last paragraph, you're dangerously close to collapsing the whole "more freedom" line of reasoning. In fact, the constitution doesn't ensure that people have "more" freedom. If we took away everyone's right to life, and replaced it with a right to murder, there would, clearly, be the same amount of freedom. However, you have to prioritize things, of course, and the right to life is more important than the right to kill.
RMS believes the right of people to see the code is more important than the right of a company to use the code however they want. People who follow the BSD believe the opposite. Of course, we don't have John Locke telling us what to think in this case, so it's a judgment call that each person has to make. However, your argument that "the BSD license is more free than the GPL" is flawed for this reason. Neither one is more free than the other; they're both free with different emphasis.
As far as benefit is concerned, I believe that it's (basically) always beneficial for people to have access to the source code for what they're running. You may, of course, disagree on this point, and it may be why you prefer the BSD license, but don't let that fool you into thinking that the BSD license is somehow "more free" than the GPL. That is not the case.
Yes, but there's more freedom and benefit in general if they can see and build off of your improvements, than if you kept your code to yourself. So the analogy stands.