[danShumway]

I guess millage may vary, the only thing I can say is that there are multiple instances (particularly GoG which the article seems to praise) that literally never work on some of my systems.

The few times I've run into Flatpak crashes, they're architecture problems that would have been present in any version of the app, so I'd be doing that work regardless. They're harder to debug in Flatpak, but also heck debugging crashes every time I try to install a piece of software. I'll happily take the added complexity of needing to boot a shell into the sandbox if it means I get to debug 50% fewer problems (and in practice Flatpak tends to reduce my number of issues by way more than 50%).

The average user is never going to open a debugger, minimizing the number of crashes is more important for that user than making the crashes easier to debug.

[prmoustache]

But on the other hand, app crashes aren't something that common on linux. I mean at least on my distro. Whenever I have an app available as rpm, I choose the rpm over the flatpak version, for space saving purpose mostly.

None of my apps crashes except one. And that is a piece of shit of a proprietary app that is not packaged by the distro maintainers: Microsoft Edge.

[danShumway]

> But on the other hand, app crashes aren't something that common on linux. I mean at least on my distro

Strong disagree, my experience is that app crashes are extremely common on Linux if you step outside of official repositories; I say this as someone who literally only runs Linux and nothing else. I'm not necessarily saying Windows is better but... it's not like nothing ever breaks. It's impressive how well developers are able to hold it all together, but my experience is that Linux systems are fragile the moment anyone stops actively managing the dependencies and putting in the work to compile everything to match.

> that is not packaged by the distro maintainers

It is not feasible or scalable for Linux for every single app (even every Open Source app) to be distributed and managed by the distro maintainers. And this is what I'm getting at with dependency isolation -- the vast majority of crashes and bugs I see on Linux (and I mean by a massive margin) are all due to dependency mismatches and shared dependencies. A lot of Linux software is generally stable if the system looks like what it's expecting the system to look like. But if you're not going through an official repository where a bunch of volunteers are putting in the work to make it consistent, then it very often doesn't look like what developers expect.

This is why people run games through Wine instead of using the Linux versions -- it's not because it's impossible to build good native versions, it's because if they don't use the Linux version they can use Bottles. That's the biggest reason; it's about the dependency isolation.

[prmoustache]

The major distros and BSD have shown, that yes, that scales fairly well in fact given the number of apps provided through distros official repos.

Most apps that I have been getting from third party repo were not included because most majors distros are us projects that can't ship patent encumbered libs/apps, not because distros mainteners couldn't package them.

> This is why people run games through Wine instead of using the Linux versions

No, the main reason is that the linux versions do not exist for the most part because devs don't want to bother supporting a non uniform software platform that represent a tiny fraction of their market.

[danShumway]

> The major distros and BSD have shown, that yes, that scales fairly well in fact given the number of apps provided through distros official repos.

I mean... citation needed :) I run Arch and I am not dismissing at all the frankly incredible work that the Arch maintainers do bundling software and making it available. It is a miracle that it works as well as it does, to the point where my Arch systems are often more stable than non-rolling-release distros I occasionally run. Fantastic work by the maintainers.

But it's not a solved problem and I can only imagine how much effort and work is getting burned to keep it running as smoothly as it does. Step outside of the official Arch repos into AUR or (heaven forbid) into completely separate ecosystems and all of those problems come back. And I don't want to ignore the software outside of the repos, I didn't start using Linux so that I would be beholden to some kind of "official" distro app store.

There are tons of Open Source applications with no legal barriers in place that are not getting packaged in official repositories for no other reason than that they're niche and there is a lot of software to package and not enough people to do package it all.

And of course any non-OS games are also going to run into these problems. That's a problem that distro maintainers can't solve, it doesn't matter how much work they put into it, they can't repackage source-available or closed source software. "People shouldn't ship that" -> but they do :) So ideally we'd be able to handle that without descending into dependency hell.

> No, the main reason is that the linux versions do not exist for the most part

I'm not talking about games where the Linux versions don't exist, I'm explaining why I'm currently running the Windows version of Inscryption on my Deck even though it has a native Linux port. Do I want to be doing that? No, of course not. But the Linux version doesn't boot, most likely because there's some dependency chain missing or an environment variable is wrong, or... I don't know, I don't want to crawl through forums and debug that myself, I want to play the game.

And I'm not alone in that, it is common advice on Linux to use Proton instead of Linux native versions. And that stinks, it's bad for the ecosystem and it's bad for users and it's bad for games. But the Linux versions have so many more problems because they make assumptions about the underlying system that turn out not to be true. Of course Windows builds also have those problems, but the difference is that they run in a containerized environment that gives them the system they expect.

[JohnFen]

> This is why people run games through Wine instead of using the Linux versions

They do? When I have a choice between the two, I'll take the Linux version every time.

[danShumway]

I would love to as well, if the Linux versions would boot up and run on Steam Deck. Even when I was gaming on my desktop, which is pure Arch, I remember regularly needing to edit Linux games or recompile dependencies to get them to work.

Flibitijibibo has some good commentary on when to dynamically/statically link libraries, leaning towards statically linking dependencies when possible to avoid relying on the OS too much. Coincidentally, Flibitijibibo's Linux ports are some of the few where I can just download them and be confident that they're likely going to work out of the box with zero troubleshooting.

[JohnFen]

Ah, OK, so this is an issue with the Steam deck and Arch? I thought that it was a general comment about Linux. My mistake.

[danShumway]

> and Arch

It is a general comment about Linux. Arch Linux is a major distro, if people using Arch can't run Linux software using existing packaging systems, the packaging systems are broken.

If the natural result of existing packaging systems is that software only works on distros like Ubuntu and Fedora, then that is very much a general Linux problem.