>For Debian it means version numbers stay the same as much as possible.

I would call that stagnant rather than stable. If a version of software remains the same with the same bugs/issues not getting resolved, that seems unstable to me. Yes, not crashing could also be considered stable as well.

In production you want what-dylan604-calls-stagnant instead of running the latest of the greatest. Yeah, I get it that you run Arch Linux on your laptop which has zero production relevance (nobody cares if you blow it up). But on a production system, where other people rely on, you don't want sudden surprises. Or, well, maybe you do, but those people who rely on it certainly don't.

If a known vuln is a stable version is exploited in the wild and left alone, why is that considered good?

That only happens in old Stable, the previous version of Stable, or machines without internet, or machines which don't receive manual maintenance (otherwise you'd need apt install unattended-upgrades).

In Stable (what you call Stagnant) vulns get backported. Only the code fixing the vulnerability gets updated, the rest is left untouched. Its how Apple deals with older iOS versions, and it keeps their happy users of older devices happy.

If I run some old piece of hardware/software, there are a few things I want: I want it to keep functioning the way I bought it, and I want it to remain secure and reliable. So what I want is security and reliability fixes ie. what Debian Stable (and e.g. Ubuntu LTS) receives.

> in Stable (what you call Stagnant) vulns get backported.

This isn’t always possible. And sometimes creates more problems than it solves or ends up not mitigating the issue completely.

In any case, backporting is a slower process. And back ports for non-stable are not done by the security team but volunteers.

I was on about security and reliability fixes. These are applied when you run Stable, via Security repository, enabled by default. I was not on about Backports repository.

> For Arch it means software does not crash because bugs get fixed in newer versions.

....what. That is not how OS stability works.

Also, Arch is nearly impossible to use in production environments.

Let's say there is a vulnerability discovered in the version of lighttpd you're running in your production environment. On Debian, you pull that package, do some testing, and you're done.

On Arch? It's a rolling release distro. They're continuously updating everything, including system libraries. You can easily end up in a situation where getting a security bugfix means you have to update nearly the entire OS thanks to it being built against updated core system libraries.

Like Gentoo it's one of those OSs that is cool for linux nerds and a headache for people who actually need to practice proper systems engineering.

As someone who used Gentoo for over a decade, including in production environments - I disagree.

Its a falsehood pushed by old 80's thinking. It sounds nice, in theory.

In practice, what you often get are bugfix patches blindly applied to older codebases, oftentimes by people (distro maintainers) who are not very familiar with the codebase. As long as the patch applies, and it passes various tests.

Remember, most OSS projects - including some critical ones - do not have large teams of devs able to maintain multiple codelines in tandem. Usually, the dev(s) just work on the latest, and pay only cursory attention to applying security bugfixes to older versions.

After all, how is an OSS dev for proj X meant to know (or even give a damn for) which distro arbitrarily decided which older version is somehow the SECURE and BLESSED one.

The dev in question probably moved on from that version months (and in regard to Debian, probably YEARS) ago.

So in theory, what you said sounds right. In practice, no.

I’ve also run Gentoo in production. But you have to know what you’re doing more than with, say, Debian or CentOS (RIP)

Gentoo is usable in production. Straps out extras. Only thing there is what you put there.

Seen it done and participated.

Production case study: ChromeOS is based on Gentoo.

I've also known a couple shops that run Gentoo as their distribution. Usually a central binary package host / build machine which makes it very easy to have a set of staging hosts. Just test package releases like normal before migrating them to prod.

Gentoo is perfect for proper systems engineering: Create a profile, and then manage what goes into it, in exactly the same way as you describe on Debian.

Actually, you don't have to do a full system upgrade, you can update a single package.

People have used Arch in prod. But personally I'll still use Debian to be on the safe side despite all of the issues that comes with.

Just because it often works doesn't mean it's a good idea. Updating a single package is officially unsupported [0] and it's burned me personally on a number of occasions.

[0] https://wiki.archlinux.org/title/System_maintenance#Partial_...

The context of the original comment is that you're updating that package on a test server and then testing it.

But sure, just yoloing a single package upgrade can break things, obviously.

I expect that's why they mentioned that it's officially unsupported behaviour. That doesn't seem too relevant to whose idea it was.

weel it's a bad idea unless you update just one package that doesn't have too many shared dependencies, things gets complicated with shared dependencies across their packages, so that's why it's better to run the full -Syu of course not automated but when you know what you are upgrading and possible manual interventions (if any) or caveats that you might have with the changes.

> Like Gentoo it's one of those OSs that is cool for linux nerds and a headache for people who actually need to practice proper systems engineering.

Fear not. As GKE is running on Container-Optimized OS which is based on Chromium OS which itself is based on Gentoo, you can safely practice proper systems engineering within the container environment :)