>I downloaded Baldur's Gate I Enhanced Edition which actually had a Linux port on GOG. I tried running it but it was missing libssl 1.0, of which Arch Linux now uses a newer version. Thankfully, an openssl 1.0 package was preserved in the Arch archive so that I can download and install it manually.
>My question is, why is this such an issue in Linux but not in Windows? Why can't an older program just use the installed newer libs? My fixing today was quite advanced for average noobs. How does Windows seamlessly manage to accommodate older programs relying on older libraries? Or should we just distribute Linux games in Flatpaks or Appimages just to be safe?

Linux distribution userspace isn't backward compatible. Flatpak tries to address this by bundling the required userspace (or implying it will), but it still doesn't truly make apps self-contained because it relies on a centralized distribution/updates network. If the repositories go offline, your workflow breaks so Flatpak isn't a complete dependency solution. AppImages are closer, but they still usually require bundling the relevant userspace libraries if you want real containment.

Traditional package managers have a similar issue as Flatpak, but arguably worse: they don't clearly separate the stability of the base OS from the stability of user applications. A rushed update that breaks core system components can affect everything on the system. Arch is the worst offender here because of its fast-moving updates. There's little isolation between OS and application. With AppImages and Flatpaks, the impact is at least isolated per application.

Windows doesn't suffer from this to the same extent because its core userspace libraries are stable and maintain backward compatibility. Applications typically only need to bundle specific third-party libraries like Qt or SDL2. On Linux, fragmentation makes it harder to coordinate a consistent, backward-compatible, stable “userspace API” across distributions.

The solution is for distribution maintainers/authors to actually care about creating and maintaining a stable userspace "API", which requires distribution maintainers to exercise real authority over the developers of key system libraries. Basically, Debian has to tell glibc programmers to stop fucking with the API/ABI stability, or ditch glibc entirely and similar independent libs to write their own stable userspace libs.

>>18739
Flatpak is fucking horrible as well as all of Freedesktop "inventions". All current Linux userspace is cancerous and horribly designed, and the devs are arrogant and impotent. It is especially prominent in GUI and desktop applications. No one is interested in delivering stable ABI and the only thing that has stable ABI is the Linux kernel itself, and only because Linus actually cares about not breaking the userspace. If not him freetards will start to break shit with each minor version.

>Windows doesn't suffer from this to the same extent because its core userspace libraries are stable and maintain backward compatibility.
MacOS too. It's the cathedral approach or "my way or the highway", some parts can really be horrible but still they are interested in bringing stable ABI. And both of these commercial OS have many batteries included so you just implement stuff their way and you will know that shit won't break. In Linux you have lots of options but all of them suck, and none of them have ABI stability.

>There's little isolation between OS and application.
That's inherent problem with all Unix inspired systems. All those flatpaks, dockers and other container bullshit are just hack jobs to 1970's design. UNIX didn't have capabilites and all that fancy stuff that we need now, so we reside to "sandboxing" (horrible term) and containers. And they're all horrible and have performance/storage space penalty. I like how isolation is implemented in Android, it's almost as good as it can be done with Linux kernel. Nix, snap, AppImage, flatpak they all suck.

>The solution is for distribution maintainers/authors to actually care about creating and maintaining a stable userspace "API", which requires distribution maintainers to exercise real authority over the developers of key system libraries. Basically, Debian has to tell glibc programmers to stop fucking with the API/ABI stability, or ditch glibc entirely and similar independent libs to write their own stable userspace libs.
ABI and API are different, don't mix those terms together.
If you want stability you use static linking, but many libraries does not support it for some bizzare reason, including mesa and GTK. Musl supports static linking, and they care about ABI stability. Replacing musl's allocator with mimalloc will bring it on par with glibc performance.
You are in no luck telling those retards to stop breaking shit, they just don't care. I am fed up with this bullshit too and that's why I'm basically writing my own graphical toolkit that doesn't suck, actually well designed and is pleasure to use and write stuff in. I refuse to touch all this bullshit that is GTK/Qt, it seems like they all are trying to cause as many painful headaches as possible with the worst performance. Just fucking stupid garbage, and there's no viable alternatives. Linux sucks, but everything else sucks way too much and is even more hostile to user. Software is always a problem.

Are BSDs better in this regard? I've never used them so I don't know.

>>18741
>Are BSDs better in this regard?
Yes. FreeBSD? Not sure. Maybe not.
OpenBSD? Yes absolutely.
The only time I had OpenBSD break on me was when I ran it on a rig with such broken RAM that memtest crashed within 2 minutes. Pic related