A Linux Kernel More Stable Than -stable 142
jfruhlinger writes '-stable' is the term for the current Linux release most suitable for general use; but as Linux moves into more and more niches, there's a need for a kernel more stable than -stable, which is updated fairly regularly. Both enterprise and embedded systems in particular need a longer horizon of kernel stability, which prompted Greg Kroah-Hartman, then at SuSE, to establish a -longterm kernel, which will remain stable for up to two years. Now there are moves to get this schedule formalized — moves that are a good sign of Linux's long-term health."
Red Hat (Score:4, Interesting)
Isn't this basically what Red Hat does - back porting security and bug fixes to an established maintenance point for the kernel and many of their other packages?
What will this do to version numbering? (Score:3, Interesting)
Since the -longterm is going to have to be based off of a -stable release and be maintained off that branch, we end right back where we were, with four version numbers, each level denoting the number of rounds of fixes applied to the number to the left. Only there's now going to be increased stagger, since stable will lag behind the release and longterm will lag behind stable. (They have to.)
If we're going to have lots of version numbers, then going back to the odd/even minor digit makes more sense than to do rapid increments. Yes, this pushes us out to five digits, which is borderline insane, but it is then five digits that carry specific pieces of discrete information rather than four digits where two don't necessarily convey a whole lot.
Re: BSD. (Score:5, Interesting)
Hello constant updates is not a sign of Stability!
The problem is there isn't much need for commercial support for something that doesn't break all the time.
I have used RedHat in a server farm of over 1000 systems and I have used FreeBSD in servers systems that were a little smaller.
The BSD generally run's behind in code version on the application side, but these are more stable and not constantly pushing the bleeding edge. It's used inside Router and Big server farms and so tends to be better on the network side.
With Red hat we had so many problem with the BNX/BNX2 10 GB ethernet drivers, it was a nightmare scenario with over $500,000K in blade servers constantly crashing, there were the HP vendor drivers, and the RH drivers and the Linux main line drivers, which we ended up building and using till RH caught up.
FreeBSD is hardly dead. Some of the fastest network drivers exist in FreeBSD.
At this point the BSD's are almost a flavor of Linux. There is a Linux compatibility layer also.
I have written drivers for Both BSD and Linux. BSD drivers are generally much clean and more straight forward and it's because of them that many HW vendors bring up a BSD driver first even if they choose never to share it.
2 years isn't a lot (Score:4, Interesting)
Real-time Kernel Patches Synchronisation? (Score:5, Interesting)
If the target for a long-term stable kernel is embedded systems, then I would suggest having some sort of arrangement with the real-time kernel patches [kernel.org] which typically don't release with every kernel.
If, for example, 2.6.39 was chosen as a -longterm, it's unattractive for many embedded developers without the option of the -rt.