Forgot your password?
typodupeerror
Linux Business Red Hat Software Linux

Red Hat Nears $1 Billion In Revenues, Closing Door On Clones 201

Posted by timothy
from the playing-within-the-rules dept.
darthcamaro writes "Red Hat is almost at its goal of being the first pure-play open source vendor to hit $1 billion in Revenues. Red Hat reported its fiscal 2011 revenues this week which hit $909 million. Going forward, Red Hat has already taken steps to protect its business by changing the way it packages the Red Hat Enterprise Linux 6 kernel, making it harder for Oracle to clone. 'We are the top commercial contributor to most of the components of the Linux kernel and we think we have a lot of value and we want to make sure that, that value is recognized,' Red Hat CEO Jim Whitehurst said. 'In terms of competition, I don't think we necessarily saw anything different from before but I'd say better to close the barn door before the horses leave than afterwards.'"
This discussion has been archived. No new comments can be posted.

Red Hat Nears $1 Billion In Revenues, Closing Door On Clones

Comments Filter:
  • by Anonymous Coward on Thursday March 24, 2011 @06:29PM (#35606394)

    CentOS and Scientific Linux are still workable, it's the "enhanced clones" like Oracle and Novell that are cherrypicking RHEL's best customers and not giving back to the open source community with development in open source filesystems, X, authentication, and genuine hardware support that are messing up the business.

    It's just too bad CentOS has lost its way with one of its developers, Johnny Hughes, telling people to not let the door hit them in the ass on the way out if they don't like how late everything is and then ignoring attempts to help. I just switched to Scientific Linux and and am quite happy.

    • Re: (Score:3, Informative)

      by ustolemyname (1301665)
      I'm confused. How on earth do you think Novell is cloning RHEL? They are a significant contributer to linux, 3rd from the top [networkworld.com], and non-trivial user ecosystem (they supplied the devs who got alot of the new AMD graphics stuff going, as I recall.) Big contributers to KDE and libre office. If they contribute less then redhat, that would only be because they have less staff (I think... at least the suse part of them does, for sure).

      Suse is as different from RHEL as debian is. Yes, they both use rpms. Th
      • by Anonymous Coward on Thursday March 24, 2011 @07:46PM (#35607098)

        Take a look at Novell's "RHEL support" offering. It's turned out to be complete crap, repackaging RHEL packages and alleging to offer one-stop support for SuSE customers, and blaming any problems on RHEL to convince customers to switch to SuSE.

        http://www.novell.com/promo/suse/free-30days-expanded-support.html

        It's complete bait and switch.

    • Re: (Score:3, Informative)

      by larry bagina (561269)
      oracle is funding btrfs development.
    • by somenickname (1270442) on Thursday March 24, 2011 @08:07PM (#35607214)

      I'm really surprised that this comment was modded up. Oracle is responsible for btrfs (negating the "filesystems" argument), Novell was the catalyst for the modern linux composited desktop with compiz/Xgl (negating the X argument), and if I thought about it for more than 10 seconds, I'm sure I could come up with a shitload of other examples where these two companies that you've "cherrypicked" have been a driving force for good in the linux world. I do agree with your sentiment but, you sound bitter for these companies not having contributed to technologies that you don't realise you are using. But, most likely, the have. And in a big way. I'm all for hating companies like Oracle but, hate them for the right reasons.

      • I installed Oracle Linux 6 this week to test. Besides the blinding red color of everything, I was a bit annoyed to see how many times I saw the word "RedHat" in the installer and the boot process.. I mean, if your going to rebrand it, then freaking re-brand it!

        • by _Shad0w_ (127912) on Friday March 25, 2011 @03:09AM (#35608854)

          I think the bit of Oracle Linux which bemused me was the fact that installing Oracle 11g on it is is still non-trivial; it requires you to install a bunch of packages and tweak kernel settings. If you're going to distribute your own brand of Linux, you could at least have an installer option for "This is going to be an Oracle RDBMS server, please install everything I need and configure the kernel as needed". Giving you a script to run as root part way through the RDBMS install process doesn't really cut it.

          • by bsDaemon (87307)

            If they made that easy, companies wouldn't need Oracle DBA staffs whose primary job is to deal with Oracle Support, so their support and training business would take a hit. I don't think they really want to make it easy.

          • To the other guy who responded to this comment: If your DBA has to call Oracle support to figure out how to install it on Linux then you need a new DBA. It takes 10 minutes to prep a RedHat OS to install Oracle, its not complicated.

            As for Oracle Linux, there is a package you can download which will install the pre-reqs called oracle-validated. From the links below:

            Named after, and derived from Validated Configurations, oracle-validated also creates an oracle OS user and an oinstall and dba group. Kernel p

    • by CAIMLAS (41445)

      The one that interests me the most (because it impacts me most directly) is XenServer. It's supposedly based on RedHat as well, and they do a degree of kernel hackery to get all their Xenery to work. I'd be curious to see where that will go, given that XenServer development isn't exactly what you'd call cutting-edge in many regards: Citrix seems to just cut and release, with little regard for many important things like documentation being up to date or full hardware support.

    • by _Shad0w_ (127912)

      You appear to be ignoring the bit where Oracle is developing btrfs and CRFS.

    • I agree, however RH fails to realize that whatever code they are applying to the kernel does not belong to them, it belongs to the open source community of Linux, which is an open distribution that everyone is allowed to code for and as such deploy, but can not directly make money from, and this business model that RH says they are using, is supposed to be only for the service and support they offer with their packaged distro, however, keeping code secret, and making it that now what you pay for is the extr

      • by McKing (1017) on Friday March 25, 2011 @09:29AM (#35611272) Homepage

        Redhat is allowed to do exactly what they are doing. Nothing in the GPL requires them to make their changes available upstream (although they usually do), it requires them to make any changes available to their customers. They still release their changes to the kernel source code, but they changed the way those changes are distributed to their customers.

        They used to make these changes available as a patch set that could be applied to the vanilla source from kernel.org. "Enhancers" like Oracle and others would take the vanilla source, cherry pick the patches that they wanted to apply out of Redhat's patch set, and compile the kernel, possibly adding in their own patches. Now Redhat is making the changes available in a single large pre-patched tarball, which means that if Oracle doesn't want to apply all of the patches, then they have to hunt down the changes themselves which is more time consuming and error-prone.

        Say Redhat comes up with a patch that tweaks the filesystem code in a way that in some cases makes an Oracle DB 10% slower. In the past, Oracle would just apply all RH patches except that one. Now they have to take the vanilla source, diff it against Redhat's patched source, hunt down all the changes related to that filesystem patch, back those changes out manually, and hope that they got it right.

      • by McKing (1017)

        The Linux kernel doesn't belong to you or me or "the community", it belongs to the copyright holders, with Linus as the arbiter of their rights. Redhat isn't closing the source or keeping anything secret, you've misunderstood both how Redhat works and also how the GPL works.

        Nothing in the GPL says that you can't make money directly from GPL'ed software. You're free to take any GPL'ed software, compile it, put it on a CD, and sell it as-is. In fact, that is how Redhat and a lot of others got started. Wha

  • Will I still be able to get the clone in the form of CentOS? I use CentOS a lot in our development environment and less critical infrastructure, just to make sure that I'll be able to upgrade it to RHEL if the system requires more professional support.
    • by MrClever (70766) on Thursday March 24, 2011 @06:37PM (#35606498) Homepage
      Under the GPL, my understanding is that RedHat need to make the source code available. This then allows CentOS to grab the source (RPMs) and re-badge/recompile it into a new distribution. So I don't think this distro is going away any time soon.
    • by petermgreen (876956) <plugwash.p10link@net> on Thursday March 24, 2011 @06:38PM (#35606504) Homepage

      Straight clones should still be possible as long as redhat complies with the GPL, the main things their changes to kernel packaging will do it

      1: make it harder for unrelated distros (e.g. debian) to pigyback of redhats long term support work for kernel releases
      2: make it harder for anyone else to provide high quality support for redhats patched kernels by making it much harder for them to answer the question when something goes wrong of "what did redhat change and why".

      • by doomy (7461) on Thursday March 24, 2011 @08:50PM (#35607400) Homepage Journal

        Straight clones should still be possible as long as redhat complies with the GPL, the main things their changes to kernel packaging will do it

        1: make it harder for unrelated distros (e.g. debian) to pigyback of redhats long term support work for kernel releases 2: make it harder for anyone else to provide high quality support for redhats patched kernels by making it much harder for them to answer the question when something goes wrong of "what did redhat change and why".

        Debian does not use Redhat kernels. Two different distributions, packing systems and philosophies.

        • by rajafarian (49150)

          Holy stuff, you have a very low /. ID number!

          I switched to Debian from Red Hat way back when Red Hat started going commercial. I send them a check every once in a while. Debian and the packaging are sublime compared to my experience with RPMs. I assume file dependency hell has been fixed. I still get newbies going on Kubuntu, though...

        • Indeed but IIRC they have with some releases deliberately picked the same version as redhat so they can cherry pick redhats fixes rather than having t do the backporting themselves.

        • by makomk (752139)

          Debian does not use Redhat kernels. Two different distributions, packing systems and philosophies.

          They do, however, both use 2.6.32-based kernels. All the non-RedHat distros are cooperating to maintain a handful of kernel releases as long-term support releases and 2.6.32 is one of them. Red Hat's move to hide what patches they've included in their own kernel is hindering this effort and increasing the inevitable divergence between Red Hat 2.6.32 and the official upstream 2.6.32 releases.

    • by F.Ultra (1673484) on Thursday March 24, 2011 @06:40PM (#35606524)
      It means exactly nothing for CentOS. CentOS clones the RH kernel 100% anyways and is not interested in the individual patches. This is only to stop Oracle from selling support contracts for Red Hat installations. So it has exactly nothing to do with cloning and everything to do with support (in order to support RH systems, Oracle would need to know which patches RH has and more importantly: why).
  • Well that's ominous (Score:5, Interesting)

    by subreality (157447) on Thursday March 24, 2011 @06:40PM (#35606528)

    TFA doesn't specify what this actually means, so let me speculate. They're not going to go closed-source; they'd be lynched. I think this is a reference to the fact that they're distributing their source prepatched now, to make it harder to just take their patches and apply them to other distros.

    IMO that's kind of sleazy. They got where they are standing on the shoulders of giants. The deal was: here, have this free stuff, build on it, make money with it, but you have to keep giving back. And they got their value out of it, but now they're trying to give back only the minimum they're contractually obligated to do. It's legal and not purely evil, but still moderately scummy.

    I don't really see it being that good for them, either. Oracle isn't going to have much trouble reverse-engineering the patches back out, but RedHat now ends up in a more difficult position: fewer of their patches will be incorporated upstream, so they have to spend more work porting them into each new release; they'll have less community review and bugfixes in their patches; and they're going to alienate the community.

    On the other hand RH users won't end up in the worst scenario: stuck using RH's buggy crap and unable to do anything about it. The source will still be there; they can still dive in to figure out what's wrong and fix it instead of dealing with a black box. I know I had to more than a few times when supporting RHEL systems.

    • by h4rr4r (612664) on Thursday March 24, 2011 @06:54PM (#35606648)

      RedHat employs Kernel devs, their patches go directly into upstream. This is for patches that will never make it into upstream for that kernel. Basically all the stuff RedHat backports to the old crusty kernels they use.

    • by Trufagus (1803250) on Thursday March 24, 2011 @06:56PM (#35606684)

      As far as I can tell RH does give back. They give back a lot. And it must get kind'of annoying for them that other companies - some of whom give back nothing - copy RH Linux and significantly undermine RH's ability to earn revenue from their distro.

      There are tons of companies out there that violate the GPL, give nothing back, or even actively undermine open source. I would suggest that your disapproval is better directed at them.

      • it must get kind'of annoying for them that other companies - some of whom give back nothing - copy RH Linux and significantly undermine RH's ability to earn revenue from their distro.

        But never forget that the vast majority of what Red Hat packages was created for free by others. Yes, Red Hat pays the most open source developers of any company with the possible exception of IBM, but that still amounts to just a small fraction of what they bundle up and sell as theirs.

        To be clear, I have absolutely no problem with Red Hat bundling up tons of free software and selling support for it. I do have a problem with Red Hat whining and playing sneaky tricks with source distribution, just because s

        • Red Hat sells support, not software, they would do well to remember that.

          Both; to be honest; their Release CD images are still valuable. The fact that they limit access to the open access to the support forums is a complete pain even when we are fully paid up because most of our internal users aren't registered with RedHat and so we will never give direct access to all the people who might need it.

          I'm not yet at all sure that this RedHat thing is a big problem; if it really is, then the correct solution is a license change at the kernel level. If RedHat can do this, then s

        • by drinkypoo (153816)

          You call "not releasing their change set as a patch" sneaky? Because I don't. If Oracle wants to do the work of a distribution for real then they can do that. Otherwise they can stop putting their name on shit. If they were smart they'd get someone to create and release a branded Linux for them. They're not smart, they're just powerful. Who goes Oracle on purpose?

    • by diegocg (1680514)

      fewer of their patches will be incorporated upstream

      Red Hat already submits all their stuff to mainline. They do it themselves, and they do it in advance, before they incorporate it to their product. How they pack their .SRPMs does not affect to how they upstream their code.

      Oracle isn't going to have much trouble reverse-engineering the patches back out,

      I doubt it.

    • by kmdrtako (1971832) on Thursday March 24, 2011 @07:05PM (#35606754)

      ...fewer of their patches will be incorporated upstream, so they have to spend more work porting them into each new release; they'll have less community review and bugfixes in their patches; and they're going to alienate the community.

      I guess it's not well known, even though it's not a secret. Red Hat pushes their fixes upstream first. After, and only after, they are accepted upstream are they then incorporated into the RHEL kernel.

      • That's a good point. And a lot of their work is in backporting new features into old kernels, to which my criticism is less valid.

    • by Kjella (173770) on Thursday March 24, 2011 @07:21PM (#35606890) Homepage

      I don't really see it being that good for them, either. Oracle isn't going to have much trouble reverse-engineering the patches back out, but RedHat now ends up in a more difficult position: fewer of their patches will be incorporated upstream, so they have to spend more work porting them into each new release; they'll have less community review and bugfixes in their patches; and they're going to alienate the community.

      I very much doubt Red Hat has any plans to change the way they work on the kernel master branch. This seems to be about their cherrypicking and backporting of patches to RHEL kernels. They want other distros - particularly Oracle it seems - to either do that work themselves or admit they are just rebranding Red Hat's work. For example in that big mega-patch they can simply add a few whitespace changes, if the same changes show up in Unbreakable Linux you know they started with the Red Hat kernel and worked from there. To be honest, I'm somewhat ambivalent about the whole thing. Making it a bit harder to cooperate is bad but making sure credit goes where credit is due is important so that people do the "invisible" work too.

    • by msobkow (48369) on Thursday March 24, 2011 @07:26PM (#35606942) Homepage Journal

      If you want scummy, look to companies like Oracle which just take, repackage, and rarely give back. They're the real problem, not RedHat.

      RedHat's patches still get submitted upstream for inclusion in the main kernel, which very often does happen.

      I have no sympathy whatsoever for leeches that were taking RedHat patches and rolling their own distributions without contributing enough back on their own.

      I fail to see how this affects seperate distros like Debian, which aren't based on RedHat-patched source in the first place.

      • I actually don't have a problem with that. RedHat does not have an exclusive right as a distributor. My personal belief is that if the world gets better use of the software by distributing it more in this manner, that net good is being done.

        The GPL ethos is you sell support, not software. The playing field is supposed to be level for the software, and you make a name by being the best at support. What RH is doing here is pushing for the software itself to be the feature they're selling, and that's going

    • by seifried (12921) on Thursday March 24, 2011 @07:29PM (#35606976) Homepage
      http://lwn.net/Articles/222773/ [lwn.net]. Red Hat plays very well with others. Part of the problem is the logistics, with Git and new Kernel development you're looking at literally thousands of source code patches (which would make for a completely unwieldy SPEC file) because Red Hat back ports stuff to keep a stable Kernel in the Enterprise Linux..
    • can hardly agree more.
      but i also fear that open source success is going toward this kind of crap: make it hard to get the source / changes properly, inserting as many BSD-licensed-and-don't-give-anything-back code etc etc. Not counting all the lets-use-GPL-closed-source-its-unlikely-we-get sued (RedHat of course will never do that, but SO many small companies do)

      Oh well, human nature & stuff.

    • TFA doesn't specify what this actually means, so let me speculate. They're not going to go closed-source; they'd be lynched. I think this is a reference to the fact that they're distributing their source prepatched now, to make it harder to just take their patches and apply them to other distros.

      One problem I see with this is that current installations of RHEL have to be patched too. Businesses relying on RHEL who can't get patches will possibly switch. If Red Hat wants to grow more it can't treat it's customers like MS does, like shit.

      Falcon

      • RHEL customers don't need the individual patches. They just download and install the updated RPMs from RedHat.

        Or do I misunderstand what you're saying?

      • What are you talking about... redhat customers will get patches... it's just the source for back-ported patches will e a little harder for Oracle to rip & apply
  • by 3vi1 (544505)

    Someone educate me: Why are people incapable of running the diff command between Red Hat and the pure kernel sources in order to get just the patches?

    • Well, that would give you one very large diff and not several specific ones that you could pick and choose between.
    • by TheUni (1007895)

      "just the patches" would be nice. But a diff doesn't give you that. It gives you a monolithic patch with no history or context.

  • Do not panic (Score:5, Insightful)

    by stikves (127823) on Thursday March 24, 2011 @06:50PM (#35606618) Homepage

    I believe they have no beef against CentOS, actually I've seen at least one Red Hat employee encouraging the use of CentOS, since Red Had is the "de facto upgrade path" (not the exact words, but something along this way). So you freely enlarge the customer base, which will go to Red Hat when they need higher level commercial support. And for the free ones, even Microsoft has recognized they cannot sell to students, and are giving away the software anyways.

    However Oracle is another deal. They just slap Oracle logo on Red Hat, do not acknowledge the source, and sell is as "unbreakable Linux". This would make a regular person ashamed of himself. They benefit a lot from open source but not giving back much in return. Do not start me with what they're doing to Solaris, Java, and OpenOffice...

    So I'm with Red Hat on this one, at least until they do something directly bad to CentOS.

    • by GrBear (63712)

      I believe they have no beef against CentOS, actually I've seen at least one Red Hat employee encouraging the use of CentOS, since Red Had is the "de facto upgrade path"

      Actually I just migrated our servers from RHEL to CentOS being as RH jacked up the prices for support by a fair amount. My $350/yr per server included limited support AND updates, and now it's only updates.

      RH can pound sand, I still get the same benefits of a "RHEL distro" w/o the $350/yr charge.

  • Scientific Linux 6 (Score:5, Informative)

    by KainX (13349) <mej@eterm . o rg> on Thursday March 24, 2011 @07:24PM (#35606920) Homepage

    Scientific Linux 6 is already out. See http://ftp1.scientificlinux.org/linux/scientific/6.0/x86_64/os/sl-release-notes-6.0.html [scientificlinux.org] for their detailed release notes. If there was any doubt in your mind that the direct rebuild projects are unaffected by this move, there shouldn't be any longer.

    It's pretty clear they're trying very hard this time around to stay in lock-step with upstream (what they call TUV and what CentOS calls PNAELV) and add fewer packages into the mix directly. They're also funded to do this work full-time by the US government, and since many universities and national labs rely on SL, it's not going away any time soon.

    If you've never tried it before, I encourage you to do so. To quote the old tagline, it's already ready already.

    • by CFD339 (795926)

      Thanks for that. I've been using CENTOS and been quite happy with it. For what I do, I don't need to be (and will never really be) up to the minute with versions anyway -aside from keeping up with security patches to the extent I can. Are there good reasons, other than speed of the release cycle, to move from CENTOS to SL?

  • putting the centos stuff aside. Redhat are doing a great job and contributing great code to the open source community. They uphold open source ideals by keeping fedora free of closed source code. I have been using Redhat/Fedora for years through my undergraduate degree, PhD and now in my job want to say what a great big thanks to you guys and wish you the best for the future!
    • And RedHat _directly_ pushes their upgrades back to the linux kernel and numerous other projects. The original poster has _no_ idea what they're talking about. This is not a change to general RHEL packaging, it's only a few abused packages, such as the kernel, which Oracle modifies heavily in their repackaging for this "Unbreakable Linux", which frankly isn't "Unbreakable", it's merely tuned for Oracle, which is typically very fragile.

  • by 2Bits (167227) on Thursday March 24, 2011 @08:13PM (#35607240)

    If every distro is doing the same thing, this is not going to be very good for the future of Linux. Engineers at every distro are going to waste a lot time trying to figure what other distros had been patching, which part of the code had been changed while a specific issue was fixed, etc. Everyone is going to end up wasting a lot of time, and creating a lot of confusion.

    Even though Linux distros are quite fragmented, but the current kernel development has been working quite well, because every distro is playing by the rule (more or less), which is quite transparent. Now, with this kind of one time big change by RH, even though you can still diff on all the source codes, it's not going to be easy to figure what has bee done (and why). And I think it's going to trigger other distros to behave similarly.

    And it will be even harder for the users. As a user, if we have in-house-built applications that rely on specific version of a library or module, we might not want to have a giant patch on basically everything, we probably want only small, concise, specific patch for some critical security problems. I'm starting to wonder how are we going to manage that.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      It wont be a problem because all the patches/fixes end up in git form upstream first, before they even hit a shipping RHEL kernel. Because of this, there is no confusion. I don't think you even use Red Hat Enterprise Linux as a product as you can't pick and choose patches and still remain in support for that modified package. You may as well just build upstream and port back those security fixes you need, which you can do because the fixes are pushed there first.

      If this is the case, and I'm just imagining

      • by makomk (752139)

        It wont be a problem because all the patches/fixes end up in git form upstream first, before they even hit a shipping RHEL kernel.

        Except that no distro uses the raw, bleeding-edge upstream git version of the kernel that RHEL's sending their patches to. They all use an older release with backported patches. If every distro was to maintain their own version of the kernel and keep it a secret which backported patches they were including like Red Hat is doing, there'd be a huge duplication of effort as everyone had to figure out for themselves which patches needed backporting in order to fix specific bugs. What's more, users would encount

    • If every distro is doing the same thing, this is not going to be very good for the future of Linux.

      If every distro were doing as much (proportionally) upstream work as Red hat, it would be very good for the future of Linux.

      Engineers at every distro are going to waste a lot time trying to figure what other distros had been patching, which part of the code had been changed while a specific issue was fixed, etc.

      But, they shouldn't be. They should be tracking *upstream*, putting their effort into *upstream*, instead of following other forks of the kernel.

      Even though Linux distros are quite fragmented, but the current kernel development has been working quite well, because every distro is playing by the rule (more or less), which is quite transparent.

      But, this has nothing to do with upstream kernel development, to which Red Hat is still contributing directly. This only has to do with development of Red Hat's Linux-based kernel (which is actually a fork).

  • by CheerfulMacFanboy (1900788) on Thursday March 24, 2011 @10:49PM (#35607972) Journal
    No jokes about "Begun, the Clone War has"? I'm so disappointed.
  • So basically Red Hat is telling us because they cannot legally change to be a fully closed source project they will just try to go against the spirit of FOSS as much as possible without breaking the letter of it?

  • As a user of Linux since Slackware was on 13 floppies, here's what I don't understand about the distros: Instead of sticking with an old kernel release and backporting patches, why not move forward to the latest kernel? Coming from the days were it was more common than not to compile your own kernel from vanilla source for whatever distro you were using, I've never gotten in trouble doing that. A few times I've left out an option and had to recompile. But I've never had a new vanilla kernel break other aspe

  • Linux-Mag covers the Rat Hat decision much better

    http://www.linux-mag.com/id/8414/

    Increasingly, Red Hat’s major competition is just saying “hey, we’ll let Red Hat do the engineering work and just provide support.” This is true of Oracle, and Novell to a lesser extent. Oracle has been riding on Red Hat’s coattails for years and has said it would do just that, saying that companies should compete “purely on the support side of the business.”

    Novell still does its own very fine Linux distro, but if you look carefully, the amount of new features and energy put into its Linux distro the past few years has waned a bit. The company has ramped up support offerings for RHEL in the meantime, and put a lot more energy into things like SUSE Studio.

    Oracle is just content to leech off of Red Hat. While Novell is trying to woo customers over to SLES by supporting RHEL as a bridge to SLES, Oracle just freeloads off of Red Hat’s distribution.

    It’s a good thing that the GPL and other open source licenses allow companies to jump in and provide support for competitor’s products. But this trend isn’t healthy for the larger community — and it’s not something that can or should be solved by licensing. Companies in the market for Linux services should exercise a little forward thinking and reward the companies that are doing the most to maintain the ecosystem. Here’s a hint: It ain’t Oracle. Even if that Oracle support contract is a bit cheaper than Red Hat’s right now, what do you think Oracle’s going to charge if it manages to marginalize Red Hat?

    Bottom line: If you want to snipe at Red Hat for its admittedly community unfriendly change, at least recognize that the company is still doing more than its share of the work.

"How to make a million dollars: First, get a million dollars." -- Steve Martin

Working...