The Increasing Cost of Red Hat Linux?
An Anonymous Coward asks: "I work at a company with a large number of Linux servers in the data center. We're currently evaluating what distribution we want to use moving forward. Upgrading to Red Hat Enterprise from 7.2 would cost ~$350k just for the systems we already have deployed. Due to the change in Red Hat's release policy, we either have to move to Enterprise, or change distributions. Also, we don't have Oracle on any of these systems, but we will need it in the future. This leaves us with rather limited options. I'm interested hearing what other Slashdot readers are running, and planning?"
How much more would Suse cost? I have worked at facilities before that switch from windows to Suse recently and they said it was a lot less expensive in the long run.
[RIAA] says its concern is artists. That's true, in just the sense that a cattle rancher is concerned about its cattle.
We made the upgrade. Its a godd choice. You know what you get, you get oracle/ibm/big gun stuff.
AND
you support open source / free software.
Have you evaluated the cost of moving to the supported versions of SuSE, etc? What's the cost there? How does it compare to Red Hat?
Also, if you find you don't need support, then why use the "enterprise" editions at all?
Finally, what'd be the total cost of moving to Windows? Probably a lot more than $350k, I'd wager. It sucks, but it's probably just time to pay the piper, or deal with supporting yourself... that's just how the market is. RH have to make a profit somehow.
The Free desktop that Just Works
Seriously, we use Debian / Qmail for pop3, Debian / Apache for web, Debian / DBJDNS for dns, and Freesco for Dhcp and firewall.
If you're running or will be running Oracle you probably want RedHat, but do you need to upgrade all of your boxes?
Vertical
72 CD D7 52 D0 7E D8 47 44 91 D5 84 D1 59 F1 A9-This is my 128bit integer. There are many like it, but this one is mine.
If you're looking for support (which is what I'm assuming your reason for going with Enterprise server is), then either pay for Advance Server or go with a different cheaper distribution and put the money you saved into someone that can search Google and find out how to make "RH only" stuff work on Debian or something.
We run oracle (both 8 and 9) on Debian, as well as most of our internet infrastructure (with the exception of proprietary programs that are stuck on Win2K for the time being). Most of the vendors of Linux based apps that we have worked with are willing to provide support even with Debian being the distro we chose (and then the ones that have complained, I've just called for another technician that was more distro-agnostic and gotten right through).
You need to look at what you are paying for, and what you need. With Redhat you're paying for a package (eg, physical box of stuff), some of their packaging expertise, a small amount of their own custom goo, and presumably support. You're also indirectly funding GNU and Linux development. If that's not worth $350k, there are a number of options out there.
I personally use FreeBSD. No, I'm not suggesting you switch, but since I use it I'll detail it as another point of view. I download the software, for free, and pay no licenses. I also don't get a pretty box, support, and I've done nothing to fund development. The pretty box is available, for a fee. Support is available from a number of companies, for a fee. You can fund development as much or as little as you like with donations.
Without telling us what you need, we're not going to be able to make a recomendation. Maybe you use some Red Hat "feature" a lot that's worth $350k/yar, maybe you don't. What I can tell you is there are more expensive (price Microsoft!), and less expensive (eg, FreeBSD) options. There are also many, many, many options in the middle.
One thing that you get with the licenses is centralized updating from redhat's servers. I find that on my networks, its easier to setup your own server and do it yourself. That way you don't have to pay RedHat and depend on each of your servers getting it from an outside source, you just need to have your update server grab it and share.
Of course, companies like redhat are good for businesses as well, because a lot of companies don't have the time to do a lot of their own support (or the technical savvy/staff), so having that option out there is a definite plus.
"Sed Quis Custodiet Ipsos Custodes?" -Juvenal
Someone please explain this claim. I have no experience with buying anything from Red Hat, but I was certainly under the understanding that the software was freely copyable. Further, if you bought one copy you should be able to install it on as many systems as you wanted. Sure, support is an issue. And if you want Red Hat to give lots of support for a lot of systems you should expect to pay for it. But couldn't AC and his company hire more people and support the systems themselves with that $350k? Don't they need support staff anyway to work with Red Hat? They would have to have support staff if they moved to Debain or other distros, so is there really a reason to move rather than stay with Red Hat and support yourself? Is there something about using Red Hat that I'm unaware of? Where is this $350k cost coming from?
I'm an American. I love this country and the freedoms that we used to have.
By all means, get Redhat support if you're just trying to make your company feel good about spending money on something. But their support is terrible. By terrible I mean completely worthless at solving any sort of problem easy or complex, big or small.
They aren't much worse than anyone else's support so far as I have experienced. But still somehow I was shocked at just how completely worthless they are.
SuSe is cheaper than AS, how much cheaper i do not know. but unlike most distro's they offer an "Enterprise Edition."
They also offer priced to fit support, and now have the backing of IBM and Sun, and they support oracle.
and this is coming from a Gentoo zealot.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." --Albert Einstein
Ok, who rated parent is "funny"? Debian is the only real option IMO for using Linux in the enterprise. This is because of it's testing, stablity and the sheer number of platforms it runs on. Plus, you never have to worry about "purchasing" newer versions. Red Hat is often released very quickly when the software which is is made up of, is often not thoroughly tested. Yes it's the bleeding edge, exactly, it can indeed leave you bleeding.
I was personally involved in porting our company's software to Linux. I chose to support Red Hat, thinking that their big name would mean that they were somehow better as an organization.
I WAS TOTALLY WRONG!
I recently tried phoning Red Hat Sales to try and buy support, and it has been more than 1 week, and I have been unable to get them to respond! My first 3 attempts to contact Sales were ignored, and finally I got someone on the phone. They directed me to someone else, and after an initial e-mail, they have yet to contact me after I sent them 2 follow-up e-mails. It is absolutely ridiculous.
You would in this day-and-age that Red Hat would be salivating over someone who is willing to pay them money for support, but they seem competely disinterested in helping me give them money. I have already complained to my superiors that we should consider supporting a different flavor of Linux, because if this is how responsive Red Hat's Sales unit is, imagine how unresponsive their Support unit it.
I agree. I have never dealt with any sales organization as unresponsive and unmotivated as Redhat's.
Fast forward to end of 2002, and we had become disgusted with Red Hat's road map for its' Advanced Server license. It seemed as though we had lost all of the benefits of the GPL.
There was no way we were going back to M$, but there was a movement from higher up top to change distributions. To make a long story short, we passed on SuSe and chose the often corporately overlooked Gentoo.
The benefits of this move are stunning. We have been able to hire 16 additional employees to handle our own fork of Portage, and 22 additional employees to provide support. Not only to we do a "ghost compile" for each box (many different Pentium and Athlon systems), we also take a minimalist approach. The combination of those two choices have enabled us to increase performance per box to something like 26% faster on average.
With the obvious help of the Gentoo open source community, we have created a low cost, self-sustained IT department that can function well into the next decade. Thanks Gentoo!
We are moving from Red Hat to Debian for all our web, dns, and email systems. Systems that are clustered and or run Oracle will run RH advanced, though those will be few. Debians stability, security, and package management was the iceing on the cake.
Actually you can install Oracle on RH8/9 (I've done both), check out http://www.werner.us for some instructions and stuff about how to do it. I've got it running on my Dell laptop on RH9 and it's good enough to develop against.
Later,
Rushfan
Totally agreed...
Debian zealotry is a plague
I agree, I think Red Hat is really leaving small/medium businesses out in the cold with their new policies.
One example, I set up a server/firewall for a small business as a contract job on the side. It runs all their stuff, web, email, etc. They really don't have a need for more than one server.
Last year when I set it up, I told them it would be good for at least three years. I don't like it that Red Hat made a liar out of me.
At my real job, we have more than a dozen Red Hat servers, and I'm stuck in the same dilemma. We can't afford to destabilize servers by putting essentially beta software on them, that the 12 month EOL requires. I used to let RH releases age about 3 or 4 months to get the major bugs out before I even considered using them in production.
So now I'm faced with either spending tons more time patching the servers by hand (even though we pay for RHN), or spending tons more money, buying RHEL which would cost at least 10 times more than the ~$1000 a year we spend on RHN now.
I really hope something gives on this situation. Red Hat better think twice before they alienate small to medium businesses. I don't need support. I do need updates. I do need more than 12 months before EOL.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Now, I have 70 Linux servers around the country, and a steady stream of new customers. I've been installing Redhat 8.0 on new deployments because 9.0 doesn't work well with our application. So, we've everything from 7.0 through 8.0 in the field. Over the past few months, Redhat dropped up2date support and patches for Redhat 7 and 7.1. I feel guilty installing 8.0 on new boxes because I know support for it will be dropped at the end of the year.
I don't wish to buy into Redhat AS or ES because I don't understand what I'm paying for. *I'm* the Redhat support. I just need something that will receive patches and support for more than one year. The 5 year lifespan of the ES versions is nice, but I've NEVER called Redhat for support. I don't plan to.
I build the kernels for each of the servers. I use vanilla kernel.org source with XFS. We sell 2, 4 and 8-way servers. Am I missing out on anything from the "optimized" Redhat Advanced Server kernels? What are other people in this situation doing?
I think it's confusing because we initially chose Redhat for the accountability aspect of having a corporation behind the distro. Now, I'm not sure who they're targeting. I would imagine that most firms that select Redhat Advanced server and are willing to pay the price (>$1000/license) would have a staff talented enough to support it. So why the mandatory support costs from Redhat?
Edmund White
http://flickr.com/ewwhite
The catch; using a commercial piece of software in the mix. In our case, a certain database. Being closed-source and totally non-self-servicable in case of serious problems or bugs, it is imperative to have a support contract for the commercial software. Almost all the RDBMS vendors have now altered/clarified their support policy: they will *not* honor a paid support agreement if you are running the free version of Red Hat underneath their software.
Why this policy exists is a question I will let somebody else speculate about...
There is exactly one major RDBMS vendor I could find that will officially support its software running on the free version of Red Hat (as of April 2003, at least), and that vendor is IBM with their DB/2 product.
Unfortunately, we were too time-constrained to port our system to DB/2, so in the end we caved and paid for Red Hat Enterprise so we could get RDBMS support on our existing platform. To this day we have not called Red Hat tech support once and don't expect to do so, ever. The thousands of dollars we paid covered the 3 minutes of effort the sales guy put in over the phone. Not a bad deal for Red Hat. If I were starting from scratch, knowing about the new support policies from the RDBMS vendors, I would have done the project using DB/2. PostgreSQL would have been an even better choice, except our project required real-time database replication, and PostgreSQL is just now getting to the point where that works well enough.
Over the last 6 months, I've noticed a declining interest in KRUD, which I attribute to several factors (low cost bandwidth due to broadband reducing the demand for CD distributions, more commercial distro users moving to more expensive Red Hat versions, and others). Interestingly, this has come at a time when many people have stated an interest in continued support of older Red Hat distributions because of the new Red Hat End Of Life announcements.
We'd like to be able to continue to do KRUD, and are exploring electronic distribution options, and broadening our offerings.
I think that KRUD provides a valuable service, both in providing an easy, secure, complete, up-to-date distribution, and in providing an alternative to Red Hat's soon to be discontinued 'hobbiest' versions.
Right now, we're evaluating providing support for 7.3 and 8.0 after Red Hat's End of Life in December. It's going to take us close to a full time engineer to do the updates, I estimate. So far, I've had only about 10 requests to provide End of Life support, which is not even close to being able to cover the costs to produce. The price would drop to a more reasonable level if more people order it.
It's interesting that many people are expressing interest for longer support for older Red Hat releases, but few seem to find any value in it.
If you're interested in pre-ordering, please feel free to contact me.
Geek Social Butterfly
At home I run the developer edition of the Oracle 9ias enterprise database as well as release 2 of the Oracle 9ias Application server. I have successfully installed to Red Hat (version 8.0 not Enterprise), Mandrake and also a Debian Distribution. At work we are running a development environment on Red Hat 8.0 and production using Solaris 8. Since we are using pure java and j2ee code our software runs flawlessly across the systems with no changes whatsoever, even considering the fact that some of the developers on the project run Windows systems on their desktops where they actually write some of the source code modules!
If you expect support from Oracle concerning an Oracle installation of any kind whatsoever on Red Hat Linux you best be using Enterprise and yes the support pricing is quite high compared to what most of us are used to running Linux over the years.
I would suggest running your most critical servers on Red Hat Enterprise and if you have supporting environments, perhaps a development or test environment, use Red Hat 8.0 (or even Debian or Mandrake) and save yourself some cash outlay in that way.
If you have the talent within your staff to self support I can attest to the fact that Oracle products run as advertised on Red Hat 7.3 and 8 (have not yet tried 9) using the install procedures Oracle outlines for use on Red Hat Enterprise, but as has already been pointed out, Oracle will not support installations with problems unless you have the Enterprise edition as your underlying Linux Distro.
The Matrix is real... but I'm only visiting!
The Matrix is real... but I'm only visiting!
Reply to my own response, go figure after a six-pack of beer on a Friday night. I'm sorry.
Your question is a great example of why Linux is not free.
Due to the change in Red Hat's release policy, we either have to move to Enterprise, or change distributions.
See if SuSE USA has better terms. If they don't then tell me what kind of terms your company is looking for. As a programmer in a Win32/Linux/AIX/NCR/SCO/OS2 shop, our linux distribution comes with helpdesk support (embedded). It's cheap, but it's not free.
Enjoy,
It's just the normal noises in here.
I went to a RH Enterprise marketing gig a couple of weeks ago, and they are promising binary compatibility between their upcoming 3.0 Enterprise versions and backwards.
Remains to be seen how well they come to accomplishing those promises, especially since they are saying 3.0 will have NPTL.
I buyed RH many times, but never the profesional or enterprise version. They were too expensive for my country(3rd world one). :-(
When RH decided to drop the 20-250$ price products, they left that price window it open for all other distros to come in and steal RH market share.
I'm too don't know what to do and what to recomend to my customers. Suse? Mandrake?
If you have only 100$ to spend in a server OS, then, you wont be running RH, and that is just plain sad.
Get my e-mail after a captcha test in: http://tinymailt
Yah, it took about 15 minutes of poking around apt-get's man page to find how to upgrade only the security packages by default (you CAN do this - apt-get update; apt-get upgrade;apt-get update with the options to select a different APT config for the first two, and create one that only has the security servers) - but it wasn't that hard, and now we've got automated security updating. Works for me!
I can not STAND people that say "Oh, well, it won't run on anything but Red Hat". Give me a break. The operating system is called Linux, not Red Hat (OK, maybe GNU/Linux). Linux defines the API and the application interfaces (ditto GNUification), and quite simply, everything that runs on Red Hat will run on Debian.
Period. Wackos who tell you "oh, maybe it's a problem with Debian" simply don't understand the way computers work. That's why I can't stand that Oracle won't support anything except Red Hat. That's silly. More than silly. They wrote a program, that works under Linux, not under Red Hat. If it's kernel version dependent, state the kernel versions it was tested under - or better yet, give the source tree! (wow!) If it's library dependent, give the library versions. If it's library dependent, static link the damned thing. There is nothing that runs under Red Hat that can't run under Debian.
You know what someone really needs to do? Write a bunch of scripts that let one distribution 'play' as another one, so you can just reboot and launch as a Red Hat clone, Debian clone, etc. (if you don't need a new kernel version, you don't need to reboot). It can't be that hard. That way when someone asks you what type of Linux you're using, you can say "What type would you like it to be, so I can then prove to you that you're being an arrogant prick and it really IS your problem?"
"distro-mode redhat". That'd be cool.
1. Both the host distro and the binary must be of the same architecture and must both be of the same binary format (e.g. two ELF-x86 distributions).
2. The binary may not use any system calls outside those required for the single UNIX spec. (This rules out things like ipchains/ipfilter/ipfw/ipfoo and various other kernel-version-dependent tools). This rule could probably be relaxed a lot before anything would break, but YMMV.
3. The kernel must be patched to fix any known bugs in SUS-compliant syscalls.
With the note that there may be other important directories needed in step 4, the basic procedure should go something like this:
Step 1: Install the distro. /rhbox ; cd /rhbox /usr /lib /bin /sbin /etc /var" | tar -xzf - /rhbox appname
Step 2: Install RedHat onto another machine and configure ssh and networking between the two machines.
Step 3: On the non-RedHat machine: mkdir
Step 4: ssh username@redhathostname.domain.top "tar -czf -
Step 5: alias appname chroot
Different operating system, my ass.
120 character sigs suck. Make it 250.
(you could easily get someone with the knowledge to do this correctly for $25k btw).
...... so start the training for redhat AS alone cost more than the damn PC.
there is no way in frozen hell you would be able to pay an enterprise admin who does level 3 work 25k per year. there is a very LARGE difference between sitting in a call center while talking to some jackass who spent $2000 on some shitty PC and talking to someone who has a $250,000+ server running Redhat AS with Oracle
not to mention that when your dealing with systems running certified oracle your dealing with systems that would potentially cause hundreds of thousands of dollards of lost profits for the company per hour if they go down/stop working.
Sony doesnt sell or run anything in this range. even if you supported their internal IT infrastructure it isnt on the level of say, NASA or all-state insurance, or some hospital. no consumer level company is really on this level. although some think they are.
there is a large difference in skill between the average phone monkey and a real unix/linux admin. not to mention if you only have one level 3 admin then you would have to pay him some sickly amount to be on call 24/7.
most data centers that have level 3 admins pay them at least double what your recomending, companies like IBM and Sun pay them several orders of magnitude more than 25/k per year. especially if your expecting them to live near your center of operations, which for larger companies is usually in a large city, which also costs more.
check out monster.com i searched for 'Linux level 3 admin' and the lowest paying job started at 50k per year. you dont hire anyone without years of experience to do level 3 no matter what degrees or certs they have, and phone support isnt the same as the real thing.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." --Albert Einstein
Redhat is by far the worst distribution when it comes to 'timely' package update for security flaws. If it's something important, alot of times using packages isn't the best way to go at all, especially when you have to wait for a package to be released, rather than patching source.
I've been running Debian since 1.0, and haven't had ANY problems with broken packages in their STABLE distribution sets, nor problems with mirrors, localized or otherwise. Out of all the distributions, with the exception of gentoo, it's the most stable and clean package management system out there.
It's not all wine and roses of course, with any package management system, dependancies create problems, but I've had more trouble with Redhat rpms by far than with deb packages.
Best of all, debian is free. No move to pay for anything, and the support community is VERY wide, and eager/quick to help. I've never been stuck in a situation where I couldn't find the answer almost immediatly, by doing research and speaking with developers over IRC or via email.
Paying for support is one thing, that both distributions provide. What I wonder, is what's so different with Redhat that they feel it necessary to charge for security updates, rather than offering it out as it's always been.
It smacks of large corporations and money grubbing, partly what the linux and opensource community in general has been working against.
Currently I am working with a lot of Sun kit - and their sales guys. They are absolutely thrilled with Red Hat's new pricing, becuase suddenly they are competitive again.
Consider - a small Oracle DB on a 2 processor machine. The cost of a decent 2 processor server is about $2000, and then the cost of RHAS is about $2700 as I recall. Suddenly the cost of a V240r doesn't seem that bad. We pick them up for a lot less than $4700. Of course we have a pretty good deal with Sun, and the poster may get a good deal with Redhat, but we've done the analysis, and RH does not stack up for us in this example. For me, in is interesting that we have said "no Linux", not because it is a "hacker OS" or it can't do the job - but because it is too expensive to deploy. And before anyone asks, we didn't do any TCO voodoo to prove the point!
Other things Sun have on their side:
- Scalability on the same architecture. Yep, I know 2.6 will scale, but it isn't even properly released yet. We develop on small machines (240s, 480s) and deploy on 15Ks without even thinking about it - apart from making sure that the app can use the CPUs
- Solaris - damn good OS, excellent support and an understanding of what enterprise computing is about
- Support. Judging by some of the comments here Redhat support is somewhat lacking. Having called regularly on Sun support, I can say it is quite exceptional - even when problems are not their fault, they will engage with other vendors to get a fix
Each distro is a different OS in the same way that every installation of Windows 98 or 200 is a different OS -- i.e., the library (DLL) and package (service pack) versions are different from one system to another, and so the behavior of a single dynamically-linked application may vary across them.
However, while Windows application vendors are happy to support every version from 95 to XP, most commercial Linux applications are extremely specific about not only the glibc and kernel (more or less equivalent to the base Windows build) versions they support, they usually tend to refuse to support users under distros other than Red Hat. It's understandable from a revenue-based POV, since Linux as a whole probably consists (even for the most hardcore scientific or engineering app vendors) of less than 10% of their business.
Realistically, though, the effort and cost required to support at least the last few versions of all the major Linux distros (Red Hat, SuSE, Mandrake, Debian, Slackware, etc.) is probably less than the support for Windows 95, 98, ME, NT 4, 2000, and XP. It's not a tecnical issue so much as an economic one, but it does negatively affect the natural competition that exists in the Linux distribution market, since any new vendor has to either work towards 100% compatibility with recent versions of Red Hat, (and therefore use RPM, standard SysV init scripts, etc.) or accept an extremely marginal, source-package-only application support model.
Taco Bell raised their prices and their popularity went up. People thought that they were getting a "better" product.
..........FULL STOP.
Suse is the only other distro doing major development work for the enterprise (like 64 bit support, Opteron, etc).
Corporate IT needs a distro where consultants and support are available, etc.
The cost of Red Hat has grown very extreme.
At my last gig I was responsible for ~30 Linux servers, all running Red Hat. There were about 5 of them running RHAS 2.1 and the rest were running 7.x
I spent a couple of days with the Oracle DBA benchmarking our applications and found it interesting that 7.3 was a tad faster than RHAS 2.1. Hardware was IBM x345, dual 2.4GHz Xeons, 2.5GB RAM, ~200GB RAID 0+1. Yes, hyperthreading was disabled.
I find it odd that Red Hat's "Enterprise Linux" is missing some key enterprise features that can be found in its consumer distribution (such as Logical Volume Management). BTW, LVM is broken in Red Hat unless you compile your own kernel, otherwise you can't mount snapshots.
In any case, Red Hat's new pricing scheme is flat out extortion. I had enterprise support on my servers and ever single time I reported a problem, I was either delayed until I found the solution for myself online or flat out told "That's not supported." You might wonder what's not supported. How about LDAP authentication? The automounter?
There are some things about Red Hat that are wonderful. And some that are pretty good. In the wonderful category, their installer is just the bees knees. Especially if you're kickstarting your servers. RHN is a nice tool but fundamentally flawed in that you must use Red Hat's repository; imagine 30 servers downloading the same 45MB of RPM's over a T1 at the same time over https (which can't be cached). yum goes a long way towards fixing this.
Debian has some nice points but IMHO has a lousy installer and zero enterprise management tools (such as RHN for Red Hat). People have been bitching about the installer forever and nothing seems to be getting overhauled there.
If I were doing this from the ground up right now, I'd go with RH 9. Keep your eyes open and keep track of major releases by RH and evaluate for yourself when an upgrade is necessary. RHEL is made up of many components that have been deprecated in the mainstream release (such as CUPS, I think Sendmail may also be deprecated). For LVM features you need >8.0 anyway. Use yum for your package management, build your own local package repository, and spend a little time learning about the guts of RPM.
Just a little info for you:
Postgres is one of the oldest and best supported dbms around. It doesn't have a couple of features Oracle has, but it is a highly superior product compared to most others in it's class. That's in a business setting anyways. MySQL is easy to use, relatively fast at simple operations. DB2 is nice. Good for big computers with lots of ram. That's my observation, there probably is no rhyme or reason to it. I have lots of ram, and I like DB2. It's just fun! MSSQL sucks rocks. I developed a lot of websites using MSSQL as a backend and just couldn't make it feel right. Oracle is great for big iron.
They say it's good on x86. I say Ellison is full of shit.
Here's my personal dbms preference list:
Business
DB2
Oracle
Postgres
MSSQL
MySQL
Hobby/Pleasure
MySQL
Postgres
DB2
MSSQL
Oracle(unless you are masochistic)
You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
Do you have hardware support from IBM or HP? Or are you considering getting support for Oracle or SAP? If so, switch to SuSE, pay the lower maintenance fee (patches and updates), and get support for SuSE from one of these primary vendors. I like the single point of contact for support.