Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's ancient and Valve had to do tons of backports to support it properly. I imagine they didn't like that very much.


Pedantic comment: it’s not that Debian itself is ancient, it’s that they prioritize stability and thus older packages. Both Arch and Debian get frequent updates in their packages, but Arch prefers cutting edge cool and Debian prefers “don’t break any users existing setups!”

Arch is still a better choice because gaming is generally using cutting edge software.


And yet, Debian based desktop systems are the ones that have always broken after updates for me. It was only when I started using an Arch based system that I was able to go past 6 months without any issues. I’ve been running Manjaro now on three different systems for almost 3 years. No other Linux desktop has ever lasted this long for me and I’m not even a newbie. I’ve been using Linux since Red Hat 4. I’ve actually had less problems with it than I have had with any other desktop of us including Windows and Mac.


If you're combining external packaging and debian packaging, or installing things manually, this is typical. Oftentimes if you're doing those, you'll have broken dependencies because Debian lags behind. I had issues keeping Blender and some other creative software up to date, because of this.

It works great if you mostly stick to official Debian packages through and through.


Yeah, I almost always need something from an external repository with Debian based systems.

I need external repositories (albeit rarely) with Arch too though and that has never caused a problem.


I was same, but now in Docker era, I no longer need to install newer programs directly on base system OS.


My solution on Debian has been to use Flatpak.


So Debian is fine if you want to use your desktop computer like an iPhone?


Or you can put in enough time and effort to actually read error messages and do a little work

If you want iPhone ease Linux use Ubuntu based distros. But traditionally Linux hadn’t been single click easy. Much like smartphones weren’t originally iPhone level easy.

Polite edit: if you’re a Linux noob start with a vm or live disk Ubuntu image and play around. If you like computers and understanding them, you’ll find the lessons you need as you need them by searching the web. Then you’ll install a bunch of distros and understand what I mean.


Could just have switched to Debian Sid, which is basically the rolling release variant of Debian.

That could have saved some time on tooling/packaging adaptions.

Not that I dislike Arch Linux, I run both Arch Linux and Debian (Stable on servers Sid on laptop).


Sid is still far behind most rolling release distributions, and anecdotally I haven't found it more stable than any of the ones I usually use.


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.


Looks like the Deck is using an AMD GPU, which tend to have good mainline support.


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.


Debian GNU/Linux: operating system so conservative that “unstable” means production ready rolling release

(My go-to though)


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.


What does Valve have to backport? Surely games aren’t targeting super new libraries? (I’d expect Valve themselves to be the ones deciding what versions are targeted.)


3d graphics libraries, drivers, input libraries, etc. It is a nightmare getting the latest versions for those on Debian/Ubuntu. Valve is pushing Linux gaming forward a lot and recent package versions are required in order to run games well.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: