7 ms·

> lipstick on a pig Yes!! > dancing around the core issue that `foo.exe` cannot ever realize `foobar-v1.8` and `foobar-v1.7` are both installed on the same co

> lipstick on a pig Yes!! > dancing around the core issue that `foo.exe` cannot ever realize `foobar-v1.8` and `foobar-v1.7` are both installed on the same computer I’m curious if you have an opinion on how you think this should be handled? At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every world. I also blame C/C++ toolchains for being very very bad on Linux.

mikepurvis 1mo ago
I mean... a big part of that with conventional Linux distros is the idea that you can security-update a low level library and all the stuff linking to it gets the fixes "for free", a dream abandoned both by Nix and also the movement toward distribution via containers/flatpaks/VMs/whatever.
- forrestthewoods 1mo ago
  I do like to say that the Linux shared library strategy has objectively failed. Containers / packs exist because it failed so hard.
hugmynutus 1mo ago
> I’m curious if you have an opinion on how you think this should be handled? To "totally overcomplicate things" but do it correctly - Binary states a list of constraints (namespace:name [<|>|>=|<=|!=] semver). - ldconf/ld.so either integrate into your package manager and/or are easier to update (I'm not writing conf files by hand and/or flakes). I should simply be able to recursively scan. - Give the runtime linker an SMT constraint solver (when <1000 this is nearly instant) - Cache known states to avoid solving NP hard problems every time you launch `cat`. > At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every world. Honestly same. Having the package manager <-> elf runtime <-> shared libraries more-or-less be a blackbox is probably for the best (which is sort of what windows does with the install-shield/install-wizard stuff). But nobody in Linux Land really wants to "improve" userland, other then change to flavor-of-the-month display managers. > I also blame C/C++ toolchains for being very very bad on Linux. They honestly aren't, it is more your pacakge manager *is* your library manager. Because of the absolute bullshit of shared libraries. If you pretend it is the 1970/80s everyone at your company has the architecture, unix version, etc. It is pretty nice. No cross compiling, multiple OSs, everything just sort of works pretty well. But like I said, "pretend".
- forrestthewoods 1mo ago
  > They honestly aren't, it is more your pacakge manager is your library manager. Because of the absolute bullshit of shared libraries. Hrm. It’s trivial for Linux to cross-compile for Windows because Windows is sane. It requires moving mountains for Windows to cross-compile to Linux. Hell, the only way Linux can reasonably compile to target an older version of glibc is to create a full container image containing and using the old glibc. It’s absurd. I suppose this isn’t the root evil. But it feels related to me. Maybe not. Sigh.

mikepurvis 1mo ago

I mean... a big part of that with conventional Linux distros is the idea that you can security-update a low level library and all the stuff linking to it gets the fixes "for free", a dream abandoned both by Nix and also the movement toward distribution via containers/flatpaks/VMs/whatever.

forrestthewoods 1mo ago
I do like to say that the Linux shared library strategy has objectively failed. Containers / packs exist because it failed so hard.

hugmynutus 1mo ago

> I’m curious if you have an opinion on how you think this should be handled? To "totally overcomplicate things" but do it correctly - Binary states a list of constraints (namespace:name [<|>|>=|<=|!=] semver). - ldconf/ld.so either integrate into your package manager and/or are easier to update (I'm not writing conf files by hand and/or flakes). I should simply be able to recursively scan. - Give the runtime linker an SMT constraint solver (when <1000 this is nearly instant) - Cache known states to avoid solving NP hard problems every time you launch `cat`. > At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every world. Honestly same. Having the package manager <-> elf runtime <-> shared libraries more-or-less be a blackbox is probably for the best (which is sort of what windows does with the install-shield/install-wizard stuff). But nobody in Linux Land really wants to "improve" userland, other then change to flavor-of-the-month display managers. > I also blame C/C++ toolchains for being very very bad on Linux. They honestly aren't, it is more your pacakge manager *is* your library manager. Because of the absolute bullshit of shared libraries. If you pretend it is the 1970/80s everyone at your company has the architecture, unix version, etc. It is pretty nice. No cross compiling, multiple OSs, everything just sort of works pretty well. But like I said, "pretend".

forrestthewoods 1mo ago
> They honestly aren't, it is more your pacakge manager is your library manager. Because of the absolute bullshit of shared libraries. Hrm. It’s trivial for Linux to cross-compile for Windows because Windows is sane. It requires moving mountains for Windows to cross-compile to Linux. Hell, the only way Linux can reasonably compile to target an older version of glibc is to create a full container image containing and using the old glibc. It’s absurd. I suppose this isn’t the root evil. But it feels related to me. Maybe not. Sigh.