Be aware the sandbox of flatpak is not safe for web browsers, specially firefox based browsers:

https://seirdy.one/notes/2022/06/12/flatpak-and-web-browsers/

https://librewolf.net/installation/linux/#security

https://github.com/uazo/cromite/issues/1053#issuecomment-2191794660

omg I cannot fucking believe that while I was typing this I just saw another distro package nonsense:

There is this very good tool called soar which I use for static binaries. (It also has support for appimages but to be honest it is not as good as AM rn).

Well we just got a complain that fastfetch is not displaying the package count of soar, which fastfetch is able to do.

Turns out this is because the archlinux package is built without SQLITE3 which is needed for that feature to work 😫

And what’s worse is that account registrations are disabled in the archlinux gitlab, so I have to jump thru some hoops to get a basic bug report filed…

I want full-scale applications that are so big they have to use system libraries to keep their disk size down

Linux is in such sad state that dynamic linking is abused to the point that it actually increases the storage usage. Just to name a few examples I know:

most distros ship a full blown libLLVM.so, this library is a massive monolith used for a bunch of stuff, it is also used for compiling and here comes the issue, by default distros build this lib with support for the following targets:

-- Targeting AArch64
-- Targeting AMDGPU
-- Targeting ARM
-- Targeting AVR
-- Targeting BPF
-- Targeting Hexagon
-- Targeting Lanai
-- Targeting LoongArch
-- Targeting Mips
-- Targeting MSP430
-- Targeting NVPTX
-- Targeting PowerPC
-- Targeting RISCV
-- Targeting Sparc
-- Targeting SystemZ
-- Targeting VE
-- Targeting WebAssembly
-- Targeting X86
-- Targeting XCore

Gentoo used to offer you the option to limit the targets and make libLLVM.so much smaller, but now rust applications that link to llvm have issues with this with caused them to remove that feature…

Another is libicudata, that’s a 30 MiB lib that all GTK applications end up linking to for nothing, because it is a dependency of libxml2, which distros override to build with icu support (by default this lib does not link to libicudata) and what’s more sad is that the depenency to libxml2 comes because of transitive dependency to libappstream, yes that appstream that I don’t even know why most applications would need to link to this.

And then there is archlinux that for some reason builds libopus to be 5 MiB when most other distros have this lib <500 KiB

Sure dynamic linking in the case of something like the coreutils, where you are going to have a bunch of small binaries makes sense, except you now have stuff like busybox which is a single static bin that acts as each of the different tools by checking the name of the symlink that launched it and it is very tiny at 1 MiB and it provides all your basic unix tools including a very good shell.

Even Linus was surprised by how much dynamic linking is abused today: https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/

To pick how I’m going to install something,

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

I have all these applications using 3.2 GIB of storage while the flatpak equivalent actually uses 14 GiB 💀: https://i.imgur.com/lvxjkTI.png

flatpak is actually sold on the idea that shared dependencies are good, you have flatpak runtimes and different flatpaks can share, the problem here is that those runtimes are huge on their own, the gnome runtime is like 2.5 GiB which is very close to all those 57 applications I have as appimage and static binaries.

but it doesn’t actually make it easier for me, it just makes it easier for the packager of the software

Well I no longer have to worry about the following issue:

• My application breaking because of a distro update, I actually now package kdeconnect as an appimage because a while ago it was broken for 2 months on archlinux. The only app I heavily rely from my distro now is distrobox.

• I also get the latest updates and fixes as soon as upstream releases a new update, with distro packaging you are waiting a week at best to get updates. And I also heard some horror stories before from a dev where they were told that they had to wait to push an update for their distro package and the only way to speed it up was if it was a security fix.

• And not only you have to make sure the app is available in your distro packages, you also have to make sure it is not abandoned, I had this issue with voidlinux when I discovered the deadbeef package was insanely out of date.

• Another issue I have with distro packages in general is that everything needs elevated rights to be installed, I actually often hear this complains from linux newbies that they need to type sudo for everything and it doesn’t have to be this way, AM itself can be installed as appman which makes it able to work on your HOME with all its features. And you can take your HOME and drop it in any other distro and be ready to go as well.

AppImage is meant to be updated using the embedded zsync info the runtime, that is the user should never have to open the app to update it.

