4 ms·

Usually tracking down old versions of libraries works, except when it doesn't of course. If the source is available, I think "just compile it" is kind of okay t

Usually tracking down old versions of libraries works, except when it doesn't of course. If the source is available, I think "just compile it" is kind of okay to be honest; it's usually not that hard, and if it is, then that's kind of a problem with that software's build system IMHO. I compiled xv from 1994 the other day on my Linux box; just has to make a tiny patch to fix an include (lots of warning, but it compiles and runs). That said, there's some room for improvement. For example pkg-config/pkgconf could automatically suggest which packages to install if "pkg-config --libs x11" fails, or some other distro-agnostic way for people to track down dependencies. If you're shipping a binary program without source (i.e. a game, for example, which tend to be closed source) you should ship the libraries or compile things statically. Some of the older Linux games on gog.com can be a bit tricky to run on modern systems due to this.

moffkalast 4y ago
> tracking down old versions of libraries works See that's the thing, everything on linux is designed to work by sideloading as much as possible, depending on thirty thousand packages that must be all installed to the perfect version by apt or else nothing works. A good system if you need to get a fully featured OS running on 100 MB of disk space, which tbf is linux's niche, but it's absolute horseshit to maintain. Windows on the other hand tends to have flatpak-style monolithic executables, with the odd .NET framework or cpp resdistrubutable here and there, but it's the rare exception. Things tend to actually work when they bundle their dependencies. Hell, the average Java app ships the JRE along with it because nothing works if the wrong version is installed globally. Linux just takes that problem as a fact of life and tells you to fuck off.
- Beltalowda 4y ago
  In general, I'm a fan of statically linked binaries or shipping the libraries with the application, so I mostly agree with you. But I also can't deny there's advantages to the shared-link approach as well. In short, there's upsides and downsides to both approaches and no perfect solution. In practice however, I rarely encounter issues, except for closed-source programs that don't ship their libraries. That, I think, is mostly the fault of the vendor and not the Linux system. Of course, as a user it doesn't really matter whose fault it is if your application doesn't work because you just want the damn thing to work. It does mean the problem (and solution) is mostly an educational one, rather than a technical one. You certainly can ship binary programs that should work for decades to come: the two core components (Linux kernel and GNU libc) take backwards compatibility pretty serious, more or less on equal level with Windows. You don't even need flatpack. A wrapper script with "LD_LIBRARY_PATH=. ./binary" gets you a long way (and still provides people the ability to use a system library if they want, so sort-of the best of both worlds).
- tadfisher 4y ago
  That's everything on Unix-likes with shared libraries, yes. You can statically-link or use a system like Nix or Guix that don't enforce a single library version (by ditching the "default library search path" concept), and you get the best of both worlds: space saved for most of your shared library dependencies, and separate versions for those binaries that need them. It's basically Unix with a garbage collector.
- int_19h 4y ago
  These days, Windows doesn't tend to have monolithic executables - look inside the installation folder of a random app, and chances are good that you'll see a bunch of DLLs aside from the CRT. Also, .NET apps are normally redistributed as a bunch of assemblies, even aside from the CLR. The key difference is that each app bundles its DLLs for its own private use. From the user's perspective, it's essentially the same as static linking, if you treat the entire folder as "the app".
  - pjmlp 4y ago
    That is exactly what the op meant with " flatpak-style monolithic executables". In MS speak, it is xcopy install, based on how MS-DOS applicatons used to be distributed, even when static linking was the only option (with overlays).

moffkalast 4y ago

> tracking down old versions of libraries works See that's the thing, everything on linux is designed to work by sideloading as much as possible, depending on thirty thousand packages that must be all installed to the perfect version by apt or else nothing works. A good system if you need to get a fully featured OS running on 100 MB of disk space, which tbf is linux's niche, but it's absolute horseshit to maintain. Windows on the other hand tends to have flatpak-style monolithic executables, with the odd .NET framework or cpp resdistrubutable here and there, but it's the rare exception. Things tend to actually work when they bundle their dependencies. Hell, the average Java app ships the JRE along with it because nothing works if the wrong version is installed globally. Linux just takes that problem as a fact of life and tells you to fuck off.

Beltalowda 4y ago
In general, I'm a fan of statically linked binaries or shipping the libraries with the application, so I mostly agree with you. But I also can't deny there's advantages to the shared-link approach as well. In short, there's upsides and downsides to both approaches and no perfect solution. In practice however, I rarely encounter issues, except for closed-source programs that don't ship their libraries. That, I think, is mostly the fault of the vendor and not the Linux system. Of course, as a user it doesn't really matter whose fault it is if your application doesn't work because you just want the damn thing to work. It does mean the problem (and solution) is mostly an educational one, rather than a technical one. You certainly can ship binary programs that should work for decades to come: the two core components (Linux kernel and GNU libc) take backwards compatibility pretty serious, more or less on equal level with Windows. You don't even need flatpack. A wrapper script with "LD_LIBRARY_PATH=. ./binary" gets you a long way (and still provides people the ability to use a system library if they want, so sort-of the best of both worlds).
tadfisher 4y ago
That's everything on Unix-likes with shared libraries, yes. You can statically-link or use a system like Nix or Guix that don't enforce a single library version (by ditching the "default library search path" concept), and you get the best of both worlds: space saved for most of your shared library dependencies, and separate versions for those binaries that need them. It's basically Unix with a garbage collector.
int_19h 4y ago
These days, Windows doesn't tend to have monolithic executables - look inside the installation folder of a random app, and chances are good that you'll see a bunch of DLLs aside from the CRT. Also, .NET apps are normally redistributed as a bunch of assemblies, even aside from the CLR. The key difference is that each app bundles its DLLs for its own private use. From the user's perspective, it's essentially the same as static linking, if you treat the entire folder as "the app".
- pjmlp 4y ago
  That is exactly what the op meant with " flatpak-style monolithic executables". In MS speak, it is xcopy install, based on how MS-DOS applicatons used to be distributed, even when static linking was the only option (with overlays).