Arch Linux is pretty faithful to shipping software exactly or as close as possible to as the upstream authors intended. It's on a rolling release which means you kind of get a firehose of nonstop major version updates though, whether you want them or not.

how does that work in practice？

upstream didn't build with all the dependencies at the same version as the latest in the arch repo. Nor are most upstream developers bumping all their dependency versions constantly

if you're a big player like ubuntu/debian you can go to the authors/upstream and ask them to fix the program to work with their dependency versions (in say.. an LTS release). most would be glad to bc it's just something upstream needs to do once every couple years and doesn't need maintenance. If even thats too much and yyou want esomething even more handsoff/timeless then you make an Appimage. It'll work for ever

With Arch youd need to constantly monitor the thing doesn't break？Are they just #yolo'ing dependency versions most of the time ？ (itd prolly work 99% of the time..)

In practice it works because GP is exaggerating. Arch does hold back library and/or program updates until they work together, or simply ships multiple major releases of libraries, and have a separate testing branch.

Right now e.g. there's openssl (still at version 3.0.x, because nobody supports 3.1.x yet) and openssl-1.1 (1.1.x-y) to handle the rather slow migration of upstreams to the new major release.

For server there's Flatcar Container Linux, which only provide just enough to run containers. Everything else is provided by the container packager.

There are operating systems - like FreeBSD - which have a very strong and clear distinction between the Operating System base and third-party software.

Fedora Silverblue https://silverblue.fedoraproject.org/

You're expected to run most apps as flatpaks.

I stopped distro-hopping a few years ago after landing on Silverblue a few years ago (back when it was still called Fedora Atomic Workstation). While it doesn't satisfy all use cases, I view it as a boring (in a good way) 80-percent solution that normally just works.

Silverblue doesn't get a lot of press but it makes a really solid desktop OS.

Fedora has always been quite bad at branding and making their distro appealing.

It's probably one of the most solid Linux distros at the moment and their website makes it seem.. boring.. No screenshots, features, mentions of whats available (like apps), that Fedora uses newer graphics/drivers kernels, that you can run Steam, that apps are sandboxed etc.

Stark contrast to something like https://vanillaos.org/

No distribution forces you to use package managers for everything. Even before flatpak/snap, distributing (especially commercial) software as just archives or executable installers was/is perfectly possible.

The caveat is, there's no common baseline for libraries. Graphics libraries, the libc itself, GUI widget libraries etc. will appear in different version combinations in different distributions, since they have different release schedules.

So if you want to go the Windows/MacOS route and ship a readily compiled program for Linux, you have to vendor in a loooot more libraries, and they have a higher risk of breaking due to incompatibilities (kernel interface for your graphics driver changed, configuration file syntax for your font renderer changed, etc.)

Flatpaks/snaps try to solve this (poorly) by vendoring the entire kitchen sink and then some, which just creates more bloat and a worse DLL hell than Windows could ever have dreamed of. So using it for everything isn't really feasible still.

> they have a higher risk of breaking due to incompatibilities (kernel interface for your graphics driver changed, configuration file syntax for your font renderer changed, etc.)

Simply don't vendor glibc and graphics drivers and you will be fine. Vendoring drivers doesn't make sense anyway as your application will be obsolete by the next HW cycle.

glibc breaks regularly, as does mesa occasionally, so it would realistically be required if you wanted win32-style 20+ years of backwards compatibility.

And there is a lot of more obscure examples: fontconfig e.g. at some point changed their config file format in a not backwards compatible way, and now some Steam games crash on startup because the developers earlier vendored it to get around its ABI breaking repeatedly.

And that sort of software doesn't really obsolete. Steam and GoG allow games to have a 10+ years long tail of slow but steady sales that don't really justify constant maintenance releases but still both let people enjoy good games (those don't really obsolete), and serve as advertisement for the developers' newer games.

> glibc breaks regularly, as does mesa occasionally

Neither of this is true.

> And there is a lot of more obscure examples: fontconfig e.g. at some point changed their config file format in a not backwards compatible way, and now some Steam games crash on startup because the developers earlier vendored it to get around its ABI breaking repeatedly.

Bundling fontconfig but not it's internal config is retarded, yes. Really, games have no business looking at system fonts at all.

Calling everyone except yourself too retarded to figure out compiling Linux software is not a productive discussion. And glibc/mesa related breakages are well documented, if you care.

Slackware, perhaps?

Honestly, if you just want the naked OS, you don't need a distro at all.

Or just don't use the package manager.

I'm curious what a Linux would look like that behaved more like windows or android in the sense that there isn't such a blurry line between the OS and its applications. For example, installing a C# or Go compiler on Linux is great with a package manager. But doing the same with a C or Python is different? This is basically the Unix "I'm not just an OS, I'm a platform for building and running C programs" heritage that isn't properly hidden I think.

We've reached the point where the C ecosystem has so given up on having a package manager that isn't Linux distributions that Microsoft added WSL and Docker(-compatible) Linux images are the most widespread distribution format. I don't think we can still figure out a way to decouple the two again, and without that, we can't really create a Linux environment that isn't a package manager with an email client.

And to a degree, the line is blurry with Windows as well, what with how deep MSVC/win32 is integrated into the system. .NET took decades to dis-entangle itself from Windows and become a proper standalone platform, and Microsoft's attempts at getting people to use UWP instead of win32 is ongoing and not very successful so far.

> in the sense that there isn't such a blurry line between the OS and its applications.

Interesting. It never occurred to me that there's a blurry line between the two. It seems to me that there's a very hard line between the two. I'm not sure I understand what you're saying here.

> For example, installing a C# or Go compiler on Linux is great with a package manager. But doing the same with a C or Python is different?

I'm confused by this question, so forgive me if this answer isn't really addressing it. A package manager is a convenience, nothing more. Using one means makes your life easier in a number of ways. But not using one isn't really that much more difficult. Package managers are 100% optional.