[skrebbel]

Not knowing much about Linux distros, can anyone explain the popularity of CentOS to me?

I mean, having used it only a few times, my impression of CentOS is "a Linux with lots of horribly outdated software, in the name of compatibility and well-testedness". Eg when I used it last, the PHP version it shipped with was 8 years old.

Now, I understand the appeal of that to certain super risk averse enterprises who value stability over any kind of developer or user happiness (including the ability to run latests versions of userland software that happens to require somewhat recent php/python/etc versions). But aren't those exactly the kinds of enterprises that would want normal RHEL licenses anyway? If you scratch those out, what audience is left? Why would I run such ancient software for any technical reason?

I know this sounds dismissive, but I don't know how else to formulate this and I'd like to understand this. I think I understand RHEL and I think I understand Fedora, but I never got the appeal of CentOS.

[JeremyNT]

It's the same value as Debian stable: you don't need to mess with it, and you don't need to learn anything new until the next big release.

RHEL / CentOS also has a lot of commercial software packaged and sold for it. You'll find plenty of niche market software shops that don't want to bother targeting more than one distribution, and that being the case they target RHEL. If you're writing and selling some niche business software, do you really want to dedicate your limited support resources (which, let's be honest, are probably your developers!) to supporting other distros?

At the end of the day, what do you need from the distribution itself? It's a tool to run the software you care about. Some distributions take pride in providing that software as a part of the distribution, but not RHEL. RHEL is stable, it's a known entity. You want a newer version of PHP? Go for it, but you're building and packaging your own on RHEL. And for many shops - not just enterprises - the "you" here is not actually anybody at the company, but some external vendor or some OSS project maintainer who packages everything (including dependencies) for RHEL.

And by the way, this is why Docker containers are so popular now - you can incorporate whatever system libs you want directly in your deployment bundle, and know that if the base system can run Docker you don't have to think about it. Something old and crufty like RHEL, as long as it has good Docker support (yes, arguable...) - you never need to care how old and crufty it is (they DO backport major kernel improvements to their custom kernels).

[jsiepkes]

> super risk averse enterprises who value stability over any kind of developer or user happiness.

Some services just need to run and get security updates and no one cares about "new features" for them. They just need to keep running. At some point every company is going to end up with services which are like that (ie. in maintenance mode).

No user is going to care some feature was added to NFSv4. They will care if their shared drives are unavailable because some feature was added to the NFSv4 daemon which causes stability issues.

[helen___keller]

> I think I understand RHEL and I think I understand Fedora, but I never got the appeal of CentOS.

The appeal of CentOS was a gratis rebuild of RHEL, so if you understand why people use RHEL then CentOS is the same but without the paid enterprise support.

> Now, I understand the appeal of that to certain super risk averse enterprises who value stability over any kind of developer or user happiness (including the ability to run latests versions of userland software that happens to require somewhat recent php/python/etc versions). But aren't those exactly the kinds of enterprises that would want normal RHEL licenses anyway?

It's a jump in logic to assume that just because an enterprise wants stability, then they want to pay for support. That's simply not the case.

[lordlimecat]

Anyone who has dealt with diverse, mixed-distro environments can tell you that CentOS / RHEL is a lot more "stable" than Ubuntu. Go try to script ip address changes or MAC reporting across Ubuntu 12.04 - 20.04 for instance, theyve changed the tooling like 3 times. With CentOS, deprecation has a long tail, so whatever works on 8.0 is likely to work in 7.0 (going back to 2012) and maybe even 6.5.

Likewise, in those mixed environments, go run `apt upgrade` and `dnf upgrade` across the board; your CentOS / RHEL breakage will be quite small, compared with the havoc that will occur in your Ubuntu deployment.

[yjftsjthsd-h]

> With CentOS, deprecation has a long tail, so whatever works on 8.0 is likely to work in 7.0 (going back to 2012) and maybe even 6.5.

And the reverse is even more true: If your app worked on RHEL 5, you can probably blindly copy it to an EL 7 box and it will just work (ask me how I know;]), and probably it would for EL 8, too.

[marcinzm]

>developer or user happiness

Some developers just want to build software that works for a decade with a minor updates. They don't want to play a perpetual game of catch up to the latest trend and dependency overhaul. A consistent old version of PHP is better than having to rewrite their code every year as language features become deprecated or changed.

