Each platform you support comes with an associated cost. Typically you require:
- A build environment
- A separate test environment (for example, not having the development tools installed)
- Additional time to build and test new releases
- Additional resources to support each platform
CentOS aims to be binary compatible with Red Hat which lessens the need for a separate build environment. However, if you don't also have access to a CentOS environment, at least for testing, you might get caught out by subtle differences.
Theoretically you might be unable to reproduce an issue that occurs on a user's CentOS installation on your Red Hat installation.
You might also have to provide different installation instructions for dependencies due to the different repository organisation.
Repository Organisation
Red Hat as of RHEL 7 has split things up into many more repositories:
- atomic host
- server
- workstation
- optional variants of the above
- supplementary repos for the above
- beta repos for the above
In fact I count no less than 85 (as follows):
>yum repolist all | grep rhel | wc -l
85
This does not seem to be the case for CentOS 7 (please correct me if I'm wrong)
Moreover things available in one RHEL repository are not compatible with some of the others.
For example, docker from atomichost does not play well on my workstation install.
Java
This post
from 2016 mentions that (Oracle) Java cannot be installed directly on CentOS:
Red Hat has a contract with Oracle to redistribute Oracle Java SE
binaries (including the JDK and JRE) and to support those products as
part of a RHEL subscriptions. CentOS does not ship Oracle Java SE;
CentOS users who wish to use Oracle Java SE must download and install
it directly from Oracle.
Security Patches
Security patches are generally applied to CentOS very quickly:
- How long after Red Hat publishes a fix does it take for CentOS to
publish a fix?
Our goal is to have individual RPM packages available on the mirrors
within 72 hours of their release, and normally they are available
within 24 hours. Occasionally packages are delayed for various
reasons. On rare occasions packages may be built and pushed to the
mirrors but not available via yum. (This is because yum-arch has not
been run on the master mirror. This may happen when issues with
upstream packages are discovered shortly after their release, and if
releasing the package would break it's functionality.)
Red Hat provide extended life-cycle support for older versions (at additional cost). This means that you can get patches for critical CVEs for RHEL 5 while CentOS can simply write off CentOS 5 as no longer supported.
Notably there have been several critical CVEs affecting RHEL 5 since it (and CentOS 5) reached end of life.
See also Is CentOS exactly the same as RHEL?
Docker
With the rise of Docker we have a new difference:
Docker Community Edition (Docker CE) is not supported on Red Hat
Enterprise Linux.
You must instead buy Docker EE license.
You can install Docker-CE on RHEL using the CentOS repositories.
See install Docker CE 17.03 on RHEL7
But this is obviously an unsupported configuration.
This is an odd one as that decision is made by the Docker team and not Red Hat.
So presumably Red Hat could decide to support Docker CE if they wanted to?
The essential difference between them is still the same:
If you want commercial support and certification you need to pay for it (use Red Hat)
If you don't want it you can use CentOS.
Direction
From the CentOS FAQ:
Red Hat and the CentOS Project are building a new CentOS, capable of driving
forward development and adoption of next-generation open source projects.
This is corporate blurb but it could be taken as meaning Red Hat want RHEL to diverge from CentOS in some interesting but unspecified way.
Update: Dec-2020
The direction for CentOS is now clearer:
- CentOS 8 is to be end of lifed early (2021).
- CentOS 7 support continues until 2024.
- RedHat (now owned by IBM) will no longer provide a CentOS that competes with RHEL.
- They now have "CentOS stream" which is upstream from RedHat and acts a bit like a beta.
The best summary is probably - https://hackaday.com/2020/12/09/centos-is-dead-long-live-centos/
See also:
The eagle eyed may note that Fedora is an upstream version of RedHat.
So where does CentOS stream fit?
To explain the difference lwn says:
“If the distros were wooden furniture, RHEL would be a finished desk, Stream would be the unpainted and unsanded desk, and Fedora would be the tree.”
A further explanation and more positive spin on the split is given by:
Best Answer
The first one reports the UUID of the ext4 filesystem on the
md
block device. It helps the system identify the file system uniquely among the filesystems available on the system. That is stored in the structure of the filesystem, that is in the data stored on the md device.The second one is the UUID of the RAID device. It helps the md subsystem identify that particular RAID device uniquely. In particular, it helps identify all the block devices that belong to the RAID array. It is stored in the metadata of the array (on each member). Array members also have their own UUID (in the md system, they may also have partition UUIDs if they are GPT partitions (which itself would be stored in the GPT partition table), or LVM volumes...).
blkid
is a bit misleading, as what it returns is the ID of the structure stored on the device (for those kind of structures it knows about like most filesystems, LVM members and swap devices). Also note that it's not uncommon to have block devices with structures with identical UUIDs (for instance LVM snapshots). And a block device can contain anything, including things whose structure doesn't include a UUID.So, as an example, you could have a system with 3 drives, with GPT partitioning. Those drives could have a World Wide Name which identifies it uniquely. Let's say the 3 drives are partitioned with one partition each (
/dev/sd[abc]1
). Each partition will have a GPT UUID stored in the GPT partition table.If those partitions make up a md RAID5 array. Each will get a md UUID as a RAID member, and the array will get a UUID as md RAID device.
That
/dev/md0
can be further partitioned with MSDOS or GPT-type partitioning. For instance, we could have a/dev/md0p1
partition with a GPT UUID (stored in the GPT partition table that is stored in the data of /dev/md0).That could in turn be a physical volume for LVM. As such it will get a PV UUID. The volume group will also have a VG UUID.
In that volume group, you would create logical volumes, each getting a LV UUID.
On one of those LVs (like
/dev/VG/LV
), you could make an ext4 filesystem. That filesystem would get an ext4 UUID.blkid /dev/VG/LV
would get you the (ext4) UUID of that filesystem. But as a partition inside the VG volume, it would also get a partition UUID (some partitioning scheme like MSDOS/MBR don't have UUIDs). That volume group is made of members PVs which are themselves other block devices.blkid /dev/md0p1
would give you the PV UUID. It also has a partition UUID in the GPT table on/dev/md0
./dev/md0
itself is made off other block devices.blkid /dev/sda1
will return the raid-member UUID. It also has a partition UUID in the GPT table on/dev/sda
.