Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Future Of The 2.0 Linux Kernel

Posted by timothy on from the watch-the-zero-carefully dept.

An Anonymous Reader writes: "The first 2.0 stable kernel was released over six years ago, in June of 1996. It was followed by the 2.2 stable kernel two and a half years later, in January of 1999. The more recent 2.4 stable kernel followed by two years in January of 2001. And the upcoming 2.6 kernel is at least a year off. Through all these years, 2.0 has continued to be maintained, currently up to revision 2.0.39, also released in January of 2001. David Weinehall maintains this kernel, and says, "there _are_ people that still use 2.0 and wouldn't consider an upgrade the next few years, simply because they know that their software/hardware works with 2.0 and have documented all quirks. Upgrading to a newer kernel-series means going through this work again." Read the full story here."

3 of 219 comments (clear)

  1. Re:killer feature by jsse · · Score: 3, Interesting

    Right you are. I know there aren't many such a case here, but my friend is working on refurbish old 486s for kids in third world. Since the requirement is to be able to surf web securely, I recommended to use stable Debian with 2.0.x kernel, which seems to work well with these old hardware, while has good security, and above all, no license fee incurred.

    Now we know who we must thank. Thank you very much David Weinehall. :)

    Only they'd have problem browsing pages which require mplayer plugin. Any expert out there would give me some hints? :)

  2. Re:Consider yourself warned by vadim_t · · Score: 3, Interesting
    Well, you can always pay somebody to do it. That's how Namesys (the people who make ReiserFS) earn money.

    Now, of course there are lots of programs out there that are useful, but broken in some way or not actively maintained. I'm sure everybody has found a nice project that just needs one little thing to be perfect but nobody touched it for a year.

    I think what we need is a "Volunteer Hackers" site where users could post their requests for help, and programmers willing to help could see what is needed. I'm wondering if this could succeed. It would be very nice if it did, and probably would be yet another good reason to switch.

  3. Re:good problems by Papineau · · Score: 3, Interesting
    A few points to consider:
    • More difficult to change big parts of the kernel, or entire subsystems, without a development kernel for which it is "normal" to be broken at times. For something in maintenance mode, the system you propose is quite fine (witness what's happening for 2.0, 2.2 and event 2.4 kernels). But for the bleeding edge, it's just not possible to do it that way, because patch A (which improves on the VM) affects patch B (VFS) and patch C (scheduler). So if you merge patch A (because it's deemed "stable") in the next official kernel release, then patch B and C must be reworked not beacuse of themselves, but because what they build upon has changed. Next, when patch C goes in, it's patch B's time to be adapted (again). It's more efficient to have all 3 develop at the same time in an unstable kernel, and have all the quirks sorted out. Of course, don't run those kernels on production machines...
    • The goal of the two kernel branches are different. One strives to be usable right now (bugfixes), the other one strives to be easier to work with in the future (more features, cleanup, performances ameliorations, etc.). If you merge those two together, you'll more than likely end up with something absolutely unstable, or a nightmare to manage (and merge different patches).
    • The goal of kernel development is not only to develop new features (aka advance). There's also a big part of it which goal is to keep running systems, well, running. It's for them that 2.0.40 is being prepared, as well as 2.2.22. And even 2.4.19 enters that category, which is quite different than the goal of 2.5.
    • As for the officiality of updates of older releases, it's only so that the development isn't split between a few groups with the same goals. I don't think a lot of the people currently working on the different subsystems of 2.5 also work a lot on 2.0.40, especially since the differences between the latest RCs are one or two fixes each time. OTOH, driver maintainers are more likely to follw it's development (although bugfixes only).
    So in the end, it's not the double of the work to maintain (which implies "no new development", hence "not a huge workload") older kernels. And if nobody would need it, nobody would do it.