[macksd]

>> I think I understand RHEL and I think I understand Fedora, but I never got the appeal of CentOS.

A lot of the appeal of RHEL is being the de facto industry standard. CentOS also gives you that, just without the support contract, which many organizations just replace with their own capable admins. People may want the stability but don't otherwise benefit from the pricing model.

What actually never made sense to me was Red Hat officially embracing the CentOS project. A free clone will inevitably happen because that's exactly what the GPL intended. Red Hat has made lots of money by adding incremental work to a large body of other people's work. They make their money delivering value to their customers who do value faster patches and support, but the source code must remain free for everyone else. I'm not really sure what anyone, Red Hat or the community, got out of CentOS current "official" status.

[alphager]

If you try out CentOs and it doesn't work, there's a chance you try Suse, Ubuntu, Arch etc.

If you try CentOS and it does work, there's a chance you grow large enough to be able to pay for Redhat.

CentOS was inevitable, might as well go for scenario 2 than 1.

[macksd]

Makes sense. But what changed in practice that made scenario 2 more likely?

[angelbar]

mostly... Official support

[shawnz]

Contrary to some of the other replies here, I agree with you that there is no point in running CentOS on its own merits. Those looking for old software could just use Debian or Ubuntu LTS. But there is an important use case you're leaving out: Developing and testing software for running on RHEL. You probably don't need to purchase RHEL licenses with enterprise support just for running on your development machines.

The point of CentOS is (or was) not to just be a free, stable, rpm-based linux distribution. The point was to be bug-for-bug compatible with RHEL.

[ktm5j]

Stability. The software in CentOS is not the newest, but has been tested thoroughly.

Fedora is cutting edge, basically the testing release for the RHEL family. What is Fedora today will eventually become a RHEL/CentOS release down the road.

CentOS and RHEL are identical, but RHEL comes with support.

[elric]

The big appeal is (was?) stability and the huge LTS window. But unlike RHEL, it's free as in beer. If you're after the bleeding edge, CentOS is probably not for you. But if you want a system with regular security updates and not too many surprises, it's a really good candidate.

[CivBase]

Why wouldn't normal users want CentOS for the same reason enterprises want RHEL?

If I were more serious about the stability of my personal server and website, I'd probably have picked CentOS up until this fiasco. Since I tinker with it from time to time, I ended up just going with Ubuntu Server, but it isn't hard to see the appeal of CentOS.

Not to mention, enterprises love to save money. Plus, I imagine it's pretty attractive for many engineers to avoid the headaches of license management when dealing with containers and VMs. If you're not going to use the enterprise support that comes with REHL, why would you even bother with it?

[theevilsharpie]

One of the main use cases for CentOS is situations where you need to run proprietary third-party software that the vendor only supports on RHEL, which is unfortunately common in the enterprise space. CentOS is (well... was) intended to be a fully binary-compatible rebuild of RHEL (bugs and all), which provides a way of running this proprietary software without also needing to pay for and maintain licenses for the host OS.

[bamboozled]

“my impression of CentOS is "a Linux with lots of horribly outdated software”

It is and it’s the secret reason Docker and Containers became so popular.

I’ve been a systems administrator for sometime now. At some point developers wanted to run Python 3 on CentOS 6 and here we are.

It allowed the systems administrators to let the developers go wild in their own sandbox and keep the systems “pristine”.

[ofrzeta]

There are several third-party repos to install up to date software on CentOS.

[bamboozled]

It’s better now, wasn’t there when Docker came along.

You also missed my point, the infrastructure teams already built stable infra on CentOS, the work was done. They didn’t always account for people wanting to run new versions of Imagemagick to process user uploaded photos, . This is what developers needed. They wanted to pipe curl through gunzip to get what was required.

Docker ticked the boxes for devs and ops.

[ofrzeta]

Maybe I really don't get your point. I don't know about ImageMagick because as far as I am concerned there have not been any important features that made be want to use a newer version.

What I did want though, was newer versions of PHP, Python and GCC. They could be gotten through either the Red Hat Developer Toolsets (which by themselves are a great way of packaging the compiler because you could actually have different versions on one machine) or the IUS repos (as the acronym implies "inline with upstream stable", also a great achievement).

[calibas]

I think one of the main reasons it's still used is that the enormously popular cPanel/WHM requires CentOS or RHEL. It's a line of software that does system admin for you, which takes care of a lot of the PITA parts of CentOS.

Not that I recommend CentOS, I prefer Ubuntu, but I think that explains the main appeal, at least among web hosting services.

[freedomben]

Everyone is different. The appeal for me is that I know RHEL really well because of work, so for personal use CentOS is awesome (I can use all my expertise).

I have a few personal prod machines (my home router, a few personal website servers) that I need to run and I don't need support for them, and I can't afford a couple grand a year to pay for them nor would I. I'd just use something else.

That said CentOS Stream will likely be fine for me. I think RH bungled the news badly, but overall Cent is still pretty much fine. It's going to be way, way more stable than Fedora, and even Fedora wouldn't be all that bad in prod (I know because like a crazy man, I run Fedora in prod sometimes when I need fresh packages). Personally, I'm mostly upset about how this went down, not so much the outcome.

[scott00]

The main reason I use it for work is that software we buy (and is crucial to our business) tends to be only or best supported on CentOS/RHEL. The reason I chose CentOS over RHEL is that we don't have a large number of servers, so I'm guessing I would get fairly worthless support from RH even if I paid for it.

[Wheaties466]

its known for being super stable and battle tested. As long as your application didn't need features from OS's from the past year and just needed stable binaries and a stable OS. Centos was the best option in terms of stability and security.

At least that is how it was seen.

[walrus01]

It is indeed extremely conservative and behind the cutting edge on many things. Thus it's incorporated into things that need to 'just work' but don't need any advanced features, like the freepbx version of the main centos distro (a custom distro shipped by the sangoma company which now owns asterisk).

Generally whatever is in it is even older than debian-stable which also take a very conservative and cautious approach to rolling out new packages.

If you need to install a specific new version of a thing there is always elrepo and EPEL, which you can enable as a custom repository. I have one system that has a very recent 5.x series kernel running on a voip server, as a xen guest, because performance is much better with a kernel that's aware of all the most recent inter-kernel xen paravirtualization hooks.

http://elrepo.org/tiki/HomePage

https://fedoraproject.org/wiki/EPEL

example from my notes follows.

sudo rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org

sudo yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rp...

[myusername@freepbx ~]$ sudo yum --enablerepo=elrepo-kernel install kernel-ml Loaded plugins: fastestmirror, versionlock Loading mirror speeds from cached hostfile * elrepo: elrepo.org * elrepo-kernel: elrepo.org elrepo | 2.9 kB 00:00:00 elrepo-kernel | 2.9 kB 00:00:00 sng-base | 3.6 kB 00:00:00 sng-epel | 2.9 kB 00:00:00 sng-extras | 2.9 kB 00:00:00 sng-pkgs | 3.4 kB 00:00:00 sng-updates | 2.9 kB 00:00:00 (1/3): sng-pkgs/7-8.2003.3.el7.sangoma/x86_64/primary_db | 782 kB 00:00:00 (2/3): elrepo/primary_db | 479 kB 00:00:00 (3/3): elrepo-kernel/primary_db | 1.9 MB 00:00:01 Resolving Dependencies --> Running transaction check ---> Package kernel-ml.x86_64 0:5.9.7-1.el7.elrepo will be installed --> Finished Dependency Resolution

Dependencies Resolved

============================================================

Package Arch Version Repository Size

============================================================

Installing: kernel-ml x86_64 5.9.7-1.el7.elrepo elrepo-kernel 51 M

Transaction Summary

============================================================

Install 1 Package

Total download size: 51 M Installed size: 233 M Is this ok [y/d/N]: y Downloading packages: kernel-ml-5.9.7-1.el7.elrepo.x86_64.rpm | 51 MB 00:00:03 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : kernel-ml-5.9.7-1.el7.elrepo.x86_64 1/1

  Verifying  : kernel-ml-5.9.7-1.el7.elrepo.x86_64                                                                                                                                      1/1 

Installed: kernel-ml.x86_64 0:5.9.7-1.el7.elrepo

Complete!

may need to set the new kernel to boot in /etc/default/grub https://wiki.centos.org/HowTos/Grub2