The user needs to have something like AM, appimagelauncher or appimaged that is then able to parse the info and update the appimages using appimageupdatetool

This method also provides delta updates, meaning it doesn’t download the entire app but only a diff, see this test with CPU-X where it downloaded 2.65 MiB to update the app:

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

AppImage is meant to be updated using the embedded zsync info the runtime, that is the user should never have to open the app to update it.

The user needs to have something like AM, appimagelauncher or appimaged that is then able to parse the info and update the appimages using appimageupdatetool

This method also provides delta updates, meaning it doesn’t download the entire app but only a diff, see this test with CPU-X where it downloaded 2.65 MiB to update the app:

appimaged does exactly that automatically for you.

see: https://streamable.com/dm575h

With that said I prefer AM, because it also adds the applications to PATH, meaning you type yuzu on the terminal and it launches yuzu as well.

Or even just Flatpak.

AM was started because flatpak sucks.

• With flatpak devs can’t agree to use a common runtime, so the user ends up with a bunch of different runtimes and even EOL versions of the same runtime, making the storage usage 5x more than the appimage equivalent and this is much worse if you use nvidia which flatpak will download the entire nvidia driver again.

• flatpak could not bother to fix the hardcoded ~/.var directory, something that AM fixes by simply bind mounting the existing application config/data files to their respective places when sandboxing which yes it is able to sandbox appimages with aisap (bubblewrap).

• flatpak threw the mess of handling conflicting applications to the user, so you have to type nonsense like flatpak run io.github.ungoogled_software.ungoogled_chromium, AM just puts the app to PATH like everyone else does, even snap doesn’t have this issue.

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

AppImage isn’t a good comparison for a lot of different reasons

Alright what does flatpak offer in this case?

• Has performance issues 1

• The thing is not XDG Base dir compliant 1 2

• Has security issues even 1 2 3 and not to mention the whole bunch of flatpaks that use EOL runtimes which are even worse, not only for security, but also because that single flatpak ends up pulling an entire runtime for itself which makes even more bloated.

• And is insanely bloated as you saw already.

I think enough people have summarised that on the internet by now.

Such as? but I likely know already what is going to be said, hopefully is none of the following:

• “Depends on libfuse2” (not true since 2022 with the static appimage runtime, this also allows making appimages that work on musl systems, which several like ghostty, goverlay, Steam, gimp, cromite, citron already do)

• “You need to build on an old distro and it is hard”, once again not true anymore since you can now bundle the glibc as well (and it is needed for appimages to work on musl systems).

• “No wayland”, this is only true if you use linuxdeploy-qt to make the AppImage, the project has been abandoned already for several years and the only project I know that still uses it is qbittorrent-enhanced.

EDIT: And also hopefully you are aware that a lot of flatpaks are literary an AppImage shipped in a flatpak runtime, like:

• https://github.com/flathub/dev.vencord.Vesktop/blob/master/dev.vencord.Vesktop.yml#L34-L46

• https://github.com/flathub/com.ultimaker.cura/blob/master/com.ultimaker.cura.yml#L24-L44

• https://github.com/flathub/xyz.armcord.ArmCord/blob/master/xyz.armcord.ArmCord.yml#L40-L43

• https://github.com/flathub/com.heroicgameslauncher.hgl/blob/master/com.heroicgameslauncher.hgl.yml#L191-L196

• https://github.com/flathub/chat.simplex.simplex/blob/master/chat.simplex.simplex.yml#L22-L31

• https://github.com/flathub/menu.kando.Kando/blob/master/menu.kando.Kando.yml#L33-L40

So yeah AppImage isn’t ideal, lets ship it in a container anyway 😁

and through deduplication between different runtimes and runtime versions. There’s usually very little bloat, if any, especially if you use Flatpaks a lot,

~20 different GUI applications, flatpak ended up using 14 GiB of storage while the appimage equivalent used 3.2 GIB.

And note I was not able to find flatpaks for ghostty, goverlay, kdeconnect and a few other apps, meaning the actual bloat of flatpak is even higher.

Edit: And this is even worse if you are an nvidia user, flatpak will download the entire nvidia driver as well.

Unfortunately because PopOS is based on debian/ubuntu, they tend to split packages into a million pieces, so something that would have a simple pacman -Syu mesa vulkan-radeon on archlinux to get the video drivers is like 6 different packages on debian which I don’t know the names of.

