Slashdot Mirror
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.
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.
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 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.
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.
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.