Timothée Besset, a software engineer who works on the Steam client for Valve, took to Mastodon this week to reveal: “Valve is seeing an increasing number of bug reports for issues caused by Canonical’s repackaging of the Steam client through snap”.
“We are not involved with the snap repackaging. It has a lot of issues”, Besset adds, noting that “the best way to install Steam on Debian and derivative operating systems is to […] use the official .deb”.
Those who don’t want to use the official Deb package are instead asked to ‘consider the Flatpak version’ — though like Canonical’s Steam snap the Steam Flatpak is also unofficial, and no directly supported by Valve.
I know the “Arch BTW” meme exists for a reason, but one of the reasons I haven’t been able to drag myself away from Arch-based distros in recent years is that it allows me to always have current versions of my software while also just not having to care about all this appimage/flatpak/snap brouhaha.
I guess it’s somewhat of a “pick your poison” kind of situation, but I find dealing with the typical complaints about Arch based distros to be both less of a problem than detractors would have you believe, and less of a headache than having to pick one of three competing alternative packaging approaches, or worse, to use a mix of them all. Standing on the sidelines of the topic it seems like a small number of people really like that these options exist, and I’m happy for those people. But mostly I’m grateful that I don’t have to care about this kind of thing.
Edited to add: Seeing how this thread has developed in the past 5 hours convinces me anew that “on the sidelines” is where I want to stay on this topic. 😁
I’ve always found the most time consuming thing about arch is having to spend half your life telling everyone you use it.
Nah, it’s repeating the installation process until you finally get enough stuff working to have internet, and then you can bootstrap installing every other bit of software that you need. Thank goodness for rolling release - I can’t imagine having to go through that again.
You can install Arch directly from a UEFI shell over the Internet: https://archlinux.org/releng/netboot/
If your BIOS has a UEFI shell that supports DHCP, HTTP and IPv4 PXE you can load the ipxe-arch.efi over HTTP and start installing.
Does UEFI shell have wget?
The important question is if the UEFI shell can run Doom.
Of course it can. What did you expect?
https://doomwiki.org/wiki/Doom_UEFI
Depends on the version. All of them (the newer ones with networking) have TFTP. Some even have HTTPS. I think HP Servers even have HTTPS-Boot with client TLS certificates.
None of it works with Wifi though. iPXE has wifi support for some devices but you obviously can’t start it over the Internet. You need to flash a ROM you don’t need or use a USB drive to load it. Then you can boot Linux from the Internet. (That also works if you don’t have a UEFI Shell in BIOS). https://netboot.xyz can also boot other OSes than Arch.
I haven’t done a vanilla arch install for years either, because if that sort of thing is fun for some folks great, but it was only fun once or twice for me. I think a lot of the vanilla arch faithful end up scripting it for fresh installs.
But, FWIW there’s always endeavouros, manjaro, and I’m sure other Arch derivatives I’ve forgotten about. I just did an endeavouros install on new hardware I was given last weekend, and it’s certainly no harder to install than Ubuntu.
I haven’t used it in years, so hard to remember now.
I was like you using arch packages for everything until ferdium was hit by a terrible bug that broke its zoom function and wont be fixed in months since it is an issue with electron. Now I use the appimage version of it to downgrade to an older version.
And then there are the rust programs that you can only find as aur git packages which means installing a bunch of dependencies and all the crap that cargo puts into my home dir just to build one binary, for that I just instead take the appimage version or sometimes the binary if they release it and place it in ~/.local/bin.
Another good thing is that the appimages get compressed and take less disk space, for example the libreoffice package in arch is 600 MiB while the appimage is 300 MiB.
And the great thing is that I can just drop my homedir into any distro and as long as I make sure that fuse is installed everything will work out of the box.
It sounds like NixOS would solve all your problems. And it makes coffee too!
Still figuring out Nix for my daily driver (too many fun customizations moving away from gnome), but love it so far and built my last self-hosted box with it. So easy to redeploy after the initial learning curve. Boot from ISO, partition with disko, upload SSH key to decrypt sops, install.
Oh and since practically everything can be overridden, its easy to get bleeding edge using existing packages!
Nix is objectively a bad language. Glancing past the syntax (which is atrocious and the parser is completely unhelpful) it’s just a bad idea to mix lazy evaluation and dynamic typing, the only way to get understandable error messages with nix is to put asserts all over the place, hoping one of them gets triggered by the evaluator.
That said I still love the system to bits and fixing the language actually wouldn’t be that hard: Add static typing, with inference most stuff should just run as-is. Exception are the two or three uses of the y-combinator (yes, seriously, that’s how you recurse in nix) deep in the bowels of nixpkgs, e.g. during stdenv bootstrap. Just make
fixa primitive, or maybe a plain fold I don’t think nix even needs to be Turing-complete. Reason it’s not being done is that there’s enough other stuff to work on and, well, Stockholm syndrome. Good news: Nix doesn’t support constructing import paths dynamically, that would have been a nightmare to sort out in a static setting.I don’t mind most of the language having FP experience, but I agree the lack of static typing just sucks. I’m using the repl a lot to try and track down why things aren’t aligning quite right when trying different techniques to keep things DRY and organized. Documentation is also a headache as a newb with the multiple ways of structuring a repo while trying to grok all the implicits and how it all gets merged.
Is NixOS xdg base dir compliant? that is one of the reasons I don’t use flatpak.
Yes, all the environment variables are set automatically and programs respect them.
Yup, the AUR is a godsend. I barely touch the other methods and only use AppImages when I’m too lazy.
Appimages when you’re lazy? The fact you have to chmod them is annoying compared to an AUR helper
I mean Dolphin gives a prompt for the same thing when I launch it.
100% all this. Canonical has been pushing snaps for awhile, and I wonder if the 12 year LTS for Ubuntu is part of that strategy - want something newer? It’s in the snap store. snap is terrible, worse than flakpak and appimage - but just as you say, as an arch user I don’t have to care. Whatever I want is probably in the AUR if not the main repos. Rolling distros, done right (arch), are an amazing experience.
I think if we could drag users (at least gamers) away from these Debian/Ubuntu based distros we could have developers just shipping packages that wouldn’t need to be compatible with some ancient LTS library release, and maybe we wouldn’t need appimage/flatpak/snap at all anymore (or at least only in rare cases).
From my perspective as someone who is both getting into gaming on Linux and also not much of a power user, Arch would have to make the installation and maintenance process a lot simpler to attract more people, and I’m not sure that’s something they actually want to do.
Looking at the official Arch installation guide, the average gamer may be overwhelmed by the process here, especially if they’re not comfortable with the terminal. Something like Linux Mint, on the other hand, has a built-in GUI installer with reasonable partitioning defaults, and it comes packaged with stuff like an app manger and update manager, something that will feel much more familiar to someone coming from windows.
If you want, or are interested in looking at an easier to manage Arch install I would suggest CachyOS, EndeavorOS, or Garuda Linux.