Samueru_sama @ Samueru_sama @programming.dev

Posts

0

Comments

17

Joined

9 mo. ago

Check my dotfiles https://github.com/Samueru-sama/dotfiles

0 hidden files, everything is in ~/Local.

Recently added this hack for ssh: https://github.com/Samueru-sama/dotfiles/commit/7e1f8bd3173da563731aea6db9efbf26a2b23e72

Alright be aware that AM not only can manage appimages, it also manages other portable formats and has access to over a 1000 static binaries from soarpkgs repo.

And it can do all of this at user level when used as appman, that is elevated rights are never needed to install anything and I can just take my HOME and drop it on any distro and be ready to go.

It made me get rid of flatpak all together and become an appimage contributor lol

what

Is topgrade used to update all the package managers at once? how many stuff are you using that you need that???

but I would have expected Fedora to come with something like this preinstalled tbh

Fedora is just plagued with poor decisions, and that's expected, it is the testing ground of redhat and not something that regular users should be using, they even go as far as repacking existing flatpaks just because and then break them.

A while back they pulled this nonsense that not even upstream approves of: https://gitlab.com/gnuwget/wget2/-/issues/661

iirc fedora also enabled wayland by default on gnome in 2016 when pretty much nothing worked.

Rhino linux lets you install AM thru its GUI installer btw.

I'm not, it's a vm that I use to test.

There is quite a lot of systems still stuck on kernel 2.6 that can't be updated, so it is always nice to make sure what I do can work on such.

So, I would say the primary complaint should be a lack of package management.

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

So, I would say the primary complaint should be a lack of package management.

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

it allows the same packages to run on any Linux kernel (any Linux distro). That is pretty useful.

flatpak itself depends on namespaces, so saying that it works on any kernel is quite a stretch.

Can flatpak do this? This is a GIMP3 appimage running on ubuntu 10.04 without any container:

The kernel is so old that even the appimage runtime itself complains of missing functions and has to fallback to a workaround.

UPDATE: flatpak can't work because bubblewrap itself can't:

PR_SET_NO_NEW_PRIVS is only available since kernel 3.5

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

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.

Be aware librewolf and all firefox based browser have security issues with flatpak because flatpak by forcing seccomp filtering breaks the internal sandbox of the browser:

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

Not to mention the librewolf flatpak is literary the portable tarball they release that works on your distro already, in other words it is the worst way possible to use librewolf.

And you only get that "ease of use" of being able to install it in the software store with one click because your distro did the pain of installing and configuring flatpak for you, otherwise it would have been much worse than what you posted.

Anyways, try using appman instead:

wget -q https://raw.githubusercontent.com/ivan-hc/AM/main/AM-INSTALLER && chmod a+x ./AM-INSTALLER && ./AM-INSTALLER

And then: appman -i librewolf which will "install" the AppImage and you can also sandbox it with am --sandbox librewolf and this sandbox does not break the internal sandbox of the browser unlike flatpak.

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.

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