4 ms·

A mounted FS per installed application so you can run different versions side by side. I like it for large standalone apps, less so for command-line utilities.

A mounted FS per installed application so you can run different versions side by side. I like it for large standalone apps, less so for command-line utilities. It easily beats untarring some third-party thing to /opt.

AnIdiotOnTheNet 6y ago
> A mounted FS per installed application so you can run different versions side by side. Does it strike anyone else as very telling that people looked at the problem of "we can't install more than one version of an application at a time because of how we structure our filesystem and hardcode paths" and decided that the solution was "let's give each application its own filesystem!"?
- sebastos 6y ago
  I know, what's up with this? I always feel like the systems guys must know something I don't, and that it would be way harder than I'm imagining. But like.. haven't we learned enough in the last 30 years to know that we need something smarter for mutually dependent pieces of software? Why is nobody trying to do this? I get that Docker, Snap, Flatpak, etc. are expedient in the here and now. But shouldn't we be trying to rebuild everything on top of nix, and then make nix completely transparent to most users?
- barrkel 6y ago
  ISTM that anything which lets you install multiple versions side by side will require each version to have pinned versions of dependencies, transitively, until it's very close to the dominant node, which ultimately is the OS API, which in turn, done right, is backward compatible. You can implement that versioned dependency DAG as a database of versioned libraries etc. combined with a version pinning database; or you can simply use disk space, and keep a copy of every dependency and put each in its own subtree, making the version pinning database implicit in the tree construction. I don't see the latter solution as being intrinsically worse than the former. I don't think there's a real alternative either; the most reliable set of dependencies is the same set as the original binary was built and tested with. (And of course it's not just libraries, but also configs of various flavours, assets, etc. If you didn't use the subtree approach, you'd need to reimplement it in a shim layer to simulate it, in order to package yesterday's applications today.)
  - m4rtink 6y ago
    For the record Flatpak solves the same issue without mountpoint spam by using OSTree zo store flatpaks and their shared runtimes. Not only that, it gets full deduplication of everything and diff downloads just by using OSTree. AFAIK Snap has no deduplication of installed stuff & not even any dhared runtimes. Not sure if it has diff downloads.
    - brnt 6y ago
      Snap has all of that too.
      - m4rtink 6y ago
        Must have been added since I last looked into it - got any links with more info about it ? :)
- xfer 6y ago
  There are multiple groups of people. This problem has been addressed by the nix package manager the way you would expect.

AnIdiotOnTheNet 6y ago

> A mounted FS per installed application so you can run different versions side by side. Does it strike anyone else as very telling that people looked at the problem of "we can't install more than one version of an application at a time because of how we structure our filesystem and hardcode paths" and decided that the solution was "let's give each application its own filesystem!"?

sebastos 6y ago
I know, what's up with this? I always feel like the systems guys must know something I don't, and that it would be way harder than I'm imagining. But like.. haven't we learned enough in the last 30 years to know that we need something smarter for mutually dependent pieces of software? Why is nobody trying to do this? I get that Docker, Snap, Flatpak, etc. are expedient in the here and now. But shouldn't we be trying to rebuild everything on top of nix, and then make nix completely transparent to most users?
barrkel 6y ago
ISTM that anything which lets you install multiple versions side by side will require each version to have pinned versions of dependencies, transitively, until it's very close to the dominant node, which ultimately is the OS API, which in turn, done right, is backward compatible. You can implement that versioned dependency DAG as a database of versioned libraries etc. combined with a version pinning database; or you can simply use disk space, and keep a copy of every dependency and put each in its own subtree, making the version pinning database implicit in the tree construction. I don't see the latter solution as being intrinsically worse than the former. I don't think there's a real alternative either; the most reliable set of dependencies is the same set as the original binary was built and tested with. (And of course it's not just libraries, but also configs of various flavours, assets, etc. If you didn't use the subtree approach, you'd need to reimplement it in a shim layer to simulate it, in order to package yesterday's applications today.)
- m4rtink 6y ago
  For the record Flatpak solves the same issue without mountpoint spam by using OSTree zo store flatpaks and their shared runtimes. Not only that, it gets full deduplication of everything and diff downloads just by using OSTree. AFAIK Snap has no deduplication of installed stuff & not even any dhared runtimes. Not sure if it has diff downloads.
  - brnt 6y ago
    Snap has all of that too.
    - m4rtink 6y ago
      Must have been added since I last looked into it - got any links with more info about it ? :)
xfer 6y ago
There are multiple groups of people. This problem has been addressed by the nix package manager the way you would expect.