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.

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.

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.