How do you know they are bad? Or do you claim that every ambitious design is inherently bad? (Maybe we should stick with DOS -- after all it is so SIMPLE, so little effort to implement it...)
> in my experience, both in Bell Labs and elsewhere, anyone with experience on > "real" unixes thinks the GNU tools are second-rate at best.
Your experience seems quite one-sided... Or how do you explain that lots of people are using the GNU tools on "real" Unices? (And did so long before Linux became popular, so you can't even claim it's only because they are used to them from GNU/Linux.)
> at least the BSD folks, who got many things wrong in their own derivative > works, understood the fundamental philosophy (mostly) of Unix.
Quite a bold claim, considering that they put that whole socket business in there, which was about the first thing to be ditched in Plan9...
> HURD does, at least, have some interesting ideas in it. of course, most of > them got there because Plan 9 [bell-labs.com] had them, wasn't open source, > and RMS wanted access to them.
History proves you wrong. The fundamental Hurd design was created at about the same time Plan9 started; they were developed independently in parallel.
Considering this, there are some striking similarities, as you seem to have noticed. This can be interpreted as a reconfirmation for both projects, that the ideas aren't that absurd. It can also be interpreted as a proof that the Hurd folks have understood the original Unix philosophy better than you want to make us believe...
But there are considerable differences between the two as well: For one, the Hurd folks looked for ways to overcome the limitations of Unix *without* breaking compatibility. Also, they chose a much more ambitious internal architecture. (Owed to different goals of the projects, different focus.)
Actually, it's rather the opposite. The Hurd was (following the model of the
other, much simpler GNU tools) originally developed by a small closed team of
"wizards". Which is really the reason why it came along so slowly. You know
Eric Raymond's famous Cathedral and Bazaar paper? I don't know whether it is
really true, or maybe he only said it out of spite; but once he claimed that
(while different examples are mentioned in the paper), the Hurd was what
actually had inspired him to write this paper -- the archetype of a mismanaged
free software project, so to say. The Hurd didn't become a success by part
precisely because it was *not* as open as Linux and many other large free
software projects.
Only later (after the original team stopped working on it fulltime and no
replacement was looked for as the project had no priority anymore) the project
opend up, and since then it's (slowly) bettering IMHO.
> The PC didn't win because it was more "open." It won because it was cheaper > than the $2000+ priced Macintosh, fueled by commodity PC-clones (remember the > phrase "PC-compatible"?) that competed with each other and brought prices > down each year.
It was cheaper precisely *because* the openness allowed for clones bringing down the prices. So that's really the same thing:-) And it's very similar with GNU/Linux...
You are completely wrong about that. Actually, the *software* is the driving force...
Face it: It's always wanting to have the newest software that forces you to upgrade the hardware as well. You can't just upgrade your software every six months, and than let your higly paid employees sit around in idle loops while the overaged computer is having his hard time trying to cope with that. (Actually, such an attitude can be found in some small companies... Which is probably the reason they are small.) And Hardware costs are usally less then 10% of the IT budget, anyways.
The problem is that software vendors are *expecting* you to upgrade hardware regularily. It's somewhat better in the free software world, but not generally: Think of KDE and Mozilla...
I used to have a quite old software system (dated 1999) on my much older PC (1997 or so), with only the most important programs updated, and it was ok -- there were a few things painfully slow of course, but generally I never felt a strong desire to change the hardware. Recently I have upgraded to a new system, with 2.4 kernel and xfree 4.1 and all, and now I will have to buy a new PC...
Of course, you can't keep using old software forever. At the end, I really had quite a bit of trouble with the old system. (Not because it was lacking functionality in itself, but because of compatibility issues...)
The only thing you can do as the customer is not rushing out and getting the newest software just because it is available, but to consider each upgrade thoroughly.
That doesn't explain why not releasing the source just now. Poeple wanting more features could fork it (actually, not very likely...); and people following your approach may still be "useful". Where is the Problem?
If you are doing it only for yourself, why releasing it at all?
They do *not* have full support. There is no really working fbdev Driver for Nvidia; I guess the same is true for GGI. Because they neither have Open Source drivers, nor even release specs.
Moveover, the Nvidia driver used to crash the whole system, for a long time. That's the benefit of having propriatary shit in the Kernel. Thanks.
That's my reason not to buy Nvidia.
I wished there were more people caring about these things -- than maybe they'd realize they are doing wrong...
Surely people would switch to free software immediately, if they couldn't get pirated versions for home use anymore.
But that's not what BSA trying to achieve. (They are assholes, but they are not stupid!) What they try to do is persuading as many people as they can to pay for the software they are using anyways...
Moreover, they are pushing laws (like the DMCA) which actively hinder free software developement. Thus, they are certainly *not* helping us, in any regard.
First of all: When people suggest something that is against your "mission", what's wrong with that? If poeple prefer other solutions, than it usally means that these solutions are better to them; they result in a more useful program for the public. And that's what free software is all about after all, isn't it?
Others have mentioned it already: First try to examine whether it's not actually best to reconsider your "mission"...
When being open and accepting contributions that deviate from your ideas, you may loose some influence on the direction your project takes. When denying contributions, your project may get forked and loose its uniqueness. We can't tell you which way to go; it's up to you to decide which is your priority.
However, don't be scared of forks too much. They are quite seldom, and only if the project already *has* gotten some popularity.
If it actually happens, that shouldn't bother you too much. Maybe the fork gets a direction so unlike to yours that it can't be really considered competition. In any case, it doesn't hinder you to go on and head for your own goals.
And if your "mission" turns out to be a better way to go at last, people will stick to it, or return. A fork can only overtake you if it actually turns out to have the better vision in the long run...
Slashdot Mirror
Nobody cared to fix it, because it wasn't really a practical problem until quite recently... The developers focused on more immediate problems.
Wrong. GNU tools were quite popular among Unix users before Linux even existed.
How do you know they are bad? Or do you claim that every ambitious design is inherently bad? (Maybe we should stick with DOS -- after all it is so SIMPLE, so little effort to implement it...)
> in my experience, both in Bell Labs and elsewhere, anyone with experience on
> "real" unixes thinks the GNU tools are second-rate at best.
Your experience seems quite one-sided... Or how do you explain that lots of
people are using the GNU tools on "real" Unices? (And did so long before Linux
became popular, so you can't even claim it's only because they are used to them
from GNU/Linux.)
> at least the BSD folks, who got many things wrong in their own derivative
> works, understood the fundamental philosophy (mostly) of Unix.
Quite a bold claim, considering that they put that whole socket business in
there, which was about the first thing to be ditched in Plan9...
> HURD does, at least, have some interesting ideas in it. of course, most of
> them got there because Plan 9 [bell-labs.com] had them, wasn't open source,
> and RMS wanted access to them.
History proves you wrong. The fundamental Hurd design was created at about the
same time Plan9 started; they were developed independently in parallel.
Considering this, there are some striking similarities, as you seem to have
noticed. This can be interpreted as a reconfirmation for both projects, that
the ideas aren't that absurd. It can also be interpreted as a proof that the
Hurd folks have understood the original Unix philosophy better than you want to
make us believe...
But there are considerable differences between the two as well: For one, the
Hurd folks looked for ways to overcome the limitations of Unix *without*
breaking compatibility. Also, they chose a much more ambitious internal
architecture. (Owed to different goals of the projects, different focus.)
Actually, it's rather the opposite. The Hurd was (following the model of the other, much simpler GNU tools) originally developed by a small closed team of "wizards". Which is really the reason why it came along so slowly. You know Eric Raymond's famous Cathedral and Bazaar paper? I don't know whether it is really true, or maybe he only said it out of spite; but once he claimed that (while different examples are mentioned in the paper), the Hurd was what actually had inspired him to write this paper -- the archetype of a mismanaged free software project, so to say. The Hurd didn't become a success by part precisely because it was *not* as open as Linux and many other large free software projects. Only later (after the original team stopped working on it fulltime and no replacement was looked for as the project had no priority anymore) the project opend up, and since then it's (slowly) bettering IMHO.
> The PC didn't win because it was more "open." It won because it was cheaper
:-) And it's very similar with
> than the $2000+ priced Macintosh, fueled by commodity PC-clones (remember the
> phrase "PC-compatible"?) that competed with each other and brought prices
> down each year.
It was cheaper precisely *because* the openness allowed for clones bringing
down the prices. So that's really the same thing
GNU/Linux...
X succeeded against NeWS, because X was free and NeWS wasn't. Kind of repeating story, isn't it? ;-)
You are completely wrong about that. Actually, the *software* is the driving force...
Face it: It's always wanting to have the newest software that forces you to upgrade the hardware as well. You can't just upgrade your software every six months, and than let your higly paid employees sit around in idle loops while the overaged computer is having his hard time trying to cope with that. (Actually, such an attitude can be found in some small companies... Which is probably the reason they are small.) And Hardware costs are usally less then 10% of the IT budget, anyways.
The problem is that software vendors are *expecting* you to upgrade hardware regularily. It's somewhat better in the free software world, but not generally: Think of KDE and Mozilla...
I used to have a quite old software system (dated 1999) on my much older PC (1997 or so), with only the most important programs updated, and it was ok -- there were a few things painfully slow of course, but generally I never felt a strong desire to change the hardware. Recently I have upgraded to a new system, with 2.4 kernel and xfree 4.1 and all, and now I will have to buy a new PC...
Of course, you can't keep using old software forever. At the end, I really had quite a bit of trouble with the old system. (Not because it was lacking functionality in itself, but because of compatibility issues...)
The only thing you can do as the customer is not rushing out and getting the newest software just because it is available, but to consider each upgrade thoroughly.
That doesn't explain why not releasing the source just now. Poeple wanting more features could fork it (actually, not very likely...); and people following your approach may still be "useful". Where is the Problem?
If you are doing it only for yourself, why releasing it at all?
They do *not* have full support. There is no really working fbdev Driver for Nvidia; I guess the same is true for GGI. Because they neither have Open Source drivers, nor even release specs.
Moveover, the Nvidia driver used to crash the whole system, for a long time. That's the benefit of having propriatary shit in the Kernel. Thanks.
That's my reason not to buy Nvidia.
I wished there were more people caring about these things -- than maybe they'd realize they are doing wrong...
Actually, they even explicitly state that they may do so. It's in the usage terms.
Surely people would switch to free software immediately, if they couldn't get pirated versions for home use anymore. But that's not what BSA trying to achieve. (They are assholes, but they are not stupid!) What they try to do is persuading as many people as they can to pay for the software they are using anyways... Moreover, they are pushing laws (like the DMCA) which actively hinder free software developement. Thus, they are certainly *not* helping us, in any regard.
Oh, wait a minute... Isn't that just what GNUChess does? :-)
First of all: When people suggest something that is against your "mission", what's wrong with that? If poeple prefer other solutions, than it usally means that these solutions are better to them; they result in a more useful program for the public. And that's what free software is all about after all, isn't it?
Others have mentioned it already: First try to examine whether it's not actually best to reconsider your "mission"...
When being open and accepting contributions that deviate from your ideas, you may loose some influence on the direction your project takes. When denying contributions, your project may get forked and loose its uniqueness. We can't tell you which way to go; it's up to you to decide which is your priority.
However, don't be scared of forks too much. They are quite seldom, and only if the project already *has* gotten some popularity.
If it actually happens, that shouldn't bother you too much. Maybe the fork gets a direction so unlike to yours that it can't be really considered competition. In any case, it doesn't hinder you to go on and head for your own goals.
And if your "mission" turns out to be a better way to go at last, people will stick to it, or return. A fork can only overtake you if it actually turns out to have the better vision in the long run...
Ever heard of a guy named ESR? "Release early, release often" -- the mantra of sucessful Free Software developement. Proved times and again.
The problem is that people will immediately run away when they see such a note.