Hacker News Reader

Comment by zokier | Hacker News Reader

Eventually all Steam games will need to run in containers or something similar to manage the dependecy hell, expecting the host system to have some collection of libraries in compatible versions is just recipe for disaster.

View on HN

They already do even for native Linux games, that’s what Steam runtime is. Unfortunately some libraries need to be from the host (e.g. the Vulkan/OpenGL libraries).

> Unfortunately some libraries need to be from the host (e.g. the Vulkan/OpenGL libraries).

AFAIK, they don't need to be from the host, they only need to be compatible with the host hardware and the host kernel (and the kernel ABI stability rules makes this easier). For instance, when running the Steam flatpak, these libraries come from the freedesktop runtime, not from the host.

Yeah big -1 from me on Steam using its own graphics/sound/hmi drivers.

This is what flatpak solves

Static linking / bundling libraries helps absolutely nothing. My SimCity 3k from Loki is dead because of OSS vs lack of hardware mixing, because it tries to go fullscreen with nowadays unsupported resolutions and refresh rates, etc. . The static linked copy may actually "load" but it's actually the dynamic exec which saves the day since you can at least replace/hook some functions in order to provide better compatibility with a recent desktop.

You can still access those files in the flatpak, replace them with your new ones, and package it back as a flatpak and let users use it.

No, you can't. That would most certainly involve modifying and then redistributing a modified flatpak, which is certainly not going to fly in the face of binary-only proprietary software like the one most likely to benefit from a stable ABI over the years.

Not to mention, flatpak would still add nothing. Just additional annoyances.

Eventually == over a decade ago, at least on windows.

From a technical perspective, steam was originally basically just a chroot-style environment that let you have an independent set of DLLs installed for each windows game on your machine.

Before that, I averaged four hours of fucking around with directx diagnostic bullshit whenever I bought a new AAA title for windows (and getting the new game to work usually broke some old games)

These days, Steam’s Linux support for Windows games is better than native Windows support ever was.

Currently, they require a fairly small base set of 32 bit Linux libraries with a relatively stable ABI. That lets them abstract away all the other crap on your Linux desktop.

Agreed, I've gone through the same when I was on windows and switched back to Linux about three years ago. Windows games that I run, leading and AAA titles in some cases, runs better on Steam Proton.

Except Windows by and large satisfies that expectation.

Linux throwing backwards compatibility and stability out the window is one of the biggest reasons it doesn't appeal to the common user. Note that Android provides this (granted less than Windows does), and we see common people use Android.

And before you mention it: Yes, I know Linus Torvalds is (sort of) adamant about backwards compatibility; the problem is the rest of Linux does not and will not care.

Windows backwards compatibility for games is abysmal, up to the point users are forced to use Wine libraries to run old Windows games on Windows.

It's still not as bad as desktop Linux (e.g. some Loki games cannot even be loaded due to breaking changes in _glibc_ out of all libraries), but it is still bad enough to qualify as abysmal.

It’s particularly bad for Vista-era “Games for Windows” titles. Getting Fable III to run on a modern Windows requires so much hoop jumping you’d be forgiven for thinking you’re playing Portal.

That was a beautiful metaphor, and I’m stealing it.

Exactly, this is uniquely a linux problem that these consumer facing operating systems were designed to avoid. In theory all Steam needs is a proton version "good enough" to emulate a handful of major eras of Windows programs.

That "rest of Linux" that you talk about is not Linux at all.

What's another term you think they should use?

Maybe "commonly encountered Free Software desktop and server userspace components"? After all, much of that is what you will also find on BSDs et al., and will give you the same trouble (if any) there.

The Linux kernel itself is in fact very, VERY extensively backwards-compatible, which is why I find it particularly unfair (on top of being wrong) to use the label Dalewyn did. It's the installed userspace libraries that aren't - at least not in all cases, but the situation sure has improved a lot over the last decade or so.

>The Linux kernel itself is in fact very, VERY extensively backwards-compatible, which is why I find it particularly unfair (on top of being wrong) to use the label Dalewyn did.

Did I ever dispute that?

Ubuntu, Gnome, etc

This is already the case for GOG which - for the good old games - ships a bundled DOSBox container wrapping the game.

Reply on news.ycombinator.com