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.
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.
sshfs and tailscale didn’t work for me there.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.
Any program that takes in input has a greater chance of bugs that may result in security vulnerabilities. And I should hope that a text editor can take inputs…
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.