6 ms·

This may actually be better in the long run. Almost all proprietary Linux binaries I've seen shipped in the wild link to shared system libraries -- and tend to

This may actually be better in the long run. Almost all proprietary Linux binaries I've seen shipped in the wild link to shared system libraries -- and tend to fall apart when the system libraries are a different version than expected. If you're shipping Linux binaries, you really should be linking statically! Any shared libraries you need, like OpenGL, you should load manually with dlsym. A windows binary targeting Wine will not stop working just because some shared system library has been updated.

AnIdiotOnTheNet 8y ago
> Almost all proprietary Linux binaries I've seen shipped in the wild link to shared system libraries -- and tend to fall apart when the system libraries are a different version than expected. This is probably the biggest problem with Linux as a desktop, and the sad reality is that it will never ever be fixed because the community has an almost religious adherence to their completely broken platform model. Maybe if Valve puts enough effort into WINE, the future of the open source desktop will be WINE on top of the Linux kernel? That'd be... tolerable.
- yrro 8y ago
  Well, now we have flatpak and snap to work around the "broken" software distribution models of most distros... That said, if you ship an application that depends on system libraries then you're just setting yourself up for problems. There's really no excuse to not do things properly!
  - AnIdiotOnTheNet 8y ago
    And before them we had GNUStep Application Bundles, ROX Filer AppDirs, and Klik (now AppImage). Flatpak and Snap do have some "advantages" over those from a Linux Desktop Community perspective though: They're incredibly over-engineered and they're the same idea implemented twice. > That said, if you ship an application that depends on system libraries then you're just setting yourself up for problems. Only on Linux, which is kinda my point. Other platforms are actually, you know, platforms.
    - Skunkleton 8y ago
      Linux implements several platforms. The issue is that the API is stable at the _source_ level, not the binary level. I guess the ideal for Linux would be for these games to be open source, but of course that will not (should not?) happen for obvious reasons.
      - ezoe 8y ago
        The obvious solution is, distribute the source code and build on end user's environment. Distributing the source code doesn't necessarily mean free software. Since those free software haters(idiots if you ask me), has no problem distributing game assets and compiled binary to the user, why is the source code exception? If you are idiot enough to want the source code to be secret, just minify and uglify the source code. Uglified source code is as readable as compiled binary.
  - tomrod 8y ago
    I've never heard of these. Can you give more info?
    - chupasaurus 8y ago
      tl;dr: Both are running applications with the exact versions of dependencies inside a separated environment (read as mount namespaces, there could be mounted directories from main file hierarchy).
    - gregknicholson 8y ago
      https://lmddgtfy.net/?q=flatpak https://lmddgtfy.net/?q=flatpak https://lmddgtfy.net/?q=snap%20linux https://lmddgtfy.net/?q=snap%20linux
    - Sylos 8y ago
      Flatpak and Snap are new package formats, which allow bundling software with all the libraries that it needs. Advantage is that developers can package exactly those versions of the libraries that they tested with and know to be working. Disadvantage is that if there's a security problem or bug in one of those libraries, you're dependent on the developer to release a new version of the Flatpak or Snap package. Another disadvantage is that libraries can't be shared between applications, which increases hard drive and RAM usage. A second important aspect of Flatpak and Snap packages, which is however not relevant to the discussion, is that the execution of the packaged applications is done in a sandboxed environment.
      - jrrrr 8y ago
        Are they exactly as portable as a statically linked binary, or more? (I vaguely recall static binaries still depending on kernel versions, or something like that)
        AnIdiotOnTheNet 8y ago
        I'm not super familiar with Flatpak and Snap, but I don't think so. They each require a runtime and use special fixed directories. AppImage requires no runtime (or more accurately, it is part of the package) and is almost as portable as a statically linked binary, largely because it is (practically) a statically linked binary. > I vaguely recall static binaries still depending on kernel versions, or something like that This has to do with glibc. If you don't use glibc you don't really have to worry about it.
