6 ms·

As a user I don't like neither Snaps (that for sure as this is Cannonical only) nor FlatPaks (as they seem conceptually a "80% solution" which combines the prob

As a user I don't like neither Snaps (that for sure as this is Cannonical only) nor FlatPaks (as they seem conceptually a "80% solution" which combines the problems of package systems with the problems of self-contianed apps, but don't improve on anything). For me the only acceptable solution besides proper .debs are AppImages. AppImage doesn't try to "replace" the package management for desktop apps like the former two candidates. It tries to complement package systems for some special cases (like for example commercial software, or for the cases where the user "just wants to try something out" without "polluting" the whole system with a lot of dependencies). For my desktop needs AppImage is like "Docker, the good parts". A simple self contained format that runs everywhere without any further dependencies. Compared to that Snap and FlatPak are bloated annoyances.

lawl 6y ago
I tend to agree with you, but I really like updating all my software with one click/command. So out of curiosity: My application is already self contained and statically linked, so no AppImage needed, but it behaves like one, you can just run download and run it everywhere. And so what you're describing will be for sure an option for those who like it (in fact currently it's the only option in alpha). How would you like to get updates for something like this? Visit the website yourself occasionally to check for updates? Have the application notify you a new version is available? Have an integrated updater so the binary can update itself?
- still_grokking 6y ago
  That's easy. It should be officially in Debian. ;-) Stuff like AppImage, static binaries, Docker & Co are for me at least a kind of "last resort". Even I'm using Docker a lot[1] to try things out I first look for an AppImage in those cases. But when I decide that some app should become part of my system I will look for a proper package. One source to rule them all… [1] Docker is a big problem on it's own. But as I can't avoid to have it installed because of work I decided I could use it at least to "keep experiments under control". Before I was forced to have Docker I've used systemd-nspawn for that use-case.
  - petre 6y ago
    Debian has a lot of rules, some of which prevent statically linked binaries, like Go programs, from being packaged and shipped with it. A notable example is lxd. Appimages are great but there's no sandboxing or updates. But hey, we used to downlad debs and install them by hand on Debian 1.3, before apt was a thing. Maybe appimages could be signed and distributed in a similar fashion.
    - viraptor 6y ago
      > prevent statically linked binaries, like Go programs What do you mean? There's debian go packaging team: https://go-team.pages.debian.net/ https://go-team.pages.debian.net/ as well as go packages in stable (for example https://packages.debian.org/buster/influxdb https://packages.debian.org/buster/influxdb)
    - ReallyOldLurker 6y ago
      "Appimages are great but there's no sandboxing or updates" Actually there is sandboxing and updates, if you want to take an extra steps. I prefer AppImages over Flatpack and Snaps for essentially the same reasons commented above. I typically launch them with Firejail for the sandboxing. i.e. "firejail --appimage /path/to/appimage" instead of just the appimage alone. Seems to work just fine. Firejail has additional options that can be done. Some AppImage creators do provide an update method that can be installed using zsync2, but I've not tried it since the whole point is disposability.
    - cyphar 6y ago
      Go programs are not (generally speaking) statically linked, unless you're explicitly doing CGO_ENABLED=0, -tags 'netgo' and the whole variety of other tricks needed to coax static binaries out of the compiler. Try running "ldd" or "file" on your Go binaries -- most of the time they'll be dynamic objects and linked to glibc, especially if you're just doing a stock "go build". In addition, Debian definitely does package Go programs -- they've packaged some of mine and they have possibly the most ambitious way of solving the great vendor/ issue (which most other distributions have ignored). The likely issue with LXD is that they require specific versions of various system libraries that they package in their source code bundles (including a fork of sqlite3!). I packaged LXD for openSUSE[1]. It wasn't really fun, but it is fairly doable if you have a flexible enough view on "good packaging practices" (and I imagine Debian packagers didn't feel like going through all the necessary workarounds -- which includes patching the ELF binary in the openSUSE case). And note that LXD isn't even a static binary -- I tried to compile it statically to get around a whole range of issues and it was a nightmare. [1]: https://build.opensuse.org/package/show/Virtualization:containers/lxd https://build.opensuse.org/package/show/Virtualization:conta...
