My own personal experience with Arch & Debian Sid is that Sid is noticeably more stable than Arch, long term. Maybe Valve thinks it's easier to address the stability problems on an Arch-based distribution rather than deal getting the latest versions of stuff on something Debian-based?
I'm also sure that Valve's system is going to have a smaller set of software than I'd use on an Arch desktop anyway, so there's less surface area for stuff to break.
> My own personal experience with Arch & Debian Sid is that Sid is noticeably more stable than Arch, long term.
I have the exact opposite experience, I used to use sid and had to do full-blown reinstall every couple months because e.g. dpkg would break too much and I wouldn't be able to install anything, or once, even boot and ended up migrating to arch despite the warnings - never had to reinstall the distro once since then
I'd been using Debian sid for almost 10 years and now use Arch for more than 5 years. Sid is definitely much more stable, as in "not requiring manual interventions", than Arch is. In fact it was actually a bit "too stable" for my taste because it effectively becomes frozen together with 'testing' right before a new 'stable' gets released.
That said, never had to reinstall either of them. Had my system broken by pacman in ways dpkg would handle much better, but it was fixable anyway.
I've been running a mixed testing/sid install since 2005 and not once did I have to reinstall. Even managed to cross-grade from i386 to amd64 a couple years ago.
Do you remember when that happened? I vaguely remember that I used to experience problems installing packages in Aptitude and it would make me "fix" them without a way forward that I liked, but that was years ago.
eh, I switched to arch around.... 2013/2014 ? after an especially bad crash with sid. Never used aptitude, only apt-get. Since then I'm carrying the same "distro" from computer to computer.
Aptitude is mostly a front-end to apt-get, but if you try to install some impossible combination of packages or get your packages in a weird state, aptitude offers solutions to fix it.
Has there ever been an analysis to see what is most likely to break on a rolling distribution? I have been using Arch for years, and have only had a couple of hardware related issues. If that is typical, rolling distributions may not even be an issue when the vendor has tight control over the product and can isolate hardware related packages in their own repository.
In my own experience, the hardware support that breaks is the GPU. For me, the GPU has broken occasionally (once every couple years) regardless of distribution, unless I'm using an Intel GPU or an older GPU with mainline support.
I'm sure that Valve is going to install a much smaller set of core software than a typical desktop, though.
It seems to me that most people finding Arch unstable find it so because they rampantly abuse the AUR. I'm not implying this is something that you, personally, would do, but it seems to be the case in most "Arch is unstable" scenarios.
I might have one or two packages from AUR, but mostly I don't touch it. I've had a number of discussions in meetups about stability and Arch over the years and have encountered plenty of people who switched from Arch to Debian or Ubuntu because of stability problems with Arch. I have a hard time imagining that it's mostly down to AUR.
Maybe the people using lots of AUR are complaining a lot, and the people who don't just quietly switch distros?
Quite possible. The number of packages in the main arch repos is a lot smaller than the number in Debian/Ubuntu. I would imagine the kind of people you're talking about are leaning on the AUR or packages found by default (and thus more heavily tested) in Debian/Ubuntu.
Not really, it slows only down around the time when Debian wants to make a stable release, i.e., every two years for 2-3 months or so.
Debian is in general really rigorous with ABI/Symbol versioning, dependencies and packaging in general - there are some outliers, but most of the packages in Debian is just high quality work.
On the other side is Arch Linux, where they do not even care about Kernel ABI bumps, which are trivial to detect and track, so if you pull in a kernel update you cannot load any new module, as they just overwrite the modules of the running kernel - I used it, but I find that still lunatic!
Nothing like having some complex workspace setup and then needing to connect to a VPN/WireGuard network but also forgetting to preload that module (I just load all possible relevant on start nowadays), forced a reboot, nothing lost but tedious.
On Debian this and other things where you're in limbo while some library version mismatches, or some AUR package is depending on another one, won't ever happen on Debian. It has its disadvantages, but they certainly dot their i's.
Have you tried openSUSE Tumbleweed? It is a well tested rolling release (https://openbuildservice.org/), with snapshots on update via btrfs.
With the opi package you can install: chrome, codecs, dotnet, msedge, msteams, plex, skype, signal, slack, teamviewer, vivaldi, vscode, vscodium, zoom and more.
Brave is app i am missing so far, but having the newest version KDE and other software that required a PPA on Ubuntu is pretty nice.
And it feels much snappier installed on a SATA SSD than Mint from a NVME SSD on the same machine!
Yes, actually I ran that for quite a while successfully before I switched to Arch Linux and Debian.
The auto-snapshot feature on updates was really cool, and direct integration then (almost 10 years ago for me) was ahead of most other distros IMO.
I then setup Arch to be more confronted with the things that actually go on under the hood, learned a lot and had generally a good experience with it. A bit later I got a job where Debian plays a key role, that sealed the deal on using Debian and Arch only for me (remembering the usage of two package managers is enough for me ^^).
But I have good memories of openSUSE, and it was the distro that I first used "full time", even introduced me to Linux to some degree (I dabbled a bit around with Ubuntu and Knoppix before).
This. Only rolling releases are fit for end user systems; point release is a server meme.
Not only is having new stuff good from a feature and hardware-support standpoint, but, paradoxically, new software seems to have WAY less bugs than old software. (I assume this is because devs are mainly on the new versions and don't care about old versions that much.) Try using CentOS 7, with ancient, should-be-rock-solid versions of apps. Dolphin crashes every time you load into a large directory. Kate's keybinds are broken. Tmux refuses to support 256 colors. I get none of these issues on Arch or Manjaro.
