SamueruSama

joined 2 months ago
[–] SamueruSama@programming.dev 1 points 18 hours ago* (last edited 18 hours ago)

AM doesn't unpack appimages.

It places them into a dedicated directory in ~/Applications if you didn't choose a install path, but the file is still the same appimage without the .AppImage extension.

Where are discussions/forums about aminstaler?

https://github.com/ivan-hc/AM/discussions

[–] SamueruSama@programming.dev 2 points 2 days ago (3 children)

https://github.com/Shikakiben/AM-GUI

It was recently tested on postmarketOS here btw

[–] SamueruSama@programming.dev 1 points 3 days ago (1 children)

I’m just curious how you think this would have happened.

because unless you went out of your way to build appimage luancher or install the nightly releases you would have run into that problem.

That problem was serious enough that we had to add a warning to all of our appimage repos to give you an idea. lsfg-vk even had it happen several times in 2025 💀

And note removing/updating appimage launcher wasn't enough, you also had to reboot, because the thing had a daemon with a binfmt rule that would still prevent you from launching appimages.

In any case you were dismissive in your first message and really negative about software that works fine for me,

I'm very sorry, I thought you were responding to this message about AppManager hence my tone.

AppManager is good.


If you wonder why AppImage had to update the appimage runtime, that is because the static runtime removed the libfuse2 dependency, which was a huge issue appimage had for a long time and to this day I still see people claim this is still a problem. It resulted in that mess with AppImageLauncher unfortunately.

[–] SamueruSama@programming.dev 1 points 3 days ago (3 children)

All I know is appImageLauncher gave me a lot of issues so as soon as I found an alternative I tried it and haven’t had an issue yet.

You likely ran an outdated version of appimagelauncher.

appimagelauncher for broken for several years when the static appimage runtime came up, the stable release didn't support it. So it would cause people to not be able to launch appimages at all.

It was fixed in the nightly releases but most people had no idea about that.

But anyways appimagelauncher right now does not support DWARFS as well, so it is not able to integrate other appimages. So do not go back to appimagelauncher.

Edit: apparently having an experience gets a downvote. Pretty whiny and weird thing to do.

Just in case it is not me that downvoted you lol

https://imgur.com/a/CsaQBbG

[–] SamueruSama@programming.dev 1 points 5 days ago

Don't run electron/chromium apps with --no-sandbox, that is not safe, you are exposing yourself to the internet.

Canonical decided on ubuntu 24.04 to disable unpriv namespaces in the name of security, in reality they did it to push snaps since that change breaks appimage and flatpak.

Do what linux mint ended up doing and disable the restriction.

kernel.apparmor_restrict_unprivileged_userns = 0' | sudo tee /etc/sysctl.d/20-fix-namespaces.conf
sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

Or better yet just don't use ubuntu, it is just a source nightmares, the uuttils switch even broke one of my appimages...

[–] SamueruSama@programming.dev 0 points 6 days ago (5 children)

Gearlever doesn't even do delta updates, it downloads the whole appimage with every update, and you often have to manually give it the URL to update the appimage.

It is also a total hack written in python, the dev was even shelling out arch to find the host arch instead of using the built in methods of python...