As a person who was all in on the AppImage distribution system (vs Flatpaks), I’m both sad and excited to see how well Flatpaks seem to be working out.
I guess they won that little competition in the end - which seems good, as there’s now a healthy standard we can focus on.
It’s genuinely great to now have widely accepted distribution independent packaging standards.
I’m glad Flatpack appears to be winning over the utterly horrible Snap, but I still don’t like it. I fear a day when it becomes difficult to get software that isn’t packaged in Flatpack, and I have good reason to: Ruby Gems. Long ago, I was big into Ruby, and was a major contributor (I authored one of the core standard libraries). Gems came along, and I hated them; eventually, for unrelated reasons, I stopped using Ruby altogether, and now when I encounter it, it’s impossible to use anything that doesn’t have Gem woven into it. Consequently, AFAIK, my current system has nothing Ruby installed on it - unless my OS package manager is doing it under the hood.
IMHO, Flatpacks are a really poor work-around for people supporting and using programming languages that don’t build software correctly. Rust and Go do it right: they build stand-alone executables. Flatpack adds literally no value to software built with these. They’re not the only languages that do this, but they’re the ones having their moment; any language that builds stand-alone, statically linked binaries would do.
I’m with you about AppImage; it would have been a better solution. Any packaging solution requiring extra software to be installed and a service to use is a bad design. I’d be objecting less if AppImage were emerging as the winner.
Incidentally, this is why Podman is superior to Docker: yes, you still need extra software to be installed, but there’s no system service with crazy, root-level permissions required to run containers with podman.
As a person who was all in on the AppImage distribution system (vs Flatpaks), I’m both sad and excited to see how well Flatpaks seem to be working out.
I guess they won that little competition in the end - which seems good, as there’s now a healthy standard we can focus on.
It’s genuinely great to now have widely accepted distribution independent packaging standards.
I’m glad Flatpack appears to be winning over the utterly horrible Snap, but I still don’t like it. I fear a day when it becomes difficult to get software that isn’t packaged in Flatpack, and I have good reason to: Ruby Gems. Long ago, I was big into Ruby, and was a major contributor (I authored one of the core standard libraries). Gems came along, and I hated them; eventually, for unrelated reasons, I stopped using Ruby altogether, and now when I encounter it, it’s impossible to use anything that doesn’t have Gem woven into it. Consequently, AFAIK, my current system has nothing Ruby installed on it - unless my OS package manager is doing it under the hood.
IMHO, Flatpacks are a really poor work-around for people supporting and using programming languages that don’t build software correctly. Rust and Go do it right: they build stand-alone executables. Flatpack adds literally no value to software built with these. They’re not the only languages that do this, but they’re the ones having their moment; any language that builds stand-alone, statically linked binaries would do.
I’m with you about AppImage; it would have been a better solution. Any packaging solution requiring extra software to be installed and a service to use is a bad design. I’d be objecting less if AppImage were emerging as the winner.
Incidentally, this is why Podman is superior to Docker: yes, you still need extra software to be installed, but there’s no system service with crazy, root-level permissions required to run containers with podman.