4 ms·

I wanted to quote a few parts of the article that I considered incorrect, but then realized I would be quoting most of the article. Short version, almost anyone

I wanted to quote a few parts of the article that I considered incorrect, but then realized I would be quoting most of the article. Short version, almost anyone who's ever tried to ship a nontrivial game on Linux should realize this article is wrong. I particularly disagree with the idea that doing any dynamic linking in a program at all means that instantly it's just as non-portable as a fully dynamically linked program. These things are a continuum, there are degrees of fragility -- you can make a program that breaks less often when ported to new systems. See some of Ethan Lee's writing on this topic.[0] On a meta-level, you should be instantly suspicious of any programming advice that includes quotes like: > Conclusion: Never use [thing]! > This has never been the case and never will be the case. In reality, most software techniques have benefits and downsides. If a debate has survived for over a decade, that means that the answer probably isn't so completely universal that you can completely ignore one side. I'm not going to say that there are no black-and-white correct answers in software development, but people who regularly claim to have found them should be regarded with suspicion. On average, they'll often just be oversimplifying things. [0]: https://gist.github.com/flibitijibibo/b67910842ab95bb3decdf89d1502de88 https://gist.github.com/flibitijibibo/b67910842ab95bb3decdf8...

klodolph 6y ago
Games on Linux are a beast, aren’t they! I think doing this kind of thing successfully requires making good decisions about which dependencies you consider to be part of the system and which dependencies you want to include with your application. For example, it is fairly reasonable to require LibSDL2 to be installed. However, if you bundle LibSDL2 with your app, you’re now directly dependent on things like X11 and ALSA.
- AnIdiotOnTheNet 6y ago
  > I think doing this kind of thing successfully requires making good decisions about which dependencies you consider to be part of the system and which dependencies you want to include with your application. Herein lies the problem, because Linux has absolutely no distinction between "system" and "application". Everything is part of the system.
- donio 6y ago
  Controversial opinion but making sure that your game runs well under Wine is not the worst way to ship games for Linux. This is especially true once the game gets older and less supported. The native Linux libraries might move on over time and the version you require might become unavailable or broken in some way but once a game works on Wine it will likely continue working forever unless you make some change to break it. These days when it comes to my Steam library I am less worried about the Proton[1] games than the native ones and there have been several cases where I opted to run the Proton version because it worked better than native. [1] Proton is the version of Wine Steam uses
