6 ms·
Flatpak, Snap, appimage, etc... I have pretty fastidiously avoided ever using any of the "package everything into the image" projects, and my life has been con
by fake-name 1y ago
Flatpak, Snap, appimage, etc...
I have pretty fastidiously avoided ever using any of the "package everything into the image" projects, and my life has been considerably better off.
All these things serve to do is make the developer experience easier, at the cost of delivering a much worse user experience.
I can't think of any reason a user would ever prefer packaged variant of something.
- ChocolateGod 1y ago> package everything into the image" projects But Flatpak does not do this. It consists of runtimes that usually contain the most of what applications needed, and are updated separately from the application itself.
- yjftsjthsd-h 1y agoYes, flatpak does do that; its base images only have the basics, leaving apps to bring the rest of their own libraries/dependencies.
- ChocolateGod 1y agothat's not everything which was the original comment, the Freedesktop runtime is generally enough for 90% of applications.
- jwrallie 1y agoIt is better when you cannot get a package otherwise, so if you use a distro with a big repo, it happens mostly with proprietary software.
- xorcist 1y agoMost proprietary software ships as tgz files which you can just unpack and run. A few ships with "installers", which are mostly just bash scripts with the tgz embedded. Simple enough.
- TingPing 1y agoIf you pretend dependencies don’t exist. Binaries aren’t portable.
- xorcist 1y agoFor all practical purposes they mostly are. Linux famously hasn't broken userspace in over thirty years. Pretty much all commercial software for unix (and Linux) is distributed this way since several decades. Things like ld-linux.so is mostly backwards compatible for this reason. You can still run ancient Firefox builds even if you might have to fetch an old libstc++. But those are still around, for exactly that reason. Of course, the world changes. Running X11 software might be tricky a few decades from now if nobody speaks the protocol. Something compiled for ALSA or esound might not work forever. Software dependent on a mail transport might not work when email is finally dead and everyone uses Facebook instead. Perhaps one day IPv4 sockets won't be available. That type of dependencies are the hard ones that will kill your software before any binary incompatibilities will. As long as there is a.out binaries or 32-bit software out there someone will make it work. Software from the past three decades still runs so there's hope for the next three. Until then, don't let perfect be the enemy of what's simple and works.
- paulddraper 1y agoHave you as a user never encountered dependency hell?? Who are you and how can we trade places?
- tapoxi 1y agoBecause shipping the runtime with the software means you can get newer software on older distributions. It's also great for immutable/atomic systems where installing packages at the system level is an anti pattern.