5 ms·

It talks about installing apps. But what about DLLs? .NET framework versions?

pjmlp 6y ago
It has been ages that the best practices are to install them alongside the applications instead of polluting C:\Windows. Also .NET Core is supposed to be bundled with the application.
- rbanffy 6y ago
  Unfortunately, this causes file duplication (which is not that bad these days of endless storage) and unnecessary vulnerabilities when outdated vendored libraries are used by applications. Linux distributions tend to keep shared libraries in their own packages and applications depend on them so that when you install an app, the packages with the libraries also get installed. And all packages in the distribution tend to use the same versions of those shared libraries.
  - pjmlp 6y ago
    Which is why nowadays Linux suffers more from .so hell and ABI breakages than Windows does.
    - rbanffy 6y ago
      Haven't seen that in ages, but, then, I try to avoid installing packages from non-official repos. Distributions work hard to make sure that everything within the distro ecosystem is self-consistent.
      - AnIdiotOnTheNet 6y ago
        Exactly, if you're not doing anything interesting you'll never notice, but the second you step out of the distro's box and do something crazy like try and install a new version of software direct from the developer, install a second version for testing, or run software compiled 10 years ago, the world falls apart.
        rbanffy 6y ago
        > if you're not doing anything interesting you'll never notice s/interesting/suicidal/ Replacing .so binaries with other arbitrary .so binaries is not what I would call "interesting". Interesting is deleting your /var folder. Or doing a `find /sys/devices/system/cpu -name 'online' -exec echo 0 > {} \;`.
    - derefr 6y ago
      Not really? In the Debian ecosystem, at least (can't speak for any other), every major version of a library package is expected to be packaged as its own separate concurrently-installable package. You'll find e.g. postgresql-11-dev and postgresql-12-dev both exist as packages, and one provides libpq.11.y.z.so + its headers, while the other provides libpq.12.y.z.so + its headers. Each gets updates independently. One will never automatically switch you over to the other. And major versions are the only things that need to be separately packaged, because the Linux native-library ecosystem is expected to keep .so ABI compatibility through both "patch" and "minor" updates (the only difference between the two being that "minor" updates can add new exported symbols to the library; they still should not break usages of existing symbols.) This particular arrangement was, in fact, what the Semantic Versioning standard was introduced to accomplish—getting upstream developers to use their version-tuples to mean the same things that Linux-distro package maintainers expect them to mean, allow Linux-distro package maintainers to reuse upstream version schemes rather than needing to maintain their own.
      - kasabali 6y ago
        All true in theory, but in practice these mechanisms are worthless because for most libraries Debian developers are dropping older version of libraries immediately after transition to the new version is completed. Want to to run a 3rd party binary that depends on an older library? You're favorite package was dropped during the transition? Tough luck. Your best bet is installing needed library packages from previous debian release and praying that'll work.
        derefr 6y ago
        True enough, but if stability is your desire, that is precisely why distros cut releases (and especially LTS releases) in the first place. If you want a program that can run without ABI-conformance changes for years and years, base it on an LTS release, and that LTS release will keep whatever ABI-major versions of the .so library-packages it shipped with updated (with security updates, at least) until the release's EOL. If you don't want ABI breakage, then don't dist-upgrade! But, this is also to say: if you're creating a new, greenfield project, or a new major version of your own app—and you haven't yet deployed it into the wild as a fixed binary that people rely on to continue running on their boxes between upgrades—then nobody else but you has any incentive to keep things stable for you. If you want to develop against the newest Debian release at any given time, then it's up to you to catch up to whatever the newest ABI-major versions of your deps are at any given time. That's a problem you've chosen for yourself.
    - jfkebwjsbx 6y ago
      Never had a single issue with official repositories.
  - contextfree 6y ago
    fwiw, on Windows MSIX deduplicates identical files across all package installs.
    - rbanffy 6y ago
      It gives rise to some interesting issues - if program A wants to update IMPORT~1.DLL that was installed also by program B, what happens if B requires a different version of IMPORT~1.DLL?
      - pjmlp 6y ago
        They don't, because MSIX introduces UWP sandboxes also for Win32 applications.
        rbanffy 6y ago
        In other words, because runtime dependency management is terrible, Microsoft added a core feature to the OS.
        pjmlp 6y ago
        Yeah, lets pretend SNAP and Flatpak don't exist.
        rbanffy 6y ago
        No, but we can pretend they are a good idea.
      - contextfree 6y ago
        Then they'll no longer be identical, so they'll go back to having separate files.

It has been ages that the best practices are to install them alongside the applications instead of polluting C:\Windows. Also .NET Core is supposed to be bundled with the application.

rbanffy 6y ago
Unfortunately, this causes file duplication (which is not that bad these days of endless storage) and unnecessary vulnerabilities when outdated vendored libraries are used by applications. Linux distributions tend to keep shared libraries in their own packages and applications depend on them so that when you install an app, the packages with the libraries also get installed. And all packages in the distribution tend to use the same versions of those shared libraries.
- pjmlp 6y ago
  Which is why nowadays Linux suffers more from .so hell and ABI breakages than Windows does.
  - rbanffy 6y ago
    Haven't seen that in ages, but, then, I try to avoid installing packages from non-official repos. Distributions work hard to make sure that everything within the distro ecosystem is self-consistent.
    - AnIdiotOnTheNet 6y ago
      Exactly, if you're not doing anything interesting you'll never notice, but the second you step out of the distro's box and do something crazy like try and install a new version of software direct from the developer, install a second version for testing, or run software compiled 10 years ago, the world falls apart.
      - rbanffy 6y ago
        > if you're not doing anything interesting you'll never notice s/interesting/suicidal/ Replacing .so binaries with other arbitrary .so binaries is not what I would call "interesting". Interesting is deleting your /var folder. Or doing a `find /sys/devices/system/cpu -name 'online' -exec echo 0 > {} \;`.
  - derefr 6y ago
    Not really? In the Debian ecosystem, at least (can't speak for any other), every major version of a library package is expected to be packaged as its own separate concurrently-installable package. You'll find e.g. postgresql-11-dev and postgresql-12-dev both exist as packages, and one provides libpq.11.y.z.so + its headers, while the other provides libpq.12.y.z.so + its headers. Each gets updates independently. One will never automatically switch you over to the other. And major versions are the only things that need to be separately packaged, because the Linux native-library ecosystem is expected to keep .so ABI compatibility through both "patch" and "minor" updates (the only difference between the two being that "minor" updates can add new exported symbols to the library; they still should not break usages of existing symbols.) This particular arrangement was, in fact, what the Semantic Versioning standard was introduced to accomplish—getting upstream developers to use their version-tuples to mean the same things that Linux-distro package maintainers expect them to mean, allow Linux-distro package maintainers to reuse upstream version schemes rather than needing to maintain their own.
    - kasabali 6y ago
      All true in theory, but in practice these mechanisms are worthless because for most libraries Debian developers are dropping older version of libraries immediately after transition to the new version is completed. Want to to run a 3rd party binary that depends on an older library? You're favorite package was dropped during the transition? Tough luck. Your best bet is installing needed library packages from previous debian release and praying that'll work.
      - derefr 6y ago
        True enough, but if stability is your desire, that is precisely why distros cut releases (and especially LTS releases) in the first place. If you want a program that can run without ABI-conformance changes for years and years, base it on an LTS release, and that LTS release will keep whatever ABI-major versions of the .so library-packages it shipped with updated (with security updates, at least) until the release's EOL. If you don't want ABI breakage, then don't dist-upgrade! But, this is also to say: if you're creating a new, greenfield project, or a new major version of your own app—and you haven't yet deployed it into the wild as a fixed binary that people rely on to continue running on their boxes between upgrades—then nobody else but you has any incentive to keep things stable for you. If you want to develop against the newest Debian release at any given time, then it's up to you to catch up to whatever the newest ABI-major versions of your deps are at any given time. That's a problem you've chosen for yourself.
  - jfkebwjsbx 6y ago
    Never had a single issue with official repositories.
- contextfree 6y ago
  fwiw, on Windows MSIX deduplicates identical files across all package installs.
  - rbanffy 6y ago
    It gives rise to some interesting issues - if program A wants to update IMPORT~1.DLL that was installed also by program B, what happens if B requires a different version of IMPORT~1.DLL?
    - pjmlp 6y ago
      They don't, because MSIX introduces UWP sandboxes also for Win32 applications.
      - rbanffy 6y ago
        In other words, because runtime dependency management is terrible, Microsoft added a core feature to the OS.
        pjmlp 6y ago
        Yeah, lets pretend SNAP and Flatpak don't exist.
        rbanffy 6y ago
        No, but we can pretend they are a good idea.
    - contextfree 6y ago
      Then they'll no longer be identical, so they'll go back to having separate files.