Slashdot Mirror
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."
I have a very old system, running redhat 4.2 on it, that does the billing for the X.25 part of my network. It runs a lot of scripts and binary programs that are reading accounting files generated by the X.25 switches, transforming them into text files and generating monthly reports for the billing department. It is so complex, that I would think more than twice even for upgrading the kernel from its current 2.0.32 to the new 2.0.39, and upgrading the operating system to a newer distribution will never be done, because it does not worth the effort. Its great to see that somebody still takes care of old software and if a bug will bother me someday, i will have the option to upgrade or at least to talk with somebody that still mantains the software.
The long time maintainance of an "old" kernel is a very important argument in favour of linux for serious industrial applications.
In our area we have the saying "you earn money with depreciated machines" - and to use them, you simple do need an "old" maintained operating system.
So the work of the "historic kernel"-maintainers is helping Linux to get good reputation.Oh wait, this is open source.
pr0n - keeping monitor glass spotless since 1981.
...don't fix it
A good example of this is that NASA still uses 8086 processors: You know exactly how they work.
New things mean new problems. If you're having a system which does its job, why upgrade to a higher level kernel that can support hardware and protocols you don't need, but brings in bugs you don't want.
Er. Not quite correct:
ftp://ftp.kernel.org/pub/linux/kernel/v2.0/testinSo the latest release candidate for 2.0.40 was only released back in June. Doesn't look dead to me.
I wonder how many Windows 95 machines are still running and in actual use. Anyone here still running a variant of Win95?
If I was the head of a company that owned a few servers and I discovered that one of them was running Win95.
Well I'll make an exception to the saying "Nobody ever got fired for buying Microsoft."
>
There are a lot of specialized applications running on legacy systems, such as many mechanical corridors that connect to aircrafts (Win 3.11) or handheld barcode scanners (DOS), or even a lot of ATMs (OS/2 1.x).
:)
The basic advantage is the understanding someone comes to have by working a number of years with something specific. Most bugs, and for certain all the serious ones, are known and documented. Design limitations are known also. There are field proven designs and in many cases known tweaks to extend functionality, even beyond the original capabilities.
This stands true for pretty much everything; another poster pointed out that NASA still uses 8086 hardware!
The need for maintenance is also something relative; if you have something that constantly works reliably, the maintenance required to keep it that way is minimal.
I believe that even if 2.0.39 was the last kernel of the 2.0.x series, people who use 2.0.x won't really care. I know, since I have a 2.0.36 based home router that runs for the past year and a half with zero maintenance. I don't even plan to upgrade to another 2.0.x kernel, let alone 2.2 or 2.4, as long as it just works (tm).
One advantage of open source is that the continuation of older versions is _truly_ market-based. That is, an old version that is genuinely valuable to a small coterie of users can remain in existence. In particular, low-benefit-low-cost products--products that appeal to a small base but cost little to maintain--can thrive as long as the benefit/cost ratio is good (even if numerator and denominator are both small).
IMHO one of the big problems with proprietary software--which I once saw personally from within a then-Fortune-500 company--is that career advancement depends on working on big projects and thinking big. One one occasion I was told that something wasn't pursuing because "on your own showing it can't bring in more than $2,000,000." I said, "yes, but the costs are trivial so it will be very good business." It was explained to me that projects of that size were just too insignificant to be considered. I believe that just the cost of translating the manuals into the fifteen languages supported by this global company was enough to sink the project (and of course ALL the company's product HAD to be translated into ALL languages because that was their procedure). On another occasion, when wondering whether we should be developing projects for a certain market sector, I was told, "Naaaah, we already had a consultant look into that, it's not worth it, it's just another $100 million market."
And of course with proprietary commercial software is you usually have the vendor "pushing" newer versions because selling new versions provides more profit to the vendor than maintaining old ones. The commercial software marketplace is a very imperfect, high-friction "market." And one place where the vendor has a lot of asymmetrical power is with respect to versions and releases. It is usually easy to keep customers on the "version treadmill." What if you don't like Microsoft discontinuing Windows NT 4.0? Where's the customer leverage? "If you do that I'll just buy Windows NT 4.0 from one of your competitors?"
"How to Do Nothing," kids activities, back in print!
Why have 4 active kernel lines?
2.0: Legacy systems & embedded. It's tiny!
2.2: Middle-aged systems or wherever stability is a must. RH6.x and other 2.2-based distros are still in widespread use.
2.4: New systems with new hardware that requires new drivers.
2.5: Development. Don't use in a production environment, lest you fall down and go boom.
Besides, each line has a different head maintainer.
DrQu+xum: Proof that the lameness filter doesn't work.
- 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.I've done 9 pre-releases since January 2001, and I'm probably going to release 2.0.40 any day now (I have one thing to do some research on first.) While the flow of releases isn't quite the same as that of the 2.4-series, it is maintained. Something would be really wrong if I had to release a new kernel every month, 6 years after the release of the first 2.0-kernel...
I open a new revision whenever I get a serious enough bug-report and/or fix, and release pre-patches/release-candidates until everything seems to have slowed down again. Wash, rinse, repeat.
Releases every one and a half years or so, with interim releases every month or two seems to be a pretty decent pace for a really stable kernel-series. Most of my users aren't the kind that does regular kernel-upgrades anyway; they usually inspect a new 2.0-kernel very carefully before installing it on their hardware.
Regards: David Weinehall, maintainer of the 2.0-series