10 ms·

> As opposed to what? Programs including their dependencies. The Linux model of global shared libraries is an abject failure. It’s a failed model — and the pr

> As opposed to what? Programs including their dependencies. The Linux model of global shared libraries is an abject failure. It’s a failed model — and the prevalence of requiring Docker simply to launch a program is evidence of this. Windows doesn’t have global library folders that are polluted by a million user scripts. And you can reliably launch software that’s 25 years old. It works great. Linux’s model was a nice effort but ultimately a failure.

cesarb 2y ago
> Windows doesn’t have global library folders that are polluted by a million user scripts. C:\WINDOWS\SYSTEM32 It's called "DLL Hell" for a reason. It used to be very common for every program you installed to dump several libraries in that directory. It included program-specific libraries (so that directory would have a mix of internal libraries for every program you ever installed; pray there were no naming conflicts!), compiler runtime libraries like the C library (and it was not uncommon for a program to overwrite an already existing runtime DLL with an older version, breaking other programs which expected the newer version), and sometimes even operating system libraries. It got so bad that IIRC Microsoft made Windows automatically detect when an important operating system DLL had been overwritten, and restore it from a secret copy of the original DLL it had stashed elsewhere.
- forrestthewoods 2y ago
  > It used to be very common for every program you installed to dump several libraries in that directory. Maybe back on Windows 95? Hasn’t been the case or an issue in as long as I can remember. > It's called "DLL Hell" for a reason. Linux shared library hell is at least a full order of magnitude more complex, fragile, and error prone. Launching a Linux program is so outrageously unreliable that everyone uses Docker just to run a bloody program! It’s so so bad. At least in the year two thousand and twenty four.
max-privatevoid 2y ago
Programs potentially duplicating dependencies at a quadratic rate is an equally abject failure. It's the other extreme of the dependency sharing spectrum. Share, but don't overshare. If two programs share a dependency, and that dependency is the exact same (by content or by its inputs, when using a pure build system), they may share the dependency. If not, you install the dependency "twice" (it's not really twice, because it's not the same dependency, so two dependencies, each installed once).
- forrestthewoods 2y ago
  > at a quadratic rate wat? Worst case is linear. Every program duplicates everything it needs. Which honestly is just totally fine. How is this quadratic?
  - max-privatevoid 2y ago
    Quadratic in the sense that, in the worst case, you have N programs sharing the same set of M dependencies, requiring N*M components worth of space. With sharing, it would only be N+M.
    - forrestthewoods 2y ago
      Ah yeah. Feels like you could argue either way! In any case I don’t think library duplication is a meaningful issue in most cases. As evidenced by everyone using Docker which duplicates libraries! Feels like this could be totally solved at the filesystem level with copy-on-write de-duplication. The best of both worlds!
      - max-privatevoid 2y ago
        FS deduplication solves the problem at the storage level, but not at the transfer level. The components would still be downloaded multiple times if the downloader doesn't have a way to know what has already been downloaded. Docker's way of doing things is basically an admittance of defeat by lazy engineers. We can do better than that.

cesarb 2y ago

> Windows doesn’t have global library folders that are polluted by a million user scripts. C:\WINDOWS\SYSTEM32 It's called "DLL Hell" for a reason. It used to be very common for every program you installed to dump several libraries in that directory. It included program-specific libraries (so that directory would have a mix of internal libraries for every program you ever installed; pray there were no naming conflicts!), compiler runtime libraries like the C library (and it was not uncommon for a program to overwrite an already existing runtime DLL with an older version, breaking other programs which expected the newer version), and sometimes even operating system libraries. It got so bad that IIRC Microsoft made Windows automatically detect when an important operating system DLL had been overwritten, and restore it from a secret copy of the original DLL it had stashed elsewhere.

forrestthewoods 2y ago
> It used to be very common for every program you installed to dump several libraries in that directory. Maybe back on Windows 95? Hasn’t been the case or an issue in as long as I can remember. > It's called "DLL Hell" for a reason. Linux shared library hell is at least a full order of magnitude more complex, fragile, and error prone. Launching a Linux program is so outrageously unreliable that everyone uses Docker just to run a bloody program! It’s so so bad. At least in the year two thousand and twenty four.

max-privatevoid 2y ago

Programs potentially duplicating dependencies at a quadratic rate is an equally abject failure. It's the other extreme of the dependency sharing spectrum. Share, but don't overshare. If two programs share a dependency, and that dependency is the exact same (by content or by its inputs, when using a pure build system), they may share the dependency. If not, you install the dependency "twice" (it's not really twice, because it's not the same dependency, so two dependencies, each installed once).

forrestthewoods 2y ago
> at a quadratic rate wat? Worst case is linear. Every program duplicates everything it needs. Which honestly is just totally fine. How is this quadratic?
- max-privatevoid 2y ago
  Quadratic in the sense that, in the worst case, you have N programs sharing the same set of M dependencies, requiring N*M components worth of space. With sharing, it would only be N+M.
  - forrestthewoods 2y ago
    Ah yeah. Feels like you could argue either way! In any case I don’t think library duplication is a meaningful issue in most cases. As evidenced by everyone using Docker which duplicates libraries! Feels like this could be totally solved at the filesystem level with copy-on-write de-duplication. The best of both worlds!
    - max-privatevoid 2y ago
      FS deduplication solves the problem at the storage level, but not at the transfer level. The components would still be downloaded multiple times if the downloader doesn't have a way to know what has already been downloaded. Docker's way of doing things is basically an admittance of defeat by lazy engineers. We can do better than that.