| |||||||||||||
Enterprise distributions and free softwareEnterprise distributions and free softwarePosted Mar 8, 2011 0:05 UTC (Tue) by airlied (subscriber, #9104)Parent article: Enterprise distributions and free software
"we could end up with a fragmented range of incompatible Linux distributions, each of which tries to lock in customers with its own combination of unique features and proprietary information"
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.
(Log in to post comments)
Enterprise distributions and free software Posted Mar 8, 2011 0:14 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
fragmented without the lock-in is not nearly as much of a problem.
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.
Enterprise distributions and free software Posted Mar 8, 2011 0:47 UTC (Tue) by blitzkrieg3 (subscriber, #57873) [Link]
> Red Hat's move to lock down information about this kernel is an admitted attempt to increase customer lock-in; they are trying to make it harder to move to another provider of support.
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.
Enterprise distributions and free software Posted Mar 8, 2011 1:09 UTC (Tue) by martinfick (subscriber, #4455) [Link]
I agree. An example of lockin would be creating custom APIs without ever pushing those APIs upstream. Android kernels seems to have that problem, not RHEL (as far as I know).
Enterprise distributions and free software Posted Mar 8, 2011 2:03 UTC (Tue) by airlied (subscriber, #9104) [Link]
I can't parse your comment, there is no different lock-in now than there was with RHEL 5 years ago.
Enterprise distributions and free software Posted Mar 8, 2011 0:33 UTC (Tue) by ejr (subscriber, #51652) [Link]
As far as I can tell, the only benefit to "enterprise" distributions (RHEL, SUSE) over simple consulting is that deployments can use binary goo from third-party sources folks. The kernel very much can be an issue when the binary goo is a hardware driver (e.g. OFED distributions) and the hardware company refuses to talk about anything other than its binary-shipped driver (even when the source exists).
Enterprise distributions and free software Posted Mar 8, 2011 1:33 UTC (Tue) by neilbrown (subscriber, #359) [Link]
I thought a significant benefit was "stability".
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.
Enterprise distributions and free software Posted Mar 8, 2011 1:46 UTC (Tue) by ejr (subscriber, #51652) [Link]
I don't buy the stability argument. I've had fewer issues with core bits of Debian than core bits of SUSE or RHEL. Quite often "stability" means "accepting out-of-date software", which just dumps the issues onto the users.
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.
Enterprise distributions and free software Posted Mar 8, 2011 2:10 UTC (Tue) by airlied (subscriber, #9104) [Link]
stability while adding new HW support is the main intersection.
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.
Enterprise distributions and free software Posted Mar 8, 2011 2:48 UTC (Tue) by ejr (subscriber, #51652) [Link]
Ok, I'm guilty of not supplying all information. I run Debian testing+bits of unstable+tiny bits of experimental personally with rare issues. And for cluster installations, you only *need* the kernel+drivers up to whatever hardware is there, and you can pick whichever kernel + OFED level that is. Forklift upgrades still are the norm in the HPC world. Otherwise, I've been recommending a (tested, via slow VM emulating 4+ nodes) Debian testing snapshot every N months (often 12). That seems quite stable for *core* pieces in my little slice of the world. I imagine that other fixed-hardware installations are similar.
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.
Enterprise distributions and free software Posted Mar 8, 2011 13:10 UTC (Tue) by SEJeff (subscriber, #51588) [Link]
Wait a minute here. The Debian guy is complaining about RHEL having old software? Pot, meet kettle... you're both black.
Enterprise distributions and free software Posted Mar 8, 2011 13:40 UTC (Tue) by ejr (subscriber, #51652) [Link]
Personally, I'm responding from Chrome 11.0.686.3 dev, running libc 2.11.2 (ok, not the latest&greatest), compiling with gcc 4.5.2 with 4.3.5, 4.4.5, and a 4.6 snapshot available for testing... All of these come with bug reporting and fixing so I don't have to go it alone.
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.
Enterprise distributions and free software Posted Mar 8, 2011 19:42 UTC (Tue) by ThinkRob (subscriber, #64513) [Link]
In all fairness, RHEL installs can definitely "out-ancient" Debian installs: RHEL is supported for so bloody long that the versions of software that a release ships with will indeed be quite old (even compared to Debian stable) towards the end of the release's supported life.
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
Enterprise distributions and free software Posted Mar 8, 2011 19:49 UTC (Tue) by skvidal (subscriber, #3094) [Link]
You realize that this is true b/c someone is paying for it, right?
No one does that kind of maintenance for fun.
Enterprise distributions and free software Posted Mar 9, 2011 0:45 UTC (Wed) by jengelh (subscriber, #33263) [Link]
The maintenance explodes when the customer wants a feature in a package that the regular enterprise distro treadmill does not cover in its updates...
Enterprise distributions and free software Posted Mar 9, 2011 4:31 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
It isn't all or nothing. Customers can and do build custom applications or updates. Depending on the problem you want to solve, third party repos are often helpful. EPEL and IUS community project for instance.
Enterprise distributions and free software Posted Mar 9, 2011 2:14 UTC (Wed) by ThinkRob (subscriber, #64513) [Link]
> You realize that this is true b/c someone is paying for it, right?
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.
|
|||||||||||||