Linux Appimage Support

[philipzae]

Rather than a bash install script for linux, why not package it as a standalone linux executable.

You can find information about how to do so here - https://github.com/AppImage/AppImageKit/

[robertheadley]

I am generally support of this idea.

[zero77]

I dont no if this helps but:

There are different ways to create AppImages:

Use Open Build Service (OBS)
Convert existing binary packages (.deb, .rpm, …)
Bundling your Travis CI builds as AppImages
Run linuxdeployqt on your Qt application
Using electron-builder for Electron-based apps
Create an AppDir manually

Documentation:
https://docs.appimage.org/packaging-guide/ways.html
https://github.com/AppImage/AppImageKit/wiki/Creating-AppImages

[indolering]

Quoting from elsewhere,

I mentioned Flatpak runtimes, and this is a key aspect of it. AppImage doesn't really have the concept of a runtime (i.e. "what does this app needs in order to run"), so you have to literally boot your computer with the oldest system you want to support, and build the AppImage inside it. This is not a joke, this is a documented best practice (!). Flatpaks don't need any of this because it addresses the true problem behind it: it isolates the application from the host system for real, at glibc level. It is, by design, guaranteed to work everywhere.

[TheAssassin]

I mentioned Flatpak runtimes, and this is a key aspect of it. AppImage doesn't really have the concept of a runtime (i.e. "what does this app needs in order to run")

True, that's entirely intentional. Our concept is simple: one file = one app. No root needed to install or uninstall, management is easy.

so you have to literally boot your computer with the oldest system you want to support, and build the AppImage inside it. This is not a joke, this is a documented best practice (!).

