On Wednesday 08 January 2014 14:48:21 David Sommerseth wrote: > On 08/01/14 01:33, Travis Heinstrom wrote: > > I think this is going to be interesting. CentOS has always been a RHEL > > clone, and I think Red Hat might try to kill the whole idea of a free > > "clone." > > That would be a stupid strategy. Seriously. If RH would manage to kill > CentOS, another CentOS variant, based on the same sources would pop up > as a replacement - or Scientific Linux would quickly gain even more > traction. That is simply a core feature of open source projects (such > as CentOS). > > In addition, claiming that RH might try to kill a free clone, that > sounds more like traditional "closed source" thinking. Which is not > even close to the values RH has: > <https://www.youtube.com/watch?v=ySyPIoyXJ-k> Working at a company that targets the RHEL platform as well as other distros which tend to have much more recent libraries and runtimes, I have to say it disambiguates a few things. For example, the argument to spend the effort maintaining dependencies (which are necessarily parallel and separate in many cases to system libs/runtimes/compilers) and package proper SELinux policies for our products is stronger now. Platform stability* and commonality is the main thing that Linux has historically lacked. I see this as one more way RH is trying to address that. Even if it is only going to marginally alleviate the issue in the minds of management, it'll at least spark some discussion at a few business software development houses. It also (and far more effectively) embraces/absorbs the 800-pound gorilla of free data center installs. It does this while marginalizing Oracle Linux as well as Oracle/IBM/HP/Microsoft/independent paid support offerings for CentOS. I can't imagine there isn't already a planned CentOS-to-RHEL or CentOS supported upgrade product. This sort of product will be the "obviously correct/safe" choice for an organization to make when it realizes that outside help is required to maintain a data center that has (for whatever reason) grown beyond the built-in management capability. [*"stability" in the development/investment risk<->reward sense, not in the sense of crash-happy systems.]