Centos.rip(centos.rip)
centos.rip
Centos.rip
https://centos.rip/
143 comments
What is the context behind this?
Oh, wow. I'm running CentOS 8 on my home server. Anyone have any recomendations for a good, stable, home server OS?
Depending what exactly you want, CentOS is still a great choice, especially if you are also using the machine for more than set serving jobs. My understanding is, that CentOS will be exactly in the middle ground between Fedora and Red Hat. So it will be ahead of Red Hat a bit, which is a good thing if you want more current software versions. But not quite as cutting edge as Fedora. Personally, I am fully on Fedora for my development machine as I want current versions of software. I didn't have stability problems with it.
There seems to be also a (planned?) free version of Red Had, if you want complete stability and only security updates.
There seems to be also a (planned?) free version of Red Had, if you want complete stability and only security updates.
>My understanding is, that CentOS will be exactly in the middle ground between Fedora and Red Hat.
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.
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.
Thanks, that means even more it still is a good choice for people who are more oriented towards the stable RHEL.
Assuming that CentOS stays dead, I'd probably recommend Ubuntu LTS.
I should probably give a look at openSuse...
I should probably give a look at openSuse...
Ubuntu server is pretty good.
For any regular server I’d recommend Debian. However, on my home server, I run Arch. It’s a pain with the upgrades, but I have access to all the latest and greatest software to tinker with. Which I feel is exactly what a home server is for. :-)
The only thing I had to build for myself was an Arch install ISO with ZFS included.
The only thing I had to build for myself was an Arch install ISO with ZFS included.
arch or freebsd. Ubuntu lts/debian depends on ur packages.
Freebsd isnt linux, but is great server OS.
Freebsd isnt linux, but is great server OS.
I second this. FreeBSD is rock solid and extremely reliable (I have systems that are running on very old hardware and little memory, and still work fine). Arch can also pretty stable, if you actually know what you're doing and you're not doing anything serious with your server.
any Ubuntu LTS version!
Debian
[deleted]
CentOS is dead, basically. It was announced yesterday.
While this is super fun, can I get more informative link? I don't follow Red Hat and for someone reason google is not helping me
Edit: Comment below beat me to it, nvm
Edit: Comment below beat me to it, nvm
I think we all knew this was coming when IBM acquired RedHat.
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.
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.
One could pull the same trick that CentOS pulled: check-out all the sources, replace all the logos and trademarks and rebuild.
I honestly hope this is what's going to happen.
I honestly hope this is what's going to happen.
The original CentOS founder already announced his intention to do exactly that. I believe it's going to land here: https://github.com/hpcng/rocky. The thread about the CentOS Stream announcement yesterday had references to other efforts too.
That man is a treasure.
https://lwn.net/Articles/786422/
That didn't age well. Maybe we'll see a Scientific Linux comeback.
That didn't age well. Maybe we'll see a Scientific Linux comeback.
I'm not sure that CERN would like to work on it full steam but, it'd be great though.
Theoretically, CentOS was the RHEL source release.
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?
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?
That was a good laugh, thank you. Now it's time to go back at freaking out.
Freaking out over what? CentOS stopped being a production OS as soon as "I've Been Moved" ingested it...were you just not paying attention? ;)
There is a difference between thinking that something might happen, and seeing it actually come to pass.
I would advise anyone who's using this as an opportunity to move on to greener pastures in terms of distributions to consider Alpine Linux: https://alpinelinux.org
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.
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.
While I'm interested in Alpine and will take a look at it, I think it's in a different class than CentOS. A look at the release schedule[0] suggests that major versions are supported for 2 years. In contrast, major releases of CentOS historically were supported for a stunning 10 years (until yesterdays' announcement, which moved the support window for CentOS 8 from 2029 to 2021). I've worked with companies that had been running legacy CentOS 6 boxes for over half a decade, and from my perspective the longevity was incredibly valuable for that kind of business.
[0] https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
[0] https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
The upgrade pace of Alpine is quite reasonable, especially considering that breakage is extremely rare. Expecting to set up a box and not touch it for 10 years is... not reasonable. If that's what you wanted from CentOS, then you have a broken organization.
It wasn’t just 10 years of support, it’s 10 years of ABI stability as well. If that wasn’t a big selling point, I don’t think Red Hat or Microsoft would be as successful as they have been in enterprise.
Two totally different markets. RHEL (and its free clone, CentOS, rip) are for regulated industries or anyone who values extreme stability over any newness. You can turn updates on and feel as safe as you can be against known exploits while at the same time feeling as confident as you can that your stuff won’t break. Once or twice a decade, you port to a new version and then go back to not thinking about it too much.
I feel confident about this with Alpine Linux. It doesn't have this sense of newness and bleeding edge. It is extremely stable and I have run upgrades on it for years without even a single issue. They release twice annually and the upgrade process is almost trivial. Keeping up with it is easy and a good practice for any organization.
I’m not sure you’re appreciating the kind of operation that RHEL is and why these kinds of businesses use it. They don’t want new features. They want a platform that works, that is approved by government regulators, that doesn’t need engineers to come fix update-caused problems regularly, which will happen with any Linux system that receives major package updates. You’re thinking like a software engineer who will be there to handle these issues. They’re thinking like a hospital that can’t risk downtime and is not a software company, even if they hire a few engineers here and there.
Don't make me repeat myself with respect to new features and stability.
You dismiss, elsewhere in this thread, the need to be on the same OS and package versions for years. That’s what people want sometimes. They don’t want to tinker with the system. They don’t need any new functionality, not this year, not next year, not in five years. They built a service, it works, and they can deploy to RHEL and (mostly) forget about it for a long time. As the end of the LTS period approaches, they can do the work to migrate and then forget about it again for a decade. Note that “they” is not just the organization running the system, but also the vendors of bespoke or otherwise niche software used by the organization. Any problem might mean getting billed big bucks per hour of engineering work.
Alpine is still linked against musl and not glibc, right? That is a rather large departure, and potentially more problematic than small package repository (usually the smaller repository, the easier it is to package your own stuff from scratch - I assume it beats rpm and deb at that).
Yes, but what of it? musl is POSIX compatible and almost all software works fine with it. It's simpler, easier to debug, and more reliable, and that easily outweighs the 30 seconds I have to spend patching the odd package with glibcisms.
I mostly hear Alpine in the context of either embedded systems or tiny docker images. I'm not even that worried about the server, but one of the neat things about CentOS was that I could run the same or a related (Fedora) system on my dev machine, too. So I'd be interested in reading more about your experience with it as a workstation system. Do you use this as a main development machine or "just" for testing server stuff?
I use it as my main development workstation as well. It should be stated that I use a fairly minimal workstation setup, however - I use sway, a web browser, and a terminal emulator, and that's it for graphical software on the typical day.
This should really be called RIP RedHat tbh. They've just shot themselves in both feet.
I disagree, Redhat is not going anywhere anytime soon. FOSS is a funny thing because people seem to get more upset about things they were handed for free than things they pay for. Why should your entire *aaS stack be composed of free software of which you make money off of? How much money did anyone reading this donate to CentOS when they were separate from Redhat? Redhat bought the CentOS team because their own community refused to support their work. Think about that...you get what you give. People are really just upset they will no longer get free Redhat (which is what CentOS is).
People are upset when something that was free becomes paid, or something good gets worse. People aren't upset "about things they were handed for free", but the removal of things they were handed for free.
Why the hell do huge companies spend tons to acquire things and then kill them? This seems to happen more in computing than other industries. You don't see shipping companies buying completely functional container ships so they can park them out in the middle of the ocean and dynamite a hole in the hull and watch them go glug glug glug for the lulz.
Many reasons:
- 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.
- 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.
I doubt Red Hat spent any money at all on acquiring CentOS. The OS was literally just Red Hat Enterprise Linux with the logos removed and without the subscription fee. RH probably just promised to help maintain it and provide infrastructure.
The folks who created CentOS didn't do it as a business. It was created because they wanted it to exist.
The folks who created CentOS didn't do it as a business. It was created because they wanted it to exist.
happened to me in publishing. we had built our own online portal to our legal book products, couple million a year in revenue and growing, bought by Reuters, everything shut down, didn’t even bother to look into keeping any of our talent around either. it was weird! severance package was great though.
The 'remove-competitor-while-still-cheap-to-do-so' rationale then, probably.
I suspect there are far too many spreadsheet versions flying around in an acquisition process.
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.
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.
Totally just blurting out from the top of my head, but I'm guessing it's more because digital things are intangible.
The tech and talent is still being used, like the cargo ships in your example, it's just the competition that's been killed.
The tech and talent is still being used, like the cargo ships in your example, it's just the competition that's been killed.
I would think for some it's the acquihire, for some it's a way of preventing competition...
Yep they are bastards.
Watch Microsoft carefully.
Watch Microsoft carefully.
What makes you think that CentOS was killed? It will be available and actively maintained.
> What makes you think that CentOS was killed?
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.
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.
Just because CentOS Stream has "CentOS" in its name does not mean it's the same thing - CentOS, as is known currently, will effectively stop existing once CentOS7 is no longer supported (not to mention CentOS8 will not even be supported for previously announced period).
Yes, CentOS as a precise RH clone will be history, but there is still RH. CentOS will still be close to the next RH release and sufficiently behind Fedora to be stable by itself. So a good choice for many, who want a bit more current software than Red Hat but want to be more conservative than to go with Fedora. For many users an actual improvement. For those who want Red Hat, they should use Red Hat or one of its clones.
> For those who want Red Hat, they should use Red Hat or one of its clones.
That's the gripe. We were using one of its clones.
That's the gripe. We were using one of its clones.
Maybe, probably not short-term though; they still have (I guess?) tens of thousands or more active licenses, which are committed to using it because replacing it will be a lengthy and expensive project.
But these companies may start migrating. It'll take 5-10 years for that to be completed though.
But these companies may start migrating. It'll take 5-10 years for that to be completed though.
My existential dread about this is worsened when I read suggestions that the best possible alternative is Oracle Linux...
Oracle linux is not an alternative to anything. Anything with the name Oracle is no longer alternative to anything either.
No bullshit, but my org went to Oracle Linux and we haven't had any issues whatsoever.
Not saying to switch to it, but it isn't like the server implodes if you disconnect a credit card swiper from it.
Not saying to switch to it, but it isn't like the server implodes if you disconnect a credit card swiper from it.
Technical problems aren't the primary reason people recommend against using Oracle, it's the extortion that happens further down the road once they've got you locked in. And in the case of Oracle Linux, that seems to be almost a certainty at some point.
Fair point, they don't have the best track record :)
Same scenario as getting ingested by IBM after all
Ubuntu has been fine for us. We just jump from one LTS to the next.
How long do you normally wait after an LTS release to start shifting?
FreeBSD is looking pretty sexy suddenly.
I wonder if Amazon might do something like what they did with their Corretto java distribution.
The writing's been on the wall ever since IBM acquired RedHat, not to mention the fact that the Linux world is otherwise converging on Debian-derived distros.
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.
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.
Eh, while I agree that RHEL feels pretty redundant in a world where Debian exists, there are some distros that absolutely bring something new that you couldn't do as a Debian downstream (in particular, NixOS).
> the Linux world is otherwise converging on Debian-derived distros
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.
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.
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.
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.
“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”.
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”.
There are several third-party repos to install up to date software on CentOS.
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.
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.
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).
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).
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.
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.
It runs about 80% of the internet, as you know it. Not much desktop usage, but almost all servers.
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
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
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
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.
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.
At least that is how it was seen.
>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.
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.
> 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.
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.
> 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.
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.
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?
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?
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.
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.
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.
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.
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.
Not that I recommend CentOS, I prefer Ubuntu, but I think that explains the main appeal, at least among web hosting services.
>> 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.
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 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.
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.
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.
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.
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.
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.
> 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.
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.
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).
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).
I hope someone resurrects Whitebox Linux. I just liked the name and that it communicates litterally same thing as the other guy but cheaper since you aren’t paying for the brand.
Might be able to pun off of “President’s Choice” = “PC” = “Personal Computer” somehow as well.
Might be able to pun off of “President’s Choice” = “PC” = “Personal Computer” somehow as well.
I hope IBM/Redhat see how negatively this decision has been received and announce a reversal in the coming few days.
1. Denial
2. Anger
3. Bargaining
4. Depression
5. Acceptance
I think I am 4, it's too hard for me to manage my own distro and update my packages when this will be EOL, so I have to wait and see, is there any alternative to CentOS aside of Debian and Ubuntu ?
Thanks,
Thanks,
You can check out SUSE. Depending what you do, maybe go with FreeBSD instead linux.
Why not Debian? I've always used either Debian or Gentoo, depending on what I'm doing. I know Gentoo isn't everyones cup of tea, but Debian seems similar enough to Centos in my eyes.
EDIT: Reading elsewhere in the thread, the answer seems to be “enterprise”, which I consider something to be actively avoided.
EDIT: Reading elsewhere in the thread, the answer seems to be “enterprise”, which I consider something to be actively avoided.
I appreciate the suggestions for alternative Linux server distros, and understand people asking about such, but CentOS wasn't just another decent Linux server distro. It's status as a direct rebuild of RHEL, crucially including robust binary compatibility, gave it a unique role. Ubuntu LTS, Alpine, Debian, etc are all fine distros but there's a particular role for a very precise completely open and free RHEL clone.
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.
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.
Inb4 rocky linux[0]
0: https://news.itsfoss.com/rocky-linux-announcement/
0: https://news.itsfoss.com/rocky-linux-announcement/
I've had to argue a lot of time at work on the merit of running a Debian system.
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.
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.
I personally hate Debian because of APT and the fact that it tends to do way too many things behind your back, things that sometimes backfire horrendously as soon as you stray too much from the path Debian dug (Ubuntu is the best example of how APT can self implode as soon as you start adding weird repositories and the scripts that keep Debian afloat start breaking). I've had to recover way too many Ubuntu installs to tolerate using APT any longer (in its defense, I understand it was designed by Debian, for Debian, and often Ubuntu abuses and misunderstands it), and while YUM/DNF aren't that much better, they're miles ahead APT in reliability and solidity, especially since RPM is arguably more reliable than DPKG, IMHO.
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.
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.
I've ran a lot of systems for the past 15+ years and I can honestly say that for servers, Debian is the most solid I've been able to run. (Debian, not Ubuntu). Especially because of its release cycle and no-nonsense vision. I'm not sure which Debian release you've had experience with, but ever since Debian Stretch it's been very solid.
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.
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.
I have not experienced any of these issues. Do you have an example of a reproducible bug in apt involving third-party repositories? And how is RPM more reliable than DPKG? I have not seen either of them exhibit what I would call reliability issues (i.e. crashes)
I have not seen crashes, but I often saw corrupted DPKG databases. This is very rare if you stick to upstream repositories, but it gets more serious when you start mixing third-party repositories in (i.e. I saw people replacing GCC with newer versions from outside repositories, and due to the sheer amount of stuff depending from it, doing a dist-upgrade required purging an immense amount of packages). I must admit it's not usually an issue on servers, though.
This doesn't seem related to apt vs yum, rpm etc. but more to replacing essential dependencies by third-party versions. What happens if one uses the same kind of hacks on CentOS? Does it handle these better?
In my experience, RPM is a bit more resilient to this kind of stuff, because I've never had such a problem on SUSE or Fedora. CentOS is different, because tecnically you're not supposed to upgrade it to a newer version, so it has less chances to experience these issues.
The one big issue with Debian is installing a package results in the service starting immediately. On CentOS and other distros this is not the case and the user has to start the service after the installation. I prefer the latter behavior as not everything I install is going to be a 24/7 service. I'd prefer not to mask some service because stopping and disabling leads to the service randomly starting after a package upgrade.
The worse aspect in my mind is that when you install a new service, it will start with the default configuration before you have a chance to configure it.
Debian is really unique in that does not totally rely on a single corporation's largess like Fedora (Red Hat), CentOS (Red Hat), or OpenSUSE (SUSE). Being a worldwide, community-run project, it has multiple stakeholders and no single point of failure.
I was under the impression all these years that CentOS was not under RedHat supervision. Was I wrong, or did something change silently?
They were acquired by Red Hat in 2014 or so.
This strikes me as an infantile response to a sensible business move. We need to grow up, realize that the free lunch is over, and pay for what we value. And developers, including large companies, need to stop coddling us by offering us their best work for free.
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).
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).
The biggest issue here is that they've went back on supporting till 2029 and given folks till this time next year to have a replacement solution in place.
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.
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.
"free lunch" is just untrue. Opensource and GPL does not work this way.
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.
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.
What about companies like mine, that run their own servers, to do stuff that is a legal requirement, but don't have money to pay RHEL?
Being out of touch from the Linux distro world, this is rather sudden.
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.
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.
Soon as in over week ago (November 30th), just FYI.
The text is copied from when the Antergos distro told their users they would still get updates.
https://web.archive.org/web/20190808223051/https://antergos....
https://web.archive.org/web/20190808223051/https://antergos....
I'm still keeping my fingers crossed for IBM to "nudge" (force?) RedHat to roll out a new distro named Red Hat Universal Blue Linux or RHUB Linux...Just so that i can use loads of awful Dad jokes related to linux and Rube Goldberg devices. (Disclaimer: I love me some linux tons, but love me some Dad jokes even more.)
Changing EoL to 2021 is absolutely unacceptable!
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.
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'd love to know what the Red Hat employee are saying internally i am sure it's a big shithole right know,
We are creating the next RHEL based Enterprise Linux - same as CentOS used to be. Targeted first release is January 31, 2021.
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://monkos.org
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://monkos.org