Fedora is the testing ground of red hat, they are known for pushing a lot of breaking changes constantly, even more than Archlinux or other rolling release distros. A while back they pulled this nonsense that we had to deal with that not even upstream approves of.

So my only distro recommendation is archlinux or some archlinux fork, every time I have had to help people with distro issues they all eventually ended up in arch because all other distros have some weird issue that’s a deal breaker. Just don’t rely too much on the Aur.

My other suggestion is that you get most of your software as appimage thru AM: https://github.com/ivan-hc/AM

We ship Steam as an AppImage with a lot of common fixes that affect the flatpak version or native versions of steam (you can check them in the readme), and you don’t have to deal with the hassle of setting up the 32bit repo and installing Steam for example.

Processes are still isolated through nested seccomp filters.

You don’t have namespaces still…

For reference, chromium will not launch without that, you have to pass the --no-sandbox flag and brave iirc disabled that all together.

Not really an issue with chromium because you do have working namespaces sandbox thru zypack, although some disagree that this is safe

Would highly recommend against anything that “updates itself.”

Disable the self updates in that case… before you were saying that AppImages had no way to self update and now are saying that you don’t recommend it?

You want someone in the stream to do some sort of validation.

Also what validation are we talking about? the one that flathub does? The most you will get is recognizing that the application comes from upstream, you can even ship pre-compiled binaries thru flathub.

There is a reason we use centralized management.

Such as?

EDIT:

I also don’t want every app trying to check for updates.

With AppImage you have this outside the application thru the zsync delta updates, the info is embedded in the appimage and it is checked by appimageupdatetool, appimagelauncher, and similar and let you know when there is an update available without the application itself doing the check.

Thank you, it seems every way I go i make the wrong choice lol

Welcome to linux.

What you were told about appimage depending on legacy stuff is also not true, it is the libfuse2 dependency, which hasn’t been a dependency of AppImage for 3 years (though some projects haven’t updated yet).

It also isn’t a big deal if you run into an appimage that still depends on it, archlinux which is a rolling release distro, some of its packages like mtpfs and ntfs-3g still depend on libfuse2 as well. And you can still run the AppImage by setting the env variable APPIMAGE_EXTRACT_AND_RUN=1 to avoid having to install libfuse2 in those cases.

They are very dated and depend on legacy stuff that often was dropped by the distro

Is it libfuse2? This has no longer been a dependency with the static appimage runtime, which released in 2022!

Although most notable, electron apps still by default use the old runtime, because electron-builder hasn’t updated the appimage runtime.

Besides that AppImage do not depend on legacy stuff.

They are also terrible for security since there is no way of pushing out updates.

This was never true lmao.

Do not use flatpak for firefox based browsers because it breaks it namespaces sandbox.

Firefox releases a portable binary that self updates.

flatpak works by using bubblewrap which creates namespaces for the applications you use, essentially the root gets swapped for a fake root, this is how docker, podman, etc work.

This contradicts their own wiki. Type 2 AppImages do use libfuse2, which is the problem

appimagekit is not actively developed anymore. Development moved to AppImage/appimagetool and type2-runtime

EDIT: Also go-appimage which was the first one to use the static runtime in 2022.

So no, they do not need libfuse2 anymore. Stop saying that nonsense, Download the AppImage of Cemu or PCSX2 or Ryujinx and remove libfuse2 and see for yourself…

Even in the github thread you linked it is said that namespaces are enabled by default in the kernel nowadays

Yeah and ubuntu recently fucked it up with namespaces restrictions.

Docker, where another kernel, package manager etc. gets loaded.

Docker doesn’t load another kernel, no idea if it can either, flatpak is pretty much another package manager as well. By your own definition it is another distro.

However if you want to be taken serious in your criticism please inform yourself on what you’re criticize

they simply don’t fix the libfuse2 issue

Fixed 3 years ago

Neither Flatpak nor Snap run “another distro inside”

The flatpak runtimes are huge and are another distro in practice, just check the contents of the gnome runtime and you will see it is another distro.

Flatpak also depends on namespaces which paranoid distros disable and cause issues. Which the person you responded to talked about it and you ignored all together lol

Xfce is on GTK3 and there are no plans to migrate to GTK4.