If you’re separating your application from the core system package manager and shared libraries, there had better be a good and specific reason for it (e.g. the app needs to be containerized for stability/security/weird dependency). If an app can’t be centrally managed I don’t want it on my system, with grudging exceptions.
Chocolatey has even made this possible in Windows, and lately for my Windows environments if I can’t install an application through chocolatey then I’ll try to find an alternative that I can. Package managers are absolutely superior to independent application installs.
Typically Windows applications bundle all their dependencies, so Chocolatey, WinGet and Scoop are all more like installing a Flatpak or AppImage than a package from a distro’s system package manager. They’re all listed in one place, yes, but so’s everything on FlatHub.
This is true, the only shared libraries are usually the .NET versions, but so many apps depend on specific .NET versions that frequently the modularity doesn’t matter.
Definitely. I’d rather have a “good and specific reason” why your application needs to use my shared libraries or have acess to my entire filesystem by default.
Using your shared libraries is always a good thing, no? Like your distro’s packages should always have the latest security fixes and such, while flatpaks require a separate upgrade path.
Access to your entire filesystem, however, I agree with you on.
I only use rolling releases on my desktop and have ran into enough issues with apps not working because of changes made in library updates that I’d rather they just include whatever version they’re targeting at this point. Sure, that might mean they’re using a less secure version, and they’re less incentivized to stay on the latest version and fix those issues as they arise, but I’m also not as concerned about the security implications of that because everything is running as my unprivileged user and confined to the flatpak.
I’d rather have a less secure flatpak then need to downgrade a library to make one app I need work and then have a less secure system overall.
I’m now confused if they’re saying that flatpak is centrally managed or not. To me it seems centrally managed, both the flatpak ecosystem but your whole machine (repo packages, firmware, flatpak) if you use those app stores. I might’ve misunderstood what they said.
Oh no, no GUI nonsense. Single, simple shell command update for the whole system so that it can be properly remotely managed, please. Something equivalent to sudo apt upgrade
I’ve written a small script that does all the updates (repo, flatpak, docker), verified the packages, does cleanup and shows if stuff needs rebooted. Handy. That way I can do everything from one short command
Flatpack can be centrally managed, it’s just like a parallel distribution scheme, where apps have dependencies and are centrally updated. If a flatpack is made reasonably, then it gets library updates independent of the app developer doing it.
“App image” and " install from tarball" violate those principles, but not snap or flatpack.
Um, if it’s “parallel” (e.g. separate from the OS package manager) then it’s not centrally managed. The OS package manager is the central management.
There might be specific use cases where this makes sense, but frankly if segregating an app from the OS is a requirement then it should be fully containerized with something like Docker, or run in an independent VM.
If a flatpack is made reasonably, then it gets library updates independent of the app developer doing it.
That feels like a load-bearing “if”. I never have to worry about this with the package manager.
Define “the OS package manager”. If the distro comes with flatpack and dnf equally, and both are invoked by the generic “get updates” tooling, then both could count as “the” update manager. They both check all apps for updates.
Odd to advocate for docker containers, they always have the app provider also on the hook for all dependencies because they always are inherently bundled. If a library has a critical bug fix, then your docker like containers will be stuck without the fix until the app provider gets around to fixing it, and app providers are highly unreliable on docker hub. Besides, update discipline among docker/podman users is generally atrocious, and given the relatively tedious nature of following updates with that ecosystem, I am not surprised. Even best case, docker style uses more disk space and more memory than any other option, apart from VM.
With respect to never having to worry about bundled dependencies with rpm/deb, third party packages bundle or statically link all the time. If they don’t, then they sometimes overwrite the OS provided dependency with an incompatible one that breaks OS packages, if the dependency is obscure enough for them not to notice other usage.
If you’re separating your application from the core system package manager and shared libraries, there had better be a good and specific reason for it (e.g. the app needs to be containerized for stability/security/weird dependency). If an app can’t be centrally managed I don’t want it on my system, with grudging exceptions.
Chocolatey has even made this possible in Windows, and lately for my Windows environments if I can’t install an application through chocolatey then I’ll try to find an alternative that I can. Package managers are absolutely superior to independent application installs.
Typically Windows applications bundle all their dependencies, so Chocolatey, WinGet and Scoop are all more like installing a Flatpak or AppImage than a package from a distro’s system package manager. They’re all listed in one place, yes, but so’s everything on FlatHub.
This is true, the only shared libraries are usually the .NET versions, but so many apps depend on specific .NET versions that frequently the modularity doesn’t matter.
I think containerization for security is a damn good reason for virtually all software.
Definitely. I’d rather have a “good and specific reason” why your application needs to use my shared libraries or have acess to my entire filesystem by default.
Using your shared libraries is always a good thing, no? Like your distro’s packages should always have the latest security fixes and such, while flatpaks require a separate upgrade path.
Access to your entire filesystem, however, I agree with you on.
I only use rolling releases on my desktop and have ran into enough issues with apps not working because of changes made in library updates that I’d rather they just include whatever version they’re targeting at this point. Sure, that might mean they’re using a less secure version, and they’re less incentivized to stay on the latest version and fix those issues as they arise, but I’m also not as concerned about the security implications of that because everything is running as my unprivileged user and confined to the flatpak.
I’d rather have a less secure flatpak then need to downgrade a library to make one app I need work and then have a less secure system overall.
emerge sec-policy/selinux-*
I think stability is a pretty good reason
Open Discover, Gnome Software etc -> Click update?
And with topgrade you can even upgrade flatpaks and your distros repos in one go
I’m now confused if they’re saying that flatpak is centrally managed or not. To me it seems centrally managed, both the flatpak ecosystem but your whole machine (repo packages, firmware, flatpak) if you use those app stores. I might’ve misunderstood what they said.
We’re both saying that it’s centrally managed
Fuck, I took both the wrong way. Sorry about that
Oh no, no GUI nonsense. Single, simple shell command update for the whole system so that it can be properly remotely managed, please. Something equivalent to
sudo apt upgradeI’ve written a small script that does all the updates (repo, flatpak, docker), verified the packages, does cleanup and shows if stuff needs rebooted. Handy. That way I can do everything from one short command
Flatpack can be centrally managed, it’s just like a parallel distribution scheme, where apps have dependencies and are centrally updated. If a flatpack is made reasonably, then it gets library updates independent of the app developer doing it.
“App image” and " install from tarball" violate those principles, but not snap or flatpack.
Um, if it’s “parallel” (e.g. separate from the OS package manager) then it’s not centrally managed. The OS package manager is the central management.
There might be specific use cases where this makes sense, but frankly if segregating an app from the OS is a requirement then it should be fully containerized with something like Docker, or run in an independent VM.
That feels like a load-bearing “if”. I never have to worry about this with the package manager.
Define “the OS package manager”. If the distro comes with flatpack and dnf equally, and both are invoked by the generic “get updates” tooling, then both could count as “the” update manager. They both check all apps for updates.
Odd to advocate for docker containers, they always have the app provider also on the hook for all dependencies because they always are inherently bundled. If a library has a critical bug fix, then your docker like containers will be stuck without the fix until the app provider gets around to fixing it, and app providers are highly unreliable on docker hub. Besides, update discipline among docker/podman users is generally atrocious, and given the relatively tedious nature of following updates with that ecosystem, I am not surprised. Even best case, docker style uses more disk space and more memory than any other option, apart from VM.
With respect to never having to worry about bundled dependencies with rpm/deb, third party packages bundle or statically link all the time. If they don’t, then they sometimes overwrite the OS provided dependency with an incompatible one that breaks OS packages, if the dependency is obscure enough for them not to notice other usage.