Oracle: Looking Past Ellison's Rhetoric ...
There's a lot of commentary floating about regarding Oracle's move to base an new, Enterprise flavor off of Red Hat Enterprise Linux (RHEL). To start, I'm not going to even address Ellison's rhetoric (I'll comment on that later). I'm going to focus on what it takes to maintain an Enterprise Linux release, specifically now Red Hat has done it. Then I'll focus on what Oracle may actually add to the world with its move, and how it could also bomb.
What is Red Hat Enterprise Linux?
Understand Red Hat has a very long-standing release model that remains unchanged since Red Hat Linux 4.0 (from the mid-to-late '90s).
Community Releases (6-9 months): They have a 2-3 month package selection program, and other 2-3 months of package testing (Fedora Development fka Red Hat Rawhide) and then a 2-3 month test release (Fedora Core Test, fka Red Hat Linux Beta) before Fedora Core (FC) is released (fka Red Hat Linux, RHL) every 6-9 months.
Enterprise Releases (18-24 months): After 2-4 release of Fedora Core (fka Red Hat Linux), Red Hat builds a new release of Red Hat Enterprise Linux (RHEL), including a formal series of Betas and then eventual release. As a result, RHEL is released every 18-24 months. It then supports RHEL at least 5 years, and it's looking more like 7+, standard. Currently, Red Hat is supported RHEL 2 (aka Advanced Server 2.1, based on RHL 7.2/7.3), RHEL 3 (based on RHL 9 / FC 1) and RHEL 4 (based on FC 3). RHEL 5 (based on FC 5/6) is currently in Beta, but its running into some non-package related shake-down issues with the new YUM-based update system (long story).
Unlike FC, and RHL before it, newer packages are virtually never made in RHEL. Red Hat backports some things in FC/RHL to maintain some compatibility, Red Hat always backports everything for RHEL to absolutely guarantee full ABI/API compatibility. This includes never changing the kernel or other, core components. Red Hat's sole focus with RHEL is Service Level Agreements (SLAs), guaranteeing any application will always run on the version, with any level of updates or other fixes. Although FC/RHL also try to maintain ABI/API compatibility, they do regularly gain newer versions of packages mid-version, as long as there are no major changes in general operation. Again, RHEL does this to an anal power, always backporting.
Despite popular statements, RHEL is still very GPL-centric. In fact, non-free software is located on a supplemental CD. While Red Hat does not allow the distro to be redistributed with its trademarks (more on that in the next section), it does release the full set of software in Source RPM (SRPM aka .src.rpm) format. This is unlike SuSE Linux Enterprise Server (SLES), who did not until after the Novell purchase.
The Red Hat(R) Trademark Debacle
To date, Red Hat(R) is the only major commercial entity who ever released a 100% redistributable distribution with its trademarks. This caused Red Hat a major headache, and was the primary reason why their 100% redistributable version was released as Fedora(TM). All while Red Hat was loose with its trademarks, SuSE(R) and many other distros were not (although Novell has since bought SuSE, and doesn't protect it nearly as much -- largely because they have their Novell name, long story).
Cobalt was one of the worst abusers of the Red Hat(R) trademark. They completely modified the distribution, but left Red Hat's trademarks intact. In fact, when many people complained about things or the "reliance on Red Hat," they didn't realize it was precisely because Cobalt had modified it so much that it was the reason, and not Red Hat. Red Hat largely ignored the issue, until Sun bought out Cobalt. When Red Hat finally barked at Sun's liberal use of their trademarks on heavily modified systems outside of even just Cobalt, Sun brought up the lack of enforcement and Red Hat legal went nuts because they had no recourse.
At first, Red Hat tried to clarify the usage of their trademarks to allow various projects, rebuilds and other, free software use. But the legal holes were still there, and plenty of redistributors -- redistributors allowed to use the Red Hat(R) trademark, still demonized Red Hat for it not realizing the real legal bind Red Hat was in. At some point, Red Hat finally decided to get out of supporting a low-end "product" altogether, and give it away (including supporting the infrastructure) for free. Today, despite several attempts to reorganize, Fedora Core (RC) continues to be developed and released to the exact same model and standards of Red Hat Linux (RHL) -- because it feeds Red Hat Enterprise Linux (RHEL).
And RHEL continues to be "free software," including the availability of SRPMs. As such, unlike SLES, there various rebuilds, including CentOS. In fact, CentOS is by far the leading rebuild. CentOS has worked with Red Hat legal in the past to ensure they are not violating any trademark laws that would require Red Hat to assert its ownership. And because of Red Hat's longer-term support of RHEL (7+ years), versus RHL/FC (only 3-4 years at best via Fedora Legacy), CentOS is becoming the basis for many new projects such as OpenFiler and SME Server (fka eSmith Server).
What Oracle Could Accomplish (Largely for Themselves)
I'm not going to give a simple "good" or "bad" comment on Oracle's move (although I will comment on Ellison's rhetoric below). Oracle has decided that Red Hat's support isn't cutting it. If they've decided this (regardless of what Ellison said), they've probably got a sound reason. As a result, it plans to offer a higher-level of support beyond what Red Hat offers -- at least from the standpoint of Oracle applications. If Oracle can pull it off, it could become the model to follow by several other, major enterprise vendors.
The idea here is that Oracle should be able to deliver a distribution that works better and reacts better to changes for, again, Oracle applications. They would not be doing this if they didn't A) feel that Red Hat's "base" is one of the best for enterprise applications, but B) Oracle knows its needs better than Red Hat or Red Hat can react with Oracle's current relationship. In fact, this whole endeavor may merely change how Red Hat and Oracle interacts, possibly bringing them closer together.
Now it's going to take significant resources for Oracle to do this. Again, I'm going to argue that a lot of cooperation with Red Hat itself is going to be unavoidable. Oracle would be shooting themselves in the foot if they didn't. But unlike projects like CentOS, which must maintain strict separation other than at the developer-level, Oracle can and should have a formal relationship with Red Hat. That's what really makes this different than what community projects like CentOS have done.
The $99 Release (Sorry, Don't See It)
I honestly don't know what Oracle expects to accomplish with a $99 release other than to cause itself headaches. Red Hat tried and tried and tried to stick with supporting a low-end product, and got out of it because you lose money. With not even 1/1,000th the desktop sales of Microsoft, you can't charge the same out of the pure reasons of economies-of-scale. So I think this will either be a short-lived option, or a basically "oh, you bought the $99 box, we won't talk to you, have a nice day" attitude that won't win them point. I think Oracle management will quickly realize this as well.
Just like Red Hat, Oracle will not be making it fully redistributable, especially if Oracle(R) is on it. It would lead them right down the same lack of trademark enforcement debacle that only Red Hat has ever done (and no major, commercial entity has ever repeated). Red Hat already offers a more flexible avenue for the community with Fedora Core (like Red Hat Linux before it), which feeds into RHEL. So anyone who thinks an Oracle endeavor is going to involve more of the community is rather near-sighted. Such focus away from supporting Oracle's core (and quite proprietary) applications is just going to distract from there ability to do so.
This is where Red Hat's comments are very accurate with regards to lack of certification and ABI/API compatibility. While Oracle clearly believes it can do a better job with its own distro for Oracle applications, that's not necessarily true of other applications outside of Oracle. So if you're running applications certified with RHEL, you want to stick with RHEL! As always, Red Hat's commentary on announcements like this are direct, true and don't bother with the rhetoric, just facts.
Ellison's Rhetoric (And How To Look Past It)
Now Ellison is outside reality. Specifically his comment that Red Hat doesn't support old versions. I think he's thinking of Fedora Core, like Red Hat Linux before it. No Fedora Core or Red Hat Linux version has been supported more than 4 years total. In fact, Red Hat's official stance has always been 1 year, although they have often supported many versions for 3+ years, and still do an average of 2-4 with Fedora Legacy (only recently dropping updates for Red Hat Linux 7.3 and 9).
Red Hat sells subscriptions, NOT fixed releases, of its Red Hat Enterprise Linux (RHEL) product. A Red Hat Network (RHN) membership is the entitlement to a RHEL WS, ES or AS editions at whatever version you want! That includes version 2[.1], 3, 4 or even 5 once it's released assuming your subscription is still good. Red Hat keeps the updates coming on its oldest releases, backporting fixes from newer packages to even old versions some 5+ years old to guarantee ABI/API compatibility to an anal power. Which leaves me I'm scratching my head on Ellison's statement.
Does Oracle plan on supporting its Enterprise Linux 10+ years? Not even Microsoft or Sun do that, and they would really have to spend a lot of money to do so! At my current client, we're already dealing with Sun's retiring of Solaris 8 come next February. My client is the leader in its market (financial trader systems), so they are currently in negotiations with Sun over an extended service contract for its niche needs. I don't see Oracle doing that in general (let alone for a $99 user), other than maybe for those who are already paying tens of millions of dollars for a particular Oracle product. If that's the case, and Oracle really does need 10+ years of support where Microsoft, Sun and others besides just Red Hat aren't willing to provide much more than 7.
In fact, that could be the driver. If so, then Oracle won't be alone in this approach in the future, if they can really do it. Other vendors who have clients that pay tens of millions of dollars for enterprise solutions might also need 10+ years of support, and figure the best way to get it is to leverage Linux, a platform they can control and modify -- unlike Solaris or Windows. That would make far more sense, although I don't know how feasible it could be to do so.
Other Commentary From Around the Industry ... (I'll respond to them I read them)
Steven Vaughan-Nichols of Ziff-Davis calls this a "rip-off." So what? If Oracle is going to release it's own version of RHEL separate from Red Hat, they probably have sound reasons for it. Looking past Ellison's rhetoric, Oracle is going to test out the feasibility of a major, enterprise application vendor taking the best enterprise Linux product they see and modifying it for just their product and supporting it as such. It was inevitable that someone would finally jump in and do it and Oracle's one of "biggest fish" that could actually do this. Oracle is going to have to continue working with Red Hat to ensure their releases are sync'd and leverage all of Red Hat's mindshare. So this isn't so much as a "rip off" as a "build upon" -- although I think Ellison's rhetoric and the $99 distro does look like a "rip off" that will quickly go away (or otherwise be ignored because it won't be supported by Oracle).
Jason Brooks' blog, who I tend to agree with more than Vaughan-Nichols, at Ziff-Davis, still seems to have a problem with history. He keeps calling for Red Hat to support Fedora Core. Red Hat is never going to formalize any support for or certify any applications against Fedora Core. They lost money trying to deal with freeloader expectations when they attempted to do so with Red Hat Linux, often supporting 6 or even 7 simultaneous releases for virtually free (or sub-$100/year). It's just not sustainable on a 6-9 month "product" release cycle, and it's cheaper for them to give it away for free, including maintaining the substantial infrastructure costs for redistribution (e.g., the Fedora Projects servers and infrastructure are much faster than the RHN was!). If you want to pay Red Hat to fix specific developer issues, including those in Fedora Core releases, they will -- but by the hour. Red Hat will only generally support a distribution with SLAs when it is unchanging, like RHEL.
Various People Buying Another Distro: I run Fedora Core at home. I support Debian and Gentoo in professional endeavors as well as RHEL -- especially liking Gentoo for bleeding-edge flexiblity early in development when libraries and other choices have not been made (and are not being supported or even in test yet). I'm sure if I didn't support RHEL as much, I'd probably run Debian-based Ubuntu instead of Fedora Core, and it's very popular because of its focus. But I honestly don't think people know what they are talking about when they say Oracle should have bought out another distro. Other than SuSE Linux Enterprise Server (SLES), there is no other distro that has maintained at least a 5 year ABI/API history. Buying Ubuntu would be like adopting Fedora Core -- even Debian or, better yet, supporting the DCC would be far better of a start. We're not talking consumer distros here, but trailing edge, strict ABI/API-anal, long SLA-supported distros. If Oracle would have bought anyone, it would have been Novell or Progeny (founded by Debian creator Murdock which integrates Debian for companies under strict principles of software engineering and enterprise configuration management, ECM), companies that understand enterprise roll-outs and long-term sustainability.
(I'll comment on others as I see them)
What is Red Hat Enterprise Linux?
Understand Red Hat has a very long-standing release model that remains unchanged since Red Hat Linux 4.0 (from the mid-to-late '90s).
Community Releases (6-9 months): They have a 2-3 month package selection program, and other 2-3 months of package testing (Fedora Development fka Red Hat Rawhide) and then a 2-3 month test release (Fedora Core Test, fka Red Hat Linux Beta) before Fedora Core (FC) is released (fka Red Hat Linux, RHL) every 6-9 months.
Enterprise Releases (18-24 months): After 2-4 release of Fedora Core (fka Red Hat Linux), Red Hat builds a new release of Red Hat Enterprise Linux (RHEL), including a formal series of Betas and then eventual release. As a result, RHEL is released every 18-24 months. It then supports RHEL at least 5 years, and it's looking more like 7+, standard. Currently, Red Hat is supported RHEL 2 (aka Advanced Server 2.1, based on RHL 7.2/7.3), RHEL 3 (based on RHL 9 / FC 1) and RHEL 4 (based on FC 3). RHEL 5 (based on FC 5/6) is currently in Beta, but its running into some non-package related shake-down issues with the new YUM-based update system (long story).
Unlike FC, and RHL before it, newer packages are virtually never made in RHEL. Red Hat backports some things in FC/RHL to maintain some compatibility, Red Hat always backports everything for RHEL to absolutely guarantee full ABI/API compatibility. This includes never changing the kernel or other, core components. Red Hat's sole focus with RHEL is Service Level Agreements (SLAs), guaranteeing any application will always run on the version, with any level of updates or other fixes. Although FC/RHL also try to maintain ABI/API compatibility, they do regularly gain newer versions of packages mid-version, as long as there are no major changes in general operation. Again, RHEL does this to an anal power, always backporting.
Despite popular statements, RHEL is still very GPL-centric. In fact, non-free software is located on a supplemental CD. While Red Hat does not allow the distro to be redistributed with its trademarks (more on that in the next section), it does release the full set of software in Source RPM (SRPM aka .src.rpm) format. This is unlike SuSE Linux Enterprise Server (SLES), who did not until after the Novell purchase.
The Red Hat(R) Trademark Debacle
To date, Red Hat(R) is the only major commercial entity who ever released a 100% redistributable distribution with its trademarks. This caused Red Hat a major headache, and was the primary reason why their 100% redistributable version was released as Fedora(TM). All while Red Hat was loose with its trademarks, SuSE(R) and many other distros were not (although Novell has since bought SuSE, and doesn't protect it nearly as much -- largely because they have their Novell name, long story).
Cobalt was one of the worst abusers of the Red Hat(R) trademark. They completely modified the distribution, but left Red Hat's trademarks intact. In fact, when many people complained about things or the "reliance on Red Hat," they didn't realize it was precisely because Cobalt had modified it so much that it was the reason, and not Red Hat. Red Hat largely ignored the issue, until Sun bought out Cobalt. When Red Hat finally barked at Sun's liberal use of their trademarks on heavily modified systems outside of even just Cobalt, Sun brought up the lack of enforcement and Red Hat legal went nuts because they had no recourse.
At first, Red Hat tried to clarify the usage of their trademarks to allow various projects, rebuilds and other, free software use. But the legal holes were still there, and plenty of redistributors -- redistributors allowed to use the Red Hat(R) trademark, still demonized Red Hat for it not realizing the real legal bind Red Hat was in. At some point, Red Hat finally decided to get out of supporting a low-end "product" altogether, and give it away (including supporting the infrastructure) for free. Today, despite several attempts to reorganize, Fedora Core (RC) continues to be developed and released to the exact same model and standards of Red Hat Linux (RHL) -- because it feeds Red Hat Enterprise Linux (RHEL).
And RHEL continues to be "free software," including the availability of SRPMs. As such, unlike SLES, there various rebuilds, including CentOS. In fact, CentOS is by far the leading rebuild. CentOS has worked with Red Hat legal in the past to ensure they are not violating any trademark laws that would require Red Hat to assert its ownership. And because of Red Hat's longer-term support of RHEL (7+ years), versus RHL/FC (only 3-4 years at best via Fedora Legacy), CentOS is becoming the basis for many new projects such as OpenFiler and SME Server (fka eSmith Server).
What Oracle Could Accomplish (Largely for Themselves)
I'm not going to give a simple "good" or "bad" comment on Oracle's move (although I will comment on Ellison's rhetoric below). Oracle has decided that Red Hat's support isn't cutting it. If they've decided this (regardless of what Ellison said), they've probably got a sound reason. As a result, it plans to offer a higher-level of support beyond what Red Hat offers -- at least from the standpoint of Oracle applications. If Oracle can pull it off, it could become the model to follow by several other, major enterprise vendors.
The idea here is that Oracle should be able to deliver a distribution that works better and reacts better to changes for, again, Oracle applications. They would not be doing this if they didn't A) feel that Red Hat's "base" is one of the best for enterprise applications, but B) Oracle knows its needs better than Red Hat or Red Hat can react with Oracle's current relationship. In fact, this whole endeavor may merely change how Red Hat and Oracle interacts, possibly bringing them closer together.
Now it's going to take significant resources for Oracle to do this. Again, I'm going to argue that a lot of cooperation with Red Hat itself is going to be unavoidable. Oracle would be shooting themselves in the foot if they didn't. But unlike projects like CentOS, which must maintain strict separation other than at the developer-level, Oracle can and should have a formal relationship with Red Hat. That's what really makes this different than what community projects like CentOS have done.
The $99 Release (Sorry, Don't See It)
I honestly don't know what Oracle expects to accomplish with a $99 release other than to cause itself headaches. Red Hat tried and tried and tried to stick with supporting a low-end product, and got out of it because you lose money. With not even 1/1,000th the desktop sales of Microsoft, you can't charge the same out of the pure reasons of economies-of-scale. So I think this will either be a short-lived option, or a basically "oh, you bought the $99 box, we won't talk to you, have a nice day" attitude that won't win them point. I think Oracle management will quickly realize this as well.
Just like Red Hat, Oracle will not be making it fully redistributable, especially if Oracle(R) is on it. It would lead them right down the same lack of trademark enforcement debacle that only Red Hat has ever done (and no major, commercial entity has ever repeated). Red Hat already offers a more flexible avenue for the community with Fedora Core (like Red Hat Linux before it), which feeds into RHEL. So anyone who thinks an Oracle endeavor is going to involve more of the community is rather near-sighted. Such focus away from supporting Oracle's core (and quite proprietary) applications is just going to distract from there ability to do so.
This is where Red Hat's comments are very accurate with regards to lack of certification and ABI/API compatibility. While Oracle clearly believes it can do a better job with its own distro for Oracle applications, that's not necessarily true of other applications outside of Oracle. So if you're running applications certified with RHEL, you want to stick with RHEL! As always, Red Hat's commentary on announcements like this are direct, true and don't bother with the rhetoric, just facts.
Ellison's Rhetoric (And How To Look Past It)
Now Ellison is outside reality. Specifically his comment that Red Hat doesn't support old versions. I think he's thinking of Fedora Core, like Red Hat Linux before it. No Fedora Core or Red Hat Linux version has been supported more than 4 years total. In fact, Red Hat's official stance has always been 1 year, although they have often supported many versions for 3+ years, and still do an average of 2-4 with Fedora Legacy (only recently dropping updates for Red Hat Linux 7.3 and 9).
Red Hat sells subscriptions, NOT fixed releases, of its Red Hat Enterprise Linux (RHEL) product. A Red Hat Network (RHN) membership is the entitlement to a RHEL WS, ES or AS editions at whatever version you want! That includes version 2[.1], 3, 4 or even 5 once it's released assuming your subscription is still good. Red Hat keeps the updates coming on its oldest releases, backporting fixes from newer packages to even old versions some 5+ years old to guarantee ABI/API compatibility to an anal power. Which leaves me I'm scratching my head on Ellison's statement.
Does Oracle plan on supporting its Enterprise Linux 10+ years? Not even Microsoft or Sun do that, and they would really have to spend a lot of money to do so! At my current client, we're already dealing with Sun's retiring of Solaris 8 come next February. My client is the leader in its market (financial trader systems), so they are currently in negotiations with Sun over an extended service contract for its niche needs. I don't see Oracle doing that in general (let alone for a $99 user), other than maybe for those who are already paying tens of millions of dollars for a particular Oracle product. If that's the case, and Oracle really does need 10+ years of support where Microsoft, Sun and others besides just Red Hat aren't willing to provide much more than 7.
In fact, that could be the driver. If so, then Oracle won't be alone in this approach in the future, if they can really do it. Other vendors who have clients that pay tens of millions of dollars for enterprise solutions might also need 10+ years of support, and figure the best way to get it is to leverage Linux, a platform they can control and modify -- unlike Solaris or Windows. That would make far more sense, although I don't know how feasible it could be to do so.
Other Commentary From Around the Industry ... (I'll respond to them I read them)
Steven Vaughan-Nichols of Ziff-Davis calls this a "rip-off." So what? If Oracle is going to release it's own version of RHEL separate from Red Hat, they probably have sound reasons for it. Looking past Ellison's rhetoric, Oracle is going to test out the feasibility of a major, enterprise application vendor taking the best enterprise Linux product they see and modifying it for just their product and supporting it as such. It was inevitable that someone would finally jump in and do it and Oracle's one of "biggest fish" that could actually do this. Oracle is going to have to continue working with Red Hat to ensure their releases are sync'd and leverage all of Red Hat's mindshare. So this isn't so much as a "rip off" as a "build upon" -- although I think Ellison's rhetoric and the $99 distro does look like a "rip off" that will quickly go away (or otherwise be ignored because it won't be supported by Oracle).
Jason Brooks' blog, who I tend to agree with more than Vaughan-Nichols, at Ziff-Davis, still seems to have a problem with history. He keeps calling for Red Hat to support Fedora Core. Red Hat is never going to formalize any support for or certify any applications against Fedora Core. They lost money trying to deal with freeloader expectations when they attempted to do so with Red Hat Linux, often supporting 6 or even 7 simultaneous releases for virtually free (or sub-$100/year). It's just not sustainable on a 6-9 month "product" release cycle, and it's cheaper for them to give it away for free, including maintaining the substantial infrastructure costs for redistribution (e.g., the Fedora Projects servers and infrastructure are much faster than the RHN was!). If you want to pay Red Hat to fix specific developer issues, including those in Fedora Core releases, they will -- but by the hour. Red Hat will only generally support a distribution with SLAs when it is unchanging, like RHEL.
Various People Buying Another Distro: I run Fedora Core at home. I support Debian and Gentoo in professional endeavors as well as RHEL -- especially liking Gentoo for bleeding-edge flexiblity early in development when libraries and other choices have not been made (and are not being supported or even in test yet). I'm sure if I didn't support RHEL as much, I'd probably run Debian-based Ubuntu instead of Fedora Core, and it's very popular because of its focus. But I honestly don't think people know what they are talking about when they say Oracle should have bought out another distro. Other than SuSE Linux Enterprise Server (SLES), there is no other distro that has maintained at least a 5 year ABI/API history. Buying Ubuntu would be like adopting Fedora Core -- even Debian or, better yet, supporting the DCC would be far better of a start. We're not talking consumer distros here, but trailing edge, strict ABI/API-anal, long SLA-supported distros. If Oracle would have bought anyone, it would have been Novell or Progeny (founded by Debian creator Murdock which integrates Debian for companies under strict principles of software engineering and enterprise configuration management, ECM), companies that understand enterprise roll-outs and long-term sustainability.
(I'll comment on others as I see them)
2 comments:
Shouldn't we abandon SUSE?
After the recent fiasco generated by Novell getting into an agreement with Microsoft and the whole Open Source Community planning to fight Novell both in and outside the court, will it be sensible to shift over to another Linux distribution? There are other distributions that are as good or better that SUSE so which will be best one to migrate to?
RedHat has been the choice for us, We use it for 6-7 years on about 10+ servers for 150 staff, mail, web, database, samba file server.. tried all the other distros but always came back to RedHat for one reason or another.
Post a Comment