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.

MacOS is UNIX, but is not the best implementation of UNIX.

The UNIX tools it ships are extremely old. For example, it comes with GNU Screen, which I was using but was having same strange issues with. It turned out it uses a version from 2006… so I had to brew install a modern version.

And I’m personally not the biggest fan of MacOS. It’s certainly better than Windows thanks to Apple mostly treating the user with basic respect (no ads), but the desktop/window manager is just super quirky. No other desktop, whether it be Windows or any desktop on Linux behaves quite like it. They tend to only adopt the nicer features while keeping a UX that feels closer to Windows. For example, MacOS quirky/unique in doing

• Requiring a click to activate a window (with no option to change this behavior)
• Fullscreening a window moves it to its own space
• Closing an app’s window does not close the app itself for the majority of apps
  • Perhaps not the biggest deal if the goal is app startup speed for heavily used apps, but unnecessary for rarely used apps and clutters the dock)
  • Also can be quite annoying since it will drag you to the last space you used the app on
• Minimized windows show on dock as previews
  • Not that of an idea, but strange since you now have two ways to bring the app back: clicking on the app icon itself or the minimized preview

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.

Packagekit mainly.

It also helps if you just focus on a single package format. The Snap Store’s performance is great, though I have seen some baffling QA issues with it (like categories showing up like “Devel…”). There’s also that store that Universal Blue is pushing, forget what it’s called.

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.

Pixels have better security features than Samsung and doesn’t prevent you from using third party OSes.

More details here: https://grapheneos.org/faq#recommended-devices

My real surprise is that this supports Linux and more specifically Wayland.

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.