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