I’m curious, what makes AppImage a good choice for the lazy developer? Is it easier to create?

The appimage is basically just git clone -> make -> make install DESTDIR=/path/to/AppDir -> wget appimagecreationtool and finally appimagecreationtool /path/to/AppDir and that’s it you have your appimage.

appimagecreationtool being several tools that can create the appimage from an AppDir, like linuxdeploy, linuxdeploqt, go-appimage, etc

And that on itself isn’t complex either, it if basically running ldd on the binary, then copy those libraries into the AppDir and finally run patchelf to patch the paths in the binaries and libraries, suyu uses a deploy script instead of using those tools, which I’ve recently forked and began expanding.

I don’t know how easy it is to make a flatpak or snap, but I do know the dev of zen browser hates dealing with the flatpak and iirc right now the flatpak is outdated as result.

EDIT: Also lite-xl has been making a flatpak for like 2 years and it isn’t ready yet.

Glad you like AM.

. If you end up with 4.7GB for runtimes, that’s basically nothing these days

Yes but that wasn’t the original comment I replied to was about.

163 flatpaks and the runtimes used 8.7GB

163 flatpaks using 8.7 GiB means that the average flatpak is using 54.6 MiB.

That’s good the other time I got this linked: https://tesk.page/2023/06/04/response-to-developers-are-lazy-thus-flatpak/#but-flatpaks-are-easier-for-end-users

Which is no good as in that example there was 173 flatpaks using 27.66 GiB, average 160 MiB, while in your case the average flatpak is using 91 MiB.

This is what I have with appimages:

In this case the average appimage is using 69 MiB, though there is one outliner which is the Steam appimage that I have there (470 MiB) which is an entire conty container with its own video drivers and everything, without it the average would be 56 MiB.

I know this doesn’t matter these days but once again that wasn’t what the original comment was about.

Well we are talking about two gigs, after all. Unless you’re using an embedded system, it’s not a much of a concern if you ask me. But it is more, true

Thanks for the link showing an average flatpak using 54 MiB though, didn’t think it was possible lol.

WAIT I just took a deeper look at the link, isn’t that guy just showing the runtimes without the applications using 8.7 GiB?

I tested installing some web browers, kdenlive, yuzu and libreoffice and without knowing I ended up with 3 different runtimes and the total storage usage (with deduplication) was 4.79 GIB.

Meanwhile with 33 appimages that I have (which includes same flatpak apps I mentioned) are using 2.2 GiB.

It doesn’t matter if they share if in the end they end up using several times more storage than the appimage equivalent.

Isn’t the gnome runtime alone 2GiB? You know how many appimages that is?

Not to mention you are unlikely to only use one runtime.

I’m pretty sure sbin originally meant static binaries and not system binaries lol

it may have the same problem.

It actually doesn’t! it works thank you!

Btw when I have multiple tabs on the vomnibar, if I scroll down the list using the arrow keys it doesn’t change to the next page, I instead have to use the mouse wheel to move to the next page, is there a way I can fix that?

Is there an easy way to migrate my vimium conf to it?

Also are you sure that it displays the page icon in the active tabs menu?

posix sh + awk for manipulating data?

It makes me mad to see the current state sway is in, I even bought an AMD GPU for nothing.

Speaking of doas, is there any advantage of using it when… sudo is still available to be used?

I like that its configuration file is very very simple.

Yeah I meant this: https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin

Alpine still keeps /bin and /usr/bin separated.

And iirc the next fedora release will finally unify everything under /usr/bin.

https://github.com/mgord9518/aisap/blob/main/profiles/profile_database.json

Very interesting tool. So this is for appimages but also binaries?

Anything portable.

Thats not a sandbox, its a nice wrapper for firejail,

aisap uses bwrap it is mentioned in both links I gave you.

appman used to have firejail sandbox but it was dropped in favor of aisap because of that.

Are all Appimages using that, if not what percentage of the ones you know?

Usually if the appimage has a github release with a zsync you have that verification.

And are tools like Gearlever enforcing or using that signature check?

I don’t use gearlever, as far as I know gearlever doesn’t even let you sandbox the appimage like AM does. I don’t think any of those forces signature verification besides AppImageUpdateTool and that’s because that’s part of the zsync update process.

Running things from random directories (like ~/Applications which AppimagePool uses) destroys that.

~/Applications is no a random place, it comes from macos. And what is appimagepool?

You mean appimagetool? that’s used to turn the AppDir into an appimage.

If you meant appimagelauncher, ~/Applications is the default location but it can be changed to any location.

(including appimages which are nearly impossible to sandbox)

See that lock next to some appimages? Yes that’s aisap sandbox..

It isn’t perfect though, right now its biggest limitation is that a sandboxed appimage can’t launch another sandboxed appimage. But dbus, pipewire, vulkan, themes, etc works.

The “open with” and “create new” things. Actually,

You can totally do that with appimages once they are integrated into the system by the previously mentioned tools, those menus rely on desktop entries in $XDG_DATA_HOME/Applications.

That concept is so broken that it needs to go.

Good thing we have choices on linux, you can make your entire home not executable if you want to.

I like to keep all the software that I need in my home, because that way I don’t depend on what my distro provides. I can just drop my home anywhere (besides a musl distro) and I’m ready to go, I even have my window manager as an appimage because I couldn’t compile it statically.

But the issue is that they were just thrown out there, “here devs, do the same shit you do on Windows, it is totally normal for people to double click an executable, not have any sandboxing, deal with updates on their own, dont have any cryptographic verification, …”.

AppImage is just a format, same as a deb or rpm, you decide how you handle it afterwards.

doing the actual update process (instead of deleting a file and placing a new one)

Same link again: https://github.com/AppImageCommunity/AppImageUpdate

Many of the appimage devs actually worked on making zsync2 for this: https://github.com/AppImageCommunity/zsync2

On Android you still have a package manager but the APKs are signed individually, updates just allowed if the signatures match. So you can sideload how you want, it is still secure.

You mean the APK itself does the signature verification or what? With appimage it is AppImageUpdateTool that does the verification.

(appimages are impossible to sandbox with bubblewrap, and hard with firejail (which is a setuid binary and had security issues), dont know about nsjail, crabjail, minijail or others)

Again this nonsense.

Regarding what?

You still have that github repo saying that appimages bloat the system when that is a total lie. they can even use less storage than native packages let alone comparing it to flatpak…

But they dont have installers, so no verification

https://lemmy.ml/post/17283790/11897811

on Linux the entire home is executable which is a huge security issue

You still have to give the exec permission to the appimage.

no desktop integration, no context menu, no file associations.

Maybe no context menu depending on what you mean exactly, but the rest are fully possible and I do it on a regular basics with my appimages…

edit: Omg you are the guy from don’t use appimages, I see you haven’t changed one bit.

And Windows executables have some weird signature verification which Appimages dont have at all.

…

EDIT:

Appimages have no install wizard.

Appimagelauncher, gearlever, AM, etc. Which is the same as a install wizard since it integrates the appimage into the system. AppImages do not need to be extracted into the system which is what windows install wizards do.

What happened to just donwload the app from it’s own creator and install on your machine?

You have that option with the appimage, inkscape releases it themselves.