Which Red Hat Should Be Worn in the Enterprise?

weatherbug asks: "I've recently been appointed as a member of a team to help determine the direction our organization is headed with Red Hat Linux. Currently we're using multiple versions from Red Hat 6.x through Advance Server 2.1. However, now that Red Hat has effectively separated their distributions into a 'consumer' (Red Hat 8,9, etc) and 'enterprise' (Red Hat Adv. Server 2.x, etc), we aren't sure which version we want to adopt. A Red Hat salesman recently told us that the 'consumer' version of Red Hat was mostly for hackers and hobbyists who weren't concerned about stability and wanted the most up-to-date software, while the 'enterprise' version would be more stable and have a five-year product lifetime. As a long time Linux system administrator, I feel that this is a sales tactic and that there really is no compelling reason for us to ever use the 'enterprise' version. After all, it is Linux and it is open source, and we have enough in-house talent to not need Red Hat support. Why would we ever need or care about a five-year product lifetime? Am I wrong, and if so, could you set us straight? We'd be interested to know what other large organizations have decided to do."

Comments

What My Organization Did:

[Captain Tenille]

We started using FreeBSD. It's stable, doesn't cost a bundle, and isn't dependent on .rpm's. Just my thought.

Security Patches

[DreadSpoon]

The lifetime applies to security patches, which is a good point to consider - are your experts up to keeping usable RPMs ready for any and all security vulnerabilities releases, across a variety of RHL products?

There's also application support to consider; the "hobbyist" version of RHL breaks binary compatibility ever other version these days, it seems. Depending on how much non-Free software you want to install, this could be a problem.

Finally, the hobbyist RHL releases tend to have lots of instabilities. There are at least several glaringly obvious major problems in every release. I haven't used an Enterprise RHL, so I can't attest that they are any better; you may find with some experimentation tho that the Enterprise RHL releases are more stable and polished, and wont take as much of your experts' time in fixing dumb distro errors.

Versions

[ceswiedler]

You answered your question yourself. If you don't want long-term Red Hat enterprise support, then go for the consumer releases. If you have enough expertise in-house to support it yourself, then great. Frankly, I would be surprised if any large organization would choose to do such a thing. Relying on hacker-experience in house is dangerous, unless you have a mammoth internal training program. The cost of enterprise-level support is far less than the cost of enterprise-level downtime. And that's not a sales pitch.

Furthermore...do you ever hear of large companies buying commercial Unixes (AIX, HP-UX, Solaris) without support contracts? Do they ever say, "we have lots of people who know unix...why do we need support?" It's the exact same thing. When it comes to support, it really doesn't matter if it's Open Source or not. It's still a big complex product which can't be allowed to break.

The advantage of Open Source comes in when you want a customized version of Red Hat deployed. You can rewrite and recompile the kernel and all applications to suit your needs. In that case, I doubt any external support organization would be able to help you.

Which RH do *WE* use?

[stanwirth]

We switched from RedHat to SuSE several years ago.

Our reasons for making the transition were:

• SuSE's stable enterprise/server editions are far less expensive than RedHat's
• DB2 UDB and Oracle are both Certified for SuSE enterprise server editions
• More specialised sub-distros available if you don't feel like twiddling and paring down the full distro yourself.
• I supported RH from 1997-1999 (IRIX, SunOS, Solaris, BSD 4.2 and 4.3 before that) My opinion is that the support database for SuSE is better than RH, and that SuSE's support is much, much better -- and not nearly as often required -- compared to SGI's or Sun Microsystems.
• When we made the transition from RH to SuSE, SuSE was streets ahead of RH in security. While not entirely up-to-date, Marc Heuse's article is a succinct and readable yet technically comprehensive introduction.

Areas in which RH and SuSE are roughly equal are:

• While RH is the market leader in the US, SuSE is the market leader in the EU. So going with the Open Source market leader because that's where the best support and latest developments are going to come from doesn't give you an answer.
• While Oracle is doing a lot of work directly with RH, IBM is doing a lot of work directly with SuSE. So going with the distro that has support from a large and highly skilled corporate because that's where the best support and latest developments are going to come from -- also doesn't give you an answer.
• Both use RPM, so if you're used to doing RPM from the command line, there is simply no change. It's very rare that I run across an RPM or a source package built for RedHat that has even minor glitches on SuSE.

As we're primarily an AS/400 development shop, with Linux just providing part of the infrastructure, it's been fortuitous that our choice, SuSE, has turned out to be the most stable distro for the AS/400 and PPC platforms.

We dealt with no salesperson in either case. Just bought the disks and support packages we felt we needed, and based our judgement entirely on what versions of what were already available on the latest release. Possibly because the RH and SuSE distro cycles were out-of-synch with each other, the latest SuSE had the more recent patch levels when we made the transition. But every time I've checked, this seems to be the case.

Re:benefits Odd.

[vladkrupin]

Why would they charge more for SMP and Memory > 4 Gig? I could have sworn that SMP was available in the standard kernel and that the Memory > 4 was just a patch.

Why? Four reasons:
1. If you can't figure out how to patch and recompile a kernel, you pay up.
2. If you can, but your boss wants "Supported 24x7" written all over the OS of choice, you pay up.
3. If neither of the above apply, but you have some spare cash, and just feel like helping RedHat out, you can pay too...

There is nothing wrong with that that. In fact, I like that model. If you are (1) you pay the "stupidity tax"; in (2) you pay the "corporate assurance tax"; in (3) you are essentially doing a charity contribution (albeit, not tax-deductable). I find myself in any of the three categories once in a while. However, Redhat just came out with a new one -

4. If you can't use Redhat9 because it's such a major pain-in-the-butt, you pay up for a decent distro (advanced server).

<rant>
It took me a couple days just to recompile all the things necessary because of the stupid Kerberos location (everything in /usr/kerberos) and OpenSSL dependency on it. That change alone broke (on source level) essentially every package out there that depends on OpenSSL and doesn't care about Kerberos. There are others
</rant>

It's not fun... Even if have the tools and the expertise in-house, it's just too painful to deal with. The time it took me to build a redhat9-based server multiplied by the $/hour my labor is worth probably was more expensive than buying an "Advanced Server" in the first place. (but on the other hand I am reading /. for the same $/hour right now, so I should probably just shut up)