Curious why they didn't go with sid. Maybe because Arch is intended to be rolling release, so it's less likely that regressions are overlooked as "well that's what sid is for, catching regressions"
(I use Arch on my desktop & WSL w/ Debian testing at work)
Debian testing is the closest thing Debian has to a "proper" rolling release. It comes with some mild drawbacks like half-baked security support (sometimes security fixes can get tangled with complex transitions and thus be somewhat delayed compared to sid) and the converse issue of long feature/transition freezes when approaching a stable release. But it's not clear that Arch is to be preferred in practice.
I think many steer clear of sid because of the security policy:
Please note that security updates for "unstable" distribution are not managed by the security team. Hence, "unstable" does not get security updates in a timely manner. [1]
While this does cover quite a bit, I think there is a little more that the security team does in terms of coordination, encouraging or even making timely package updates.
It’s understandable that some would fall on either side of being ok with that gap or not.
I haven't been regularly using Debian in about 15 years now, so I don't know how things are nowadays. But back in the day when I was running Debian unstable on my desktop, temporary breakages in dependencies or in individual packages weren't that uncommon. I think sometimes some functionality was broken for a while when there was some kind of a transition going on.
Those were entirely understandable given sid's nature, and it was much more reliable and functional than one would have expected from an "unstable" active development OS distro. It wasn't unstable in the sense of crashing or being generally buggy, and it was generally quite possible to use it as an everyday desktop.
It did, at least back then, require more active administration and a corresponding mindset than a fire-and-forget stable release would, though.
Sid might of course work as a basis for a distro for someone like Valve, but I think they'd need to do something similar to what Ubuntu does with freezes and weeding out issues before releases, or at the least have some kind of a delay before updates were pushed to non-testing devices if they based directly on the unstable release.
The drawback to using sid in this way is that every 2 years during the release freeze, regular uploads to it taper off or halt. Depending on the maintainer, uploads of new releases etc. may continue into the experimental branch, but those packages have to be pulled in manually, and continuing to upload in this manner is not always done. In principle, though, sid+experimental has the capacity to be analogous to a true rolling release.
not at all involved here, but i'd think managment of the full system from source (as might be needed for low level support e.g. kernel/libc patches) would be easier on arch than debian.
Too bad for most linuces we still cant build the base system in a single step like we have been able to do since the dawn of time in traditional unices.
"This distribution will never get released; instead, packages from it will propagate into testing and then into a real release." is a literal quote from https://www.debian.org/releases/sid/
I understand what it says, but it's misleading. The packages are "released" in the sense that they are in a repository that you can use to install a functional OS. See for yourself. http://ftp.debian.org/debian/dists/sid/main/
Valve wants the more frequent update schedule provided by Arch, presumably so that changes they need can be part of official arch releases vs. maintaining their own branches of debian packages that would need merged periodically.
Every time my friends show me arch, they always boast about how great their setup is (it's so stable, everything works out of the box !) then proceed to demo great features.
But then this little thing doesnt work yet because, they say, they haven't configure it correctly. And this little one, it's nothing mind you, it never worked. And this one, just a small detail, but it broke yesterday. We have a different definition of the box.
And so I go back to my Ubuntu LTS. I really want to try arch but I'm not 20 anymore, fiddling with my workstation is not as fun as it used to be. I just want to use it.
Maybe with the steam deck it will become so battle tested it will turn into the most stable distro ever.
I think their decision makes sense though, they don't want to have to craft every update and spend too much time on it. It's a good strat for them.
This was pretty much my experience with Arch and long long ago, Gentoo (where I really started with Linux).
Then I adopted Fedora and never looked back for several years. Even more recently I have been using WSL inside of Windows... and it actually covers most of my use cases well enough.
I dont have the time or patience anymore to keep up with distro's like Arch, but I also get that some people love tinkering and figuring out how to make their system work like its some kind of puzzle.
Edit: One thing about Arch, its possible to dig yourself a real bad hole if you don't keep updating regularly and I get that's sort of the point, but it can cause a lot of issues if for example, you go on vacation for a few weeks.
Yeah, that could be a problem with the deck, consoles players are not great at keepong their stuff up to date. My switched stay offline for months. Besides, I wanna play, not update, so If I see an update prompt I delay, and if I can't I hate the product.
Yeah, I was wondering about the Arch updates too. I had a machine that wasn't updated for a long time and had to go through the process of updating small bits at a time with archived packages: https://wiki.archlinux.org/title/Arch_Linux_Archive
> One thing about Arch, its possible to dig yourself a real bad hole if you don't keep updating regularly and I get that's sort of the point, but it can cause a lot of issues if for example, you go on vacation for a few weeks.
Any changes that could be problematic are announced on the site and the arch-announce mailing list. It's really not a matter of weeks. I've gone many months without updating, without any problems.
If you don't update, it'll stay usable indefinitely. If you do, you can skim arch-announce in less time than it takes to keep up with the release cycle of any other OS.
In return you'll never need to update a Debian release name in sources.list, click away a nagging update prompt, wait for a double-reboot cycle for some registry changes, or anything of the sort.
Yes, you will need to understand what's on your system to know what news is relevant for you. You automatically will because you set it up yourself.
> Any changes that could be problematic are announced on the site and the arch-announce mailing list
Yeah.. once I did a normal upgrade and it fucked my whole system. I asked for help and I was told that exact sentence "read the mailing list, it was announced". Thanks, but no thanks.
> announced on the site and the arch-announce mailing list
Perhaps there exists some subculture of folks that delight in having to read a set of articles published in the time between the last update and today before they do so again, but I have never encountered it.
You really don't have to. If you're subscribed to the mailing you just get an email every month or two. Most of the time it either won't apply to you, or it'll just be a nice-to-know. Every once in a long time (last time for me was 18 months ago) you'll actually have to remember for the next time you upgrade. Otherwise you can just upgrade and you'll be fine.
It's honestly incredibly low-maintenance. You just have to spend a relatively long time setting things up first.
What are these things that do not work? Asking as someone who's been using Arch consistently on my laptop and on a long-lived VPS since 2007 ... Original VPS install was maintained just through regular updates (including the transition from 32-bit to 64-bit). I did reinstall on the laptop for that.
Meanwhile, $work server images have been Ubuntu LTS, CentOS, and AL2 with updates introducing breakage several times a year.
Some friends had significant issues with screen sharing on Wayland on Arch. Pipewire wouldn't work correctly, or only allow sharing one screen, but not another.
As far as I can tell, they have resolved these issues now, but it was a pain point.
Pipewire itself has had some issues as it’s still relatively new. But I’ve found the last few releases have ironed them out. bleeding edge is more the issue than Arch
Fedora do seem [1] to make the same versions available. So there doesn't seem to be any' holding back' of unstable versions unless they decide to backport fixes from higher versions?
Fedora do work on six-month releases so there will be some version jumps between versions of Fedora but IIRC they will update little and often just like Arch whilst on a given release.
I'm personally guessing it's not as much that the releases themselves were inherently buggy as much as some configuration was required to get it working correctly.
And Fedora shipped some configuration that worked for the standard environment you'd have when you just installed Fedora and didn't change things around too much. Since Arch encourages you to build your own setup and roll your own configs to a much larger degree, the defaults probably weren't quite right or quite enough for their specific setups.
I don't mean this in an "Arch bad, other distro good" sense, I just wanted to say I've seen the same thing where some detail in an Arch setup was broken. It's simply different strokes for different folks.
You're describing exactly the Arch Philosophy though, not constantly broken mind you, but as vanilla (close to upstream) as possible. It's not supposed to be an "out of the box" distro at all, as in everything works out of the box.
When you sign up to Arch, yeah I think you sign up for a lot of tweaking that would be done for you already. Luckily there is the excellent Arch Wiki to hold your hand through much of it.
I feel that way about Linux generally. I didn't realize how much stuff I wasn't doing just because it rarely worked and often broke things (drag and drop as a general interaction, for instance), how much time I was spending keeping things sorta working, and how many little broken things I was just not even noticing because I was so used to them, until I finally (mostly) abandoned it as a desktop OS after ~10 years as a desktop Linux user.
Very much not a fan of recent Gnome last time I tried it (some months ago). Performance is so very bad. Dropped frames everywhere (maybe blame Linux for generally having fine-grained performance that isn't exactly bad but is more variable and unpredictable than other platforms) and generally sluggish. Used to like Gnome, but back then it was much lighter than KDE, but now the tables have (much to my surprise) entirely turned.
I like the idea of pop!_os but part of the flagship experience is a big ol' Javascript extension on top of Gnome. I can't imagine I'd find that enjoyable.
Last time I had a Linux working and I didn't hate the experience was a "so small I could drown it in a tub" install/config of Void with mostly Suckless tools/programs. I find Linux to be most tolerable in those kinds of configs, these days. Doesn't do much, but what it does do actually works and behaves fairly consistently. Start trying to get fancy, and the machine begins to feel haunted in a hurry.
Funnily I just did. My machine has now one entry in grub that doesn't work because pop didn't bother to sign the kernel or prompt me for it and I'm using secure boot.
Oh man, I’ve used Pop exclusively for 2 years now. I run it on a Thinkpad X1 Extreme, and I love it. I switched from using Macs (for the better part of 20 years) after the whole 2018 keyboard debacle. I can’t imagine going back. Only downside is the terrible battery life on the X1 Extreme.
Even as an ubuntu fan I can see I have to tweak a little my machine, at least more so than a mac or windows user.
It's stable enough for me, and I see that as the price to pay for more freedom and flexibility, but I can understand one wanting to get down to close to zero fiddling and pay premium for OSX to be done with it.
This comment is kinda true of anything. Even with WSL there are a bunch of things that "just work" better on Linux than Windows. Even with Steam there are a bunch of things that "just work" better on Windows than Mac.
I think in general finding the right tool is more about finding the thing whose inadequacies are least inconvenient to you personally rather than looking for some mythical tool that works well for everyone, in every case.
Windows for games, macOS for anything that might qualify as work. Linux for single-application multimedia appliances, probably on an RPi so the install is just a dd command and the platform's got enough eyes on it that it'll almost certainly Just Work with minimal tinkering. Linux on servers, but eyeing FreeBSD pretty hard.
Yeah, that one's heavily dependent on what one does. Software availability rules all, for that choice, and one only really has a choice if some certain minimum level of that is met by more than one OS. If I were developing deep server-side VM tools, or drivings, or what have you, I might find using a Linux or BSD workstation well worth the hassle. Embedded dev, macOS probably isn't a realistic choice, and maybe not even anything other than Windows, depending on hardware vendor support.
But when I write or compose documents, I don't need MS Office interop, and it'd probably be my 3rd or 4th choice of "suite" for that kind of thing, behind the Apple's versions (mostly because they have great default templates, are very stable, are fairly easy to use, and are very light on system resources), Abiword/Gnumeric and other pieced-together open source options, and maybe LibreOffice in 3rd place. But, if I had to pass around Office documents, that'd be another story.
Probably my main pain-point on Mac, as far as work-stuff goes, are under-developed virtualization tools. They have a hypervisor, but it's a pain to use and there's almost no community around it. No simple way to pick an earlier version of macOS and virtualize it, even. VirtualBox is... OK. Barely. 3rd party commercial options improve the situation a ton, but you get much better tools out-of-the-box on basically every other at-least-semi-viable workstation OS.
I had a similar experience, used Arch for awhile got tired of random things breaking, then I overcorrected and switched to Debian, thinking that infrequent changes would mean less breakage. That came with its own problems with things not working, especially if you let Debian fall out of date and it becomes un-upgradable. I also landed on Ubuntu LTS for my Linux needs, reasonably up-to-date, longer support cycles (a decade for security) than Debian versions, allowing me to be lazier than I could otherwise get away with managing other Linux distros.
However, the Steam Deck only has three main hardware configurations and Valve presumably has a team dedicated to making sure it runs correctly. So Arch may be a really good value proposition for them.
They will only have the required software dependencies and configuration they need to support those combined hardware/software configurations. So it should be easier for them to regression test and ensure stability even with Arch as a base.
Looks like they want to have the ability to be fairly agile and not getting locked into a platform for 2+ years
If you're not into fiddling but you still want a nice rolling release, you can try an Arch based distro.
I use Manjaro and it's been nothing but smooth sailing for a few years now. I have it on 4 machines - a home desktop, a work desktop, a laptop and an old Mac Pro from 2012.
This is a decent comment, and I get it. I also don't want to fool with my setup too much anymore. I use Manjaro for my primary system, and it's great though. I don't want to manage the software that I use everyday through SNAPs or however you do it on Ubuntu nowadays.
I just want the very latest of a short(ish) list of things, lets say arbitrarily within about 2 weeks of release, which is what Manjaro basically gives me.
pamac upgrade -a
Done. Or even better, most of the time:
pacman -Syu
This could be great for a games platform, because you'll get the latest CPU bytecode, and eg. Vulkan, and graphics drivers as well as the latest compatibility tools. Usually it's best to have the latest.
Anyway for Steam deck my first reaction is that they will need to:
1. Do like Manjaro and hold updates for a period of time before distributing them.
2. Provide some sort of one-click revert for when an update randomly prevents your device from booting. These are basically the only big problems that I encounter anymore - it usually takes 20 minutes to an hour to figure out which package is the problem and fix it, but you don't want to be doing that on your $600 steam deck.
Edit: As far as updates that brick your system go, my first experience with Arch was that if you don't keep up with the rolling releases, you will brick your system guaranteed when you update. So we'll see how that goes. That was 10+ years ago, and maybe it's not as bad now.
I've had maybe three or four high-friction upgrades on Ubuntu over the past 15 years, where it wouldn't boot properly until I fixed the problem. So yeah it's /better/, but it's far from flawless.
Note I don't stick to LTS releases. If I only upgraded to the X.1 LTS releases I expect it would have been smoother.
Two big differences with Arch and derivatives though:
1. AUR - almost anything you could need.
2. rolling releases - I admit I haven't used Ubuntu in a long time, but I use Debian for a variety of things, and it can be painful to need a release upgrade in order to get the next version of some piece of software. With Arch and derivatives, as long as you do updates regularly, everything stays new.
In arch, everything works straight out of the box. However the box is very small, and you need a lot of other boxes, to get a «normal» working system that can write code and play music and tile windows and…
It's based on Arch, it's not purely Arch. Valve takes Arch and distributes their own configured version. I don't see how that would make SteamOS unstable unless Valve makes a mistake in testing.
I don't think it will make arch more stable. It would require a good amount of change on the way the whole package repositories are tested.
I'm quite sure that Steam Deck will have its own repositories so that they can validate upstream changes before pushing those to the Steam Deck users.
There's also going the opposite direction and throwing out everything that requires any non trivial amount of configuration. I've been pretty happy doing this.
This is what I came to say. Arch is fine but you are expected to babysit your PC and perform maintenance every week. And do that for each and every build in the house.
Things break often and I am not interested in fixing them. And that's not taking into account wife and kids builds. It took me a while to realize the Arch crowd largely doesn't get that not everyone is exciting to thinker with their OS all the time. I get it. I really do. But I am old
As you say, hopefully Valve's efforts are going to help with that. In fact, there's hardly a chance they won't because they business depends on it, at least long term.
I think people are making too much of Arch in this case. They aren't going to put Arch on Steam Deck and call it a day. It'll be more like putting Manjaro on it. Except it isn't Manjaro, it's their own distro based on Arch that they'll be managing and distributing. And honestly, Manjaro is one of the most stable, easy to use Linux distros I've used and it's based on Arch (in the same way that SteamOS will be based on Arch). So people need to calm their tits.
The endless criticism of everything needs to stop.
I have a 6 years old arch installation, and an Ubuntu installation that has been going and was regularly updated to a recent release for about as long.
I spend more time just trying to have up-to-date software on that Ubuntu installation than I spend time configuring anything about the arch installation. Granted, sometimes you need to edit some files after an update (oh device names changed again in pulseaudio so your volume hotkeys need to be fixed!), but that's usually a matter of seconds because I already know how everything fits together. When a package is totally broken for some reason, I just downgrade it.
Meanwhile on Ubuntu your only option for getting up to date versions of Jameica/Hibiscus, pretty much any mapping software that OSM contributors/users would want to use, and a bucket list of other productivity software that tends to be useless if outdated, is to compile from source (don't forget to fix incompatibilities with Ubuntu's libraries!) or manual downloads. Oh I forgot to mention Subsurface and TurtleSport. Don't get me started about those. Bonus points for Ubuntu not having disabled the built-in version checks in a lot of software (it's usually just a compile time options or command line argument!), so it nags users that they're running outdated software when there's no way to upgrade!
At this point I'm convinced the only noteworthy software that Ubuntu manages to have acceptably recent versions of is Firefox. If all you want to do is browse web, Ubuntu might be less work.
I'm not surprised Ubuntu is trying to move to snap packages. That's their last ditch attempt at getting their house in order.
Arch will always at least have an automatically installing AUR package for you with a version that isn't from 2018.
For me I find PPAs typically make getting the latest versions of software where I want the bleeding edge painless. And I don't need to also have everything bleeding edge the way Arch forces me to.
PPAs work great until they don't, because it's just some random guy building the packages half of the time.
The last time I seriously tried to use Ubuntu was probably 8-10 years ago and I ran into a lot of trouble trying to get up to date graphics drivers via PPAs. I also remember being tired of having to go find a random PPA for every piece of software I wanted. Most of the time I would just find some random blog that provided a "PPA for up-to-date package X" and ultimately felt like what I was doing wasn't really any better than downloading random MSIs like you would on Windows.
With Arch though you get the AUR which quite literally has every piece of software you could ever want and is at least managed and maintained in a central place so you're not just adding random PPAs for everything.
The PPA landscape certainly has changed and things weren't nearly as centralized as they are now.
I don't think the AUR is necessarily more secure but in general the nature of how the AUR works does perhaps give some slight advantage. The suggested approach to the AUR is to download and inspect the PKGBUILD so you know how/what the package is doing opposed to a PPA typically being a precompiled binary. AUR helpers will also typically show recent comments, etc. so if a package was compromised or had issues you'd probably know as you're pulling it down.
Really though the AUR just tends to be more convenient and complete than finding random PPAs in my experience.
Distros like Ubuntu don't aim to always keep up to date. The value in them is that they're sufficiently recent but updated infrequently enough that they don't regularly break after an update, and support can be provided.
You're supposed to separately manage the software you care about. e.g. there's a nodejs for people who don't exploit it in their daily use except as dependencies to other software, but if you use it regularly you should manage your own nodejs binaries.
I moved to Fedora and it's solved that problem with Ubuntu. Sometimes it goes too far with the update (ruby to 3.0 breaks a lot of things for development)
You are referring to great features, but Arch just uses the same upstream packages as everyone else and in a more vanilla form, so it seems like it's about user customization.
If so, why is this the distribution's fault? The installation is a bit cumbersome but other than that you do not need to do much.
I personally keep my configuration small and tidy, following a "bang for the buck" approach and have not faced any issues. Perhaps my usage patterns are just simpler, but even Steam works fine.
I wonder to what extent they were showing you the new features that they'd mostly added, because they were proud of them. Most of the stuff I actually use on my install is fully set up, but I wouldn't show it to a friend, because it is boring work stuff.
>Maybe with the steam deck it will become so battle tested it will turn into the most stable distro ever.
Being a rolling release goes directly against that. It might be the most stable rolling release together with openSUSE Tumbleweed. When you combine it with a modern filesystem and features like snapshots it really feels solid.
In the context of the Steam Deck they can just test and hold/fix bugs so that's a very different scenario.
There are just too many changes everywhere and different hardware, software combinations, to expect a bug free experience. Not even Apple with a different release model can manage that and they control everything and have most of the hardware combinations to test. Many DEs and bigger applications need a few point releases to be better but maybe you're talking only about the base distro if it's even possible to make that distinction.
I've used Arch and Ubuntu both for years, so here's my take. Basically, anything you get working in Arch stays working. On Ubuntu, every single major upgrade has been broken so badly that I eventually gave up and reinstalled from scratch. Annoyingly, some super sensible defaults just never make it back up to the original maintainers (or are rejected, I dunno), so the polished Ubuntu experience is because a lot of engineers at Canonical put a lot of time into enabling things which should absolutely be enabled by default in any modern distro. This includes big things like encrypted storage being a single click option in the installer (compared to several hours of research and false starts with GRUB on Arch Linux) and small things like having a reasonably big set of fonts installed by default. Maybe I just haven't discovered the right metapackages yet :)
All that said, I can thoroughly recommend NixOS (my setup[1]) as an alternative, and I personally predict SteamOS will show up there eventually. Initial setup is a fair bit easier, and being able to seamlessly boot into any of the previous configurations is a big deal. The main issues so far have been with dev env setups (Nix isn't terrible, but it's another language to add on top of my existing setups) and running out of disk space because each upgrade takes multiple GB. Don't install unless you have ~100GB to spare for the root partition and a decently fast Internet connection.
Fiddling with the workstation is not fun anymore. I dont think it was a useful activity even when I was younger. That time could have been spent doing things that are useful - development, writing my thesis etc.
I switched to macOS several years ago for my personal desktop. I use Ubuntu (or any Linux) only at work where someone else (IT) manages the machine and ensures things work.
My experience with Arch is that I just install everything and it works straight out of the box because as nothing is patched the integration work done by each projects doesn't break.
Meanwhile Debian and Ubuntu both are a hodgepot of random patches thrown together by more or less (but rather less) knowledgeable maintainers for reasons which are clear only to themselves and involve goals I don't share such as allowing things to run over weird kernels and maintaining some imaginary philosophical open source purity. I wouldn't touch that with a ten feet pole.
I still personnaly believe that the Linux distribution system is the main reason Linux wasn't more successful. I like Arch because amongst all the successful distribution they seem to be the one doing the less.
It's stability vs reliability. I know Arch is reliable enough that I can depend upon the community to take the right decisions, Find what I need in their unparalleled documentation, Find bleeding edge binary packages of open-source tools in the community repo etc.
Yes I occasionally don't know what's causing a problem and I have to reinstall some packages. It's definitely not stable.
But if I needed stability I would have gone for Cent OS or what ever stands for stability nowadays. And that's the beauty of Linux, There's something for everyone.
As an Arch user I wonder if this means I'll get better native support of Steam on my desktop. I wouldn't say there are any major issues right now but every little bit that makes the experience better is one more reason I can stop keeping a Windows install around.
Frankly, this is a good move for both the users who don't care and the users who do.
If you just want to own a Steam Deck for the Steam interface, you can do that. The fact that it's just an x86 Ryzen chip at the end of the day guarantees you at least 10 more years of kernel upgrades, and the current state of Proton makes me confident that it can "just work".
For the people who do care about digging in, we can ascertain that they own $400+ enthusiast hardware, they want to tinker to their hearts content. Arch is just "better" at providing custom Proton builds, hunting down esoteric 32-bit libraries, and maintaining "gaming" software like Feral Gamemode, Lutris, Retroarch and Mangohud. No, it won't be stable, but gaming on Windows is not getting any better, nor will it get any better with Windows 11 cutting support for 80% of the world's active computers.
Is this the same Valve that still ships Steam on Linux with almost 10 year old libraries, which it never bothered to update? Debian is bleeding edge compared to that.
I'm really curious to see how they plan to deliver system updates. Arch always makes me think of highly customized systems with per-package updates. For a little handheld with limited battery life, relatively short uptime, and a straightforward use case (so only enthusiasts who are capable of jumping through hoops are going to care whether they can install some other system-level packages), that makes very little sense. So I'm really hoping SteamOS 3 uses ostree. I haven't seen examples of people doing that with Arch, but I imagine it's quite possible.
The could release the source to steam and let the community fix the issues with it (since they've struggled so much with this.)
The problem is that one of the primary selling points to publishers is that it prevents you from running games you might have on your machine (DRM.) That is: The biggest feature of steam besides configuring Wine for you is that it doesn't work most of the time.
I don't really see any argument against of for either distro here. And then there is de false argument that Debian 'groups updates in to a big update', which is also not really the case.
I suppose the real issue I personally take is the wording used here; updates aren't "just updates" and haven't been for a long time, not even in commercial-desktop-land. You have updates that just do things like security and bug fixes, and then there are feature updates, and then you have major changes. In Debian's case, you don't get major updates of packages within a single Debian release. If you started with GNOME2 for example, you don't get GNOME3 until the next Debian release. But you do get GNOME 2.1, 2.2, 2.3 etc. (this is just an example, not a real versioning or naming scheme)
What the article makes it seem is that you don't get minor updates either. Or bug fixes. Perhaps this is a result of trying to 'dumb down' the intricacies of downstream vs. upstream packaging, distributions and multi-project releases.
At the same time, the whole argument doesn't make any sense anyway: if you are Valve, you control your own releases and your own distribution. It matters a whole lot less what 'upstream' vendor your use is doing, because you can always do whatever you want in your own distro. Or better yet, you can take what upstream does, and use backports to get major core changes into your current version. And if that isn't enough, you can take a look at the many bistro-derivatives, including the likes of Ubuntu; they are (sometimes loosely) based on an existing long-term distro but with a lot of local modifications/replacements on top of that.
Because Valve is already making their own distro, it is unlikely to really matter what 'upstream' they use, the only big change would be the standards they uphold (be it packaging methods, like dpkg vs. rpm) or openness (DFSG vs. "I'll just drop this binary in here and see what happens later"). Better yet, if Debian wasn't a good fit, they could have gone with Ubuntu instead. Or any other derivative.
It smells like a 'we wanted something different but not really deal with licensing/legal' combined with 'the new guy runs arch on his Thinkpad so yeah'. In the end if matters a whole lot less than your average distro-war; Valve still just has a distro, they still release it, and they still support it. It's just more hobby-like than production-like at this time. Switching to some SONiC-SAI type architecture would have made more sense.
Arch I'm sure is a great choice when someone else (Valve, in this case) is configuring and administrating it for you.
When you're doing it yourself, every Arch user seems to have a list of things which "aren't working today".
I've been using openSUSE Tumbleweed for a while, which has all the advantages of a rolling distribution like Arch (and their repo is enormous), but also comes with Yast, their frankly amazing graphical administration tool which handles everything.
It doesn't seem that common, at least in the USA, but I recommend it.
I hopped around distros, starting with Ubuntu/Kubuntu, and then I switched to Manjaro (my first rolling release) because I was sick of ppas for newer software. Manjaro broke frequently, however. Finally found my home on openSUSE Tumbleweed. It's great because I have tons of new packages, but honestly it's never broken once for me (and if it did, btrfs snapshots would let me quickly revert).
I think that having SUSE behind it maybe helps the stability? But I have no concrete knowledge of the testing process that goes into Tumbleweeed.
Interesting - I run MS Teams on Arch with no issue. The only complaint I've got is that changes to the PulseAudio devices don't seem to be detected without restarting the application - can be a PITA when you plug/unplug a USB microphone.
I wonder how long it'll be before this type of platform uses an "immutable" system like NixOS. Not that NixOS is the best for this right now, but the offerings of an obscenely concrete configuration based OS seem amazing for this type of hardware.
Worse for the user experience if users want to self-install stuff, but still.
Valve missed an opportunity to implement (again) the dual boot partition concept that worked so well for CoreOS, before Redhat bought them and "discontinued" the very good idea. Deploying a complete and coherent and well tested base layer that has built-in fallback, and then deploying games as signed containers would have been a robust system. Instead they picked yet another upgrade complexity mess.
There was a video from Collabora talking about Valve, immutability and different possibilities of deployment. I don't have the time to find and rewatch it but I'm not sure this article confirms that they will just do regular updates even if they say they are small. It could be interpreted in many ways. Maybe the video was only about the Steam Runtime.
you're overestimate the complexity here. these are homogeneous devices it'll be very easy to update them safely. the other approaches are actually more complex and error prone due to bit rot.
having a frequently updated system ensure you're constantly exercising the code paths involved. and your change differential for regression testing is much smaller.
The reason is ChimeraOS (used to be GamerOS) which completely took over SteamOS’s position as a big picture Steam Linux OS, and the method used on top of Arch base was such that you as a user didn’t have to generally customise anything, and no manual updating etc. I can’t believe the article wouldn’t even mention it, very poor research as it was the case that proved that the Debian stable base was ultimately a poor choice for both keeping pace with the latest graphics stack and even worse for upgrading the base requiring users to reinstall. I’ve been using Chimera for a while now, and really excited to see Valve are going that direction. https://chimeraos.org/about
Yeah no. You want to stick with the established base Linux distros that have corporate backing or people that know what they are doing. Don't swim down the river and like hardware peripherals don't use anything that associates itself with gamers.
NixOS would be a great OS for the Steam deck. Arch certainly has a lot of advantages and was my go-to for the last 10 years before rencetly switching to NixOS.
I actually used Arch as the base OS for a few linux computer labs (~100 machines) and it was both a joy and a headache. I really enjoyed being able to package proprietary software like Matlab & Mathematica. It was also nice that students had access to the latest software.
However, the stability of the boot process and upgrades was not fun. Identical machines running what should have been the same configuration would drift over time. I used Ansible to template a lot of the configuration but it would basically be a full time job to keep track of everything. Random machines would end up with a broken Pacman keyring causing updates to fail, etc. Somehow partial upgrades were occuring which would break the boot process.
While 90% of software was easy to package, the other 10% were research projects that would make a lot of assumptions regarding what system C++ libraries were available.
So far with NixOS, it is very stable. Unless you are activelly messing with the bootloader settings, it's almost impossible to break since you can select a previous configuration at boot time. While packageing software is not as easy as Arch, having a per-application dependency tree is extreamly helpful.
That said NixOS is currently going through a lot of changes and missing a few things:
1. No easy secure boot configuration.
2. Networking configuration is sort of in a flux between network-manager & systemd-networkd.
3. Packages are typically fairly up-to-date but the consistency is pretty variable.
TLDR; I am curious how Valve is handeling OS upgrades on the Steam Deck. My experience in using pacman -Syu in a unattended* manner was anything but smooth. I would not be suprised if system partitions are RO and/or updated via a disk image.
I only briefly looked at Guix. I think there is an arguement that it has a better language. Besides that I'm not sure what one gains compared to NixOS.
Overall Guix looked nice but it is very opinionated on the free-software issue which really hurts its adoptability. It is also a niche sibling of an already niche distro so I doubt it would be used in (real) production any time soon.
The community & related projects around NixOS are also very compelling. Structured flakes like devos [1] and developer tools like direnv/nix-shell make getting started very easy. I'm not sure if the same can be said about Guix (I'll admit I having been keeping a close eye on it). The darwin (MacOS) compatability is also a huge selling point since a lot of MacOS developers already need tools like Homebrew.
Just to note,a brief look and a close eye aren't exactly the same thing.
I agree that, at this stage Guix will have as much success as Hurd does in becoming a production ready system. But I do think there might be some form of borrowing between the Nix and Guix.
In my case however, I'd rather have an Arch-based system with NixOS's clean architecture.
I like NixOS, but I think the redundancy in the /nix/store could possibly take up a lot of space on a system with as little storage as the 64GB Steam Decks. Plus the tooling has a weird interface.
NixOS hardlinks the /nix/store so there isn't much redundancy unless you are actually using packages that need completely different dependency versions. My system is currently at 13G but that could be optimised a bit & seems comparable to how much Archlinux used with the same packages installed.
Archlinux isn't much better when it comes to storage efficiency. Arch does not seperate out documentation and development libraries from the main package so there is quite a bit extra stuff in a lot of packages.
Valve can do a lot of things to save space like disable or delete the Pacman cache after every install. They could build their own repos/packages that stripped out documentation and development libraries.
Overall compared to the size of many games, the storage overhead of Arch or Nix is pretty minimal. At Valve's scale either can & probably will be tweaked to take up <10GB. I guess I forgot that the base model's storage is only 64GB. It makes me wonder if they are going to have optimised game downloads with lower resolution textures; many games would use ~10% of the space if the texture's were optimised.
I like Arch because it's a "containment" distro just like Manjaro. It keeps a lot of the most toxic gamer and ricing community isolated in some form. Thank god Valve picked that. Don't get triggered by what I'm saying, there are plenty of great people in the Arch community and the software is great but what I said is still true in many ways. The forums and even their reddit is very hard to interact with, I always had to walk on eggshells. Another great thing is their wiki and I use it all the time.
Weird that the article doesn't mention KDE Plasma as I believe it's another reason why they need rapid development. They are finishing some huge migrations like Wayland and refining their theme and applications so it's even more accessible to less technical folks. I was scared to death when the reviewers were using Plasma docked because it needs a lot of testing before it's ready. That's natural when you are making big changes.
I wonder if they considered openSUSE Tumbleweed as a base rolling release and if so, why they picked Arch.
Is it because openSUSE Tumbleweed is less popular? Too "opinionated" / "customized, with Yast and all? Or just that (someone in) the team is more proficient in Arch?
openSUSE seems more robust than Arch overall, and especially for updates for which you are not particularly expected to read the document before updatinopenSUSE seems more robust than Arch overall, and especially for updates for which you are not particularly expected to read the document before updating [1].
It would seem that just using openSUSE Tumbleweed instead of Arch would mean less maintenance work for Valve because of this. I guess they need to test and validate updates before pushing them to the device anyway.
KDE/Plasma is also a first class desktop environment on openSUSE, so it would also be a good fit, since they are adopting this desktop environment.
Maybe Arch is more "KISS" and therefore easier to hack?
I also wonder if they considered Gentoo, which would help them tweak the (optimization-related) compilation flags for customized builds?
The entire point of proton is gaming on linux. By nature arch linux will be the best supported platform for it now, which is a disservice to those that use the most popular distro's of debian/ubuntu. I cannot reasonably expect even technical users to configure arch correctly, nor be able to maintain or, nor have a good experience. Valve's taking the easy path that doesn't benefit the community. But I thought that was obvious from the fact they're putting out a handheld device that can barely play games.
126 comments
[ 2.0 ms ] story [ 208 ms ] thread(I use Arch on my desktop & WSL w/ Debian testing at work)
And yet the use "rolling" distributions that often contains exactly the same software.
Please note that security updates for "unstable" distribution are not managed by the security team. Hence, "unstable" does not get security updates in a timely manner. [1]
[1] https://www.debian.org/releases/sid/
Sid/Unstable and Testing track upstream releases.
If an upstream developer releases a new version to fix a vulnerability, Sid gets the upstream fix just like other rolling distro.
If a version in Testing has a vulnerability and Testing entered a pre-release freeze the fix gets backported.
If a version in Stable has a vulnerability the fix gets backported.
This is designed to provide the "best of both worlds".
It’s understandable that some would fall on either side of being ok with that gap or not.
Those were entirely understandable given sid's nature, and it was much more reliable and functional than one would have expected from an "unstable" active development OS distro. It wasn't unstable in the sense of crashing or being generally buggy, and it was generally quite possible to use it as an everyday desktop.
It did, at least back then, require more active administration and a corresponding mindset than a fire-and-forget stable release would, though.
Sid might of course work as a basis for a distro for someone like Valve, but I think they'd need to do something similar to what Ubuntu does with freezes and weeding out issues before releases, or at the least have some kind of a delay before updates were pushed to non-testing devices if they based directly on the unstable release.
Too bad for most linuces we still cant build the base system in a single step like we have been able to do since the dawn of time in traditional unices.
sid is not a release, it is a staging area for packages to roll into a release.
[1] https://www.debian.org/releases/sid/
You can absolutely upgrade to sid, run it, and get daily updates, at the much higher risk of breakage of your system.
"This distribution will never get released; instead, packages from it will propagate into testing and then into a real release." is a literal quote from https://www.debian.org/releases/sid/
"continuously updated and never released" would be more correct.
It's like saying that a git repository that never gets version tags is "released on every commit".
Valve wants the more frequent update schedule provided by Arch, presumably so that changes they need can be part of official arch releases vs. maintaining their own branches of debian packages that would need merged periodically.
But then this little thing doesnt work yet because, they say, they haven't configure it correctly. And this little one, it's nothing mind you, it never worked. And this one, just a small detail, but it broke yesterday. We have a different definition of the box.
And so I go back to my Ubuntu LTS. I really want to try arch but I'm not 20 anymore, fiddling with my workstation is not as fun as it used to be. I just want to use it.
Maybe with the steam deck it will become so battle tested it will turn into the most stable distro ever.
I think their decision makes sense though, they don't want to have to craft every update and spend too much time on it. It's a good strat for them.
Then I adopted Fedora and never looked back for several years. Even more recently I have been using WSL inside of Windows... and it actually covers most of my use cases well enough.
I dont have the time or patience anymore to keep up with distro's like Arch, but I also get that some people love tinkering and figuring out how to make their system work like its some kind of puzzle.
Edit: One thing about Arch, its possible to dig yourself a real bad hole if you don't keep updating regularly and I get that's sort of the point, but it can cause a lot of issues if for example, you go on vacation for a few weeks.
Any changes that could be problematic are announced on the site and the arch-announce mailing list. It's really not a matter of weeks. I've gone many months without updating, without any problems.
In return you'll never need to update a Debian release name in sources.list, click away a nagging update prompt, wait for a double-reboot cycle for some registry changes, or anything of the sort.
Yes, you will need to understand what's on your system to know what news is relevant for you. You automatically will because you set it up yourself.
Yeah.. once I did a normal upgrade and it fucked my whole system. I asked for help and I was told that exact sentence "read the mailing list, it was announced". Thanks, but no thanks.
Perhaps there exists some subculture of folks that delight in having to read a set of articles published in the time between the last update and today before they do so again, but I have never encountered it.
It's honestly incredibly low-maintenance. You just have to spend a relatively long time setting things up first.
I suspect they will do like those Arch derivatives do: holding back updates for testing, which is easy when you target known hardware.
Meanwhile, $work server images have been Ubuntu LTS, CentOS, and AL2 with updates introducing breakage several times a year.
As far as I can tell, they have resolved these issues now, but it was a pain point.
I understand they're different distros with different philosophies, but in the end I do need my screen sharing to work no questions asked.
Fedora do work on six-month releases so there will be some version jumps between versions of Fedora but IIRC they will update little and often just like Arch whilst on a given release.
https://koji.fedoraproject.org/koji/packageinfo?packageID=24...
And Fedora shipped some configuration that worked for the standard environment you'd have when you just installed Fedora and didn't change things around too much. Since Arch encourages you to build your own setup and roll your own configs to a much larger degree, the defaults probably weren't quite right or quite enough for their specific setups.
I don't mean this in an "Arch bad, other distro good" sense, I just wanted to say I've seen the same thing where some detail in an Arch setup was broken. It's simply different strokes for different folks.
When you sign up to Arch, yeah I think you sign up for a lot of tweaking that would be done for you already. Luckily there is the excellent Arch Wiki to hold your hand through much of it.
I like the idea of pop!_os but part of the flagship experience is a big ol' Javascript extension on top of Gnome. I can't imagine I'd find that enjoyable.
Last time I had a Linux working and I didn't hate the experience was a "so small I could drown it in a tub" install/config of Void with mostly Suckless tools/programs. I find Linux to be most tolerable in those kinds of configs, these days. Doesn't do much, but what it does do actually works and behaves fairly consistently. Start trying to get fancy, and the machine begins to feel haunted in a hurry.
It's stable enough for me, and I see that as the price to pay for more freedom and flexibility, but I can understand one wanting to get down to close to zero fiddling and pay premium for OSX to be done with it.
I think in general finding the right tool is more about finding the thing whose inadequacies are least inconvenient to you personally rather than looking for some mythical tool that works well for everyone, in every case.
FWIW, a lot of "work" areas are still deep into Microsoft Word, which works a lot better on Windows.
But when I write or compose documents, I don't need MS Office interop, and it'd probably be my 3rd or 4th choice of "suite" for that kind of thing, behind the Apple's versions (mostly because they have great default templates, are very stable, are fairly easy to use, and are very light on system resources), Abiword/Gnumeric and other pieced-together open source options, and maybe LibreOffice in 3rd place. But, if I had to pass around Office documents, that'd be another story.
Probably my main pain-point on Mac, as far as work-stuff goes, are under-developed virtualization tools. They have a hypervisor, but it's a pain to use and there's almost no community around it. No simple way to pick an earlier version of macOS and virtualize it, even. VirtualBox is... OK. Barely. 3rd party commercial options improve the situation a ton, but you get much better tools out-of-the-box on basically every other at-least-semi-viable workstation OS.
However, the Steam Deck only has three main hardware configurations and Valve presumably has a team dedicated to making sure it runs correctly. So Arch may be a really good value proposition for them.
Looks like they want to have the ability to be fairly agile and not getting locked into a platform for 2+ years
I use Manjaro and it's been nothing but smooth sailing for a few years now. I have it on 4 machines - a home desktop, a work desktop, a laptop and an old Mac Pro from 2012.
It also provides continuous snapshots: https://snapshot.debian.org/
I just want the very latest of a short(ish) list of things, lets say arbitrarily within about 2 weeks of release, which is what Manjaro basically gives me.
Done. Or even better, most of the time: This could be great for a games platform, because you'll get the latest CPU bytecode, and eg. Vulkan, and graphics drivers as well as the latest compatibility tools. Usually it's best to have the latest.Anyway for Steam deck my first reaction is that they will need to:
1. Do like Manjaro and hold updates for a period of time before distributing them.
2. Provide some sort of one-click revert for when an update randomly prevents your device from booting. These are basically the only big problems that I encounter anymore - it usually takes 20 minutes to an hour to figure out which package is the problem and fix it, but you don't want to be doing that on your $600 steam deck.
Edit: As far as updates that brick your system go, my first experience with Arch was that if you don't keep up with the rolling releases, you will brick your system guaranteed when you update. So we'll see how that goes. That was 10+ years ago, and maybe it's not as bad now.
More than 0, but not a lot.
Note I don't stick to LTS releases. If I only upgraded to the X.1 LTS releases I expect it would have been smoother.
1. AUR - almost anything you could need.
2. rolling releases - I admit I haven't used Ubuntu in a long time, but I use Debian for a variety of things, and it can be painful to need a release upgrade in order to get the next version of some piece of software. With Arch and derivatives, as long as you do updates regularly, everything stays new.
I get new hardware support and access to the many only-arch-pre-packaged software, in a more stable base.
Things break often and I am not interested in fixing them. And that's not taking into account wife and kids builds. It took me a while to realize the Arch crowd largely doesn't get that not everyone is exciting to thinker with their OS all the time. I get it. I really do. But I am old
As you say, hopefully Valve's efforts are going to help with that. In fact, there's hardly a chance they won't because they business depends on it, at least long term.
The endless criticism of everything needs to stop.
I spend more time just trying to have up-to-date software on that Ubuntu installation than I spend time configuring anything about the arch installation. Granted, sometimes you need to edit some files after an update (oh device names changed again in pulseaudio so your volume hotkeys need to be fixed!), but that's usually a matter of seconds because I already know how everything fits together. When a package is totally broken for some reason, I just downgrade it.
Meanwhile on Ubuntu your only option for getting up to date versions of Jameica/Hibiscus, pretty much any mapping software that OSM contributors/users would want to use, and a bucket list of other productivity software that tends to be useless if outdated, is to compile from source (don't forget to fix incompatibilities with Ubuntu's libraries!) or manual downloads. Oh I forgot to mention Subsurface and TurtleSport. Don't get me started about those. Bonus points for Ubuntu not having disabled the built-in version checks in a lot of software (it's usually just a compile time options or command line argument!), so it nags users that they're running outdated software when there's no way to upgrade!
At this point I'm convinced the only noteworthy software that Ubuntu manages to have acceptably recent versions of is Firefox. If all you want to do is browse web, Ubuntu might be less work.
I'm not surprised Ubuntu is trying to move to snap packages. That's their last ditch attempt at getting their house in order.
Arch will always at least have an automatically installing AUR package for you with a version that isn't from 2018.
The last time I seriously tried to use Ubuntu was probably 8-10 years ago and I ran into a lot of trouble trying to get up to date graphics drivers via PPAs. I also remember being tired of having to go find a random PPA for every piece of software I wanted. Most of the time I would just find some random blog that provided a "PPA for up-to-date package X" and ultimately felt like what I was doing wasn't really any better than downloading random MSIs like you would on Windows.
With Arch though you get the AUR which quite literally has every piece of software you could ever want and is at least managed and maintained in a central place so you're not just adding random PPAs for everything.
I don't think the AUR is necessarily more secure but in general the nature of how the AUR works does perhaps give some slight advantage. The suggested approach to the AUR is to download and inspect the PKGBUILD so you know how/what the package is doing opposed to a PPA typically being a precompiled binary. AUR helpers will also typically show recent comments, etc. so if a package was compromised or had issues you'd probably know as you're pulling it down.
Really though the AUR just tends to be more convenient and complete than finding random PPAs in my experience.
You're supposed to separately manage the software you care about. e.g. there's a nodejs for people who don't exploit it in their daily use except as dependencies to other software, but if you use it regularly you should manage your own nodejs binaries.
If so, why is this the distribution's fault? The installation is a bit cumbersome but other than that you do not need to do much.
I personally keep my configuration small and tidy, following a "bang for the buck" approach and have not faced any issues. Perhaps my usage patterns are just simpler, but even Steam works fine.
With flatpaks/snaps being so ubiquitous it doesn't really matter much at this point anyway.
Being a rolling release goes directly against that. It might be the most stable rolling release together with openSUSE Tumbleweed. When you combine it with a modern filesystem and features like snapshots it really feels solid.
In the context of the Steam Deck they can just test and hold/fix bugs so that's a very different scenario.
There are just too many changes everywhere and different hardware, software combinations, to expect a bug free experience. Not even Apple with a different release model can manage that and they control everything and have most of the hardware combinations to test. Many DEs and bigger applications need a few point releases to be better but maybe you're talking only about the base distro if it's even possible to make that distinction.
All that said, I can thoroughly recommend NixOS (my setup[1]) as an alternative, and I personally predict SteamOS will show up there eventually. Initial setup is a fair bit easier, and being able to seamlessly boot into any of the previous configurations is a big deal. The main issues so far have been with dev env setups (Nix isn't terrible, but it's another language to add on top of my existing setups) and running out of disk space because each upgrade takes multiple GB. Don't install unless you have ~100GB to spare for the root partition and a decently fast Internet connection.
[1] https://gitlab.com/victor-engmark/root/
To me arch tries to be fast moving without checking if anything breaks
I switched to macOS several years ago for my personal desktop. I use Ubuntu (or any Linux) only at work where someone else (IT) manages the machine and ensures things work.
Meanwhile Debian and Ubuntu both are a hodgepot of random patches thrown together by more or less (but rather less) knowledgeable maintainers for reasons which are clear only to themselves and involve goals I don't share such as allowing things to run over weird kernels and maintaining some imaginary philosophical open source purity. I wouldn't touch that with a ten feet pole.
I still personnaly believe that the Linux distribution system is the main reason Linux wasn't more successful. I like Arch because amongst all the successful distribution they seem to be the one doing the less.
Yes I occasionally don't know what's causing a problem and I have to reinstall some packages. It's definitely not stable.
But if I needed stability I would have gone for Cent OS or what ever stands for stability nowadays. And that's the beauty of Linux, There's something for everyone.
If you just want to own a Steam Deck for the Steam interface, you can do that. The fact that it's just an x86 Ryzen chip at the end of the day guarantees you at least 10 more years of kernel upgrades, and the current state of Proton makes me confident that it can "just work".
For the people who do care about digging in, we can ascertain that they own $400+ enthusiast hardware, they want to tinker to their hearts content. Arch is just "better" at providing custom Proton builds, hunting down esoteric 32-bit libraries, and maintaining "gaming" software like Feral Gamemode, Lutris, Retroarch and Mangohud. No, it won't be stable, but gaming on Windows is not getting any better, nor will it get any better with Windows 11 cutting support for 80% of the world's active computers.
The problem is that one of the primary selling points to publishers is that it prevents you from running games you might have on your machine (DRM.) That is: The biggest feature of steam besides configuring Wine for you is that it doesn't work most of the time.
I suppose the real issue I personally take is the wording used here; updates aren't "just updates" and haven't been for a long time, not even in commercial-desktop-land. You have updates that just do things like security and bug fixes, and then there are feature updates, and then you have major changes. In Debian's case, you don't get major updates of packages within a single Debian release. If you started with GNOME2 for example, you don't get GNOME3 until the next Debian release. But you do get GNOME 2.1, 2.2, 2.3 etc. (this is just an example, not a real versioning or naming scheme)
What the article makes it seem is that you don't get minor updates either. Or bug fixes. Perhaps this is a result of trying to 'dumb down' the intricacies of downstream vs. upstream packaging, distributions and multi-project releases.
At the same time, the whole argument doesn't make any sense anyway: if you are Valve, you control your own releases and your own distribution. It matters a whole lot less what 'upstream' vendor your use is doing, because you can always do whatever you want in your own distro. Or better yet, you can take what upstream does, and use backports to get major core changes into your current version. And if that isn't enough, you can take a look at the many bistro-derivatives, including the likes of Ubuntu; they are (sometimes loosely) based on an existing long-term distro but with a lot of local modifications/replacements on top of that.
Because Valve is already making their own distro, it is unlikely to really matter what 'upstream' they use, the only big change would be the standards they uphold (be it packaging methods, like dpkg vs. rpm) or openness (DFSG vs. "I'll just drop this binary in here and see what happens later"). Better yet, if Debian wasn't a good fit, they could have gone with Ubuntu instead. Or any other derivative.
It smells like a 'we wanted something different but not really deal with licensing/legal' combined with 'the new guy runs arch on his Thinkpad so yeah'. In the end if matters a whole lot less than your average distro-war; Valve still just has a distro, they still release it, and they still support it. It's just more hobby-like than production-like at this time. Switching to some SONiC-SAI type architecture would have made more sense.
When you're doing it yourself, every Arch user seems to have a list of things which "aren't working today".
I've been using openSUSE Tumbleweed for a while, which has all the advantages of a rolling distribution like Arch (and their repo is enormous), but also comes with Yast, their frankly amazing graphical administration tool which handles everything.
It doesn't seem that common, at least in the USA, but I recommend it.
I think that having SUSE behind it maybe helps the stability? But I have no concrete knowledge of the testing process that goes into Tumbleweeed.
http://open.qa/ here, and the OpenSUSE specific instance here https://openqa.opensuse.org/
Worse for the user experience if users want to self-install stuff, but still.
having a frequently updated system ensure you're constantly exercising the code paths involved. and your change differential for regression testing is much smaller.
I actually used Arch as the base OS for a few linux computer labs (~100 machines) and it was both a joy and a headache. I really enjoyed being able to package proprietary software like Matlab & Mathematica. It was also nice that students had access to the latest software.
However, the stability of the boot process and upgrades was not fun. Identical machines running what should have been the same configuration would drift over time. I used Ansible to template a lot of the configuration but it would basically be a full time job to keep track of everything. Random machines would end up with a broken Pacman keyring causing updates to fail, etc. Somehow partial upgrades were occuring which would break the boot process.
While 90% of software was easy to package, the other 10% were research projects that would make a lot of assumptions regarding what system C++ libraries were available.
So far with NixOS, it is very stable. Unless you are activelly messing with the bootloader settings, it's almost impossible to break since you can select a previous configuration at boot time. While packageing software is not as easy as Arch, having a per-application dependency tree is extreamly helpful.
That said NixOS is currently going through a lot of changes and missing a few things: 1. No easy secure boot configuration. 2. Networking configuration is sort of in a flux between network-manager & systemd-networkd. 3. Packages are typically fairly up-to-date but the consistency is pretty variable.
TLDR; I am curious how Valve is handeling OS upgrades on the Steam Deck. My experience in using pacman -Syu in a unattended* manner was anything but smooth. I would not be suprised if system partitions are RO and/or updated via a disk image.
Overall Guix looked nice but it is very opinionated on the free-software issue which really hurts its adoptability. It is also a niche sibling of an already niche distro so I doubt it would be used in (real) production any time soon.
The community & related projects around NixOS are also very compelling. Structured flakes like devos [1] and developer tools like direnv/nix-shell make getting started very easy. I'm not sure if the same can be said about Guix (I'll admit I having been keeping a close eye on it). The darwin (MacOS) compatability is also a huge selling point since a lot of MacOS developers already need tools like Homebrew.
[1] https://github.com/divnix/devos
I agree that, at this stage Guix will have as much success as Hurd does in becoming a production ready system. But I do think there might be some form of borrowing between the Nix and Guix.
In my case however, I'd rather have an Arch-based system with NixOS's clean architecture.
Archlinux isn't much better when it comes to storage efficiency. Arch does not seperate out documentation and development libraries from the main package so there is quite a bit extra stuff in a lot of packages.
Valve can do a lot of things to save space like disable or delete the Pacman cache after every install. They could build their own repos/packages that stripped out documentation and development libraries.
Overall compared to the size of many games, the storage overhead of Arch or Nix is pretty minimal. At Valve's scale either can & probably will be tweaked to take up <10GB. I guess I forgot that the base model's storage is only 64GB. It makes me wonder if they are going to have optimised game downloads with lower resolution textures; many games would use ~10% of the space if the texture's were optimised.
Weird that the article doesn't mention KDE Plasma as I believe it's another reason why they need rapid development. They are finishing some huge migrations like Wayland and refining their theme and applications so it's even more accessible to less technical folks. I was scared to death when the reviewers were using Plasma docked because it needs a lot of testing before it's ready. That's natural when you are making big changes.
Is it because openSUSE Tumbleweed is less popular? Too "opinionated" / "customized, with Yast and all? Or just that (someone in) the team is more proficient in Arch?
openSUSE seems more robust than Arch overall, and especially for updates for which you are not particularly expected to read the document before updatinopenSUSE seems more robust than Arch overall, and especially for updates for which you are not particularly expected to read the document before updating [1].
It would seem that just using openSUSE Tumbleweed instead of Arch would mean less maintenance work for Valve because of this. I guess they need to test and validate updates before pushing them to the device anyway.
KDE/Plasma is also a first class desktop environment on openSUSE, so it would also be a good fit, since they are adopting this desktop environment.
Maybe Arch is more "KISS" and therefore easier to hack?
I also wonder if they considered Gentoo, which would help them tweak the (optimization-related) compilation flags for customized builds?
[1] https://wiki.archlinux.org/title/System_maintenance#Read_bef...