That's just nonsense. Nobody forces you to reboot your computer. There's Docker, there's VMs, there's chroot, there's tons of way to avoid rebooting while still building on an older system. Then there's ways to include everything into your AppImage (including libc, but that's got a lot of downsides), and you can also use tools like devtoolset which partially link libc/libstdc++ into your application.

What should be a best practice is not insisting to live on the bleeding edge. In 99% of all cases, there's no point in depending on the ever latest libraries and other deps.

Flatpaks don't need any of this because it addresses the true problem behind it: it isolates the application from the host system for real, at glibc level.

True. That comes at a significant cost. You don't have just one runtime, worst case you have one per app. The management requires root, and they're not nearly as portable as an AppImage (which you can copy onto e.g., a USB disk, and it'll work on almost any Linux computer).

It is, by design, guaranteed to work everywhere.

But only if flatpak is installed, the user is allowed to use it, ...

Well-built AppImages literally work everywhere, no dependencies needed. AppImages add a little bit of work for the developers, but for users there's no complexity. The only sticking point is they have to chmod +x them. But it's not hard at all, and there's a Quickstart docs page.

[indolering]

I am not an expert on AppImage or Flatpak, so please forgive any misconceptions I have and take the following questions as genuine 🤗.

That's just nonsense. Nobody forces you to reboot your computer. There's Docker, there's VMs, there's chroot, there's tons of way to avoid rebooting while still building on an older system. Then there's ways to include everything into your AppImage (including libc, but that's got a lot of downsides), and you can also use tools like devtoolset which partially link libc/libstdc++ into your application.

The point is that the maintenance burden is higher. And if you copy everything into AppImage, do you also copy in distro specific binaries? What happens when those binaries need a security update?

What should be a best practice is not insisting to live on the bleeding edge. In 99% of all cases, there's no point in depending on the ever latest libraries and other deps.

I thought the support lifecycle for Flatpak runtimes had gotten better since the 1.0 release? I know RedHat was working on making one that the community can use, which will be supported for 10 years.

Flatpaks don't need any of this because it addresses the true problem behind it: it isolates the application from the host system for real, at glibc level.

True. That comes at a significant cost. You don't have just one runtime, worst case you have one per app.

One runtime per application is not a genuine argument, please be kind :) Most applications use one of the runtimes maintained by Flatpak (Freedesktop + Gnome or KDE) and files within those runtimes are de-duplicated via OSTree.

The cost of not having runtimes is that you either have to:

• bundle components into the binary (which are not de-duplicated without a fancy filesystem);
• or rely on system libraries and support each distro individually.

The management requires root,

Only for the initial Flatpak install, not for application installs or updates. And for most personal computers which aren't administrated by a third party, that isn't a problem.

and they're not nearly as portable as an AppImage (which you can copy onto e.g., a USB disk, and it'll work on almost any Linux computer).

For all of the linux distros that the application developers are willing to support, right?

Well-built AppImages literally work everywhere, no dependencies needed. AppImages add a little bit of work for the developers, but for users there's no complexity. The only sticking point is they have to chmod +x them. But it's not hard at all, and there's a Quickstart docs page.

But it sounds like a well built AppImage requires work on par with shipping a custom binary for each distro, right?

What does AppImage provide that BiglyBT doesn't get from using Install4J? I think it makes it so you don't have to use the package manager to install Java... And what benefit does it have over including OpenJDK or using the Java AOT compiler?

My biggest concern is security: BiglyBT is exposed to anonymous network peers and handles sketchy files. Having a distribution independent sandboxing mechanism (which Flatpak provides) would be very helpful. 🤷

[TheAssassin]

The point is that the maintenance burden is higher.

Not really. There's tooling that automates all this away. Flatpak isn't magic either, they just have a lot more people work on more tools for more use cases. Our tools are far less complex and therefore are easy to include in automated scripts. It's fairly easy to write something based on Docker in half an hour. I just copy-paste my scripts often enough.

And if you copy everything into AppImage, do you also copy in distro specific binaries? What happens when those binaries need a security update?

Well, the tools that create the bundles copy whatever libs the binary depends on in that second. Most binaries from, say, Ubuntu or Debian just work everywhere.

There's of course a need to keep your AppImages up to date. If you don't want to do it by yourself, openSUSE build service auto-rebuilds AppImages when deps are updated. Of course, the user still has to update, but that's outside the scope of this question.

I thought the support lifecycle for Flatpak runtimes had gotten better since the 1.0 release? I know RedHat was working on making one that the community can use, which will be supported for 10 years.

This was meant as a general remark. Unless you have to, it's IMO a misconception to still depend on the latest e.g., C/C++ release, library versions etc.

One runtime per application is not a genuine argument, please be kind :) Most applications use one of the runtimes maintained by Flatpak (Freedesktop + Gnome or KDE) and files within those runtimes are de-duplicated via OSTree.

That's the worst case. Us programmers tend to think in the big-O notation to express complexity. Worst case for Flatpak runtimes is O(n). Best case would be O(1) (just one runtime), but that's just unrealistic as well. The truth is somewhere in between. The more runtimes there exist, though, the more runtimes you'll see people using for their own apps.

The cost of not having runtimes is that you either have to:

• bundle components into the binary (which are not de-duplicated without a fancy filesystem);
• or rely on system libraries and support each distro individually.

AppImage has ever done a hybrid approach (they use squashfs internally, which is a fancy file system that deduplicates). We rely on some system libs (e.g., libc) not only for efficiency (filesize) or security (updated with the system) reasons. Some dependencies like e.g., GPU or other hardware drivers, cannot be safely bundled even, and they then start failing if you have the wrong libc version on the system.

Only for the initial Flatpak install, not for application installs or updates. And for most personal computers which aren't administrated by a third party, that isn't a problem.

Still. There's tons of computers where you don't have root access (schools/universities/corporate environments). It's a significant drawback that AppImage doesn't have due to its portable, user-oriented design.

For all of the linux distros that the application developers are willing to support, right?

There's always esoteric weird systems. Any developer-authored application bundle is provided for specific systems, they can't support every weird system. However, at least you can call AppImages a best-effort attempt to support these, too. It might work.

Note that there's no runtime dependencies required from systems other than FUSE, really (and maybe some sane directory layout that respects the FHS).

But it sounds like a well built AppImage requires work on par with shipping a custom binary for each distro, right?

