Slashdot Mirror
A Linux Kernel More Stable Than -stable
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."
Maybe other open source projects take the hint and provide something where I can install and not worry about it breaking every few months. You don't buy a new car every month.
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?
#DeleteChrome
Have you ever taken a Kroah-Hartman test? It's a test designed to provoke an emotional response.
Hartman: You're in a repository, compiling a kernel, when all of a sudden you look down.
Dotzler: What version?
Hartman: What?
Dotzler: What version?
Hartman: It doesn't make any difference what version - it's completely hypothetical.
Dotzler: That's what I've been trying to convince the world all week!
Hartman: Maybe you're fed up. Maybe you want to be by yourself. Who knows? You look down at the screen and see the codebase in TortoiseGIT. It's crawling toward release.
Dotzler: TortoiseGIT? What's that?
Hartman: You know what TortoiseSVN was?
Dotzler: Of course!
Hartman: Same thing.
Dotzler: I've never seen a stable UI. But I understand what you mean.
Hartman: You merge some code down, change the UI, and increment the release number just for the hell of it, Asa.
Dotzler: Do you make up these questions Mr. Hartman? Or do Slashdotters just write cheap pop culture parodies instead of working?
Hartman: The project lays on its back, its belly baking in the white-hot flames of a thousand angry users, beating its legs trying to make itself stable but it can't. Not without your help. But you're not helping.
Dotzler: What do you mean I'm not helping?
Hartman: I mean you're not helping! Why is that, Asa? (pause) They're just questions, Asa. In answer to your query, it was either this or a filk based on a Rob Zombie song. It's a test, designed to provoke an emotional response. Shall we continue?
Dotzler: Nothing is worse than having an itch you can never scratch!
Hartman: Describe in single words only the good things that come into your mind about your mother.
Dotzler: My mother?
Hartman: Yeah.
Dotzler: Let me tell you about my mother... *BLAM BLAM BLAM*
"More stable than -stable", that's our motto.
Why does the summary say "then at SuSE"? Greg's still working for SUSE/Novell as a Linux kernel developer fellow right?
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I, for one, would never have guessed that. Apart from being illogical, the statement had no value regardless of the .
In fact, it's a first post, that's all there was to it, until you told. So "the upshot of all this is" that - you advertised Coors Light more than the OP! Thank you!
This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen
Wow! That's the first time the lameness filter has eaten parts of my post like that - and considering how lame some of my posts are.,, anyway on with the corrections.
After "regardless of the" there's a variable place holder in angled brackets called insert liquid here. After told, it said "me". Until you told me, it was a first post, see?
Thank you...
This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen
its ultra championship edition stable!
Yes, a static baseline is great for certification programs such as EAL and FAA approval, but it's not the only sort of "stable" that you want. Data centres want a "carrier-grade" OS (which means five nines reliability). They don't necessarily care if they have to patch, since you can now hot-patch the kernel without taking it down, but they absolutely do not want the software to show any unreliability whatsoever. They'd likely get upset at having to patch more than once a year, since in-situ patching isn't always safe, but if you're limited to a few minutes downtime a year on a server as an absolute maximum (this is ignoring failover, etc, that's a whole different issue than a specific physical or virtual server instance being five nines) then I could see it being tolerated a whole lot more than a blind kernel upgrade at year's end.
(This assumes that the hot upgrades can be made fault-tolerant enough that a brown-paper-bag release - you know they're going to happen on any tree eventually - can be backed out without violating five nines.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Wait, a piece of software moving towards a slower, more enterprise-friendly release system, in direct contradiction of recent trends (see: Firefox 10)?
What if I call it Slow Loris?
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
Ugh....
What does "enterprise" mean in this context?
Anyone who is comfy installing all applications and back porting security fixes for them that is. The packages are less than stable on FreeBSD.
Analogies don't equal equalities, they are merely somewhat analogous.
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.
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
By definition a stable system has to be running older code that's been fixed and is well understood rather then "the latest" updated code.
If your constantly churning and updating you can not be stable.
Red Had run's behind the main Linux distribution to get added stability.
But FreeBSD which seems old and stodgy is like that because of the emphasis on stability over features and improvement.
It's also simpler under the hood which is also important for Stability.
But it all depends on what your trying to do. GUI vs. Server.
For Server I'd go with BSD.
For GUI I'd go with Windows, Apple OS-X (BSD variant), maybe Android (haven't developed on it yet) X Windows just sucks.
For Embedded , I'd go with what ever the eval boards ship with. Usually Linux these days. (Certainly not PSOS or QNIX)
At this point I can compile the same code on all of these using GCC and run them equally well. They are all Posix compliant. SDL run's on all of them.
Java also run on them. So does Flash, LLVM, TCL, PERL, RUBY, Python or what ever langue du jour.
Let's end the religious wars on OS's, it's about getting your work done. The OS is just a platform for the language your want your code to run on.
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
1) insert Windows install disk
2) c: format
3) run win7.exe
4) PROFIT!!!!
And you must use & to get <.
The Tao of math: The numbers you can count are not the real numbers.
"....... I am sick of the comparison between the car and desktop-computer industries."
This is /. How dare you sir.
for such a sacrilegious statement you should go to the front counter and hand in your slashdot number and name /. without Car analogies would be like.... like....., like a car without seats.
da da da dum indeed.
Debian security support stands for more than 2 years. So if you say "more than 2 years", I'd say, that's what we get with any Debian release. So I hope that the plan is to have it for longer, otherwise it's YASM (Yet Another Suse Marketing...). There's all signs that 2.6.32 will be maintained for a long long, very long, extremely long time, since so many distro are using it.
Linux could have dominated, if there was some sort of stable API for third-party developers. Developing for the Linux platform quickly becomes an experience of insanity, when you start doing compatibility test, and the test matrix just explodes.
I'd say, if it was too hard to keep API stable across all versions of Linux, maybe we should at least have API stable for all minor versions, say, 2.6.x?
I know all the arguments for moving faster, for keeping a cleaner code base, etc. But hell, what good is a shiny kernel if the apps can't keep up with?
Just venting, from my experiences working with kernel module.
I usually have this problem more on Windows than on Linux. I'd says 95% of the time it's not really high CPU-usage, but disk or other device activity that grinds everything to a halt.
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 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.
I'm the dude who envisioned, designed, developed and shipped both autoexec.bat and Clippy, so clearly I know my shit. What the hell have YOU ever done? You know what, I don't have time for your jibber jabber, I have to finish the bootware for the Kin 3. It's gonna be the iPhone killer.
Yeah, you say that till you have driver issues on your band spanking new Dell running Windows Server. HockeyPuck, has a point that you should lab the performance of the box before deploying a bunch of Blades. The kind of money you have to put down for that! It's always wise to make sure they're going to work.
But who hasn't been there when you trust the vendors just a little too much, purchase a bunch of new gear and the OS and the Hardware simply doesn't mesh.
An example of the gamble you play with new tech. I've had a bunch of HP G5's and G4's running all on Debian we used the G4's as our DR. The G4's are 2 years older than the G5's but they kept running and running and running. Meanwhile 6 months into using the new kit it kept blowing harddisks left right centre. We patched the firmware on the controllers and presto all fixed - sometimes it just isn't the OS's fault either!
Why not use Caldera, or Corel Linux, or something as old from companies that are either no longer around, or who no longer do Linux? If it's a Debian based distro, patch it up w/ the latest from Debian, but otherwise, it seems to meet your requirements - much more than 5 years. Chances are that even Linux crackers won't be interested in those, and you can build it into anything - your garage, your car, your home security system, anything!
Dear Mr Puck,
> please sign your comment with your company
You don't sign with your company nor do you even use your real name, you are hardly in a position for such a lecture.
The company was Citrix. They did validate the hardware with load simulators running for a weeks and the problem wasn't apparent.
But a live customer load with over 190,000 live TCP session on some hosts it could still take weeks before we say a glitch, and it wasn't clear what the cause was. Some times it's a bad drive or ram. A host will die every now and again for no apparent reason. It's the nature of the beast.
Sometimes these things take months to show up on a single machine, but with a cloud with 1000's of hosts and live traffic loads, it suddenly become a constant problem.
For example say a problem only crops up every 720 hours. (24 hr * 30 days = once per month) Not unusual since it could be a 64 bit int overflowing for example.
But the QA is only for a week and the loads aren't quite the same as live traffic.
With a thousand hosts, 33 systems per day would fail.
Now with the BNX problem the host just drop off the network, meaning you can't ssh in to the host! All Logging and SNMP data just stops and the host is no longer ping-able.
You can only use the Remote console manually which is slow as mud, and a real pain.
In reality we rolled those hosts out slowly 10 then 100 and tried a variety of driver version till we found a stable one but it was still 3 times per day(Or Night at 3am even) we had to have someone reboot these and restart the software, and bring the host back in to service.
It's even worse when we would roll out a YUM update in Red Hat and it would break things. Since we were mandated to have every host be within 90 days for PCI compliance.
Once a kernel is reasonably stable you should work elsewhere. Trying to still a floating boat will not make it float any better. The boat floats.
-- The Grand Teddy Bear has Spoken: "Windows 8 Source Code Available NOW! more disgusting than your pr..."
I am http://www.linkedin.com/in/johnsokol
http://www.videotechnology.com/
http://churchofbsd.blogspot.com/
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
Kroah-Hartman says - "Consumer devices have a 1-2 year lifespan" -- this is a sign of our times. Just make junk that last a couple of years at best, and then chuck it. It would be far better to create devices that last twenty years and can be updated and repaired. This is why I like 'dumb phones'- cellphones that are less likely to be pwn3d, last longer, are cheaper, tougher, and easier to use. Ah, I am going to miss you, Nokia, and Motorola, and Siemens, and...
Isn't this exactly what cgroups is for? They have been in the kernel for about a year now.
Do you like our kernel?
It's unstable?
Of course it is.
Must crash a lot.
Often. It seems you feel our work is not a benefit to the public.
Kernels are like any other software - they're either a benefit or a hazard. If they're a benefit, it's not my problem.
Solaris got the 'slow-aris' nickname because lots of things in the kernel were designed for scalability at the expense of speed. Run it on a 1-2 processor machine, and that's overhead. Run it on a 64-processor machine, and you really appreciate it. The Solaris kernel was split into lots of largely independent threads back when Linux was still using a single lock for everything.
I am TheRaven on Soylent News
...it's the external drivers - as you point out in your post it was a kernel module that caused you massive grief. Most applications don't depend on out-of-tree with kernel drivers and thus are insulated from the kernel changes (this is why you can often get away with running a hand rolled modern kernel on "old" distributions).
However, the moment you have touch out-of-tree drivers your experience is going to be ongoing pain and it generally doesn't matter which out-of-tree driver you are using. If you are ever lucky enough to use a system that doesn't need out-of-tree drivers (i.e. you don't need the fastest graphics, you don't use Virtualbox/VMWare, you aren't using ndiswrapper for your network card, you aren't using certain virus checkers, etc) you will see a reasonable kernel experience.
A stable kernel API won't help the Linux compatibility matrix issue (wrt to the kernel) either - in addition to a stable API you would also need a stable ABI (otherwise you have to rebuild the driver for each distro anyway). To get either of these you need someone to do the work of writing and maintaining glue layers and that (like all work) is thankless, expensive, never ending work which people want if someone else is doing it but do not want to pay the price for.
You're right - it wasn't contradictory or wrong just an unusual way to highlight it :).
We are being driven by software, which then drives the hardware, which then drives more software. Sanity would seem to say that a computer which works should continue to work, and continue to be supported. No, it's not a good business model if you're a gigantic company trying to steal all the money you can until someone else puts you out of business. Why aren't there any companies picking up old software and hardware service? The best I can see is Wary 5 Puppy, which goes back to the last kernel which could still address analog modems and freezes it there, and adds just enough of today's software to make an old computer feel like it can still keep up. A lot of us poor people just can't keep buying more and more, new and newer computers. I know it's not The American Way, but we should be more like Cuba sometimes, where 1950s American cars are maintained because they can't get new ones.