Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
I'm not sure why you think the second set of requirements is necessary for the first statement to be true.
We have the first one now in the enterprise space alone we have, RHEL, SLES/SLED, Ubuntu LTS, Debian stable, and others have come/gone.
In the other spaces we have Ubuntu, Fedora, OpenSUSE etc.
its already fragmented it has been for years, the kernel used is probably the least of anyone's worries.
Enterprise distributions and free software
Posted Mar 8, 2011 0:14 UTC (Tue) by dlang (✭ supporter ✭, #313)
the kernels used by different distros used to be far more fragmented then they currently are, but since there was no lock-in, things were able to be smoothed out.
if there is lock-in, it makes it much harder to fix any of the other problems.
Posted Mar 8, 2011 0:47 UTC (Tue) by blitzkrieg3 (subscriber, #57873)
I take issue with this definition of lock-in, which is one I've never heard before. Red Hat doesn't do anything to the OS or to the customer to make it harder for the customer to move, we simply make it harder for competitors to support Red Hat software. Now if you're a business person and you say, "We could move to vendor X for Enterprise Linux support, but their support is not as good as Red Hat", I could see how that might make it "hard to move", but that isn't lock-in.
Posted Mar 8, 2011 1:09 UTC (Tue) by martinfick (subscriber, #4455)
Posted Mar 8, 2011 2:03 UTC (Tue) by airlied (subscriber, #9104)
Posted Mar 8, 2011 0:33 UTC (Tue) by ejr (subscriber, #51652)
Posted Mar 8, 2011 1:33 UTC (Tue) by neilbrown (subscriber, #359)
The vendor (Redhat / Novell / Canonical / ...) do their own QA, then release. Partners, customers, community all report bugs and these get fixed, so the kernel theoretically gets more and more stable - each customer benefiting from the bugs found by other customers/partners/etc.
The common -stable kernel series is an attempt to provide these benefits across distributions.
There are other (claimed) benefits too such as third-party certification, and incorporation of "valuable" out-of-tree patches.
So I don't think there is "only" one benefit - there are several. I wouldn't claim to suggest what the "main" benefit is though.
Posted Mar 8, 2011 1:46 UTC (Tue) by ejr (subscriber, #51652)
The third-party certification's immediate impact for me is the availability of binary blobs. I'm not trying to resell, so I can see that difference. My experience is with HPC systems, not customer-service terminals and the like, so perhaps my view is a bit skewed.
So you're right, the one enterprise benefit is a "for me" thing. The stability issue, though, I don't see as a differentiator against large-scale community distributions.
Posted Mar 8, 2011 2:10 UTC (Tue) by airlied (subscriber, #9104)
I'm not saying its perfect but it less bad than bouncing to an upstream kernel., running Debian stable is fine on 2 yr old hw, even on hw coming out now Debian stable is already behind.
Posted Mar 8, 2011 2:48 UTC (Tue) by ejr (subscriber, #51652)
And in response to another comment, for *me* the VM performs much better with respect to my multithreaded jobs than older kernels do. But I also turn off swapping for HPC installations; if you swap, you loose the high-performance part. That does eat a little memory for monitors that *could* be swapped out, but it reduces the perturbation when those monitors happen to trigger during a compute job. Turning off swap doesn't turn off mmap-ing of large data sets, so it's not a huge deal for common apps and helps stop student mistakes from crippling the nodes. Setting the ulimit at a tested maximum keeps the OOM killer at bay (or seems to do so).
But I'm also stuck with RHEL given current employer restrictions. It's not terribly OpenMP-friendly, in my experience, leading to many people griping about how "Linux" sucks.
Posted Mar 8, 2011 13:10 UTC (Tue) by SEJeff (subscriber, #51588)
Posted Mar 8, 2011 13:40 UTC (Tue) by ejr (subscriber, #51652)
With Debian (and Fedora, and...), you can pull newer versions of tools if you need them. You can at least see how the version chance affects the system even if you decide not to use the Debian version. I don't get why people insist that the named "stable" release is the only thing available. I know apt lets you set defaults to pick and choose easily, and I assume the other distributions' tools do.
I suppose it's another thing I don't get about "enterprise" distributions. You tie your timeline tightly to the producer's decisions. I'd rather be able to tie our cluster upgrade and testing timelines to our calendar.
But, again, I'm talking about systems used for development of some flavor. I suppose shipping a word processing box is different, but you definitely don't want the latest & greatest there, either. Retraining is a major cost.
Posted Mar 8, 2011 19:42 UTC (Tue) by ThinkRob (subscriber, #64513)
It's not uncommon to see a production Debian machine with versions of software that are a couple years old. It's also not uncommon to see a production RHEL install with software versions from the better part of a decade ago. RHEL wins. :D
Posted Mar 8, 2011 19:49 UTC (Tue) by skvidal (subscriber, #3094)
No one does that kind of maintenance for fun.
Posted Mar 9, 2011 0:45 UTC (Wed) by jengelh (subscriber, #33263)
Posted Mar 9, 2011 4:31 UTC (Wed) by rahulsundaram (subscriber, #21946)
Posted Mar 9, 2011 2:14 UTC (Wed) by ThinkRob (subscriber, #64513)
Oh, absolutely. I was merely pointing out that a RHEL release can and often does have a much longer shelf life than a Debian release.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds