Centos.rip(centos.rip) |
Centos.rip(centos.rip) |
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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”.
Not that I recommend CentOS, I prefer Ubuntu, but I think that explains the main appeal, at least among web hosting services.
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.
At least that is how it was seen.
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
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
Hopefully the same forces that lead to the creation of CentOS will Also lead to the establishment of a replacement project, and there are hopeful signs in that direction.
Does anyone know if the licensing is permissive enough to enable Centos spin-offs? If that's possible there's a decent chance some company will jump on it and fill the void.
I honestly hope this is what's going to happen.
That didn't age well. Maybe we'll see a Scientific Linux comeback.
Now that this changed, I wonder, do RHEL sources are still available 100% identical to their binary? Or the announcement yesterday just broke GPL2 compliance?
In the same family of RHEL clone distros there is at least:
* Oracle (yuk)
* Scientific Linux (though I don't think they attempt to guarantee binary compatibility as CentOS does/did)
Everyone coming in has always been keen on just getting CentOS up for a server. Outside vendors also just tell me: "we need CentOS X for this", and I've never understood the reason for that.
Having run both systems, I know that Debian is much more solid.
Sometimes the argument even comes down to: "Oh but when I search online for guides, it's always RedHat/CentOS"
It's driving me mad sometimes.
Not saying to switch to it, but it isn't like the server implodes if you disconnect a credit card swiper from it.
CentOS impressed me so much in the years I've been using it that I wanted to grab a RHCSE and start recommending subscriptions to my clients.
After pulling the rug out from under my feet I will no longer be interested in recommending anything under the Red Hat brand. We will migrate to another solution for our internal systems and not look back.
I still run CentOS on many of my dedicated servers (now known as bare-metal) from a decade ago. While almost everything else was all custom-built anyways, I guess the lack of core updates is going to be a problem. Though, CentOS 6 was going to reach EOL soon anyways.
Might be able to pun off of “President’s Choice” = “PC” = “Personal Computer” somehow as well.
Edit: Comment below beat me to it, nvm
Looking for both volunteers or people who want to be paid for their efforts. Join us to secure Enterprise Linux as a free (as in beer and freedom) for the foreseeable future.
https://web.archive.org/web/20190808223051/https://antergos....
SourceHut runs entirely on Alpine, as do my personal workstations. It is extremely reliable, stable, and robust; maintainable over long periods of time with minimal effort; and small and simple enough to be easily understood by everyone responsible for its use on your teams. The package repositories are somewhat small - you may have to write some packages yourself, but don't be afraid of that. It's very easy and you would be well-advised to learn how it's done if you're going to invest in any distro.
I consider Alpine Linux to be a competitive advantage for my business. CentOS and RHEL provide the illusion of stability and an executive who will weep and beg for forgiveness when it breaks, but true stability is only possible through simplicity.
1. Denial
2. Anger
3. Bargaining
4. Depression
5. Acceptance
Thanks,
Edit: "We" includes me; I should pay for more software too (not that I use any commercial software illegally; I only mean choosing paid products over free ones).
I'm all for supporting the continuation of services I enjoy and make use of, but this is a huge stab in the back.
Most people will probably be fine with Stream, but it's not what CentOS users signed up for.
Also Redhat just cut support on one of its projects. Their business model is build on their reputation and long term support. Not best long term move.
I personally hope the Linux world converges. There are too many needless distributions whose only major difference is branding and a few file locations and other minor quibbling choices. There is absolutely no value in having both a Debian and RedHat/CentOS in the world other than annoying people who want to distribute software for Linux by making them support two package managers.
NixOS seems to be taking off, Alpine is most used in containers but is great on bare metal, Arch Linux remains a pillar of the wider community, Void is still going strong. Debian is excellent, but it's not the world.
You may well say that Arch Linux and the like, compared to Debian-based distributions, basically leave you in the middle of nowhere with just a knife and a rope, but at least you know what you signed for. Relying on fancy shmancy automatic configuration systems is often a recipe for disaster, especially if you plan to stray a lot from the defaults, because it's guaranteed you won't have any idea of what's happening when everything has turned south.
For these and other reasons,I think that systems like BSDs are much, much more pleasant to use than Debian and Red Hat, but I understand why they might not be the right choice for everyone. Still, I can't but recommend everyone to give a shot at FreeBSD if your needs allow it.
Another system (altogether different since it's not Linux) that comes close to Debian in terms of solidness is FreeBSD. However, the experience of doing `dist-upgrade` for Debian from a release to another is miles better than `freebsd-upgrade` and the shenanigans of upgrading all your ports tree. I have to do that once every 2-3 years, and it takes an hour for Debian, whereas it takes half a day for FreeBSD (for example I just had to do that recently for a 10.x to 12.2 database running on FreeBSD system)
I would definitely NOT recommend Ubuntu. If one looks at Ubuntu and think it's like Debian - it's not. It doesn't come close at all in terms of robustness. An unrelated example: once you have Ubuntu up, there's tons of service that I don't know serves what purpose that's already running. For Debian, that does not happen, you have a minimal set running.
Also, you can keep running Debian for years before having to touch anything. This is one of the behaviour I'm looking for when I consider systems for work (what I mean by "solid"/"robust").
So rolling release systems like Arch serves a totally different purpose.
- Eliminate a competitor
- Absorb another company's team
Not all the reasons are as macabre as they sound; sometimes the bought company failed to monetize properly whatever they were doing, and their developers decided it was time to stop eating from bean cans. In those cases an acquisition can improve their diet slightly.
The folks who created CentOS didn't do it as a business. It was created because they wanted it to exist.
Once the acquired company numbers are loaded into the right spreadsheets that reflect reality in business ops, executives will see a bunch of cells in yellow and red color... which is not good.
The tech and talent is still being used, like the cargo ships in your example, it's just the competition that's been killed.
Watch Microsoft carefully.
But these companies may start migrating. It'll take 5-10 years for that to be completed though.
EDIT: Reading elsewhere in the thread, the answer seems to be “enterprise”, which I consider something to be actively avoided.
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.
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).
Their own announcement yesterday.
> It will be available and actively maintained.
CentOS8 will not be after 31 December 2021, that's what they announced yesterday. CentOS7 will be, until 30 June 2024, according to their current status page, but who's going to trust them after what they pulled yesterday? Overnight, they changed CentOS8's End-of-life from 31 May 2029 to 31 Dec 2021. Surely you understand that that made a few people a bit upset.
The only thing actively maintained in the future will be CentOS Stream, which is not CentOS classic as people understoond and used it. CentOS classic were RHEL-release clones without Redhat branding and support. CentOS Stream is RHEL-next Beta.
That's the gripe. We were using one of its clones.
There seems to be also a (planned?) free version of Red Had, if you want complete stability and only security updates.
Not "exactly the middle ground", so much as
Fedora ---------------------------------------->> CentOS Stream -->> RHEL
At any given time CentOS Stream is only a couple months ahead of RHEL, that is not remotely true for Fedora.
I should probably give a look at openSuse...
The only thing I had to build for myself was an Arch install ISO with ZFS included.
Freebsd isnt linux, but is great server OS.
Switch to the LTS kernel as well if you can, i.e. if your hardware does not need the HWE (Hardware Enablement) versions. The HWE kernels are mostly for newish laptops anyway and proper server hardware shouldn't need it.