The Future Of The 2.0 Linux Kernel

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."

Comments

Re:old systems

[skydude_20]

isn't this kind of attitude of "it works, leave it alone" that gave us that Y2K fiasco?

then again we have the "it doesn't work, lets make it better" attitude that gave us Windows, so its your choice of the lesser of two evils

Re:If it ain't broke

[guybarr]

A good example of this is that NASA still uses 8086 processors: You know exactly how they work.

I thought this was more due to radiation robustness , than due to plain conservatism (which I agree is an asset in critical-system engineering)

am I wrong ?

Re:killer feature

[jsse]

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? :)

Re:Used since 1996!

[modicr]

Hi!

What about this network:

SERVER:
1 x Netware 4.2 small business

CLIENTS:
1 x Windows 98 SE / Win2K SP2 (dual boot)
19 x Windows 98 SE
1 x Windows 98
2 x Windows 95B
1 x Windows 95A
5 x Window 3.11 for Workgroups (& MS Word 6)

Ciao, Roman

Re:Consider yourself warned

[vadim_t]

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.

linux 2.0 stability

[FeatureBug]

The 2.0 series had real stability. In 6 years I had just one or two 2.0 kernel crash mainly when using X or the sparse superblock patch. The 2.4 series has more features but I've much less stability. I've lost count of how many crashes I've had even without using X, or beta quality optional kernel code, or devfsd. The most annoying ones are the module load/unload lockups still present in 2.4.19 and up:

# lsmod
Module Size Used by
isa-pnp 21381 0 (unused)

# insmod etherpro
# lsmod
Module Size Used by
etherpro100 13413 0

# rmmod epic100
Jun 27 11:32:03 koyuki kernel: unregister_netdevice: waiting for eth0 to become free. Usage count = 4

At this point, the kernel module code is unsalvageable. A reboot is required.

Re:Consider yourself warned

[jabberw0k]

But what happens when everyone deletes the old source versions off their mirrors "because it's just a copy of old stuff" ...?

This is just what happened with the plans for the Saturn V rocket -- there were three copies, each of which was destroyed "because it's just a copy."

Where do you go, then?

Re:good problems

[Papineau]

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.