The Arch Linux team is now working directly with Valve(tomshardware.com)
tomshardware.com
The Arch Linux team is now working directly with Valve
https://www.tomshardware.com/software/linux/the-arch-linux-team-is-now-working-directly-with-valve-steamos-and-arch-should-both-benefit-greatly
112 comments
I think the pick for Arch makes a lot of sense if you consider the big players in the ecosystem:
* Debian habitually ships ancient versions of software unless you setup backports. It's also by far the distro that makes the most downstream modifications to software, which causes issues with upstream.
* Ubuntu is a semi-rolling (basically, a stable copy every 9 months) release of Debian + Backports with a Canonical skin and nice branding. Cute, but it inherits the same problems that Debian has.
* Fedora is fine, but it's also very beholden to Red Hat. Whilst Red Hat going IBM squeeze mode occurred after Valve picked a distro, the ties it has to Red Hat are a problem for Valve, considering their Linux push was always defined by not wanting to be tied as heavily to a third-party vendor (it almost entirely originates from Microsoft blowing their left foot off with Windows 8 and the Microsoft Store being both awful and a direct competitor to Valve; Gabe Newell is an ex-Microsoft employee, he probably recognized the direction MS is going in). Also, major system upgrades with Fedora aren't exactly the greatest process; they work, but since they're inheriting the CentOS structure, Fedora isn't really build around that sort of thing. I've always had to do manual checkups on key software when using Fedora.
By contrast Arch has a policy to "ship as close to upstream as possible" (even in cases where it's weird; last I checked, their nano still has the bad word wrap that nano is known for), pushes out updates extremely quickly and is a non-profit. With Valve having their own button on the upgrade process, they can also ensure that you don't get some of the more typical "hilarity" of running Syu and realizing your drivers made it so you ended up in an emergency shell mode.
Other distros just don't have the installbase to guarantee consistent support (everything on distrowatch) or are too inaccessible for regular users (aka "why not NixOS" -> because NixOS actively requires you to ignore almost every online resource and to only use the NixOS provided documentation since nothing else on the planet works the way NixOS does. Gentoo also is in this category, since most people that own a Steam Deck probably aren't looking to custom compile everything.)
* Debian habitually ships ancient versions of software unless you setup backports. It's also by far the distro that makes the most downstream modifications to software, which causes issues with upstream.
* Ubuntu is a semi-rolling (basically, a stable copy every 9 months) release of Debian + Backports with a Canonical skin and nice branding. Cute, but it inherits the same problems that Debian has.
* Fedora is fine, but it's also very beholden to Red Hat. Whilst Red Hat going IBM squeeze mode occurred after Valve picked a distro, the ties it has to Red Hat are a problem for Valve, considering their Linux push was always defined by not wanting to be tied as heavily to a third-party vendor (it almost entirely originates from Microsoft blowing their left foot off with Windows 8 and the Microsoft Store being both awful and a direct competitor to Valve; Gabe Newell is an ex-Microsoft employee, he probably recognized the direction MS is going in). Also, major system upgrades with Fedora aren't exactly the greatest process; they work, but since they're inheriting the CentOS structure, Fedora isn't really build around that sort of thing. I've always had to do manual checkups on key software when using Fedora.
By contrast Arch has a policy to "ship as close to upstream as possible" (even in cases where it's weird; last I checked, their nano still has the bad word wrap that nano is known for), pushes out updates extremely quickly and is a non-profit. With Valve having their own button on the upgrade process, they can also ensure that you don't get some of the more typical "hilarity" of running Syu and realizing your drivers made it so you ended up in an emergency shell mode.
Other distros just don't have the installbase to guarantee consistent support (everything on distrowatch) or are too inaccessible for regular users (aka "why not NixOS" -> because NixOS actively requires you to ignore almost every online resource and to only use the NixOS provided documentation since nothing else on the planet works the way NixOS does. Gentoo also is in this category, since most people that own a Steam Deck probably aren't looking to custom compile everything.)
Minor nit pick, but gentoo has had binary downloads since dec 2023 and has supported binary updates for years
https://www.gentoo.org/news/2023/12/29/Gentoo-binary.html
https://www.gentoo.org/news/2023/12/29/Gentoo-binary.html
And if Gentoo's binary support is good enough for even ChromeOS, I'd imagine it'll also work perfectly fine for SteamOS.
What I don't like about Debian is that they have several names for releases which are difficult to remember (for example, a distribution can be called "Bookworm" and "stable" at the same time and later it is not "stable" anymore). It would be much easier if they just used numbers everywhere and added names in brackets.
Debian also has version numbers (11, 12, 13) but people prefer the names releases for some reason.
I don't mind the names too much, and I don't even mind the moving "stable" name, but I do get confused because Debian's names don't necessarily increment. Ubuntu made the smart decision to make their names alphabetical and that helps tremendously when you're trying to guess how recent a particular version is.
I don't mind the names too much, and I don't even mind the moving "stable" name, but I do get confused because Debian's names don't necessarily increment. Ubuntu made the smart decision to make their names alphabetical and that helps tremendously when you're trying to guess how recent a particular version is.
Ubuntu alphabetical names help if you keep up with it. I can name various releases of the past, like debian, and don't know which is the latest one.
And with numbers you don't need to remember anything, especially if they are release years.
The main reason they picked Arch is the rolling release model with updates from upstream projects they work with landing quickly and continuously.
So yes, TH's speculation is just off the mark here.
So yes, TH's speculation is just off the mark here.
...so they picked a rolling release distro to take snapshots of and distribute outdated versions to their users. Plasma in SteamOS 3.6 (current beta) is still at version 5.27, just like in Debian stable.
The main reason they switched were PKGBUILDs. Debian packaging, while much more powerful, requires more effort, and yet they weren't going to reap its fruits as their distro gets fully reinstalled on each update anyway. Nothing else matters much for their particular use-case. If it was about fresher base system, they could have gone with snapshots of sid instead, which would have been easier as previous SteamOS versions were already Debian-based.
The main reason they switched were PKGBUILDs. Debian packaging, while much more powerful, requires more effort, and yet they weren't going to reap its fruits as their distro gets fully reinstalled on each update anyway. Nothing else matters much for their particular use-case. If it was about fresher base system, they could have gone with snapshots of sid instead, which would have been easier as previous SteamOS versions were already Debian-based.
About releases: They typically refer to the OS version or base in these rolling distros such as Fedora. Rolling releases aren't all like Sid.
In Fedora, there is a base OS version with a sort of configuration, specif directory structure, major architectural versions of software (like Gnome or KDE), sometimes cryptographic policy, or other system backends such as logging or DNS resolution.
Fedora used its release cycle to migrate to systemd-resolved, to pick an example, because this change introduced structural changes to the way the system operated. In the release in question, system services leverage the D-Bus API to get DNS lookups, systemd binds to the local port. By segregating this behavior by release, it makes the dependency tree much simpler to manage at the cost of possibly needing to backport patches, but Distributions are doing much more than shipping mostly upstream packages like Arch is.
I always thought arch would be well suited to this sort of thing. Arch Build System is very good, and since packages are very close to upstream, it would be very easy to make your own ABS repo as it stands. It is very similar to the ports tree, arch linux has very little flavor in many respects.
In Fedora, there is a base OS version with a sort of configuration, specif directory structure, major architectural versions of software (like Gnome or KDE), sometimes cryptographic policy, or other system backends such as logging or DNS resolution.
Fedora used its release cycle to migrate to systemd-resolved, to pick an example, because this change introduced structural changes to the way the system operated. In the release in question, system services leverage the D-Bus API to get DNS lookups, systemd binds to the local port. By segregating this behavior by release, it makes the dependency tree much simpler to manage at the cost of possibly needing to backport patches, but Distributions are doing much more than shipping mostly upstream packages like Arch is.
I always thought arch would be well suited to this sort of thing. Arch Build System is very good, and since packages are very close to upstream, it would be very easy to make your own ABS repo as it stands. It is very similar to the ports tree, arch linux has very little flavor in many respects.
Fedora isn't a rolling distro the way Arch is. And even Arch while popularly known as a rolling release distro doesn't entirely live up to this ethos. Python 3.12 & Gnome release delays just to give an example.
Fedora has something that resembles Arch as a rolling distro. Their unstable branch for development which they call Fedora Rawhide.
That said you wouldn't be wrong to call Arch a rolling release distro because it is one for the most part.
Fedora has something that resembles Arch as a rolling distro. Their unstable branch for development which they call Fedora Rawhide.
That said you wouldn't be wrong to call Arch a rolling release distro because it is one for the most part.
You are working off an unusual definition of "rolling release". A rolling release just means that there are no major version bumps that require an active opt-in when upgrading.
And besides, the behavior of Fedora Rawhide can easily be achieved in Arch Linux by just adding the [testing] repo that's already prepared (but commented out) in your /etc/pacman.conf
And besides, the behavior of Fedora Rawhide can easily be achieved in Arch Linux by just adding the [testing] repo that's already prepared (but commented out) in your /etc/pacman.conf
> A rolling release just means that there are no major version bumps that require an active opt-in when upgrading.
Indeed. However IMO this definition is not complete without taking into account the matching status of upstream software versions available and package versions made available by the distro at any given point in time. This is the continuous delivery expected and what gives a distro rolling status among its peers.
Indeed. However IMO this definition is not complete without taking into account the matching status of upstream software versions available and package versions made available by the distro at any given point in time. This is the continuous delivery expected and what gives a distro rolling status among its peers.
> Python 3.12 & Gnome release delays just to give an example.
GNOME updates usually come when the packagers have time, latest this usually is the .1 release. 47 for example was available like a few days after the official release, if not a day or so after (I didn't check specific dates, but that was when I updated).
With other software it usually depends on if dependencies can work with the new version. LLVM is a major package that always is like 1 release behind due to stuff that depend on it not being updated for the new version. And shipping multiple of a single package is something they try to avoid.
GNOME updates usually come when the packagers have time, latest this usually is the .1 release. 47 for example was available like a few days after the official release, if not a day or so after (I didn't check specific dates, but that was when I updated).
With other software it usually depends on if dependencies can work with the new version. LLVM is a major package that always is like 1 release behind due to stuff that depend on it not being updated for the new version. And shipping multiple of a single package is something they try to avoid.
> they picked it is that it is smaller and less commercial than others (such as Debain or Ubuntu)
I agree with you, just nitpicking: it is smaller than some (like Debian) and less commercial than others (like Ubuntu).
I agree with you, just nitpicking: it is smaller than some (like Debian) and less commercial than others (like Ubuntu).
> I am not sure Arch is going to be faster for gaming than any other distro, but I can see why Valve picked it for a minimalist base.
it does go hand in hand. The max potential may not be faster, but if you have the time and expertise to hyperoptimize, getting those bits of power out can be crucial.
it does go hand in hand. The max potential may not be faster, but if you have the time and expertise to hyperoptimize, getting those bits of power out can be crucial.
NixOS could have been good alternative as well and probably easier to maintain / develop, but I'm sure Arch as base takes less space than NixOS.
While I love NixOS and use it personally, IMO it's just too different from standard linux distros to be able to use it in a consumer-facing device, that offers users the ability to look under the hood.
It would've probably lead to massive confusion due to users not getting the "nix-way" and it seems like easy hack-ability is part of the steam-decks value proposition.
It would've probably lead to massive confusion due to users not getting the "nix-way" and it seems like easy hack-ability is part of the steam-decks value proposition.
While I agree that Nix is not user friendly, Nix would allow more hack-ability than the current Arch approach.
The Steamdeck modifications often get broken in updates, because the Steamdeck software is an image that is managed by Valve. Meanwhile, with Nix I think it would be easier to maintain modifications, as you could layer them on top of each other.
Also, most Steamdeck users:
- Don’t modify their Steamdeck
- Use Flatpak, which works on Nix
- Run an install script from the internet, such as DeckyLoader, Emudeck. Which often break with updates.
The Steamdeck modifications often get broken in updates, because the Steamdeck software is an image that is managed by Valve. Meanwhile, with Nix I think it would be easier to maintain modifications, as you could layer them on top of each other.
Also, most Steamdeck users:
- Don’t modify their Steamdeck
- Use Flatpak, which works on Nix
- Run an install script from the internet, such as DeckyLoader, Emudeck. Which often break with updates.
The arch used in steam deck is already used as a immutable base. Users typically use flatpak to install custom software. It's possible to remove the read-only lock, but any modifications to base will get overwritten by updates.
Seen from a certain angle, the real question is: why don’t more companies do this? This isn’t charity, this is enlightened self interest paired with understanding that pissing off your free supplier is a bad idea.
I'd say half of it comes down to Valve having the staff with the key knowledge and skills to provide support, and the other half comes down to not being public.
I'm sure many devs and publishers are filled with people who know that acts like this can garner trust and future support for their company, but will have efforts cut short because someone above complained that the line didn't immediately go up.
I'm sure many devs and publishers are filled with people who know that acts like this can garner trust and future support for their company, but will have efforts cut short because someone above complained that the line didn't immediately go up.
> the other half comes down to not being public
In every service or product I've bought, going public (and prep to go public) has preceeded a decline in quality. The day Valve goes public will be the day its downward trend starts, because its customers become the shareholders.
In every service or product I've bought, going public (and prep to go public) has preceeded a decline in quality. The day Valve goes public will be the day its downward trend starts, because its customers become the shareholders.
>why don’t more companies do this?
What exactly?
Whole big tech contributes to linux. MSFT is probably biggest of them
What exactly?
Whole big tech contributes to linux. MSFT is probably biggest of them
Wasn't Microsofts biggest Linux contribution the code to make it run on Microsofts Hyper-V ? From what I understand their only other major contribution is the Rust project that ran head long into a wall.
Jup it's crazy that people still think Microsoft (the "We Love Linux initiative") did anything big apart from let Linux run good on their Hypervisor, Oracle for example did 100x more then MS (yes oracle...).
> why don’t more companies do this?
1. Support is expensive for the layman/small business, but peanuts for large companies compared to hiring their own experts. And faster to ramp up/down. The strong arming stuff like Adobe can do to companies is mitigated when you can hire PR/Dev relations dedicated to strong arming their support companies.
The peanuts add up, but it's not like most companies these days are thinking long term.
2. Liability is almost as important as support. Being able to point fingers to someone else during disaster (e.g. Crowdstrike) can also save a lot of money for companies taht have lawsuits thrown at them 24/7. A small linux team won't want to claim liability. it's pretty much the main "downside" of most FOSS licenses.
1. Support is expensive for the layman/small business, but peanuts for large companies compared to hiring their own experts. And faster to ramp up/down. The strong arming stuff like Adobe can do to companies is mitigated when you can hire PR/Dev relations dedicated to strong arming their support companies.
The peanuts add up, but it's not like most companies these days are thinking long term.
2. Liability is almost as important as support. Being able to point fingers to someone else during disaster (e.g. Crowdstrike) can also save a lot of money for companies taht have lawsuits thrown at them 24/7. A small linux team won't want to claim liability. it's pretty much the main "downside" of most FOSS licenses.
Because it's money, and not doing that barely impacts them. Valve is always more prosocial than other companies because they have an infinite money spigot as long as everyone likes them, so prosociality is their business model.
No other OS is as configurable, adaptable and versatile as Linux. It runs on the biggest super-computers, on the helicopter that flew on Mars, on the server that is hosting this service and on the device I'm typing just now.
Now, just imagine... just imagine how much performance could be gained if game vendors didn't ignore it.
Now, just imagine... just imagine how much performance could be gained if game vendors didn't ignore it.
> on the server that is hosting this service
I’m not sure if it changed, but last time I heard HN was running on FreeBSD: https://news.ycombinator.com/item?id=16076041
> just imagine how much performance could be gained if game vendors didn't ignore it
In the case of FreeBSD, Sony used it as the base for the OS on PlayStation since PS3.
I’m not sure if it changed, but last time I heard HN was running on FreeBSD: https://news.ycombinator.com/item?id=16076041
> just imagine how much performance could be gained if game vendors didn't ignore it
In the case of FreeBSD, Sony used it as the base for the OS on PlayStation since PS3.
> No other OS is as configurable, adaptable and versatile as Linux.
BSD wants a word with you.
From games consoles to core internet devices powering the packets to enable you to post.
Linux may be having an up-trend at the moment but BSD has already been there and still is.
BSD wants a word with you.
From games consoles to core internet devices powering the packets to enable you to post.
Linux may be having an up-trend at the moment but BSD has already been there and still is.
Yes, BSDs are great technically and popular enough to be noticeable.
Unfortunately, most of BSD innovation stays locked behind proprietary forks.
Unfortunately, most of BSD innovation stays locked behind proprietary forks.
> BSD wants a word with you.
BSD is great for many things, but hardware support is sadly behind. I'm a Linux guy but I run both XigmaNAS as my server and OpnSense as firewall on two different platforms, and all their WiFi and Bluetooth chipsets are unsupported, especially 802.11ac is way behind. Not that I'd use all of them on those machines for security implications, but having them supported could be handy sometimes.
BSD is great for many things, but hardware support is sadly behind. I'm a Linux guy but I run both XigmaNAS as my server and OpnSense as firewall on two different platforms, and all their WiFi and Bluetooth chipsets are unsupported, especially 802.11ac is way behind. Not that I'd use all of them on those machines for security implications, but having them supported could be handy sometimes.
If the complaint is WiFi and co, that's not the fault of BSD.
That's the fault of vendors not opening up their proprietary firmware blobs up to other systems.
That's the fault of vendors not opening up their proprietary firmware blobs up to other systems.
Saying "complain to vendors" isn't an answer for 99% of users (unless you're a corporate user who vendors will listen to) and basically translates to "it's not worthwhile for you to pick it".
Basically it's the equivalent to a shrug; means you can't do anything with it.
Basically it's the equivalent to a shrug; means you can't do anything with it.
Nobody here is blaming *BSD for not supporting closed hardware: it's a huge effort whose failures are entirely on manufacturers' stubborn refusal to cooperate with anyone that isn't a corporation. Unfortunately that's the reality we must live in today. The point is that Joe User doesn't give a damn about installing closed blobs that can't be examined nor updated, he wants his machine to work, and if it doesn't, he blames the software while switching to something that supports his hardware.
So it could be as versatile as Linux if someone would actually make it versatile? Does not sound very versatile at all.
BTW BSD had its last release in 1995, so you probably mean something else.
BTW BSD had its last release in 1995, so you probably mean something else.
And the RT patches are making it to upstream, which together with the userland sched can make a huge difference in frame rates and latency when gaming.
RT is entirely about guarantee regarding response time. It is generally overall slower than non real time in basically any scenario where it doesn’t matter. Video games are purposefully written so as not to be latency critical so RT would be a net loss.
I reckon it might be interesting for esports, those types of games where people turn graphics settings way down and purchase very overpowered hardware go push FPS into hundreds, resulting in lower latencies.
Since RT sacrifices throughput for latency you would likely se a drop in FPS, which inturn would also reduce the input processing frequency. sched_ext is much more interesting in that regard as IIRC lavd[1] is for example designed to (ab)use the frequent repetitive access/processing patterns of game engines
[1]: https://github.com/sched-ext/scx/tree/main/scheds/rust/scx_l...
[1]: https://github.com/sched-ext/scx/tree/main/scheds/rust/scx_l...
Generally slower at completing long tasks, sure, but is that the real workload of the Deck?
I feel that there's enough aspects and subtleties to consider that I wouldn't trust anyone, particularly not myself, to guess how things are really going to fare. We will likely have a phase of experimentation and tweaking that will improve things with and without RT patches as more workloads are considered and things are ironed out.
I feel that there's enough aspects and subtleties to consider that I wouldn't trust anyone, particularly not myself, to guess how things are really going to fare. We will likely have a phase of experimentation and tweaking that will improve things with and without RT patches as more workloads are considered and things are ironed out.
[deleted]
I doubt they wanna run an RT kernel in SteamOS. There are severe costs to doing so.
Are there some benchmarks for that, or a good discussion somewhere?
Because I was wondering about that myself. RT kernel sounds at first like it may help achieve better latency in games, but then you are so deep in the stack and depending on overall performance, that the costs of RT mode might hurt much more than one would gain. But I don't really know how that plays out in practice.
Because I was wondering about that myself. RT kernel sounds at first like it may help achieve better latency in games, but then you are so deep in the stack and depending on overall performance, that the costs of RT mode might hurt much more than one would gain. But I don't really know how that plays out in practice.
I don’t know. My understanding though is that RT Linux adds predicability at the cost of throughput. For games where CPU throughput isn’t important (like an action game where most of the work is pushed off onto the GPU) this would maybe help. Someone could certainly try. But for other games like many strategy games and simulations where the CPU is a limiting factor, there would likely be a cost.
The problem is that it’s not a free win, and games are very varied. But theoretically, on something like a console, you could offer choice.
The problem is that it’s not a free win, and games are very varied. But theoretically, on something like a console, you could offer choice.
My understanding is that real-time isn't so much about lower latency (though that is also desirable), but rather about predictable, bounded latency. For the purposes of gaming, no amount of predictability at the kernel level will reduce the amount of work you need to perform to draw a frame, and that is the real limiting factor for most games.
> For the purposes of gaming, no amount of predictability at the kernel level will reduce the amount of work you need to perform to draw a frame, and that is the real limiting factor for most games.
It all depends on what you're trying to optimize for. You can maximize raw framerate numbers by having an unlimited frame queue depth, but it'll feel like shit because you won't have even frame pacing and your input latency will vary wildly. The ideal scenario in gaming is for your draw time to be perfectly deterministic, and be able to schedule things so you can read input and do your render calls just before vsync.
It all depends on what you're trying to optimize for. You can maximize raw framerate numbers by having an unlimited frame queue depth, but it'll feel like shit because you won't have even frame pacing and your input latency will vary wildly. The ideal scenario in gaming is for your draw time to be perfectly deterministic, and be able to schedule things so you can read input and do your render calls just before vsync.
> how much performance could be gained if game vendors
It might not even be the fault of vendors or their developers.
GPU drivers are still a bit of a pain to non technical users outside of PopOS. They need to "just work" transparently to the user or they'll just leave for Windows.
And game devs tend to use a premade engine - that engine needs to have good support for both Windows and Unix, or they will just default to the bigger market: Windows. So that's another important driver in migration to Unix.
I frequently find the best way to game on Unix is to either dual boot or install a Windows VM
It might not even be the fault of vendors or their developers.
GPU drivers are still a bit of a pain to non technical users outside of PopOS. They need to "just work" transparently to the user or they'll just leave for Windows.
And game devs tend to use a premade engine - that engine needs to have good support for both Windows and Unix, or they will just default to the bigger market: Windows. So that's another important driver in migration to Unix.
I frequently find the best way to game on Unix is to either dual boot or install a Windows VM
I recently tried PopOS because of it's benefits for having GPU drivers configured out of the box and was told that it would "just werk". And to be fair to it, it did mostly just work (ignoring unintuitive UX decisions in the OS generally). But I also spent two days trying to get Steam to show at the correct scale and eventually gave up.
The recent 560 drivers for Nvidia also broke the "it just works" nature of Pop!_OS. I run it on my home desktop and managed to dodge that update. As far as I know, those drivers still break some games and have broken DX3D 12 support for Proton games.
This means I have to manage package updates manually instead of just taking the "System Updates" through the UI.
I say all of that, but I'm still far happier to be Windows-free (Linux at home, OS-X for work).
This means I have to manage package updates manually instead of just taking the "System Updates" through the UI.
I say all of that, but I'm still far happier to be Windows-free (Linux at home, OS-X for work).
Nvidia Linux drivers have always been a pain in the ass. My previous computer when ever either the driver or the kernel updated would the Nvidia driver would shit itself and boot to a black screen until I switched to single user mode and totally uninstalled and purged any configuration files for them then reinstalled them. I got to where I could type the comands blind on the black screen without single usermode letting me see the terminal I was working in.
I think that’s just an issue with Steam on Linux, surprisngly. As much as I love Steam sometimes they just leave fundamental things like that unfixed.
They don't ignore it, it powers many servers, and the games on Android and ChromeOS.
Additionally PlayStation OS is based on a FreeBSD fork, and the Switch mikrokernel OS still has a POSIX flavour to it, to the extent that it matters for C and C++ standard libraries.
What they ignore is the desktop mess, and lack of paying customers outside platforms where people are willing to pay even for fart apps.
Additionally PlayStation OS is based on a FreeBSD fork, and the Switch mikrokernel OS still has a POSIX flavour to it, to the extent that it matters for C and C++ standard libraries.
What they ignore is the desktop mess, and lack of paying customers outside platforms where people are willing to pay even for fart apps.
And now Real-Time support is getting mainlined, which means we might see even more stuff like Mars Rovers running Linux.
What did mainlining it change from the industry point of view? I recall installing in minutes the -rt fork from official Debian repositories ages ago, mainly to have lower/more consistent latency with music apps, and never had a problem.
Official support, and more eyes seeing it. Maybe better integration since they'll need to make it integrate fully to reach mainstream kernel.
"In the long-term, the funding touted should, at minimum, allow Arch Linux to improve the security of its distribution and provide more structured releases compared to its current near-continuous update cycle."
Isn't rolling release one of the core ideas behind arch? Sounds like the usual gaming journalism...
Isn't rolling release one of the core ideas behind arch? Sounds like the usual gaming journalism...
[deleted]
Yes, and it's also one of the features Steam likely wants, given all of the work they're doing upstream, they'll want those changes ASAP.
I'm still hoping to see an official immutable version of Arch Linux.
SteamOS is immutable, and I'm "stuck" using Fedora Silverblue [1] because immutable is the future and I won't go back to installing stuff manually while cruft accumulates in system directories. I don't interact often with rpm, but I hate them with a passion, while I used to maintain multiple Archlinux packages as it was so easy to do.
1: Silverblue host, but working within an Arch Linux container with Emacs, of course. Imagine having to maintain all the five dozen LSP servers and dev tools without access to the AUR.
SteamOS is immutable, and I'm "stuck" using Fedora Silverblue [1] because immutable is the future and I won't go back to installing stuff manually while cruft accumulates in system directories. I don't interact often with rpm, but I hate them with a passion, while I used to maintain multiple Archlinux packages as it was so easy to do.
1: Silverblue host, but working within an Arch Linux container with Emacs, of course. Imagine having to maintain all the five dozen LSP servers and dev tools without access to the AUR.
> Valve is now providing a build service infrastructure
Fingers crossed this means Arch will support the ARM architecture* in the official repositories. There's a related RFC which has been accepted but but I'm not sure where things stand right now.
https://rfc.archlinux.page/0032-arch-linux-ports/
* I'm well aware of Arch Linux ARM but that's a separate project with even less resources (missing packages, some broken). Asahi used to use it before moving to Fedora due to similar problems.
Fingers crossed this means Arch will support the ARM architecture* in the official repositories. There's a related RFC which has been accepted but but I'm not sure where things stand right now.
https://rfc.archlinux.page/0032-arch-linux-ports/
* I'm well aware of Arch Linux ARM but that's a separate project with even less resources (missing packages, some broken). Asahi used to use it before moving to Fedora due to similar problems.
> Fingers crossed this means Arch will support the ARM architecture* in the official repositories. There's a related RFC which has been accepted but but I'm not sure where things stand right now.
That is the goal with the work they are sponsoring, yes.
That is the goal with the work they are sponsoring, yes.
> In the long-term, the funding touted should, at minimum, allow Arch Linux to improve the security of its distribution and provide more structured releases compared to its current near-continuous update cycle.
This is a weird point, and concerning if it is true, because it seems to assume Arch's rolling release model is a bad model that the Arch team are forced into due to lack of funds, whereas for most of us it is in fact one of the main reasons to use Arch. As another commenter mentioned, the rolling release model is one of the reasons why Valve chose Arch, so hopefully this comment in the article is just misinformed. But there is a concern IMO that once Arch starts to look how Valve want it to look, they will try and influence the project to move to a more Debian-like release model (so that they have to worry less about breaking changes). Of course whether they can successfully influence the project in that way is another thing.
This is a weird point, and concerning if it is true, because it seems to assume Arch's rolling release model is a bad model that the Arch team are forced into due to lack of funds, whereas for most of us it is in fact one of the main reasons to use Arch. As another commenter mentioned, the rolling release model is one of the reasons why Valve chose Arch, so hopefully this comment in the article is just misinformed. But there is a concern IMO that once Arch starts to look how Valve want it to look, they will try and influence the project to move to a more Debian-like release model (so that they have to worry less about breaking changes). Of course whether they can successfully influence the project in that way is another thing.
> This is a weird point, and concerning if it is true, because it seems to assume Arch's rolling release model is a bad model that the Arch team are forced into due to lack of funds, whereas for most of us it is in fact one of the main reasons to use Arch.
This is reading too much into it. The issue is that things like proper build infrastructure and signing enclaves is hard work that is not easy to work out and provide on a volunteer basis.
We (Arch) do not support multiple architectures for the simple reason that it would imply I'd need to watch N number of builds of one package pr architecture. This is what we did for the 32bit version and 64bit version. That's a lot of wasted time, and doesn't help you sell architecture support.
Signing enclave is hard to do right as it requires the technical know-how to do securely and the supported tooling to move the package signing from a pr developer basis to a central signing key. In the long run this would also enable Arch to support Secure Boot.
This is reading too much into it. The issue is that things like proper build infrastructure and signing enclaves is hard work that is not easy to work out and provide on a volunteer basis.
We (Arch) do not support multiple architectures for the simple reason that it would imply I'd need to watch N number of builds of one package pr architecture. This is what we did for the 32bit version and 64bit version. That's a lot of wasted time, and doesn't help you sell architecture support.
Signing enclave is hard to do right as it requires the technical know-how to do securely and the supported tooling to move the package signing from a pr developer basis to a central signing key. In the long run this would also enable Arch to support Secure Boot.
I thought one of the big things Valve wants to implement is a more sound CI/CD pipeline. And I assume at some point maybe have some sort of more unified app (store). I know people love AUR. But one thing that plagues linux is the flatpak/snap/app-get/dnf/aur dance.
Getting something more unified (at least for 'casuals') would be good.
Getting something more unified (at least for 'casuals') would be good.
It's not in what the Arch maintainers said. The improvements are more around improving their build pipeline and allowing things like simultaneous x86 V3 and v4 releases (from the comments I've seen). This isn't about moving away from rolling releases afaik.
I'm still curious about why they picked Arch over Debian or a BSD.
The article claims it's because Arch is "lightweight," but then why not pick a smaller distro?
My best guess would be familiarity (Valve can afford to buy the best developers, and lots of great folks enjoy the fiddlyness of Arch), hackability, and insanely fantastic documentation of Arch
The article claims it's because Arch is "lightweight," but then why not pick a smaller distro?
My best guess would be familiarity (Valve can afford to buy the best developers, and lots of great folks enjoy the fiddlyness of Arch), hackability, and insanely fantastic documentation of Arch
I wonder why Arch as well, because it's a rolling distro so a terrible model for a commercial/production product/service, but why no *BSD is easy: bad modern hw support, Debian because of a rock solid base but extremely old distro with many issues especially in customizing it (I'm serious D/I and preseed are HORRIFIC).
So I wonder why not NixOS since it's safe updates (an update essentially can't break anything, not necessarily true for database etc outside Nix but still much saver than any other non-declarative distro) and effortless rollbacks, customization etc. It's community is problematic right now, but it's still the most complete modern distro we have, with Guix due to the GNU design a bit behind and all the others FAR behind.
So I wonder why not NixOS since it's safe updates (an update essentially can't break anything, not necessarily true for database etc outside Nix but still much saver than any other non-declarative distro) and effortless rollbacks, customization etc. It's community is problematic right now, but it's still the most complete modern distro we have, with Guix due to the GNU design a bit behind and all the others FAR behind.
Steam does a lot of upstream graphic/proton works. A distro like debian that update once a year is going to be a bad idea.
It means a fix in graphic stack or proton will either,
1. deliver after a whole year, and get actually feedback after two years.
2. require a lot of backport so steam can actually use it.
Rolling update in the other end, suits well with the changing nature of graphic stacks.
It means a fix in graphic stack or proton will either,
1. deliver after a whole year, and get actually feedback after two years.
2. require a lot of backport so steam can actually use it.
Rolling update in the other end, suits well with the changing nature of graphic stacks.
BSDs are off the table because Proton, the set of extensions to Wine for playing video games, uses Linux-specific system calls. Also, the major graphics hardware vendors don't release their first-party drivers for anything other than Windows and Linux. While open source drivers exist, they are not good enough for the latest games or the latest hardware.
> Also, the major graphics hardware vendors don't release their first-party drivers for anything other than Windows and Linux.
https://www.nvidia.com/en-us/drivers/unix/ lists official drivers for FreeBSD and Solaris (which also apparently are used by illumos). In fact, I suspect they have a better time than Linux on account of having actual stable driver ABIs.
https://www.nvidia.com/en-us/drivers/unix/ lists official drivers for FreeBSD and Solaris (which also apparently are used by illumos). In fact, I suspect they have a better time than Linux on account of having actual stable driver ABIs.
Good to know! It certainly looks like all the necessary pieces are there for FreeBSD at least.
FreeBSD package of proton: https://www.freshports.org/emulators/wine-proton
The steamdeck runs an AMD chip, which unlike nvidia, is an official first-party open source graphics driver with a decade of development behind it. It works for literally every game I've ever thrown at it. FreeBSD also runs the same open source driver.
The steamdeck runs an AMD chip, which unlike nvidia, is an official first-party open source graphics driver with a decade of development behind it. It works for literally every game I've ever thrown at it. FreeBSD also runs the same open source driver.
This is good to know.
I'd be interested to see a comparison in performance of the same (recent) game on the same hardware with Windows vs. Linux vs. FreeBSD; I assume there will be a small penalty from Windows to Linux (in general) and a larger one from Windows to FreeBSD, just because the games are not optimized for the best way to do things on the other platforms. Syscall emulation gets you comparable functionality but not necessarily comparable performance, given there's mismatch between the underlying abstractions.
On the driver front, even if it's just nVidia that's holding things back [edit: apparently they're not], that's still going to affect most PC gamers.
I'd be interested to see a comparison in performance of the same (recent) game on the same hardware with Windows vs. Linux vs. FreeBSD; I assume there will be a small penalty from Windows to Linux (in general) and a larger one from Windows to FreeBSD, just because the games are not optimized for the best way to do things on the other platforms. Syscall emulation gets you comparable functionality but not necessarily comparable performance, given there's mismatch between the underlying abstractions.
On the driver front, even if it's just nVidia that's holding things back [edit: apparently they're not], that's still going to affect most PC gamers.
> the set of extensions to Wine for playing video games, uses Linux-specific system calls.
I have wine/proton on FreeBSD and FreeBSD has also a Linuxlator (a Linux system call translator), so no blocker here.
But you are right, if you want a open-platform (opposed to Playstation), Linux is probably the better choice atm.
I have wine/proton on FreeBSD and FreeBSD has also a Linuxlator (a Linux system call translator), so no blocker here.
But you are right, if you want a open-platform (opposed to Playstation), Linux is probably the better choice atm.
Keep in mind that they did originally pick Debian. SteamOS 1 & 2 were Debian based (used for their ill-fated Steam Machine and Steam Link products), then switched to Arch-based for SteamOS 3
Steam Link did not use SteamOS.
> Steam Link
I will not accept ill talk of the Steam Link slander /s
I got mine for 6€ new when they stopped production. Don't use it much, but its nice to have that when I have a system no where close to an actual TV.
I will not accept ill talk of the Steam Link slander /s
I got mine for 6€ new when they stopped production. Don't use it much, but its nice to have that when I have a system no where close to an actual TV.
Well... Arch community is very kind and very active, but Arch is a rolling distro, a paradigm essentially incompatible with stable production systems.
I wonder why not choosing NixOS or a custom Guix System (due to the non-free stuff) instead since their model offer effortless rollbacks and safe updates.
I wonder why not choosing NixOS or a custom Guix System (due to the non-free stuff) instead since their model offer effortless rollbacks and safe updates.
Valve could offer their own device snapshotting/versioning, and frankly it may not even be a real issue since the device can just be reinstalled with the "factory image" at worst.
They have been putting a lot of work into upstream packages to provide the Proton compatibility, and they'll likely want to keep getting those packages into users hands as quickly as possible.
For fast moving development in this space, it makes sense to have a base of packages that aren't outdated right out of the gate.
They have been putting a lot of work into upstream packages to provide the Proton compatibility, and they'll likely want to keep getting those packages into users hands as quickly as possible.
For fast moving development in this space, it makes sense to have a base of packages that aren't outdated right out of the gate.
Reinstalling from images is resource intensive and take time and bandwidth than a simple "reboot into the old verision", while with NixOS all they need is provide their own channel.
On Arch they could provide their own repos as well, of course, but a thing is keeping some derivations in sync, testing them etc, another is keeping a classic distro "de-facto semi-fork", it's again an order of magnitude more complex, resource intensive and time consuming. It's much simpler and faster a declarative ecosystem and developing with it then the classic model, astonishingly faster and simpler.
I know many have never tried so do not know, but the IT at Valve I expect should be a bit beyond "the many who have never tried", so well, just curious why.
On Arch they could provide their own repos as well, of course, but a thing is keeping some derivations in sync, testing them etc, another is keeping a classic distro "de-facto semi-fork", it's again an order of magnitude more complex, resource intensive and time consuming. It's much simpler and faster a declarative ecosystem and developing with it then the classic model, astonishingly faster and simpler.
I know many have never tried so do not know, but the IT at Valve I expect should be a bit beyond "the many who have never tried", so well, just curious why.
I understand where you're coming from, I love NixOS and it seems like it could be well suited in a way, but it is extremely complex to learn Nix, and it doesn't have the scale or support Arch does, on top of being a massive departure from the typical distro and I think Valve want the Steam Deck to be a straight up portable PC.
Being pragmatic about it, I just don't think NixOS was ever a contender.
Being pragmatic about it, I just don't think NixOS was ever a contender.
If I'm not mistaken, Arch Linux only supports x64 (excluding the unofficial ARM port), so I wonder why they've chosen to go with it rather than Fedora or Debian.
My guess: Fedora is in the tight grasp of RedHat, and Debian perpetually ships old packages.
Steam/Valve are doing lots of work on various parts of the stack upstream, that they'll want to get hold of as quick as possible and not be limited by outdated dependencies.
Steam/Valve are doing lots of work on various parts of the stack upstream, that they'll want to get hold of as quick as possible and not be limited by outdated dependencies.
Did gentoo have any similar collaborations with Google?
(Chromeos is based on gentoo)
(Chromeos is based on gentoo)
Yeah, and chromeos is more than just the chromeos used on chromebooks, it's also the Container-Runtime Optimised OS (CROS) and used for some other things too, it's "the google Linux".
I'd be speculating but I think inside google there's two Linux's, one which is the immutable OS built via blaze, more like an appliance, and the other is the "dynamic" user environment stuff based on Debian, that is intended largely to be throwaway in most circumstances.
[0]: https://cloud.google.com/container-optimized-os/docs
I'd be speculating but I think inside google there's two Linux's, one which is the immutable OS built via blaze, more like an appliance, and the other is the "dynamic" user environment stuff based on Debian, that is intended largely to be throwaway in most circumstances.
[0]: https://cloud.google.com/container-optimized-os/docs
[deleted]
I'm glad I started looking at other distributions like Alpine recently. This could just as well have negative effects as positive ones. Time for me to diversify.
I run Alpine on my mini-laptop (Starlite MkIV) and on an intel compute stick (STK1A32SC) and it works perfectly fine. It's small, fast and straightforward to configure. It has quite a bit of Gentoo DNA which is convenient if you are already familiar with it.
> It has quite a bit of Gentoo DNA which is convenient if you are already familiar with it.
Do tell? I'm not familiar with Gentoo, TBH, but I wasn't aware of any link.
Do tell? I'm not familiar with Gentoo, TBH, but I wasn't aware of any link.
https://sourceforge.net/p/leaf/mailman/message/12731262/
It has certainly drifted apart since, but you can still see it here and there (runlevels, initramfs script, how the installed packages are called world etc).
It has certainly drifted apart since, but you can still see it here and there (runlevels, initramfs script, how the installed packages are called world etc).
Fair enough! Thanks for this. Interesting info I wasn't aware of.
What negative effects are you afraid of? I really can not see any downsides to this partnership.
In the long-run, a project can become dependent on such donations and this can give donors power over the project and those donors may want to steer the project in ways that we don't want to see it go. That may not happen and may even be unlikely but it's important to be prepared for that possibility and have contingencies available.
There is already a comment here which discusses one such scenario: https://news.ycombinator.com/reply?id=41695062&goto=item%3Fi...
There is already a comment here which discusses one such scenario: https://news.ycombinator.com/reply?id=41695062&goto=item%3Fi...
Maybe I’m being naive but I trust Valve to not fuck this up. They already make their money selling games so they will not try to turn Linux into a product. What they actually want is to make Linux better for everyone so they can reduce their dependency on Microsoft. I guess we’ll see what happens next.
Steam sells software and prevents you from copying it and using it easily. Not something you want to happen to a Linux distribution.
Usage of Steam's DRM is actually optional.
There are plenty of games that you can copy the files of and run on another system without Steam present. [0]
[0] https://www.pcgamingwiki.com/wiki/The_big_list_of_DRM-free_g...
[0] https://www.pcgamingwiki.com/wiki/The_big_list_of_DRM-free_g...
Do they prevent you from using it easily? Yes, they sell software on a platform, but so does Nintendo. Yet Nintendo hardware is completely locked down and the software they sold you works only on said locked down hardware. Meanwhile, I can run anything on SteamDeck, and I can run SteamDeck software and/or their games on any reasonable gaming PC, in any form factor.
In practice, over the years that I've had a gaming collection with them, they've only ENABLED me to run the games easily.
In practice, over the years that I've had a gaming collection with them, they've only ENABLED me to run the games easily.
I am not sure Arch is going to be faster for gaming than any other distro, but I can see why Valve picked it for a minimalist base. Another reason I am sure they picked it is that it is smaller and less commercial than others (such as Debain or Ubuntu) and they would have more ability to influence the project.
> In the long-term, the funding touted should, at minimum, allow Arch Linux to improve the security of its distribution and provide more structured releases compared to its current near-continuous update cycle.
This was literally the stated reason they moved from Debian in 2021, because they preferred rolling releases. [1]
[1] https://www.rockpapershotgun.com/heres-why-steamos-switched-...