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).
SteamOS was based on Debian directly, not Ubuntu. Ubuntu is just what they officially support for the desktop Steam client.
I wonder if they considered alpine? Though arch is a fine choice and makes me want one all the more!
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.
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.
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. :)
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.
It's more than an installer. Manjaro and Arch don't even share repositories.
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).
Only recommend using them for subsequent installations. You have to get the basics right first, so you can troubleshoot anything in the arch forums
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.
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 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.
This isn’t always possible. And sometimes creates more problems than it solves or ends up not mitigating the issue completely.
In any case, backporting is a slower process. And back ports for non-stable are not done by the security team but volunteers.
....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.
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.
Seen it done and participated.
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.
People have used Arch in prod. But personally I'll still use Debian to be on the safe side despite all of the issues that comes with.
[0] https://wiki.archlinux.org/title/System_maintenance#Partial_...
But sure, just yoloing a single package upgrade can break things, obviously.
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 :)
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.
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.
Thanks for playing games on NixOS!
https://nix.dev/tutorials/cross-compilation#cross-compilatio... for an approachable introduction.
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
- https://github.com/nix-windows/nix Windows port of Nix
We finish these things up, and then we have the flawless Unix <-> Windows I advertised.
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.
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).
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.
Or just use packages and make regular snapshots.
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.
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.
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.
- Able to connect to WiFi from within the installer.
- Full-disk encryption setup, ideally with a single checkbox like Ubuntu.
- Interactive partitioning.
- Auto-detects or allows choosing between BIOS/UEFI.
- Supports creating a NetworkManager-based network setup, so that I don't have to switch network managers after installation.
However I do welcome an installer, it's fun to install Arch a couple of times, but after that I'm not really learning anything new.
Thus your expression "an absolute wall" would mean that you immediately grasp everything there is to know.
But since the meaning since has unintentionally shifted and the original meaning is universally ignored, we all understand you.
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'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.
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...
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.
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.
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.)
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 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 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.
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.
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.
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.
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.
Not really, unless you did everything with a GUI in other distros before and refused to learn anything about the underlying guts of the OS.
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.