- Joker_vD 6y ago
  > For example, it is fairly reasonable to require LibSDL2 to be installed. You mean, "the game's package has libsdl2 listed as a requirement"? Or "if you install the game without libsdl2 present, it will install, but will crash on launch"? > However, if you bundle LibSDL2 with your app, you’re now directly dependent on things like X11 and ALSA. Well, either those are present and the game will work, or you've tried to install the game on a headless server and surely you don't expect to miraculously just work?
  - klodolph 6y ago
    > You mean, "the game's package has libsdl2 listed as a requirement"? Or "if you install the game without libsdl2 present, it will install, but will crash on launch"? Are you some kind of malevolent genie? Trying to figure out the worst possible user experience that corresponds to the words I wrote? > Well, either those are present and the game will work, or you've tried to install the game on a headless server and surely you don't expect to miraculously just work? The assumption here is that the only two options are either “X11+ALSA” or “headless”, and I don’t agree with that assumption. SDL2 on Linux has two video drivers and five audio drivers. Fact is, I can run horribly old Linux software that uses SDL for audio and it works fine, but old software that uses OSS or /dev/dsp is not going to work. With Wayland, I think it's not unreasonable to prefer a dependency on SDL over a direct dependency on X11.
    - Joker_vD 6y ago
      Oh, I think I understand your point now: there are old versions of SDL2 for old Linuxes, and more recent versions of SDL2 for modern Linuxes, and they use different Linux subsystems, but since they have the same API, any old software that used SDL2 still functions properly to modern Linux even though the low levels of the stack have changed dramatically. Yes, that's a valid point actually. But ultimately it's a bet on what API will end up more durable: X11 or SDL2, isn't it?
      - klodolph 6y ago
        Yeah, it’s a bet on which API is more durable. Some other minor factors are that you might want a newer SDL anyway, because the library comes with a database of different models of gamepads (https://github.com/gabomdq/SDL_GameControllerDB https://github.com/gabomdq/SDL_GameControllerDB) and if you link against SDL dynamically, you get support for newer gamepad models for “free”. One of the other factors here is that the ability to play old games is in some sense about the preservation of culture. If you have an x64 Linux binary that uses SDL + OpenGL, I have a strong feeling that you’ll be able to play it 20 years from now, although it might inconvenient to get working.
vvanders 6y ago
> I'm not going to say that there are no black-and-white correct answers in software development, but people who regularly claim to have found them should be regarded with suspicion. I'm going to go a step further and say that the whole reason that software exists as a large profession is specifically because these trade-offs and domain and situation specific. If we really had one-size-fits-all software as a whole would largely be a solved domain.
cycloptic 6y ago
>almost anyone who's ever tried to ship a nontrivial game on Linux should realize this article is wrong. How? I'm honestly confused what you mean here, can you explain how to build a nontrivial game on Linux while statically linking GL/Mesa/X11/Wayland/ALSA/Pulseaudio/libpng/etc, and guaranteeing that it will work on all systems and won't have any issues or security problems? Because as far as I can tell this is close to impossible. Or do you consider use of dlopen to be a different case than what the article is discussing?
- danShumway 6y ago
  You don't need to statically link core standard libraries (you don't want to ship an entire OS), but neither should you dynamically link everything in your program. If you go into shipping a game using only dynamic linking (as this article advocates), then you're going to run into a bunch of portability problems. I'm hard pressed to think of a reason you would ever want to dynamically link to something like vorbis or libpng for a game. The goal is not ideological purity in either direction, it's to minimize compatibility issues. It's to look at each library and decide whether the upsides of using the system's version (assuming it has that library) override the downsides of needing to deal with all of the different systems and library versions people might be running.
  - cycloptic 6y ago
    Examples of CVEs in libpng and libvorbis are not exactly hard to find: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5146 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5146 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7317 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7317 If your nontrivial game has an online component with voice chat or custom avatars or something like that, then you now have an attack vector. If your game is closed source, I hope you are following updates from these libraries and either updating your vendored copy or backporting patches and then immediately pushing out a new release whenever an upstream update is published. And you will likely want to be committed to doing this for however many years you plan to keep your game online. And if you're going through all the trouble of doing that, I don't see what benefit you're getting from static linking these libraries anymore. (Unless the argument is that you're going to patch it faster than the distros)
gridlockd 6y ago
There are still too many people out there who think (or even insist) that you should ship your game on Linux. This has never been the case and never will be the case.
m463 6y ago
The problem is that linux is pretty much a source-level operating system. It's designed that way philosophically and practically... or is that impractically? Dynamic linking is probably your path if you're developing an app that is packaged and shipped with some distribution of linux and you use standard interfaces. But yeah, a game would make this all wrong. With dynamic linking your game would last one release cycle. As soon as ubuntu 20.04 comes out, your 18.04 game would stop working. You'd get some weird shared library mismatch in your 100 dependencies and that would be that. try this for fun: cd /usr/bin ldd mplayer

klodolph 6y ago

Games on Linux are a beast, aren’t they! I think doing this kind of thing successfully requires making good decisions about which dependencies you consider to be part of the system and which dependencies you want to include with your application. For example, it is fairly reasonable to require LibSDL2 to be installed. However, if you bundle LibSDL2 with your app, you’re now directly dependent on things like X11 and ALSA.