The entire idea of AppImage is to not have to ship anything distro-specific. Most AppImages just work on any major distro.

What does AppImage provide that BiglyBT doesn't get from using Install4J? I think it makes it so you don't have to use the package manager to install Java... And what benefit does it have over including OpenJDK or using the Java AOT compiler?

AppImages have a standard UI. What language your software is written in is merely an implementation detail, the user doesn't have to care. AppImages provide proper desktop integration (i.e., there's conventions on how to bundle icons, AppStream metadata, desktop files, ...), and there's tools which pick those up (e.g., AppImageLauncher).

You're free to ship your own hacks for that, but by relying on AppImage's concepts, you don't have to worry. There're tools even which automatically recognize problems and provide feedback on how to improve.

My biggest concern is security: BiglyBT is exposed to anonymous network peers and handles sketchy files. Having a distribution independent sandboxing mechanism (which Flatpak provides) would be very helpful. shrug

Well, sandboxing is at most a minor component in your system's protection against malware. I don't know how big the attack surface of BiglyBT is. Relying on sandboxing only is not a good idea. Most profiles I've seen try to limit access, but unless written by someone who knows all the internals of the software, they leave some doors open as well.

If you think this software would be risky to use, you should maybe think twice about using it on your regular system. Setting up a VM is not too complicated, and much safer than any sandboxing.

(These are general comments by the way, I don't know BiglyBT. I was pointed here by someone on IRC to lift a few secrets on AppImage.)

[indolering]

I haven't had to package anything with AppImage, so I'm not going to comment on how much easier/harder it is to support a given distro here. But maybe we could dialogue over email? I'm thinking of writing up a comparison for a blog post....

I thought the support lifecycle for Flatpak runtimes had gotten better since the 1.0 release? I know RedHat was working on making one that the community can use, which will be supported for 10 years.

This was meant as a general remark. Unless you have to, it's IMO a misconception to still depend on the latest e.g., C/C++ release, library versions etc.

But Flatpak was specifically designed to alleviate this particular aspect of dependency hell without having to compromise on security and requiring O(n) effort to support more distros. In practice, the early versions of Flatpak runtimes weren't backporting security fixes and lacked LTS releases. But that has gotten better since 1.0 and will be virtually eliminated if/when RedHat releases their commercially supported LTS runtime.

One runtime per application is not a genuine argument, please be kind :) Most applications use one of the runtimes maintained by Flatpak (Freedesktop + Gnome or KDE) and files within those runtimes are de-duplicated via OSTree.

That's the worst case. Us programmers tend to think in the big-O notation to express complexity. Worst case for Flatpak runtimes is O(n). Best case would be O(1) (just one runtime), but that's just unrealistic as well. The truth is somewhere in between. The more runtimes there exist, though, the more runtimes you'll see people using for their own apps.

Technically speaking, AppImage packaging adds a constant amount of disk-space overhead for each supported distro, which results in O(n) overhead for each application. But that's not a good-faith argument because (as my computer science professor emphasized on the first day of Algorithms and Complexity 😉) the details matter.

I'm not bored enough to write a script to do this analysis, but I checked roughly half of the runtimes used on Flathub and found only three that were not using the standard Freedesktop, Gnome, or KDE runtimes. There are multiple versions of each runtime, but the real-world space overhead is (thanks to OSTree deduping files) O(log(3 * runtime_versions)). So the most appropriate figure to cite here is O(log n).

It's true that a runtime will add more overhead than in-lining libraries, but your argument would be much more convincing if you made some real-world measurements of Flatpak and AppImage disk space overhead.

It would be really cool if Gnome collected telemetry on Flatpak disk usage....

For all of the linux distros that the application developers are willing to support, right?

There's always esoteric weird systems. Any developer-authored application bundle is provided for specific systems, they can't support every weird system. However, at least you can call AppImages a best-effort attempt to support these, too. It might work.

Note that there's no runtime dependencies required from systems other than FUSE, really (and maybe some sane directory layout that respects the FHS).

