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.
If something isn't broken and does what you want, why upgrade it? That's the beauty of free software, *you* decide what version you're running, not your vendor...
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.
How about in a server environment? [ducks]
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
Something that hasn't been updated in a year and a half counts as "maintained" in your book?
2.0 is pretty much dead.
Do you bother to read the article before trolling?
"The 2.0.40 kernel is due to be released soon."
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).
No one expects non-technical users to teach themselves to be kernel hackers. That's just a silly straw man.
The point is that you can hire a kernel hacker to do the work. Linus and the rest of the gang doing the volunteer work don't want to support the stuff that's running your business anymore? Hire someone else to do it. It's an option, and in some cases it can be a very good one.
Whereas with unfree software, whether from MS or Sun or whoever, that option just doesn't exist.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
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!
Absolutely. The machine I'm typing on now is running 98SE, customised with 98lite using the explorer.exe from 95. Runs every win32 program I need on a desktop, and does it noticeably faster than machines with significantly more powerful hardware running later versions. Reasonably stable, considering it is windows after all - it gets uptime close to the Win2k boxes they have at work actually.
If you had any doubt that the answer to your question would be yes, this will really blow your mind - I've also got DOS 6.22 and WfW on a CD on a shelf across the room, I haven't actually used it in months (haven't used WfW in years, but DOS 6 really does come in very handy at times.)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
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.
Why oil price increase equals economic trouble (Score: Interesti
What's bad in using Linux-2.4 on 486?
The real advantage (from the non-programmers point of view) is that free software gives you the a much larger choice of suppliers. As long as the market exists, someone will be their to support it. With non-free software, you are depending on a single supplier, who may at any time refocus their interrest away from you.
Of course, even with free software the market can become so small that the cost of finding supplier becomes too large. But at least it is your wallet, and not the strategic geniuses in some board room, that decides when that point has been reached.
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.With open source, the existence of a user community for a particular version is far more likely to produce people who are willing to maintain that version than in the commercial case. Companies will drop products even when there's a thriving user community, if the sales of the product in question are no longer commercially viable. (I've done this myself, with a software package I used to sell.) All products eventually become the responsibility of their user communities, but with open source, at least you have some options, up to and including paying someone to make enhancements and fix bugs for you. If all you have are binaries, you're SOL.
Weren't there patches against the 1.0 patchlevel 9 kernel to make it compile with gcc 2.7.2? Who continues to maintain this one? :-)
A monkey is doing the real work for me.
Why in the world would secure browsing be a requirement for third world kids on old PCs?
What, poor kids don't deserve to have Hotmail? Or Yahoo mail?
There are a lot of people in the "Third World". They want services too. My ex-gf was Brazilian. She just got a Pentium 4, and needs secure browsing to do her online banking. You can do things with ATMs there that they're just designing here. Check out www.lavrasnovas.com.br. This is a small town, maybe 100 people (but at least 10 bars, woohoo!), but it's got a web site, with Shockwave.
"The Third World" is a pretty complex, diverse place. I personally hate the term, it has too many connotations of arrogance. But if you do use it, don't lump people all together. Middle class there is a much better life than middle class here.
...is using RH 5.x with 2.0.36 on their DNS servers. Of course we're also using Bind 4.9.7. Apparently they have (well, had) no ambition to upgrade. My network project requires a new DHCP setup and dynamic DNS. Now they have to upgrade. If it wasn't for that though, I wouldn't see them upgrading either system until a security problem cropped up and bit them on the ass. I keep all of my systems current to within a couple RH releases and my kernels are always to within a couple versions on a stable major release.
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
The merging of Patch A into the stable kernel would not affect Patch B or Patch C
They're not dependant on it, they're intermangled with it. They touch the same subsystems (same source files), although they can be orthogonal (in theory) to each other (applied in whatever combination you want). But still, you'll need to adapt each of those to the current kernel (and for each new kernel before your patch is adopted). That takes some efforts.
I agree that a very very very good revision system could maybe do the trick, although it'll need help from a (more likely, more than one) human.
Another thing is applications and libraries. Yes, normally they're independant from the kernel (to a certain point). But if your development and stable kernel are the same, you'll need to update some of those a lot more often if you upgrade your kernel. By contrast, a stable kernel series should be compatible with the same libs and apps from beginning to end. If there are some changes in API or new features, get the newer kernel series, along with updated apps and libs. It's called modularity. A new kernel series is effectively another module, even if it replaces a previous one and fulfils the same task.
Last thing (somewhat linked to the last point): up until now, I've mostly talked about the POV of a user (either server or desktop). Now I'll take the POV of a developer (distributor, or a company designing a new product using this technology). Field upgrades are a PITA. There are some ways to do them, but they're difficult (witness the number of unpatched IIS installation trying to propagate Code Red). When you need to do one, you (normally) prefer to change the minimum of things. So no jump from 2.0.32 to 2.4.19, but ideally 2.0.32 to 2.0.32+patches, or 2.0.40 if really needed. Now, if that 2.0.40 had diverged on a number of fronts from your 2.0.32, because features and major changes creep in in minor releases, your PITA has just grown again. It would be like basing your new product development on 2.5.0, and then trying to keep on top of new changes with every new releases. Good luck.
According to the Linux Counter, about 1.6% of the Linux users use the 2.0 kernel.
That's more than the number of people using 2.5.
(Don't like the numbers? Get counted!)
Right you are.
Talking about online banking. I might have to use Windows if I had to let them communicating with commericals, as most companies there are Windows-centric. I'm glad that we work for kids, that gives us greater flexibility in choosing platform
I still run some servers on 2.0. They have been up for years, only failing after hardware fries or a power outage.
Why should I mess with them? I have software on another machine that requires an old verson of gcc (due the changes in the String library) and I don't want to rewrite it. Everything works. Everything is stable.
I also run old distros, even with the 2.2 kernel. I upgraded one machine to Slackware 4.0 when that was the New Thing and it took me a while to get it stable. Now I don't want to mess with it; just upgrade the kernel for security issues. It just runs apache and WordPerfect, it is a PPro200 with 128Mb RAM and is solid as can be. If I upgrade it, my old copy of WordPerfect won't work anymore and I don't like the new one.
Many friends who came from the Windoze world always have the need to be upgrading. As long as the old software still works, why change it?