It turns out the malware doesn't work because it runs subprocess.run(["rm", "-rf", "/*"])

That will never delete anything, since there is no shell to expand the glob in /* here, so rm gets a literal /* as the path to delete 😭

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

It was recently tested on postmarketOS here btw

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 💀

• https://github.com/PancakeTAS/lsfg-vk/discussions/351
• https://github.com/PancakeTAS/lsfg-vk/discussions/336

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.

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

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...

https://github.com/pkgforge-dev/Anylinux-AppImages

Didn't know that measuring and comparing means I'm jumping thru hoops.

If you talking about the infrastructure cost, then yeah it flatpak would be 'better'. since all your users would use the same runtime and you only have to ship the binary.

But this only makes sense for the first time the user downloads the application, because it turns out appimage can do delta updates just like flatpak lol

In practice not even the first point is true btw, a lot of flatpaks often ship bundled in dependencies (due to having compat issues with the flaptak runtime), so the donwload size of the .flatpak alone is similar or bigger than the one of the appimage.

Flatpak makes sense from a bandwidth and storage standpoint for end-users.

While flatpaks "share" dependencies, different flatpaks depend on different flatpak runtimes and even different versions of the same runtime, so it is actually the least efficient way to ship software.

https://pkgforge-dev.github.io/Anylinux-AppImages/disk-usage-vs-flatpak.html

• control + f

• type deadbeef

• 0 results

• close page

heh

This is because flatpak apps depend on flatpak runtimes, so the app will download the entire runtime it needs when you dont have it installed already.

This is bad because a lot of flatpak runtimes like the GNOME runtime only have one year of support, so you blow a lot of storage in practice