I know snap is fairly unpopular in the Linux community, and I’ve seen mixed responses regarding Flatpak. I wanted to know, what’s the general opinion of people in this community regarding this 2 package managers?

  • corsicanguppy@lemmy.ca
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    As an out-of-band software delivery method and supply chain that

    • breaks single source of truth
    • defeats/breaks simple enterprise-style (HOST-RESOURCES-MIB::hrSWInstalledName) inventory
    • enforces/uses alternate dependencies

    It has ab-sol-ute-ly no value to me, and only security risk after security risk.

    Apologies to those who’ve spent time on them, but I’m happy to not see them as their value within the scope of my workday fell off a cliff in about 1996 - maybe before they even existed - with the advent of something better.

    Again, sorry. I’m only speaking as someone who used to manage OS security on Unix and has spent 20 years in the leviathan-enterprise space as rehab. Your mileage with glitter may vary.

  • sleepyTonia@programming.dev
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    1 year ago

    Flatpak’s the only one I’ve had good experiences with. Tangentially related, but I especially dislike AppImages. I’m not a fan of how bulky installing various flatpaks ends up being and use native packages or the AUR usually, but beyond that they’re really convenient for non-critical applications that otherwise would mesh poorly with my distro or aren’t available there. Friend of mine tells me it’s also a nice system to package Windows applications/games with a preconfigured Wine version.

  • PrivateButts@geddit.social
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    I like having options, but I wished they were better. Snap has been nothing but trouble for me, I had Authy break on me for weeks until I found that it couldn’t handle a symlink in my home directory. Flatpaks just take forever to install and update, and it sucks that there’s weird sharp edges around flatpaks permissions that cause some apps to break. App Image have been pretty okay, especially when you have that integrator tool, just would be nice if they could update themselves.

    IDK. I kinda miss PPAs being the norm.

  • ChilledFlames@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Don’t really like Snap since it uses my system ram whenever I boot up my os.

    As for Flatpak, its been a great experience for me so far.

  • ghariksforge@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 year ago

    Flatpak made my life much easier. It solves so many problems that the Linux ecosystem had. “Package once, use everywhere” is great.

    Snap could have been similarly good, but I think Canonical made some mistakes.

    I don’t hate Snap. I think a bit of friendly competition is good for both Snap and Flatpak.

  • minnix@lemux.minnix.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    I’m on Kinoite so I love flatpaks obviously. I will never integrate another application into my system again after going immutable. For everything else I setup a toolbox.

  • afb@lemmy.ml
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    I like Snaps on my server, not on my desktop. Flatpaks are fine. I use them for stuff I wouldn’t compile myself anyway (mainly proprietary binaries) but I prefer compiling my own packages where I can.

  • heliumlake@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Only snap app I have is Nextcloud on my Ubuntu-based VPS. It “just worked” as opposed to the manual install and automatically updates. Several years with minimal downtime (only for regular system upgrades and moving from one LTS release to the next), so it’s been very reliable actually. I use Flatpak for certain applications on my desktop since I don’t run Ubuntu on my personal computers. I haven’t had any bad practical experiences with either, but definitely understand those weary of Snap.

  • featured@lemmy.ml
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Flatpak is fantastic. I think containerization is definitely the future of Linux app distribution, because the security and portability are so much better than native packages. Flatpak is the best implementation of this concept IMO, because it has a robust permission management system, is completely open unlike snap, and is performant with fast load times, solid deduplication of dependencies, and no garbage loopback devices

  • Vincent@feddit.nl
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Thanks to Flatpak, I can have basically careless OS updates with Fedora Silverblue, so I’m very happy with them. I also appreciate the fact that every distro that can run Flatpak automatically has a wide range of software available to it.

    I’m sure Snaps have similar advantages, but I haven’t worked with them much. I don’t really like that you can only publish Snaps through Canonical though, so in that sense I hope Flatpak wins.

  • wolf@lemmy.zip
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    1 year ago

    Seriously, I really wonder if the opinion about Snap/Flatpak is really that strong outside of the echo chambers of the Linux online communities.

    Concerning Snap, I saw people upgrade from Ubuntu 18.04 to 22.04 w/o even noticing it. (AFAIK that was after Canonical invested some time in the performance problems.) Of course, I can also understand Ubuntu users which where unhappy about performance degradations with Snap packages.

    I run openSUSE MicroOS/Aeon on my entertainment system with Flatpaks, and for my use case, flatpaks / immutable Linux distributions are brilliant: Automatic updates on reboot and I didn’t have to bother with anything after the first time setup.

    On my work desktops I run Debian and I am quite happy for some applications packaged as Flatpak, which would be hard to get in updated versions otherwise. At the same time, development environments in Flatpak are - at this moment - more trouble to me than it is worth it (integrating with toolchains/build systems and the operating system).

    In general, my opinion is that Snaps/Flatpak provide a great solution distributing software in the Linux ecosystem and I would prefer, if distributions focus more on their core operating system instead of the redundant work of packaging the same software again and again and again. Of course, Snaps/Flatpaks will always have some drawbacks compared to a package integrated into your system (a little bit more disk space and perhaps a little bit more memory). OTOH a lot of problems we see now will hopefully be solved in the short/long run (theme integration, sandboxing, integration in the rest of the system).

    The best thing that could possibly happen is, that the maintainers of several distributions which do redundant work team up on the flatpak packages and make them really awesome.

    Looking really forward how things will develop in the next few years, and I especially look forward how openSUSE Aeon will develop. Linux is getting interesting again. ;-)

  • Ryan@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    arrow-down
    1
    ·
    1 year ago

    In my experience, snaps are better for servers, and flatpaks are better for desktops.

    I haven’t used snaps for a couple years, so they may have fixed this, but I’ve found flatpaks have less issues interacting with peripherals that aren’t mice/keyboards without fenagling with app permissions. A number of snap apps just wouldn’t work without disabling containment entirely (aka “classic”).

    Flatpak permissions can be manipulated from system settings in Plasma, and there’s also Flatseal. I am not aware of an equivalent for snaps; doesn’t mean it doesn’t exist, I haven’t kept up with what’s available for snap for some time.

  • PAPPP@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    0
    arrow-down
    1
    ·
    1 year ago

    For the most part, I’d rather have native packages. I’m not deeply philosophically opposed to secondary packaging systems, and only mildly opposed to “ship the whole dependency tree in an archive” software distribution methods (lookin’ at you NextStep/OS X style bundles), and see their potential especially on platforms with no/bad native package managers or to bring in specific software that would pose a compatibility problem for the host system… but they never seem to work nearly as well as native packages, and the two big players on Linux have problems.

    As far as I’m concerned, they’re just taking the old last-ditch practice of “I have this piece of recalcitrant software that is incompatible with the rest of my system, so I’ll throw it in /opt with its entire dependency tree,” replacing opt with a bunch of bind mounts, and doing so with varying degrees of additional tooling.

    The sandboxing is a nice idea, but it seems like in practice the models on both snap and flatpack are simultaneously restrictive in ways that make them annoying-to-unusable for many tasks, and too sloppy to provide reliable security guarantees.

    They make debugging problems harder because you can’t check functionality from another program because they likely don’t share libs. ldd is a lot easier than spelunking around with eg. flatpak list --app --columns=application,runtime until you find a “peer” to test.

    If I need a one-off piece of software that is a compatibility nuisance on my host distro (but not so much of a nuisance it needs to go in a container or VM, which is a pretty narrow window), I’ll usually reach for an AppImage because unlike the other two, they’re actually fairly standalone and don’t involve a big invasive runtime/tooling system.

    The Immutable-core OSes that depend on them are kind of the same way at the moment. Fundamentally a pretty neat idea, but so far I find them super frustrating in practice. Nix is …different… to work with, but is likely a more elegant scheme to solve the same class of problems.