Comment Re:This would be really great... (Score 1) 90
I worked in Red Hat Support when both RHEL 4 and RHEL 5 were released. Yes, each one had growing pains that made it unsuitable for many users. Most of those problems involved:
1) 3rd-party kernel modules
2) combinations of motherboards/BIOSes/peripherals/firmwares that each individually worked fine, but interacted in a way that caused undefined behavior that just happened to work correctly on the previous release
3) hardware that wasn't available for QA prior to release
4) entirely new features that had never been widely used in enterprise environments.
5) inadequate configuration tools or documentation
The first three don't apply to a VM hosting provider, because they use racks upon racks of identical hardware that's been QA'd to death, and the guest OS can run either a fully-virtualized kernel that's been thoroughly tested against the VM, or a paravirtualized kernel that you've already QA'd yourself on your hardware and run across all distributions you offer. Most of the new features that the last two apply to are for scale-up use cases, not scale-down use cases, so they mostly don't apply to the typical VM hosting customer either.
My developers want a modern LAMP stack, like the one in Ubuntu 10.04, and I want to give them that without subscribing to 3rd-party repos maintained by people who don't know how to write an RPM spec file. I'd also like it running on top of ext4, with a bunch of other management goodies in the newer distro. A RHEL 6 VM would be perfectly fine for that.