- AnIdiotOnTheNet 6y ago
  Personally, I rarely think about updating my software unless there's a new feature I need or a fix for a bug that's been ruining my life, so just visiting the website when to check for new versions is fine by me. However, you could also include a facility to manually check for updates and either self-update or just show the changelog. Why manually? "I know you're about to do this thing real quick that needs to get done, but a new version is available! Would you like to twiddle your thumbs for 5 minutes while watching a progress bar?".
  - ric2b 6y ago
    > Why manually? "I know you're about to do this thing real quick that needs to get done, but a new version is available! Would you like to twiddle your thumbs for 5 minutes while watching a progress bar?". That's a very Windows-centric point of view. Programs on Linux can be updated without closing them. You get the new version when you restart them.
    - vpzom 6y ago
      Firefox has entered the chat
      - Phrenzy 6y ago
        Chocolaty GUI for Redmond. sudo apt update && sudo apt full-upgrade -y && sudo apt autoremove -y && echo 'All done!, rebooting' && sudo reboot now For everything else.
    - pjmlp 6y ago
      It only works if they are self contained without access additional resources on the file system, as the executable file is kept alive until process termination. Now if the process tries to access some datafiles that changed contents during the upgrade, it might just crash and burn, eventually corrupting data in the process.
  - michaelmrose 6y ago
    Ideally security updates aren't deferred for 5 years because its working well enough and happen for the whole system when you aren't using the machine as opposed to just for that app when you launch it.
- dflock 6y ago
  most AppImages seem to auto-update themselves when you run them, which is convenient, until it isn't. I'd want it in an apt repo, really.
  - m4rtink 6y ago
    That actually sounds pretty dangerous - what is more likely to get compromised and stay that for a long time - a random developpers app image update service or distro infrastructure ?
- yellowapple 6y ago
  > How would you like to get updates for something like this? Visit the website yourself occasionally to check for updates? Have the application notify you a new version is available? Have an integrated updater so the binary can update itself? I've seen all three approaches with AppImage'd software. There are also package managers specifically for AppImage'd software, though it doesn't look like any of 'em are particularly mature.
- wahern 6y ago
  Plenty of software companies provide their own Apt repositories. Adding a repository is usually as simple as copying a single file to /etc/apt/sources.list.d/. Sometimes you may also need to add a GPG key, which can also be as simple as copying a file to /etc/apt/trusted.gpg.d/ (though most instructions seem to favor a manual one-liner that imports the key to the global database[1]). Technically you could automate both with a one-time deb install, though I'm not aware of anybody that actually does this. In any event, after that `apt-get upgrade` will upgrade third-party packages just as well as Debian or Ubuntu packages. I much prefer Debian packages over RPM, and Apt over Yum/DNF, but unfortunately setting up a Debian package repository is more difficult than for RPM. The tools exist, and are more sophisticated and capable--for example, Aptly--but there's a higher learning curve. Also, good luck using them outside Linux. Years ago I published Debian package repositories from OpenBSD, but I had to manually hack the relevant tools to build and work on OpenBSD. For RPM/Yum I could have more easily written (and at a different job later did) an indexing tool from scratch. The problem with Debian packages and Apt repositories isn't that they're not capable, it's that they have high learning curves due to the slow accretion of features that obscure their potential. A better tooling story would help, particularly for repositories. Better tools for initializing Debian package builds exist; the problem is more a surfeit of choices. [1] It's more complicated and creates unnecessary headaches than dropping a file into trusted.gpgp.d, but the practice seems to reflect the opacity of the Debian packaging ecosystem. There's a better, simpler way to do it, but everybody cargo cults the same old solutions and then complains that it's too complex or inelegant.
m4rtink 6y ago
Appimage has its own issues though: - no update mechanism - no sandboxing and only basic app isolation - no deduplication (Flatpak automatically deduplicates everything it installs on a machine)
- AnIdiotOnTheNet 6y ago
  AppImages do have an update mechanism: https://docs.appimage.org/packaging-guide/optional/updates.html https://docs.appimage.org/packaging-guide/optional/updates.h...
  - m4rtink 6y ago
    Interesting! That must be something relatively new, as it at least looked like there was nothing back then when I looked up Appimage.
  - robotbikes 6y ago
    AppImage seems like the best replacement then. I've loathed Snap since it first appeared on my horizon and I installed LibreOffice with it and that snap image showed up in my mounted drives forever. I was a big fan of Canonical/Ubuntu for years and switching to Debian has not been without pain points but at least I have more control of my computer. Pop! OS and Linux Mint seem like good Linux desktop alternatives to Ubuntu at this point if you don't want to use Debian.
    - riku_iki 6y ago
      > Linux Mint seem like good Linux desktop alternatives to Ubuntu at this point if you don't want to use Debian. Mint also has Debian based distro.
