4 ms·

There's a Pareto effort, of course. If you release Debian and Redhat packages, you cover 80% of the user base. It's not hard to maintain, if you compare to buil

There's a Pareto effort, of course. If you release Debian and Redhat packages, you cover 80% of the user base. It's not hard to maintain, if you compare to building msi installers. Further, the process of generating packages for derivatives of debian or redhat can be mostly automated, so user coverage is bound to grow if your package is popular. As for root requirements, what you are asking for are (non privileged) user installable packages. Packages that install only to the user account. This feature doesn't exist, but it'd be a much saner approach than snap/flatpak.

bogwog 4y ago
I go to cool app website, I click download, I get a '.deb' file, I click .deb file, it opens some installer GUI (instead of Ark because I'm lucky today), I click install, I get error, I google error, I find cryptic commands that modify my system in weird ways just to get the app to install, I install app, I open app, it crashes, I open firefox, I get error "error: libX.so.1.2 not found", I can no longer google the error. The system package manager is convenient when it works, because it's already there. But that's about it. Using it to install any random apps is a recipe for disaster, it leads to fragmentation since everyone on a different distro uses different commands/workarounds to fuck up their systems in different ways when trying to install poorly packaged software. If everyone just used Debian, we wouldn't need Flatpak, but obviously that's not the case. Whenever you find a "linux app" that's packaged for distroA, but you're on distroB, there's a chance that it will work. That is 100% luck and coincidence, because most linux distros just so happen to ship the same family of system software/libs, sometimes even with the same versions. Rather than leave it up to the undefined behavior lottery, a standardized non-system packaging format can guarantee that things will work across any distro. That's better for everyone involved: users, sysadmins, distro maintainers, and developers. Whether Flatpak is that format idk, but IMO it's the best overall out of the three main contenders (Flatpak, Snap, AppImage)
ripley12 4y ago
> It's not hard to maintain, if you compare to building msi installers. I don’t think building MSI installers is especially difficult; it’s kind of a set-it-and-forget-it thing. Configure Wix or Inno Setup once and then you’re good to go (on every Windows machine, no need to worry about multiple distros).
wander_homer 4y ago
> If you release Debian and Redhat packages, you cover 80% of the user base. That means you need three builds to cover Ubuntu and its derivatives (20.04, 22.04, 22.10). Two to cover Debian (10 and 11). Three to cover RHEL (7,8,9) and also a few more if you want to support Fedora. If you want to support multiple architectures you get at least twice as much builds. No matter how you put it, that's a lot more work than maintaining a simple flatpak manifest, which allows you to target all those platforms with one automated build for each architecture. And you also get the benefit of being placed in the app store and not being hold back by whatever API is the lowest-common-denominator between all those platforms or having to clutter your code base with `ifdef`s; if you want your app to use an API which was only added in GLib 2.74, then you can just do that and it'll work.

bogwog 4y ago

I go to cool app website, I click download, I get a '.deb' file, I click .deb file, it opens some installer GUI (instead of Ark because I'm lucky today), I click install, I get error, I google error, I find cryptic commands that modify my system in weird ways just to get the app to install, I install app, I open app, it crashes, I open firefox, I get error "error: libX.so.1.2 not found", I can no longer google the error. The system package manager is convenient when it works, because it's already there. But that's about it. Using it to install any random apps is a recipe for disaster, it leads to fragmentation since everyone on a different distro uses different commands/workarounds to fuck up their systems in different ways when trying to install poorly packaged software. If everyone just used Debian, we wouldn't need Flatpak, but obviously that's not the case. Whenever you find a "linux app" that's packaged for distroA, but you're on distroB, there's a chance that it will work. That is 100% luck and coincidence, because most linux distros just so happen to ship the same family of system software/libs, sometimes even with the same versions. Rather than leave it up to the undefined behavior lottery, a standardized non-system packaging format can guarantee that things will work across any distro. That's better for everyone involved: users, sysadmins, distro maintainers, and developers. Whether Flatpak is that format idk, but IMO it's the best overall out of the three main contenders (Flatpak, Snap, AppImage)

ripley12 4y ago

> It's not hard to maintain, if you compare to building msi installers. I don’t think building MSI installers is especially difficult; it’s kind of a set-it-and-forget-it thing. Configure Wix or Inno Setup once and then you’re good to go (on every Windows machine, no need to worry about multiple distros).

wander_homer 4y ago

> If you release Debian and Redhat packages, you cover 80% of the user base. That means you need three builds to cover Ubuntu and its derivatives (20.04, 22.04, 22.10). Two to cover Debian (10 and 11). Three to cover RHEL (7,8,9) and also a few more if you want to support Fedora. If you want to support multiple architectures you get at least twice as much builds. No matter how you put it, that's a lot more work than maintaining a simple flatpak manifest, which allows you to target all those platforms with one automated build for each architecture. And you also get the benefit of being placed in the app store and not being hold back by whatever API is the lowest-common-denominator between all those platforms or having to clutter your code base with `ifdef`s; if you want your app to use an API which was only added in GLib 2.74, then you can just do that and it'll work.