Nobody

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.

That’s unlikely. It’s far more likely that they are at the top simply because they are more popular.

The only exception to this rule is the higher end 13th/14th gen Intel chips, which really do have a crashing problem.

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.

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.