I know that "the vast majority of changes made (by CentOS team ndr) will be made to comply with the upstream vendor's re-distribution policies concerning trademarked names or logos"

But I'm looking for a way to measure the real differences between RHEL and CentOS. My goal is to demonstrate "scientifically" that is possibile to use CentOS for development and testing purpose and use RHEL in the production environment.

Any suggestion?

Thanks in advance.


Short of doing installations of both and running a fancy diff between the two and manually picking through the output, there's no real way to prove to most people that they're the same. Yes, they use the same compiler, and the same linker, and the same libraries, all with the same options, but many people don't see induction as proof.


Any answer must be tailored to just who it is that needs the proof (or what sort of "who"), and the level of proof (read: how tolerant the application is of differences).

For the casual: they build from the same sources, so they are functionally the same. You can obtain the source rpm for any given package through both distributions and compare them.

For the nit-picker: the two environments are provably not the same. Everything is rebuilt from the same sources, but the RH build environment is not perfectly described. Arguably the CentOS team's cannot be identical without constant inside knowledge. The artwork is clearly different. The updaters are clearly different: 5.x is closer since both use yum, in 4.x C uses yum and RH uses a proprietary one.

For the paranoid: if you allow updates, no two machines are going to stay the same unless you take extraordinary measures like cloning disks (and violate licensing...?).

For the practical: what does it matter to the application? We test on both. After we test on both, we can deploy both.


what's the logic for RHEL in production and CentOS in dev/test ?

frankly, even if they're "scientifically" the same, you should use 3 (ideally 4) identical environments for dev/qa/staging/prod.

  • I agree. Your environments should be as identical as possible. OS, clustering, load-balancing, whatever. They should match. Otherwise, you don't have a TRUE represntation, and after a production cut-over fails there will be someone who brings up "well, test isn't exactly like production". – Alex Apr 28 '10 at 17:00
  • 2
    Sadly, many companies won't pay for the extra commercial licenses. Often this means that staff have a limited number of servers for their non-production environments, or are forced to squish dev/qa/staging onto a limited number of licensed servers. Does RedHat offer a developer license? I have spoken to some people who believe the RHEL license only applies to production or public-facing servers. They then use the RHEL products behind the firewall. However, I don't know if those products are limited by the lack of RHN services, etc. – Stefan Lasiewski Apr 28 '10 at 17:34
  • Sorry, but these answers are not very pertinent to my question. – w00binda Apr 29 '10 at 16:33

But they aren't exactly the same. I know CentOS is binary compatible, but try hooking a CentOS box into a RHEL repo and upgrade something like gcc. Its messy. As above have said, the only real way is to use exactly the same setup in dev as prod.


cost. People only want to pay for production but by using centos for the other 2 you can spin up/down as many copies of centos as you want.


We use CentOS / RHEL for just this type of testing. However if you REALLY need to use RHEL for everything you can alway purchase one advanced and / or virtual license from RHEL and then deploy many machines via KVM. The advantage here is your are 100% apples to apples for the powers that be and you can spin up and turn down and test as needed. I think the advanced license supports up to 4 VM's and the virtual license is unlimited across as many as 6 sockets worth of machines.

That being said we have never run into a specific RHEL issues that could not be recreated on CentOS and/or vis versa.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.