[ddevault]

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.

[helen___keller]

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

[ddevault]

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.

[invokestatic]

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.

[anonunivgrad]

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.

[ddevault]

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.

[anonunivgrad]

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.

[ddevault]

Don't make me repeat myself with respect to new features and stability.

[anonunivgrad]

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.

[kklimonda]

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).

[ddevault]

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.

[mhd]

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?

[ddevault]

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.