Hacker News Reader

Comment by eternityforest | Hacker News Reader

Maybe Linux should just agree on a standard runtime like Steam has. That can be free and open and cross-distro, and be based on "API Levels" like anything else, so your app can target "API Level 27", and always be usable because API27 never changes, you just make a level 28 next year.

Eventually people would get tired of patching old ones, but at that point you just freeze them and have people use a VM to avoid the security holes.

Windows has compatibility mode for older windows. And it's great.

View on HN

congratulations, you have reinvented https://en.wikipedia.org/wiki/Linux_Standard_Base, which is dead. it's not a terrible idea, but had a number of fundamental problems. first, it was a massive undertaking primarily driven from the "enterprise" side with minimal support in the community. the former isn't necessarily an issue, but the latter was a death sentence for a supposedly comprehensive standard. furthermore, the goal of LSB is fundamentally at odds with the extensible and decentralized nature of Linux; full adoption would destroy most of the value of Linux as a customizable system.

funnily enough, though, Red Hat failed with LSB, but systemd is, for better or worse, accomplishing much of the same goals, causing many of the same issues of poor extensibility and customizability.

Linux seems to be a lot more enterprise dominated now, so perhaps LSB could make a comeback.

The new trendy solution seems to just be having different tiers for devices that can't handle the full thing.

Customizability itself is, to some degree at odds with pretty much all of what the majority of users who are not hobbyists want, so I'm not sure it's the best plan to prioritize that.

On the other hand, the current solution of pretending that only Ubuntu and Red Hat exist and leaving other distros to figure out the compatibility for themselves seems to be a slight less restrictive de facto standard that works well for most.

that's basically flatpak, although flatpak runtimes are versioned by year.month

But Debian/Ubuntu are resisting Flatpak.

Quick search shows Debian has a Flatpak package, which feels like the right amount of involvement. Ubuntu installing Snap packages via apt is exactly the behavior I don't want.

Canonical/Ubuntu are, not Debian.

I could see Steam/Proton evolving into a sort of gaming specialized cross platform runtime.

Or FreeBSD, or virtually every other OS out there. Honestly I do wonder why Valve chose Linux over FreeBSD for this use case; for a single-purpose machine FreeBSD offers a far more stable baseline.

FreeBSD has poor hardware support; the modern graphics acceleration drivers are simply ports of the Linux kernel code. Sure, Valve could port or rewrite the drivers for the limited set of devices they support, but why would they? Valve supports Linux not because of its technical advantages, but simply because it helps mitigate some of the Microsoft- and Apple-related business risks. Linux is undeniably a safer, more conservative business decision than FreeBSD.

> the modern graphics acceleration drivers are simply ports of the Linux kernel code.

Does that matter? If there is a stable driver that's what's important, and FreeBSD has if anything a better track record for maintaining drivers for longer, even if those drivers were originally ported from elsewhere.

> Linux is undeniably a safer, more conservative business decision than FreeBSD.

I disagree; safe and conservative is exactly what FreeBSD does better than Linux.

Safe and conservative isn't what's needed for gaming.

For example, a lot of the tricks that Proton relies on explicitly use patches to the Linux kernel to do with FUTEX_WAIT implementation, which have only been patched into mainline since 5.16 afaik, as well as bleeding edge Mesa/xorg versions, the current state of things is that it makes sense for them to base on a rolling release where they can frequently push system images with bleeding edge versions to the deck hardware.

Maybe a few years down the line it'd make more sense to base on something more stable like BSD, but things are moving very quickly in Linux+wine gaming support and it's actually helpful right now to be on experimental/unstable versions of certain things.

Tech almost always reaches a good enough point eventually. SSDs made electron apps good enough and IMHO somewhat made lightweight kind of an outdated idea.

Bullseye is the good enough point for basically everything other than gaming on debian distros, not much you can't do with juat the bullseye repos.

Now that Valve has decided Linux gaming is a real thing, within a few years Debian will probably be good enough for that..

Not that it will stop them from constantly changing stuff in breaking ways for 3% better performance....

I mean that didn't stop Sony from using it as the base for the PS4. Of course you're using the playstation userland on top of it though as Orbis OS.

It was _their_ hardware, Sony didn't care about generic hardware support, since they need to support their own only, and only they know how it works. Not at all the same thing.

The only thing Sony needed from FreeBSD was x86 support and generic kernel facilities such as memory, process and IO management. Everything else they wrote themselves for their proprietary hardware and userspace.

My brain's still on Steam Deck, sorry. In that context it would make sense.

Linux will not agree on anything.

Steam (or whoever at this point) could bring together the efforts put in static linking of Linux apps and combine it with some sort of app isolation (freebsd like "jailing"... maybe doable with lxc?) so that a game binary once linked doesn't need anything other than the kernel and the isolation keeps it from affecting other apps in case it is exploited because of vulnerabilities in statically linked parts of the binary.

This way, we could have forever running apps if that is what we want.

I mean, Steam installed from Flatpak (app isolation) running Windows games targeting a specific Proton version (static set of libraries inside another layer of isolation) is basically what you're asking for, and it already out there.

Reply on news.ycombinator.com