- yellowapple 6y ago
  On the sandboxing front, it works great with Firejail: https://firejail.wordpress.com/documentation-2/appimage-support/ https://firejail.wordpress.com/documentation-2/appimage-supp...
baldfat 6y ago
FlatPack was made to address two things focused on security: 1) Application won't need root privileges 2) Without compromising on the systems security
- cies 6y ago
  Some kernels, e.g. Linux, were also made to do just (that amoung other things). I think fixing what we have in standard kernel/userland, and leaving the containers for specialized developer/devops deployed workloads may well be where this (what will be known as the snap/flatpack saga) started from, and will end as well.
saurik 6y ago
Is "I just give you a tgz with small folder of files, one of which is a binary; I managed to make it run just about everywhere" worse than AppImage (notably, for a GUI app)?
- yellowapple 6y ago
  That's basically what an AppImage is, except that an AppImage goes one step further and slaps that tarball onto an executable that opens its embedded tarball and runs whatever's inside.
rezonant 6y ago
AppImage is the format I'm using for distributing Linux apps as well, for many of the reasons you mention
arminiusreturns 6y ago
AppImages are the only thing I run also, as a full time linux user and admin. I just hate the proliferation of questionable services, especially in systemd land. A lot of my focus is on minimization of stack, and snap and flatpak just don't stand up to scrutiny imho.
Sir_Substance 6y ago
I also prefer appimages as the "least worst" of the three. However, a quick note: As someone who unofficially maintains a linux port of my companies software, I have considered packaging it as an appimage, but there's one problem with appimages that kills the concept. Appimages are read-only[1]. I'd love to package my companies product that way, but we already have update-delivery infrastructure that works on windows and mac (and linux), and it assumes it can write to the "install folder". Changing the entire update infrastructure specifically for an OS we don't officially support is a non-starter. From a developer perspective, I would love the ability to update an appimage's contents in place. However, as a user I'd also like the ability to set it read-only to block updates if I desire. Flatpak's mandatory updates are one of the key reasons I dislike it. Never the less, if the goal is to smooth the path for proprietary software to support linux without making half a dozen different packaging solutions, in place updates need to be supported. [1] edit: according to comments below, they now have an update mechanism, but it's still a totally appimage-specific process, so my problem remains :/

lawl 6y ago

I tend to agree with you, but I really like updating all my software with one click/command. So out of curiosity: My application is already self contained and statically linked, so no AppImage needed, but it behaves like one, you can just run download and run it everywhere. And so what you're describing will be for sure an option for those who like it (in fact currently it's the only option in alpha). How would you like to get updates for something like this? Visit the website yourself occasionally to check for updates? Have the application notify you a new version is available? Have an integrated updater so the binary can update itself?

