[crickey]

This is only because of the nature of dynamic linking. Have a statically linked executable and you should be fine. Not that it should be an issue to get old software to run you simply need to download the dependent lib versions. Anyone who sais this i feel hasnt worked very much with software, not that you should need to thats up to the one distributing the executable

[brigade]

What you mean is: the only stable ABI in Linux is the Linux kernel’s itself.

Windows is the opposite: the only stable ABI is the dynamically linked user space ABI. So yes, it’s perfectly possible to have a stable dynamic ABI across a dynamically linked boundary.

[imtringued]

There used to be operating systems where the only stable interface was glibc.

[memefrog]

>Windows is the opposite: the only stable ABI is the dynamically linked user space ABI.

... to the kernel. So not the opposite at all. In fact exactly the same.

[brigade]

No. The userspace/kernel boundary is explicitly not stable on Windows, and binaries that try to use that interface have broken when it changed.

[Macha]

This is true for basically ever OS other than Linux, as the Golang developers learned the hard way on macOS and BSD.

[memefrog]

which is why the Linux approach is superior: it has a stable ABI that is language-agnostic.

[memefrog]

That is completely irrelevant to the discussion. The point is that both systems have very stable ABIs. Windows has a somewhat higher-level stable ABI, but as a result it is a much wider surface to keep compatible, it breaks much more often, it requires a lot more hacks to keep it stable over time (program-specific hacks kept around for decades), etc.

This is the point of difference: the layer at which each is stable. NOT whether Linux is stable.

[brigade]

The nature of stability literally is the discussion; I replied to a post that blamed the lack of a Linux equivalent to Win32 on dynamic linking. That the stable ABI you get on Linux requires you to bundle literally every dependency you have as if distros don't exist... And then still have issues because the kernel ABIs for graphics are entirely GPU dependent...

The two approaches are definitively not the same (as you claim), and the significant shortcomings of Linux's approach are why Win32 is becoming the ABI devs target even on Linux.

[memefrog]

>That the stable ABI you get on Linux requires you to bundle literally every dependency you have as if distros don't exist...

This is not true. If your target platform is a distribution then you can assume that distribution's guarantees hold true.

What you cannot do is target "GNU/Linux" broadly and assume every glibc-based system running on top of the Linux kernel has all the libraries you want to depend on.

Pick a platform and target it. That can be the kernel. That can be glibc+the kernel (hey look GNU/Linux really is useful terminology), that can be RHEL9 or it can be Debian xyz. But don't pick "Linux" then make assumptions about userspace.

[gjsman-1000]

Unless you statically linked GTK, possibly Xorg, and more into a ludicrous bundle size, you’d still be screwed.

As for “just get the libs,” that’s hilariously easier said than done. Try my example - it’s enough to make an engineer cry.

[filmor]

Your example doesn't make sense. Linux distributions have always had this trade off: Binaries provided through the package manager work with the libraries that are provided by the same package manager. I have a bunch of older gog or Humble Bundle Linux releases of games that still work fine on my system because (Windows style) they carry around all of their libraries with them. Linking Xorg doesn't make sense and applications linked statically against libX11 will work perfectly fine even with Xwayland.

[crickey]

https://www.x.org/wiki/Releases/ https://www.gtk.org/docs/installations/linux/ I mean it will probably not be painless and other applications u run might break* but xorg is relativly stable. Liba are out there are free to get. Usually people are arguing that the conveniences isnt there not that its not possible.

* if u dont sandbox this a bit with custom lib paths

[gjsman-1000]

I didn’t dispute that it isn’t possible.

What I am disputing is how this comes off to a game developer; 5 years from now, heck, 2 years from now when their games require library surgery to keep running... that’s just an awful experience.

That is not what a developer would consider a stable ABI. They could look into Flatpak - but look at what’s trending on Hacker News today - a rant against Flatpak.

Win32 over Proton is the winner for them; all other proposed solutions are hilariously naive and optimistic to what game development requires. No game developer is ever going to individually package, and consistently repackage, their game for 20 distributions. That’s never going to happen.

[smoldesu]

> No game developer is ever going to individually package, and consistently repackage, their game for 20 distributions.

Nor do they. Steam Linux Runtime exists.

[memefrog]

There is no "library surgery". This is EXACTLY what people are forced to do on Windows already: bundle all dependencies.

>No game developer is ever going to individually package, and consistently repackage, their game for 20 distributions. That’s never going to happen.

Nobody has suggested they should.

[crickey]

Well u sure made an effort to exclaim how hard it would be. If a developer had an install guide with links to dependencies or mirrors to those dependencies it wouldnt be very hard as they should have internally for their dev/ testing. Do windows devs not track their dependencies? Relying only on Win32 ? Whos the naive one ?

[memefrog]

No video game has any use for GTK+.

XLib is tiny by modern standards.

[simion314]

>No video game has any use for GTK+

my memory might be wrong but I had issues with native linux games that had level editor based on GTK and python, could not get them to run after 3 years since launch, I do not claim it is impossible just that I could not do it with some a few hours effort.