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."
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....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.
Which reduces the problem but doesn't negate it. Everyone loves pointing out that anyone can get their hands on the tools necessary to modify open-source software, but they tend to conveniently ignore the fact that not everyone has the programming skills necessary to do so.
Sure there are a lot of people out there who can program, and even a decent number of people out there who can program well. But in this case, you'd need someone with at least some Linux kernel hacking skills and enough programming know-how to be able to close a bug (possibly even a security bug) that made it past all those people who've hacked on 2.0 so far. Now factor in that you'd want a programmer good enough to be trusted with mucking around with the kernel for Very Important Systems -- systems important enough, at least, that you aren't willing to even take the next big jump in kernel versions.
It all boils down to a dicey situation. Even certain Open Source projects/versions get end-of-lifed by the official maintainers. You aren't always guaranteed that someone else will pick it up.
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!