Haven’t done it personally, but I think Ubuntu would be one of the better choices. You get the Ubuntu ARM debs and ARM snaps out of the box.

You can then install Flathub and Fedora Flatpaks.

Fedora Flatapks is small and not without controversy, but one of its benefits is that all of its packages are built for ARM. Flathub and Snap aren’t consistent in doing that. Any many times you’ll find that Snap has an ARM build and Flathub doesn’t, and vice versa.

It certainly has it’s issues. Takes up quite a bit of space since each app tends ships its own copy of electron (though distros like Arch do try to make apps share a single Electron build). Apps may ship out of date versions that may have security vulnerabilities, though it’s not always the end of the world since they tend not to access outside of their own domains. As for slowness and resource usages, it’s bit of a tricky subject; an Electron app can be optimized, but will always use quite a bit of RAM.

Though undeniably they have been beneficial for Linux if only because it allows some companies to support Linux without too much extra work.

SSD is still supported, just tested Spotify and Flathub’s Electron test app in a VM with Plasma.

That’s misleading, there was a significant outlier. Gnome was on average slower, but not that much slower.

And with community maintained distros like Debian and Fedora, you kinda get the best of both worlds. You have a mostly community distro that doesn’t have corporate interests pushed on it, but have a corporation paying developers to work on it because it’s in their interest to.

Though unlike Gnome Web, this the performance is actually good despite being an early beta.

The scrolling performance using a mouse in Gnome Web just sucks, it’s choppy and inconsistent. Though it does feel okay when using a touchpad.

I’m looking through Gear Lever and don’t see anything. I only see the option to change the path where there actual Appimages are stored, not the data created by the appimages.

I see two options.

The simpler of which is to have a wrapper script that says HOME=/custom/path/for/appimage. Apps that correctly follow xdg-specs will then put all their data in that path. But not all apps will. Apps that put stuff in /home/$USER will not use the correct location.

The more foolproof way would be using something like bubblewrap, which is used by flatpak. With bubblewrap, the sandboxing can make /home/$USER appear as /custom/path/for/appimage. However, this would take more work to setup, since I presume you want the appimages to feel unsandboxed.

That doesn’t solve the issue of keeping data in a specified directory.

Flatpak cannot access the host GPU drivers, so there are runtimes for NVIDIA drivers.

What they are referring to is that the driver version on the host must match the driver version installed as a flatpak runtime. Otherwise, you may get graphical issues and crashes.

It doesn’t work better or worse on Ubuntu. The fact it (partially) uses Ubuntu libraries matters very little given that the libraries are 14 years old… But I think the client now mostly relies on Debian 12 libraries to run since a year or two ago.

In this case, the DE is the main cause of issue, not the distro base.

That was a combination of the Steam client being a piece of trash (incredible complexity and technical debt*) and COSMIC. COSMIC is quite buggy when it comes to Xwayland. I’ve had plenty of issues where I close a Xwayland window, but a ghost of the window remains.

• the Steam Client runs on a combination of Ubuntu 12.04 LTS and Debian 12 libraries. It has a combination of their old VGUI code and newer Chromium GUI. It remains 32-bit and only supports X11.

It’s right. While Fedora is a community project, Red Hat does hold a special place in it as its corporate sponsor. For example, the Fedora Project Leader position must be held by a Red Hat employee.

Arch is quite an old distro and extremely popular. Valve could have chosen any distro, but settled on Arch.

I’m saying that we should be able to use package managers like DNF similarly to homebrew. Rather than managing system packages, it would only be used for packages the user installs. Whether it installs them into /usr/local, /home/dnf, ~/.local/bin doesn’t matter. All that matters is that it’s not managing system packages or mixing system-installed/user-installed packages.

Homebrew isn’t perfect. Awhile ago I tried to go all homebrew for my packages, but sshfs ended up not working (maybe a SELinux issue?). So I had to fallback to overlaying the package. Simiarly, I tried to install tailscale from brew, couldn’t get it to work.

It’s just that in “immutable” (I know how much you hate the term lol), there’s package manager fatigue.

• There’s flatpak, which is only meant for GUI apps but for certain GUI apps (like IDEs), it’s not good.
• There’s distrobox, which works for both GUI and CLI, but it adds some friction and sometimes the containerization breaks certain functionality.
• Brew largely avoids the issues of distrobox and works for GUI and CLI, but the GUI app selection is limited and as I mentioned, sshfs and tailscale didn’t work for me there.
• And so to work around the issues of those 3, we get yet another way to install packages (systemd system extensions
• (and of course that’s not even speaking of snap, appimage, cpak, unpackaged apps, etc)

My thesis is essentially that we’re creating too many package package managers with too many compromises. Traditional package management is far from perfect, but at least those package managers, you can do essentially anything. Brew could be that, if it had more GUI apps and maybe better SELinux integration (I say that not knowing for 100% sure that SELinux was the cause of my sshfs issuse). I would like for people to take a step back and find simpler solutions, make a single package manager that can handle any kind of package.

Edit: correction, tested again and sshfs is actually working, not sure what was causing the original issue. though I still have sshfs overlayed, maybe that provides some necessary dependency or SELinux tweak?

Edit 2: after removing the sshfs overlay, the sshfs brew package also stops working, so it seems like some host configuration is needed for the brew version to work.

So if i were to “sudo dnf install neovim” on Bluefin, that would install Neovim to ~/.local/bin?

I didn’t mean to say that Universal Blue specifically was making new package managers, but that in general new package managers have been created specifically to solve problems introduced by going immutable/atomic/image-based/whatever.

We are discussing immutable distros, where you don’t have apt/dnf/guix/whatever installed on the host system. They are replaced with other package managers. On Ubuntu Core, that is snap. On Fedora Atomic, that is rpm-ostree, flatpak, and toolbox.

MacOS is immutable, there is no non-immutable version.

MacOS’s has been immutable for a while now. But that’s not what I was referring to. Homebrew also works on Linux, lots of CLI tools and libraries are available there. It does have some GUI apps, but not as many packaged as for MacOS.

That’s not the reason. On immutable distros, you can still mess up your flatpak packages, distrobox containers, homebrew packages, etc.

Only “OS” files like those in /bin prevent accidental modification and removal since you cannot directly change them, even with root.

It’s not how you “generally” do it because many immutable distro developers keep developing additional ways to do package management that are more and more complicated.

I still don’t get why we can’t have a BSD like approach. Make usr, bin, sbin read-only. But have /usr/local be writable and have a traditional package manager install to that location instead.