(I'm Red Hat employee.)
just... throwing that out there.
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.
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. 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.
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.
They don't strictly have to put all the sources in a conveniently compilable format on FTP servers.
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.
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