Arch Linux is amazing. The biggest surprise for me was that it's more stable than so-called stable distros, probably because the various packages don't end up drifting several months from each other when keeping up to date.
Hopefully this eventually results in more user friendly Arch Linux installers. The learning curve is an absolute wall when installing, even after several years on Linux, but after that it's pretty standard.
Based on this trajectory I expect they'll be migrating to NixOS (or maybe Nix on Arch) in about 5-10 years.
Ubuntu was likely too difficult for Valve to keep modified and up to date for their needs.
Canonical doesn't have any reason to be friendly towards the specific features Valve needs to make SteamOS a thing, and Valve probably doesn't want to maintain their own fork of the entire Ubuntu distro.
Not to mention, a default install of Arch is tiny and minimalist. It's the perfect base to apply your own packages on top of without having to worry too much about conflicts with system packages, or anything else that might break between Ubuntu LTS version updates.
It means Valve can mostly have their own custom distro without having to do most of the work required to maintain a custom distro.
It also means Valve can deploy the latest package of something that boosts gaming performance (like some new graphics driver or whatever), again, without jeopardizing the core os. Arch is well known for being "bleeding edge" and getting the latest packages out immediately which is something gamers (the target audience for SteamOS) want (every single extra FPS matters, etc).
Nix's existing support for Steam is pretty reliable as it is. Using Nix to distribute Steam would be awesome!
I'm not sure how ready Valve would be to require not only their own game distribution mechamisms but a whole package manager, but Nix + NixGL would be a very reliable and low-overhead way to get cross-platform support and to make it easy for games that might depend on extra libraries or specific versions of them.
> Hopefully this eventually results in more user friendly Arch Linux installers.
Pretty sure it won't. I bet it's going to use a self-made system upgrade facility and not rely directly on pacman either.
pacman is great for its intended use-cases, but it's not a package manager you want to use with no supervision of an experienced user. It may even silently leave a package in broken state just because the rootfs went full during the upgrade.
And at the very least, pretty sure they're not going to use actual Arch system repos but roll their own.
Because Valve's target is deterministic (relatively, hardware revisions not-withstanding) pacman is actually perfect for their use-case.
You can nail down a new release on your local hardware using a bash script that calls pacman against specific packages and specific package versions. Once your local dev works, push that to the update tool. Hopefully you caught all the bugs. :)
I'm not convinced packages need to care. Most config users care about on a SteamDeck is going to be Steam or game specific, so Valve are in a good position to put that on some mutable partition.
For the system data, which could be immutable, they could either take an A/B approach with two different partitions, or perhaps use either btrfs or ZFS to allow the new version to be applied over the old version as a 'diff' of the system partition. On a failed update, or to rollback for any other reason the system partition would simply be rolled back to the last snapshot.
Valve (as they did with Debian based previous versions of SteamOS) will maintain their own curated repository of packages, so they can control the versions of packages directly, no need to mess about forcing versions via pacman.
I just used the new arch installer script, even though I've gotten my install time down to under an hour over time. It took maybe 10 minutes. I don't have very complicated or unique needs, but it "just worked" on my 4 year old Thinkpad.
I just installed arch two days ago on my wife’s 2013 MacBook Air. I heard of a script. Googled around. Looked in the wiki. Didn’t find squat!
That being said arch on a 2013 MacBook Air is 10 minutes of cli and it runs like a champ!
When I built a new PC a couple months ago, my first OS on it was Manjaro - coming only from an Ubuntu/debian background. Linux has its limits but the experience is pretty seamless.
No, EndeavourOS is a nice, easy installer for Arch. You use Calamares and either select packages, or groups of packages in GUI, or/and provide a list of packages in a text file for Calamares to pick up during the install. You can even ignore Calamares altogether and just use Live OS to install Arch kind of the usual way, but from a comfort of a graphical environment; i.e., multiple pseudo TTYs, no need to configure WiFi, with a full-fledged GUI browser (Firefox), etc.
Manjaro Live OS can't be used to install vanilla Arch. Manjaro uses its own package repositories that differ significantly from the Arch repos, in terms of versions (which are held back for at least a couple of weeks) and in terms of which packages are available (quite a few AUR packages are present in the Manjaro's repositories).
I used to use Anarchy (or.. I think they had to change name?) but Arch itself has an installer new (as of last month or so), so I'll just use that next time.
I am testing it. Died on me when applying the desktop config, but I haven't been able to toy with it for long.
It is very, very promising. It spits a JSON that can be used for reproducible installs. It is also very flexible in which you can use the API with custom python install scripts. Very impressive and ergonomic.
Manjaro fired their treasurer for calling out misuse of funds. They tried to bundle paid freeoffice instead of libreoffice. They screwed up their SSL certs (twice). I'd avoid them.
There are different kinds of stability. For Debian it means version numbers stay the same as much as possible. For Arch it means software does not crash because bugs get fixed in newer versions.
>For Debian it means version numbers stay the same as much as possible.
I would call that stagnant rather than stable. If a version of software remains the same with the same bugs/issues not getting resolved, that seems unstable to me. Yes, not crashing could also be considered stable as well.
In production you want what-dylan604-calls-stagnant instead of running the latest of the greatest. Yeah, I get it that you run Arch Linux on your laptop which has zero production relevance (nobody cares if you blow it up). But on a production system, where other people rely on, you don't want sudden surprises. Or, well, maybe you do, but those people who rely on it certainly don't.
That only happens in old Stable, the previous version of Stable, or machines without internet, or machines which don't receive manual maintenance (otherwise you'd need apt install unattended-upgrades).
In Stable (what you call Stagnant) vulns get backported. Only the code fixing the vulnerability gets updated, the rest is left untouched. Its how Apple deals with older iOS versions, and it keeps their happy users of older devices happy.
If I run some old piece of hardware/software, there are a few things I want: I want it to keep functioning the way I bought it, and I want it to remain secure and reliable. So what I want is security and reliability fixes ie. what Debian Stable (and e.g. Ubuntu LTS) receives.
I was on about security and reliability fixes. These are applied when you run Stable, via Security repository, enabled by default. I was not on about Backports repository.
> For Arch it means software does not crash because bugs get fixed in newer versions.
....what. That is not how OS stability works.
Also, Arch is nearly impossible to use in production environments.
Let's say there is a vulnerability discovered in the version of lighttpd you're running in your production environment. On Debian, you pull that package, do some testing, and you're done.
On Arch? It's a rolling release distro. They're continuously updating everything, including system libraries. You can easily end up in a situation where getting a security bugfix means you have to update nearly the entire OS thanks to it being built against updated core system libraries.
Like Gentoo it's one of those OSs that is cool for linux nerds and a headache for people who actually need to practice proper systems engineering.
As someone who used Gentoo for over a decade, including in production environments - I disagree.
Its a falsehood pushed by old 80's thinking. It sounds nice, in theory.
In practice, what you often get are bugfix patches blindly applied to older codebases, oftentimes by people (distro maintainers) who are not very familiar with the codebase. As long as the patch applies, and it passes various tests.
Remember, most OSS projects - including some critical ones - do not have large teams of devs able to maintain multiple codelines in tandem. Usually, the dev(s) just work on the latest, and pay only cursory attention to applying security bugfixes to older versions.
After all, how is an OSS dev for proj X meant to know (or even give a damn for) which distro arbitrarily decided which older version is somehow the SECURE and BLESSED one.
The dev in question probably moved on from that version months (and in regard to Debian, probably YEARS) ago.
So in theory, what you said sounds right. In practice, no.
Production case study: ChromeOS is based on Gentoo.
I've also known a couple shops that run Gentoo as their distribution. Usually a central binary package host / build machine which makes it very easy to have a set of staging hosts. Just test package releases like normal before migrating them to prod.
Gentoo is perfect for proper systems engineering: Create a profile, and then manage what goes into it, in exactly the same way as you describe on Debian.
Just because it often works doesn't mean it's a good idea. Updating a single package is officially unsupported [0] and it's burned me personally on a number of occasions.
weel it's a bad idea unless you update just one package that doesn't have too many shared dependencies, things gets complicated with shared dependencies across their packages, so that's why it's better to run the full -Syu of course not automated but when you know what you are upgrading and possible manual interventions (if any) or caveats that you might have with the changes.
> Like Gentoo it's one of those OSs that is cool for linux nerds and a headache for people who actually need to practice proper systems engineering.
Fear not. As GKE is running on Container-Optimized OS which is based on Chromium OS which itself is based on Gentoo, you can safely practice proper systems engineering within the container environment :)
> The learning curve is an absolute wall when installing, even after several years on Linux, but after that it's pretty standard.
I'm surprised, I found it very easy to get into Arch linux. But I came from distributions like Slackware & Gentoo where it was common to do the installation almost entirely from commands in the terminal.
IMO distributions that keep the installation primarily command-line focused are a good way for beginners to get started, it gives them a real grasp of how linux works, and how to change things to suit.
I second this: Command-line and text files are more user friendly than it seems.
1/ You can search for stuff on the internet and get quick results (not a video)
2/ You can _paste_ a command and send it to someone to run it instead of a word document with instructions and screenshots.
3/ Once you learn to find and search for stuff in files, it is easy to discover where stuff is configured.
4/ Manual pages are great once you know how to read (I mean skim) them.
I really want to sell Valve on the Nixpkgs cross compilation work we've done someday. If anyone knows anyone there that would be interested in flawless Linux <-> Windows builds with all toolchain combinations, do let me know!
Currently we just support Unix -> Windows via MinGW. That's not good enough for AAA games.
But in the works is:
- https://github.com/NixOS/nixpkgs/pull/72366 Windows cross via LLVM and auto-downloaded MSVC runtime (you do need to indicate you signed the license, but that's it). I've heard of running cl.exe in Wine, and we could do that too
I’ve been following the nix-windows project, has there been any recent progress there? I already run NixOS on my home server, Nix and home-manager on my MacBook. It would be great to replace scoop on Windows with Nix too.
No progress on a nix-windows recently. I think the hardest part has just been keeping up with nix when we need to rewrite the build system.
However, https://github.com/NixOS/nix/pull/3160 to switch to Meson, has gotten new life breathed into it. Pamplemousse, who is interning where Edolstra works, is fuzzing Nix and needs Meson to make that less burdensome.
If that does get merged, than nix-windows can just be about Windows and not also be about Nix's build system, which will make it a lot easier to finish.
I share your feelings about Arch, but I'm still running Fedora mostly out of laziness.
Still, I think Arch is an interesting choice for a console. I'd think you'd want stability (in the sense of very controlled changes / not requiring updates every day).
My guess is that Valve will keep their own mirrors and update from upstream only once their relevant packages will be tested for compatibility.
I have been using Archlinux for more than 10 years and from time to time some major upgrades can make things broken for a couple days until all the packages get updated and all the relevant compatibility fixes have been pushed upstream by the developers.
But in most cases this happens with some 3rd party desktop related packages or closed source drivers. I bet that Valve won't have that many problems with AMD since their drivers are open source.
I could also see them running a read-only system partition with snapshots for updates. And with btrfs send/receive you could do 'system updates' with just incremental snapshots, and the ability to rollback.
The problem with Arch is that Arch needs to be tinkered with when Arch wants to be tinkered with, not when you want to spend an evening messing with your OS configuration. "This evening I want to learn about X," becomes "this evening I am learning about the linux userspace ecosystem," for every value of X.
Steam bundles its own runtime for games (it can be configured to use system libs instead, but that's not the default). Games will often also ship with copies of additional libraries not in steam's runtime.
I bet that the underlying distribution doesn't matter much at all, and since this console is meant to also be a desktop (or living room) PC, might as well ship with a distribution that's good for that purpose. Arch makes more sense for desktops than Ubuntu, and has for a while tbh.
Agreed. I've used Arch for about 12 years. My system has been unbootable after an update maybe 3 times. That's not bad really, and that's just applying updates daily. Any additional rigour should improve this a lot.
> it's more stable than so-called stable distros, probably because the various packages don't end up drifting several months from each other when keeping up to date
What are you precisely referring to with "packages drift from each other"? Stable distros like Ubuntu (and I suppose Debian) don't do release updates at all, only critical/security fixes only. Only some software has special treatment (browsers first of all) and get full updates.
> Hopefully this eventually results in more user friendly Arch Linux installers.
Funny you say that! Arch images now ship with an official installer as of a couple of months ago - which is comparable to the Ubuntu or Fedora installers in ease-of-use.
I think the thrust of sayings like "the learning curve is a wall" is to indicate that there is little to no slope, which is to say you don't get the benefit of time spent learning easier parts step by step until you know a lot of the system and can handle the more difficult aspects of it. Instead it feels like you either know how it all works or nothing about how it works, and it's hard to figure out how to start and get a foothold, so to speak.
That may be true now, but things have settled down a lot in general these last ten years or so. Before that things were often in a state of flux and things definitely broke on Arch regularly. The point is, Arch itself does nothing to give you stability. What you're seeing is just that the packages you're using are stable and bleeding edge doesn't mean what it once did.
Manjaro is nice, but last time I hit update the computer became un bootable until I found an afternoon to fix it. Kernel or grub iirc, not a big deal but still a bit disruptive. Ubuntu does this less a little less often
This brings back so many memories from around 17 years ago when I would try to do a dual install of arch linux with windows XP using the GRUB bootloader. Fun times! Can't believe it's been so long!
I highly recommend staying away from Arch and NixOS if you're not ready to commit upwards of 30% of your work and free time fixing and tweaking your box.
I've tried both, Arch Linux will routinely hose your entire install if you don't carefully read the update notes every time (even if most of the time there is no call to action for you). Unless it has changed, this is still the expectation of users.
NixOS promises stability, you just walk back to a previous version! Alas, i've had NixOS hose _all_ of my previous versions because of X server issues. Not only that, but the community of NixOS is hostile to getting shit done, if its not the NixOS way please stay away,
> I've tried both, Arch Linux will routinely hose your entire install if you don't carefully read the update notes every time (even if most of the time there is no call to action for you). Unless it has changed, this is still the expectation of users.
I'm honestly not quite sure what you're talking about. I've been using Arch as my daily driver for maybe 5 or 6 years, and I don't recall ever having my installation messed up from an update. Arch is fair bit along the spectrum of being a "build your own system from the ground up" type of deal though (although not quite as far along as something like Gentoo), so I don't doubt your experience, given how much two Arch installations can differ.
I've had Arch on 3 servers for 5-6 years also and only had a couple of incidents where Arch updates messed things up.
But one of those was a big compatibility breaking one that I hadn't done the prep for (because I'd missed the whole lead up for various reasons and was months late on the update anyway) and I still can't really explain the other.
Compared to Debian which I managed to break many times in the same time frame...
> Compared to Debian which I managed to break many times in the same time frame...
How did you exactly break Debian multiple times?
I've read about people doing crazy stuff, like replacing the default compiler entirely (rather than setting an alternative one) or forcing apt to install incompatible packages... and then complaining that the distribution is not stable.
Non-rolling distros are very very conservative with package upgrades, and they don't "just break", as little changes over a given version.
Generally Debian breaks come from a mission critical software that isn't really available and requires package updates beyond what your version does or from trying to force an update. Also twice dpkg just shat the bed for no reason, but that was 7 and 8 years ago.
> How did you exactly break Debian multiple times?
Alas, I can't remember exactly what happened but it was the late 1990s/early 2000s - no crazy stuff involved, just things getting confused / crashing whilst doing updates and leaving things half-arsed and broken.
You started using arch after it became stable. I've been using arch for a decade and Voxl's description of a `pacman -Syu` just completely hosing your system used to happen a lot more back then, but I haven't had an issue like that at all in the past 5-6 years.
> NixOS promises stability, you just walk back to a previous version! Alas, i've had NixOS hose _all_ of my previous versions because of X server issues.
I'd love to hear more detail about this, because `nixos-rebuild switch` is not capable of causing such a problem in a permanent way.
(It can arise temporarily, though, if you switch to a new configuration without rebooting, and that configuration requires a different kernel than you are currently running. Rebooting and choosing your old configuration at the bootloader menu fixes this.)
I've run Arch for years and this in no way resembles my experience.
Yes, Arch requires you manage and maintain your system, it's not a "just works" thing, but that's a few minutes of work here and there, it mostly just chugs along.
As to hosing your install, I've never had even the threat of that. Yes, you should check the news before doing upgrades to make sure there isn't something that requires your attention, but it's not exactly a big deal to check an RSS feed before you run an update command.
> I highly recommend staying away from Arch and NixOS if you're not ready to commit upwards of 30% of your work and free time fixing and tweaking your box.
I started using Arch back in 2011 and Manjaro (Arch-based) in 2018. Besides a day or two of initial setup, getting things how I like, I spend ZERO time tweaking or fixing my installation. Your warning simply does not match up with my experience.
I have my home server/router running Arch, update maybe 5 times per year, only one time a non-critical service(redis) failed to start due to a default config option change. I originally meant to run Debian on that, but when I bought the hardware, it's pretty exotic for Debian's old kernel, and Arch ran great.
I also have a Pi2 running Arch ARM at my mom's house, doing one or two updates per year when I visit her, also failed only once, and that's because of a corrupted SD card.
I'd admit I'm usually a bit nervous typing pacman -Syu on those two, but it's doing surprisingly great.
You’d probably have less overall risk on upgrades if you actually did it more often. A couple of times a year can result in quite a jump when using a rolling distro
I never read the update notes and the only time I've ever bricked my Arch system was by pulling the power chord during an update. I probably could have recovered from live cd, but it didn't seem worth it.
I bricked my system once due to not reading release notes (but that was closer to 2010 than 2020). Release notes were kind enough to outline solution for systems broken due to not reading the release notes.
However, I stopped using arch mainly because I was working with ROS at the time, where every boost upgrade triggered half-a-day recompilation of ROS and it's various plugins.
Arch Linux sucks. Its the default OS on the Pinephone which I use as a backup smartphone (main smartphone is Android). I'm used to running Debian, which is rock stable. Arch Linux? I get dependency issues when I'm running the software update installer. Not once or twice, all bloody time. I mean, WTF? How would anyone want such in production???
NixOS is more sane because it has roll backs, and declarative configuration is like a gigantic black hole eating everything which was known before it.
To be fair, that's Arch Linux ARM, which is technically a separate project. The pinephone arch linux arm repositories aren't even maintained by the official project.
That said, I've had no such issues running Arch on my pinephone.
I think its Manjaro by default but that's based on Arch. It follow exactly the same principles.
I've had the same problem on Arch Linux on my desktop. To be fair, I was using AUR, but without that there's far less software (less than Ubuntu I suppose). So what I did was trying out Arch Linux on a separate NVMe during some free time, learning some specific tools (it also has NixOS installed on another partition for the same purpose). I come back after a while, want to update my OS first because that is the first thing I do when I use any computer. What ya know? Boom, dependency issues. I really do not want to deal with that before I can use a tool. And every time I bring this up I get these replies "I never have issues with Arch". Sure thing, I must be special.
Look, I ran Debian Testing and Unstable for a while before Arch was cool (1999 - 2003 era). That way I could run Linux with tools such as a decent package manager, while running recent software. But this was a different time, and not mission critical computers.
pacman is pretty amazing package manager - I would be curious to know more about your dependency issues.
I suppose it could have been a temporary bug in Manjaro (which started as an Arch derivative but turned into a separate distro with links to Arch - the repositories are different).
I would recommend following the wiki and installing Arch Linux (I know, no UI) over Manjaro to have a true Arch experience.
That said, AUR is the reason I use arch linux, because there are scripts to install pretty much anything in a frictionless way.
When installing esoteric stuff the dpkg / apt repositories dance gets old pretty quickly on debian derivates. Often I would just install things on the system instead of creating my own deb. On Arch Linux I can often find a package in AUR (or quickly write a PKGBUILD).
Upgrading the system every few months and breaking a lot of things all at once (making a reinstall the easiest option) is also not very appealing in my book.
I prefer the rolling release model which gives me the latest update immediately and let me fix things once at a time.
That said, anyone has its own preferences, no need to bad mouth distros.
Hopefully this eventually results in more user friendly Arch Linux installers. The learning curve is an absolute wall when installing, even after several years on Linux, but after that it's pretty standard.
Based on this trajectory I expect they'll be migrating to NixOS (or maybe Nix on Arch) in about 5-10 years.