5 ms·
Poor stow. We used it in the stone age about 20 years ago for unpackaged, shared software management on academic research clusters (Think "/usr/{{other hierarch
by throwiforgtnlzy 3y ago
Poor stow. We used it in the stone age about 20 years ago for unpackaged, shared software management on academic research clusters (Think "/usr/{{other hierarchy}}" over NFS). The problem with it is it depends entirely on symlinks and some programs get confused or just don't like them.
Nix, hab/habitat, containers, or overlay filesystems (such as with flatpak, etc.) are options that might work better that get around this problem.
- blablabla123 3y agoI used to use it quite a lot actually. Nowadays maybe twice a year if I need to install a messy source dependency cleanly. For such rare usages symlink handling is quite a non-issue. When I used it so intensively, actually I mostly used xstow which can automatically resolve common conflicting symlinks on directories, unfortunately that's not maintained anymore. (Sure, there's Nix and containers but stow is way faster)
- throwiforgtnlzy 3y agoApples (stow) and oranges (containers and exo-package builders and management). When using commands in conflict with the installed base combined and with things that should run unmodified, it gets tricky, usually in the form of shim binaries or improper PATH manipulation, to run things sufficiently isolated and predictably. It's cheap enough and reduces the risks for leaking dependencies to create a chroot/jail/cgroup environment that only includes just enough of a standard environment and its specific dependencies rather than allowing unfettered access to all the things at all times. Depends on what you're doing whether some things can be shoveled in or need more isolation guarantees.