Hacker News Reader

Hey, someone who thinks the same way I do. Never thought I'd run into another native port advocate in 2023.

That said: it's funny you talk about rewards offered by Valve and then list 4 Valve Games. I know they wouldn't do that, but it'd be hilarious to think about.

> Isn’t that is unfair? Not as long others use incompatible APIs (Mantel and Direct3D) and enforce users to switch platforms (all consoles). Apple, Microsoft, Sony and Nintendo use platform exclusive titles for decades.

I don't see it as unfortunate, since very few devs are going to make games specifically to compete for saving 15% on rev-share. That's a huge gamble. And no one is going to bet on Linux exclusives for a chance to save 30%

The only potentially unfair issue may be that some AAA game ends up getting the rewards, the sort of studios who'd need that money the least. But that is ultimately what we want to encourage, so IDK. Maybe 2 rewards, one for general and one for "small teams" (defining that term will take a lot of fanagling).

I hope for both and the categories are aiming for both. I assume “also Linux” for AAA and the “only Linux” for small independent developers :)

What I expected for 2023 was Half-Life 3 with a Linux port. And the press release stating that a Windows port “may” follow later but not now.

I used to feel like this, but then ran into games like S.H.O.G.O:MAD and Terminus, and The Bard's Tale - those have native Linux ports, and they're pretty much un-playable these days. Using Proton, I can run even problematic old games like Dark Messiah of Might and Magic (that won't even run on Windows anymore!).

I feel like insisting on Linux native ports is letting perfect be the enemy of the good, and that native ports don't necessarily guarantee anything at all.

I certainly do appreciate developers who can provide native ports, though. In the end, I just want to relax and shoot alien space nazis in the face, and not think about how to get the alien space nazis to run on my machine.

The high-quality ports are being limited by how dependencies work on Linux distros. You're tied to a very specific version of a library. Fine if you can just recompile the code every time the version changes, but not fine if you're shipping an unchanging binary.

Meanwhile in Windows land, you static link everything and import only the system DLLs, and everything is great. You can't do that on Linux even if you wanted to.

That is what closed-source software does on Linux and Windows and Mac. Usually all required libraries are shipped with the executable. Most don’t link statically, sometimes this even isn’t possible.

People also ship Microsoft’s system libraries. Windows tends to be in “undefined state” due to missing package management (file corruption), broken Windows-Update or whatever went wrong.

It is hard teaching developers not to package their software for Linux! Native packages are maintained by distributions and require well documented dependencies only. Instead many developers maintain themself various packages for outdated distributions not used by anyone. Examples?

    * Amazons MP3-Downloader (that’s old)
    * Valve (shipping only for Ubuntu but they learned to allow redistribution quickly, one of the first requests came from Arch)     
     * Microsoft with Teams (yes, they should know better…)

But they want to package?

Do it once with Flatpak. No Snap! No AppImage. Just Flatpak. It is designed for that usage.

Else?

Provide binaries in tar.gz, document instructions, allow in any case redistribution. Always. If need the distribution maintainers will care. If not the users can copie them just on disk.

Its pretty easy to statically link with musl on linux.

I heard that attempting to load dynamic libraries from an executable using MUSL was difficult. Specifically when the library you want to load imports libc.