[myusername@freepbx ~]$ sudo awk -F\' '$1=="menuentry " {print i++ " : " $2}' /etc/grub2.cfg [sudo] password for myusername: 0 : Sangoma Linux (5.9.7-1.el7.elrepo.x86_64) 7 (Core) 1 : Sangoma Linux (3.10.0-1127.10.1.el7.x86_64) 7 (Core)

grub2-set-default 0

reboot

ssh to the system

[myusername@freepbx ~]$ uname -a Linux freepbx.sangoma.local 5.9.7-1.el7.elrepo.x86_64 #1 SMP Tue Nov 10 09:56:43 EST 2020 x86_64 x86_64 x86_64 GNU/Linux

confirm that we're using the xen PV on HVM drivers in the kernel for much better performance

[root@freepbx .ssh]# dmesg |grep -i xen [ 0.000000] DMI: Xen HVM domU, BIOS 4.11.4 10/01/2020 [ 0.000000] Hypervisor detected: Xen HVM [ 0.000000] Xen version 4.11. [ 0.000000] Xen Platform PCI: I/O protocol version 1 [ 0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs. [ 0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks. [ 0.034434] ACPI: RSDP 0x00000000000F5A30 000024 (v02 Xen ) [ 0.034440] ACPI: XSDT 0x00000000FC00A8D0 000054 (v01 Xen HVM 00000000 HVML 00000000) [ 0.034448] ACPI: FACP 0x00000000FC00A5F0 0000F4 (v04 Xen HVM 00000000 HVML 00000000) [ 0.034456] ACPI: DSDT 0x00000000FC0012C0 0092A3 (v02 Xen HVM 00000000 INTL 20181213) [ 0.034469] ACPI: APIC 0x00000000FC00A6F0 000070 (v02 Xen HVM 00000000 HVML 00000000) [ 0.034474] ACPI: HPET 0x00000000FC00A7E0 000038 (v01 Xen HVM 00000000 HVML 00000000) [ 0.034478] ACPI: WAET 0x00000000FC00A820 000028 (v01 Xen HVM 00000000 HVML 00000000) [ 0.034483] ACPI: SSDT 0x00000000FC00A850 000031 (v02 Xen HVM 00000000 INTL 20181213) [ 0.034487] ACPI: SSDT 0x00000000FC00A890 000031 (v02 Xen HVM 00000000 INTL 20181213) [ 0.040587] Booting paravirtualized kernel on Xen HVM [ 0.040782] xen: PV spinlocks enabled [ 0.065203] xen:events: Using FIFO-based ABI [ 0.065210] xen:events: Xen HVM callback vector for event delivery is enabled [ 0.137093] clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [ 0.137105] Xen: using vcpuop timer interface [ 0.137113] installing Xen timer for CPU 0 [ 0.137489] installing Xen timer for CPU 1 [ 0.140515] xenbus: xs_reset_watches failed: -38 [ 0.504443] xen: --> pirq=16 -> irq=9 (gsi=9) [ 0.560804] xen:balloon: Initialising balloon driver [ 0.578529] clocksource: Switched to clocksource xen [ 0.593233] xen: --> pirq=17 -> irq=8 (gsi=8) [ 0.593278] xen: --> pirq=18 -> irq=12 (gsi=12) [ 0.593321] xen: --> pirq=19 -> irq=1 (gsi=1) [ 0.593362] xen: --> pirq=20 -> irq=6 (gsi=6) [ 0.981024] xen: --> pirq=21 -> irq=24 (gsi=24) [ 0.981232] xen:grant_table: Grant tables using version 1 layout [ 1.005806] xenbus_probe_frontend: Device with no driver: device/vbd/51712 [ 1.005806] xenbus_probe_frontend: Device with no driver: device/vkbd/0 [ 1.005807] xenbus_probe_frontend: Device with no driver: device/vif/0 [ 1.022168] systemd[1]: Detected virtualization xen. [ 1.436682] xen_netfront: Initialising Xen virtual ethernet driver [ 2.850090] input: Xen Virtual Keyboard as /devices/virtual/input/input6 [ 2.851114] input: Xen Virtual Pointer as /devices/virtual/input/input7

[rurban]

It runs about 80% of the internet, as you know it. Not much desktop usage, but almost all servers.