Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Linux Kernel 3.0? 369

Posted by CmdrTaco from the cuz-2.x-is-just-stale-now dept.
An anonymous reader writes "A discussion on the Linux kernel mailing list between Linux creator Linus Torvalds, Linux guru Ingo Molnar, and a few others debated the name of the upcoming stable kernel release. The choices: 2.6 or 3.0. Evidently there's been enough improvements, most notably the VM, that they're leaning towards calling it 3.0..."
This discussion has been archived. No new comments can be posted.

Linux Kernel 3.0? More

Linux Kernel 3.0?

Comments Filter:

  • Consumer Marketing (Score:4, Funny)

    by brad3378 ( 155304 ) on Sunday September 29, 2002 @09:29AM (#4353537)
    To a consumer, 3.0 sounds like a better product than 2.6

    My vote would be to make it Linux 10.0 to make it compatible with the SuSe & mandrake number systems. :-)

    • Re:Consumer Marketing (Score:4, Insightful)

      by no soup for you ( 607826 ) <.jesse.wolgamott. .at. .gmail.com.> on Sunday September 29, 2002 @09:45AM (#4353593) Homepage
      To a consumer, 3.0 sounds like a better product than 2.6
      My vote would be to make it Linux 10.0 to make it compatible with the SuSe & mandrake number systems. :-)
      In my opinion a consumer will never notice the kernel version number. They'll see the distribution version numbers, but won't bother to check which kernel the system is using -- because to do so would mean they'd have to understand that a kernel existed in the first place.

      • Re:Consumer Marketing (Score:2, Interesting)

        by TecraMan ( 12354 )
        In my opinion a consumer will never notice the kernel version number.

        Yeah, but you wouldn't believe the amount of IT managers who would. 3.0 could seriously help divorce Linux from some of the FUD that's been spread about 2.0, 2.2 and 2.4.

        DS

    • Consumer marketing is irrelevant to the kernel (Score:4, Insightful)

      by BluBrick ( 1924 ) <blubrick@nOSpaM.gmail.com> on Sunday September 29, 2002 @10:11AM (#4353669) Homepage
      To a consumer, 3.0 sounds like a better product than 2.6

      The Linux kernel alone is not a consumer product.

      By itself, it is not very useful, but when you bundle it with a couple of hundred other utilities, applications and environments and call it a distribution, the distribution becomes a consumer product. When you strip it bare and embed it into a device, the device becomes a consumer product. When you load it onto a general purpose computer and call it an appliance, the appliance becomes a consumer product.

      When it comes to the kernel, there is no need for consumer level marketing trickery.

    • Sheesh, you're new to the entire concept marketing, aren't you? Only a geek would suggest "Linux 3.0". "Linux 10.0" is just as bad, but at least it expresses a recognition of reality. There is a real world out there and the name of a product defines that product, makes it sexy!

      Release it on January 1st 2003 and call it Linux 2004.

      Now THAT'S marketing!

      -
      • Release it on January 1st 2003 and call it Linux 2004.

        so that's why the marketing folks always have to have a floor all on their own :). it's a kernel not a distribution. RH GNU/Linux 2004 would be good (from a marketing perspective), but linux 2004? that's like ms renaming their kernel32.dll to windowsXPkernel32.dll. you know so when the message pops up that there's an error in windowsXPkernel32.dll, you really know what product you're using. then again, the marketing folks at ms probably see this message too and wouldn't want to give the user any more firepower.

    • Linux XP (Score:3, Funny)

      by 0x0d0a ( 568518 )
      If you really want marketing.

  • And then.... (Score:5, Funny)

    by WilliamsDA ( 567274 ) <derkNO@SPAMderk.org> on Sunday September 29, 2002 @09:29AM (#4353540) Homepage
    on to 3.11! Oops!

  • Why not use Microsoft's versioning system? (Score:5, Funny)

    by Tsar ( 536185 ) on Sunday September 29, 2002 @09:33AM (#4353551) Homepage Journal
    • 3.1 = Universal Beta
    • 4.0 = First stable release
    • 5.0 = Last stable release
    • XP = DRM-crip^H^H^H^Hdifferently-abled release

  • It's all marketing (Score:3, Insightful)

    by SexyKellyOsbourne ( 606860 ) on Sunday September 29, 2002 @09:36AM (#4353563) Journal
    Though some of the improvements may have been a real boost (the O(1) scheduler, etc), the decision to call it "3.0" won't come until some serious marketing decisions are made.

    Linux is not an underground system anymore -- it is a competitor in a business market and means billions of dollars to people and businesses, as unsuccessful [yahoo.com] as they may be.

    Calling the kernel 3.0 is just a name, a marketing strategy, that will give the idea to people who aren't in the know that something truly significant and revolutionary has happened.

    There's clearly a war going on between the idealists and the realists in that mailing list, and a simple number like "3.0" can make or break millions of dollars.
    • Calling the kernel 3.0 is just a name, a marketing strategy, that will give the idea to people who aren't in the know that something truly significant and revolutionary has happened.

      Actually, those people are already given warm fuzzies by the distribution version numbers. Non-geeks really wouldn't pay attention to the kernel version number, doubly so since it wouldn't have any _visible_ impact on the system's behavior.
    • I don't really agree.

      First of all, most people (that care about Linux marketing) are only interested in the names of the distributions. How many times have I heard "Where can I download Linux 7.2" or "Linux 8.1". Most have no idea what the difference is between the distribution and the kernel.

      Second, those that are paying attention to kernel versions are not likely to give two shits what the numbers are. 2.6 is going to be the same as 3.0 for me. Just another version.

      Finally, I haven't run anything in 2.5 yet. I don't see any major reason to upgrade to it... Sure the VM is supposedly better, there are other enhacements, but nothing that would make me consider this a major leap (if I am not about to upgrade to it, what's to say that it is revolutionary, and believe me, I am into bleeding edge.)
      • I don't know. New driver model, kernel preemption (big one!), new block device layer, reworked VM. I think that deserves a 3.0. Those kinds of changes would have Micro$oft jacking the version up to XXX-P.
    • It might also make them think, ug... a dot-zero release... I'll wait until 3.1 when they've fixed all the bugs.

      Where as 2.6 sounds like the most stable of the version 2 kernels yet.

      Why not do a Sun job, and call the next version 6.

  • As Shakespeare said (more or less) (Score:5, Funny)

    by rknop ( 240417 ) on Sunday September 29, 2002 @09:38AM (#4353570) Homepage
    A rose by any other name would still have thorns.

  • Testing 2.5 (Score:5, Interesting)

    by crazney ( 194622 ) on Sunday September 29, 2002 @09:40AM (#4353576) Homepage Journal
    Linus said:

    --
    Linus agreed that if the VM is as good as it seems to be, indeed the upcoming release deserves to be called 3.0. But he also pointed out that there are many silent users who tend not to speak up until there is an official release. He asks, "people who are having VM trouble with the current 2.5.x series, please _complain_, and tell what your workload is. Don't sit silent and make us think we're good to go.. And if Ingo is right, I'll do the 3.0.x thing."
    ---

    So does this mean that us semi-power users should be going ahead and testing the 2.5 kernel? If so to what degree.. Should we be running 2.5 on our desktop boxes? What about video drivers (nvidia) and all that?... When does it actually get into the 'testing' time frame, hence things start to become stable?

    Cheers

    craz

    • Re:Testing 2.5 (Score:4, Informative)

      by Webmonger ( 24302 ) on Sunday September 29, 2002 @10:52AM (#4353827) Homepage
      The 'testing' time frame-- probably the closest thing to that is the planned Oct 31 feature freeze. After that, the focus should be on getting it into a releaseable state.

    • Re:Testing 2.5 (Score:3, Insightful)

      by BigPenguin ( 529751 )
      I'm a "semi-power user" and I had the same thoughts. Allthough I was kinda *forced* into testing 2.5.x because all the patches I wanted to 2.4.x wouldn't play nice together (preempt, O(1), VM, xfs) and they had all been merged into 2.5.

      I tried 2.5.38, but then alas, nvidia does not support the 2.5.x series! After doing a little googling [google.com] I found that nvidia's driver is only broken on the source side (as opposed to the binary only part) and that people have had some success patching for 2.5.

      Here's the best patch [xs4all.nl] I've found, it is for the NVIDIA_kernel-2960 (Thanks to Nicholas Petreley & Mark Hurenkamp). After adding a xfs cvs patch [profinet.sk] on 2.5.24-dj2 and recompiling the nvidia driver, my system was up and running (faster than ever).

      The improvements in 2.5.x are wonderful, and while I agree with both Linux and Igno have to say, I too am leaning toward 3.0, but it's only a number; distros will happily roll whatever [improvements/number] Linus and friends gives them.
      • Okie dokie..

        So, I tried that - went to 2.5.39 - used that nvidia patch.. and I guess they've broken the interface since, cause the patch didnt help. I had to move around some include files it couldn't find (irq_vectors.h) - but now it seems devfs_unregister_chrdev / devfs_regsiter_chrdev (i think those are the functions) no longer exist in the kernel.. I'm not exactly sure what to replace them with, so I give up ;-).

        Other than the nvidia stuff, everything else seemd ok - but I'm back to 2.4 now.

        Cheers

        craz ;-)

  • Take a lesson from emacs here (Score:3, Interesting)

    by big.ears ( 136789 ) on Sunday September 29, 2002 @09:40AM (#4353578) Homepage
    Emacs adheres religiously to the maxim of only bumping up the release number for really major changes (i.e., those that created backwards incompatibility.). Consequently, they are on point release 21 or something--they have dropped the initial 1. or 2. because it apparently seemed redundant.
    • Uhh

      they have dropped the initial 1. or 2. because it apparently seemed redundant.

      I think you are arguing against yourself here. Wouldn't the situation be the same if they just called it Emacs 21.0, since the major has become irrelevant?

      The minor has become the de facto major, is what I am trying to say. Their strict adherance to not incrementing the major has accomplished the opposite of what they wanted.

      • Re:Take a lesson from emacs here (Score:5, Funny)

        by jonadab ( 583620 ) on Sunday September 29, 2002 @12:53PM (#4354283) Homepage Journal
        > The minor has become the de facto major, is what I am trying to
        > say. Their strict adherance to not incrementing the major has
        > accomplished the opposite of what they wanted.

        No, no, you don't understand. Current versions are still numbered
        0.21.n.n because the first major release hasn't been reached yet.

        The version number won't be incremented to 1.0 until Emacs has all
        the fundamentally vital features it needs to be credibly called a
        text editor. Besides better threading (planned for 0.22 or 0.23),
        Emacs still needs thorough support for multiple human languages
        and OS platforms, a more extensive help system, and complete text
        manipulation functionality before a solid 1.0 release can be made.
        Better (reentrant) scriptability and networking support would also
        be very nice to have for the 1.0 release. Sure, the developers
        and early adopters don't bother to say the "0." part, but we all
        know it's there. As far as end users are concerned, Emacs really
        doesn't even exist yet, in fully-functional released form. Those
        of us who have started using it early only do so for testing, or
        because there are no alternatives. (If anyone is aware of any
        fully-functional text editing application, whether open or closed,
        commercial or non-commercial, I would like to know about it, but I
        have looked high and low and am under the impression that there is
        none available for any platform, at any price. Emacs 0.21, despite
        its obvious incompleteness, is the closest thing there is that I
        have been able to find.)

        See, people may think Mozilla.org invented the fully-functional
        1.0 release, but Emacs has had that philosophy all along. In
        spades. So, now you know ;-)

  • Hm (Score:2)

    by gTsiros ( 205624 )
    Here's my idea...
    I've heard that the 2.2 kernel was very very stable. Now, one could say that:

    #1 from 2.2 -> 2.6, we improve stability (since we're taking the 2.x codebase and improving on it) and refrain from adding too many new features.

    #2 from 2.2 -> 3.0, we are expected to lose some stability, since this is a *new* codebase (it is a newer version, right? not an improvement like the #1 case) and see more new features.

    but personaly, i don't care what you call it. Call it version 3.1337 or whatever...it's still the newer Linux ("Linux kernel" is redundant).

    just my thoughts.

    • Re:Hm (Score:5, Funny)

      by tuxedo-steve ( 33545 ) on Sunday September 29, 2002 @09:47AM (#4353605)
      ...it's still the newer Linux ("Linux kernel" is redundant).
      I'm pretty sure that RMS hates you.

      • Re:Hm (Score:4, Insightful)

        by stevey ( 64018 ) on Sunday September 29, 2002 @11:01AM (#4353868) Homepage

        Nope .. He always makes the speach go something like thigs:

        "Linux is the kernel, which was written by Linus (and others). The distributions are the Linux kernel + GNU Utitilites - so Linux distributions should be called GNU/Linux"

        On that basis the Linux Kernel is just Linux.

        • Re:Hm (Score:3, Insightful)

          by slackerweb ( 313212 )
          If the distributions are the Linux Kernel + GNU Utilities shouldn't it be called Linux/GNU?

          • Re:Hm (Score:2)

            by jelle ( 14827 )
            Or better yet, Linux+GNU

            Then that would allow for incompatible Linux-GNU, Linux=GNU, and Linux.GNU distributions, in addition to the wealth of LinuxWindows, LinuxOS, LinuxCE, LinuxNT, LinuxXP, and Linux.Net, LinuxPro, WebLinux, eLinux, ActiveLinux, linuX, LinuxPlus, MyLinux, DeskLinux, EasyLinux, SuperLinux, HolyLinux, TuxLinux, LINU (Linux Is Not Unix), etc...

            In other words: Who cares, really? Besides RMS...

          • Re:Hm (Score:2, Informative)

            by Doctor Faustus ( 127273 )
            If the distributions are the Linux Kernel + GNU Utilities shouldn't it be called Linux/GNU?

            Actually, no. I think this is the same philosophy as TCP/IP, which everyone just pronounces as "Tee See Pee Eye Pee", but really means TCP over IP (as IP is a lower level protocol, and TCP runs on top of it). By the same token, GNU/Linux would be GNU over (or on) Linux.

            The way RMS says it, though, it sounds like he's trying to take credit for Linux. If he asked people to call the systems "GNU on Linux", it would come off as a lot more reasonable.

    • "Linux kernel" because it's a trademark (Score:5, Insightful)

      by yerricde ( 125198 ) on Sunday September 29, 2002 @10:43AM (#4353786) Homepage Journal

      "Linux kernel" is redundant

      No. Under USA trademark law, product and brand names are adjectives and should be followed by a generic noun. Thus, "Linux kernel", "Windows operating system", "Mac OS", "Macintosh computer", "Kleenex tissue", "SPAM luncheon meat", "Xerox copier", etc.

  • Importance of Versioning (Score:5, Interesting)

    by peatbakke ( 52079 ) <peat@pe[ ]org ['at.' in gap]> on Sunday September 29, 2002 @09:54AM (#4353623) Homepage
    As Linus said, it doesn't really matter what it's called, so long as people use it. Versions don't have any real technical meaning (other than the even/odd kernels which signify stable/development).

    Since it doesn't have any technical meaning, it shouldn't be argued on technical merit. However, version numbers play a big roll in the business world. Business and marketing folk get the biggerbetterfaster vibe from increasing version numbers.

    Several distributions just released new versions in the last couple of months, or are on the verge of releasing new versions. Redhat, Mandrake, Debian, etc. Good stuff. Let the hype play out, and don't trump it by releasing a Brand New Big Version Kernel that none of the distros contain.

    Make this one 2.6. Technical people in the know, the ones who run the servers, the ones who really need the performance increases, will upgrade accordingly. Rumors in the press will be able to convince people that Linux is growing and kicking ass.

    Make the 3.0 switch after distributions have caught their breath, and after some of the other nifty things that impact userland have been completed: the POSIX stuff, further refinement of the new VM system, FS improvements (resizing, reiser 4, etc).

    Then everyone can whoop and holler about what a great new kernel it is, and how much more added value it gives to distribution version increments, etc. etc.

    Linux is great technology. Fantastic technology. It's development shouldn't be dictated by fickle marketroids. But version numbers are the most publicly visible attribute of the kernel, and should be treated accordingly.

    • >Several distributions just released new versions in
      >the last couple of months, or are on the verge of
      >releasing new versions. Redhat, Mandrake, Debian,
      >etc. Good stuff. Let the hype play out, and don't
      >trump it by releasing a Brand New Big Version
      >Kernel that none of the distros contain.

      Indeed. I'm sure there are also a few installation scripts and programs that check for uname -r == 2.* for a kernel version and might break if the major went up. Changing a major number *IS* a major thing and should only be done if there are fundamental design and interface (as in kernel module and datastructure) changes.

      Either way, I'm glad for the constant improvements to the Linux kernel and will be very happy with either 2.6 or 3.0.

  • It should be 3.0: here's why (Score:5, Funny)

    by smagoun ( 546733 ) on Sunday September 29, 2002 @10:08AM (#4353666) Homepage
    There's no 2.6 in the list of What Software Version Numbers Really Mean [stokely.com], so obviously it can't be 2.6. Therefore it must be at least 3.0. In fact, I'm stil confused as to how a 2.4 release got out.

  • This is the biggest problem with Linux (Score:5, Funny)

    by Quixote ( 154172 ) on Sunday September 29, 2002 @10:10AM (#4353667) Homepage Journal
    In the time that Linux has gone from 0.9 to 2.5, Windows has gone from 3.11 to 2000 ! In other words, Windows development is proceeding at 1331.26 times the development of Linux! No wonder Microsoft is light-years ahead of Linux.

    I think we should speed up development and annoint a dedicated "version czar" who will make sure that the Linux kernels stay ahead of Windows. Hard as it may be, I'm willing to ``do my share'' and volunteer for this position. My first step would be to shift the decimal point 3 places to the right. This decimal has been hogging the #2 spot in the release number for too long; it is time it got relegated to the #5 spot, where it rightfully belongs.

    :-) for the :-)-impaired

  • Sounds like he means it (Score:3, Interesting)

    by Odinson ( 4523 ) on Sunday September 29, 2002 @10:24AM (#4353715) Homepage Journal
    While I defiantly see the point about binary compatibility, it doesn't have to be the only major upgrade reason. I think I'll go compile it right now to make sure we are ready for this...

    The truth is changing major version numbers would give the Linux business a major shot in the arm. Every press establishment would have no choice but to run a story about Linux and it's capibilities at a time when MS is chasing it's customers off, and everybody would have to upgrade their Linux mascot.

    Do you really think there would be version wars if the announcments didn't make the participants money?

    • >The truth is changing major version numbers would
      >give the Linux business a major shot in the arm.

      True. But, do we really want to have the public think we depend on version numbers for publicity? Such would be disadvantageous.

      >Every press establishment would have no choice but
      >to run a story about Linux and it's capibilities at
      >a time when MS is chasing it's customers off, and
      >everybody would have to upgrade their Linux mascot.

      Let the Linux Kernel Dev team stay with what they're good at: Making a technically great Linux Kernel. Let the marketing people stay with what they're good at: Hyping a product. And let's not have these twain meet anytime soon ok?
  • Calling the successor of 2.5 version 3.0 ignores the 2.4 (pre .14 or perhaps .16) debacle and the old adage to never deploy a .0 operating system.

    While millions of Linux users were apparently happy with the early 2.4 kernels, those of us with heavy CPU large memory needs were appalled when we watched our computers lock up under heavy memory usage. Yes, we thought we had a usable system at 2.4.14, but then came .15, with file system corruption, so .16 was the FIRST usable version for systems with high memory demand. Wouldn't it be great if 2.6.1 was as robust as 2.2, or 2.4.17, at the beginning?

    Since we all know better than to deploy a .0 version, 3.0 must be a non-starter.

    • Wouldn't it be great if 2.6.1 was as robust as 2.2, or 2.4.17, at the beginning?

      Things just don't work like this. It's difficult to say before a release whether it will be extremely robust. The only way to test stability is to get a whole lot of people to pound on the kernel and find stability problems. Unfortunately, this doesn't happen until Linus declares that the kernel is stable. But he's really just saying "As far as I can tell, the kernel is stable."

      Anyway, not everyone had results as good as you with the 2.2 kernels. In fact, you may recall that 2.2.0 wasn't stable at all; 2.2.1 was release shortly thereafter to fix a major bug. When I switched from 2.0 to 2.2, I had plenty of stability problems, mostly due to buggy drivers. Things gradually improved through the 2.2 releases, until I finally stopped having problems around 2.2.14. From looking at LKML archives, I suspect this is the norm, rather than the exception.

      In fact, I would say that linux kernel development has the following general pattern:

      1. Linus maintains an unstable branch, and developers add new features, make big changes in the code, etc.
      2. Linus declares a feature freeze, and developers fix bugs until things seem to work well.
      3. Linus declares a stable release, and a huge number of people begin using the new kernel. All the new users expose a bunch more bugs, and the developers work to fix them.
      4. The kernel becomes stable in fact rather than just in version number, and Linus gives up maintainership to someone else. He then opens another unstable branch, and the whole cycle begins again
    • the old adage to never deploy a .0 operating system.

      So, maybe we should just go from 2.5 to 3.1 directly? :-)

      I remember Commodore caught a bit of flak for their versioning system (it was the same as the Linux kernel's and people couldn't handle double digits in the minors without feeling woozy and have a bit of a lay down) from time to time, but Microsoft's just plain silly. Has anyone seen Exchange 1.0? 2.0? 3.0, even? Or the "Exchange client" in Windows 95 Mk II that didn't have support for the Exchange server?

      It's a good thing I'm currently on Windows NT 5.1, an OS named Windows Vomit ( :-XP ) would be too much to bear for my poor Athlon...

  • Linux IV (Score:4, Funny)

    by rjamestaylor ( 117847 ) <rjamestaylor@gmail.com> on Sunday September 29, 2002 @10:47AM (#4353805) Journal
    Jump the revision to IV. The major improvements are in the IO blocking and VM subsystem. That's the excuse... but the real reason would be to benefit from the press explaining the numbering revision and what it means--that's the ploy Microsoft, Intel, and IBM have used to manipulate free press about their products ever since, well, the IBM AT and IBM PS/2. Heck, even Apple does it.

    Linux IV, becuase Free software needs free press, too.

  • This is how I always thought it should work...

    X.Y.Z

    Increment Z for bugfix releases.

    Increment Y for major feature enhancements.

    Increment X when it breaks binary compatability.

  • GCC (Score:2, Interesting)

    by crywolf ( 445243 )
    If binary incompatibility is one of the criteria for increasing the major number, then I'd say when the Linux kernel requires gcc 3.2 (or better) to compile is when they should call it 3.0. And if they work toward that after releasing 2.6, they should skip 2.7 and jump to 2.9 to indicate the intention of making a 3.0 kernel.

    • Re:GCC (Score:2, Informative)

      by Isle ( 95215 )
      The Linux kernel is written in C and assembler, so it will stay binary compatible between gcc 2.95/96 and gcc 3.2.
  • I have to say, Winamp (3.0) and commercial games have convinced me that *.0 releases of almost everything should really be *.0 beta. Zeros scare me, 2.6 sounds comfortingly mature.
  • Transcipts were released today including those of Gates and Ballmer arguing over what to call the latest version of Windows. Gates suggests WindowsXP where Ballmer is whining like a monkey screaming for WindowsXS. Gates eventually won the argument by giving Ballmer a food pellet.

    Really exciting news ladies and gentlemen. (but it's okay... it is Sunday :))

  • Version number abuse (Score:3, Insightful)

    by captaineo ( 87164 ) on Sunday September 29, 2002 @11:50AM (#4354039)
    Argh! The first digit in the kernel version number was always meant to indicate the ABI version! They should NOT change it from 2. to 3. unless they intend to make major (backwards-incompatible) changes to the kernel ABI. If they do this then we will lose the second-to-last piece of information in kernel version numbers. (the last piece being the even/odd stable/development thing)

    I guess Linus is falling into the same trap as most other free software developers. Already in most software packages, version numbers provide nothing more than an ordered sequence of releases. There is no way to tell just by looking at a version number what ABI/API version is exported, whether it is a stable or development release, etc. Pathetic.

    • Re:Version number abuse (Score:2, Interesting)

      by mce ( 509 )
      Argh! The first digit in the kernel version number was always meant to indicate the ABI version!

      Where did you get that idea? It's simply not true, and never has been. The increase from 1.x to 2.x was to signal the addition of SMP capability. The kernel ABI's change quite regularly during a development series. Usually in such ways as to remain compatible, but compatible does not imply contstant and every so often things are broken (think about some of the problems with some well known binary-only modules for some examples).
      • I stand corrected - you are right about 1.x vs 2.x. I just got the distinct impression that 2.x was to stay until a long-off "flag day" when enough incompatible changes have been waiting to be worth breaking user-space.

        BTW by "ABI version" I specifically mean the kernel-user ABI - i.e. the syscall numbers, their arguments, and expected behavior. Not the kernel-driver ABI, which, as you point out, changes with virtually every release.

        The kernel-user ABI has the distinction of being practically the only ABI that has *not* seen incompatible changes in my 3+ years of Linux usage =).

  • What Software Version Numbers Really Mean (Score:2, Funny)

    by Anonymous Coward
    What Software Version Numbers Really Mean (Author Unknown)

    Once you start playing with software you quickly become aware that each software package has a revision code attached to it. It is obvious that this revision code gives the sequence of changes to the product, but in reality there's substantially more information available through the rev-code than that. This article provides a guide for interpreting the meaning of the revision codes and what they actually signify.

    1.0: Also known as "one point uh-oh", or "barely out of beta". We had to release because the lab guys had reached a point of exhaustion and the marketing guys were in a cold sweat of terror. We're praying that you'll find it more functional than, say, a computer virus and that its operation has some resemblance to that specified in the marketing copy.

    1.1: We fixed all the killer bugs ...

    1.2: Uh, we introduced a few new bugs fixing the killer bugs and so we had to fix them, too.

    2.0: We did the product we really wanted to do to begin with. Mind you, it's really not what the customer needs yet, but we're working on it.

    2.1: Well, not surprisingly, we broke some things in making major changes so we had to fix them. But we did a really good job of testing this time, so we don't think we introduced any new bugs while we were fixing these bugs.

    2.2: Uh, sorry, one slipped through. One lousy typo error and you won't believe how much trouble it caused!

    2.3: Some jerk found a deep-seated bug that's been there since 1.0 and wouldn't stop nagging until we fixed it!!

    3.0: Hey, we finally think we've got it right! Most of the customers are really happy with this.

    3.1: Of course, we did break a few little things.

    4.0: More features. It's doubled in size now, by the way, and you'll need to get more memory and a faster processor ...

    4.1: Just one or two bugs this time... Honest!

    5.0: We really need to go on to a new product, but we have an installed base out there to protect. We're cutting the staffing after this.

    6.0: We had to fix a few things we broke in 5.0. Not very many, but it's been so long since we looked at this thing we might as well call it a major upgrade. Oh, yeah, we added a few flashy cosmetic features so we could justify the major upgrade number.

    6.1: Since I'm leaving the company and I'm the last guy left in the lab who works on the product, I wanted to make sure that all the changes I've made are incorporated before I go. I added some cute demos, too, since I was getting pretty bored back here in my dark little corner (I kept complaining about the lighting but they wouldn't do anything). They're talking about obsolescence planning but they'll try to keep selling it for as long as there's a buck or two to be made. I'm leaving the bits in as good a shape as I can in case somebody has to tweak them, but it'll be sheer luck if no one loses them.

    ______________

  • A little history (Score:3, Interesting)

    by scharkalvin ( 72228 ) on Sunday September 29, 2002 @12:09PM (#4354102) Homepage
    The change from 1.x to 2.0 was made at the time that the a.out format was dropped in favor of elf. But wasn't this just a library change? Anyway after 2.8 they could go to 2.10, no reason the second number can't be two digits. Still the changes to vm, and /dev alone might be enough to jump it to 3.0, especially if the changes for SMT with kernel pre-emption are added.

  • Afterthought? (Score:4, Insightful)

    by ReadParse ( 38517 ) <john@funnycow.RABBITcom minus herbivore> on Sunday September 29, 2002 @12:14PM (#4354122) Homepage
    There's something strange about making a bumping a major version number as an afterthought, don't you think?

    Don't get me wrong... I have all the confidence in the world in Linus, and he knows way more about what he's doing than I do. I'm just surprised that a project that organized wouldn't have a "3.0 List" by now of all the new stuff they plan to do in 3.0 one of these days... and when they start putting all those pieces together in a source tree, they would call that the "3.0 code" from the beginning.

    At least that's the way I would imagine it. But don't miscontrue anything I've said as a suggestion that I have any idea what I'm talking about .

    RP

  • I prefer 2.6 (Score:3, Insightful)

    by Dr. Spork ( 142693 ) on Sunday September 29, 2002 @12:34PM (#4354213)
    I'm not a developer or anyone important, but I think it would be psychologically good for the developers to call it 2.6. If they call it 3.0 it will be an extra excuse to screw around with stuff they should be releasing--because, after all, we're expecting something really new in a major number revision. The thinking would be "hey, 3.0 sounds like a big deal, so I should take my time and mess with everything before we release it."

    If the VM improvements are really so cool. just stick them into 2.6, get it out the door, and save your grand schemes for the next release. I know it must be tempting to stick in the next great idea that seems just around the corner, but that just leads to endless delays and demoralizes the hackers that finished their work "on time" as they're waiting out to feature freeze while everyone else is still cleaning their code for release.

    Ideal would be, I think, to call a 2.6 feature freeze very soon, and very shortly thereafter, open a 2.7 (2.9?) unstable branch where "anything goes."

  • I always thought after 2.8 the next stable release was 2.10 with the development branch being 2.9.. why do they act like that is confussing? Nothing new with that.. lots of projects do version numbering just that way. You only bump the major version number for changes that are extreme or break compatibility or change the goal of the project or something large like that. The changes in the 2.5 branch would seem enough to jump to a 3.0 version but I'm confussed why they talked as if after 2.8 you HAD to jump to 3.0 as the next version.
  • Can someone enlighten me as to what this means? Does it for instance mean that drivers compiled for 2.6.1 will be binary compatible with other 2.6.x-kernels unlike in the 2.4-tree?
    • I would agree except for the Unicode. I think UTF-8 should be used everywhere, as it is upwardly-compatable with 8-bit Ascii, and this avoids the need for any legacy interfaces, and makes it pretty obvious how to store the filenames on older systems.

      It may also be a good idea to allow float and double values in system interfaces whereever they make sense, such as time intervals.

    • No, as long as Linus is in charge there will never be binary compatibility of modules between minor kernel versions (or even different configurations of a single version, e.g. UP or SMP). Linus considers it too much trouble to be worth the effort.

      AFAIK the new driver model basically puts all drivers in a uniform structure, primarily for the purposes of handling power management (sleep states) uniformly, and of moving towards a simple, standardized layout for /proc interfaces. There has been some talk about revising the module loading/unloading process (since the current methods still have some problems), but no action has been taken yet.

  • I believe the Linux kernel should not be called 3.0 until it is 64-bit through and through.

    The difference between 1.x and 2.x was a major architectural change: multiprocessor capability and portability to different platforms. The difference of 3.x should be equally as large: widening of all interfaces and data structures that are currently reaching their limits.

    This includes 64-bit memory access, 64-bit file size access, 64-bit block counts on filesystems, and so on. Important external interfaces such as networking and filesystems must also be widened. A fully complete and robust IPv6 stack is a must: something that isn't quite there yet, but is getting close.

    Essentially all fields in stat() require widening! Major and minor device numbers desperately need more room. Inode numbers and file size 64-bit, of course. Timestamps need to fix the Y2038 problem: 64-bit, possibly with added precision as well (to guarantee each file can be unambiguously sorted by time even on fast systems with such applications as parallel make). Security needs to be more fine grained (full ACL support). 32-bit UID and GID numbers. And finally, the filename itself needs to have full Unicode support without loss of field width (255 Unicode characters should be accepted). The output of the ls(1) command is a call to action: essentially every field there is in need of widening!

    The main difference should be in the defaults: currently, standard stat() file limits and IPv4 are the defaults, and programs must go out of their way to request larger sizes (O_LARGEFILE) and IPv6. The programming model should be changed to provide programs with the widened resources as standard. This will take a long time, and is a gradual evolution, so there is a definite need for 2.6 and possibly 2.8 as transitional steps. The widening of these critical system resources is probably the main thing keeping Linux from large commercial UNIX installations!

  • ... Linux .NET
    And release it before Windows .NET.
  • There have been some excellent and very valid points made in the comments here - bumping it gives a media boost because everyone will devote a few screen inches to it. That therefore needs to be balanced with a collection of new features that people can be sold on. "It runs millions more threads than you will ever see, it does it in the blink of a very small and fast blinking bat" isn't quite the same as "we put in all new disk management and resizing tools, all new enterprise-class filing systems, top notch new security controls..", etc, etc.
    Those are all perfectly true and someone needs to work that out, not to mention work out if it really matters.
    What I think really does matter is what the 3.0 release comes from, not when. I really wouldn't like to see 2.5 or 2.9 go straight into 3.0. Sure it may be a lovely new kernel, but if it's going to take until 3.0.14 to get stable enough, people are going to be unhappy.
    I guess my suggestion therefore would be to turn 2.5 into 2.6, get it stable and into all the major distros, then run two development trees, an experimental 3.1 for way out new core stuff, but also a 2.9 that simply adds non-core things to 2.6 (e.g. Reiser4, EVMS, MACs, etc.) so that it has a stable base to sit on while integration work is done. The wonderous BitKeeper ought to make back/forward porting work done on each tree relatively simple, plus we get to announce a big 3.0 release that not only has tons of sweet new features, but also has many months of proven stability because it's core is really 2.6. Nes pas?
  • In general, I think Linux version numbers tend to be as screwed up as Windows version numbers. The kernel itself, and stuff like GNOME and KDE are fine, but a lot of the secondary software is not. There are totally stable products that have 1.0 is something the author has some level of faith in.
    • Damn /. The last sentence should read:

      There are totally stable products that have version numbers less than 1.0, because the author wants some holy grail for the first release. While that's admirable, I think its important that version numbers give at least a general idea of the amount of faith the author has in the stability of a particular release.
  • Why not avoid the whole 2.4 not being stable for a while issue? Release as 2.6, fix mountains of bugs, when it is properly stable, release 3.0==2.6.14 or whatever.

  • OT (Score:2)

    by wedg ( 145806 )
    Ever wonder if Linus cackles to himself a little bit each night before he goes to sleep?

Slashdot Top Deals

Each new user of a new system uncovers a new class of bugs. -- Kernighan

Close