Slashdot Mirror
Guessing Linux 2.6.0 Release Date
thorgil writes "Guessing about the linux-2.6.0 release date is hard, but here is a new angle (pseudo-scientific): I made a graph (gif) based on errors/warnings from John Cherry's (OSDL) compile statistics for linus' linux bitkeeper tree.
My guess is around 12th October, 2003. What is your guess and more important, why?"
is that you have way too much free time on your hands.
It's ironic that slashdot would run a story about linux today at all. But what really surprises me is that Slashdot would continue operation today, even though they allegedly support the Online Demonstration Against Software Patents.
/. staff to immediately shut down operations and support the
I would urge the
demonstration, unless they really don't care about open-source software at all.
Maybe a great open source businessmodel?
1) Do free stuff.
2) ?
3) Call your local bookeeper and gamble on kernel 2.6.0 release-date.
4) Profit!
To quote a famous game developer: "When it's done."
The question that really count is when will the first stable version of 2.6.x be out. I mean 2.6.35 or such...
But I don't think the "it compiles, let's ship it" is the criteria for releasing 2.6.0 A better way is to look at Andrew Mortons must-fix list. When most items are fixes, it can be released. ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/ must-fix/must-fix-6.txt
Should it be a linear best-fit? I'd be guessing that the number of errors/warnings will only approach zero? Much like tracking bugs.. On second thoughts, errors will more than likely hit zero but warnings we can live with.. :)
Anyway, interesting stuff
Oct, 12th is in about 6 weeks. So, because every IT project takes twice as long as you think, my guess is around Nov, 30th.
....Excuse me, but
Since when do compile time errors and warnings reaching zero mean that there no more bugs in a program? Most bugs are those the compiler doesnt complain about.
What are you waiting for?
This should have been a poll. Now, it just leads to endless ramblings.
PROGRAMMERS DRINKING SONG:
...
99 little bugs in the code,
99 bugs in the code,
fix one bug, compile it again,
101 little bugs in the code.
101 little bugs in the code
(Repeat until BUGS = 0)
!
Ummm, the Kernel Bug Tracker as previously discussed here?
You are being MICROattacked, from various angles, in a SOFT manner.
When the kernel itself is declared "released" is irrelevant to most people. If you really want the latest and greated, you can always download whatever the current version is, whatever it's called, and use it.
What's important is when most distro companies (other than bleedinge edge Gentoo and "we don't need no steenking 2.x kernels" Debian) will start building their distributions around 2.6-final instead of 2.4. For that, it's quite obvious at this point: The spring refresh cycle. (The fall cycle may have a few optional pre-release kernels, but the real action will be the spring.) Sometime in the April timeframe we'll see Red Had, Mandrake, and SuSE releasing 2.6-based versions. Hopefully they'll also have funness like KDE 3.2 and so on by then, which are just as important to most people.
When Linus says "ok, I'm done, let's work on something else" isn't important. When Red Hat says "we'll give you a support contract on this now", THAT'S important.
--GrouchoMarx
Card-carrying member of the EFF, FSF, and ACLU. Are you?
Maybe I do... Oh wait... Yeah I do...
Warning: This sig contains a small bug. ==> *
Do some searching around (linux-kernel mailing list archives, the bugzilla for linux-kernel) and try to work out whether it has already been reported.
Ensure that you can reproduce the problem on the latest kernel.
If the bug has only just appeared, it is very useful for the developers to know which kernel version it appeared in. The best way to find this out is to do a binary search between the working and non-working kernel versions.
If it has been reported, you might be able to contact the relevant maintainer (check the bug details or the MAINTAINERS file for details) and get a "possible fix" patch to try out.
If it hasn't been reported, I guess the best way to report it is to use the bugzilla. Please read and follow the advice there for how to report a bug, but again common sense applies.
Depending on the bug and your level of interest and ability, it can be really fun to try and work out a fix yourself.
(Sometime you can do this even if you aren't a great coder
e.g. Once I couldn't mount a CD and had a kernel message error about a 2k block size. I knew nothing about the driver, but grepped for the message, found it was bracketed by a "is it 1k or 4k" test. Simply adding 2k as another option to the "if" test and recompiling/rebooting allowed the CD to mount. That ruled.)
If you do produce your own fix, sending it to the relevant maintainer as a suggested change may be helpful, but please don't be upset if your fix isn't used. There are many reasons (some good, some bad) why something which works for someone isn't a good thing in general. (If you do send a patch, use 'diff -u oldfile.c newfile.c' to generate the patch file)).
Good luck
I don't think it will happen during the next 6 weeks, there are still some major things to be done. IDE still does not work as module (some circular dependencies in symbols), ISDN is still somewhere between the no longer working old model and the not yet complete CAPI support, just to name two.
"When it's done." I think this is a good "guess" for two reasons:
a) it's 100% accurate.
b) It didn't cost me precious hours of my life to come up with this answer.
I'll now continue to invest my time in more important stuff...like reading slashdot.
(Hey! They say it's "Stuff that matters!")
But then again, gifs and pngs are still better for line art. chunking the image into 8x8 blocks doesn't make sense for charts and low color images. In these scenarios, it's better to just use gif/png.
Hofstadters law:
"Everything takes longer than you expect, even when you take into account Hofstadters law."
Douglas Hofstadter, "Godel, Esher, Bach", ISBN: 0465026567
Not that I think it's the greatest language or anything, but my experience with ADA was that vastly more stupid things that programmers (in this case me) do show up as compile time errors. Almost to the point where if a program compiled it was bug free. Of course it's still possible to have a logical errors, but whole classes of what would be run time errors in C are compile time errors when ADA is properly used with things like range checking.
To quote a famous game developer: "When it's done."
Daikatana wasn't exactly the hit everyone was salivating over...
You can accomplish anything you set your mind to. The impossible just takes a little longer.
So, does the person who guesses closest receive a free copy of the 2.6 kernel?