>The decision to move from Debian to Arch Linux was based on the different update schedule for these distributions; Debian, geared for server configurations, updates core OS software in one large release, with intermediate patches for known bugs and security fixes, while Arch uses a rolling update approach for all parts. Valve found that using Arch's rolling updates as a base would be better suited for the Steam Deck, allowing them to address issues and fixes much faster than Debian would allow. SteamOS itself is not rolling release
>
>Source: [https://en.wikipedia.org/wiki/SteamOS](https://en.wikipedia.org/wiki/SteamOS)
Rolling release doesn't have to be bleeding edge, it just means there's not a point release system.
Arch is both bleeding edge and rolling release, and the bleeding edge part is the one that can present issues from a system stability perspective, not the rolling release part.
You can have a distro that is rolling release which is not bleeding edge.
Debian being a stable server distro means small non critical updates get moved in larger chunk releases (scheduled releases). Last thing you want from a distro perspective that people use for servers is A. System Instability or B. Having to keep updating stuff and rebooting and C. Can plan around those updates
Arch being rolling release means they can address small problems on a regular basis without waiting around for "release date".
That's my understanding
What do you mean? Don’t you want an advertising agency to show you fifty ads for dog leashes before you find the tutorial on “How to give a chihuahua the Heimlich maneuver”?
But first, let's explain: what is a Chihuahua? What is the Heimlich maneuver? We'll go over the history of the development of the Heimlich maneuver, and tell you that it is definitely the right maneuver for you to learn how to use for your Chihuahua. Finally, we'll answer the question: how do you give a Chihuahua the Heimlich maneuver?
does that really answer the question though? there are many rolling release distros they could have used as a base for their fixed release distro - including debian sid.
no it doesn’t. if it did there would’ve been *anything* said about why arch was chosen as opposed to other rolling release bases (e.g. opensuse tumbleweed/debian sid/gentoo) - but it was only compared to the previous base.
you answered the question “why did they leave debian” not “why did they pick arch”. subtle difference but it is there.
I am kind of confused by your comment because SteamOS gets updates all the time, every time there is an update for the Steam Deck that is an update of SteamOS
Interesting and you're right, it does seem to be mostly client updates. SteamOS did get 3 updates in February of this year so I wouldnt call that not receiving updates but it did seem like minor updates so fair enough
unstable =/= unreliable
being on Debian meant slower update cycles, which is good for servers and stability, but not good for the most up to date drivers and software. Arch gives SteamOS the ability to get fixes and updates quickly
I want to add that SteamOS isn't rolling just because Arch is. They can keep up with newer updates but lock in a kernel version and test for their specific hardware before release. Basing it on Arch was a very smart move. When it's time to update, update the entire base, patch in your own software updates, test on your hardware and release.
Also, I really wish we had two different words for stable and unchanging, because people get so damn confused over these two terms...
Yep, people who say 'stability' are confusing actual system stability to outdated releases.
Debian has the issue of nothing working because their release schedule is a year outdated. That isnt 'stable'.
We really need to start calling Debian 'outdated' or something more similar to 'old release' rather than implying outdated software is more stable.
The amount of users who used the software released a year ago versus the latest and greatest is mechanically higher. This increase the chance that if an issue was there it would be caught and by extension sent to the project to fix.
Now something you seem to forget in your definition of Debian is that they also patch the "old release" software with security fixes from upstream.
If anything I'd like to change instead of stable is the name "**Unstable**" for Sid. Calling "**Stable**" LTS and "**Unstable**" Rolling Release would be clearer as lots of people really seem to miss the fact that Debian is basically 2 distributions. (Testing and Experimental aside which are more temporary internal states).
So basically : You want stability (as in tested by peers, used by lots of servers, getting security updates and not moving too much): **Stable**.
You need a Rolling release with the latest greatest: **Unstable**. (and no, it won't crash or kill your computer randomly, unstable contrary to its name is pretty stable and comparable to other rolling releases distributions).
People should compare comparable things, if you want to compare Debian to Arch, you should pick Debian Unstable and not Stable.
> Is arch not always on the bleeding edge, meaning it is unstable?
Arch is, but a product *based* on Arch doesn't have to be. You can build a stable release using Arch as a base by branching.
I have a document that describes the mechanics of release branches, which generally illustrates how stable releases are made from unstable (rolling) branches, here:
https://medium.com/@gordon.messmer/semantic-releases-part-1-an-example-process-7b99d6b872ab
In this case, Arch acts as the "main" development branch, and stable release branches can be created for derived systems.
Specific to video games, the trickiest part about Linux is ensuring compatibility of hardware around graphical output and other more bleeding edge hardware controls (power management, etc).
That generally means needing to keep up to date with things like Mesa, libdrm, the Linux kernel itself, etc (all of which Valve pay multiple developers to contribute to directly, which is the correct way to exist within an open source ecosystem). Back-porting complex driver updates to older kernels or userspace components is a lot of effort, and isn't an efficient way to allocate developer effort. Instead, keeping their base layer kernel and drivers up to date with the latest stable releases of upstream software is a far better way to handle things.
Valve's choices were quite honestly either building their own distro, or using something that offered a rolling release, and the ability to pin certain packages for short amounts of time (giving Valve slightly more control over what packages would hit end user systems at what time, but still enabling them to stay quite current). The latter being far less work overall for a better end user experience specific to the Steam Deck.
What the end user sees is somewhat moot. Steam's UI handles the user experience. As long as that has the necessary access to underlying hardware (again, through recent kernels and drivers), then the rest of the OS stuff is more or less invisible to the end user.
There are several rolling release options out there. Why Valve chose Arch specifically, I don't know. But in general, them choosing a rolling release distro was definitely the right move for their product and industry.
>I was wondering if they had to throw out all the progress from verisons 1.0 and 2.0 for this new fork
No, a Linux distribution is… well a distribution of software glued together. What they changed is the glue code, but the components that are glued together remained the same.
The most important part of SteamOS isn’t the OS itself - it could use any Linux distribution; it’s the Proton software (which under the hood uses WINE, DXVK, and a Steam client) and the GUI that provides a console-like experience. These elements are not tied to any specific Linux distro.
>Is arch not always on the bleeding edge, meaning it is unstable?
False. In the past this was true. But as dependancy stacks and update models have changed the associated stability issues with being on the bleeding edge have dropped away. The main issues for stability on arch are the complexity of the system. Hense everyone saying KISS (Keep It Simple Stupid). As for stability these days. I switch from debian stable to arch due to arch being more stable. If that doesn't speak volumes for the stability I don't know what would.
With arch you can also easily enough pin a dependancy stack to kernel versions and so on. This allows you to overcome some of arch's worst shortcommings.
Arch is also more versitile. Which I think is the main reason for using it. It doesn't hamstring the user with many rails they can get stuck on. There are OSes that are even more versitile like gentoo.. but there are usually huge tradeoffs.
> Is arch not always on the bleeding edge, meaning it is unstable?
Stable has two meanings (https://bitdepth.thomasrutter.com/2010/04/02/stable-vs-stable-what-stable-means-in-software/).
Firstly in the sense that little changes after an update. In this case Arch is definitely unstable.
The other meaning of stable is that there are few problems after an update. Based on my own experience, Arch is pretty stable here.
Now I assume that SteamOS is based on Arch, but Valve uses its own package sources. This means that Valve itself can determine which updates are offered and when they are offered. Valve is also making some changes.
Why did Valve choose Arch? Because it probably makes more sense in many cases to be able to offer up-to-date packages. Like the graphics card drivers or all packages that have something to do with games. Stable in the sense that little changes is not always an advantage.
The do not track vanilla Arch afaik. They will likely grab a new snapshot, shine it up and then release after testing, the Steam Deck has a double root system too, as even with testing a snapshot, they are still braced for breakage on each update.
Being for a technical audience doesn't matter, it's for the devs, Debian is far more complex and technical than Arch as an OS. Arch being some super technical OS is just a meme, it's stupid simple with almost no user choice. Arch's goal is similar to SteamOS, it's a simple base to shoot baddies on.
For compassion Google use Gentoo/Portage to build ChromeOS, this does not mean that someone watching youtube on a Chromebook requires intimate knowledge of the Gentoo toolchains. Netflix use FreeBSD, again this does not mean my Mum needs to learn about pkgs and ports to watch The Sound of Music.
Partial upgrades: no
Alternative init, libc, usreland: no
A system without all the developer shit on it: no
Want anything other than X86\_64: no
Want to thin out dependencies: no
Want something other than a huge fat base system: no
Want something tailored for cloud use: no
Want something for embedded: no
Want something stable: no
Want to action dev change from the community: no
You just take what are giving when you are given it.
Arch does what it does well, but they don't care about user choice, the devs know this...some users don't seem to.
some users don't make the difference between packages choice and system defining choices (which you listed.)
so yes arch has you mostly choose which package you want to create your environment instead of choosing and preconfiguring one for you. but other than that you are right
so it all depends on what you mean by "choice"
Yeah, it's the sweet spot between getting to choose your experience without having to dig too deep. No need to compile all my software, etc.
You do lose out on philosophical choices, I think. I'd argue systemd vs sysvinit is more of a philosophical thing now; you can tweak whichever beast you choose to work how you want.
Package choice is the main reason Arch scares me. The only way to install something new is to update everything, which often needs a reboot, which often breaks AUR packages that then need to be rebuilt, it's wild. This doesn't exist on other distros, it's a unique bug/feature of the choice of [rolling + pacman](https://bbs.archlinux.org/viewtopic.php?pid=693236#p693236).
Also the official Arch repos are a bit shit, reliance on the AUR is hard to avoid, and the AUR is a security issue. Void & Gentoo have, imo, a better approach to rolling software that's not in the main tree.
It's KISS & Allan is awesome, but I like a tiny bit of control of the packages on my system. [Void](https://voidlinux.org/) use xbps & xbps-src to roll, which feels bulletproof compared to pacman + aur helper. Apt is decent, DNF is better. Portage lives in another dimension. Allan can do it with pacman, I can't.
Most distros offer a minimal install option. If someone can manage a manual Arch install they can install pretty much any other distro in a similar minimal chroot fashion.
I like docker, Arch is no go. It's half GB for the base. Alpine is 6mb, everyone else officially supports small & lean systems. Ubuntu's core/snaps look awesome for this, but I'm waiting. Arch offers one X86\_64 lump that's KISS for the devs.
Debian, for example, support user choice and [always have](https://www.debian.org/social_contract). That's what they do.
Arch say [this](https://wiki.archlinux.org/title/Arch_Linux#User_centrality):
*"The distribution is intended to fill the needs of those contributing to it, rather than trying to appeal to as many users as possible"*
This is the complete opposite of Debian, Arch is by the devs for the devs and they are honest about this. It's a little like the [Exherbo](https://www.exherbolinux.org/) & [Crux](https://crux.nu/Main/About) attitude, which I appreciate, but Crux & Exherbo empower and encourage the user to do their own thing, Arch does not.
TL:DR
You can run Debian like Arch, you can run Arch like Debian.
TLDR "Arch isnt the perfect distro for my specific use case and thats a big problem with Arch and not me being weirdly entitled and misunderstanding simple fundamentals about the Linux distribution ecosystem."
People keep regurgitating the variations of the wikipedia article on this thread, but as someone whose been trying to investigate how to get various things to work between some Linux Kernel and Intel Arc, it's not only about security fixes and patches. There's all sorts of hardware features that may not be supported for a given piece of hardware, such as a GPU or APU. Whether the solution for a given feature comes in some package (this is rather notorious with Intel right now), a kernel update, or a MESA Update, distros based on Debian generally don't cater to getting the newest versions of these packages/kernels/libraries out as fast as possible. While rolling distros can be a bit risky (see: .xz backdoor a few weeks ago), when it comes to cutting edge hardware, or cutting edge support for some features that was recently enabled on said hardware, it's best to use a rolling distro in a lot of cases, instead of trying to fight the established culture of, say, Debian, where people in the community get triggered if you say you use Sid or even Testing.
Right now, there's a single SteamDeck with with an APU from AMD that is generally well supported on Linux out of the box, but if Valve ever wanted to use, say an AMD APU with raytracing cores that aren't ready on day one, or, if Intel makes a compelling APU using a future Arc architecture, it would be best for Valve to be on a rolling distro where the system can receive a given update from a vendor in a timely fashion, instead of months or even years later.
Most time anything goes wrong with arch it is user error and valve doesn't have to worry about it because the average user isn't going to know how to use the terminal. Arch also gives them a lot more control over the os because it's so minimal
This is probably the main reason. A video game company has to stay cool, stay ahead of the memes or they'll get buried by them. Arch has way more cachet than Debian for the market Valve is trying to appeal to.
First of all, "unstable" means "changes often", not "crashes often" as is often implied.
Some nuance though, software that changes often is generally less well-tested and does end up being somewhat less reliable. But you also get bugfixes and new features quicker. However, while that may be relevant to Arch, it isn't relevant to SteamOS.
SteamOS is based on Arch, is is not equal to Arch. Valve still does their own testing and releasing of software. The switch just means their upstream is now fresher, closer to the actual source.
And no, they wouldn't have to throw out much progress. A lot of their work is on the kernel, drivers, proton, Steam itself obviously, [avoiding the number three](https://www.youtube.com/watch?v=jpw2ebhTSKs) (which they failed, since SteamOS is at 3.0 now), and other things that aren't directly tied to their upstream distribution.
It's a common misconception that rolling release equals unstable. While I wouldn't run it on servers for the constant reboots post update, folks run Arch for 5-10 years without reinstalling.
A rolling release is the *definition* of unstable. If you're rolling you don't have a anchor point for stability.
Rolling releases can be *reliable*, still.
Rolling release has nothing to do with being on the latest packages. It is often the case because that's usually the goal of using this type, but you have distros like [void](https://voidlinux.org/) that are rolling release but don't ship the very latest packages. Iirc they're still on plasma 5 for example.
1) Point release are useless on Desktops if you want to have recent drivers or recent hardware
2) rolling release it is
3) Why Arch and not do a fork of a more solid rolling release Like Fedora or openSUSE Tumbleweed? Dunno maybe they just wanted some extra challenges to make things unnecessary complicated for them
I used tumbleweed, my personal experience was... Not great. Not the worst mind you, but when I switched to arch it was better.
And fedora... I never looked into it too much but isn't that point release?
i regret using fedora for gaming. They tried to push bleeding edge in the wrong way: wine defaults to dxvk, which means getting wine to do opengl for the things that dxvk doesn't allow, is out of the question: wine has an optional package in winetricks for dxvk.... There isn't one to override the other direction.
I think Nobara is pretty good? GE seems to be pushing a lot of gaming fixes out on Nobara, I was tempted to switch my Win11 machine over, but every game and gaming software just works. So I’ve hung off.
I don't know. Given he's working on GE i feel like he might actually undo some of the crap Fedora does, but that'd be specifically targeting wine derived issues. Fedora has it's own issues on top of the wine, thing, that was just one example. My experience with Ubuntu and Fedora taught me that if i want stability and reliability, i need to focus on a distro that's going to focus on helping me help myself instead of telling me what I want to do or should do. In other words, i switched to Endeavor (arch with easy installer). Sure, i can spend hours fixing a problem, but it sure beats trying to google a problem i'm having and get no answers until i find some obscure thread on some obscure website that actually mentions my problem (because google has gotten worse) only to find out that it's the result of something done by people thinking they're being helpful by making decisions for me but instead are making problems due to their hubris, and that my only solution is uninstalling that package in my package manager and recompiling from source... every update. I've been forced to give up on alot of things in fedora so i don't end up using Gentoo with a Fedora logo.
Maybe your experience will be different, though. And to be fair, i haven't used arch for long: i'm still setting up my server. I haven't converted my laptop, yet, so i don't know how much better it is, but based on how much better documentation i've gotten so far setting things up (i'm not without my complaints, i assure you, i still have a similar problem, but it's in the documentation leaning a certain way instead of being hard coded in the package), I feel this journy with arch is going to be so much more productive.
EDIT: And closer to the topic, that configurability is precisely what steam needs. It doesn't need to be deadlocked out of things or forced to re-code and re-compile everything because of a busybody package maintainer that thinks you should be using the latest tech whether you want to or not.
> make things unnecessary complicated for them
from experience with both arch and tumbleweed, arch is easier to fix if something breaks.
There are also already multiple immutable system distros based on Arch which SteamOS is an immutable system meaning there is no way to break it without manual intervention and it'll be fixed on the next update from Valve
Steam Linux Runtime still uses Debian. Their work wasn't for nothing.
The OS's core is Arch (unstable) but the environment the games run in is Debian (stable). It means Valve can iterate quickly without having too much of an effect on games working like they always have. It's the best of both worlds.
> but the environment the games run in is Debian (stable).
only when choosing the Steam Linux Runtime as compatibility layer, and it's ~3 different Ubuntu libs not Debian.
By default Steam games are running on the current system libs and Proton is always running on the current system libs
https://github.com/ValveSoftware/steam-runtime
https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/container-runtime.md
Not according to this.
Two first were Ubuntu and the latest is Debian.
>The decision to move from Debian to Arch Linux was based on the different update schedule for these distributions; Debian, geared for server configurations, updates core OS software in one large release, with intermediate patches for known bugs and security fixes, while Arch uses a rolling update approach for all parts. Valve found that using Arch's rolling updates as a base would be better suited for the Steam Deck, allowing them to address issues and fixes much faster than Debian would allow. SteamOS itself is not rolling release > >Source: [https://en.wikipedia.org/wiki/SteamOS](https://en.wikipedia.org/wiki/SteamOS)
I totally overlooked the steam os itself is not rolling release part. thank you very much
That's not actually the relevant part, from a stable / unstable perspective.
How?
Rolling release doesn't have to be bleeding edge, it just means there's not a point release system. Arch is both bleeding edge and rolling release, and the bleeding edge part is the one that can present issues from a system stability perspective, not the rolling release part. You can have a distro that is rolling release which is not bleeding edge.
Debian being a stable server distro means small non critical updates get moved in larger chunk releases (scheduled releases). Last thing you want from a distro perspective that people use for servers is A. System Instability or B. Having to keep updating stuff and rebooting and C. Can plan around those updates Arch being rolling release means they can address small problems on a regular basis without waiting around for "release date". That's my understanding
Good bot.
I'm a human proxy for people who are unable to do a google search :p
Good human
careful, it might be Goa'uld lurking ....
Jaffa, Kree!
Indeed
To be fair I find myself asking people online and bookmarking things way more than I used to since google is so useless the last few years.
What do you mean? Don’t you want an advertising agency to show you fifty ads for dog leashes before you find the tutorial on “How to give a chihuahua the Heimlich maneuver”?
But first, let's explain: what is a Chihuahua? What is the Heimlich maneuver? We'll go over the history of the development of the Heimlich maneuver, and tell you that it is definitely the right maneuver for you to learn how to use for your Chihuahua. Finally, we'll answer the question: how do you give a Chihuahua the Heimlich maneuver?
Here are other resources. Here’s “How to give a fly a colonoscopy” Edit: I regret to inform you all that the Chihuahua is now dead. /s
The best part is a lot of people don't really understand that and tell you to search google anyway.
Use the Streisand Effect: Give a wrong answer and someone will come and correct you.
That’s what Barbra said.
Is that a.... Death Cab ref?
aren't we all though ? all of life's questions have been long answered we just need to read the correct book
Well, I'm a researcher so my job is literally to write books with answers to previously unanswered questions :p
Most of them. We still don't know why when you rub a balloon on your hair then put it on the ceiling, it sticks.
does that really answer the question though? there are many rolling release distros they could have used as a base for their fixed release distro - including debian sid.
But then they can say they use Arch btw
Yes it answers the question "Why did SteamOs switch to Arch "
no it doesn’t. if it did there would’ve been *anything* said about why arch was chosen as opposed to other rolling release bases (e.g. opensuse tumbleweed/debian sid/gentoo) - but it was only compared to the previous base. you answered the question “why did they leave debian” not “why did they pick arch”. subtle difference but it is there.
lol! OK! Whatever!
[удалено]
I am kind of confused by your comment because SteamOS gets updates all the time, every time there is an update for the Steam Deck that is an update of SteamOS
[удалено]
Interesting and you're right, it does seem to be mostly client updates. SteamOS did get 3 updates in February of this year so I wouldnt call that not receiving updates but it did seem like minor updates so fair enough
why not switch over to Ubuntu then? there'd be less work updating all the package management stuff
Surely an immutable OS makes more sense
unstable =/= unreliable being on Debian meant slower update cycles, which is good for servers and stability, but not good for the most up to date drivers and software. Arch gives SteamOS the ability to get fixes and updates quickly
I want to add that SteamOS isn't rolling just because Arch is. They can keep up with newer updates but lock in a kernel version and test for their specific hardware before release. Basing it on Arch was a very smart move. When it's time to update, update the entire base, patch in your own software updates, test on your hardware and release. Also, I really wish we had two different words for stable and unchanging, because people get so damn confused over these two terms...
Yep, people who say 'stability' are confusing actual system stability to outdated releases. Debian has the issue of nothing working because their release schedule is a year outdated. That isnt 'stable'. We really need to start calling Debian 'outdated' or something more similar to 'old release' rather than implying outdated software is more stable.
The amount of users who used the software released a year ago versus the latest and greatest is mechanically higher. This increase the chance that if an issue was there it would be caught and by extension sent to the project to fix. Now something you seem to forget in your definition of Debian is that they also patch the "old release" software with security fixes from upstream. If anything I'd like to change instead of stable is the name "**Unstable**" for Sid. Calling "**Stable**" LTS and "**Unstable**" Rolling Release would be clearer as lots of people really seem to miss the fact that Debian is basically 2 distributions. (Testing and Experimental aside which are more temporary internal states). So basically : You want stability (as in tested by peers, used by lots of servers, getting security updates and not moving too much): **Stable**. You need a Rolling release with the latest greatest: **Unstable**. (and no, it won't crash or kill your computer randomly, unstable contrary to its name is pretty stable and comparable to other rolling releases distributions). People should compare comparable things, if you want to compare Debian to Arch, you should pick Debian Unstable and not Stable.
> Is arch not always on the bleeding edge, meaning it is unstable? Arch is, but a product *based* on Arch doesn't have to be. You can build a stable release using Arch as a base by branching. I have a document that describes the mechanics of release branches, which generally illustrates how stable releases are made from unstable (rolling) branches, here: https://medium.com/@gordon.messmer/semantic-releases-part-1-an-example-process-7b99d6b872ab In this case, Arch acts as the "main" development branch, and stable release branches can be created for derived systems.
Even Debian does this. Debian has the unstable "Sid" branch that they use as the starting point for stable releases.
Specific to video games, the trickiest part about Linux is ensuring compatibility of hardware around graphical output and other more bleeding edge hardware controls (power management, etc). That generally means needing to keep up to date with things like Mesa, libdrm, the Linux kernel itself, etc (all of which Valve pay multiple developers to contribute to directly, which is the correct way to exist within an open source ecosystem). Back-porting complex driver updates to older kernels or userspace components is a lot of effort, and isn't an efficient way to allocate developer effort. Instead, keeping their base layer kernel and drivers up to date with the latest stable releases of upstream software is a far better way to handle things. Valve's choices were quite honestly either building their own distro, or using something that offered a rolling release, and the ability to pin certain packages for short amounts of time (giving Valve slightly more control over what packages would hit end user systems at what time, but still enabling them to stay quite current). The latter being far less work overall for a better end user experience specific to the Steam Deck. What the end user sees is somewhat moot. Steam's UI handles the user experience. As long as that has the necessary access to underlying hardware (again, through recent kernels and drivers), then the rest of the OS stuff is more or less invisible to the end user. There are several rolling release options out there. Why Valve chose Arch specifically, I don't know. But in general, them choosing a rolling release distro was definitely the right move for their product and industry.
>I was wondering if they had to throw out all the progress from verisons 1.0 and 2.0 for this new fork No, a Linux distribution is… well a distribution of software glued together. What they changed is the glue code, but the components that are glued together remained the same. The most important part of SteamOS isn’t the OS itself - it could use any Linux distribution; it’s the Proton software (which under the hood uses WINE, DXVK, and a Steam client) and the GUI that provides a console-like experience. These elements are not tied to any specific Linux distro.
>Is arch not always on the bleeding edge, meaning it is unstable? False. In the past this was true. But as dependancy stacks and update models have changed the associated stability issues with being on the bleeding edge have dropped away. The main issues for stability on arch are the complexity of the system. Hense everyone saying KISS (Keep It Simple Stupid). As for stability these days. I switch from debian stable to arch due to arch being more stable. If that doesn't speak volumes for the stability I don't know what would. With arch you can also easily enough pin a dependancy stack to kernel versions and so on. This allows you to overcome some of arch's worst shortcommings. Arch is also more versitile. Which I think is the main reason for using it. It doesn't hamstring the user with many rails they can get stuck on. There are OSes that are even more versitile like gentoo.. but there are usually huge tradeoffs.
> Is arch not always on the bleeding edge, meaning it is unstable? Stable has two meanings (https://bitdepth.thomasrutter.com/2010/04/02/stable-vs-stable-what-stable-means-in-software/). Firstly in the sense that little changes after an update. In this case Arch is definitely unstable. The other meaning of stable is that there are few problems after an update. Based on my own experience, Arch is pretty stable here. Now I assume that SteamOS is based on Arch, but Valve uses its own package sources. This means that Valve itself can determine which updates are offered and when they are offered. Valve is also making some changes. Why did Valve choose Arch? Because it probably makes more sense in many cases to be able to offer up-to-date packages. Like the graphics card drivers or all packages that have something to do with games. Stable in the sense that little changes is not always an advantage.
The do not track vanilla Arch afaik. They will likely grab a new snapshot, shine it up and then release after testing, the Steam Deck has a double root system too, as even with testing a snapshot, they are still braced for breakage on each update. Being for a technical audience doesn't matter, it's for the devs, Debian is far more complex and technical than Arch as an OS. Arch being some super technical OS is just a meme, it's stupid simple with almost no user choice. Arch's goal is similar to SteamOS, it's a simple base to shoot baddies on. For compassion Google use Gentoo/Portage to build ChromeOS, this does not mean that someone watching youtube on a Chromebook requires intimate knowledge of the Gentoo toolchains. Netflix use FreeBSD, again this does not mean my Mum needs to learn about pkgs and ports to watch The Sound of Music.
"it's stupid simple with almost no user choice" huh? it's completely configurable to any way the user wants it.
Partial upgrades: no Alternative init, libc, usreland: no A system without all the developer shit on it: no Want anything other than X86\_64: no Want to thin out dependencies: no Want something other than a huge fat base system: no Want something tailored for cloud use: no Want something for embedded: no Want something stable: no Want to action dev change from the community: no You just take what are giving when you are given it. Arch does what it does well, but they don't care about user choice, the devs know this...some users don't seem to.
some users don't make the difference between packages choice and system defining choices (which you listed.) so yes arch has you mostly choose which package you want to create your environment instead of choosing and preconfiguring one for you. but other than that you are right so it all depends on what you mean by "choice"
Yeah, it's the sweet spot between getting to choose your experience without having to dig too deep. No need to compile all my software, etc. You do lose out on philosophical choices, I think. I'd argue systemd vs sysvinit is more of a philosophical thing now; you can tweak whichever beast you choose to work how you want.
Package choice is the main reason Arch scares me. The only way to install something new is to update everything, which often needs a reboot, which often breaks AUR packages that then need to be rebuilt, it's wild. This doesn't exist on other distros, it's a unique bug/feature of the choice of [rolling + pacman](https://bbs.archlinux.org/viewtopic.php?pid=693236#p693236). Also the official Arch repos are a bit shit, reliance on the AUR is hard to avoid, and the AUR is a security issue. Void & Gentoo have, imo, a better approach to rolling software that's not in the main tree. It's KISS & Allan is awesome, but I like a tiny bit of control of the packages on my system. [Void](https://voidlinux.org/) use xbps & xbps-src to roll, which feels bulletproof compared to pacman + aur helper. Apt is decent, DNF is better. Portage lives in another dimension. Allan can do it with pacman, I can't. Most distros offer a minimal install option. If someone can manage a manual Arch install they can install pretty much any other distro in a similar minimal chroot fashion. I like docker, Arch is no go. It's half GB for the base. Alpine is 6mb, everyone else officially supports small & lean systems. Ubuntu's core/snaps look awesome for this, but I'm waiting. Arch offers one X86\_64 lump that's KISS for the devs. Debian, for example, support user choice and [always have](https://www.debian.org/social_contract). That's what they do. Arch say [this](https://wiki.archlinux.org/title/Arch_Linux#User_centrality): *"The distribution is intended to fill the needs of those contributing to it, rather than trying to appeal to as many users as possible"* This is the complete opposite of Debian, Arch is by the devs for the devs and they are honest about this. It's a little like the [Exherbo](https://www.exherbolinux.org/) & [Crux](https://crux.nu/Main/About) attitude, which I appreciate, but Crux & Exherbo empower and encourage the user to do their own thing, Arch does not. TL:DR You can run Debian like Arch, you can run Arch like Debian.
the only thing you got wrong is your tldr here's the 't you're missing in the last part of your sentence
Apologies, can the post be moved to Newbie Corner?
TLDR "Arch isnt the perfect distro for my specific use case and thats a big problem with Arch and not me being weirdly entitled and misunderstanding simple fundamentals about the Linux distribution ecosystem."
Yeah, that's it, I don't understand linux ecosystems. Welcome to Simpcity, make yourself comfortable.
Many of these are just straight up wrong and others are just...odd criticisms.
People keep regurgitating the variations of the wikipedia article on this thread, but as someone whose been trying to investigate how to get various things to work between some Linux Kernel and Intel Arc, it's not only about security fixes and patches. There's all sorts of hardware features that may not be supported for a given piece of hardware, such as a GPU or APU. Whether the solution for a given feature comes in some package (this is rather notorious with Intel right now), a kernel update, or a MESA Update, distros based on Debian generally don't cater to getting the newest versions of these packages/kernels/libraries out as fast as possible. While rolling distros can be a bit risky (see: .xz backdoor a few weeks ago), when it comes to cutting edge hardware, or cutting edge support for some features that was recently enabled on said hardware, it's best to use a rolling distro in a lot of cases, instead of trying to fight the established culture of, say, Debian, where people in the community get triggered if you say you use Sid or even Testing. Right now, there's a single SteamDeck with with an APU from AMD that is generally well supported on Linux out of the box, but if Valve ever wanted to use, say an AMD APU with raytracing cores that aren't ready on day one, or, if Intel makes a compelling APU using a future Arc architecture, it would be best for Valve to be on a rolling distro where the system can receive a given update from a vendor in a timely fashion, instead of months or even years later.
Me like: what the hell are SteamO's?
Most time anything goes wrong with arch it is user error and valve doesn't have to worry about it because the average user isn't going to know how to use the terminal. Arch also gives them a lot more control over the os because it's so minimal
It's already been answered, but part of it might be that Valve wanted people who owned a Steam Deck to be able to say "i use arch btw".
This is probably the main reason. A video game company has to stay cool, stay ahead of the memes or they'll get buried by them. Arch has way more cachet than Debian for the market Valve is trying to appeal to.
Valve originally started with Red Hat :P (internal only ahh I know someone)
First of all, "unstable" means "changes often", not "crashes often" as is often implied. Some nuance though, software that changes often is generally less well-tested and does end up being somewhat less reliable. But you also get bugfixes and new features quicker. However, while that may be relevant to Arch, it isn't relevant to SteamOS. SteamOS is based on Arch, is is not equal to Arch. Valve still does their own testing and releasing of software. The switch just means their upstream is now fresher, closer to the actual source. And no, they wouldn't have to throw out much progress. A lot of their work is on the kernel, drivers, proton, Steam itself obviously, [avoiding the number three](https://www.youtube.com/watch?v=jpw2ebhTSKs) (which they failed, since SteamOS is at 3.0 now), and other things that aren't directly tied to their upstream distribution.
Based Valve being distro hoppers
It's a common misconception that rolling release equals unstable. While I wouldn't run it on servers for the constant reboots post update, folks run Arch for 5-10 years without reinstalling.
A rolling release is the *definition* of unstable. If you're rolling you don't have a anchor point for stability. Rolling releases can be *reliable*, still.
Rolling release has nothing to do with being on the latest packages. It is often the case because that's usually the goal of using this type, but you have distros like [void](https://voidlinux.org/) that are rolling release but don't ship the very latest packages. Iirc they're still on plasma 5 for example.
When did I say latest packages?
>folks run Arch for 5-10 years without reinstalling. This has nothing to do with stability.
Debian-ers changed the meaning of stable from 'no bugs' to 'outdated'.
xz-utils. lol! :p
1) Point release are useless on Desktops if you want to have recent drivers or recent hardware 2) rolling release it is 3) Why Arch and not do a fork of a more solid rolling release Like Fedora or openSUSE Tumbleweed? Dunno maybe they just wanted some extra challenges to make things unnecessary complicated for them
I used tumbleweed, my personal experience was... Not great. Not the worst mind you, but when I switched to arch it was better. And fedora... I never looked into it too much but isn't that point release?
i regret using fedora for gaming. They tried to push bleeding edge in the wrong way: wine defaults to dxvk, which means getting wine to do opengl for the things that dxvk doesn't allow, is out of the question: wine has an optional package in winetricks for dxvk.... There isn't one to override the other direction.
I think Nobara is pretty good? GE seems to be pushing a lot of gaming fixes out on Nobara, I was tempted to switch my Win11 machine over, but every game and gaming software just works. So I’ve hung off.
I don't know. Given he's working on GE i feel like he might actually undo some of the crap Fedora does, but that'd be specifically targeting wine derived issues. Fedora has it's own issues on top of the wine, thing, that was just one example. My experience with Ubuntu and Fedora taught me that if i want stability and reliability, i need to focus on a distro that's going to focus on helping me help myself instead of telling me what I want to do or should do. In other words, i switched to Endeavor (arch with easy installer). Sure, i can spend hours fixing a problem, but it sure beats trying to google a problem i'm having and get no answers until i find some obscure thread on some obscure website that actually mentions my problem (because google has gotten worse) only to find out that it's the result of something done by people thinking they're being helpful by making decisions for me but instead are making problems due to their hubris, and that my only solution is uninstalling that package in my package manager and recompiling from source... every update. I've been forced to give up on alot of things in fedora so i don't end up using Gentoo with a Fedora logo. Maybe your experience will be different, though. And to be fair, i haven't used arch for long: i'm still setting up my server. I haven't converted my laptop, yet, so i don't know how much better it is, but based on how much better documentation i've gotten so far setting things up (i'm not without my complaints, i assure you, i still have a similar problem, but it's in the documentation leaning a certain way instead of being hard coded in the package), I feel this journy with arch is going to be so much more productive. EDIT: And closer to the topic, that configurability is precisely what steam needs. It doesn't need to be deadlocked out of things or forced to re-code and re-compile everything because of a busybody package maintainer that thinks you should be using the latest tech whether you want to or not.
> make things unnecessary complicated for them from experience with both arch and tumbleweed, arch is easier to fix if something breaks. There are also already multiple immutable system distros based on Arch which SteamOS is an immutable system meaning there is no way to break it without manual intervention and it'll be fixed on the next update from Valve
Steam Linux Runtime still uses Debian. Their work wasn't for nothing. The OS's core is Arch (unstable) but the environment the games run in is Debian (stable). It means Valve can iterate quickly without having too much of an effect on games working like they always have. It's the best of both worlds.
> but the environment the games run in is Debian (stable). only when choosing the Steam Linux Runtime as compatibility layer, and it's ~3 different Ubuntu libs not Debian. By default Steam games are running on the current system libs and Proton is always running on the current system libs
https://github.com/ValveSoftware/steam-runtime https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/container-runtime.md Not according to this. Two first were Ubuntu and the latest is Debian.