Some of us are forced by edict/policy to RHEL-only. I'm doing work for a client whose IT dept requires it, because it's all they 'support'.
Their 'support' largely consists of
a) giving ridiculously small and unchangeable /home and /usr partition sizes,
b) randomly logging in at unannounced times to add more logging and monitoring tools in to /home and /usr (then rebooting, also unannounced),
c) sending sporadic emails telling us to clean up our system because we are dangerously low on drive space in /home and /usr.
Got a message the other day stating that they power down our machine in 2 days unless we freed up drive space because 'low drive space can impact system availability and security'. Powering it down also impacts availability, but that point seemed lost on them.
EDIT: Realizing now that ... our RHEL 7 will expire at end of month. We've had 0 communication from them about this. Annoyed because when I'd requested this machine back in 2021, asking for RHEL 8, I was told "we don't officially support that", and now we're going in to EOL territory because of RHEL 7. I'm expecting an "hair on fire" email in early July indicating our machines will be shut down shortly without an immediate upgrade, that we will be forced to do ourselves (because upgrades fall outside 'support').
Only 5% of my work - I don't deal with them but a few times per year. I'm constantly confounded by how difficult they make relatively simple things, compared to other clients/projects I work with. But... this is dealing with state government. There are definitely sharp people that work in state govt - not dumping on all of them. But... this dept's incentives don't typically align with most others, and there's generally little that can be done about it. My eyes water when I see what my project is required to pay for this, relative to the 'support' we get.
Sort of does. Can't imagine it's a typical experience and makes me wonder what's so unusual in this case. There are always bad experiences with support but usually systematic tire fires indicate some other issues.
if you are going to stay, don't update to 8. Update to 9. Any 'significant' fixes you need fixed for 8 wont be possible in this stage of life and only 9 fits that requirement.
at this point, it will probably have to be a rebuild of a few machines - i'm not sure we can jump from 7->9 in an automated way (is it possible?) and i'm unsure how we'd recover if there was a hiccup in that process.
possible good news is that we'd been forced to use more machines a few years ago due to some IT policy about databases not being colocated on the same physical instance as the application(s) accessing it, which forced multiple servers when fewer were needed. I was told that's not a hard requirement any longer, which may allow us to consolidate some pieces during a rebuild.
I"m not sure how mature the LEAPP program is, but you could always simplify the process by running your apps in an el7 container for the initial migration while you ensure the rest of userspace catches up/adequately tested.
Debian was always there, they deserve what they get.
I'm saying this as someone who fought tooth and nail to migrate to Debian instead of Scientific in 2010 because you can't ever trust a for profit company.
But that was too hard, and what would a grad student know about the real world anyway, so here we are.
Sorry but that's an asinine reply. The people looking for the support are busy doing something and looking to pay a company for the support. If they had the time to volunteer for support, they wouldn't be looking for support themselves. You're the one touting Debian out of nowhere, you can't ask the people you're talking to, to volunteer to make your point better.
Debian handles all of these transitions by itself during upgrade process, and shows you a nice readme before starting all of them.
For example, Debian has finished two big transitions recently. Merging /usr and 64 bit time support. Both are done on testing, and even on testing nothing has broken.
Another big change (which also made HN front page via LWN) was /tmp behavior change. It's handled differently. If your system is already installed, it doesn't change the behavior, but new systems will behave differently.
All of these changes are again communicated via "NEWS" mechanism. If Debian changes a config file, it's replaced. If you modified this file, apt will ask what you prefer, and you can diff the file in place.
In the past, many similar changes are made, and all were transparent. If you're not using any external repositories which change tons of system packages with their own versions, nothing changes during upgrades for you.
While there's an extensive release note provided with every release like [0], the upgrades are pretty straightforward.
As a result, having a few or many Debian systems which are older than a decade is a norm, not an exception.
There are a lot of HPC sysadmins that are very busy lately. A lot of third party software started dropping CentOS 7 support this year, and they never upgraded their clusters to 8/9.
The situation is pretty backwards for us, ironically.
Upgrading the OS is easy. Initial work is a couple of days, rest of the deployment is an hour or so, but the software we need to run doesn't support CentOS 7+. Containerization might help or not, but most software is distributed as RPM packages and some of them are written with things like Python2.7.
As the IBM constructorships’ beams cut up this ecosystem you kind of see why the head Vogon has no sympathy because the plans have not been “in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’”
Personally, I found RPM distros to be quite stable but have largely moved over to Ubuntu LTS for servers (technically Debian also has a LTS release, but it’s not as mainstream) and Linux Mint locally (largely Ubuntu without focus on snaps and the Cinnamon desktop is pleasant), it’s been working pretty well so far.
Then again, I run most software in Docker containers, so thankfully underlying OS changes usually aren’t too bad for me to deal with.
>Some people have actually had good luck with Oracle Linux but that’s very much an individual (or corporate) choice to consider.
Jup for enterprise, OracleLinux it is. I don't like Oracle as any normal person would, but they never did some shady stuff with their Linux, it even works perfectly on a Raspberry PI.
Debian 12, after a period of using Ubuntu that ended when Canonical decided to put advertising in the friggin cli. Oh, and pushing snap, but the advertising is what really nailed it for me. ;)
I realy like debian but is there any equivalent to yum ? It did some really nice advanced stuff I don't think you can replicate with apt. The shell mode avoided me some really big trouble several times (erlang updates often made me uninstall anything using it on update).
Current job doesn't give me many chances to use linux rn so I'm a bit out of touch. Recently took a look at rocky and it felt like a centos. also tried ubuntu but I recall I had to remove some ads package yeah.
Funnily enough, years ago, I migrated from Debian as my daily driver to (at the time) "Fedora Core" on my desktop.
My first question was "what's the replacement for aptitude", and people pointed me to "yum shell". It was not as good, but I got used to it, and went with it.
If you run "aptitude" on debian, without any argument, you end up in a TUI, you can use it to install or remove packages from your system, and then see the "preview" of the change, and apply/cancel the change. The same way people use "yum shell".
I'm used to new "dnf shell", so I don't miss aptitude anymore, but I think aptitude is what you're looking for.
Interesting, in my head aptitude was an ubuntu thing so I never tried in debian. Thanks for the tip.
I don't have anything against apt, it's just specific edge cases when it really saved me massive headaches by being able to remove and add during same change without having to remove all apps depending on it.
+1 Alma is great. I've interacted less with Rocky but both projects have great teams behind them, and both have a clear mission and promise to their users.
Which is probably the right answer (or Rocky) if you're set on having CentOS like it was before the team was acquired by Red Hat (which frankly didn't change the situation as much as some folks assume it did).
Switched to Debian since one of services we use is Debian supported only so it was a logical choice. Some clients are still requesting Oracle or RHEL but we are pushing towards Debian. It was a nice ride with CentOS.
There are a ton of perfectly good Linux distros out there--many with some type of support available. The thing with CentOS was that, especially latterly after the CentOS team was acquired by Red Hat, many saw CentOS--as a downstream rebuild from RHEL sources, albeit with a different build system--as a semi-supported version of RHEL for free.
For people who don't want CentOS Stream, i.e. basically the nightly RHEL builds, the lack of having a versioned CentOS mirroring RHEL versions coming out of Red Hat (for about the last 10 years) puts them in somewhat uncharted waters even if they could pick one of the RHEL alternatives and "probably" be fine.
Their 'support' largely consists of
a) giving ridiculously small and unchangeable /home and /usr partition sizes,
b) randomly logging in at unannounced times to add more logging and monitoring tools in to /home and /usr (then rebooting, also unannounced),
c) sending sporadic emails telling us to clean up our system because we are dangerously low on drive space in /home and /usr.
Got a message the other day stating that they power down our machine in 2 days unless we freed up drive space because 'low drive space can impact system availability and security'. Powering it down also impacts availability, but that point seemed lost on them.
EDIT: Realizing now that ... our RHEL 7 will expire at end of month. We've had 0 communication from them about this. Annoyed because when I'd requested this machine back in 2021, asking for RHEL 8, I was told "we don't officially support that", and now we're going in to EOL territory because of RHEL 7. I'm expecting an "hair on fire" email in early July indicating our machines will be shut down shortly without an immediate upgrade, that we will be forced to do ourselves (because upgrades fall outside 'support').