• Derin@lemmy.beru.co
    link
    fedilink
    arrow-up
    0
    ·
    1 day ago

    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.