It’s not insecure.

There’s the inconvenient truth: it’s easiest to secure an OS, say for enterprise life, the farther you are from the bleeding edge: churn is lower, the targets move dramatically slower, and testing an install set (as a set) is markedly easier. It’s why enterprise linux distros are ALL version-branched at a given version, and only port security fixes in: if you need to change a package and start the extensive testing, keep it to security fixes and similarly drastic reasons.

So most ent-like distros aren’t insecure; not at all. Security is the goal and the reason they endure wave after yearly wave of people not understanding why they don’t surf that bleeding edge. They don’t get it.

Enterprise distros also offer a really stable platform to release stuff on; that was a mantra the sales team used for Open that we’d stress in ISV Engineering too, as we dealt with companies and people porting onto Open. But ISVs had their own inexperienced types for whom the idea of a stable platform that guaranteed a long life to their product with guaranteed compatibility wasn’t as valuable as “ooh shiny”. But that was the indirect benefit: market your Sybase or ProgressDb on the brand new release and once it’s working you don’t have to care about library rug-pulls or similar surprises for a fucking decade (or half that as you start the next wave onto the next distro release). And 5 years is a much better cadence than ‘every week’.

So while it’s easy to secure and support something that never moves, that’s also not feasible: you have to march forward. So ent distros stay a little back from the bleeding edge, market ‘RHL7’ or ‘OL31’ as a stable LTS distro, and try to get people onto it so they have a better time of it.

Just, now devs have to cope with libs and tools that are, on average, 5 years stale. For some, that’s not acceptable. And that’s always the challenge.

Yeah I agree I don’t want bleeding edge hence why I won’t be using anything Arch-based (despite the fact that Arch-based systems are the ones I’m most familiar with, I’m typing this on an Artix system rn). But there is definitely a middle ground between bleeding edge and outdated, and I imagine a server should want to be somewhere between the middle and outdated, depending on how they balance stability and security.

I’m also not categorically opposed to using Debian. Ubuntu was my first Linux distro so I’m at least more familiar with Debian-based distros than most other popular server distros. I was just thinking probably not Debian because of how old its packages are and that I’m fairly concerned with security.

@bjoern_tantau @communism That ‘support for years and years’ means security support. So even if the nominal versions stay stable, security fixes are backported. Security scans that only check versions usually give false positives: they think fixes in newer versions are not present when in fact they are.

Many others distros do exactly the same. I only chose Debian because the amount of software already packaged in the distro itself is bigger than any other, barring 3rd party repos.

Love me some dietpi! Was pleasantly surprised of how smart and easy it was to use 🙌

@GustavoM @communism I think Alpine is better. It’s also very minimalist, but without going too bespoke so it’s still easy to google a solution.

Snaps are meant for server applications but yeah

Do you have a plan on how you’d do version controlling on Arch? It’d be annoying to upgrade, something breaks, and you can’t easily roll back.

I wouldn’t personally use Arch on a server. The rolling release could cause a lot of problems, especially since you lack the ability to seamlessly integrate older versions of packages like with gentoo masking.