still_grokking 6y ago
That's easy. It should be officially in Debian. ;-) Stuff like AppImage, static binaries, Docker & Co are for me at least a kind of "last resort". Even I'm using Docker a lot[1] to try things out I first look for an AppImage in those cases. But when I decide that some app should become part of my system I will look for a proper package. One source to rule them all… [1] Docker is a big problem on it's own. But as I can't avoid to have it installed because of work I decided I could use it at least to "keep experiments under control". Before I was forced to have Docker I've used systemd-nspawn for that use-case.
- petre 6y ago
  Debian has a lot of rules, some of which prevent statically linked binaries, like Go programs, from being packaged and shipped with it. A notable example is lxd. Appimages are great but there's no sandboxing or updates. But hey, we used to downlad debs and install them by hand on Debian 1.3, before apt was a thing. Maybe appimages could be signed and distributed in a similar fashion.
  - viraptor 6y ago
    > prevent statically linked binaries, like Go programs What do you mean? There's debian go packaging team: https://go-team.pages.debian.net/ https://go-team.pages.debian.net/ as well as go packages in stable (for example https://packages.debian.org/buster/influxdb https://packages.debian.org/buster/influxdb)
  - ReallyOldLurker 6y ago
    "Appimages are great but there's no sandboxing or updates" Actually there is sandboxing and updates, if you want to take an extra steps. I prefer AppImages over Flatpack and Snaps for essentially the same reasons commented above. I typically launch them with Firejail for the sandboxing. i.e. "firejail --appimage /path/to/appimage" instead of just the appimage alone. Seems to work just fine. Firejail has additional options that can be done. Some AppImage creators do provide an update method that can be installed using zsync2, but I've not tried it since the whole point is disposability.
  - cyphar 6y ago
    Go programs are not (generally speaking) statically linked, unless you're explicitly doing CGO_ENABLED=0, -tags 'netgo' and the whole variety of other tricks needed to coax static binaries out of the compiler. Try running "ldd" or "file" on your Go binaries -- most of the time they'll be dynamic objects and linked to glibc, especially if you're just doing a stock "go build". In addition, Debian definitely does package Go programs -- they've packaged some of mine and they have possibly the most ambitious way of solving the great vendor/ issue (which most other distributions have ignored). The likely issue with LXD is that they require specific versions of various system libraries that they package in their source code bundles (including a fork of sqlite3!). I packaged LXD for openSUSE[1]. It wasn't really fun, but it is fairly doable if you have a flexible enough view on "good packaging practices" (and I imagine Debian packagers didn't feel like going through all the necessary workarounds -- which includes patching the ELF binary in the openSUSE case). And note that LXD isn't even a static binary -- I tried to compile it statically to get around a whole range of issues and it was a nightmare. [1]: https://build.opensuse.org/package/show/Virtualization:containers/lxd https://build.opensuse.org/package/show/Virtualization:conta...
AnIdiotOnTheNet 6y ago
Personally, I rarely think about updating my software unless there's a new feature I need or a fix for a bug that's been ruining my life, so just visiting the website when to check for new versions is fine by me. However, you could also include a facility to manually check for updates and either self-update or just show the changelog. Why manually? "I know you're about to do this thing real quick that needs to get done, but a new version is available! Would you like to twiddle your thumbs for 5 minutes while watching a progress bar?".
- ric2b 6y ago
  > Why manually? "I know you're about to do this thing real quick that needs to get done, but a new version is available! Would you like to twiddle your thumbs for 5 minutes while watching a progress bar?". That's a very Windows-centric point of view. Programs on Linux can be updated without closing them. You get the new version when you restart them.
  - vpzom 6y ago
    Firefox has entered the chat
    - Phrenzy 6y ago
      Chocolaty GUI for Redmond. sudo apt update && sudo apt full-upgrade -y && sudo apt autoremove -y && echo 'All done!, rebooting' && sudo reboot now For everything else.
  - pjmlp 6y ago
    It only works if they are self contained without access additional resources on the file system, as the executable file is kept alive until process termination. Now if the process tries to access some datafiles that changed contents during the upgrade, it might just crash and burn, eventually corrupting data in the process.
- michaelmrose 6y ago
  Ideally security updates aren't deferred for 5 years because its working well enough and happen for the whole system when you aren't using the machine as opposed to just for that app when you launch it.
dflock 6y ago
most AppImages seem to auto-update themselves when you run them, which is convenient, until it isn't. I'd want it in an apt repo, really.
- m4rtink 6y ago
  That actually sounds pretty dangerous - what is more likely to get compromised and stay that for a long time - a random developpers app image update service or distro infrastructure ?
