Comment by dazzawazza | Hacker News Reader

Comment by dazzawazza | Hacker News Reader

Parent Full thread

As someone who has just released[1] a first access game across Windows, macOS and Linux:

10 years ago developing on linux as a game developer was way worse than windows and MacOS, now there is no real difference at all. I speak as a long time UNIX user, Linux was terrible for C++ devleopment, debugging and asset creation/viewing (compared to the others) making gamedev tougher than it needed to be.

10 years ago linux's OpenGL drivers were behind even MacOS and way behind Windows OpenGL which was behind DirectX by quite some way. Now Linux's drivers are fairly good although it's still a nightmare upgrading radeon drivers and NVidia's drivers seem to be fickle. This leads to a lot of bugs from users and supporting various distro/hw/driver combinations.

Libraries like libSDL(2) were less mature 10 year ago, multi monitor, input and sound support were patchy because the Linux landscape was fragmented and buggy. Now libSDL2 is pretty much spot on. Mutli-monitor is doable (not as good as macOS but as good as windows), input is pretty good and sound is OK (but most people use FMOD which is superb).

Where Linux falls behind is deployment. No I am not going to ship my source for you to compile. itch.io and Steam go a long way to make it easy to deploy and crucially update the game. It's still a PITA to deploy a compiled app on Linux with unclear glibc versions and amazingly it's worse than MS DLL hell of MSVC redistributable shambles.

It's not impossible to overcome but it's a PITA for a small market. Not a good position to be in. I support macOS and Linux as well as Windows because I believe in plurality but I can see why many chose not to. Don't think that using Unity or Unreal make anything easier either. In many ways they are worse than a well written custom engine.

[1] https://executionunit.itch.io/smith-and-winston

> It's still a PITA to deploy a compiled app on Linux with unclear glibc versions and amazingly it's worse than MS DLL hell of MSVC redistributable shambles.

One option is to statically link against musl libc [1].

