![GNU is Not Unix GNU is Not Unix](http://a.fsdn.com/sd/topics/gnu_64.png)
![Software Software](http://a.fsdn.com/sd/topics/software_64.png)
![It's funny. Laugh. It's funny. Laugh.](http://a.fsdn.com/sd/topics/humor_64.png)
![Linux Linux](http://a.fsdn.com/sd/topics/linux_64.png)
Guessing Linux 2.6.0 Release Date 313
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?"
My guess (Score:4, Funny)
Re:My guess (Score:5, Insightful)
I think that gif is a nice hack. So lay off those "too much time on your hand" stuff..
however, I must ask myself - do hacks have to be necessarily of some utility? I mean, Zen would say "it will be out when it will be out".
hnh. My guess.... (Score:3)
Maybe (Score:4, Funny)
Re:My guess (Score:2)
So try not to criticize how others decide to use their time, unless you're paying them for it.
Re:My guess (Score:2)
http://hypertextbook.com/facts/1999/JennyChen.s
Support the Protest Against Patents... (Score:5, Insightful)
I would urge the
demonstration, unless they really don't care about open-source software at all.
Re:Support the Protest Against Patents... (Score:2, Insightful)
Re:Support the Protest Against Patents... (Score:2, Insightful)
Re:Support the Protest Against Patents... (Score:2, Insightful)
People would like slashdot to join this demonstartion because they perceive slashdot in their own way but it cannot be 'all ways'.
Slashdot is a name and thats all it has to it, its mechanism is under the GPL and not patented, it already is fragmenting for several reasons.
Good thing slashcode is not patented e
Re:Support the Protest Against Patents... (Score:2)
Re:Support the Protest Against Patents... (Score:3, Insightful)
Re:Support the Protest Against Patents... (Score:2, Informative)
Mainstream media like statistics. If important sites like Slashdot join the protest, they can safely add some more thousand affected users to the stats, and the protest becomes more important in the eyes of the public - thus, more important to the politician.
Re:Support the Protest Against Patents... (Score:3, Funny)
Your comment is far too logical, rational, realistic, and practical for any of the nerd androids to comprehend.
SO true Seahawk, and I'm glad you pointed it out- honestly 90% of this slashcrap is masturbation, it is a byproduct of creative minds, geek-droppings, if you will, that aren't going to cease excreting.
Personally, if they continue to crank out useful products like apache and linux, who cares if they wank here all day- just don't rattle their cages too much.
Re:Support the Protest Against Patents... (Score:2, Insightful)
Today is an important day for demonstrations here in Europe. If we manage to minimize the damage caused by software patents legislation (ideally cancelling their approval), software freedom (and our personal freedom btw) will be much safer.
Slashdot, close your operation, shutdown -h NOW!
Tomorrow you can resume normal activity, and rejoice by talking about how proper your behavior was.
/etc/init.d/apache stop (Score:2)
Re:Support the Protest Against Patents... (Score:2)
Tomorrow you can resume normal activity, and rejoice by talking about how proper your behavior was.
Yes, because we all know it's the only moral and correct thing to do. And it makes so much sense to protest in a manner that makes your act of protesting completely unknowable on the one day people care about it.
Geez, get your own website.
Re:Support the Protest Against Patents... (Score:2, Insightful)
Re:Support the Protest Against Patents... (Score:2, Insightful)
Simple logic...
Re:Support the Protest Against Patents... (Score:2)
Sorry but I have patented... (Score:2, Funny)
Not gonna happen, here's why (Score:3, Insightful)
Re:Support the Protest Against Patents... (Score:2, Funny)
Re:Support the Protest Against Patents... (Score:2)
Slashdot is primarily a forum, not a news agency. Slashdot doesn't even report on the news: its users do. So I think that that's a perfectly reasonable conclusion that should be expected, given the tendency of people to disagree on most things.
Just my $0.02. Feel free to disagree if you'd like.
May be a good businessmodel? (Score:4, Funny)
1) Do free stuff.
2) ?
3) Call your local bookeeper and gamble on kernel 2.6.0 release-date.
4) Profit!
My guess... (Score:5, Insightful)
Yeah, but (Score:4, Funny)
Daikatana wasn't exactly the hit everyone was salivating over...
Re:My guess... (Score:3, Funny)
I'm going to guess that it will be released about three revs before then.
Stable version? (Score:4, Insightful)
Re:Stable version? (Score:3, Informative)
Re:Stable version? (Score:4, Insightful)
Unfortunately 2.4.0 was "pretty stable" too, but until 2.4.18 reiserfs and block devices bugs caused many cases of data corruption, which costed to my firm quite a good amount of work and money.
Maybe I'm much too conservative on this, but I think that whichever software (expecially a kernel!) should not be considered "Stable" until the absence of crashes and data corruption has been thoroughly stress-tested. Sorry, but "it' been up for some days on some PC" is just not enough.
Flamebait? Maybe. But I really don't like the current attitude toward kernel versioning:
maybe it compiles -> devel
compiles (quite) and seems to work -> stable
no more serious bugs -> end of life, occasional maintanance
I think it shoud be:
maybe it compiles -> don't even release
seems to work -> unstable
no more serious bugs -> stable, thorough maintenance to squash last few bugs.
"End Of Life" of a stable version shoud happen only when a newer one goes stable. Waiting months to see the security breach on 2.4.20 corrected while no other stable kernel were around should happen NO MORE.
Forcing users to test new kernels by cheating on version numbers it's not a way to gain testers, but rather to loose many of them, after their data gets eaten...
Re:Stable version? (Score:2)
Re:Stable version? (Score:2)
You can get the updated module-init-tools at:
ftp.kernel.org/pub/linux/kernel/people/rusty/modu l es [kernel.org]
The latest is module-init-tools-0.9.14-pre1.tar.bz2
Re:Stable version? (Score:2)
[dave@bend ~]# uname -a
Linux bend.local.davenjudy.org 2.6.0-test4 #1 SMP Sat Aug 23 10:15:04 MDT 2003 i686 athlon i386 GNU/Linux
[dave@bend ~]# uptime
10:31:57 up 3 days, 22:02, 9 users, load average: 0.06, 0.01, 0.00
and much more responsive than 2.4. I'm at work right now so this system is basically idle but it gets hammered when I'm at home.
Sure it compiles. (Score:5, Insightful)
Re:Sure it compiles. (Score:2)
Re:Sure it compiles. (Score:2)
Re:Sure it compiles. (Score:2, Interesting)
(and assuming morton will be the 2.6 maintainer)
05/12/03 10:49PM 17,511 must-fix-1.txt
05/12/03 10:50PM 19,024 must-fix-2.txt
05/14/03 02:33AM 23,417 must-fix-3.txt
05/15/03 12:38AM 27,594 must-fix-4.txt
05/21/03 05:32PM 28,070 must-fix-4a.txt
05/21/03 09:59PM 30,821 must-fix-5.txt
05/30/03 11:35PM 15,294 must-fix-6.txt
05/30/03 11:35PM 19,045 should-fix-6.txt
The must fix list is not stable at all over time. It grew so big h
Re:Sure it compiles. (Score:2)
I wont be testing it until allmods compiles; anything less is a complete waste of my time. I'll report bugs, but I'm not going to modify the kernel, just so I can run a buggy kernel and be told that I put the bugs in there. I have enough instability on my machine.
Joe
Best fit? (Score:3, Insightful)
Anyway, interesting stuff
November, 30th (Score:5, Insightful)
Re:November, 30th (Score:4, Funny)
Re:November, 30th (Score:2, Funny)
It always takes longer than you expect, even when taking Hofstadters law into account.
He states it in his book "Godel, Escher, Bach" (a good read if you can wrap your mind around it).
Re:November, 30th (Score:2)
Whatever.
Re:November, 30th (Score:3, Funny)
So if it "should take 6 weeks", the anwser to give to your boss would be 12 months.
beta testers (Score:2, Interesting)
Re:beta testers (Score:2)
Re:beta testers (Score:5, Insightful)
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 [osdl.org]. 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
Re:beta testers (Score:2)
Some resources:
Re:beta testers (Score:4, Informative)
Since when (Score:5, Insightful)
since ADA (Score:3, Informative)
Re:since ADA (Score:2)
Re:since ADA (Score:2)
Re:since ADA (Score:2)
If you did mean ADA was that?
Air Defense Artillery
Americans with Disabilities Act.
Aint Dat Assonine?
Art Deco Association
An Ada version of the linux kernel would be cool, but you loose a few of the neat features (like tasks and
Not the end in and of itself (Score:3)
All measurements of this kind have inaccuracies. Do you have a better one? If so, then let's hear it.
Re:Since when (Score:2)
Re:Since when (Score:2)
A lot of the things which differ between 2.4 and 2.6 with respect to drivers are the APIs of some important things they depend on. The new APIs are less error-prone. This suggests that a driver will work correctly if it worked before and has been updated, and it won't compile otherwise.
Drivers don't get updated until the interfaces are stable and the kernel otherwise works well enough for the people who maintain those
Re:Since when (Score:2)
July 13 (Score:5, Insightful)
What are you waiting for?
Re:July 13 (Score:2, Informative)
Re:July 13 (Score:2)
Re:July 13 (Score:2)
Re:July 13 (Score:2)
Should have been a poll (Score:5, Insightful)
My guess (Score:2, Funny)
CowboyNeal.
I don't want to read about Linux 2.6! (Score:2, Funny)
LaLaLa (Score:5, Funny)
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)
Re:LaLaLa (Score:5, Funny)
Which presumably happens when the bug count wraps around from 2^31 to -2^31+1 then up to zero...
Maybe this is the basis for Microsoft release schedules?
Re:LaLaLa (Score:2)
Re:LaLaLa (Score:2)
Thus, it's obviously the basis for the HURD's release schedule.
Re:LaLaLa (Score:3, Funny)
Which is why they don't have a 64-bit Windows released yet, not enough bugs to overflow 2^63
Here's your problem (Score:2)
(Repeate until BUGS == 0)
('=' is an assignment operator, '==' is a comparison operator)
or:
while (BUGS > 0): sing(...)
Obligatory Linus Quote (Score:3, Funny)
So now we're guessing the release date based on when it will compile without errors, eh?
Wrong question (Score:5, Insightful)
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.
Re:Wrong question (Score:5, Insightful)
Debian Unstable currently has 2.6.0-test kernels available.
Your complaint, which is perhaps mildly legitimate, is that Debian Woody (current "stable") was released with the standard default vanilla kernel as a 2.2 kernel.
In fact it had plenty of choices there for people who wanted to run 2.4 kernels - they just weren't the default standard vanilla choice.
Really: just what you want for a stable server-oriented environment.
Re:Wrong question (Score:2)
Re:Wrong question (Score:2)
This makes me smile.
Not that it's not too much of an strech.
I'm running several gentoo boxen, all with at least 2.6.0-test3-mm1 or higher.
It's pretty damn good, but there is always room for improvement.
Re:Wrong question (Score:4, Interesting)
Actually it's highly relevant. People (myself included to some extent) don't like running alpha/beta kernels on their everyday machines unless they have nothing of value if it all screws up. I'm sure I'll get the usual reassurances that -test1 "works fine for me" etc. but the point still stands.
Now I think it's close enough to release that I'll give it a spin myself as it has some drivers I want, but then I'm capable of building and configuring the kernel. A vast number of people are not capable or inclined to do that and are waiting for their favourite dists to ship with it.
Which comes to the second point. No distribution, be it Red Hat, Suse or even Mandrake is going to ship with a beta kernel by default. They're all waiting for 2.6.0 to be stamped and labelled, and possibly have a few more patches on top again before they'll bet the bank on it. Even if that means delaying their release, or having a 'backup plan' to ship a dual 2.4.x / 2.6.x system with support for the new kernel coming in the form of patches when it's ready. And believe me, 2.6.0 offers some extremely sexy stuff that dists and end users would dearly like, e.g. ALSA sound instead of the shitty OSS for one, but all kinds of improvements including general responsiveness tweaks. But only when its officially ready.
So the new kernel getting to 2.6.0 (and deserving that moniker because it is now production quality) is extremely relevant to lots of people. That doesn't stop people from diving in when they feel comfortable, but the tidal wave is not going to happen until 2.6.0 goes final.
Re:Wrong question (Score:2)
I'm not sure where you would even get a beta kernel. The X.Y.Z releases, where Y is odd denotes a development kernel. I've used development kernels in production for 2 servers before because I actually needed the features (extra file descriptors) that the 2.1.125 (IIRC) kernel had to offer, and had no problems.
Ironically, most ( >95% ) of the patches, exploits, problems with all of the above distros
Re:Wrong question (Score:2)
emerge mm-sources
I don't exactly remember whether I'd set ACCEPT_KEYWORD to ~x86(unstable) but given that ALL the mm-sources packages currently in portage are 2.6, I'd say it's a safe bet that it doesn't particularly matter. The point is, when it comes times to move to a new package, that time usually comes faster with Gentoo. If I really wanted, I could install a 2.2 kernel on my Gentoo box, but that doesn't make the system as a whole any less bleeding edge.
still some big issues (Score:3, Informative)
Easy one (Score:3, Funny)
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!")
Hofstadters law (Score:3, Insightful)
"Everything takes longer than you expect, even when you take into account Hofstadters law."
Douglas Hofstadter, "Godel, Esher, Bach", ISBN: 0465026567
The more interesting question is: (Score:2, Interesting)
How much influence has SCO on the developers, e.g. make them response to the SCO FUD instead of fixing bugs in the kernel? That's also a sort of "denial of service" attack.
Re:The more interesting question is: (Score:2)
Call me optimistic but... (Score:2, Insightful)
And other archs maybe would have to wait some minor versions?
Considering this and the graph predictions, my guess is 3-4th week of September.
December 9th, 2003 (Score:2)
It really sucked last year when my 21st birthday was also on the Monday of exams week. OSU's present to me? The toughest exam (EE) I've had there yet, at 7:30am nonetheless. But don't worry, after that, the rest of the week was a blur.
It Will Be Released (Score:2)
2.6.0-test* seems solid enough for daily use, although if you have a laptop with a Synaptics touchpad, there seem to be some problems with the driver for that (I've not been able to get mine recognized but I prefer the USB mouse anyway.)
2.6.10? (Score:2)
Based on the 2.4 experience with the memory mapper changing horses well after 2.4.0, I'd be careful making predictions.
Also, Linus is now full time at OSDL (+).
Also, Alan will be going back to school (-). Good for him, though.
I'll go out on a limb, though, and say
which is evidently [buyusa.gov] Finnish Independence Day.Pool anyone? (Score:2)
Performance testing (Score:2)
October 15th (Score:2)
What's the prize? (Score:3, Funny)
Never mind this! (Score:2)
When it is done (Score:2)
NumDays = NumOpenBugs/(bugsClosed-bugsOpend)*time period
Very simple, and suprisingly effective for large projects where the bug finding and bug closing rate is very close to constant over a period of time (lets say a week)
So basically this says, that as long as your bug openning rate is higher than your bug closing rate, don't even bother predicting a
Re:Question (Score:2, Informative)
'still' would mean that it did in earlier versions. This has not been proven, and based on all of the information we have seen (as in code presented in that PowerPoint slideshow) does not lead to the conclusion that the 2.4 kernel contains any code that is 'owned' by SCO.
Re:Gifs are bad! (Score:3, Informative)
Re:Gifs are bad! (Score:2, Informative)
Re:who checks in code that compiles with warnings? (Score:2, Insightful)