Hacker News new | ask | show | jobs
by thesnide 524 days ago
I was thinking that way in the past. But then, the only stable ABI is the win32 one.

The linux kernel one is very stable, but the libs ones isn't.

As soon as the dev ensure and cooperates with wine/proton to make it work nicely, i'm game.

Needing those old libs in linux is rather cumbersome, if at all possible. So having wine doing the translation layer is a really good thing. As it frees the devs to be able to focus on 1 plateform.

I also noted that the switch enabled a lot of linux native ports. That's also a nice side effect.

3 comments

> the only stable ABI is the win32 one

TBF, that's also true when compared to Windows. The only actually stable ABI in all major OS's are Linux Win32 via Wine.

You can create portable apps on Linux that will work for years to come. Bundle everything except for very core libraries, even libstd++. Things to NOT bundle would be glibc and any opengl implementation. To make apps backwards compatible with older versions of Linux, compile the app on a system with the oldest glibc you wish to support (because glibc is forwards compatible, but not backwards compatible).
This never really works in practice, far too many variations and compilation differences between distros. The Linux Standard Base was an attempt to do this and it went.... no where.

> (because glibc is forwards compatible, but not backwards compatible).

I've lost count of times I've had "portable" binaries not work because I'm using a newer version of glibc and the binary was compiled for Ubuntu/Debian.

The only "standardised" way of making native Linux apps portable and "work for life" is to use the thing that worked in the server space, containers, Flatpak being the vendor-neutral and more widely supported for desktop apps.

Is this something that Flatpak could fix?
Steam can already use bwrap (Flatpaks sandbox system) with its own runtime to accomplish this, but why bother when you can just target Win32 and have it work out the box.

Outside of graphic and input, game engines make use of very few native APIs compared to applications as they're made to be portable with consoles.