Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
It's funny.  Laugh.

Kernel Pool Is Back For 2.6 87

Manuka writes: "Win Fabulous Prizes and the recognition of your peers! (well, OK, maybe not the latter). As it's become somewhat of a tradition, is now taking bets for the release date of the next production Linux kernel. Congratulations to Bill Wendling who won the pool for 2.4." Hey waitaminute, I don't even have a Slashdot shirt, never mind a VA Polo -- where do you get these?! Of course, Linus has promised a shortening release cycle, so bet accordingly.
This discussion has been archived. No new comments can be posted.

Kernel Pool Is Back For 2.6

Comments Filter:
  • Well, you could bug Rob.. I work for GameSpy, and I have tons of stuff .. hats (not limited to GameSpy -- I have Half Life, etc) shirts, mouse pads.. I'm sure that CmdrTaco has a similar stash. (OF CLOTHES! Don't think about dirty stuff.)

  • January 13, 2002
  • Hell, just to get everyone on the same page, I think the next releases should be numbered as follows...
    Kernal 8.0.0
    Apache 8.0.0
    KDE 8.0.0
    Gnome 8.0.0
    GCC 8.0.0
    Glibc 8.0.0
    XFree86 8.0.0
    RPM 8.0.0
    OpenOffice 8.0.0
    KOffice 8.0.0

    I'm sure I missed a lot of programs. Just number the next release of anything 8.0.0 to be sure.
    Digital Wokan
    I wanted to spend 8 years defending the US constitution.
  • by Fervent ( 178271 ) on Sunday January 07, 2001 @05:22PM (#524482)
    I don't think time_t even supports the year I'm thinking of.
  • The one thing I want to see between now and 2.6/3.0 is ReiserFS replacing ext2. From what I've seen so far, ReiserFS is much better than ext3 will be. I don't know much about Tux2, but it seems to me that everything Tux2 offers is already being shown by ReiserFS. I do know that ReiserFS has great performance and Tux2 would have to do a lot to outdo it. I say screw compatibility with ext2. I can always backup and reinstall or copy my files to a new partition. If ext3 or Tux2 ends up being the standard just because its easy to convert your partition to them I'll be really pissed off.

    "Homo sum: humani nil a me alienum puto"
    (I am a man: nothing human is alien to me)

  • "With one exception, every prime number is odd"

    "2 is an even prime number"

    I'm wondering what that exception could be...

    Okay... I'll do the stupid things first, then you shy people follow.

  • If ext3 or Tux2 ends up being the standard just because its easy to convert your partition to them I'll be really pissed off.

    Who cares what "the standard" turns out to be? You can run reiserfs all you like either way.

  • 2.5 is particularly interesting...

    Perhaps Linus is not against odd numbers; he is actually against square numbers. If you drop the "." (which will subsequently cause havoc on the internet, as thousands of people try to access "http://slashorg"), it becomes 25, which is 5^2.

    Wait, that's it! Linus must hate the idea of 2.5 because it is 5 -- an odd number -- squared.

  • GNU/Linus should start releasing the kernel with numbers behind it with his prediction of when it will be released... GNU/Linux2038 btw, I wouldn't wear a VA shirt if it was the last shirt on earth! Hey, what the hell happened to that stupid Slashdot Troll Wagon they were giving away at LWE?
  • Is that Alan and Linus???? Holy ShiT!!!!!!!!
  • by Prizm ( 52977 )
    I disagree. The problem with this is, many of the distributions come out at different times. This can cause mass confusion and purchasing errors. Say the kernel is behind Redhat or Slackware's distributions, many may buy the distribution assuming it has the kernel of the same number, but in reality it won't. I just feel it's more confusing to have similar numbers, especially to new linux users who may be confused by "Redhat version 7.6, kernel 7.4, GCC version 7.6, etc." Too many similar numbers in my opinion.
  • Users aren't stupid.

    You've never worked tech support, have you? :)

    1st Law Of Networking: Loose ends are bad, termination is good.

  • I expect ext2 will be around for quite some time, and will remain the default on installs for some time.

    I don't. I'm expecting that ext3 will be the default filesystem for any install. It's backwards-compatible (old kernels can mount ext3 filesystems as ext2), and eliminates fsck.

  • So DON'T READ IT. Or better yet, start your own website and post higher quality stories that relate to your interests. Regardless, you have no right to whine and complain unless you plan on doing something about it.
  • A Google search for the phrase "Finnish Love Machine" finds one match.
  • I think the point was more rather than rewriting several major parts of the kernel for one release, why not let 2.4 rewrite one major system, then 2.6 rewrite the next, etc. And of course get updated drivers and other nice things along the way. Say 2.4 was released a year ago with all the nice hardware support improvements (USB, card services, PCI changes, anything else I missed), and then 2.6 came out now with all the memory management rewrites? I don't see a downside to that. I never heard complaints about memory management before, but plenty of people wanted USB. So why not cut back on the scale of each release? Targetting for roughly yearly releases sounds reasonable to me.
  • What's "featuredon"? Ha ha ha, kill me, I'm funny. Seriously, I'm towards the idea that the next version will be 3.0, and it will be "released" "sometime next year". I'm pretty exact, eh?
  • If these trends continue, I'd probably expect to see the next kernel on February 31st, 2001. ;)

    There are no 31st in February. Where are you getting at?

  • Even though delayed, isn't it already on a shortening release cycle? IIRC, there was a little over 2 1/2 years between 2.0 and 2.2 and there was just under 2 years between 2.2 and 2.4. So its not a huge improvement, but still technically, an improvement.
  • by Pflipp ( 130638 )
    I don'I don't know much about Tux2, but it seems to me that everything Tux2 offers is already being shown by ReiserFS.

    Ow, c'mon. At least you forgot the coolness factor. Tux2 is a "whole new technology", it has to face a patent to a similar system that is probably invalid or at least not applicable to Tux2 (because Tux2's predecessors itself form the prior art), it doesn't have to journal so it comes per definition with less overhead, and it introduces all kind of fluffy terms. Plus it didn't take all kinds of flames to get into the darned kernel (sorry Hans, I know emotions can run high on mailinlists sometimes).

    I mean, comparing Tux2 to ReiserFS is like comparing Linux to BSD. They may both validly work in practice, but Linux seems to be the more sexy and to have the buzzword factor.

    It's... It's...
  • You're calling the Linux *kernel* GNU/ Linux? That's plain filthy, you RMS! There's no GNU code in that thing (yes, it's GPLed, but no part of the GNU project)! And GNU/ Linus? What's that supposed to mean? Were his parents hippies?

    Instead, we might rather talk about Linux/ HURD when referring to the HURD by now...


    It's... It's...
  • Why not do it like Micros~1? I can see it now:

    Linux 2000 release delayed until early 2001....
  • your truely evil. I laughed so loud the the security guard from down the hall came to see what was so funny.
  • I believe the linux kernel should go up to 11.
  • by Ig0r ( 154739 )
    Most of the hardcore gamers I know would/have take(n) the time to learn how to do things in Linux because they aren't worried about screwing up things. They are fairly compitent about hardware and software interactions, and wouldn't be too thrown off by different methods of doing things in alternate OS's.

  • It will probally be 3.0, if 1.2->2.0 is any indication...
    Also, in the Linus interview linked earlier, he mentions that its premature to be talking about 2.5/3.0, indicating that the next release will likely be 3.0, and thus not really a part of the newer/quicker kernel series.
  • ipchains -I input 1 -p tcp -s 80 -d -j REJECT
  • by Nailer ( 69468 ) on Sunday January 07, 2001 @05:50PM (#524507)
    Releasing less incremental updates makes it easier on users, developers and distributors, in that if they need a feature like, for example, a new VM, they can just blanketly tell users they need Linux 2.4. If the new VM was released for 2.2, you'd have to require people to have a 2.2.27 kernel or newer. That doesn't sound too difficult, but it soon becomes a major headache. `I have 2.2.26 and it doesn't work for me'. Remember, most current Linux users don't match the profile of most future Linux users.

    As it is now, bleedign edge folk can get incremental updates via odd kernels.

    A new release neatly bundles all those incremental changes. 2.4 is a known quantity. A minor release isn't, becuase nobody can afford to keep track of the incremental updates in each release. If a user needs DVD support for my game, I tell them to get 2.4. I could tell them to get a 2.2.50 if it had those features, but better to break everything in their distribution at one time rather than cause many small annoying issues. Eg, since their 2.2.7 distro didn't create /dev/dvd, despite the fact they have DVD support in their new 2.2.50, my app might fail if it was looking for /dev/dvd [which it should be].
  • by Anonymous Coward
    That's because it's in your cache. You got any roommates?


  • /. on Kernel Pool 2.2 [] (1998! yah!)
  • This is the kind of reasoning we need if we are ever going to catchup to windows. if it takes a year or so to increment by .2 then it will take 10000 years to get anywhere near 2000.
  • Of course, Linus has promised a shortening release cycle, so bet accordingly.

    Oh really? Is this like the time he said that in 1999 about 2.4? Not bashing or anything, I think Linus should release when he thinks it's ready, I'm just saying that you might want to bet on it (ha ha).

    It just means you should add a year to whatever you bet is. (Or to whatever Linus announces as the expected release date)

  • Early on in the 2.4 kernel pool, I got e-mail from somone who insisted that the next version would be a new *.0, and cited the 1.2 to 2.0. Of course, now it's easy to criticize. ;-)

    If the next release is 69.0, the entries in the kernel pool will be applied to it -- the exact version of the next stable kernel isn't important.

  • by Throw Away Account ( 240185 ) on Sunday January 07, 2001 @07:29PM (#524513)
    The standard file system shouldn't be dictated by the kernel at all. The current ext2isms in the kernel vfs code should be hunted down and eliminated, but not replaced by Reiserisms. Let the distros and users decide which fs they want to use; the kernel should be completely fs neutral.
  • That the release date shall occur upon the arrival of the next service pack for a Windows operating system
  • Shortly after the release of 2.2, Linus was saying that the development cycle for 2.3 WOULD be very short, and we should be looking for it to be released in around 8 months.

    So I placed a vote for around then. My ranking when all was said and done was around 1,100 out of 1,400.

    It'd be nice if it were shorter this time, but I wouldn't bet the farm on it.

  • Or perhaps "an Itanium plated Box"...

  • by b3kZ ( 192674 )
  • You probably could make it work by using serial monitors, and redirecting virt terminals to the serial ports....
  • The problem here is that changes to one subsystem often require changes to another subsystem. Very few channges happen totally in isolation.

    Another issue to consider is the constant advancement in hardware. One reason for changes at the memory management level was the the existing system was inefficient when run on large memory machines. Your mechanism will lead to stagnation in the development tree. Commercial distributions will ignore this, releasing patched kernels with source that hasn't been fully audited, leading to stability problems.

  • Journalling (ie writing all metadata twice) is silly.

    We need soft-updates (or phase-trees, whatever).

  • The kernel should be FS independent, for a very simple reason - different systems have different needs. Some might need maximum integrity. Others could sacrifice SOME integrity if they could get a significantly better throughput. As professionals, we should have the option to choose. Otherwise, we might as well run NT!

    Anyhow - I thought the entire opensource philosophy was that there's more than one way to do it?
  • Didn't ANYBODY watch that show on last night about World Sports Exchange? Basically, three guys founded an online sports gambling startup, in Antigua, just to be safe. Now the US gov considers them criminals on the run from the law!
  • the last interveiw i read with linus said that he was going to think for a bit before releasing the next kernel version. he may be planning to jump straight to version 3.0 next. it seems a touch unlikely to me at least, but who gets the prizes if that happens??

    this is a touch sarcastic...


    Drink more tea []
  • January 5th 2005
  • by Foxman98 ( 37487 ) on Sunday January 07, 2001 @03:31PM (#524525) Homepage
    I'm betting on two weeks after the next time it's featuredon the vaporware list.... ;-)
  • I can always backup and reinstall or copy my files to a new partition.

    Good for you. My server is located an hour from my house (and work), so getting over there to to the backup/format/restore shuffle is an annoying whole day event. ext3/tux2 lets me upgrade w/ a quick file edit and a reboot (all from remote). (one of these days, I'll convince myself to get a PC Weasel so I can try out new kernels as well...)

    As for the "standard" business, I think pretty much everyone else summed it up. The kernel shouldn't care what FS is running, that's the VFS' job. I really hope that ext2 hard-codes have been removed from the rest of the kernel if they were there at all.

    The current "standard" *is* ext2, because it's the FS that is available everywhere. I would think that ext3/tux2 becomes the next standard for compatibility reasons. However, nothing will stop you from using any of the other fses available (even included with the kernel), including reiserfs. It's like now, with a different set of file systems available.

  • Better not tell you now...

    I say July 2, 2002
  • by be-fan ( 61476 ) on Monday January 08, 2001 @01:30PM (#524528)
    I don't think so. First, the hardware drivers should be entirely independant of the kernel. I'd really like to see drivers forked as independant projects with strong ties to the kernel developers. Second, you don't really point out *how* these developments are interrelated. As far as I can see, USB has nothing to do with the new VM. The news filesystems such as ReiserFS and the like have little to do with other kernel components other than the VFS (thought, technically, the VFS should require no changes for new filesystems...) agpgart is totally unrelated to the VM, as is DRI, etc. Starting to get the idea? While it may be true that changing one subsystem requires changes to other subsystems, it is not true that they require *major* changes at the same time. If the kernel was upgraded incrementally, then the resulting product would not only be easier to support (less stuff to break) but the transition would be easier. I remember that upgrading from 2.0 to 2.2 was a huge pain (I had to change distros) because so much stuff had changed. 2.4 will be a similarly big leap, and I can't help wondering how people will handle the 3.0 jump. Recently on BeDevTalk (the BeOS mailing list) there was some talk of what would happen if Be had to break binary compatibility (to move to GCC 3.0, if they ever do it.) There was also talk what would happen if changes to the InterfaceKit (the UI API) needed a break in binary compatiblity. Somebody (me) suggested lumping all of these breaks together. Of course I was (rightfully) chastised by a developer who pointed out that such major changes should be handled gradually, and it would be insane to make developers deal with both a new binary standard and a new API.
  • Ok this is a stetch, But I really think Linux should make the marketing move to 7.0 or even go form 2.4 to 7.6 instead of 2.6 that way it is inline with the variosu distrobutions who are all on 7.0-7.2. I know Slackware got in trouble with this and yea some peopel have problems with it, but ITwould make it far less confusing for the majority of people who are now switching to linux, getting DISTROBUTION X at 7.0 andwonderign why the kernel is only 2.4
  • we should put the vaporware list on the vaporware list. It has not been delivered to spec, and I doubt it will ever will be. Plus it would be full of recursive sillyness :)

  • I like the split. Lets you know if the newbies are talking about their distribution or their kernel without asking. Easier to support, and you don't have to make them feel bad when they get the two confused.
  • Perhaps it's just me, but I'd prefer only a slightly shorter release cycle (maybe..1 1/2 years between major versions). This is because I believe it's more efficient to have a few large releases instead of a bunch of them - there's a slower, more complete time to handle bug fixes, and not as much release-preparation done by the developers. Then again a kernel is not as bad as your traditional shrink-wrapped product in terms of marketing, packaging, etc.. but there's still some degree of last-minute preparation that's done. Maybe someone with more experience in how the kernel is released could share their opinion.

  • Check here []. I can't find a link to the VA Linux shirt, although I'm almost positive I saw one there ..

  • Couldn't certain people be in a position to rig this thing? I mean, there are the obvious ones, the few people who directly control the code, but couldn't tactics be used by other contributors to delay the kernel?
    "You just stranded one of the world's greatest leaders in San Dimas!"
  • A titanium plated Tux!
  • (and if I was Linus Torvalds, ala "Being Linus Torvalds" in which I stumble in a portal somewhere in San Jose which lets you see and feel everything Linus does, then pick up conveniently single pretty Maximum Linux columnists* ... )

    I would make the date November 20th [].

    * Hey, just joking about that part! :) * also, this would not technically be cheating on Mrs. Torvalds, since it would really be me inside the Finnish Love Machine**.
    ** I don't think anyone has ever put the words "Love," "Machine" and "Finnish" in that particular order before, certainly not in this context.

  • If these trends continue, I'd probably expect to see the next kernel on February 31st, 2001. ;)
  • by slothbait ( 2922 ) on Sunday January 07, 2001 @06:13PM (#524538)
    > The one thing I want to see between now and 2.6/3.0 is ReiserFS replacing ext2

    It sounds likely that ReiserFS will make it into the kernel sometime 2.4.x, perhaps early in the lifecycle. And once one journalling filesystem goes in, the rest will come rather quickly. Quite a bit of the difficulty has been in introducing journalling features into the VFS layer. This is code that will be reused for every journalling-style filesystem implemented.

    Also, once ReiserFS becomes stable, it will not necessarily replace ext2fs. I expect ext2 will be around for quite some time, and will remain the default on installs for some time.

  • by goingware ( 85213 ) on Sunday January 07, 2001 @06:27PM (#524539) Homepage
    The kind folks at SunSITE Denmark [] are helping me out with my proposal to make testing new Linux kernels more widespread and effective with the Linux Quality Database at:

    So far it's just a proposal. In the short term there will be resources on testing strategies, as well as tips on writing quality code. I the long run will come a nice web form for reporting bugs in a way that will be especially meaningful for kernel developers (capturing and searching hardware configuration and kernel config options).

    Michael D. Crawford
    GoingWare Inc

  • That might be a concern if major prizes were being awarded. However, with all due respect to Open Sound System and tummy, I can't imagine any of the people in charge of the kernel rigging the date just to win this pool. Particularly since, if they are in a position to do this (Linus, Alan Cox, etc) I'm sure they could all just request free copies of what the prizes are anyway.
  • My bet is:

    January 18th, 2038

    I sure hope everybody has a 64 bit time_t by then...
    Slashdot didn't accept your submission? [] will!

  • Has anybody got some information on which new features are primarily being worked on in Kernel 2.6? Not only could this help in an estimation of the final date, but also I'm just plain curious =)

  • I'm not placing my bet until I see what the feature list for the next releases is going to be - let alone what the bug situation with 2.4.0 is!

    Think about it - 3.0 could technically arrive next week, if they REALLY wanted it to!


  • If the past can give any indication as to the future numbering, it will be 2.5, not 2.9. The devel. version numbers from 1.2 to 2.0 were numbered 1.3.x.
  • There are no 31st in February. Where are you getting at?

    Umm... that was the joke..

    Arrrr, forget it :)
  • Maybe all of the distributions should move their version back to 2.4 to match the kernel.
  • Or, we'll have a bunch of 2.5.x kernels, then 2.99.x, then 3.0.0-testx, then 3.0.0-prerelease, and then 3.0.0.
  • &nbsp &nbsp &nbsp The real question is what improvements are necesary. I see people coming up with arbitrary figures such as "there should be a new release every 18 months," when the real issue is "what changes will be made and how long will they take"
    &nbsp &nbsp &nbsp The only people who need to follow any given time-frame are companies who want to keep profits rolling in in steady proprtions
  • by Nerds ( 126684 ) on Sunday January 07, 2001 @03:45PM (#524549) Homepage
    Of course, Linus has promised a shortening release cycle, so bet accordingly.

    Oh really? Is this like the time he said that in 1999 [] about 2.4? Not bashing or anything, I think Linus should release when he thinks it's ready, I'm just saying that you might want to bet on it (ha ha).
  • by grammar nazi ( 197303 ) on Sunday January 07, 2001 @03:47PM (#524550) Journal
    It's number discrimination! Linus is discriminating against odd tenths of a number.

    Sure they lack factors of 2, but they are still numbers. With one exception, every prime number is odd and prime numbers are important. Does Linus Torvals hate prime numbers?

    This 'even-numbered' favoritism is surely a sign of some deeply rooted hatred and fear.

  • Well, you may be right, and (separate issue) Linus may agree;)

    I hope not, though -- the conservative version numbering system so far employed has demonstrated restraint and non-craven humility ... the diff. between 2.2 and 2.4 in terms of features (can't speak for performance personally yet, but all I hear is good so far :) ) is really amazing, and that's refreshing. It's craft, pride of workmanship and engineering over marketing, a rare triumph!

    Now it might make sense, as some have suggested, to go straight to 3.0 from here -- ok, that I could live with, it's at least the next integer in line, and "three point oh" does have a nice ring to it. But to take the slackware leap would be ultimately futile -- if Linus calls the next kernel "Linux 7.0" then some distro will busily repackage all their disks with that kernel until they are called "Official DistroName Linux 8.5!"

    Maybe some distro (Debian leaps out, for version-numbering reasons) should introduce a 3rd version number or add a letter.

    And a conversation like this one could happen:

    "Hey, whatcha runnin' there?"
    "Debian 2.6"
    "Yeah? 2.6.b?"
    "No, .c -- that usb problem was cleared up, and now it's got XFree 4.5 by default."

    Just a thought,

  • by supine ( 94843 ) on Sunday January 07, 2001 @04:58PM (#524552) Homepage
    Lotteries are a tax on people who can't do math.

    Does this mean this pool is a tax on people who haven't read "Mythical Man Month"...


    PS: yeah, i know you don't pay to enter, go along with the joke...
  • Do you really think it matters? Users aren't stupid. Most people can figure out that a higher versioned software isn't necessarily better. People have been doing this with model years and TV model names for years, the computer industry isn't so f*cking 'leet that people can't figure out revisioning. (there are exceptions, but you have idiots who use gearshits to hold handbags too.) The problem with Linux isn't the fact that the kernel and the distro have two seperate numbers (it really isn't an issue, MS has had seperate version numbers for DirectX and Windows or Word and Windows for a long time) but the fact that people aren't really clear on what "Linux" is. If the distro makers would stop calling their products "Linux" or somebody would change the name of the kernel to something else, then it wouldn't be confusing. In the end, it really doesn't make a rat's @ss of a difference. People shouldn't really care what kernel version is in there anyway. (For those 'leet users, not having the low-level system info shoved in your face doesn't make you any less 'leet. It just means you have to dig around in /proc from now on.) The kernel is just another part of a well organized, coherent whole that is the LinuxOS. (Yea right...)
  • ...but ITwould make it far less confusing for the majority of people who are now switching to linux...

    Not to mention far less useful to those who have been using it all along. I mean, WTF is so hard about the kernel being just a part of the overall package??

  • I am sick and tired of everyone saying, "We should do X, so newbies won't have to learn Y". I am happy if people want to use GNU/Linux, but if it means having to dumb down everything, then what is the point anymore?

    So why do you call it "GNU/Linux". Wasn't RMS's excuse that he wants newbies to know about GNU? So isn't calling is "GNU/Linux" really "dumbing down" the name so that newbies won't have to spend some time using Linux so they can find out for themselves that some of the command line utils and libc are GNU?
  • not true, 2 is an even prime number
  • by be-fan ( 61476 ) on Sunday January 07, 2001 @05:04PM (#524557)
    I'd beg to differ. If, instead of huge, long in coding major releases, the kernel had shorter, more succinct releases. then progress would be faster (less stuff to test for each release) and the product would be higher quality (less stuff that could break for each release.) When you write a major program, you don't code major subsystems at one time do you? Of course not. You code the thing incrementally. For example, if you wanted to change the VM, you change the VM and release a minor release. That's what .x releases are for. Major, structure changing releases (which 2.4 is) should increment the major version number (x.0) Of course, IANAKE (I am not a kernel engineer) so take this with a grain of salt ;)
  • No, don't you know that the kernel releases are coordinated with Debian releases?

    The next release will be approximately 3-4 months after the next Debian is out which includes 2.4. :p

  • then will the devel kernel be called 2.5 or 2.9?

    I could probably look up what happened last time...
  • also, this would not technically be cheating on Mrs. Torvalds, since it would really be me inside the Finnish Love Machine**.
    ** I don't think anyone has ever put the words "Love," "Machine" and "Finnish" in that particular order before, certainly not in this context.

    A quick Google search shows prior use: []

  • On the console or in X? it's already available in X (it's called xinerama or something like that).
    The kernel supports 2 cards just fine, it just happens to only display stuff using one of them. =)
  • What about emacs then?
    They're whey beyond 8.0.0 ...
  • Now see what happens when a stable version of Linux comes out.
  • It will probably be 3.0, if 1.2 -> 2.0 is any indication...

    Is that part of the pool too? I think it should be included: what version you think it will be, and what release date you think it will be.
  • No (Yes?), I do know where and how to get a Slashdot one and eventually would like to, and may even end up with a VA Polo eventually, but I think corporate polos require a better procurement channel than simple T-shirts, so I just wonder where they got theirs ;)

    that's all ;)


Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling