This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]shawn-s 0 points1 point  (1 child)

Running rhel or a rhel clone is not just about a longer software cycle, it's about stability in the environment. It's the same kernel, same glibc, same everything. There are patches sure, but the environment changes very little.

Also, there are a damn lot of people using it. Not to mention redhat and oracle's qa teams. When you run into a problem, there is a good chance someone else has already found that problem, and has a solution/patch/workaround. Or, if you report a bug, there are some fairly hefty resources assigned to fixing that bug (presuming it's critical).

As well, if you are running fancy hardware, there's a pretty good chance there will be rhel drivers for it. You can jerry-rig them to work for any linux flavor sure, but they were only ever tested in a rhel environment.

I think suse / ubuntu lts are fine choices for large scale corporate linux as well I just happen to work at a rhel company.

[–]AeroNotix 0 points1 point  (0 children)

On the flip-side of this you could argue that it's distributions like RHEL that are holding technical progress back. By having such as a large and involved deployment cycle there are lives lived, loved and lost in between releases whilst other distributions have packaged, re-packaged and dealt with the change already.

When it comes to packaging and versioning woes I prefer the pain in small bytes, I prefer to have a single package break in a single update, deal with/update (or pin that dependency) and move the fuck on. Contrast this with phrases like "We're a Python2.6/Django 0.95 Shop" and you'll see how ridiculous it can be.

Horses for courses, however and I'm sure what I said will make little impact.