137
Why Flatpak Won and Snap and AppImage Didn't. - Cameron Knauff (youtube.com)
submitted 6 months ago by to c/linux@programming.dev
123 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 98 points 6 months ago (52 children)

I like both flatpaks and appimages why does everything have to be a victory and defeat

  • permalink
  • fedilink
  • source
  • hideshow 52 child comments
    •
  • [–] 72 points 6 months ago (37 children)

    Because it's nice for devs to have a single package type to build per OS

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 37 child comments
    •
  • [–] 20 points 6 months ago (24 children)

    Why can’t they do that already? Just choose whichever one you want it’s trivial for me to run whichever as a user

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 24 child comments
    •
  • [–] 36 points 6 months ago (14 children)

    Just not snaps.

    AppImage and flatpak are fine though

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 14 child comments
    •
  • [–] 9 points 6 months ago (12 children)

    Whats wrong with snaps? My only "issue" with appimages is i tend to leave them in my downloads folder and lose them

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 12 child comments
    •
  • [–] 20 points 6 months ago*

    The snap store is a shit show of security issues.

    Forced migration to snaps.

    Performance issues.

    Proprietary back end.

    Slow to install

    Slow to start

    Eat up RAM

    Eat up disk space

    They screw up access to devices.

    They automatically update themselves without user confirmation.

    Fuck snaps. Fuck Canonical.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 6 points 6 months ago (4 children)

    There's an appimaged daemon you can install that will manage them, and it watches a bunch of folders to integrate appimages with xdg and whatever window manager you've got. ~/Applications looks like an easy pick, or ~/.local/bin.

    Appimages you decide to keep you can just move there!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 6 months ago (3 children)

    Why do you keep appimages? I don't do that and now I'm wondering if I do something wrong. But I try to install from repos as much as possible.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 6 months ago*

    I've used one or two tools that only distribute for my system as an appimage or as source code.

    I can't always be bothered to set up a compilation environment or deal with removing dependencies.

    I only use one or two regularly, but it's nice to have them integrated!

    I prefer from the distro's repos, then source, then flatpack, then appimage. Sometimes you have to take what you can get!

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 6 months ago

    That's why I whenever I download an appimage that I intend to use somewhat regurarly, I typically make a .desktop file for it in /usr/share/applications so it shows up in my app menu or rofi or dmenu or whatever and I don't have to go looking for it. It also helps to have a folder you toss them all into

  • permalink
  • fedilink
  • source
  • parent
  • [–] 10 points 6 months ago (8 children)

    Recently I wanted to uninstall $thing. Couldn’t via the package manager. I had forgotten that it wasn’t a native package. So what was it? *scratches head* Flatpak, snap or Appimage? Aw damn, it’s an AppImage. Now where did I put the binary? *scratches head*.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 11 points 6 months ago (2 children)
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 5 points 6 months ago

    Maybe you would like appimagelauncher. It allows you to define a directory for storing your appimages and you just put them in there and you can automatically launch it from the system menu as if they were installed apps. It also makes removing them easier, since they're all in the same directory and you just remove them and the shortcuts get deleted as well

  • permalink
  • fedilink
  • source
  • parent
  • [–] 4 points 6 months ago

    The fluxer appimage will 'install' itself into /opt/ without your knowledge. I think because it's essentially an electron package similar to stoat, standard notes and discord, large parts of it can self-update without needing to bump the actual package version, but this is really shitty behaviour considering what appimages are designed to do.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 12 points 6 months ago (6 children)

    It goes a long way to simplicity from both a user and dev to have only one package type to deal with and distribute.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 7 points 6 months ago (3 children)

    This completely. Speaking as a person who's more tech skilled than 99% of non-programmers, i can tell you that installing apps is the main tech hurdle for Linux getting mainstream adoption.

    There are non-tech hurdles too, but of the actual technology being easy to use then app installation is really the only aspect left that regular people can't do without a huge dive of tech learning that's beyond what most people can do.

    • Installing on mac: click the Mac download button and follow the prompts.

    • Installing on Windows: click the Windows download button and follow the prompts.

    • Installing on Linux: there's no Linux download button, there's a couple of buttons that say words you've never heard of before. They look kinda like buttons to download an app. You click one and try to open it, but it just shows an error, etc etc etc

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 6 months ago (2 children)

    As a longtime Mac user, that’s not quite as easy. Some apps are only available through the Mac App Store. For applications you download there are several variants:

    • installers: double click and go through an install wizard with next buttons
    • zip files: double click to unpack, then put the app wherever you want (typically /Applications or ~/Applications)
    • disk images: double click to mount. Then drag and drop the app to /Applications
    • through macports or homebrew via command line
    • there are a couple of Apple system tools, that are often installed via command line like Rosetta and Xcode command line tools

    Of course you can have a zip file, that contains a disk image, that then contains an installer.

    For applications downloaded from the internet, you also get at least a warning when opening it. If it’s not notarized, you have to go to system settings to be able to run it. For many applications, you also need to go to settings and fiddle with sandbox settings to make them work.

    New users are often challenged by all these options. There are many who end up running an app from a disk image for example.

    You might also need to select the correct architecture because some applications don’t provide universal binaries for some reason.

    While installation is an issue for Linux, the bigger issue is the low availability of quality commercial software. The immense fracturing between distributions creates tons of issues as well.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 6 months ago (1 child)

    You CAN do those, but essentially 100% of apps that regular people are gonna want will be: click mac download -> open file -> follow prompts. That's the point of a standard, which is not to necessarily eliminate alternatives, rather to make a single one be the default for almost 100% of standard situations.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 6 months ago

    Yes, for Linux it‘s like this typically (varies by distro):

    • Discover (App Store) has two versions of the same application: repository and flatpack
    • The website of the project might offer specific instructions or packages for a handful of distros, maybe a extra repository, maybe an appimage

    Figuring out the best way to install the software often involves at least comparing two versions and deciding, which one you want.

    macOS has many ways to install, but most software only choose one or two. And you usually get the same version regardless of install path.

    For Linux you have several options to install and you don’t end up with the same version.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 5 points 6 months ago (1 child)

    I'd agree with that sentiment, but at least for me, if we went with all flatpacks, i'd be losing the one ability that I like about appimages, which is as a one-time-use type of "installation". They're kind of like those windows EXEs that you could just run in place without needing to install. very useful for stuff like raspberrypi imager where I don't need to keep it around much

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 7 points 6 months ago

    appimages also allow some sort of portable apps you can carry around. Very useful for dealing with no internet scenarios. I also use appimages for things iI use very rarely and don't want to bother to have them being updated regularly along with the system

  • permalink
  • fedilink
  • source
  • parent
  • [–] 0 points 6 months ago (4 children)

    why does everything have to be a victory and defeat

    there can only be one standard.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 3 points 6 months ago (3 children)

    But what if it doesn't cover my specific usecase?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •