Slashdot Mirror
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."
We started using FreeBSD. It's stable, doesn't cost a bundle, and isn't dependent on .rpm's. Just my thought.
------------
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.
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.
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.
Of you have the talent in house and do not need support then I would suggest Gentoo? Or maybe SuSE if you want commercial support.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
We've created a minimal distro based on 7.2, with nothing that's not essential. You can optionally install RH's high availability tool "Pirahna" (snaffled from advanced server), but that's it. No X. Just enough stuff to admin the box. Everything else get's installed from source. The distro is easy to maintain; updates are downloaded by a cron job. Product End-of-life is worrying tho ....
$ strings FTP.EXE | grep Copyright
@(#) Copyright (c) 1983 The Regents of the University of California.
We have several servers running 7.3.. They run just fine. it's linux and really as long as you keep your apps and kernel up2date everything is fine. The only advantage I can see to upgrading to another version of RH is the apps that come along with it. So if the server is running RH7.3 with all patches and software upgrades on it.. I say let it run. In fact my OS of choice for servers is RH7.3 because I feel that anything above that is starting to become bloat ware. I just install 7.3.. do up2dates and customize to my liking. Has worked well so far.
I've been told straight out from the RH sales folks that they really couldn't care less about the "comsumer"/free as in beer version of RH. They don't believe that market penetration at the desktop level for general use is where they need to devote resources, therefore, they're going for the server and high-performance workstation market. Thus, we have the Enterprise AS/ES/WS products, with long-term support and more attention/quality focus. I for one like this idea of 5-year support cycles, but am worried about the increased costs, in particular at the workstation level.
I'm in the same situation as the article poster. I'm running 6.2 up to AS as well, and am somewhat confused as to what I will do with my workstation users. There's little to no economic incentive to prefer Enterprise WS over WXP. RH 7.3 and 8.0 lose support at the end of this year, and I'm not sure that 9's support will last much beyond that. It seems that the "comsumer" grade products will have only about a year of support. And, with no "apt-get dist-upgrade" equivalent, I'd have to visit these boxes personally to perform upgrades. In some cases, that's impossible for me to do, as they're embedded all over the country in remote-sensing applications.
Not really... the obvious question that springs to my mind on reading this is, "If you have enough in house talent to not need RH support, why are you even using RH?". If you want to support the company, or feel that they have the best, most stable distribution, that's fine. If it's because management said you must have a supported OS, and Redhat fit that bill, then you don't have a choice -- you need to go with one of the server offerings.
If you don't have a reason, then maybe you should rethink your reasoning for RH in the first place (I run RH9 at home, so I'm not anti-RH) and then go from there.
My suspicion is that you're better off with one of the server versions because they do offer support. Sure, you can go without, but at that point I see little advantage of paying the additional money for RH in the first place.
2 CPU's & massive amounts of memory for example
/proc/version
Piffle. My $79.95 SuSE Pro 8.1 supports at least 2 CPUs and 64 GB memory out of the box.
$cat
Linux version 2.4.19-64GB-SMP (root@SMP_X86.suse.de) (gcc version 3.2) #1 SMP Fri Sep 13 13:15:53 UTC 2002
Not that I have 64 GB of memory installed, but I am running dual CPUs.
-- Alastair
We are running into this here at work. We've been deploying RH 6.2 workstations from the beginning (more than 2 years now). We wanted a standard software configuration and stability. Until March, we've been receiving RH 6.2 security updates from redhat. Now, RH isn't providing them any more.
We are planning on upgrading to RH 9, but patch/fix support for that is only scheduled at a year! Where do we go from here? Yearly upgrades? There goes our stability model.
I was told that RH's "Enterprise" workstation product only comes with an additional year of security fixes and support, coming in at 2 years. We really need something on the order of 3-5 years.. Does anyone have any suggestions?
-molo
Using your sig line to advertise for friends is lame.
I work for a branch of a Canadian provincial gov't. We're moving from the consumer versions to the enterprise ones.
;) I just don't have time for that shit. A bit of money (and it is really only a little, when you're spending corporate $$) for less hassle? Sure...
One simple reason: I (the sole admin for 30+ servers, with development work to do on top of that) don't have the time to run around every year upgrading the systems as the version of redhat they're running gets end-of-lifed. The lack of security patches that can be quickly rolled out means that we need the longer support & release cycles.
We have several custom applications that are a real pain to install -- there is no install script. The procedure goes something like:
- install package foo
- install package bar from source
- customise the following 10 config files
- repeat for each of 10 - 20 dependencies
- grab the custom code from cvs
- compile & install
- test
- migrate user data
- no downtime allowed.
Repeat that for 30 servers with different apps, and you're starting to get the picture. Believe it or not, I'm actually a competent admin (RHCE even
Now, I did think about moving to debian stable, or freebsd, or something, but for the people left when I bugger off in a year or so, I decided to have mercy and keep the environment they're used to.
Just to add to your indecision, look at SuSE Enterprise Server 8. Runs on just about everything, up to 32 processors/64GByte, costs around $750/year per server including maintenance. And SCO may have a hard time with SuSE.
Panurge has posted for the last time. Thanks for the positive moderations.
Where I work, we're seriously considering shelling out the dough for one of the Enterprise editions, even though it feels like a bit of a scam to me.
We use several large-capacity machines to store and serve brain imaging data, and we have a lot of in-house programs that we've developed over the years. If we have to keep upgrading our version of Redhat every few months, we'll end up spending all our time testing it to make sure it's sufficiently secure, as well as re-tweaking our in-house programs. Now, you can say that we shouldn't have to tweak anything, but inevitably there's SOMETHING that doesn't work the way it used to. If we were dumb enough to deploy without testing, it'd cost us lots in downtime; as it is, it costs us in development and testing time. And then we end up having to use crap like 8, which isn't all that stable, or 9, which hadn't been out for all that long when they made their final announcement about ending support for 6.2 and 7.x.
Now, for people who have lots of gurus and lots of time to do in-house support, Enterprise probably isn't necessary. For us, it might be a good option.
Not only do we run Redhat servers here, but my employer sent me away for redhat-run classes, I got to crash at the Mariott across the street even though the training site was only 30 miles away, ate steak dinner nightly, and got my RHCE, all at no charge to moi! :)
I am now running RHN and couldn't be happier. The auto-upgrades have performed flawlessly with exceptional download speed. I contemplated using apt to substitute for RHN, but the PHBs agreed to the RHN expense. It is a great way to support a Linux company, and fairly reasonable in price ($60 basic, $90 enterprise). Manual updates are no longer an option without daily checks of bugtraq. Even then you could be too late. I had a system with outdated openssh that was cracked 2 days after the bug was announced. I was away at the time and couldn't have fixed it anyway.
I am now on RH 9 standard edition. No stability issues at all. The other versions appear to be marketing hype. But there is nothing scientific about that comparison.
---RHCE 7-2k
I think this is good advice. Consider creating a list of several different options (such as Debian or FreeBSD). Roll out a couple test machines and see if they aren't easier to administer and more of what you want.
You certainly aren't going to rely on our opinion for your mission critical stuff. Try some things out and you may find something really impresses you.
The major difference in the distributions is how they address the details of updating. They all have the same kernel and apps (well FreeBSD has a different kernel!)
So, I've seen various opinions on this, including one from Redhat. Why do I need a license for each machine running RH. Doesn't their software allow me to install one copy of Advanced (workstation/server/whatever) to any number of machines? Ok, so I can't contact their network from each machine to get updates and I get zero support, but what if I don't care? I've never needed support, and I'm used to updating RPMs by hand. So, why can't I just continue on like this?
Why are you asking Slashdot then? Why don't you go ahead and build your own distribution? Why don't you just burn a copy from an ftp server and modify it for yourself? I personally think that Redhat is providing something corporations want, they'll often stick with what works for a long time. If your company can support itself why are you asking this question?
And why pay Red Hat big bucks unless you need their expertise?
Agreed. Some do, some don't. But those who don't, shouldn't.
Are they going to stop chasing bugs in the consumer division because of the obvious conflict of interest with their revenue stream selling support?
Um, this has *got* to be a troll. First off, any company that doesn't chase and fix bugs should (and will) go out of business. Second, selling support if *not* about fixing bugs, it's about set up, maintenance, and *applying* bug fixes.
FWIW I don't use Red Hat anymore (gentoo now), but am a big fan since they helped me get into linux.
Personally its not God I dislike, its his fan club I cant stand (bash.org)
I have been looking at this problem for the last few months. I admin a small business network and the idea of paying an extra thousand plus dollars per year for per seat license for the same thing we have been getting for nearly free does not appeal to me, for a broken (no SMP, etc), non redistributable product. The choice is for me now is which distro to move to as as the option of only running the "unstable" redhat release with a very limited support life (errata, bug fixes, etc.)
Ike
p.s. Redhat has lost me as a loyal customer over this, I have been running RH since 4.2
Yes, the salesman is correct. :-) (isn't that something that almost never happens?) :-) but because, for example, they backported some features from kernel-2.5 into the distribution kernel, thus triggering some weird stuff in the VM on systems with lotsa spawning processes from Perl, or they were early adopters of glibc-2.3, thus breaking some assumption some threading applications were making, etc. All that is fine on my home computer, it's not fine on the servers that pay my bills.
;-)
The Red Hat Advanced Server is indeed the best choice for the enterprise. The consumer-grade Red Hat is interesting indeed, has nice features, but sometimes is just a bit too much into the cutting edge.
I've run several times into issues with various pieces of software when running them on the consumer grade Red Hat. No, it wasn't because "Red Hat is buggy"
If you're a small company and want to use the consumer grade Red Hat because it's cheaper, there are some tricks you can play. One of them and probably the most important, is to not start using it as soon as it gets out. Wait for a few months, i'll say at least three, then deploy it. This way, the most obvious bugs will get squashed out. Once i even deployed RH8.0 instead of RH9, because at the time SpamAssassin was not happy at all when running on 9.
Now, Red Hat choose to shorten the support for older versions of their consumer grade distribution, therefore making it more difficult to apply my advice. So, use your best judgement.
Overall, i'll say Red Hat has a three-layered approach to stability:
1. They have the so-called the Rawhide distribution, which is their perpetual beta, from which a new consumer grade distribution emerges every 6 months.
2. The consumer grade distribution, from which RH Advanced Server emerges every 2 years or something like that.
3. Red Hat Advanced Server.
IMO, the consumer grade distribution is a beta for RHAS, only they don't call it that way.
really. it's a graet desktop distro, and all the server goodies are there. same too of suse i guess, though i've never tried suse. they have done some nice work in their corporate edition and they have really nice gui interfaces, but you can easily do it all with vi and a term. in my class, i have a p3 933 with 512mb ram runnign 9.0, and it acts as a Xserver for 7 clients, runs ftp/http, has 4-5 ncp mounts at any one time, has 3-4 copies of OO.org and moz open at any one time, etc. plus, every where i go on campus i bring my old notebook, and bring up X remotely. amazes the hell outta people. when my students are in the lab, i'll have them share files via ftp and have more than 30 connections concurrently, and lots of other stuff. now, this is hardly "enterprise", but my uptime is over 150 days. i pound it really hard, and still no crash. none. seriously, drake is quite good.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
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: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.
Why would you compile the source on every server?
Seriously, this topic is pretty lame. The poster answers his own question, and the whole EOL issue is really a non-issue in open source.
Who cares if a particular piece of software is no longer supported by a particular distro? You can get either an updated version from the authors, or a precompiled version from another distro.
You can also use tools like rpm2tgz to convert rpms to gzipped tarballs, which install on pretty much any linux system.
Here's a real question: Is it possible to end-of-life a piece of software that's being actively supported by the authors/others.other distros? I don't think so. So you've EOL'd RHat [insert version here]? Big deal. Anyone can still run it w. the latest kernels and the latest software copied from your "consumer" cds. In the Open source world, EOL by corporate dictate is pretty much a pipe dream.
I would go with the enterprise solutions for 2 reasons:
- Compatibility: you can be certain that your applications are supported in the foreseeable future. Every time I upgrade version I have to check compatibility in my php scripts, perl modules, C libraries... a complete hassle... that's a strong reason for me pushing a RHEL migration path within my company...
- Certification: you get enterprise applicatoins certified for RHEL... Oracle, J2EE, backup solutions and so on... and this is good because you don't have to take a wild guess or check a compatibility list if you're trying to deploy a new solution... this is another reason for me to support the migration
I would recommend to you not to upgrade if you're running non-critical stuff or don't need certification from 3rd parties to run their products... after all it's good to know that your J2EE platform that takes care of your e-commerce website won't be supported or you'll be on your own when you don't have someone to call and are losing $$$ on the minute
my $0.02
Another is this, and quite honestly, it's important. Controlled upgrades. As of now, there are multiple upgrades almost DAILY for various packages. How many are needed, critical (security), and how many are trivial and one doesn't care? How do you control upgrades over a large number of systems? RH AS provides solutions for upgrading your system.
FINALLY
RH AS also has some components from the 2.5 kernel that are tested and stable within their kernel. An example is the new job scheduler which more efficiently utilizes hyper-threading Intel XEON CPUs.
So it's a combination of expertise, services and some advanced kernel components. As for consumers, RH will support folks using the same model as with older versions -OR- you can use thier AS Workstation and they'll support that as well.
It's a pretty good product combination of SW, solution and service. HOWEVER (caveat) for the cost, I think it's outrageous, BUT for a large environment (like where I work) it makes sense if one can buy in bulk. Even then it's high, but once SuSE comes out with something similar we'll get some better pricing...
For right now, it's not windows and that's good enough for me.
Computer Science is Applied Philosophy
It's a bit scary, but I've found the rpm 4.1.1 backport of 4.2 to be much more stable than the current version shipped with RH8 (and presumably RH9). It's now one of my standard upgrades.
--
This isn't really a direct answer to your question; it started out as one, but it gradually morphed into "what distro should I use" instead of "what Redhat should I use." At this point it's only tangentially related to the original question, but I'll go ahead and post it anyway. It may not help you specifically, but other people reading it may benefit.
****
I'm an RHCE (not an especially tough cert, btw, but someone who passes it is at least competent), but I don't overwhelmingly like their distro as a server. I should point out, however, that I have not run their Advanced Server, so I am unsure how valid my opinion is there. I have run quite a lot of RH boxes over the years; I stopped using their system around 7.0.
I'm presently running a network of about 80 machines. Most of them are Debian, and are incredibly easy to manage remotely. We have a few remaining old RH boxes, and they're very difficult to deal with in comparison -- hard to administer, hard to patch, just a royal PITA.
The support-contract option with RH can be a nice thing to have, but you say you have a lot of inhouse talent already, and Debian is very, very good as a server. I think it makes a rotten desktop client (personally I like Mandrake for that), but Debian stable is *extremely* stable, and Debian testing is just fine for most production servers. If you happen to want to run it as a desktop, you can use unstable for that, which is the bleeding-edge stuff that may break horribly.
Debian's entire emphasis is on two things: stability, and being managed remotely. They do not casually break things; by the time it gets even to 'testing' it's usually very solid. Their distributed community is really, really good. It's a great example of just how good truly free software can be.
It does, of course, have problems. My biggest gripe is probably that installation is always a new adventure. The installer is old, text-based, and not updated frequently. Getting it running on newer hardware can be a real pain, and once you have it running, you can run into weird dependency problems sometimes. (for awhile, as an example, when I did a base install, updated the source lines from 'stable' to 'testing', and then tried to install a recent kernel image, the install failed with a requirement for 'dash', but I couldn't install either dash or ash because both required ash! My solution was to drop back to stable, install ash [which had no dependency], and then switch back to testing. ) That particular problem may be gone, but every time I install a new batch of servers I run into a whole new batch of problems, be it unsupported hardware or what have you. I have never had a problem *once I have the server running*, but getting it up and stable in the first place is probably Debian's weakest point. RH has their wonderful Kickstart system, which is just lightyears better, one of the things I really, really like about their distro.
The cost in switching from RH to Debian is probably not trivial. It took me probably six months to learn, and I'm still picking up new tricks and tips. But I believe you will see an excellent ROI, as it's amazingly easy to script updates across vast numbers of machines very quickly. It's just a cleaner design, and it's easier to work with remotely. You don't really have to worry about intentional obsolescence.... there are people out there who, with great care, have been running their Debian servers for 5+ years without reinstalling. The Debian teams react very, very quickly to security issues. And it's both free-as-in-speech and free-as-in-beer.
RH, on the other hand, offers much better installation, and they have a custom version of the kernel that many people swear by. It's the best-supported of the Linux distros, and if you have a substantial investment in scripts and the RPM format, or if you need commercial application support (eg, Oracle) it's probably not worth switching. And it's easier to find people qualified in RH.
So what's best? Purely up to you. I can tell you that I'm extremely happy with a combo of Debian and Mandrake.
The five year product support lifetime really isn't something you upgrade to for your current team. It is for those that come after you leave.
Think of it this way: you deploy what the consumer version of Redhat, 3 years from now you and all of your best Admins leave for a new company. Suddenly new admins come in... with a much lower knowledge level of Redhat than you.
They come in at the end of the product support from the vendor (and, regardless of the fact you may not need it, they may.)
I would recommend that you deploy the most recent stable version that has the longest life left on the support time. Bite the bullet and upgrade everything to lower your cost of ownership in the long haul. Nuances between versions may be insignificant to you, but in the long run it is worth it to lower the knowledge level required for support. In 3-5 years, revisit the decision if you are still there. Don't do it half-ass. Make it a project for your department.
"Look! There! Evil, pure and simple from the Eighth Dimension!" --Buckaroo Banzai
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
</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
Jobs? Which jobs?
Personally, I'd take a totally different road. I had 5 redhat servers in production up until they announced they were going to put an end of life on their software. I don't disagree with EOL, but 1 year?!?! I'll end up spending all my time upgrading software on servers. Specially since upgrades don't go well unless it's from one version to another. God forbid you skip a version and try to upgrade. It wasn't long their announcement I starting installing gentoo on my servers. And now I can do the same work, with 3 servers that I needed 5 to do before. I don't care what anyone says, redhat, without spending as long if not longer doing optimizations will be as slow as pond water.
Let's move into RHN. What a huge hunk of crap!! First off, when you do any updates from RH after you've done some custom work(optimizing or even cgi wrapping). First thing you're going to ask is "what can this break and how long will it take me to fix it?". Not to mention their lack of concern about what software you actually HAVE installed. I get Errata for things like KDE or Gnome software when I don't even have X installed in the first place let alone KDE or Gnome. What's the point of us "sending our hardware and software specs" to them if they aren't going to be using it. Last thing I'll beat RH up for on RHN is, god forbid you want to remove a system or account. I removed a server a year ago from my account, still get errata for it. And recently when I migrated my servers away from redhat, I obviously disabled my RHN account. Still getting errata for all that equipment that's been "removed" and an account that's suppose to have been deactivated 2-3 months ago.
Which kind of brings me to my point. Upper management always says, "We want a product from a company so we can hold them accountable if anything goes really bad". I'm sorry, but if you install the software they aren't accountable because you agreed to the license agreement. In short is says "as is, no warranty. You bought it, now if you break it it's on you". My point is, doesn't matter what OS you use, if it goes down, you're on your own. Tell that to your upper management and see about getting something better than redhat in your midst. There's far better solutions than RH, they just happen to have started first and got a jump on everone which gave them name recognition.
One thing I'd say about the 1 year support (which is true of way more than Red Hat if you look around) is that for a lot of the desktop stuff when you want the latest and greatest you might well be thinking "need to upgrade want cool new evolution want funky new KDE 4" within 12 months anyway.
In hacker terms Red Hat Enterprise products are "boring". For some markets this has a huge appeal, for others it doesn't.
Advanced Server is too expensive - I work in a university. So I'm left with the choice between upgrading way more often than I'd like or switching to another distribution - too much work to contemplate at the moment, but Debian would be the choice if I did. (Of course if I stop using Red Hat, the Red Hat mirror I run for the university will go away... It would be kind of nice if Red Hat gave AS free to unis, or maybe to people who do evangelism for them :-)
Danny.
I have written over 900 book reviews
If not, then get away from RedHat. Far FAR away.
The main reason to move onto Red Hat Enterprise Linux is for Oracle support, as you simply won't get any under 7.x-9. If you're not dealing with ever calling up for support for either Oracle or RedHat itself, then why bother paying so much for Linux?
However, the higher-ups won't be happy about giving up an external support resource. The only way around this is documentation, and lots of it. Relying on debian packages? Running a custom apt repository? Document your policies and stick to them. Don't just install some random Linux, make an in-house distro, and with it, the documentation needed to upgrade it. This isn't a toy for a teenager and his Pentium box, it's a corporate-grade Linux distro. No downtime, no compromises. They'll want you to be able to train staff quickly, and in the end, you *are* replaceable. Don't make it too hard on yourself.
Raptor
"Procrastination is great. It gives me a lot more time to do things that I'm never going to do."
Yes, but in context, my quote makes much more sence...
"'Are they going to stop chasing bugs in the consumer division because of the obvious conflict of interest with their revenue stream selling support?'
Um, this has *got* to be a troll. First off, any company that doesn't chase and fix bugs should (and will) go out of business."
My post was in the same context of what is described above in the origional post.
But I do agree with you on those points outside of this particular context.
Two infinite things: your stupidity and mine. But I'm not sure about the latter. If my sig offends you, I'm sorry.
We still run some redhat 5.x boxen in our datacenter. Many 6.x too. Recently, 7.2 and 7.3 prooved to be pretty reliable, too.
... as long as you know a lot about it and you feel comfortable with it. Since i deployed AS on some critical servers, i find myself looking at debian and *bsd more and more...
Then came the Advanced Server thingie. I've had more problems with it than with any RedHat before, even had to fix kernel bugs to get my hardware to work properly. RedHat was aware of this particular probelm, but even with paid support, we only got 'fix in the nex errata' reply. So much for a support.
It does not matter if you have rh AS, 7.3, debian, *bsd