yellowapple 6y ago
> How would you like to get updates for something like this? Visit the website yourself occasionally to check for updates? Have the application notify you a new version is available? Have an integrated updater so the binary can update itself? I've seen all three approaches with AppImage'd software. There are also package managers specifically for AppImage'd software, though it doesn't look like any of 'em are particularly mature.
wahern 6y ago
Plenty of software companies provide their own Apt repositories. Adding a repository is usually as simple as copying a single file to /etc/apt/sources.list.d/. Sometimes you may also need to add a GPG key, which can also be as simple as copying a file to /etc/apt/trusted.gpg.d/ (though most instructions seem to favor a manual one-liner that imports the key to the global database[1]). Technically you could automate both with a one-time deb install, though I'm not aware of anybody that actually does this. In any event, after that `apt-get upgrade` will upgrade third-party packages just as well as Debian or Ubuntu packages. I much prefer Debian packages over RPM, and Apt over Yum/DNF, but unfortunately setting up a Debian package repository is more difficult than for RPM. The tools exist, and are more sophisticated and capable--for example, Aptly--but there's a higher learning curve. Also, good luck using them outside Linux. Years ago I published Debian package repositories from OpenBSD, but I had to manually hack the relevant tools to build and work on OpenBSD. For RPM/Yum I could have more easily written (and at a different job later did) an indexing tool from scratch. The problem with Debian packages and Apt repositories isn't that they're not capable, it's that they have high learning curves due to the slow accretion of features that obscure their potential. A better tooling story would help, particularly for repositories. Better tools for initializing Debian package builds exist; the problem is more a surfeit of choices. [1] It's more complicated and creates unnecessary headaches than dropping a file into trusted.gpgp.d, but the practice seems to reflect the opacity of the Debian packaging ecosystem. There's a better, simpler way to do it, but everybody cargo cults the same old solutions and then complains that it's too complex or inelegant.

m4rtink 6y ago

Appimage has its own issues though: - no update mechanism - no sandboxing and only basic app isolation - no deduplication (Flatpak automatically deduplicates everything it installs on a machine)

AnIdiotOnTheNet 6y ago
AppImages do have an update mechanism: https://docs.appimage.org/packaging-guide/optional/updates.html https://docs.appimage.org/packaging-guide/optional/updates.h...
- m4rtink 6y ago
  Interesting! That must be something relatively new, as it at least looked like there was nothing back then when I looked up Appimage.
- robotbikes 6y ago
  AppImage seems like the best replacement then. I've loathed Snap since it first appeared on my horizon and I installed LibreOffice with it and that snap image showed up in my mounted drives forever. I was a big fan of Canonical/Ubuntu for years and switching to Debian has not been without pain points but at least I have more control of my computer. Pop! OS and Linux Mint seem like good Linux desktop alternatives to Ubuntu at this point if you don't want to use Debian.
  - riku_iki 6y ago
    > Linux Mint seem like good Linux desktop alternatives to Ubuntu at this point if you don't want to use Debian. Mint also has Debian based distro.
yellowapple 6y ago
On the sandboxing front, it works great with Firejail: https://firejail.wordpress.com/documentation-2/appimage-support/ https://firejail.wordpress.com/documentation-2/appimage-supp...

baldfat 6y ago

FlatPack was made to address two things focused on security: 1) Application won't need root privileges 2) Without compromising on the systems security

cies 6y ago
Some kernels, e.g. Linux, were also made to do just (that amoung other things). I think fixing what we have in standard kernel/userland, and leaving the containers for specialized developer/devops deployed workloads may well be where this (what will be known as the snap/flatpack saga) started from, and will end as well.

saurik 6y ago

Is "I just give you a tgz with small folder of files, one of which is a binary; I managed to make it run just about everywhere" worse than AppImage (notably, for a GUI app)?

yellowapple 6y ago
That's basically what an AppImage is, except that an AppImage goes one step further and slaps that tarball onto an executable that opens its embedded tarball and runs whatever's inside.

rezonant 6y ago

AppImage is the format I'm using for distributing Linux apps as well, for many of the reasons you mention

arminiusreturns 6y ago

AppImages are the only thing I run also, as a full time linux user and admin. I just hate the proliferation of questionable services, especially in systemd land. A lot of my focus is on minimization of stack, and snap and flatpak just don't stand up to scrutiny imho.

Sir_Substance 6y ago

I also prefer appimages as the "least worst" of the three. However, a quick note: As someone who unofficially maintains a linux port of my companies software, I have considered packaging it as an appimage, but there's one problem with appimages that kills the concept. Appimages are read-only[1]. I'd love to package my companies product that way, but we already have update-delivery infrastructure that works on windows and mac (and linux), and it assumes it can write to the "install folder". Changing the entire update infrastructure specifically for an OS we don't officially support is a non-starter. From a developer perspective, I would love the ability to update an appimage's contents in place. However, as a user I'd also like the ability to set it read-only to block updates if I desire. Flatpak's mandatory updates are one of the key reasons I dislike it. Never the less, if the goal is to smooth the path for proprietary software to support linux without making half a dozen different packaging solutions, in place updates need to be supported. [1] edit: according to comments below, they now have an update mechanism, but it's still a totally appimage-specific process, so my problem remains :/