The kernel ABI is about the only stable thing you can rely on (which is something you _can't_ rely on for macOS or Windows).

[1] https://www.musl-libc.org/

Thank you. musl looks very interesting. It's something I didn't consider, I'll add it to my research list :)

Is it not possible to link glibc staticalliy? IIRC musl has readability and code size in mind while glibc optimizes for performance at the cost of readability and codesize.

The problem that I know of is that glibc supports loading DSO modules, eg. for NSS, so it's not going to support pluggable NSS sources like LDAP etc when statically linked. There are workarounds, however:

https://stackoverflow.com/questions/3430400/linux-static-lin...

Can't imagine many Linux gamers are going to need NSS support in their game binaries. It's a bit of a stretch to say glibc doesn't support static linking, perhaps "officially" it doesn't, its just not all the extended features are going to work.

Static linking is generally going to be frowned upon these days however since you're effectively linking security issues into the binary forever.

Not really. musl optimizes for performance and codesize, whilst glibc optimizes for the random user who needs to read error message in farsi and logs on via an external LDAP service, and needs LD and MALLOC hooks to debug weird edge cases.

glibc unicode tables are huge, musl are tiny.

glibc uses assembler optimizations for everything, whilst musl uses compiler auto-vectorization, which mostly beats handwritten assembly, esp. with constant arguments.

> The kernel ABI is about the only stable thing you can rely on (which is something you _can't_ rely on for macOS or Windows).

In Windows's case, technically accurate but not really relevant, since the interface for working with the base DLLs like kernel32, user32, etc. hasn't changed.

Sorry I wasn't clearer. I just meant that on Windows and macOS, you can rely on certain userland libraries, but not the kernel ABI, while on Linux you can rely on the kernel ABI, but not the libraries.

Note a program compiled with musl can't use shared libraries which were compiled with glibc. I wrote my own tiny x64 C standard library which, unlike musl, is compatible with other glibc libraries: https://github.com/procedural/c_stdlib

If you want an automated tool to generate a deb file for distribution, you might want to try this program I created for that purpose:

https://www.getlazarus.org/apps/makedeb/

Well, you should release the source code, or else a DOS executable file that can run on DOSBOX, or a .NES ROM image file, or whatever, the end user can then provide their own emulator to run it on. Only the end user shall have full control over what runs on their computer, not you.

I currently use Linux and it is much better than Windows (although I didn't like the desktop environment so I uninstalled it, but customizing the system is what I do regardless of what operating system).

> It's still a PITA to deploy a compiled app on Linux with unclear glibc versions

If you don't want to worry about the glibc version on your users' machines, you can just ship your dynamic linker and use it to run your executable in your wrapper script (you do have one, right?). Why's that so hard?

It's not hard, it's just stupid that the platform has such a remarkable lack of consistency that you can't rely on anything but the kernel ABI.

Heh, speaking on relying on APIs/ABIs, macOS must be a lot of fun with Apple deprecating OpenGL to begin with.

I honestly don't see the problem. It's a different platform so it's got different quirks, that's just life.

Having said that, I strongly prefer Linux's explicit shared object search paths and very user-friendly dynamic linker to Window's implicit search scheme (aka the DLL hell). If that means I need to add my dynamic linker along with a couple lines of wrapper script so my binaries work, so be it.

And, you can even avoid the wrapper script if you can make sure your stuff is always installed to a standard location (eg. /opt/yourcompany) and you pass -Wl,rpath to your linker (at compile time) but I really don't see the point.

> I honestly don't see the problem. It's a different platform so it's got different quirks, that's just life.

If Linux Desktop were one singe different platform there wouldn't be a problem. Instead it is effectively some ridiculously large number of platforms.

The differences between them are getting smaller and smaller with time. With the notable exceptions of some really cool distros like nixOS or Solus most others have almost the same libraries at this point at varying versions.

How about AppImage?

What about it? It doesn't solve the problem, it just allows you to conveniently package everything you can't rely on the distro having, which is basically everything.

Which was the complaint.

But the Linux kernel is really the only common thing you can expect across a wide array of distributions.

* If you're a GUI app you can also speak X11 with GLX and its up to the user to have something that understands your messages.

* If you want desktop integration you use one of the many dbus protocols and it's up to the user's DE to understand your requests.

* If you distribute through Steam you may also depend on the Steam runtime, but you have to be careful to only depend on what's provided.

* If you distribute through Flatpak or Snap you can also depend on any of the provided runtimes or build your own for maybe easier maintainability. It's essentially 'bundle everything' as a service.

tl;dr depend on protocols and runtimes, not libraries.

Also, nothing is stopping you from building against Ubuntu:latest. It's more cumbersome but Linux users will typically find a way to make your stuff work on other distros.

> Also, nothing is stopping you from building against Ubuntu:latest. It's more cumbersome but Linux users will typically find a way to make your stuff work on other distros.

This is not the mentality of anyone who cares about the user experience of the product.

"Mutli-monitor is doable (not as good as macOS but as good as windows), "

What's the gap between Linux/Windows and Mac OS ?

MacOS has had perfect crisp multi-monitor support including fractional scaling and mixed DPI with per-windiow/per-monitor application DPI awareness for years.

Windows is finally introducing a diagnostic in the task manager to show which applications have high DPI support. The modern option, per-monitor awareness, isn't even possible on Linux with the X display server - it requires Wayland.

This is the issue in a nutshell for me. I wish I’d bought a FHD 1080 screen instead of 4K on my XPS 13 for this very issue.

Wayland isn’t an option for me yet because I need screensharing under Hangouts, etc.

You can’t mix the HiDPI internal screen with, say, a 1440 external monitor with Gnome on X11. Scaling is applied equally across both.

Also if you drop back to plain text e.g. during boot up the internal screen will show text at 100% scaling and the text is tiny.

I guess that might be something BIOS could take care of but it’s currently a problem.

Sorry, can’t offer comparisons to Windows, I just work with macOS and Linux.

What do you use as a compiler? gcc?

Containers could be a way out for deployment, if the mixing of licenses can be constructed in a tractable way.

or snaps

even with snaps or whatever that thing ubuntu has?

Not everyone is on Ubuntu.

I currently have eight VMs each with different distros. Mostly it's for testing library compatability on install and input weirdness.

That's a lot of testing.

Snaps work on other Linux distros, not just Ubuntu. There is also Flatpak which may work even better. You should do your research.

He still has a deployment problem. Flatpak needs to be installed and requires users to set up repos, including flathub itself, so he has to have them jump through extra hoops even if he puts his product in the largest most default repo available.

From what I understand about Snap, the only difference is that that the One True Repo is installed by default.

AppImage is another option he could consider, which requires no repos or additional installs, just flipping the execute bit on the AppImage file. Unfortunately even that is spotty because there is no standard set of libraries to rely on like there is on other platforms, so he'd pretty much have to include everything from glibc up to be safe.

Snaps work on at least 40 different distros last time I looked. They remove a significant chunk of that 'library compatibility' because they ship the necessary dependencies in the package. While Ubuntu dominates the Linux desktop market, by a couple of orders of magnitude, we made snaps with the express intention of them working on all the major leading distros. The goal being to ensure you don't need to test on all those different distros. One snap to rule them all ;)

i think people mentioned snaps work on non-ubuntu systems. can't you build everything statically that you need, and deploy as snap? is it a ton more difficult than that? not saying thats easy, but seems less of a burden and you can hit at least a large amount of users

Reply on news.ycombinator.com