- Valmar 8y ago
  > completely broken platform model Hardly. It works extremely well for Linux distribution maintainers, and for the FOSS projects that work with this model in mind. Within the FOSS community, the platform model is excellent. It doesn't work so well for proprietary application developers, who should just be using static libs because of this.

AnIdiotOnTheNet 8y ago

> Almost all proprietary Linux binaries I've seen shipped in the wild link to shared system libraries -- and tend to fall apart when the system libraries are a different version than expected. This is probably the biggest problem with Linux as a desktop, and the sad reality is that it will never ever be fixed because the community has an almost religious adherence to their completely broken platform model. Maybe if Valve puts enough effort into WINE, the future of the open source desktop will be WINE on top of the Linux kernel? That'd be... tolerable.

yrro 8y ago
Well, now we have flatpak and snap to work around the "broken" software distribution models of most distros... That said, if you ship an application that depends on system libraries then you're just setting yourself up for problems. There's really no excuse to not do things properly!
- AnIdiotOnTheNet 8y ago
  And before them we had GNUStep Application Bundles, ROX Filer AppDirs, and Klik (now AppImage). Flatpak and Snap do have some "advantages" over those from a Linux Desktop Community perspective though: They're incredibly over-engineered and they're the same idea implemented twice. > That said, if you ship an application that depends on system libraries then you're just setting yourself up for problems. Only on Linux, which is kinda my point. Other platforms are actually, you know, platforms.
  - Skunkleton 8y ago
    Linux implements several platforms. The issue is that the API is stable at the _source_ level, not the binary level. I guess the ideal for Linux would be for these games to be open source, but of course that will not (should not?) happen for obvious reasons.
    - ezoe 8y ago
      The obvious solution is, distribute the source code and build on end user's environment. Distributing the source code doesn't necessarily mean free software. Since those free software haters(idiots if you ask me), has no problem distributing game assets and compiled binary to the user, why is the source code exception? If you are idiot enough to want the source code to be secret, just minify and uglify the source code. Uglified source code is as readable as compiled binary.
- tomrod 8y ago
  I've never heard of these. Can you give more info?
  - chupasaurus 8y ago
    tl;dr: Both are running applications with the exact versions of dependencies inside a separated environment (read as mount namespaces, there could be mounted directories from main file hierarchy).
  - gregknicholson 8y ago
    https://lmddgtfy.net/?q=flatpak https://lmddgtfy.net/?q=flatpak https://lmddgtfy.net/?q=snap%20linux https://lmddgtfy.net/?q=snap%20linux
  - Sylos 8y ago
    Flatpak and Snap are new package formats, which allow bundling software with all the libraries that it needs. Advantage is that developers can package exactly those versions of the libraries that they tested with and know to be working. Disadvantage is that if there's a security problem or bug in one of those libraries, you're dependent on the developer to release a new version of the Flatpak or Snap package. Another disadvantage is that libraries can't be shared between applications, which increases hard drive and RAM usage. A second important aspect of Flatpak and Snap packages, which is however not relevant to the discussion, is that the execution of the packaged applications is done in a sandboxed environment.
    - jrrrr 8y ago
      Are they exactly as portable as a statically linked binary, or more? (I vaguely recall static binaries still depending on kernel versions, or something like that)
      - AnIdiotOnTheNet 8y ago
        I'm not super familiar with Flatpak and Snap, but I don't think so. They each require a runtime and use special fixed directories. AppImage requires no runtime (or more accurately, it is part of the package) and is almost as portable as a statically linked binary, largely because it is (practically) a statically linked binary. > I vaguely recall static binaries still depending on kernel versions, or something like that This has to do with glibc. If you don't use glibc you don't really have to worry about it.
Valmar 8y ago
> completely broken platform model Hardly. It works extremely well for Linux distribution maintainers, and for the FOSS projects that work with this model in mind. Within the FOSS community, the platform model is excellent. It doesn't work so well for proprietary application developers, who should just be using static libs because of this.