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."
Debian. It's the best "Red Hat" out there.
Wearing a Red Shirt while on the enterprise.
Oh wait, nevermind...
Do you Gentoo!?
For now, our company has been deploying Red Hat 7.3 with all the latest bugfixes and security releases patched in. However, 7.3 is ending its product life at the end of this year, so we may have to "rethink" our strategy with using Red Hat.
-- 4 8 15 16 23 42
We started using FreeBSD. It's stable, doesn't cost a bundle, and isn't dependent on .rpm's. Just my thought.
------------
I think there's more to it than just some support and a 5 year lifetime... Enterprise addition will support many things that the other versions do not: 2 CPU's & massive amounts of memory for example
I have often regretted my speech, never my silence.
-Xenocrates
Trouble making decisions? Just flip for it.
You should choose neither! There is no Red Hat Advanced Server! They have taken all of their enterprise server capabilities from our product! We have sued the Red Hat Infadels out of existence! You will all be running SCO Unix soon!
-- SCO Information Minister Mohammed Saeed al-Sahaf
My journal has hot
Ummm... This One?
Whenever the offence inspires less horror than the punishment, the rigour of penal law is obliged to give way...
If you don't care about using their patches and updated RPMs then you don't need 5 years of support. But if you don't want to have to compile the src on every server or do your own patching some other way then the "consumer" version is not thw way to go. They tend to stop releasing patched RPM's after a while.
The Enterprise product includes these additional features over the basic product:
Systems Search/Package Profile Comparison - Search through systems based on a number of criteria: packages, networking information, even hardware asset tags.
Systems Grouping - Develop groups of systems for easier administration and maintenance. Allows maintenance of groups rather than individual systems.
Multiple Administators - Administators may be given the rights to particular systems groups, easing the burden of systems management over large organizations.
If you don't need that functionality, don't buy it.
Here you go
Trolling is a art,
If you plan to use Red Hat's support services, then use the "Enterprise" edition but if you are using self support, then use whatever version you like.
Then you probably do not have the in-house talent after all. I suggest finding a commercial OS like Solaris, HP/UX. Or FreeBSD, then you won't need to worry about support.
ive tried pretty much all of the RH versions, and I find that RH 9 is the best. I have never had a single crash once, ive never had any trouble with any of the configuration utilities, and ive never had to mess around with hardware issues(kernel modules and so on). It might just be that RH 9 suits the hardware im using very well, but I cant say the same things about any of the previous versions. Well thats my suggestion.
Selling software wont make you money, selling a service will.
If you really have enough in-house talent to not need Red Hat support why bother with Red Hat on a commercial level at all? Just download one of their ISOs (that is possible, right?) - or any other distribution for that matter - and do it all yourself. Correct me if I'm wrong but the number one reason to actually pay for a Linux distribution is the support that comes with it, isn't it?
Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
If you have enough in house talent, why aren't you using slack?
You could roll your own, ala Gentoo or LFS. Since you are bound to have many server or workstations that will need the same packages, you could have a machine(s) dedicated to creating the environment you want, and then distribute it from there. No need to compile on each machine. This will be streamlined, and potentially more secure. Of course this could be way more work than you are will to put in.
Great Linux Site
If you are, you may need support for many years for that OS version 9.x. There can be libraries that your application relies upon, but those older-version libraries might not be present in newer versions of the software that contain exploits you would want to patch, or features you might like to build around.
Food for thought.
And if you don't need Red Hat's service plan... why not just run Debian -> Stable?
The ______ Agenda
After using Redhat 8, and then redhat 9, I can definately say that their talk about stability/bleeding-edginess of their consumer versions is true so maybe the rest of what they're talking about is too. You will definately want to ensure that whatever version of Redhat you choose is compatible with whatever software you're using. For instance, I use a perlTK app at work, the version that came with Redhat 8 AND 9 was missing things and wouldn't run the app. CPAN also refused to work, in the end I had to use a third party rpm to get my app working. However, once it got going it seemed to be fine. Just make sure what you want to run is compatible, setup a test box maybe, I mean you can't lose by using the free version to test it then decide from there.
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.
Well, my org was using Red Hat 7.x, plus the $60/yr Red Hat Network stuff keeping everything up to date. When RH announced their end-of-life policy, that meant we had to upgrade a bunch of monitorless machines, we had to be physically present to do it (can't do it over the network), and we'd have to do it every year.
.. which is a lot of folks.
Our solution?
All machines now run FreeBSD and are kept up to date with CVSup. No more corporate BS. The saved $60/yr/machine covers the cost of an admin running "make buildworld" every now and then.
Once you get BSD set up just right with your make.conf and stuff like that, it's so easy to keep up to date.
I'd recommend this (or one of the Linux distros that use similar tech like Gentoo or Debian). Red Hat has made life difficult for anybody between "hobbyist" and "enterprise"
..and support linux. That way you are sure not going to miss out on anything that could be in the enterprise version.
If you see no reason to use enterprise, then don't. In that case, go with the least complex distro they have. At the very least, it might save you troubleshooting headaches later on. Perhaps put half on enterprise, in case you need the additional features, and half on the others.
Think about a mission critical system that needs to run 24x7. Every time you have to apply a patch or upgrade the system, that's downtime you can't afford.
"Enterprise" servers are one's that just work and you don't have to mess with them. That is contrary to what most sysadmins like to do with systems - that is, mess with them constantly.
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.
It's really a matter of hardware and longer development cycles. For instance, it's hard to get HP FC HBA drivers for RH8/9, but drivers for RH AS 2.1 are available. This is true for a number of HBA vendors. The same can be said for other vendor provided drivers. They don't want to release binary-only modules for 15 revs of the kernel if they don't have to.
The other side is the longer release cycle. A server doesn't need everything and the kitchen sync, but relies upon the viability of the core applications. On AS, this code is arguably more stable, and minimizes the "extra" code. Also, anyone doing Oracle on Linux needs AS 2.1, hands down.
For a simple webserver, sure; RH 8/9 is fine. For production database and application servers, I'd go for Advanced Server any day.
Feh.
If you don't stick close to the stock RH packages (roll your own kernel or apache, etc), there would really be no reason to go with a support plan, etc. If you stick closely to the RH packages, roll your own RPMS etc, it may be helpful to go with Advanced Server or the like. One thing to consider is if your org will be the same 5-6 years down the road as it is today. If it is a nice small shop that doesn't change a lot, it may very well be. If it is a traditional corporate environment, your dept may be filled with bean-heads in the next few years and it may be very helpful to leave them with a more vendor maintained rev with a support plan.
I think one thing to keep in mind is what will your tech department look like in 5 years. Shoot, 5 years ago who would have guessed things would be like they are now? Say your staff is halved in 5 years for whatever reason. Will not having official support matter at that time? I'm not trying to advocate buying Advanced Server, but you should at least keep in mind that crazy things can happen over the course of 5 years.
To some, the extra money is well worth the insurance you get.
For what my opinion it worth... We've got about 200 workstations (a decent enough size network) and we've got several RH servers... we standardize on every 3rd release (6.2, 7.2, and now 9) and don't have any problems. We've got redhat network subscriptions for updates and everything is rock solid. I see no need for "enterprise editions." Upgrading the servers every few years before end of life isn't that horrible for us... And there's usually compelling reasons like journaled file systems and new versions of ssh that justify it.
But you need to evaluate your own needs obviously.
It depends on how much you rely on RedHat after you install the product, and how much the company wants to continue to do that.
First remember to think in terms of the company. While you and your fellow admins might be uber-gurus you might not be with the company forever. Will they find other slashdot reading uber-gurus to replace you, or will they be left with less capable people?
Then consider what you do on your own. Do you install RPMs from RedHat, or do you "use the source"? Do you update your own kernel? What do you do if there's a security flaw or bug in a software package? Do you use the source or the RPM.
RedHat offers an attractive model for companies who don't want to depend on having "Bob the admin" around and would rather depend on the idea that "RedHat" will be around (the former usually isn't there as long as is around.)
Everyone company has a different culture and answer, those are some of the questions to consider.
Darthtuttle
Thought Architect
I know that if you have Oracle in your environment, Red Hat is going to push you to use Advance Server 2.1. Too be honest there is not really that much difference between the two except how they configured the kernel and advance server is specialized for clustering. Which you can do on your own. But if you are looking for support for products like Oracle or any other corporate solutions go with advance server. If you are just using it for email, web server, file server, etc (isn't linux wonderful) then stick with the "consumer version". It's cheaper.
All that is necessary for the triumph of evil is that good men do nothing. --Edmund Burke
At my office it is Red Hat 2.1 all the way. It is part of our "Security through Obscurity" initiative.
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.
If you ever want to run an Itanium2 with Linux you'll need Redhat Advanced Server. And cough up the dough too. For both the machine and the software license. Intel did a deal with Redhat to give first shot at itanium2's for porting. And with an Itanium2 there is a lot of porting to be done.
I'd personaly go with an opteron myself. You dont need to reorganize your software for the architecture so it will run efficiently. Also you are not tied to Intels linux compilers which are pretty poor quality for the itanium2. Gcc has been ported to the itanium2, but it has not been optimized well yet. And Intels compiler is just very very buggy.
RedShodan --------- Never underestimate the bandwidth of a station wagon full of tapes.
If you want an "enterprise" distribution, well, I suppose that you want to run there certified software (like i.e. Oracle), and then you should see for what distributions that software is certified to choose from (for the Oracle example, probably will be RedHat Advanced Server and United Linux in general).
If you don't meant to run certified software, and have knowledgable people there, well, probably most properly maintained distributions will do the work.
I'll get a "Real" OS from Redmond when they offer one. When will that be?
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.
I really don't think you need enterprise. If you want stable just go with RedHat 7.3. If you want some newer cutting edge stuff than look at 9 and avoid 8 at all costs.
With your inhouse talent you don't need the extra support anyway. If you are worried about updates run a local mirror and have the systems pull the updates from there using apt-rpm. There's no reason to pay for an up2date account.
And finally join the RedHat update/security mailinglist. You will be informed of any updates as they are released. So you'll know when you need to sync up your mirror and do updates.
The Product Family Comparison table on the following pages detail the differences between the Red Hat Linux and Red Hat Enterprise Linux product families. The most important differences are as follows:
Product Focus: Red Hat Linux products are designed for the Open Source movement and home/personal user. These low-cost products feature the latest technologies and provide a means for them to be exposed to the general public for extensive testing. Meanwhile Red Hat Enterprise Linux products provide fully matured and stable technologies that are specifically targeted for commercial usage.
Product Release Cycle: Red Hat Linux products are released every 4-6 months. This is necessary to keep up to date with the latest Open Source code, but is too rapid for both commercial IT deployments and for our ISV and OEM parters to keep up with. Red Hat Enterprise Linux products are released on a 12-18 month schedule, giving time for customers to plan and execute upgrades and Red Hat's partners to certify and sell their products.
Product Support: Red Hat Enterprise Linux products are provided with a full year of support services, renewable for up to five years. This includes upgrades, unlimited-incident remedial support and access to errata/patches and updates. These support services are a vital requirement for any commercial IT deployment. Meanwhile, the rapidly changing Red Hat Linux products are provided with 30-60 days of support, and a maximum of one year of errata/patch availability (from initial product release).
Product Certifications: As noted above, the 4-6 monthly release cycle of the Red Hat Linux products proved to be too rapid for Red Hat's ISV and OEM partners, so commercial customers were often unable to obtain certified solutions from vendors. The slower release cycle of Red Hat Enterprise Linux products enables ISVs and OEMs to provide fully certified hardware and software solutions.
Benchmarks: Prior to the availability of Red Hat Enterprise Linux products there were very few audited performance benchmarks available for Linux. The rapid release cycle of consumer-focused products makes benchmarking impractical. Red Hat Enterprise Linux products have multiple audited benchmark results, including several world records.
If you have the talent, don't worry about it. Just make sure that the talent never leaves, and that management will back you up on open source initiatives. My organization makes a "big" deal on having a number to call. They just haven't worked with technical support people enough to know that having someone on the other line who can't answer your question is frustrating. I like to figure things out myself.
As a warning, they do not recommend it for servers, simply because of the way portage behaves by default, but with a little hands on effort, you can easily establish a consistent software footprint throughout your enterprise. Its worked great for us in anycase.
We had various i/o and hardware related issues with AS. Plain one worked just fine.
Who knows - supposed to be the other way. But I think the issue is that AS being more "stable" and "tested" might not include the latest and greatest hw support and kernel features.
supports 64 bit itaniums too if you need em
that and they have the 24/7 "I fucked up" support
the consumer one relies on calling slashdot users for help
Not every organization, large or otherwise, has the in-house talent to do their own open-source maintenance and support. Maybe they have most of their machines running Windows, maybe not.
Beyond that, a lot of experienced tech executives, having been burned by a lack of support in the past, are not going to chance it without a service contract like the one Enterprise offers.
The arguments for and against are like the arguments for and against buying insurance, because the support contract is a form of insurance. You will never convince me that the full coverage I pay for on my vehicle isn't worth it, because at the moment my car was stolen and totalled, I received more money back than I'd ever paid the insurance company. On the other hand, you'll never convince my girlfriend -- who drives an '83 Accord -- that anything other than the minimum liability insurance the law requires is necessary.
We're both right, because our situations are different.
If you really don't need support, why are you using Red Hat Linux at all? I'd think it'd be worth switching to debian-stable... All the stability of Red Hat Enterprise, plus you get to avoid RPM and sendmail.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
This was recently discussed on the Beowulf list.
-- Don't Tase me, bro!
Other than that, the EE features only take advantage of 2+ processor machines and IA64 architectures, which aren't necessarily essential for most business applications.
I think any reasonably talented system admin can save you the expense of the other enterprise features.
There is a significant difference between the correct stability/reliability tradeoff for a desktop/hobbyist operating system and a production server operating system.
This difference is especially apparent with Linux distributions. A distribution intended for desktop use will, by nessisity, include unstable software and libraries so as to allow constantly-unstable software like media players to work. On the other hand, a server distribution will run tested, stable versions of everything.
If Red Hat is actually claiming 5 year product lifetimes for their server products then it's probably worth getting them. That will allow you to not do a reinstall until your application needs a OS upgrade - instead of needing to reinstall because Red Hat no longer supports the old version.
-- The act of censorship is always worse than whatever is being censored. Always.
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.
As one who works somewhere where the pointy haired idiots don't even want to hear the word Linux, I would kill to have your problems.
Quit whining and pick one you lucky little bastard.
"A microprocessor... is a terrible thing to waste." --
GeneralEmergency
Then you don't pay for "Support" that in the vast majority of cases you don't need.
;)
Some IT managers are scared of non-commerical distros though. It is almost like they feel they need to pay someone
In my organization, we use Oracle applications (Collaboration Suite, iFiles, etc.), and Oracle will not support installations on any Linux distribution other than AS 2.1. The way that they package updates and installers makes it impossible to use anything else. My point is that you need to look at the requirements of any software you may be running before making a decision.
You said you were a Linux sysadmin, so I'm sure you know just how stable RHx can be. I can't imagine what more the Enterprise edition offers in terms of stability. My honest opinion is that RedHat is selling a similar product to companies that are paranoid about stability. I don't think it'll make too much of a difference.
This guy was telling you to run for your life
while you still had something to hang on to:
"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..."
For god's sake, install Slackware before it's
too late!
What makes your boss feel more secure? Is your boss the kind to totally trust you and your judgement, or do they like to see some 'backup'?
Also, would you like to be totally on your own, or would you like to be able to say "Know what? I'm sick of this problem!" and call up Red Hat support? This could be helpful in shifting blame away from yourself.
Computers are useless. They can only give you answers.
-- Pablo Picasso
Do you use any commercial, 3rd party software on those Red Hat boxes? If so, you'll be better off using Advanced Server. It's a major league pain for ISVs to support 3 or 4 Red Had "hobbyist" releases per year; a more stable release stream more like a commercial OS is a blessing for ISVs. I'd rather support 4 flavors of Linux than 25.
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.
Does your server has 4CPU's and huge amounts of memory? Or, is your server one of the 2CPU $840 specials from tigerdirect? Enterprise RedHat for the former and RedHat Pro/RedHat downloaded ISO's/slackware/gentoo for the latter.
If RH is pricing itself out of the market you have other choices.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
My concerns are the following:
- Advanced server is costly. Paying >$2000/year sure does dispell that "linux is free" myth doesn't it?
- RedHat seems motivated to prematurely end support for the previous, non-AS versions. I.e., when the next inevitable OpenSSH hole is uncovered, you have to change your upgrade path after each version is EOL'ed. Perhaps they are focusing more energy on the AS versions...
- All the changes that go into the kernel to make it "AS" don't seem to make it into the mainstream as readily. I.e. scheduler, bigmem, etc.
- With bandwidth issues, and a "You must use our servers" ideology, I don't think RedHat Network is worth it.
All that being said, I don't know the right answer. Perhaps there is now room in the market for 3rd party support of the "consumer" versions or RedHat.Of course, I'm just one guy, I could be wrong.
Don't sweat the petty things. But do pet the sweaty things.
Which Red Hat Should Be Worn in the Enterprise? None, its rude to wear a hat inside! hahaha
They release their bigmem kernels as well as smp kernels
What I'm curious about is the salesman's talk about stability. Sure, it's probably just sales talk (like pillow talk, but for money), yet what if there is a grain (dare I say, kernel?) of truth?
For instance, RedHat and other distributions don't just put out stock kernels. They have their own patches they apply and make attempts to spruce things up. Granted, open source, so it's all out in the wild. Still, what if, by default, the "consumer" versions don't provide some of the nice patches that RH provides by default with the "enterprise" version? Yes, you can recompile the kernel, but perhaps that is what is meant by "stability" improvements in enterprise vs. consumer?
7.x - obsolete for business (EOL 6/30/03) 8.x - replaced by 9.x 9.x - good for desktops, at home or work, provided that *if* your company pays for Red Hat support, you don't expect to get any help. AS (Advanced Server) 2.1 - good for business, but being replaced shortly. AS - New upcoming version (3.0 or 2.2?) is the next step from AS 2.1. 8+ way CPU support, 16GB RAM, etc. ES - Business server version for small/mid sized businesses. 1 or 2 way CPU systems. WS - Business desktops. Basically, the AS, ES, and WS offer 5 year support. That probably doesn't matter to a home user, but to a business, it's good to know you can build a server and then only need to patch it for the next 5 years, without worrying about whether the next glibc upgrade will break your applications. You don't need to buy the 5 year support plan now, but if you have a problem in 6 months or a year and need extremely fast help, you probably won't get it with a "home user" release. What Red Hat is saying makes perfect sense. AS, ES, and WS will be basically the same system. WS will include desktop components that AS and ES don't need. AS will include kernels for beefier systems and will include clustering software - things ES users won't need. All three will be thoroughly tested and will provide a solid, unchanging (save for patches) target. Home users will still be able get the latest and greatest. As to your answer, if you're doing this for a business, go with AS, ES, and WS. The only reason you should be using Red Hat 9.x in a business is for your desktop if you're 1337 and want cutting edge software.
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.
...Feeding....Trollllll
-Looking for a job as a materials chemist or multivariat
There are a few ways of looking at it. The most simple being that Red Hat 9 et al are great for the desktop because they include the newest desktops and office apps without hassle. The AS edition is for the server where stability, lifecycle and support are more important.
If you are running commercial apps on the server, then have a look at what they officially support. We have two Websphere 5 servers and IBM supports Red Hat 7.3 and Suse 8.1 Pro (I may be wrong on that Suse version) on the server and Red Hat 8 for a development system. In this case, we also want support from IBM, so using AS makes sense even though Websphere works fine on Red Hat 9, Debian, etc.
The answer is really just a combination of what you're looking for. For a team of Linux experts who will update their own software, Red Hat is merely an installer. If you're going to update with RHN, then a long product lifecycle is important to keep your system secure.
The global economy is a great thing until you feel it locally.
It's a question of manpower and applications.
If you're running Big Expensive Software (Oracle or DB2, for example), you want to run a configuration that your Big Expensive Software vendor supports, and you don't want to upgrade any more than necessary. Same thing's true for in-house apps. Upgrades can take a lot of manpower (thus money). In cases like that, plunking down a few hundred (or even thousand) for a support contract and/or a configuration that's guaranteed to be supported for five years is a great deal.
On the other hand, if you're running "commodity" services and servers (i.e. the kind of stuff that's installed by default when you click the "server" box during a RH install), you probably have failover anyway, so there's no harm in running the cheap/free version of RH with some sort of internal RPM update service (AutoRPM, rpm-update, or the like) and upgrading all of those machines every year. On the flip side, it might still be cheaper for your organization to buy Enterprise or Workstation and put your "upgrade time" to use somewhere else.
The big case for the free version, IMO, is software development and desktop clients. If you're WRITING software for RH, your developers should be using the platform that they're developing for. Also, if you have a whole lot of desktop linux users, the per-seat price for the Workstation version can add up quickly.
Forward, retransmit, or republish anything I say here. Just don't misquote me.
...GO WITH WINDOWS!!!!
No matter how boneheaded a decision that may be. This is because a lot of technology decisions are made by the people least qualified to make them: the suits. The suits want someone they can go yell at. It's called "passing the buck". I think it's time that this concept were put to rest. What we really need is a lot of techies to say "the buck stops here".
When it comes to using Linux in an enterprise environment, nearly any problem can be resolved very quickly if you are experienced with the OS. This is because the OS is open. Linux makes it possible for an IT dept. to take responsibility for a problem and provide a quick resolution rather then relying on poor support and long delays between bug fixes that companies like MS foist on people.
I would say that with Redhat, it doesn't matter which version of the distro you go with because as long as you can get soure for anything you are working with, all problems can be easily and quickly solved or at the very least worked around.
They could be following what Microsoft, SCO and Sun are doing with their products to get more money on the license/support side of things. For example, the free-binary version of Solaris 9 allows you to run it on a machine with 1 CPU and have to pay more to be able to run it on 2 CPU machine (even more as you scale up to 4, 16, 32, etc.). I'm not sure if there are any memory limitations set with each processor count level for Solaris.
Windows Server (standard) versus Windows Advanced Server (nee Enterprise Edition for Windows Server 2003) does the same: 4 processor and 4GB memory limit for standard and 8CPU and 32GB memory limit for Advanced Server/Enterprise Edition. Want more processors and memory? Gotta pay more for Datacenter Edition (which is only available by OEM).
SCO's UnixWare is the same thing IIRC.
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.
However, surely the Enterprise version suffers the same security problems (for kernel and core applications) that the consumer version has ? I'm willing to bet that there's been several kernel fixes for the Enterprise version, which of course require a reboot and hence downtime. Does anyone have any figures as to how many "critical" Enterprise fixes there's been in the last year and how that compares to, say, Red Hat 8.0 ?
On the consumer side, I've decided to skip Red Hat 9 - it only gives you 4 months extra life compared to even 7.2 - with barely much difference between say 8.0 and 9 and I am waiting instead for the release after 9 to upgrade existing 7.X and 8.X machines to.
Of course, all this applies to servers - desktops can follow the bleeding edge a bit more (it's cheaper/almost risk-free to try out new releases on a few desktops and then roll them out when you're happy) and I can't honestly ever see the point of running anything other than the consumer Red Hat release on those, even on corporate desktops.
When someone has a problem with the server, do you want them calling you when you're on vacation, relaxing at home on the weekend, sleeping, etc., or would you rather have them call Red Hat support?
+1 Insightful, -1 Troll. What can I say, I'm an Insightful Troll.
I'm the admin at a modestly-sized education-related organization (phew!) and we decided on 7.3 for our web, e-mail, DNS, and backup file servers. For us it was a nice mix of:
While I run Slackware, Debian, and Gentoo at home, Red Hat just made more sense for the workplace. And in my experience there's not much difference from 7.3 -> 8.0 -> 9 except when run as a workstation, so you might as well stick with something a little more tried-and-true.
As far as the server versions are concerned, they provide the ability to support your favorite "free" software with your company's capital, and also someone "accountable" if something goes wrong. A lot of companies won't use FOSS because there's no one to sue in the event of a catastrophe.
This'll let you have your root partition of XFS, which is (IMHO) the best overall journalled FS out there at the moment, though ReiserFS is damn good too.
The problem with RH is that their installer is so damn primitive, all the useful options don't exist, so you've gotta find some other installer to give them for you.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Our scientific users are highly dependant on specific software packages for their research and data reduction. This means, once you follow the multiple "have you tried this?" arguments, is that we need to use RedHat for about half of our 150 scientific workstations (the other half are Solaris).
Due to RedHat's rearrangement of their product lines, our current "approved" version of RedHat Linux is 7.3. We will not migrate to 8.0, as it was the first release in a major version change, and we will not migrate to 9, as it is now the sandbox for potentially unstable features.
We are currently investigating the RedHat Enterprise Linux WS distribution; thanks to being an education institution, we can get volume licenses for a whole lot less than the list price. If it weren't for the price break, we'd already be looking for an alternate distribution to use. If the Enterprise WS distribution doesn't work out, we'll be looking anyway.
Why does this matter? Hardware support. The x86 hardware market will not let us buy 3-4 years behind the times. As it is, we already buy our hardware well behind the bleeding edge, and there's still the occasional compatability issue. We already custom-build most of our software from source, but the hardware support is a real sticker. Custom compiling current kernels for a highly diverse workstation clientele is not a time-effective option.
is the Slackware hat!
If not from redhat then from third party vendors. I think that eventually people like Oracle, Peoplesoft, etc are going to support their software on RH AS exclusivly because they won't have to come out with a new version every couple of months but will instead have to follow the 3-4 current versions of AS. If you don't think you will need this kind of third party support, or will only need it for some of your servers then maybe split your shop, RH AS for those platforms that need to be more stable and less of moving targets, and the standard distro for webservers, whatever that can afford to be broken once in a while because it's tracking the bleeding edge.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
First, it's not called Red Hat Advanced Server anymore. It's now Red Hat Enterprise Linux (RHEL), and there are three "flavors" -- WS, ES, and AS -- with varying hardware support, package selection, and maintenance options.
The major drivers for this are hardware and software vendors. It's simply not practical to test/certify/support a new Red Hat release every six monts, let alone kernel and glibc errata in the interim. RHEL (and SLES/UnitedLinux) give hardware and software vendors a stable target which will be supported for several years.
So if you want to use commercial software such as Oracle, WebLogic, SAP, etc., you're almost certainly going to have to transition to the RHEL products eventually.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
The stable version of Debian isn't called stable because they house some horses in it...
When you need to upgrade you can easily switch to the next version.
And it will cost you a few $ for some cd-rs.
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.
Be creative. Use Slackware (www.slackware.com).
Its more robust and better for real kernel hackers or server-side applications. RH is just more 'newbie' friendly and more for workstation development.
Redhat with advanced server tries to provide a more stable (as in not changing) target for independent software vendors, who do not like the idea of the operating system vendor releasing more frequently than them. I'm talking about big corporate staples like sybase, oracle, veritas etc, who always lag behind support for latest-and-greatest distros because they don't like moving targets.
So if you're an ISV OR use ISV software, the choice has been made for you.
Redhat also claims that they release in-house developed advanced scheduling-and-stability code in advanced server first, and then eventually to the community. THIS may be just a sales pitch - but note that advanced server is not free as in beer.
The last stable version of RedHat I use was 6.2.
Ceci n'est pas une Signature !
Sticking feathers up your butt does not make you a chicken - Tyler Durden
You folks realize that AS currently consists of RH 7.2 with a few updates. AS is still using a bloody 2.4.9 kernel!!! Go look at the srpms on redhat's site.
s e/ 2.1AS/en/os/i386/SRPMS/b /redhat/linux/updates/ent erprise/2.1AS/en/os/SRPMS/
http://ftp.redhat.com/pub/redhat/linux/enterpri
http://ftp.redhat.com/pu
There are a handfull of pacakges that aren't in 7.2, but you can download them. This will change with the next release, but right now it's pretty much RH 7.2.
It's all about the support, and certifications people!!!
IANALBIPOOGL (I am not a Lawyer, but I play one on GrokLaw.)
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.
I've never been a big fan of Red Hat. We replaced our Red Hat 6.2/7.0/7.1 servers here with Debian (some stable, some testing) and haven't looked back. There's something so comforting about never having to worry about versions and upgrades -- it's as if we've got infinite support.
Plus, I've found IRC people (what I refer to as "REAL tech support") most helpful on debian-related channels. How many times have you called up Red Hat because you needed support? Google and mailing lists are probably a more effective method anyway.
If you know your Linux, Debian is probably what you want. If not, there are several options besides Red Hat. Don't be afraid just because the name is different!
BSD: FreeBSD 5.1 Released
You must be because that devil character has points on his head!
The requirements of the organization and the specifc application need to be considered. In the consumer line, there will be a lot less rigourous testing and many more kernel and patch updates and version releases than on the enterprise side. The Enterprise package will be tested more throughly, and have a higher level of support than the consumer edition. Also enterprise offers more higher-end tools and utils for disk mgmt, clustering etc.
So if your org is fanatic about applying the latest patches and upgrades and running the latest version, then Enterprise could be a lot less work and mych more stable. As Kernel updates tend to require application re-compiles, frequent kernel upgrades could become a lot more work on the consumer edition of the product.
If your company has a lot of internal resources and you likely don't require Red Hat's assistance with troubleshooting, then the Consumer edition may work for you. Typically you see a lot of fire and forget servers being built anyway. Usually if you get a machine up and running with the app and everything is working fine, consensus tends to be don't mess with it and they will sit for years without kernel updates or patches being applied unless a specific vulnerability is being exploited.
The1Genius - Littera Scripta Manet
There is some difference. AS2.1 has been tweaked and customized more than RH6.2-RH8. Some of these customizations involved pre-loaded configurations like Samba. These might be things that your company could do on its own.
The question is what do you need? If you just need some web servers, file and print servers, etc. then I would opt for just the consumer version. If your needs are more company sensitive (databases servers, domain controllers, etc), I would go with enterprise.
I would also focus on the support side of things. Is Redhat willing to sell you the same support if you buy the consumer version? With AS, you get 24x7 support as part of the software sale.
Well, there's spam egg sausage and spam, that's not got much spam in it.
It is called Lycoris, formerly Redmond Linux.
You say you want a revolution....
I don't know what kind of piss poor system you've been using but unless my server's kernel has something seriously wrong with it that is somehow a remote exploit vunerability there is no way in hell the system is going down. Patching takes a couple keystrokes to download the patch, a couple more to apply it, and a make install in the offending directory to rebuild and reinstall that piece.
Maybe you should try a real os if you have downtime everytime a patch comes out: www.openbsd.org, www.freebsd.org, www.netbsd.org, www.debian.org, www.slackware.com. Those are good places to start (in no particular order).
obsd user
When you say things like:
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
Well - as a long time Linux sysadmin - I don't understand why you're using redhat!
And then you said:
After all, it is Linux and it is open source, and we have enough in-house talent to not need Red Hat support.
So why not go with a REAL GNU/Linux distribution like Slackware or Debian - you've got talented admins/programmers - no need for RPM or RedHat Updates. Besides the Debian APT tool is much better for updates.
You seem to have the answers - but you don't want to acknowledge them. Lose RedHat.
[Connection closed by foreign host]
Quite correct. Because paying someone puts them on the hook to fix your problems, especially the company that the product comes from. So doesn't he pay the IT department to fix it? Yes. But the adadge goes "you get what you pay for". Whether this is the case or not, it is the perception that drives the sale.
If you had to pick out a cosmetic kit as a present for your girlfriend, (with an assumption you knew nothing about make-up kits), would you purchase the $19.99 or the $120 kit?
Please no comments about the assumption. It's only to prove an argument about price.
"Last one in is a rotten goblin!" - Kepp
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
- Use a consumer Red Had product and reinstall all of your systems every year.
- Don't care about updates and simply live with bugs and security holes.
- Monitor the security/bug lists and build custom patches yourself (or find a third party to do it for you).
- Use a Red Hat enterprise product.
- Don't use Red Hat at all.
The most palatable option for our business has so far been option 5, mainly due to the cost and hassle of self-maintenance or using an enterprise product. Not to mention that Linux in general is not mature enough in certain areas that are important to our business. Our only viable option to date has been other Unix/Unix-like products.Thanks for the info, and attitude.
rpmfind.net and have no problems.
and we have enough in-house talent to not need Red Hat support
Bold statement: go for debian. I mean if you don't need support, why bother paying for Red Hat?
The site where: "I'm right, as long as you ignore the things that prove me wrong", became a valid method of debate.
At least, that's what I keep reading.*
* Here.
SuSE is very nice.
Agreed. That's why I've been using it for 3 years now. I tried various versions of RH several times over the years and came to the conclusion that it really should be called "Red Crap" Linux. I even tried the newest RH9 a couple weeks ago, and promptly decided to stay with my SuSE 8.1 and 8.2.
SuSE just works so well on my Compaq Proliant servers, and I love the LVM and XFS.
I like RedHat for their installer, it's not as full l featured as I'd like to see, but it's well on the way. They distribute a nice range of utils,apps and daeoms with the setup. But the one major drawback to RedHat is that you are pretty much locked in to RedHat forever with their RPM updates.
The other selling point is the auto-update feature that will poll RedHat every few hours to check for necessary updates to the software.
But, RedHat has a very nasty habit of moving everything from where the original developer would want it, to where RedHat thinks it should be. They also seem to obfusticate some of the configurations, in some cases removing or overriding the standard config files with a custom configurator. This means you can't, for example, simply download the newest Apache from apache.org, compile it and run it. You have to twiddle with config files to get the new Apache to locate all the existing files, or you have to move/link the existing files to where Apache group thinks they should be.
Moving between the RPM versions and the self compiled versions of software is a non-trivial isssue.
My preferred method is to use free downloaded RH to "bootstap" a system, performing a minimal install of kernel, libraries, basic utilities, development stuff, etc. I then DL and manually install the other services I need like WWW,SMTP,POP,FTP,DNS.
Most sites won't be running too much more than this services-wise, so it's not such a major headache to check for updates every few days or weeks and re-install what needs to be updated.
The RH update systems seems to be headed the way of Microsoft... hands-off, auto-updates that lock you in to their proprietary way of thinking. I don't like it. I'll do the extra work to keep that extra level of control over my systems.
Article X: The powers not delegated... by the Constitution...are reserved...to the people
It's been my observation that the Enterprise/AS lines advertise 3 years between releases, plus some additional time of errata support. I haven't seen "five years" anywhere. I've spoken to RH sales about this and been to the site. Never heard anything that long.
-j
-j
You have to consider 2 things...
1. RedHat 9 is only going to have 1 year of errata published for it.
2. RedHat Advanced Server is going to be the target for a lot of Enterprise application vendors.
For #1 - what are you going to do for errata after 1 year? Upgrade to RedHat 10? Find another source of binary patches, or hope that some other commercial entity decided to build them? Build them yourself? You need to figure this out
For #2 - many application vendors like Oracle are aiming at RHAS, simply because the "commercial" 8/9/10... distros are a target that moves too quickly. I assume that others (Veritas, etc.) are in the same boat.
My organization is small enough that people running Linux on their desktops take care of themselves and the Linux servers are few enough to be upgraded as needed. However, if your orgzanization is larger you need to consider what RHAS provides. I'd be interested in what people who have larger RH deployments are doing...
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
I think the biggest advantage to the "enterprise" offerings from RedHat is that they don't change as often as the "consumer" versions. This is good when a 3rd party software company is trying to certify their product for use on RedHat.
The 5 year life cycle of the Enterprise Linux product line is a big benefit over the 'consumer' line. If you choose the 'consumer' line you will end up upgrading all your servers each year when Red Hat quits providing package updates for the version you are running. Having a 5 year life cycle for package updates gives you a stable platoform that you can count on. Without this kind of consistenency planning becomes much more difficult. Unless you don't mind upgrading your OS all the time, you should go with the Enterprise product line.
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?
If you have the in house talent to provide your company with support and do your own upgrades, then what reason would you use red hat? Grab a free, unadulterated distribution, like Slackware, and do it from scratch.
I think red hat's strategy in having "consumer" and "commercial" versions is pretty much what you stated that they rh salesman stated. "consumer" versions can have the latest and greatest, while the "commercial" versions can be slightly older, but stable, production proven versions. In any evolving software, the more time you can let people bang on software, the more stable it will prove to be. Also, more companies will target those stable versions than they will the bleeding edge stuff, unless they are forced to through a new kernel feature.
Why on earth would you choose RedHat? Haven't you read this ?
My beliefs do not require that you agree with them.
We have a few huge custom software systems that run on Linux. Due to the nature of our business (remote PCs, POTS connections, 24-7 use) we can't upgrade very often. The less, the better. We also have a RedHat guy on staff, b/c we want and need support for a long time.
Another thing to consider is your hardware vendor. They often won't support a "new PC/old Redhat" combo. We have already bought hundreds of PCs just b/c we'll need them in a few years, but will probably be stuck with an old RedHat (unless we want to support our own software on more OS versions than we already do!).
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?
You're looking at this from a standpoint of employment insurance, which is reasonable since that is how government employees are rewarded. So buying stuff is a big pain in the butt, but hiring staff to build it yourself is easier to justify. It's convoluted.
But if you were working for a company the question would be "which costs less", supporting the solution yourself over the next 5-10 years... or buying support from a company.
Also factor into this, "What do I want to be doing in 5 years." If your answer is "continuing to support this cobbled together Linux solution" then being a Government employee is the right career for you. But if you want to be doing something different, you might want to think about what would be the easiest exit strategy for your job there, i.e. turning over your work to someone else.
Sorry for the disdain, but I used to be a government employee and I saw the way things worked.
The infinite is possible with Red Hat Enterprise Linux... You can do anything with Red Hat Enterprise Linux... Red Hat 9.0 is only for Hobbyists and Free-love, free-beer linux hippies.... This is Red Hat Enterprise Linux, and welcome to you who are spending thousands of dollars for a free OS and marketing hype....
Run with Debian. You'll be glad you did.
This isn't a question at all. He isn't 'asking slashdot' because he wants an answer.
This is a (long) rant pretending to be a question. He obviously dislikes Redhat or the idea of Enterprise Linux solutions, and wants to vent. He answers his question, not once, but twice, in the post in ways to say how useless Enterprise edition is.
Mod parent up as troll
-Eyston
And to re-state the above as the converse: The consumer-packaged RedHat Linux (7,8,9... anything other than AS 2.x) will NOT support Oracle.
Advanced Server also includes value-added features, like the Oracle clustering filesystem, and other clustering features, which won't be released into the wild immediately.
For the Enterprise it makes sense to just build your own standardized systems. Trim down the distro to fit the needs of its intended purpose.
From the nature of the question, it would seem that you have not had to make very many enterprise tech decisions. You are not thinking like a manager. Let me explain.
There is value to RH ADV SRV. You yourself mentioned a few of them. Inexperienced decision makers tend to error on the side of being cheap instead just buying the right product. The end of life support is enough to tip the scales. Upgrading a out of date RH distro that has been hacked all to hell is not something you would want to do in the enterprise level numbers.
The cost of licensing ADV SRV is a very small portion of the lifetime costs.
www.bleepyou.com
That's all it is. The enterprise kernel is a standard linux kernel with an alan cox patch set and bunch of other patches applied on top of that. It is most likely tested thoroughly on configurations scaling up to 16+ CPUs and 4+ GB of RAM. But it is no different that taking the source from kernel.org and patching it yourself.
RedHat 9, for example, just doesn't have the same type of QA or stability patches. It has a bunch of performance patches, etc. that may not have been tested thoroughly, IMO. But I haven't done much research into this.
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
I'd love to use it (the Workstation version) - I hate the thought of upgrading perfectly working installs once a year.
But they've apparently never heard of such a thing called 'site licensing'. My institution (several hundreds of installs) will *not* pay for something that's "technically" free, when the cost for it is more than we pay for WindowsXP ($50 someodd dollars compared to $179 or so for Workstation).
Speaking to the salesman, I leveled it out - Look, I said, I don't want phone, email, any sort of support. All I want are your upgrade RPMS for the five years the product lasts. No dice.
So there's your TCO of Linux. If Debian didn't ask so many dang questions during a simple apt-get upgrade (like, sendmail) so I didn't have to be there to upgrade it, we would have switched.
I'll keep watching for site license options, but until then, they're not making as much money as they could.
SuSE is muuuuch betteh!
In other words, the Oracle installer won't work (since it's based on a jre that is broken under 9 [afaik]).
9 got a new major release mainly because of binary incompatibilities due to pthreads.
I work at a large health insurance company and we chose to use Redhat AS simply because that is what our vendors require and support (VMware GSX, fibre-attaching to IBM ESS Shark).
:-)
Plus since we are an insurance company, we by nature are slow to change
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.
What is the pricing structure for AS? Is per-seat licensing involved? Can you buy 1 copy of AS and deploy it across multiple machines?
Redhat's whole server line is just a ploy to get the most money possible out of free software. Anyone who uses Redhat Linux at their company either A. Has people that will take care of the problem way before Redhat will, reggardless of whether they are in house or a 3rd party or B. Uses Windows instead
I've been using Redhat's "Consumer Line" for awhile now and will continue to do so. I have had no real problems and the ones that I did have were fixed by me.
You're heading in the wrong direction with this question.
From what I gather you've got:
1.) rock solid expierience with Linux
2.) are in a position where you're opinion weighs in
3.) are (partly) in charge when new software is installed
4.) have competent collegues
You should seriously ask yourself if you need an OSS-confectionist like Red Hat alltogether.
I'd take a small, non-showstopper piece of your network (2-3 boxen) and migrate to Debian Woody (Debian Woody being a substitute for [fill in favourite free distro here]). If it works out and you feel comfortable (which I'd allmost bet) you're gonna have a product lifetime that's top-of-the-line in the software business.
Better yet:
If fiddling with that debian stuff isn't your job and you need some in-depth tuning done for it to work out, you should definitly look for a small company that offers their own OSS solutions based on free distros . Since you are savy of all the details it would be adeqate to do some kind of cooperation, like them setting everything up debian-compliant and you paying them for the extras, adding an agreement to the contract that all extras go stante pede to debian.org as a contribution by [fill in you company name here] and [fill in your small local linuxhouse here]. Documentation included. This will ashure three things:
1.) You get what you pay for. Nothing more, nothing less. In the end you'll most certainly come out cheaper.
2.) You'll have the above mentioned, quasi infinite product lifetime
3.) You'll have a good and loyal partner for the maintainence jobs inhouse and maybe with customers and you'll get some bragging rights for supporting the superhip OSS community.
In something like a half a year from now I'd consider the company I'm about to found a viable partner for such a cooperation. From what I've read, that is.
We suffer more in our imagination than in reality. - Seneca
I say just install the most stable package of redhat you have encountered thus far and hack it until you get it the way you want it, then make a disk image of the installation.
You could make a generic image with all kinds of services ready to go and just disable and update accordingly each time you restore the image.
Look at your risks... What happens if this thing fails? How much down time is acceptable? What if you run into a problem that your in-house talent can't handle? (no offense intended towards your in-house talent). Bottom line: If this thing is mission-critical, then you want support on the hardware, application, AND the O/S. Less critical means more risk is acceptable. Is it a test / play system?... Pick your favorite free O/S. If its a production system, get support.
Why is this a choice between just Redhat consumer and enterprise? There are many other distributions out there. Especially if you already have the "talent" Do you really use the Redhat support or whatever it is they offer?
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
just install the "kernel-devel" option, switch on the SMP options, and recompile. Takes less time than writing to Ask Slashdot, that's for sure.
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.
I thought RedHat was the greatest thing in the world until I tried Debian. I now use Debian 'stable' on servers, 'testing' or 'unstable' on workstations/etc.
.debs for me, but hand tweaking is usually necessary.
It is hard to beat having security patches backported for keeping a system stable. (The other main reason I switched to Debian is that its the only distro that will install run on all the different hardware I use like PA-RISC, Alpha, Sparc{32,64}, and MIPS without jumping through any hoops).
Before anyone jumps on me with a "this other distro is even better", let me clarify that I'm posting this only to say that I think there's a better option than RedHat. In particular, other great distros like Slack and Gentoo that don't have binary package management systems (for better or worse) aren't really comparable to RedHat. Mandrake, from the few days I've used it, just seemed like a flashier and even more bloated version of RedHat.
The only downside I've found to using Debian over RedHat (or the other distros that are based on RedHat) is that some commercial apps are geared towards RedHat and only release RPMs. In particular, Compaq's Linux support software/drivers are almost exclusively in RPM format. Now 'alien' does indeed convert them to installable
And yes, it is much easier to use 'apt-get' than dealing with the RHN to get 'up2date' working.
Glad you could finally make it. :-)
:-)
On the upside, the 5 year life cycle is a good thing from an administration point of view because you don't have to worry about the product changing its feature-set on you. RH has done a good job of trying to backport security fixes to whatever version they released with the distro (not always possible, though). This is useful because most open source projects reccomend upgrading to the latest version of their software whenever a bug is found and fixed, and this can cause problems. One example was bind 8.2.2... there was a remote exploit in there that was fixed in 8.3.X, but the 8.3.X changed the requirements for how the named.conf was supposed to be configured (I think you had to add in a default TTL or something). With 2000 servers online, rolling our new 8.3.X self-made RPMs actually caused problems since our support staff had to go in and manually update all the customers' named.conf to get it up to snuff. That's what the longer lifecycle is protecting you from.
OTOH, your hands are kind of tied. There is some cool stuff coming down the pipe, and RH will be absolutely stubborn about putting it into their older distros. The line will be "that feature is going into our next version, please upgrade when it's available".
So it all gets back to what you need the distro to do. If you'd rather just have admins on the payroll to make sure the software on the server is up and running instead of keeping a few developers on the payroll and maintaining your own in-house distro (and there are a number of companies that have chosen to take the latter route), then knuckle down, sign up for RHN, and start shelling out for entitlements. Or you can find another distro to use... Debian's stable usually has a long lifetime and they do an excellent job of keeping it patched up.
Just remember that whichever option you choose, there will be much pain and expense, and before AS is EOL'd you will probably be replaced by some young gimp who calls you a "crack head" for making whichever choice it is that you will make.
Have a nice day.
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
I imagine that the very last bit would turn any corporation off Red Hat as a whole for a good long while. Exactly what sort of salesman was this?
The coolest voice ever.
"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?"
Well I'll try to set you straight without being patronising or snide about it.
In an enterprise environment, a business is run on stability and predictability. Red Hat is free, which is fine, but how much money will your company pay to make sure that someone is there to take responsibility for but fixes over the next five years? I'll give you a hint--if you're a private, profit-making company and YOU are expected to fix the OS after a year, then get out now--you'll be living in hell for another year until your company goes under.
As cliche'd as it is, companies buy solutions. I don't want to buy Red Hat v8 or 9 or SUSE whatever, or slackware or Windows XP or Solaris--I want to buy a system that does the job I give to it, and I want a vendor to back it for at least half a decade.
If you're a professional company, don't even consider trying to 'do it yourself' with hobbiest level software. Get a conservative, supported package; and work with the vendor as much as possible. Don't waste time and money trying to go it alone.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Its Linux. Therefore, no free-binary without a free-source. At least for the kernel.
-phish
Just the fact that RH had a salesperson pushing your for a more expensive product suggests that you probably do not need it (otherwise you would know what to do, right?). Unless you have applications that absolutely depend on RH I would not consider them at all. Why? Because there are better and cheaper alternatives with less bugs and more bang for a buck, especially if you have enough talent and resources. I found that from management point of view FreeBSD beats RedHat at least in updates and application management via ports. I would strongly suggest that rather than tons of money down the drain.
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.
If you are an organization that maintains a SLA (Service Level Agreement) then a 24x7 support contract is a MUST! Even if you have a crew of experienced admins. It is as much an insurance policy as anything else. I've been asked by customers what type of service contracts we have with our critical component suppliers (OS, App, and hardware.) They asked because our SLA was only as good as the SLAs and Service Contracts that backed our organization.
I have to concur with the posters here and throw my (non-red but debian) hat into the ring. I used many different distros (most RH based) until I grew up to Debian. It might be harder to install, but I don't believe anything else, including RH, can come close to Debian Stable. It is simply a whole level of stability higher than anything else in the Linux world.
The direction I see RedHat taking with the RHAS line is in pushing it as a target platform for Big Name Products like Oracle and WebSphere. You can be sure that other enterprise software vendors will be relieved to have a slightly slower-moving target on which to develop their products.
The result? Right now you can get enterprise linux software for "RedHat Linux 7.x, RHAS 2.x". In the future it will be "RedHat Advanced Server version " full-stop, and given that the "hacker" versions of RedHat will be more current in terms of kernel and glibc, that platform requiremient will likely mean something.
Ideology breeds Hypocrisy. Just how much is up to you.
From what I've seen at http://www.redhat.com/software/whichlinux.html , if you don't switch to Enterprise, you're doomed to a life of lots of upgrades. New versions every 4-6 months, security and bug fixes only for 6 months after they release the next version. If your time is valueless, stick with standard.
For my company it's simple. Some of the powers that be a level or 2 above me have convinced powers above them that we should invest in some Linux infrastructure. The powers at the top would not agree to this unless they could get the same vendor support for Linux as they have for HP-UX, Tru64 and AIX. Thus, we have RH Advance Server 2.1 with a support package from RedHat.
What does that mean for me, one of the lowly SysAdmins? Up2date only. We are not "officially" allowed to install anything from source. That's not to say that there may be a few "unofficial" Redhat 8 and 9 systems around *wink*. This official release of an Enterprise level has opened my eyes a bit as to how far along Linux is for enterprise, and how much farther it has to go, i.e. High Availability, LVM, Dynamic partition resizing..... Things taken for granted on a Alphaserver running Tru64.
"We're gonna need a bigger boat"
is not a sandbox for new features, it's really just 8.2 (if you examine version numbers of the component software).
There aren't any big jumps, like gcc 2.96 to gcc 3.x.
I've been running it (on a laptop!) and it's dandy. Much better than 7 or 8, IMO.
Fuck Beta. Fuck Dice
I use Slackware 8.1 and a uptodate linux kernel plus latest patches and fixes. None *ever* crashed or cracked...
I don't see any need for RedHat AS... don't know what's the advantage...
sorry my english...
\m/
Advantages: Enterprise Server has the long life cycle which means that if you have a database server and there is a compromise of sshd or something 2 years down the road, all you have to do is run up2date -u rather than hunt down rpms that have not been tested on your platform. Support may end up being useful Unnecessary rpms are not in the enterprise version (I believe there are about 30% fewer rpms in the enterprise version than the normal version) The kernel has been optimized for server use. Generally, these benefits are cheaper than the manpower required to make them unimportant (my favorite being the smaller default install - fewer potential holes/bugs/problems). Any serious IT department needs this kind of support. Otherwise, you're just another hack who is in the DIY mindframe which says that you are not actually thinking about the business first (which is your job after all). If you're really serious, you can also get your own up2date server running to test rpms in a test environment before you allow other machines to pull them.
Does anyone know if RH Advanced Server is redistributable? The 5-year life cycle is really appealing, if I could just download the updates. (which is what I do now, I don't bother with up2date).
But I've never seen ISO's available for AS. Anyone know why not?
run solaris
Surely you jest. Solaris is an out of date sack of shit...yes, that inlcludes 9 as well.
If you expect any off the shelf software -- whether it's DOS 4 or RedHat SuperAdvancedServer 99.2 -- to run with stability in the (presumably corporate) environment you manage, you're not doing due diligence as a sysadmin.
Regardless of what you choose, you need to do a soft rollout and test it to death (excessive load, lose a disk, simulate a crash and restore) before you unleash it on the unwashed masses. Once it has been rolled out, you need to watch for security updates and apply them manually, always expecting to have to back it out a minute later because it's flawed.
The only thing that enterprise editions buy you is the ability to point a finger at someone else when something goes wrong.
Let's take a look at a client of mine that was using CL7. He was updating all his packages using a public repository kept by Conectiva.
Unffortunetly when the new CL version was released, just a few days later, when the repository was updated, his production machines sundely stoped due to package incompatiblities.
It could be avoided if Conectiva had a upgrade plan like RH.
-=-=-=-=
I know life isn't fair, but why can't it ever be un-fair in MY favor!?
It's really dependant on the needs of your organization. If you need to know that you have a "go-to" company for support, or if you need to know that the hardware you're buying is specifically certified for the OS that you're installing, you should go with the RedHat Enterprise Linux line. If you can support it in-house, don't care about either making patches yourself, or upgrading the OS ever 18 months or so, and can generally hack it on your own, go with the consumer version.
RHEL adds clustering, but you can do that with other packages. All of the kernel updates that are in RHEL are available from kernel.org, either in a later 2.4 kernel or in the 2.5 series. Outside of that, I don't think there's much else.
We just decided to go with RHEL. But we have the aforementioned support issues. Management needs the warm fuzzies, and we have a lot of existing RedHat knowledge that can be leverages (thus making a move to an alternate distro a bad idea). Plus it's nice to know that when I, as an infrastructure person, need an answer to a question that I can't quite figure out, I can just call our RedHat rep and make them to the legwork. Sure, that might not be worth the license fees, but together with the support issues, it's what we need.
-Todd
"The details of my life are quite inconsequential..."
You'd better use Debian. Compile your own kernel and you'll have all the stability you'll ever need.
Lifetime? With apt-get it can last forever.
Omar
I'll tell you why. Because commercial software providers are generally incompetant. They are incapable of doing what Open Source applications do every day (that is, list their specific dependencies). Because of this, they list specific distributions and releases of linux they support.
With something like AS being offered with a 5 year lifetime commercial software companies will jump at the chance to require that. Then they only have to test their software with one distribution once every 5 or so years.
If you're not running commercial apps, no, you probably don't care. But if you want to run oracle, coldfusion, whatever, it's almost guaranteed you'll eventually need to go AS of some form or another.
"No nation could preserve its freedom in the midst of continual warfare."
--James Madison
... As far as I can see that's reason enough not to use Oracle's products. Red Hat 6.2/7.3/8.0 were good enough for them to port to it for years but now they aren't good enough?
It doesn't matter anyway because we'll all be running Unixware in a year and Oracle won't support THAT either.
Didn't Oracle learn before that hitching your buggy to a proprietary horse is a bad thing?
Background: I work as a system administrator for a large european corporation in the aviation field. My opinions are my own. Posting anonymously not because I fear my employer, but because I am too lazy to hunt down my password. ;)
We use Linux mostly on smaller systems, mostly web applications, but also for our company-wide intranet (10gb traffic/day) and for our mail servers (220k mails/day). As an aside, we did try Linux on a mainframe and were less than satisfied. A lot of work remains to be done with that.
Anyway, I'd like to offer a few thoughts.
First of all, who says it has to be RedHat?
Second of all, I feel that "up to date software" and "stable" are mutually exclusive. Never use the latest, newest; for professional application you want to go the route of time-tested. Pick a distro, any distro, that offers stability and timely security patches.
Finally, I think the major reason to buy any Linux distro is not only the software package you get, but the support you get for the software package. Are the security fixes timely? Does the company react in a timely manner? What SLAs do they provide? If something gets seriously fucked up, what are their garuantees, how fast will they fix your problems? If they cannot fix your problems, then what?
Let's face it, except for ease of installation, support is the ONLY reason to give money to RedHat or SuSE or whoever. If they don't offer you a really good support package, then you might as well just grab the tarballs and hope that in case anything goes wrong, usenet or google know the answer.
In our case, colleagues sat down with the major Linux distrubtors and hammered out agreements that covered pretty much anything from installation support to emergency support in case a very important server dies. It's the same kind of agreement we have with Microsoft or with IBM or with any other company that supplies us with software.
Bottom line: Ask your sales representative about the service part, and pick whatever package suits your needs. If you and your managers are really confident that in-house talent will solve any possible problem, and liability is not an issue, stick with Debian and save your organization some money (especially seeing you work for the gov't.)
I used to be a Red Hat user and at one time thought it was a good choice. Now, I know this was because I simply didn't know better. I figured it was normal for an upgrade from one version to another (6.0 to 6.1) to be iffy. After all there's so much software to upgrade, and how can they know about all your system's specific customizations. So most of the time an upgrade meant a complete reinstall and retweak, especially between major versions (6.x to 7.x).
But as I said, this was simply because I didn't know any better. Eventaully, after trying several distributions, I found Debian (http://debian.org). After a very short while it became appearent that what I was experiencing in Red Hat (and thought to be normal) was completely unnecessary. Debian's thorough Policy helps ensure that system upgrades are almost always seamless, and your system specific customizations are maintained.
So, now knowing about Debian, I would never run my business systems (or any other system for that matter) on Red Hat.
Also, you ask why a long release cycle is important. How often do you want to upgrade (or in the case of Red Hat) rebuild your business servers? Having a long supported release is critical for business systems.
In our organization we did an in-depth study of 7.3 and AS. You get several things with AS that you do not get with 7.3, 8.0, or 9.0. First, guaranteed service (three different levels). In a large organization with mission critical apps, that is important. Also, with AS you get clustering. Several flavors. And it works out of the box. Also, as has been mentioned, stability. Oracle uses Redhat AS as a reference platform. That means that everything works, including ORACLE RAC, another clustering solution. None of this is guaranteed to work with Commercial Versions. Maybe you don't need these things, but when you have a cluster of Oracle servers (and you are trying to convince management that they can save money using Linux v Windows or other Unices) this stuff is important.
The one reason I can think of for going with RH Enterprise.
..., N.x series at Oracle so if this matters to you and your organization has the bucks and the inclination to standardize on Oracle (as opposed to Postgres, MySQL, etc.) you want to go with R.H. Enterprise for those boxen running Oracle. All other boxen are stable/secure enough on the 8.x, 9.x, etc. series.
Plain and simple. Oracle was certified for RH7.1, NOT 7.2. (On some systems the Oracle Universal Installer won't even run on anything but 7.1)
The next version of Red Hat to be granted Oracle certification is Red Hat Linux 2.1 Enterprise. There are no plans to certify anything in the 8.x, 9.x,
My office has been taken over by iPod people.
I ran a hodgepodge of about 50 servers for an enterprise of around 60,000 users. I convinced management to standardize on Red Hat Linux for all my servers and completed the mirgration. My motives were that it was the cheapest and most secure solution. We got two new racks of Dell servers running Linux. It included the support from Red Hat. When Sendmail had its series of vulnerability notices a few months ago, we didn't have to download, recompile, or do anything other than click-click. Red Hat had done all the work and posted the patches. No mess, no fuss.
There are a few things that'd I'd like to see, and the main one is the 2.6 kernel. I'd like to know if once the kernel is stable (hopefully in 5 yrs :) that it will be distributed with advanced server. It seems like a major version jump would be required for something like that. I don't think they want to back port all of the new features.
Just curious
I've been a Redhat Advanced Server User for a long time, going on 6 months. I haven't had a single prob
Unable to handle kernel NULL pointer dereference at virtual address 00000040
printing eip: c01b1a66
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[]
EFLAGS: 00010046
eax: 00000000 ebx: c02d7adc ecx: cff39a78
edx: 0000b807 esi: c02d7adc edi: 00000286
ebp: c02d7a98 esp: c027df40
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c027d000)
Stack: c02d7adc cff39a60 c01ae6b0 c02d7adc
mp3's are only for those with bad memories
Your sales tech's sole point with going with the enterprise edition was that it was more up to date then the standard, but up to date changes daily, I prefer to use debian and not install what I don't need to begin with, you install debian it's just debian, then you install by a simple means what you need, you need apache, install apache, you need postfix install postfix, don't just go with the red hat install button that installs 200 daemons you are never going to need that are going to have 800 security vunerabilities found that you'll never patch because you didn't even notice in the first place that it was installed. Answer: go Debian, apt-get install and then periodically do apt-get upgrade to auto-install the latest security patches, you're good to go!
They told RedHat to shove it due to the high price and are going with SUSE.
I work for a large Medical Distributor, and was giving a free reign to choose what OS I wanted to put on our new webserver(s). After much searching I decided on RedHat 8, mainly because I know Redhat inside and out, and it was the newest RH at the time, and I wanted to try it :).
I've been using it in a production environment for about 10 months now, and am beyond pleased. It's on our primary webserver, a Xeon running Apache 2, PHP, and Tomcat and our identical backup box. Some minor compilation issues with GCC at the beginning, but a couple of months after that a update fixed it.
But yeah, I don't see any need for RHEL. It's a great concept, but unless you need the support, or cluster management I don't see why you would want to do it.
Then again, thanks to my boss and a former employee our mail/file server is a NetWare 6 box :P
Anyway, go with RH7.3, 8, or 9.
As I was reading the intro blurb discussing the various versions of RH, it made me think of Debian. Really, all along Debian has been doing the same thing that RH and SuSE are just getting around to: Offering a solid distro for long-term server use, and flavours for enthusiasts.
Perhaps Debian could adopt a slightly different naming scheme for its three versions. Maybe instead of Stable, Testing and Unstable, they could call it Debian Server, Debian Workstation and Debian Development (or somesuch.)
In my workplace we are looking to deploy a lab of Linux machines and are trying to decide what version of Linux to use. If all goes well, I hope to replace some aging Sun's with more Linux boxes in the future. While many current users prefer Mandrake, RH or SuSE, given Debian's stability and ease of management, I'm leaning toward picking Stable (and bolting on a GNOME/KDE backport) or Testing.
I have spoken with my manager about RH's position on supporting their standard distros for a year. He obviously didn't like that, but I'm afraid that I will scare him off when I tell him the price of the RH Advanced line. Debian seems like a good answer to me, but it's tricky when I explain the difference between Stable, Testing and Unstable. In fact, as soon as I mention anything other than Stable people start to lose interest.
I know that naming is a stupid thing to get hung up on, but it _does_ matter. Think of it: People's general perception of Debian (if they've heard of it at all) is that it's too old. All Debian users know that this may be true of Stable, but is not so for Testing/Unstable. Perhaps simply changing the naming convention will help people realize that this is a viable, vibrant distro, well suited to large-scale use.
I love Debian, to me it captures the essence of Linux and OSS. I certainly don't want it to become just another distro for suits, but the current naming convention makes larger deployments difficult.
So, Debian developers, what do you say? Could Debian change it's ways ever so slightly to help a larger body of users realize the potential of this outstanding OS?
Get the Enterprise version to CYA. Supposing some day something really hits the fan and it is just beyond your experience and/or your ability to fix and support. Well then what? If you have the normal version, you are screwed, and it might cost you your job. If you got the fully supported enterprise version, you ahve a resource to fall back on and someone to share blame with.
Kinda depends on how your particular company works.
Maybe it's just me, but recently RedHat released a kernel upgrade to 2.4.18 that fixed the ptrace vulnerability. But then within 12 hours released another kernel upgrade to 2.4.20. Nothing is wrong with this, except that the 2.4.20 kernel does not seem to be QA tested at all. It includes the early ptrace patch which had a bug where processes that switched user ids did not have their /proc//environ and /proc//cmdline files readable, even by root. This resulted in ps reporting that all these processes were swapped out, and ptrace not working on suid processes. This is a VERY obvious bug that should have been found in QA testing right away. There are corrected ptrace patches that fix this problem on several kernel lists.
However, while that bug is really just a minor annoyance, there seem to be other serious problems. I tried deploying it on several machines, and 3 out of 4 had severe stability problems. Only my dell workstation has worked with it. The other machines were Dell servers using serverworks chipsets. All of them couldn't stay up for more than 20 minutes, and they also wrote tons of errors to the syslog.
Late last week redhat finally released the new enterprise kernel source, 2.4.9-e.24. I compiled that and have been running it perfectly on all those same servers that had problems with the mainline 7.2 update. (We have always run the enterprise kernels on non-enterprise versions of redhat).
To me, this looks like RH skipped some major QA testing when releasing the 2.4.20 kernel just to get the fix out asap. So for me, I'll stick with the enterprise kernels, and in the future I am going to install redhat enterprise versions from the start.
And I'll also be sticking with supported redhat products, as compiling from source for over 50 servers is not fun. When redhat doesn't release an update in a timely manner, like the recent OpenSSL delay, then I'll spend the time to build my own RPMs, but I'd rather install redhat's tested RPMs.
So to make this someone more on topic, to answer your question, go with the baseline if you don't mind either installed a new OS every year, or rolling your own updates. If you want enterprise level support, and to reduce your load in administering several similar boxes, go with redhat enterprise. I think it's worth the money.
Nicodemus
Still, I fear Redhat's motives. Their code and RPMs are frequently found to be full of security vulnerabilities and remote root exploits. Now they are only going to release patches for "consumer grade" versions for one year?! Sounds almost as bad as the offerings from Redmond. Redhat should offer patches for security flaws and bugs for much longer than one year.
The other thing not to loose sight of is that Redhat is charging an arm and a leg for the Advanced Server options and for support. Advanced Server seems to be somewhat proprietary (and likely to become more so.) Redhat's offering looses something that was once a positive aspect of Linux -- relative freedom from vendor lock-in. Watch out for rising prices once they have a captive audience!
Finally, and this may be the weakest point, but the fact that Linux runs on commodity hardware and has such a large community for grass-roots support contributes to its cost effectiveness. If the intent is to run high end hardware, and pay through the nose for support contracts... what's the benefit over HP-UX, Solaris, AIX? All of those are proven operating systems from companies with years of experience providing support. HP's support is the best I've ever seen.
There's a lot of freedom in sticking with the most widely deployed versions of Linux, the ones with the biggest communities behind them. Give Debian and SUSE a good long look.
"Hey Albert, Good luck exploring the infinite abyss."
If you look at what Oracle is doing you'll find that THEY are standardizing on RedHat Advanced server (now that it is out). This means that if you want Oracle on Linux support, you better be running RHAS. It's not just marketting bullshit. If Oracle (and all these other big vendors (PeopleSoft is migrating to Linux I've heard)) is to adopt Linux, then linux must slow way the hell down and give Oracle and other companies the ability to say that they can run on this AS platform. The AS release cycle is slower but keep in mind it's not really JUST for Linux end-users, it's so these other vendors can target the platform and thus adopt it for support...a problem that doesn't really come up in the propriatary world.
Will you be running Oracle? PeopleSoft? Other apps that will be supporting ONLY advanced server? If yes, sorry pal, you need AS. If not, then fuck it. Don't worry about it then. Go with 8 or um, 9...er...yeah.
-- A cat is no trade for integrity!
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
Red Hat Enterprise releases are slower-changing and provide less of a moving target for 3rd party hardware and software developers who are trying to produce reliable and easy-to-install "solutions" for Linux.
Most Enterprises are not reliably staffed by good Linux hackers (it's a shame, but true). As such, they can get stuck trying to get binary-only distributions working on their latest-and-greatest RedHat consumer distribution. They're not used to compiling/linking their own software, and won't have the source to fix problems even if they were.
If you're not using or producing closed-source software for linux, you probably don't have to care.
I'm surprised at the level of ignorance shown in some of these posts. Deploying Linux in the enterprise is different from installing it on your own machine. The company I work for has several Linux installs including 6.2, 7.2, 7.3 and 8.0. The rapid release cycle just doesn't work for us. We have enough things to do (such as running a business) to keep updating multiple servers to the latest release.
The Red Hat Advanced Server product is just what we want. It is stable, well tested and has a long support life. The cost goes towards an annual support contract which removes the fear that Linux has no backup when there's problems. Knowing that pay for, commercial software (such as Oracle) and specific hardware models are certified for this platform makes life very easy. You need to think how some of our customers who are used to Sun or Microsoft feel about using a "toy" operating system. To them, the financial costs are not the issue, having a mature, stable and supported platform on which to run their applications is all that counts.
We've standardised on Red Hat Advanced Server ES for our Linux customers, but we're still using 8.0 internally. We have enough UNIX experience to manage our own boxes, but for customers, Advanced Server is perfect.
Red Hat may not be the most hardcore distribution, but it is the most respected in the business world. That's why we are happy to use and recommend it.
Possibly, for fairly unusual values of "true"...
There's been a lot of talk about the 'infinite' updatedness of debian/gentoo etc, due to apt-get and ebuild. This of course means you can keep upgrading the box while it is running (no 2 hour install process) and at most a reboot for the new kernel.
However, people may have not realised that redhat have recently added a new switch to up2date:
I haven't used it (and I haven't got any boxes running RH
Now RH9, plus up2date subscription (~$60) plus the new up2date could solve the "what happens at the end of RH9s lifecycle?" problem. Obviously you would have to still test all your code on the new platform etc, but this along with the other up2date options (--undo, --dry-run etc) could make life a bit easier for the folks that want to stick with the 'consumer' versions...
" To steal ideas from one person is plagiarism; to steal from many is research. "
Calling "your" president an asshole is now considered a capital offense? What paragraph of the USA PATRIOT Act included that provision?
I'm afraid my life may be in danger now. Given the choice of siding with a numbnutz redneck like you or the Dixie Chicks, I'll take those babes any old day. Go ahead and shoot me, Hinckley.
In 1999, Red Hat released RH 6.0 & 6.1
In 2000, RH 6.2 & RH 7.0
In 2001, RH 7.1 & RH 7.2
In 2002, RH 7.3 & RH 8.0
Are you including Rawhide or the betas in that count of 3 or 4 releases? I count *2* releases per year. What flavors of GNU/Linux are you supporting right now? For what products are you supporting them?
I've standardized on RedHat 7.3 as being the distribution of choice for server installs.
IMHO, it has the best mix of latest packages and stability that RedHat 9 just doesn't have. Sure, it may use older packages such as perl 5.6.1, but there's nothing stopping you from taking the src rpm from the RedHat 9 release and recompiling it for 7.3. Thats what I do if I absolutely need something from the latest release.
Brielle
sure does seem like here's a big web based business going begging, some enterprising lads who would make their own updates for the RH 7.x series. They build the RPMs with the corrected whatevers, distribute for nominal fee. I like the 7 series, I tried the 8, not happening, and really not interested in 9 because I'd have to upgrade my still functional old machine that works great now, no probs. I'm sure 9 is a nice distro and all, but for a lot of folks out there,looking down the thread, the 7 series hit a sort of high point, it's nice. It's the same on the windows side, I know quite a lot of people in absolutely no hurry to switch to XP, requiring a new computer and all, they have mostly 98, with all the patches and updates and etc, it works well enough for them.
The economy is starting to bite the big one, notice more and more yard sales and a lot more pretty new looking vehicles sitting on the used car lots and outside peoples houses with for sale signs on them. I trust that more than the 6 o clock news or the stock sellers infotainment spiels.
Most people like the idea of "a company" behind the critical part of their computer, operarting system, businesses hire full time people to maintain their machines, that leaves 95% of the rest of the world on their own. Me, I picked redhat when I switched because they seemed the largest and most stable and most likely to "be there". Not sure what I will do if the 7 series develops some critical flaw that there's no patch for, I am under no illusions of this guy called "me" writing said patch. Most likely just unplug it then.
If that was to happen, I'll switch back to my old macs, they still work, never had any sort of security problem with them-at least nothing that ever effected me. That part was s-o-o-o-o-o nice. Little slow, sure, despite that, no probs. by then maybe the upper end G3s will have dropped in price enough to get one cheap.
I like open source, don't mind paying small fees, but not really if every 6 months my OS and hardware are obsolete. There's good and bad to rapid development.
With that said, I wonder how long enthusiasts will keep mac classic running? Still millions of machines out there chugging away with it.
I am senior at a big hosting company, and we are moving away from redhat.
The main problem with the new strategy is support. All the new consumer versions will have
12 months of support, which means reinstalling every year, not acceptable.
For normal companys it just isn't possible to make your own updates, sure new kernels is easy,
but what about glibc, zlib, apache, php, minicom, etc.
Advanced server is too expensive for us, so we've decided to switch to freebsd and debian where linux is inevitable.
may be worn on the Enteprise, per order of Captain Picard. Red Hats are strictly prohibited. And the ship is running Free BSD, fyi.
Your should go with windows. after all the goverment is is pushing for windows. it is so much more reliable *cough BULLSHIT cough*. ok, ok, on amore serious note for your core servers and all the backend servers go with the more reliable enterprise redhat. for your end users, go with the consumer version(RH9). this also depend on how big your company is. if you have a buch of people and more money that you know what to do with, then go with enterprise everywhere.)
Lizard "Never let them set limits on your mind!"
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.
Primary reason is errata. If they stop doing eratta on and version of RH after one year it is useless to the Enterprise. RHEL is the only choice in this situation.
It depends on the systems you want to run.
:)
It seems a bit amusing that they suggest that desktop versions of their OS won't be as stable as the Enterprise, consdidering it runs off the same damn stable kernel.. what do they do.. write in an kernel panic after 60 days into the desktop version?
I have been using Red Hat 7.2 and 7.3 over three different servers.. the two 7.2 systems run a web cache, dns, and DHCP service which service about 800 machines each. They work like a charm. The 7.3 machine handles a webmail system - again, works like a charm.
I'll just continue to use the desktop / "home" versions with Enterprise level RHN accounts - seems to work really well even on high end Dell server gear!
"Hey! Unless this is a nude love-in, get the hell off my property!!"
Every site is different, but with declining headcount and an ever increasing number of servers we have found that RHEN makes life a lot easier on us. It's nice to apply the same patch to a couple dozen servers with minimal effort.
I used to love to roll my own for every situation. Then the number of servers climbed faster than my brain could scale. Having a long-lived distro suddenly became important, especially when running expensive third-party apps on them.
Yes, there are other distros that could be made to work. I don't like paying large $$$ for linux, but I do like having support for when we get in a jam. All in all, moving to RedHat enterprise has been the right thing for my shop.
--
Help! I'm a techie trapped inside a manager's body!
You seem to miss the major points! Companies requested a longer time between versions for a few reasons to save money and increase profits:
1. Re-use training material over an extended time.
2. Fewer upgrades mean fewer re-training sessions.
3. Consistancy improves worker performance, re-learning reduces productivity.
4. Companies pay for support of the "Enterprise" operating system, drivers, and applications to insure that support will be there when system administration staff goes through changes.
Summary: Re-developing training materials and re-educating workers takes resources away from production. While remaining competitive requires maintaining "state of the art" companies, continual re-tooling can deprive a company of the consistent and timely product required for profitability.
I think that at the end of the year where will be a lot of Linus users asking themselves, "just how hard would it be to move all my RedHat machines to something else?"
A distribution which comes out with RedHat migration tool will find their market share suddenly increase manyfold in a very short time. On the other hand, if no distribution will offer an easy install on top of RedHat which preserves existing configurations as much as possible, it's likely that RedHat install base will remain largely unchanged, in both quantity and quality (i.e. RedHat machines will simply remain as they are and people will stop installing patches when patches are not available).
Yes RedHat came out with the Advanced line of their products to make more money.
/year for their RHN stuff and you should be set.
Yes they have customers like IBM, Oracle and Dell who want upgrades to major components done much more slowly than every 6 month. They want it every 18 months at the earliest.
Yes some customers want the latest stuff, and don't care about big dog changes to their systems.
Yes companies like Oracle, and IBM will only support the "advanced" server line.
I am in the exact same boat you are in. However, because we use Oracle on Redhat we HAVE to use the "Advanced" product line. The good news is that you can get this product without support for around $350.00. That isn't horrible. Now pay around $60
What I don't know is if you can load that exact version on every server you have. I believe that you can, and then just pay the $60/year for the RHN per server.
What I would like to see RedHat do is offer a per incident suppport pack. Similar to Microsoft and Novell, you could purchase a 10 pack of calls for say a grand, and then call on ANY of your servers.
The more I learn about science, the more my faith in God increases.
I just switched my workstation from Debian to RH9.0, because of stability. The servers run debian stable.
VMWare crashed on both stable and test, but not on RedHat.
Joe
Joe Batt Solid Design
I can't remember any specific episode where they wore any hat. I think Kirk wore a fur hat in one episode on a cold planet though. I assume that the uniforms aboard the Enterprise follow the Navy tradition of not wearing hats aboard ship.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
The reason that we use redhat (currently 7.3) is to use an OS that is supported by our applications. Since RedHat is currently end of lifeing 7.3 we will probably migrate to suse, since it is the 2nd largest commercial distro, and is certified by a large number of vendors.
Debian would be nice, so would FreeBSD, but your legacy database that has been certified for RedHat only freaks out in the middle of the night, the last thing you want to hear is "I'm sorry, we don't support debian."
Definately a sales tactic. It won't be "more stable". RH isn't just "for hackers". Heck, real hackers don't use redhat anyway...
When end of life is reached, redhat will no longer provide updates, security or otherwise, most likely. So then, it's up to you what to do. Realistically, it should not be a problem for you to upgrade to a newer system by that time. Either that, or you'll have to keep track of security stuff by yourself (which you do anyway, right?)
He was speaking about the bug in RPM where the database gets locked and you have to manually erase some files to unlock it. It happens even with Red Hat "original" packages, heck it happened to me once even when using up2date.
It's been reported in bugzilla a long time ago. Red Hat has failed so far to fix it.
was use Debian.
Seriously though, as a long time sysadmin with linux experience, your own opinion is what counts. It IS a sales tactic, nothing more. It's an attempt to force you to think about issues that you never cared about before because they don't matter to you. It's a way of steering you into a certain way of thinking, so you will spend more money.
I was wondering when someone would bring this up. It's a frigging OS, you run whatever version supports the apps that keep your business running. Unless you're hosting shell accounts or something, look at your applications. Most large companies (think SAP or Manugistics or i2) won't support their apps on an OS that's more than a couple of years/revisions old. And what about new apps? When your business gets big enough that they need some new CRM app, you won't be able to get one because you're not running a supported platform.
Unless all you're running are in-house apps and you KNOW that's all you're ever going to run, stick with something that's "supported" (by more than just the manufacturer!).
Just junk food for thought...
We've had the same discussion and are leaning towards the enterprise version. The main reason being the kernal and software packages. There are several pieces of entrprise software we have been looking at which will only be writing for the enterprise version. They are doing this because of the stability of the kernal. (ie they won't have to rewrite their software five times a year)
Of course when we have looked at the enterprise version, it seems to be right around 7.3. Reading the license agreement also indicates you have to pay for support, so if you feel your team is skilled enough, you should still be able to download and use the enterprise version for free (or at a minimum pay for one copy)
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
The source RPMS are downloadable. You would have to compile them and then bootstrap a running system. Of course, you'll also have a joyous time hacking up a custom installer for your handrolled binaries.
I'm not sure what applies to the CDs that come out of a RHAS box. I imagine that even if those CDs are redistributable, you don't get access to RH's update servers and incident lines which is most of the point of running it in the first place.
If you want a free Linux with a long lifecyle, just run Debian Stable. RHAS is probably just as staid and boring (and stable...I hope) as it is.
I've been reading constant comments how redhat kernel's suck, are buggy, etc etc etc.
Doesnt anyone compile their own kernels anymore? I cant even code "hello world" and yet every linux box i roll out for clients i grab 2.4.20, tweak and tune
as needed, and everyone lives happily ever after. My company runs a couple of ecommerce web sites off rh7.3 with my custom kernels, and we never have stability problems.
Lawyers, MBA's, RIAA? A jedi fears not these things!
He is the troll.
Doh! Look at is history. Look at his reply.
Can you elaborate on requiring AS for Oracle? Is this just a certification issue, or is there a real problem running the DB on RH 9?
"All that is required for evil to triumph is for good men to do nothing." - Edmund Burke
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?
It's linux man, knock together yer own distro.
If you WANT to use redhat, then sure, 7.3 rocks. Sure as hell better than 8. 9's okay, but still not super. But really, so much of it depends on how you're using it. The kernel remains the same (meaning that you'll still have to recompile it to take advantage of this or that thing) so all you'll have to worry about is what apps you're going to be using on that box. There are usually only a few.
I mean, if I need a development box, and I want to save time by loading redhat, I've got to go in and dump all the java it comes with anyway, because the java that comes with redhat sucks for anything past a simple jsp or servlet. GCC is usually bleeding edge, and I tend to back off from that a bit, because it screws stuff up.
In short, if yer gonna use it for anythign fancy, yer gonna have to config it anyway, soooooo, why not just simplify things for yourself? Not like you need most of the stuff that comes with Redhat...I mean, do you want KDE and Gnome on your gateway firewall? Apache? Fricking Canna? (Which is mostly useless but redhat LOVES it). You can trim that stuff down to nothing, and have a great distro that does just what you like.
Just my opinion.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
First Post? If this was supposed to be the first post, it must really have been brought to us by PBS.
Seth your back man, now what is it with you and Sims ? did he fuck your mother?
you sir are such a loser, and I bet your penis is soo soo small.
heck sometimes i wonder if you are the guy at goatse
I pretty much agree, but let me point out, contrary to popular belief, Slackware does have a binary packages system, has for ages, and it works real well. Those tarballs have install scripts, you use the package manager and it runs them and keeps a database so they can be cleanly uninstalled. The main difference between Slack and Debian/RH in terms of package management is that it doesn't try to keep track of dependencies - which after fighting with Redhat for awhile seems like a really good choice. I know the argument over whether it's better to do it one way or the other can go on forever, and I'd rather not rehash it yet again, but the point is it's simply incorrect to claim Slack doesn't have package management. It does, it was the first with it I believe, it's just that it follows the slack philosophy of simple elegance and doesn't try to do everything.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Obviously!
thank you thank you, I'll be sacraficing Karma all week.
-pyrrho
I recently migrated some of the (tens) of servers I manage to Debian. I was a little worried initially because I was afraid to waste all the years of expertise on redhat.
Well, after a couple of weeks of studying and testing, I must say I'll never go back.
Debian simply rules.
Try it out.
Alex
assuming you are not a troll, this guy is harrasing Michael Sims a /. editor, the guy is mentally unstable, a lunatic, and a dedicated troll who created 10s of slashdot accounts, and ran automated scripts to post messages every time sims submits a story.
a true rare case.
If you're planning on using Red Hat in your enterprise, these are my suggestions before proceeding:
.Net Framework for Linux is a great example of programs not working due to major changes in versions of operating systems.
1) DON'T listen to the Red Hat salesmen, their whole existence in life is to sell you their product. Get a rough idea what you want to implement and go to the product newsgroups/forums/websites for information on what to do. Products like Apache, Samba, and the various Unix SQL products are the big products I place under this 'umbrella'. I place other administrators experiences and advice in higher regard than the average salesman/person.
2) Be wary of changes in each of the new versions of Red Hat as file system and other system changes may render a program, that works on a pervious version of Red Hat, completely useless. Microsoft's
3) Are there other flavors of Unix in your enterprise? If so, you're going to have to do a TON of dev homework to get technologies such as Kerberos implemented into your enterprise. The reason I say this is that the master source code is designed to work, out of the box, for Free BSD. The Kerberos distribution for Red Hat works for Red hat. However, if you're implementing (for example) IRIX machines into your enterprise, you'll need to know things like the IRIX command line tags to run various Kerberos programs and then port them from RedHat/Free BSD to IRIX.
4) Read any non-GNU licensing, support, and upgrade agreeements VERY carefully before proceeding with a potential purchase.
5) Make sure their Hardware Compatability List for Red Hat will be acceptable for your company's budgetary requirements.
Good Luck!
Dolemite
_____________________________
Save the World! Use a Quote!
Can you picture the weeping Penguin. Its not clear what exaclty you use the servers for but if you have the in house expertise go with the "consumer" Redhat. I never thought i would see the day that i would hear a Linux pitch from a snakeoil salesman. The commercialization of Linux is like capitalism. It could be the best thing that happened or the worst. No one doubts the contribution that redhat has made to the Linux and the open source movement as a whole, but I'm sure I'm not the only one who has noticed a Redmond type thinking emerging over at Redhat.
I use it to keep KDE up to date all the time. Freshrpms also keeps a lot of libs up to date for me too.
RH users should checkout http://freshrpms.net/
Do not spread "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0" over the internet, thank you.
If you want to stay with x86 hardware, Solaris 9 x86 might not be silly. If you want to stick with Linux, forget RedHat and go with Debian or Trustix.
Debian -> Stable for all my servers.
Debian -> testing for all my workstations and my video encoder machines.
Debian -> unstable for MY workstation and home machine because i'm adventurous.
My few encounters with redhat have all been quite unpleasant.
I can't believe people actually use redhat for servers... that just seems wrong to me. The very first thing I do when we order a new colocated server is to log in via ssh, install debian and a custom kernel then reboot.
Call me crazy but i don't think a server should have X and all the related gui apps installed at all.
Unfortunatly we are in the same boat. We currently have Redhat running alot of our Oracle database servers. Oracle won't support anything but Advanced Server. The reason we got into linux was because of the stability and the cost. Advanced Server's price is to much for us to swallow and we don't need no steaking support from Redhat. Looks like we might have to go back to Solaris.
For what it's worth, there are a lot of people in the industry facing this problem, and every one I've talked to has made the same decision. Red Hat probably doesn't care though, since they aren't losing paying customers. Expect to see a lot of work go into automated installation tools for other distros soon, because the demand is definitely there.
If you're running a binary-only package from some ISV that is not agile enough to track Red Hat's releases, you're probably better off with the Enterprise version's longer life cycle -- unless, of course, you're not at all concerned about updates and patches becoming unavailable for your OS. On the other hand, if you're running only Free Software, you're probably better off tracking Red Hat's mainline releases (but not too closely).
***offtopic***
Moderators, I've been seeing a higher number of trolls modded 3 and above.
I don't know how in the hell you idiots got karma, but I will get you in metamod..
***offtopic***
Moving along, Debian isn't going to give you an extended product life over RH's consumer distro.
What in the hell doesn't run on FreeBSD that you'd want a server on?
Click on the Microsoft link. Read the URL. Nice try to redirect us to goatse, Asshat.
Finally, just read this guy's Journal.
From a boss' point of view, it's simple. You pay for Enterprise. You don't for the free version. As they see it, you always get what you pay for. My shop just bought a dozen copies of ES. The software may be marginally more stable, but really you're paying (and paying, and paying... those are yearly support fees, NOT one-time purchase costs) for the time savings of the product. Why? Support, ease of maintenance thru Red Hat Network (a fabulous thing), and the ability to upgrade when _we_ want to, not when Red Hat cuts off the errata (incidentally timed to fall near the end of the school year, making it darn tough on us education folks). Also, the fact that the software and kernel get to mature a bit are a Good Thing. I'm not an idiot and am perfectly capable rolling our own software from source, but why waste my time on that and keeping up to date with all errata from the mailing lists when I can have Red Hat do it for me? There is a lot of man-hour savings in the support and red hat network components of Enterprise, which means I can spend my time working on my boss' pet projects. He gets stability, I get to keep my job. Sounds like it's worth something to me.
Something that nobody seems to have mentioned. It may be true that you have lots of in-house Linux expertise. However, your company should think about opportunity cost. They have certain standards to meet in terms of uptime, security, etc. Can they meet them more cheaply by having in-house people spend time on the server maintenance? Or can they hive that off to Red Hat, and your in-house people
(a) can spend time doing required development work and stuff that actually makes money, or
(b) can be laid off (ouch!)
Just because you have the expertise, doesn't mean you ought to be using it.
It seems to me that the attractive part of the license subscription to the advanced/enterprise server for some is the support/RHN access. But what if you're a shop where that's a waste? You do all the support yourself, and grab the updates from a mirror anyway and don't use RHN, but you like the fact that you're not going to have to deal with an EOL product every year. If you need to call in and get help from RH, then you can pay a fee. One of the reasons why companies want to go to linux is to get rid of the licensing manager crap & audits.
I realize that RH needs a better revenue stream, but they should for users that want to make one time purchases for the software and aren't a burden on their support staff or networks.
the good ground has been paved over by suicidal maniacs
There are a plethora of 'enhancements' in AS 2.1 ( which I guess is now Red Hat EL-AS ) that Oracle can take advantage of. You may want to give this whitepaper a read for some in depth look at some of the "Performance, Reliability, and Manageability Encnhancements on Red Hat Linux AS 2.1" I'm not a big time Oracle person, but my understanding is that many of these enhancements are only applicable on larger systems (by larger I mean 2+ CPU/>2Gb RAM).
Here is a feature chart comparing EL-AS, EL-WS, and EL-ES. As you can see you there are differing levels of support for things like ia64, large amounts of RAM, and >2 CPUs. This definately isn't at 'salesmen screwing with you' type of thing. There are definately some things to consider when deciding between going with AS or not. I would have some concerns about this becuase you are asking slashdot about this when there is a decent amount of data on redhat.com explaining the differences between their different OS releases. If, as you claim, you have in house people with the skillsets to manage you linux systems you might not even need redhat at all, just roll your own that meets your needs. If, on the other hand, you require and OS that is certified by your other software vendors then your purchasing decision will be swayed by that requirement, and most likely swayed towards the AS/EL-?? line of products (or suse or ).
Bleah.
Enough rambling and spelling mistakes for this post.
with little pointy red horns on it.
Seriously, my Athlon would not even boot RH9 to do the install. Decided I would wait till it got to the 11 release to try it again.
Never answer an anonymous letter. - Yogi Berra
Slackware 9.
I'm not crazy about salesmen, (regardless of the colour of their hats), using the support lifespan of a product to sell it - "we're going to stop fixing our bugs unless you keep giving us money". However, it is not an unreasonable concession to make for customers that probably spend $20K/year/head on computing infrastructure.
Perhaps the real reason that a viable business model exists for OSS products is because it is actually *worth* something to a customer to have their software bugs fixed in a timely manner. Meanwhile, for those of us willing and able to look after our own systems, bleeding edge is simply good enough.
In the case of the original poster, I don't doubt that his organization could keep Linux and its applications suitably patched. However, since RedHat's distro includes so many patches, it becomes progressively harder to keep applying non-RedHat patches from the original authors. This is, in large part, what you are paying for.
you know you need it
WebSphere Application Server 3.5 supported in Linux was for several distros: RHat 6.2, Caldera 2.3 e-Server and 2.4 e-Desktop, Suse 6.4 and Turbolinux 6.0.x Server. The installation aslo had to include glibc-2.1 But there's a new version of WSph., so that may have changed.
IP was invented for the sake of lawsuits.
If red hats are anything like red shirts, then when the Enterprise crew beams down, you definitely do NOT want to be wearing ANY KIND of red hat.
The thing is, I don't recall seeing any of the Enterprise crew wearing hats of any color, let a lone red.
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.
;)
So... Red Hat Enterprise == Debian???
From my perspective, the benifits of Advanced Server are 1) Thoroughly tested more advanced kernel, 2) Stability 3) Longer Lifetime (5 years) 4) Much better support.
The first two really could be achieved from building from source, using debian or gentoo. However, items 3 and 4 for an enterprise matter a lot. Why do you think Microsoft has supported NT 4.0 all these years? The thing is that if you're completely confident that your staff is as capable as redhat or you plan to build large portions of the OS from source, get RH 9, or even better Debian or Gentoo. However, if you're like most enterprises, who have people who have messed around with linux, have a couple linux system administration books lying around, but really couldn't solve a big crisis if it hit them, the AS version is your cup of tea. For mission critical use, I'd choose the AS version every time, if it weren't for the cost.
Possibly, for fairly unusual values of "true"...
Try this in perl:
if ("God") { print "God is true\n"; }
if ("Evolution") { print "Evolution is true\n"; }
If I have been able to see further than others, it is because I bought a pair of binoculars.
Yes, you can do what you like with linux. You understand linux.
Unfortunately, two people don't:
1) Your boss
2) People like oracle
Lets get number 2 out fo the way first. Oracle installs using java. It requires various kernel tweaks to run reliably. The installer is compiled against one version of glibc, when the main running program is compiled against another (draw from this what you wish). but the basic point is that oracle is only certified against the systems they know to work, and that's outdated crap with big price tags.
oh, and 1) your boss.. he doesn't believe you because you don't have a label attached to yourself.
I am sure someone else will say this but... Employees come and go (more going than coming these days) and (I hate to say this) if you have a vendor support contract you are not as locked into who you keep or let go, but you are locked into a vendor.
The second point is that if you are developping for Red Hat, then it makes sense to develop for the Advanced Server releases as these will be the most stable over time. Therefore, it makes sense to have at least some versions of AS lying around.
Last point, from what I understand the difference between AS and regular Red Hat is that AS is simply the "best of" Red Hat over the last 18 months plus some enterprise hooks. An 18 month life cycle is also a decent one for doing upgrades. Do you really want to upgrade every six months?
[Slack] doesn't try to keep track of dependencies - which after fighting with Redhat for awhile seems like a really good choice
:)
Which statement only makes it obvious that you've never used Debian. As someone who went from SLS to Slackware to RH to Debian, perhaps I can explain. Dependencies are:
In Slackware: things that would allow your apps to run, if only you knew what they were.
In RedHat: things that would allow your apps to install, if only you could find them.
In Debian: things that got installed for you without any need to worry on your part.
[Slack] does [have a package management system], it was the first with it I believe
Begging the question, is what Slack offers really a package management system? (You can call cat(1) an editor, and people have used it to create files, but it doesn't meet most people's definition of a text editor.) No Slack wasn't first. SLS was first, and the Debian project was founded at almost the same time as the Slackware project, so that's nearly a tie there too. (Although Debian's first official release was later than Slack's first official release. But then vi took longer to write than cat did too.:)
it's just that it follows the slack philosophy of simple elegance
IMO (as a former Slack user), Slack goes beyond "simple elegance" into the realms of painful inadequacy, but I realize that not everyone agrees with me. Then again, there are people who routinely use cat(1) to create text files too...
In a few years when RH7.3 is too old I'll prob move to gentoo or debian.
---- Put Sig here:
Pretty much the winner as far as we are concerned. AS is a platform the Oracles, Veritas's, Computer Associates (bleuch), EMC's, Emulex's etc etc etc devloper their code for. You can't run an enterprise on GNU + linux alone. And it's no good having something tha sorta works, it needs to be supported to work in the enterprise. At the end of the day, you need to be sure that there is a contract riding on a firm being able to fix something and meet you requirements, not just an interested dev. That goes for the distro too - hence AS for us, despite the fact none of us actually run the thing at home...
Don't you mean red shirt? You wear red shirts on the Enterprise, and they're not nearly as dangerous as they used to be...
As I said, I don't want to rehash the same old arguments here so I'm simply going to ignore most of what you said, other than to state that it's a matter of personal preference.
But one of your comments is way off in a different direction, and I'll address that one.
While I appreciate your humour (and a kernel of seriousness underneath) I explicitly chose to say that RH in particular made the choice of slack in this respect look good. I'm aware that Debian handles the dependency problems much better, that's why I phrased it like I did.
BTW, taste issues aside, your characterisation of slack and dependencies is quite inaccurate for 99.9% of cases at least. You can generally download anything from reputable sources and just have it run, if there's some particular dependency that will be noted. I have had the experience occasionally of installing something that did have an unsatisfied dependency, it's not difficult at all to figure out what they are. You start the program, it says fatal error could not find blah_blah.so you search for blah_blah.so and there you go. Yes, in comparison to debian magically going off and grabbing it for you that might be seen as a slight inconvenience, but it's no big deal. The nice thing is that the system doesn't care if blah_blah.so is there from a package or if you compiled it or how it got there, it just works. What does Debian do? I know Redhat is completely unable to cope in any sane way. RH fans will doubtless jump on me and point out --nodeps and --force, but then when you complain about it shitting it's own database they say it's probably because you used --nodeps and --force and you should never do that. I think the truth is more like you should never compile from source on RH, which sort of ruins the point of running a Free system in my mind. Or you should compile and jump through all the hoops to make an rpm and then install that instead, what a mess that is. On slack you can do the same thing, a lot easier, if you want, or you can just use make install and make uninstall and the package manager will play nice either way. How does Debian cope with source installs? I have used it a little but never did that on a debian system...
Oh, and one more btw, cat isn't an editor, but ed sure is. ;)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
I've never noticed any hats being part of the Starfleet uniform...
I just can't picture Picard in a red hat.
Red Hat has split their product into two lines, Red Hat Enterprise Linux (RHEL) and Red Hat Linux Consumer Edition (RHL). With this change they have changed their support levels, support lengths, and packages in the different lines of Red Hat Linux. With all of these changes, several which affect me directly, so I figured now is a pretty good time to re-evaluate our setup and some alternatives, such as upgrading to RHEL or switching to another Linux distribution
Rest of the article
We are happily running RH8 + Oracle 8i&9i + Java on our development and QA boxes but We won't use anything but Sun/Solaris on our production systems.
If you are running anything too critical the cost of Sun/Solaris is worth the money because it is the most stable environment you can get. I could never justify paying that much for RH.
Consider the semiconductor industry. The vast majority of Linux computers we put in today are replacing or augmenting older unix vendor equiptment (like Suns and HPs). It is probably a compute farm system, and no one ever goes interactive with it. In this environment, you pick what your tool requires, because the tool is the only thing of any significance that you will run regularly on the computer.
Today, we have a lot of vendors who specify a particular revision of RedHat. If you have a problem with the tool, one of the first questions the support people ask is 'what rev of RedHat are you running?' And if you answer that question incorrectly, win a direct line to the 'sorry, that is not a supported configuration [click]' response. These are tools which cost thousands of dollars to license and support, the customer is not going to blink at the requirement for an additional $300 per system. That's chump change.
Since RedHat is moving to an accellerated retirement schedule, I am predicting that some (if not all) of these vendors are going to eventually specify an Enterprise edition of RedHat so that they are not constantly having to port their tool to the 'current' release. A three to five year stability program makes a lot of sense.
So the computer won't get the latest and greatest -- who really cares? The computer runs this tool, not the latest and greatest.
The only disturbing thing about this is that the vendors are being mysteriously silent on this matter. I've queried a number of SEs and reps about their companies plans to deal with RedHat stopping support for older revs of the OS, and to a man they plead ignorance. Whether that ignorance is genuine or due to a lack of corporate policy on their end, I don't know.
If, on the other hand, you merely have some desktop replacement computers -- heck, it takes about 30 minutes to set up a KickStart environment. Grab the latest ISOs and kick them all every four months!
you should read everything on the internet as if it had "but I'm probably talking out of my ass" appended to it.
One of the reasons you might have trouble is that Red Hat has got this "product offering" (a lovely wanky marketing term, isn't it?) wrong. I have two major gripes with it.
Firstly: price. I have one box with 50 people running on it. At AUD$1.5K, Enterprise is priced right for that. The remainder of my boxes are "glue" that hold the network together. They do jobs like print servers, routers, firewalls and the like. They cost me AUD$300 each. What I need is a reliable Linux that has as steady supply of security patches. Red Hat plans to charge me 5 fives the cost of these machines every year for the privilege of supplying it. Obviously, that ain't going to happen.
Secondly: release schedule. 2.1AS is currently shipping with XFree86 4.1.0. So I go and buy a brand new box for AUD$500. I spare no expense - 2GHz Intel motherboard, 1/2 Gig of RAM, 40Gb HDD, Sony Floppy - nothing but the best, the most standard system I can buy. I then fork over AUD$1500 for Red Hat EA Workstation. And guess what - it won't run. XFree86 4.1.0 can't be made to support the Intel 845DV video on the motherboard.
This is actually worse than it was under the old system. If you based your systems on say Red Hat 7.0, then you had a number of years of binary compatibility (7.1, 7.2, 7.3) during which you could be sure the latest hardware was supported. And, as it happens, 7.3 does come with XFree86 4.2.0 and so it can be made to support the new Intel motherboards. But not so for its erstwhile replacement - Red Hat enterprise Linux.
I have trouble seeing now this is anything but a total marketing balls up on Red Hat's part. Yes, I can sympathise with Red Hat wanting to make money from their Linux releases. But what they had managed to do it release something that does less and cost heaps more. Before they had a single release that worked well for the hobbyist, grandma, the commercial "farm of cheap PC's" and the big iron.
Now we have:
My unwanted advice to Red Hat: try again. You can do better - far better. Currently you get nothing out of me for my "glue" boxes. Continue like this and the situation will change - for the worse. I will start installing other distributions at home, and no doubt grow to appreciate them. Or, charge me say $200 up front for a CD for an O/S with a 5 year life time, and then say $50 per year for security updates, and I will be a happy man. And I promise to never to contact you - other than to send cheques of course. The decision doesn't look too hard from where I sit.
First lets get one thing straight. There is a difference between Red Hat and Linux. Linux is pretty much Linux. While Red Hat is a GUI wrapper around Linux.
I hate to compare Linux and Windows but Linux is comparable to early editions of Windows. Windows was just a GUI wrapper around DOS.
I work for a wireless ISP and we run a Linux shop. We use Linux for all of our routing and to control our network around the city. Most of our Red Hat 9 machines run in level 3 or text mode so I don't think it really matters which linux we run because we are not running the GUI.
But we do have entitlements for all of our machines so we can get the latest updates.
I work for a MAJOR professional services business. Until recently, I helped maintain a core financial system that runs on a distributed system of Vax 4000 and 7000 machines, running OpenVMS version 5. For ten years now no-one has been willing to budget to upgrade, because the replacement system will be ready any day now. They are currently working on replacement system four, after abandoning three prior efforts.
/.er younger than 30 who can configure DECNET.
Extra points for any
Remove the previous rpm install and dependencies and install the new set.
If I were running linux as a production server I would build almost everything. Realistically what do you need to make a distribution complete? You answer would be different for almost every SysAdmin you ask. I just do minimal installs and get the components I need as I'm running off my server checklist.
Hell, slackware is still one of my favorites. Since Sun is still supporting Solaris 2.6 why is it so difficult for Redhat to continue to support their distros for longer? In the real world this will keep RedHat out of the exact place they want to be, Enterprise level servers.
I know Solaris is my first choice for a DB platform (Oracle). And I'm considering evaluating it on OS X with 970's if they come out (and Oracle gets out of RC stage).
I read all the mod 5 posts. One thing missing is the licensing and related costs/accounting/restrictions.
Advanced server follows microsoft style licensing, and bsa style auditing.
Don't take my word for it. Read the Red Hat licensing on Red Hat's site. Here's one clause, and here's the entire eula (don't know if the links are still good, copied from an old mailing list post, you may have to adjust the link a bit).
A while back, there was a discussion by one of the online tech news sites, concerning licensing for red hat advanced server. I'm sorry to say I didn't save it, as this discussion came up in a mailing list recently. But when I pointed the people on the mailing list to Red Hat's docs on licensing, they were a little surprised to say the least.
Basically, you can't copy advanced server to more than one server. You can't update the additional server, unless it is a legitimately licensed copy on the additional server. You can't exchange email with other companies discussing workarounds or what's part of Redhat's patching of advanced server (or just not with someone else who doesn't have a licensed and paid for copy(?)). Some of this is taken from the licensing wording itself, and some is taken from the discussions and observation from the online tech news site. And I if I remember correctly, they used an example of two or more companies that were exchanging info on this and were forced to stop.
Red Hat's revenue model for advanced server follows microsoft's/bsa's revenue model, and allows for audits ala bsa style, to make sure you aren't running any unlicensed copies of advanced server.
Why this never gets mentioned in articles touting linux, I'll never know. Maybe the authors aren't aware of how restrictive the advanced server licensing is. This throws out the window (no pun intended) the argument of not incurring licensing mainetenance costs, or management of the licenses. Totally destroys it.
Not dumping on gnu/linux. I run suse, and will be switching to debian due to the pain in the ass of upgrading, and the damn rpm dependency bullshit.
Why was the salesman touting advanced server? And dumping on the "consumer" version? If you could freely copy the consumer version to all of your servers without paying for the individual copies, and just pay for a maintenance contract, or if you had to pay for each server, for a very expensive license, and were prohibited from copying to additional servers without paying, which would you choose?
And with all these observations, I still believe microsoft is a screaming sell, and Red Hat is a screaming buy.
See what happened to VA Software last week? They surged on butterball ballmer's statements on linux, even though VA Software doesn't even have anything to do with linux anymore. The investors were just trying to find any stock even remotely related to linux, and buying. Wait and see the downdraft/updraft between microsoft and Red Hat when investors and analysts finally admit that microsoft will be shrinking, not growing, going forward. butterball's comments, and gate's comments earlier are simply preparing investors for the coming implosion. And the investors and analysts have their head in the sand. And are blind to what's happening outside the US.
That sounds like a problem with "compatibility", as opposed to "stability". Perhaps RH9 is using a later version of GCC (and where RedHat goes, VMWare is sure to follow)?
IME, a newer version of GCC is not always a good thing.
If a giant oil company wanted an abortion, would W's head explode?
I don't know who told you that stuff.. but its not a question of stability. Its a question of two and only two things...
... you will want to have whatever systems are connected to it FULLY qualified by the manufacturers most likely. If they only qualify one or the other (i.e RH Regular or Advanced) then buy that.
1. Red Hat Advanced (Server, Enterprise, and Workstation) are subscription based products... they come with a full year's support from Red Hat. If you want that support, buy this product.
2. Some manufacturers (HP, Storagetek, IBM, etc. etc.) are strapped for dollars to certify their hardware on different versions of Linux. They may or may not certify your product on "Red Hat Regular". If you are buying, say for example, a $250,000 SAN device
RHAS v2.1 is basically RH v7.2 with some added features like clustering and a year's support.
RHAS V3.0 (I think) will be based on RH v9.
-KevinJ
are you actually running an enterprise server? Didn't think so. Notice that enterprise software such as DB2 client/DB2 and Oracle have to run for the enterprise. RH 7.3 going away? well good luck trying any of the above on RH8 OR 9.
Place I ork, an employee was reprimanded for "violating the company dress policy" by wearing a hat. (The fact that she hadn't been given said policy was beside the point, from an executive POV.)
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
I'm surprised that all of your posts aren't modded "Troll" due to your opinionistic sig.
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
you lazy wankers with your package management...
I've still got a box in production running SLS with I think a pre 1.0 kernel (forget the exact version). It serves bootp on a small lan and doesn't do anything else. I'm pretty sure the harddrive died a couple of years ago, but that's fine since everything's on a ramdisk. Those 386's were built to last. Last time I checked it was humming away happily with a couple of inches of dust bung up the case. Gave it a blast with the compressed air and it's good for another couple of years.
I'll have to agree: nothing really beats Debian's package management system. As for installation, at the moment you can use the "bf2.4" installer (please don't use "vanilla" or "compact," they're horrid command-line-based things with the 2.2.x kernel that don't support many newer pieces of hardware), but a new set of installers is being worked on (the last I heard it was planned to have 3 frontends -- text, ncurses, and gtk, so you can do a text install over a serial line, an ncurses install at a local console from floppies, or a flashy gtk install from a bootable install CD).
On another note: if you're running a desktop system (i.e. something that's not a production system) you really should consider using either testing or unstable. Despite the name, 'unstable' actually isn't all that unstable. When stuff breaks, it usually gets fixed pretty quickly, and usually nothing too major breaks (the worst breakage is usually uninstallable packages, not broken versions of actually installed packages). But if that's too risky, 'testing' is quite stable. A lot of people run 'stable' when they really should be using testing or unstable, and then complain that the software in there is all a year old (Mozilla 1.0.x and whatnot). But that's the point of 'stable' -- it's designed to be for a production release that doesn't ever need (or receive) upgrades except for critical security patches. It's really stable, probably moreso than you want your desktop system to be, especially if you read slashdot.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I work at a university, so we've been confronted with this issue. Given our budgeting constraints, we will opt to move most of our machines to Debian. Why Debian ? It's one of the older, more mature distributions. It has always been the leading (and for the most part, the only) non-commercial distribution. Redhat used to be my distribution of choice, but it's not an option for us now they have their new model. I will probably continue to use it on my home desktop, but my work desktop is running Debian unstable, and the servers at work will run some form of Debian.
On the other hand, if you have the resources, the Enterprise version of Redhat may also be a good option. Redhat are still a reputable vendor, and business likes to do business with business, so the idea of using something with corporate support behind it may appeal to your managers.
Cheers,
Does it really matter which distro you are going to us. Once you have made a choice on what needs to be installed ie services and what they have to provide, your only really problem is security patches. Your needs for this server might grow, but do you always need bleeding edge software, problably not for an enterpise server. I have placed into business Redhat, Debian and Solaris. They all did the job they we installed for and all of the had very high reliablility. Usually the only time they were down was for tinkering. Find the right choice for the job right now, look at weather the distro is going to be around for a while. I am sure stable could be made fairly equal on all the distro, if you stay away from the continual upgrading and patch (except for security). My $0.02c Debian 8)
There's nothing wrong with keeping RH as the linux distro but, also nothing that says you can't use another one. One thing we have found is that for configuration management it is best to pick one distro and stick with it. Yes, linux is Linux but support is still an issue so the fewer differences between OS builds the easier it is.
Side Point: Yes the sale guy is trying to sell you the more expensive solution but it is, never the less, a good technical stratigy.
--
If I actually could spell I'd have spelled it right in the first place.
Being a Slackware user myself for 7 years I can
only second this. The Slack package management
system is basic but it does not try to be too
smart. I like the "Keep It Simple Stupid" approach
of Patrick a lot.
Red Hat Package dependencies _can_ lead to heavy
dowloading and unsatisfactory results.
We ran into a problem where a server had insufficiently many serial ports, and wanted to buy a usb-serial bridge ($50) instead of another terminal server ($1000). However there was no usb-serial bridge (i.e. converter) support in FreeBSD at the time. I believe that KeySpan even offered to work with FreeBSD on supporting their products, but apparently nobody would act as the contact.
We've also had serious problems with FreeBSD on our fileserver, due to a long-overlooked bug when many files are deleted quickly (a quota bug was found in the process, too).
I'm not claiming here that GNU/Linux systems are better, nor will I claim they are worse. But the "It's a server, use FreeBSD!" mantra is silly, at least in our experience. FreeBSD has not been more stable, or faster, or more flexible, or easier to admin than GNU/Linux systems. It's just another version of Free unix on a PC.
-Paul Komarek
Then drink the cool-aid. If your going to go RH you should us rpms and RHN as much as possible and make every effort to keep custom stuff seperate and out of harms way. Then you can do all your security patches w/ up2date -ui. The trouble is this luxury is gone when they stop releasing RPMs for the system. Meanwhile your stuck compiling and upgrading every time another exploite rolls around. RH has the nice feature of backporting security and bug patches to the old version, so your not locked into beta testing every new release on your currently stable box. If your going to go the "we can support it ourselves route." Then ditch RH all together. There are much better distros out there to help you manage all the compiling. Think Gentoo or Debian. It's not the "support" in terms of telling you how to setup your modem, but the precompiled / tested packages that makes the 5 year lifespan worthwhile. -r.
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."
Really. VMWare runs well on supported kernels, but always has some kinds of problems if I recompile the kernel module and run it with something else, such as a custom kernel.
It really boils down to which apps you'll be running on your RedHat boxen and what verions they support.
For example Checkpoint's Firewall software isn't Certified for the Enterprise flavor. So, even if you do get it running on the Enterprise flavor(the latest release requires you to run Checkpoint's custom kernel) you'll be told by Checkpoint's tech support that your are running an unsupport configuration and they can't really help you.
It is a lovely Catch-22 and I have spoke with Checkpoint senior tech support and there are no current plans to support the Enterprise flavor of RedHat or even Version 9.0.
If you aren't running any 3rd party apps that require RedHat, I would suggest using FreeBSD or Debian. Personally I would go with FreeBSD.
We have a small Linux support company, all told we've installed/maintain on the order of a few hundred Linux machines. We faced this exact decision in the past months.
We've decided to use Debian as our default distribution from now on. When we tell our customers they really don't care, we explain our reasons and they're more than happy to switch for the same reasons that we are:
- stability
- upgradeability/maintainability
- vendor neutrality
- software availability (8,000+ packages)
- etc.
I've been trying to get our organization to use Debian for 3 years, it's funny that finally Redhat themselves have forced the switch.
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
Debian is also available for several BSDs and for Hurd, should you wish some other than Linux kernel.
Debian's the obvious choice for the server room. RedHat, Mandrake, and SuSe are good for the desktop.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
I tried to run debian on our servers. Unfortunately, getting debian to run on server hardware can be challenging compared to red hat. It is also more time consuming to track down the relevant patches than it is with Red Hat, which in my experience has extensive support for server hardware.
:)
Other than that, debian rocks
Stop the brainwash
Dude, if you're gonna bitch, don't cower behind the AC name.
Do that, or STFU.
that is all.
You don't wear any hat in the enterprise.
You take your fscking hat off when indoors, as is right and proper.
Yeah, I'm sure all of us at one point encountered some idiot teacher in elementary school or whatnot who grabbed hats off of people's heads. Everyone thought he was some sort of hat-hating loser.
But the truth of the matter is, you look like a jackass by wearing a hat indoors. It's as bad, if not worse, as wearing sunglasses indoors.
Casual slackers.
Wear a suit! Then maybe you'll get laid once in awhile!
to Miguel de Icaza. The same man who famously started his lecture at Usenix with the line "Unix sucks".
If you're a McGuiver type or running a small business on a very tight budget, go for the consumer package. You'll have to do some fiddling, but you can install pretty much everything the enterprise edition has.
If you want corporate warm n fuzzies and a bunch of extras already set up so you can just sit in it and drive away, go for the enterprise version. I suppose most business customers will do the latter, simply because it makes it a little easier to get started.
Have you got your LWN subscription yet?
I'll tell you... there is nothing more satisfying than knowing that if this post got modded down to Troll, that at LEAST one person foolishly followed the link. It pleases me even more when I consider that the chances are even greater that more than one person followed the link but didn't have mod points! :) Happy trolling my brothers!
There seems to be some lack of knowledge around here as to where Unix is now used at in big business and where RH wants to break in the big server market.
;-)
I only got to know because I have a neighbour who works for Acatel SEL. We don't talk much about Linux or Unix because he always gets worked up about it and doesn't like to talk about it. He is a fan of MS by the way
Nevertheless, he sells huge 24/7 machine setups with their own apps to telcos all over the world (he's been to China a lot lately). Those machines manages telephone networks. So if one would go down Your telephone goes down. Since this isn't accepted generally very often the setups have to be pretty stable. They are now working with HP-Unix at the moment, because the *nix they used before (some other big business one I don't know) broke compatibility with their apps at each other upgrade even though they were promised otherwise by the developers. He now gripes about the fact that HP hard drives cost twice the market price and have to be replaced at least twice as often as they used to be (in Raid they just see the red light and replace it).
For those setups they need 24/7 support with very low response times to ANY bugs in the system on any layer. He talked about a 4 hour maximum response time for getting the system to run again and 24 hours for nailing and fixing the cause.
Last Cebit (big computer fair in Germany) I met him by chance and he said that his company is looking into Linux, because of the low cost fo x86 server hardware which has become very stable. Linux is the only stable x86 *nix from their point of view, because RH is the only company that offers the kind of contract (24/7 support, low response time) and might even be able to deliver on it. He said something about a couple million dollars a year per contract. So I think this is were Red Hat AS comes in.
This is also the reason why they can't use FreeBSD for example (or Debian, my flavour of choice for that matter).
You can take any System, be it HP, Solaris, OpenBSD, TurboLinux or Windows 2000 and install it on your home network or your company or as your webserver. If your company/wallet doesn't have much money to invest and shops for a good deal for their money they compare alternatives a lot different. Microsoft offers now stability and no security, but there is a high chance that you can degrade one of your engineers to quickly install it and hope it doesn't break or you can easily install it at home. FreeBSD was and is the best alternative for a lot of web servers, because it is free, runs on the cheapest hardware, is very stable and scalable.
Debian is IMHO the best mix of all for me, because it contains all the software that I want, is more stable than I would ever need, is easy to maintain and can be upgraded to the next version. It could improve on ease to configure and documentation a lot, but those drawbacks are the same drawbacks FreeBSD has and the "Desktop" Linux distros can't upgrade properly IMHO.
For a company that loose a lot of mony on downtime and have a lot of money to invest Debian and BSD is simply not an alternative. They might be more stable, but if a bug occurs, who fixes it guarenteed within 24 hours?
I've read through most of the comments, and between that and talking with real people, I think I know what the original poster is facing. People want ONE distribution to run across the enterprise (desktops, critical servers, non-critical servers). (This is what Sun provides, BTW). But, people don't want to shell out for an expensive advance server license and support for every single DNS server or MTA or desktop just for the sake of standardization.
Basically, people want to just maintain one distro (and also don't want the distro to mandate upgrades every 1.5 years) but at the same time, they don't want to pay Between $179 adn $2499 for every single box in their organization just for the sake of them all being the same.
I think if Redhat had a longer lived standard edition, but would provide enterprise level support when purchased, maybe there would be a better market for them.
Dude, if you're gonna bitch, don't cower behind the AC name.
How cute. Yet another person who thinks the Slashdot karma game means something.
Incidentally, did you notice how this whole thread got bitchslapped?
Nor am I "bikering". I said I thought it's too expensive, and I think it is. How is that "bickering"?
Anybody who doesn't understand this shouldn't be in charge of the decision of which to buy (enterprise with its high cost or standard with its short lifespan) because they don't have a fundamental grasp on the fact that they don't need to pay for either.
Anybody who posts responses based on reading only the bold letters should think about reading the entire post before responding.
Computer Science is Applied Philosophy
Don't really care. Karma is irrelevant.
Bitchslapping happens when we get this OT anyhow.
Karma is irrelevant.
Then why did you make that remark about logging in? You said it yourself. The karma game is silly.
Bitchslapping happens when we get this OT anyhow.
I don't care when it happens. It's the fact that it happens that bothers me.
This has been more a question about RedHat vs something else. I've seen most of the posters liked debian for its stability.
The main reason we keep using RedHat is about the installer. Most of all because it supports the creation of Volumes (LVM) and RAID right in the beggining of the installation. That makes it way easier than something else.
Then we roll the update rpms !
It might just be because most people that do mod base it on the message and not the sig. Or it could be that they respect that I am brave enough to publicly proclaim that I do believe in God but that I also believe in Science. Or they like the fact that I am will to stand up to the closed minded bigots on both sides. The all Christians are evil stupid people and the far right that think that "If it isn't in the Bible they should not be teaching it group." It is funny but I tend to get very little flack for my sig. and over all really don't care if I do.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
I beg to differ. Not only does Red Hat (a member of the Linux community) provide Advanced Server to cover the very "Big IT" issues you describe, but they're not the only ones doing it. The Debian stable branch is *exactly* for this sort of problem.
Don't confuse the ranting fandom of people who haven't had the experience of a "business environment" with a failing of "the linux community." The community is diverse, and does some pretty amazing things in the bleeding-edge daily snapshot area (Mozilla) as well as the established, stable, big business realm (the fact that you can run Linux on server hardware from just about anyone now, and then get a version of Oracle to run on it, to boot).
Not bad for a community that mostly does things for the fun of it.
But you said teh key thing. "Want more processors and memory? Gotta pay more for Datacenter Edition (which is only available by OEM)." You do not have to pay for these patches. You can get them and apply them for "free". The extra support is worth paying for but the patches. Well I guess if you are in a datacenter situation the extra cost is pretty low.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
How about in c++.
if(God&&Evolution){
cout "I am right\n";
} else {
cout "who cares\n";
}
I could crunch it down to
if(God&&Evolution) cout << "I am right\n";
else cout &le&le "Who cares\n";
But I find the first way is easier to read.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Yeah, I know, late, but just FYI...
Assuming that by "source install" you mean that you've built and install some software outside the Debian dpkg system, but want that software to fulfill a dependency of another Debian package, the canonical way is to use the 'equivs' package. Basically, you provide a list of dependencies that your (local) software fulfills, and it builds and and installs a sort of psuedo package with the right control information to update the dpkg database. Yeah, you can lie to it, but it's a lot more controlled and traceable than a simple --force-depends.
But I hardly ever do that. See, the thing is you very rarely run across a Debian package for which it's difficult to find the appropriate dependee packages. If it's in the archive, the dependencies are met from the archive. If it's from somebodies private stash, either the dependencies are in the archive, or they've built them for their stash.
Even if you want package from unstable to run on your stable system, usually the easiest thing to do is 'apt-get source foo/unstable', build it, and install the new package - certainly no harder than the usual untar, configure, make sequence. No, it doesn't work for big infra-structure things like X or Gnome 2 or KDE, but it works most of the time.
Lets try that again.
How about in c++.But I find the first way is easier to read.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Hey, thanks for the reply.
Sounds like about what I figured - a bit saner than RH, but still in my mind inferior to Slack.
Admittedly, it would rarely come up on either system because both have great package collections, but it's important to have the freedom to compile without jumping through a bunch of hoops. Whether it's because something just isn't in wide enough use to have a package out, or because you want a version with non-standard compile options, or because you need to change a few lines of source for one reason or another. The whole idea of relying on packages exclusively is, IMOP, quite antithetical to Free software. It's a nice thing they are there, and they save a lot of time and are a great thing, but only as long as you aren't locked into them, only as long as you can still go grab the source and do things that way too whenever you want. When the package system interferes with that, is when it's gone too far, in my opinion.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
If I ever meet you, I'm going to punch you in the face. And all that jazz...
Well, I don't want to get into a "my distribution is better than yours" kind of thing (because it really is a matter of taste, and how you rank the good things and bad things about it), but I'll point out that my standard technique for doing package variants is basically this:
One can add steps like getting a new version of the original source and applying the Debian diff, shoving the whole thing in CVS as a vendor branch, so I can appy my mods to new versions of the package, etc. etc. etc. Sure, it's a little different than starting from a .tar.gz, but I don't think it's really any harder.
I'd agree that being locked into a packaging system is a bad idea. While I often build local packages just to get the book-keeping and un-install support, some software is just not amenable to an quick and dirty package, and it's nice to be able to throw the whole thing in /usr/local, and I'd have to say that I've never felt that the Debian packaging system got in the way. Although it's more Debian *policy* that makes this work: I know where Debian packages will put stuff, and more importantly, where they *won't* put stuff, Also, there's a diversion mechanism to
re-direct individual files from a package (if you just want to replace one binary, for example.)
Okay, I'll shut up now...
SIG REPLYERS ARE FAGS