“At the time, most of us thought Oracle undercutting Red Hat’s Linux business with its Unbreakable Linux was a big deal. Would customers flock to Oracle’s cut-rate version of RHEL? Would Red Hat be pounded by Larry Ellison’s minions? After a few months, the answers appear to be: No, it wasn’t a big deal; and no; and no.”
Red Hat is a proven vendor of Linux. Oracle is not. The cost savings aren’t worth the risk if a disaster hits.
According to CIOs, it goes even further than that. Apparently Red Hat is a proven service provider, whereas Oracle sits near the bottom of the list. If Oracle can’t support their own bread-and-butter, then how are they going to take on Linux?
That’s very true. Seems as though our team knows more about Oracle AS than they do. Typically we log a support request, then figure it out and tell Oracle how we fixed it.
I found this on ArsTechnica the other day, and despite the lack of downloads of Oracle Linux, I don’t think this is a trivial issue:
http://arstechnica.com/news.ars/post/20070130-8737.html
One of the things we are looking at is the cost of RHEL when it comes to patches. Maybe people are starting to balk at $10,000.00 per server minus subscription fees per machine for Satellite Server. And if Oracle can provide the same service for less and provide the same QOS, why not?
10K? Isn’t RHEL AS with the top support level $2499 per server with RHN?
Definitely still expensive, but for 24/7 support, it’s a reasonable deal for SMBs that really rely on their IT infrastructure.
“10K? Isn’t RHEL AS with the top support level $2499 per server with RHN?
Definitely still expensive, but for 24/7 support, it’s a reasonable deal for SMBs that really rely on their IT infrastructure.”
True, not a bad price. Just remember that is $2499 per year.
RHEL AS – $2499/year for 3 years = $7497
Oracle Premier Linux – $3597 per every 3 years = $3597
Savings of $3900 for the first 3 years right there. for 24/7 support. Figure server life is about 5 years when possible, that takes RHEL over $12K total cost, with Oracle Linux at $7194 for 6 years total. Huge cost difference, and mostly what SMB’s look at, not name behind it.
http://www.redhat.com/rhel/details/faq/#10
Edit: Added RHEL FAQ link
Edited 2007-02-05 20:50
I’ll support your server for $1000 a year.
“I’ll support your server for $1000 a year.”
Hell, I support it at my salary. The bean counters however insist on the support as they want someone outside the company to blame if things go wrong. I have yet to actually use that support over the last 2 years, and when I pointed that out they still want to purchase it. Go figure.
If you cannot connect all of your machines to RHN (we can’t) and you want to apply patches, then you have to purchase Satellite Server in order to deploy patches which requires additional fees in addition to the cost of Satellite Server.
That’s not quite true. You can set up one proxy server to cache the updates and put them in a yum repo. Then add the yum line to your /etc/sysconfig/rhn/sources file on the other servers.
Thanks, because the impression RedHat gives our management is that you have to use Satellite Server to handle patches.
Here:
http://www.osnews.com/permalink.php?news_id=16294&comment_id=175674
But then industry analysts like to play toy soldiers in public.
This is misleading. It’s a Linux article, nothing to do with Oracle’s core business.
The director of Marketing at Oracle must be an idiot. Did they do a market survey?! This decision is a flop.
People who need mission critical support won’t find the extra cost of RH a problem, compared to the level of reliability. People who don’t need mission critical support will find community support (Centos) good enough. Makes sense.
speaking of somebody who has used centos in various situations, i can say this without hesitation: RHEL and its derivatives are seriously awesome.
1. I can purchase a product with support from the company who has the engineers that made the product.
2. For a cheaper price, I can purchase a product from a company that did not make the product, but promises they will support it anyway.
Doesn’t sound like a tough choice to me. And that is not even considering any moral implications.
Based on what evidence? I mean, Oracle have worked with the kernel extensively along with their own products; so they’re hardly a novice company when it comes to understanding the in’s and out’s of GNU/Linux.
Neither company “make” Linux or the kernel. But, Redhat does create the RHEL distribution, with all of its tools and integration. This is the product that Oracle has so kindly repackaged.
Not to sound argumentative, but whose to say that Oracle isn’t going to make their own version based off Fedora? if they were still ‘lifting’ a version off Red Hat and merely rebranding it, I would have concerns.
2. For a cheaper price, I can purchase a product from a company that did not make the product, but promises they will support it anyway.
Reminds me of IBM. When we have a big issues there is so many channels to get to the Novel its not even funny. With this I can’t see it being any better. Why not get your support straight from the source!
“That’s very true. Seems as though our team knows more about Oracle AS than they do. Typically we log a support request, then figure it out and tell Oracle how we fixed it.”
Oh man, I hear you on that one. I can’t go too into it, but we had a pretty disastrous project a couple of years ago that went nowhere with Oracle consultants until our IT Development department took over got the work done. I admit that part of it was that our business is complex, but still… they came in claiming it could do X Y and Z and it could only do X.
[edit]
This has nothing to do with Linux, btw… we actually use RHEL. But with Oracle’s services in general.
Edited 2007-02-06 06:06
i don’t think we’ve seen the last of unbreakable Linux, they’ll be back.
remember that ORACLE is more business savvy than even Microsoft.
their business savvy ought to be telling them that this was a retarded idea to begin with, right about now.
Steven Vaughn-Nichols has added to his original eWeek story. See http://www.eweek.com/article2/0,1895,2090899,00.asp.