That's cool! You keep mentioning OBS (for which I was an enthusastic user and recommend regularly) but it doesn't support anything outside of the .deb and .rpm hegemony. What is it like for Arch or Gentoo? I assume that any distro can support Flatpak by ensuring compatibility between Flatpak and the core runtimes....

But it sounds like a well built AppImage requires work on par with shipping a custom binary for each distro, right?

The entire idea of AppImage is to not have to ship anything distro-specific. Most AppImages just work on any major distro.

But if you have to build on each supported distro.... I guess I need to dig into AppImage to really understand the requirements here.

Well, sandboxing is at most a minor component in your system's protection against malware. I don't know how big the attack surface of BiglyBT is. Relying on sandboxing only is not a good idea. Most profiles I've seen try to limit access, but unless written by someone who knows all the internals of the software, they leave some doors open as well.

User based privilege separation was designed for single-use servers back in the 1970s. For the applications that 98% of the population uses, sandboxing + portals (see 1, 2) would confine any security issues to the application's data.

Would you seriously consider using any smartphone that didn't deploy per-app sandboxing policies?

If you think this software would be risky to use, you should maybe think twice about using it on your regular system. Setting up a VM is not too complicated, and much safer than any sandboxing.

I run almost everything in tightly constrained sandboxes or distinct virtual machines; it's a fucking nightmare of complexity. I believe that normal people deserve to have privacy and security. I'm advocating for Flatpak because they are doing the hard work of creating well defined boundaries between applications and the host system. Someday, we could even wrap Flatpak apps in lightweight VMs and get Qubes-level security without the insane overhead and crappy UX.

What does AppImage provide that BiglyBT doesn't get from using Install4J? I think it makes it so you don't have to use the package manager to install Java...

AppImages have a standard UI. .... AppImages provide proper desktop integration (i.e., there's conventions on how to bundle icons, AppStream metadata, desktop files, ...),

This is a pure Java app that uses a cross platform windowing toolkit.

(These are general comments by the way, I don't know BiglyBT. I was pointed here by someone on IRC to lift a few secrets on AppImage.)

Using AppImage would literally just mean the user doesn't need sudo to install BiglyBT, which isn't a hard requirement anyway.

Maybe we should stop hijacking this thread and move discussion to elsewhere 😁?

[philipzae]

You can meet TheAssassin on the #appimage IRC channel on freenode.

[AmyMoriyama]

AppImage support would be great for one main reason, portability.

You can dump an AppImage on a USB stick and it will run. You can move it here and move it there and it still works. However, to be really portable, the app needs an argument to specify where to store settings and such at minimum.

[Natekmbowie]

I came here to suggest the same thing, but figured I'd add my two cents. I was able to point the PKG to AppImage Tool to the universal installer and generate one myself for my personal use. Aside from auto updates prompting but not working, it works great; especially on my Chromebook running Debian since I can run it 100% off removable storage. I personally think it's cool and might be a useful installation option to have.

[hbednar]

@Natekmbowie

I came here to suggest the same thing, but figured I'd add my two cents. I was able to point the PKG to AppImage Tool to the universal installer and generate one myself for my personal use. Aside from auto updates prompting but not working, it works great; especially on my Chromebook running Debian since I can run it 100% off removable storage. I personally think it's cool and might be a useful installation option to have.

Are you able to provide a pr for this.

[Natekmbowie]

@Natekmbowie

I came here to suggest the same thing, but figured I'd add my two cents. I was able to point the PKG to AppImage Tool to the universal installer and generate one myself for my personal use. Aside from auto updates prompting but not working, it works great; especially on my Chromebook running Debian since I can run it 100% off removable storage. I personally think it's cool and might be a useful installation option to have.

Are you able to provide a pr for this.

Sorry I missed your reply until now. I'm not sure if a pull request would be to applicable only because the PKG to app image tool pretty much just takes the existing code and bundle it all up with a custom .desktop file.

I'm missing my computer at the moment but should be able to share the script soon if you want

[parg]

Closing this as it isn't something that BiglyBT dev is going to work on.