I see this as a good thing. Seems to me that we are basically getting back RedHat releases pre-RHEL. Fedora is great for the desktop, but I really like "Enterprise Linux" on the server side. I basically abandoned RedHat after the RHEL/Fedora split. Went to Gentoo (to unstable at the time) for a bit, Ubuntu, then CentOS during the late 4.x releases. I will pretty much stick with CentOS from here on out, why? Well enterprise customers who what support can get it, people who don't can easily use it, and those that don't want to pay now but know they will need to later will have an easy path forward. And its nice to have a major release that will remain stable and patched for a 7 year haul. Some folks seem to be concerned like this is a bad thing, RedHat has been a model citizen for open source. The amount of work they do in backporting fixes for people who need to remain on a version for whatever reason is huge. On top of the fact that they make most (all?) of their own software freely available as well. There is really no advantage for them to do anything to CentOS other than keep it doing what its doing, but faster.
To those wondering, I think that Red Hat doesn't make that much money from SELLING RHEL. It's the support, certifications and those things that are making Red Hat's budget. So CentOS and RHEL aren't really competing products. But Red Hat can now offer support even to CentOS customers.
I don't see why so many people think this deal is such a head scratcher. Red Hat is shifting away from pure support to a suite of cloud services. People are more likely to choose them if they are already using a Red Hat platform. This is especially useful if you're obliged to maintain a free version.
The moment you enter the blade business, you stop caring if someone is giving away your razors.
"The CentOS Project will expand its mission to provide additional open source technology-specific variant editions of the core operating system. Such editions will be capable of serving as a foundation for multiple, complementary cloud/virtualization projects. A current example is the Xen4CentOS project, which provides the components required to use CentOS 6 as a Xen host. Future examples will likely include variants to provide the virtualization component needs for OpenStack and oVirt, and variants providing hardware support and component updates for web hosters."
So they're publicly committing to continue to support that.
meh. From what I've seen it looks way better for "spin up a vm every now and then to test something" - But that's not what I do. My hosts run virtuals, and only run virtuals. But eh. I know many people who are obviously way smarter than I am telling me that KVM is the way to go. (I'm actually setting up a new KVM system for my old formerly known as tile networks customers this weekend. we will see)
I also have some (perhaps irrational? I have yet to test) fears about KVM's superior ram over-subscription mechanisms. That's the thing. Having poor over-subscription mechanisms is a honest signal to the customer that you aren't oversubscribing.
KVM systems can actually hand out host swap to the guests as if it were ram[1]. In a multi-tenant 'race to the bottom' kind of environment? Well, it hasn't happened yet, but I think it's quite possible that we will see KVM go the way of OpenVZ when it comes to multi-tenant setups, simply 'cause I could sell 144 gigabytes of ram on my servers with only 72 gigabytes of real ram. Aside from performance, I don't think customers would be able to tell. If I were to do that in Xen, it would be pretty goddamn obvious (I'd have to add the swap within the guest, so you could see how much swap you were actually using, then you'd have a 'balloon' driver eating up the ram that I said I gave you that you don't have.)
To be clear, feeding guests swap as ram is the most clumsy method of memory over-subscription. KVM has some super-slick methods... some of which are partly supported by later versions of Xen. Tmem actually can gain some benefits from oversubscription without any downside; e.g. deduping memory pages and using the leftovers for read-cache, that can be grabbed back by the guest. - but that isn't going to make the guest look like it has more ram, that's just going to make disk I/O slightly better.
On one hand, this might actually improve the state of CentOS. But on the other hand, it's a bit of a conflict of interest for Red Hat to be maintaining the free (as in freedom) version. The real question is, how compatible is the freemium (as in beer) business model with open-source interests?
No, it's a transition from Premium Enterprise Linux to Freemium Enterprise Linux, since the usage of CentOS pretty much made that already the case. They are so compatible that you can purchase support contracts for CentOS by doing an in-place upgrade to RHEL from CentOS for support.
This is more of a strategic move to make Oracle Linux and the other RHEL copies and CentOS-wannabes less compelling: many enterprises that are evaluating Oracle vs. Red Hat will stick to the single-vendor option, and many enterprises that are evaluating Ubuntu vs. CentOS can finally check both checkboxes for "corporate backed and officially endorsed" and "$0 to get started".
>This is more of a strategic move to make Oracle Linux and the other RHEL copies and CentOS-wannabes less compelling: many enterprises that are evaluating Oracle vs. Red Hat will stick to the single-vendor option, and many enterprises that are evaluating Ubuntu vs. CentOS can finally check both checkboxes for "corporate backed and officially endorsed" and "$0 to get started".
Yes. There are customers like me who are never going to give you $500 per server. sorry. it's just not happening.
But, eh, when I need money, you know what I do? I go work for larger companies, maintaining their servers. You know what I tell them to do? I tell them to go buy RHEL; It's a good product. They really do set things up so you don't have to do a major upgrade for ten years. And for the large companies? the $500 isn't a big deal, and the support really is worth something; they have someone to call if I'm not around.
CentOS was perfect for RedHat, because there is a real disadvantage to CentOS, even without the support problems; there's a delay. Nobody who can afford the $500 a machine is going to use CentOS, but it's there and good enough for those of us who can't.
Oracle changed this situation. Oracle will give you CentOS, for free, and is much faster at the re-compile. Now, I don't use it because I hate Oracle, but using Oracle has been the rational choice for some time now. (And I like RedHat. I mean, as much as you can like a company. Vs. Oracle? I am really rooting for RedHat here.)
My hope here is that RHEL will improve the compile-time of CentOS to where it's as good as Oracle.
I question my own understanding here, because I still don't think I grok all the motivation for this action (on both sides), but I don't think it's a conflict of interest. Nobody buys RHEL because they can't get it anywhere else. They buy it because it's what Red Hat officially supports. Or they buy it for one of the add-on projects that you have to pay for, like Satellite, etc. I don't think any of that changes with the merger. Just my 2c, though, because again - I feel like I'm missing something.
RedHat, already is free as in freedom, thats why CentOS is allowed to exist. They're just not Free as in Free beer. The corporations who pay for RHEL aren't going to suddenly cancel all of their support contracts.
What's the worst thing that could happen? CentOS is literally RHEL with the Red Hat branding removed. Even if Red Hat decided to cancel the CentOS project for some reason, the RHEL source code will still be available.
The worst that could happen would be that Red Hat would stop shipping sources for all the BSD/MIT/etc licensed bits, and be as difficult as possible for GPL sources (written offer, valid for three years, and making CentOS pay for the media costs, and then play stupid legal games with the requirement that it be `on a medium customarily used for software interchange').
They don't strictly have to put all the sources in a conveniently compilable format on FTP servers.
Oh, there's worse things Red Hat can do to block access to GPL source. For example, technically they only have to provide source to their customers, and there's nothing in the GPL that stops them terminating the contracts of any customers who distribute that source code and closing off their access to updates.
In a way they're already doing that with kernel source; the actual broken-out patches applied to the kernel are only available to customers and they're contractually obliged not to distribute them otherwise their contract will be terminated and they'll lose access to support, software and security updates and the right to run RHEL at all.
That's a pretty novel interpretation of the GPL, and I doubt that it would hold up in court. Reading through the GPLv2 I can't see anything in there that even suggests Red Hat would be within their rights to do that.
They still provide all the sources, as well as easy means to build them ( a source rpm ). This is far more than what the GPL requires them to do. What they don't distribute is the srpm with all of the patches neatly broken out by bug number and CVE (if applicable).
It makes it harder to figure out what sources came from RH, and what are vanilla kernel sources, but there's nothing in the GPL that says you have to detail the provenance of every line of source code distributed