AnIdiotOnTheNet 6y ago
> I think doing this kind of thing successfully requires making good decisions about which dependencies you consider to be part of the system and which dependencies you want to include with your application. Herein lies the problem, because Linux has absolutely no distinction between "system" and "application". Everything is part of the system.
donio 6y ago
Controversial opinion but making sure that your game runs well under Wine is not the worst way to ship games for Linux. This is especially true once the game gets older and less supported. The native Linux libraries might move on over time and the version you require might become unavailable or broken in some way but once a game works on Wine it will likely continue working forever unless you make some change to break it. These days when it comes to my Steam library I am less worried about the Proton[1] games than the native ones and there have been several cases where I opted to run the Proton version because it worked better than native. [1] Proton is the version of Wine Steam uses
Joker_vD 6y ago
> For example, it is fairly reasonable to require LibSDL2 to be installed. You mean, "the game's package has libsdl2 listed as a requirement"? Or "if you install the game without libsdl2 present, it will install, but will crash on launch"? > However, if you bundle LibSDL2 with your app, you’re now directly dependent on things like X11 and ALSA. Well, either those are present and the game will work, or you've tried to install the game on a headless server and surely you don't expect to miraculously just work?
- klodolph 6y ago
  > You mean, "the game's package has libsdl2 listed as a requirement"? Or "if you install the game without libsdl2 present, it will install, but will crash on launch"? Are you some kind of malevolent genie? Trying to figure out the worst possible user experience that corresponds to the words I wrote? > Well, either those are present and the game will work, or you've tried to install the game on a headless server and surely you don't expect to miraculously just work? The assumption here is that the only two options are either “X11+ALSA” or “headless”, and I don’t agree with that assumption. SDL2 on Linux has two video drivers and five audio drivers. Fact is, I can run horribly old Linux software that uses SDL for audio and it works fine, but old software that uses OSS or /dev/dsp is not going to work. With Wayland, I think it's not unreasonable to prefer a dependency on SDL over a direct dependency on X11.
  - Joker_vD 6y ago
    Oh, I think I understand your point now: there are old versions of SDL2 for old Linuxes, and more recent versions of SDL2 for modern Linuxes, and they use different Linux subsystems, but since they have the same API, any old software that used SDL2 still functions properly to modern Linux even though the low levels of the stack have changed dramatically. Yes, that's a valid point actually. But ultimately it's a bet on what API will end up more durable: X11 or SDL2, isn't it?
    - klodolph 6y ago
      Yeah, it’s a bet on which API is more durable. Some other minor factors are that you might want a newer SDL anyway, because the library comes with a database of different models of gamepads (https://github.com/gabomdq/SDL_GameControllerDB https://github.com/gabomdq/SDL_GameControllerDB) and if you link against SDL dynamically, you get support for newer gamepad models for “free”. One of the other factors here is that the ability to play old games is in some sense about the preservation of culture. If you have an x64 Linux binary that uses SDL + OpenGL, I have a strong feeling that you’ll be able to play it 20 years from now, although it might inconvenient to get working.

vvanders 6y ago

> I'm not going to say that there are no black-and-white correct answers in software development, but people who regularly claim to have found them should be regarded with suspicion. I'm going to go a step further and say that the whole reason that software exists as a large profession is specifically because these trade-offs and domain and situation specific. If we really had one-size-fits-all software as a whole would largely be a solved domain.

cycloptic 6y ago

>almost anyone who's ever tried to ship a nontrivial game on Linux should realize this article is wrong. How? I'm honestly confused what you mean here, can you explain how to build a nontrivial game on Linux while statically linking GL/Mesa/X11/Wayland/ALSA/Pulseaudio/libpng/etc, and guaranteeing that it will work on all systems and won't have any issues or security problems? Because as far as I can tell this is close to impossible. Or do you consider use of dlopen to be a different case than what the article is discussing?

danShumway 6y ago
You don't need to statically link core standard libraries (you don't want to ship an entire OS), but neither should you dynamically link everything in your program. If you go into shipping a game using only dynamic linking (as this article advocates), then you're going to run into a bunch of portability problems. I'm hard pressed to think of a reason you would ever want to dynamically link to something like vorbis or libpng for a game. The goal is not ideological purity in either direction, it's to minimize compatibility issues. It's to look at each library and decide whether the upsides of using the system's version (assuming it has that library) override the downsides of needing to deal with all of the different systems and library versions people might be running.
- cycloptic 6y ago
  Examples of CVEs in libpng and libvorbis are not exactly hard to find: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5146 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5146 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7317 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7317 If your nontrivial game has an online component with voice chat or custom avatars or something like that, then you now have an attack vector. If your game is closed source, I hope you are following updates from these libraries and either updating your vendored copy or backporting patches and then immediately pushing out a new release whenever an upstream update is published. And you will likely want to be committed to doing this for however many years you plan to keep your game online. And if you're going through all the trouble of doing that, I don't see what benefit you're getting from static linking these libraries anymore. (Unless the argument is that you're going to patch it faster than the distros)

gridlockd 6y ago

There are still too many people out there who think (or even insist) that you should ship your game on Linux. This has never been the case and never will be the case.

m463 6y ago

The problem is that linux is pretty much a source-level operating system. It's designed that way philosophically and practically... or is that impractically? Dynamic linking is probably your path if you're developing an app that is packaged and shipped with some distribution of linux and you use standard interfaces. But yeah, a game would make this all wrong. With dynamic linking your game would last one release cycle. As soon as ubuntu 20.04 comes out, your 18.04 game would stop working. You'd get some weird shared library mismatch in your 100 dependencies and that would be that. try this for fun: cd /usr/bin ldd mplayer