768
Canonical's Steam Snap is Causing Headaches for Valve
(www.omgubuntu.co.uk)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 18 Jan 2024
768 points (100.0% liked)
Linux
48313 readers
674 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
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.
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.
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.
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.
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.
As someone who knows nothing about Arch, what do you do if your app exists only as a .deb file? Can you install it?
I know you already got another answer, but - it's very rare that any software for Linux exists that is both 1) not present in the official Arch repos, and also 2) not packaged by a user for the AUR.
Probably 99% of what a typical user (I know we all define that differently) will want doesn't even require AUR access - it will be in the official Arch repositories and will be up to date to within a few weeks of release.
There are some potentially substantial downsides to the AUR (it's the Arch USER Repository - so these are not official arch packages) but IME the real world problems are minimal. I would suggest anyone who is new to the Arch way of distributing software should hit up the relevant page on the Arch wiki and make up their own mind before using the AUR - but it's about being aware of what you are doing more than it is a real warning, if that makes sense. I suspect few Arch or Arch-based users don't have at least a smidgen of AUR packages on their system. (Edit: That page is very thorough. I think it makes installing from the AUR sound much harder than it needs to be. For most people the command is just "yay -S packagename." There are gui options that handle all packages including AUR, and yay is not the only cli option, either.)
Interestingly, there are some AUR packages that work by pulling down the deb and deconstructing it for installation on your system - AFAIK it can be that, RPM, a true "compile from source" situation, or I'm guessing some AUR packages are deconstructing snaps\flatpaks\appimages during the install. Whatever the origin of the files, they include a pkgbuild file that tells your system how to either compile or deconstruct and install the software.
I know I ran into this years ago. I think it was some collection manager app for a trading card game that someone had on GitHub and only had .deb releases. Eventually you will want to install something niche.
I have found no such instances. Software which is only officially packaged as deb will usually be unofficially repackaged on the AUR regardless.
I distribute an app I made for Linux, macOS and Windows. The Linux version I only have available as a .deb. Released recently and has about 200 users so far, but definitely exists. No Arch user contacted me yet.
When folks start wanting it, someone will package it for the AUR, or if it becomes even somewhat mainstream it will end up in the main repos eventually.
Possibly, though I wonder how updates would work then. Currently I have a Debian repository that contains a single package, and installing the .deb from my website also installs the repository so you get updates as with any other package.
If someone repackages it on AUR, I guess they will also need to update it every time I update the .deb, so it's always behind? Of course it would be better if I provided a first party package for AUR, but I can spend time on that when there is actual interest. Most of my users are on Windows anyway.
Usually what you describe is what they do. Someone "owns" the AUR package (and it's not quite literally any random user IIRC - you have to be accepted as an AUR maintainer I think) and they then take on the responsibility to repackage it whenever the author (you) releases a new version. There is also a mechanism for users to flag the AUR package as out of date in case that maintainer misses a release, and if they abandon it (or even if folks just don't like how they package it) someone else can package it, assuming someone else wants to.
Sometimes the AUR maintainer is the dev themselves. I can't think of a good example currently, but I know I've seen it before.
I don't know the process for how things end up in the official repos, but I would guess it's similar to however any other distros identify software they want to officially package.
They may not have to. For example, Plex on nixos just unpacks the deb and installs the files the "nix" way.
https://github.com/NixOS/nixpkgs/blob/e18f8d69fb90bc71c33dc0851e6482284fe2e71e/pkgs/servers/plex/raw.nix
It isn't recommended, but dpkg will install it if you really want to. You just need to handle dependencies manually.
But it's a pretty rare issue. If something isn't available in the official repo, AUR probably has it.
Debian-trixie is pretty up to date and flatpak fills the holes perfectly.