this post was submitted on 21 Dec 2024
186 points (90.1% liked)
Linux
5491 readers
649 users here now
A community for everything relating to the linux operating system
Also check out !linux_memes@programming.dev
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Coming from someone who just migrated myself and my family within the last year. Flatpaks were a big deal. I get people have their criticisms of it but wow, installing and updating apps is so much easier now compared to when I tried linux last and flatpak is probably the main reason why we are still on Linux today.
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.