Opinions on AppImage ?

4 respuestas [Último envío]
PublicLewdness
Desconectado/a
se unió: 03/15/2020

I noticed recently with certain software, that wasn't in the Trisquel repo, that it only gets distributed by AppImage on the developer website otherwise. Now I have read quite a bit about a lot of downfalls to FlatPacks and I never trusted Snaps much anyway but I was wondering what some opinions were on AppImages ? Are they any better ?

For reference here is some issues I read about FlatPacks:

https://flatkill.org/2020/

Magic Banana

I am a member!

I am a translator!

Desconectado/a
se unió: 07/24/2010

AppImage is certainly the easiest way to distribute an application having the guarantee that it can:

  • be executed by anybody (no root permission required, no framework either, no decompression, nothing: just execute the AppImage);
  • run on any GNU/Linux distribution (dependencies are included in the AppImage).

You need to trust whoever built the AppImage to not have altered the upstream application (but the upstream developers often build the AppImage themselves), in particular to not have included malware.

chaosmonk

I am a member!

I am a translator!

Desconectado/a
se unió: 07/07/2017

I only occasionally use AppImages, but that fact that they are self contained in a single file and do not need to be installed on the system makes them nice for things like

* running an application that you only want to use once and then discard
* testing a beta version of an application while leaving the stable version unstalled and untouched

For applications that you want to actually install and keep using, AppImages are a little annoying. You have to navigate to and execute it every time you want to use it, rather than launching it like a normal program. It also has a lot of the same problems that Snaps and Flatpaks do. For example, it bundles copies of its dependencies and uses those instead of your distro's system libs. When your distro ships a security update to one of those dependencies, the bundled copy does not get patched.

Why are the applications that you want not available in Trisquel? If it is because they are proprietary or have dependencies like Electron that are difficult to package, consider alternative software if any exists. If it is because Trisquel is so out-of-date, consider using Debian main. If Trisquel's out-of-date packages are leading you to frequently go out-of-repo, then it doesn't really matter so much that Trisquel's repo only contains FSDG software, since it's no longer your go-to source for installing stuff. This outweighs the minor freedom differences between Debian main and Trisquel.

PublicLewdness
Desconectado/a
se unió: 03/15/2020

"Why are the applications that you want not available in Trisquel? If it is because they are proprietary or have dependencies like Electron that are difficult to package, consider alternative software if any exists. If it is because Trisquel is so out-of-date, consider using Debian main. If Trisquel's out-of-date packages are leading you to frequently go out-of-repo, then it doesn't really matter so much that Trisquel's repo only contains FSDG software, since it's no longer your go-to source for installing stuff. This outweighs the minor freedom differences between Debian main and Trisquel."

I can't speak for why they aren't in the repo. Etcher is made with Electron (as well as other things I think). Nextcloud is written in PHP and Javascript. I'm not sure what Session-Messenger is written in. Turns out that Nextcloud has a PPA on their site for Ubuntu based distros so I can sue that over App Image.

chaosmonk

I am a member!

I am a translator!

Desconectado/a
se unió: 07/07/2017

> Etcher is made with Electron

Electron has a ways to go before it can be packaged properly in Debian based distros (and generally results in crappy applications).

> Nextcloud is written in PHP and Javascript.

Are you referring to the server side code, or the desktop client? The desktop client is in Debian/Ubuntu, but won't be in Trisquel until Trisquel 10. The server side code has not been packaged. It would seem odd to use AppImage on a server though. Maybe people do that, it's just never occured to me as a good use case for AppImage.

> I'm not sure what Session-Messenger is written in.

It doesn't matter what language it's written in, as long as it's a language that can be packaged in free distros. However, Session-Messenger appears to depend on Electron. I only use Electron applications as a last resort when there is no free alternative that's an actual desktop app and not a shitty webapp wrapped in Chromium.