Slashdot Log In
Linux 2.4 Wins 4th Place ... in Vaporware
Posted by
CmdrTaco
on Wed Dec 27, 2000 12:37 PM
from the wired-must-have-been-bored-today dept.
from the wired-must-have-been-bored-today dept.
An anonymous reader says: "Linux kernel 2.4 got itself at the 4th position in
Wired Vaporware 2000 contest!
The top prize goes to ... (check the link out for yrself ;)"
I have a hard time calling something Vapor that I've been running on 30 days uptime, but what do I know? I guess a "product" without a release date just isn't something comprehensible.
This discussion has been archived.
No new comments can be posted.
Linux 2.4 Wins 4th Place... in Vaporware
|
Log In/Create an Account
| Top
| 228 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
DVD player for Linux? (Score:3)
Re:architecture and long release cycles (Score:3)
Yes. Lend your support for a different opensource OS, such as Fluke or EROS. Get it running under VMWare and the rest of the hardware support picture can be done at a more leisurely pace. Linux isn't the only game in town.
--
Not so vapourware (Score:3)
Yes, Linus stated a lot of "soon, soon, soon..." and that's bad. I think that timelines should be more strictly stated and the process of kernel delivery made more simple and strightforward. Because many people are already working with 2.4 since the first "test" releases. Here 2.4 is widely used since test6 and that is a few monthes ago. A lot of people on the community are already using "test" tarballs for quite long.
Yes, many users don't feel the "benefits" of 2.4. But sorry people that's what Linux is all about - construction sets. I perfectly understand that some may not have the preparation to make a kernel upgrade or play with it. Unfortunately the difference between Windows and Linux is exactly on this. You build the system according to your needs and don't wait for the train to arrive to your station. You build the train and get off the station
Anyway, Linus is wrong by saying a lot of "soons". But even if he shot 2.4 in December, it would take 3-4 monthes to see it on the distros. And nearly half year to see it widespreading. So I would still put 2.4 in this vapourware list. Just to blame the way this kernel is being promised. But surely not in 4th place. Somewhere between 8th or 9th, maybe.
agreed but the point is (Score:3)
Why not just say "It'll be done when it's done" and leave it at that rather than pulling dates out of thin air that obviously mean nothing?
up and running? (Score:3)
and .NET (Score:3)
infinitely more vaporous than most of the top 10, including OSX, which has been in beta for a while...
of course, .NET will be out there, RSN
tagline
What about Team Fortress 2? (Score:3)
Don't get me started on Daikatana.
------------
CitizenC
Linus said December (Score:3)
My vote goes to... (Score:3)
Going on means going far
Going far means returning
Re:and .NET (Score:3)
infinitely more vaporous than most of the top 10, including OSX, which has been in beta for a while...
Prefer something that works the first time (Score:3)
One list of 2.4 issues is available here [sourceforge.net], for the curious.
architecture and long release cycles (Score:3)
The architecture of the current Linux kernel served it well over the first few years of its existence: it allowed a lot of features and reasonable performance to be implemented quickly. But it may not serve as well in the current environment.
Can we solve this problem? Maybe one of the open source microkernels, or maybe the use of some other programming language for the kernel that couples different parts of the kernel less tightly and isolates the kernel from problems in individual modules would help. Or maybe it will be possible to move there incrementally, without starting from scratch.
What about... (Score:4)
Re:Vaporware? Not likely (Score:4)
Half Right about 2.4 (Score:4)
2) But if you are using their definition of vaporware as just software that was expected out by now, then the 2.4 kernel does earn a spot.
It is easy to second guess the actions of great men (Linus Torvalds and company) but far harder to be worthy of their respect. And yet I critisize anyway
When Linus Torvalds blessed the beginning of the 2.3 developement cycle, he said he wanted MUCH SHORTER developement cycles with "9 months being about right". Nine months came and went and he started saying he expected to see it done by xx/xx/xxxx date while in the mean time, he kept accepting neat new features/rewrites to the kernel causing more delays.
Now if Linus had not talked publicly about "shorter developement cycles" and "hope to get it out before
If Linus had just said something to the press like this:
"I really don't know when to expect the next kernel out. We are perfectionist and when a new kernel is released, we want to be proud to have our names attached to it... We think that the 2.2 kernel is a very good kernel and we hope that for those few who could really use the new features in 2.3, that we can provide them as soon as we know how."
With variations of a response like that, people would never be able to claim 2.4 is late. Now on the mailing list, Linus's speaches about getting 2.3 ready ASAP, was/is resonable and any reporter who writes about stuff from the kernel mailing list should be lynched.
BTW: From reading LKML, I think the kernel developers have done an exceptional job with the 2.4 kernel and it is really something to look forward to.
These articles are bad (Score:5)
And Apple's OSX - they aren't done either. Tribes 2 is full of bugs, and it isn't done. I hope companies don't listen/read these. I'm happy to wait for a finished product. Release it when it's done, not when it's due.
The actual release isn't what makes it Vapor. (Score:5)
Duane
Re:These articles are bad (Score:5)
While it is indeed unreasonable to expect that products will ship exactly on announced dates, and that pressuring people to do so might result in the release of still-buggy code, I think there's room for more discipline than is in fact being exhibited by the Linux kernel gurus. Scheduling software projects is not totally a black art. People experienced in a particular kind of programming can often come up with remarkably good estimates of how long things will take, how much extra time to allow for bugs that fall out during testing, etc. Nobody's perfect, but it is entirely possible to come up with a date whose percentage probability of being met is in the high nineties.
Why doesn't this happen in Linux? Two reasons: optimism and lack of discipline. There's no significant penalty for missing a date in open source, so there's no incentive to be pessimistic. When people aren't afraid of the consequences for a date being wrong, they'll usually give you a "best guess" - 51% confidence - date. People who hold themselves to a higher standard of diligence might give you a 90% number, but the project as a whole invariably ends up delayed by the people who couldn't be bothered coming up with a solid number when the project started.
Lack of discipline bites us in several ways:
All of this adds up to create an extremely unpredictable development environment. It's only because of hard work and raw talent that Linux kernel release dates aren't ten times more of a joke than Microsoft's have ever been. With talent and work and just a tiny bit of engineering discipline, we could do a hell of a lot better than we're doing wrt release dates.
Vaporware? Not likely (Score:5)
By that standard, Linux 2.4.x and Mac OS X are certainly not vaporware. Even
I mean, it's not like the 2.4 test kernels are hidden from the world, only mentioned in glowy press releases and described as the Second Coming of MS.
Wired: Will Troll For Hits
Discount (Score:5)
Oh, wait . .