It’s interesting to compare these package managers to service containerization, I.e docker, podman etc. There it works pretty well, but many of these benefits don’t seem to be present in desktop use.
These “package managers” (in quotes, as I find them a bad substitute for an actual package manager, but that’s a sidenote) effectively use the same underlying technology, cgroups etc. as docker containers etc.
The thing is, what makes sense on the server, doesn’t necessarily make sense on the desktop. It makes sense to prioritize developer comfort over disk space use in server context, for example; it makes way less sense to do so in the desktop context.
Yeah, for example, it’s nice not having to manually fiddle with PHP dependencies etc. when it comes to web servers, but desktop apps are rarely like this. They just have their executable, and seldom require any serious configuration.
Desktop apps can have a crap-ton of dependencies and a finicky requirements around specific versions. That’s one of the reasons why “flatsnappimage” stuff got created in the first place — to go around the limitations of Linux distribution package manager dependency management model.
And we do need a better way to deal with this. But the “flatsnappimage” approach is not that, IMVHO, as it’s clearly driven by other considerations (like the “we want to have an app store we control” thing mentioned in the article).
But the thing is, in a server context you have developers, sysadmins, and that’s kinda it. They can make informed decisions on how to manage stuff, and making it easier for the developers to deploy stuff is a reasonably good strategy.
On the desktop you have app developers, OS maintainers, and users. Users often will not be able to make anywhere near as informed decisions as developers and maintainers. Focusing on developer comfort basically leads to ignoring users’ needs (like: “a calculator app should not need a 2.8GiB of stuff just for itself”).
It’s interesting to compare these package managers to service containerization, I.e docker, podman etc. There it works pretty well, but many of these benefits don’t seem to be present in desktop use.
These “package managers” (in quotes, as I find them a bad substitute for an actual package manager, but that’s a sidenote) effectively use the same underlying technology,
cgroupsetc. asdockercontainers etc.The thing is, what makes sense on the server, doesn’t necessarily make sense on the desktop. It makes sense to prioritize developer comfort over disk space use in server context, for example; it makes way less sense to do so in the desktop context.
Yeah, for example, it’s nice not having to manually fiddle with PHP dependencies etc. when it comes to web servers, but desktop apps are rarely like this. They just have their executable, and seldom require any serious configuration.
Desktop apps can have a crap-ton of dependencies and a finicky requirements around specific versions. That’s one of the reasons why “flatsnappimage” stuff got created in the first place — to go around the limitations of Linux distribution package manager dependency management model.
And we do need a better way to deal with this. But the “flatsnappimage” approach is not that, IMVHO, as it’s clearly driven by other considerations (like the “we want to have an app store we control” thing mentioned in the article).
But the thing is, in a server context you have developers, sysadmins, and that’s kinda it. They can make informed decisions on how to manage stuff, and making it easier for the developers to deploy stuff is a reasonably good strategy.
On the desktop you have app developers, OS maintainers, and users. Users often will not be able to make anywhere near as informed decisions as developers and maintainers. Focusing on developer comfort basically leads to ignoring users’ needs (like: “a calculator app should not need a 2.8GiB of stuff just for itself”).