New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linux Appimage Support #250
Comments
I am generally support of this idea. |
I dont no if this helps but:
|
Quoting from elsewhere,
|
True, that's entirely intentional. Our concept is simple: one file = one app. No root needed to install or uninstall, management is easy.
That's just nonsense. Nobody forces you to reboot your computer. There's Docker, there's VMs, there's 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.
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).
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 |
I am not an expert on AppImage or Flatpak, so please forgive any misconceptions I have and take the following questions as genuine 🤗.
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?
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.
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:
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.
For all of the linux distros that the application developers are willing to support, right?
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. 🤷 |
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.
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.
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.
That's the worst case. Us programmers tend to think in the big-O notation to express complexity. Worst case for Flatpak runtimes is
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.
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.
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).
The entire idea of AppImage is to not have to ship anything distro-specific. Most AppImages just work on any major distro.
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.
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.) |
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....
But Flatpak was specifically designed to alleviate this particular aspect of dependency hell without having to compromise on security and requiring
Technically speaking, AppImage packaging adds a constant amount of disk-space overhead for each supported distro, which results in 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) 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....
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 if you have to build on each supported distro.... I guess I need to dig into AppImage to really understand the requirements here.
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?
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.
This is a pure Java app that uses a cross platform windowing toolkit.
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 😁? |
You can meet TheAssassin on the #appimage IRC channel on freenode. |
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. |
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 |
Closing this as it isn't something that BiglyBT dev is going to work on. |
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/
The text was updated successfully, but these errors were encountered: