12 ms·

I agree, but I’m happy to see that Nix, Guix, and the one I do the most work on Spack are starting to gain some traction since they all do basically this. Makin

by trws 3y ago

I agree, but I’m happy to see that Nix, Guix, and the one I do the most work on Spack are starting to gain some traction since they all do basically this. Making it work is not always trivial though, and making it work efficiently is harder. Only in the last few years have I felt like we’re finally getting to the point where this is actually a maintainable model for the majority of software distribution. Here’s hoping it gets the rest of the way!

nerdponx 3y ago
Homebrew has been doing it for a long time. It's not known for being fast, but without profiling the application I'm hesitant to blame the file layout.
lproven 3y ago
They are, yes, but there is a very important core difference here that I think is not mentioned. The big cost about Nix/Guix that puts people off is that it eliminates a human-readable filesystem. The traditional layout is gone or empty, replaced by a tonne of folders under `/nix/` called stuff like `240-572-9837wfgjh234098672-_bash` and you have to just... *trust* that your path and so on will work and stuff will just get found somehow. You have to let go of navigating your own filesystem. That's just too much for a lot of people. The filesystem layout is one of Unix's defining characteristics. Whereas Gobo's goal is the opposite: yes, let us discard the traditional filesystem layout, but let's do it by making it more human readable instead. You can work out where things are without knowing. There's better isolation. It's like semantic versioning, applied to the filesystem: a semantic filesystem layout, where folder names encapsulate versioning info and are more meaningful than the old 1970s reduce-typing-effort-at-all-costs approach. Nix says ignore paths, ignore directories, you don't need them, we'll manage that for you. Gobo says forget traditional paths, here are some better ones that you will find easier and more useful. For me, that's an attractive proposition. In real life, it seems that both were too much for most people. My suggestion would be: why not merge them? Try to bring the advantages of Gobo -- readable, meaningful directory paths -- to a version of Nix. Instead of a flat directory tree with hashes, a consistent algorithm that categorises apps and puts them in a tree: /gonix/apps/gui/productivity/images/krita/5.1/ /gonix/apps/console/shell/bash/5.2/ /gonix/apps/programming/compilers/fpc/3.1/ /gonix/libraries/c/glibc/2.39 /gonix/apps/console/editors/vim/9.1 I am totally making these up, you understand, they're merely illustrative examples.
- Lurkki 3y ago
  With Nix /run/current-system/sw/ is basically the /usr of mutable FHS distros, with the difference that it's all read-only symlinks. So you can still look at the layout of your active system.
- pxc 3y ago
  > The big cost about Nix/Guix that puts people off is that it eliminates a human-readable filesystem. The traditional layout is gone or empty, replaced by a tonne of folders under `/nix/` called stuff like `240-572-9837wfgjh234098672-_bash` and you have to just... trust that your path and so on will work and stuff will just get found somehow. > You have to let go of navigating your own filesystem. Your broader point makes sense in that I get how a user-navigable filesystem is attractive, especially in the context of store paths being exposed to users as they are embedded in binaries and scripts. But I think the above is an overstatement. Stuff on NixOS gets on your path the exact same way as it does on any distro: a bit of shell! Users can read through the `set-environment` script and the config NixOS generates for their shell in /etc and all that. They can check what binaries are on their PATH with `which -a` as usual. They can ask their shell where a given variable was defined using the usual tools it offers. And the human-readable part of the filesystem does exist, just on top of the Nix store. The symlinks under /nix/var/nix/profiles/... or /run/current-system/sw are about as human-friendly as Unix ever is, imo. Perhaps NixOS could do more to make those 'official', foreground them and document them, and even provide more loosely versioned paths to them like you suggest (making it easier to impurely manually build against them).
  - lproven 3y ago
    I think you're missing multiple points here. Secondly, from my position as a tech writer (for about 25 years) overlapping for well over a decade with some 20-odd years as a software tech support person and trainer, I think you are dramatically over-estimating the level of understanding of the average Linux user. A Linux user can be expected to be a bit more clueful than a Windows user, but not much. They probably understand the concept of a "directory tree" and know that there are "files", some "executable", in "directories", one of which is "current", and stuff like that, but you can not rely on them grasping advanced concepts such as "search paths" and "links" (of different kinds, no less!) The idea that there's a second, "more standard" tree, and it's optionally overlayed on top of the flat software-managed Nix tree, made up of symbolic links, and that you don't need to know where things are because the software magically makes sure that the OS can find them... I'm sorry but after coming up on 40 years in tech, my reaction to that might be captured by the crying-laughing emoticon. You could no more explain that to the average distro-hopper than you could explain it to a Labrador dog. How it gets set? Don't care. A script is what I'd assume, sure, but that's no more important than the colour of the script's author's hair. I'm saying that, professionally, as a writer, I have now presented the concept to smart interested users that they let go of the filesystem hierarchy and just let the OS manage that, and I'd say about 9 out 10 of my readers responded "oh to h3ll with that! No WAY!" It is a step _much_ too far. It's comparable but worse than self-driving cars to these folks. To refer to memes again, you need the god-level intellect step of the intelligence meme: https://imgflip.com/i/45rmf2 https://imgflip.com/i/45rmf2 ... to grasp the concept that you don't need to know where files are so long as the OS knows. This is not one step too far. It is a two-year backpacking trip across all of Asia too far.

by trws 3y ago

nerdponx 3y ago

Homebrew has been doing it for a long time. It's not known for being fast, but without profiling the application I'm hesitant to blame the file layout.

lproven 3y ago

They are, yes, but there is a very important core difference here that I think is not mentioned. The big cost about Nix/Guix that puts people off is that it eliminates a human-readable filesystem. The traditional layout is gone or empty, replaced by a tonne of folders under `/nix/` called stuff like `240-572-9837wfgjh234098672-_bash` and you have to just... *trust* that your path and so on will work and stuff will just get found somehow. You have to let go of navigating your own filesystem. That's just too much for a lot of people. The filesystem layout is one of Unix's defining characteristics. Whereas Gobo's goal is the opposite: yes, let us discard the traditional filesystem layout, but let's do it by making it more human readable instead. You can work out where things are without knowing. There's better isolation. It's like semantic versioning, applied to the filesystem: a semantic filesystem layout, where folder names encapsulate versioning info and are more meaningful than the old 1970s reduce-typing-effort-at-all-costs approach. Nix says ignore paths, ignore directories, you don't need them, we'll manage that for you. Gobo says forget traditional paths, here are some better ones that you will find easier and more useful. For me, that's an attractive proposition. In real life, it seems that both were too much for most people. My suggestion would be: why not merge them? Try to bring the advantages of Gobo -- readable, meaningful directory paths -- to a version of Nix. Instead of a flat directory tree with hashes, a consistent algorithm that categorises apps and puts them in a tree: /gonix/apps/gui/productivity/images/krita/5.1/ /gonix/apps/console/shell/bash/5.2/ /gonix/apps/programming/compilers/fpc/3.1/ /gonix/libraries/c/glibc/2.39 /gonix/apps/console/editors/vim/9.1 I am totally making these up, you understand, they're merely illustrative examples.

Lurkki 3y ago
With Nix /run/current-system/sw/ is basically the /usr of mutable FHS distros, with the difference that it's all read-only symlinks. So you can still look at the layout of your active system.
pxc 3y ago
> The big cost about Nix/Guix that puts people off is that it eliminates a human-readable filesystem. The traditional layout is gone or empty, replaced by a tonne of folders under `/nix/` called stuff like `240-572-9837wfgjh234098672-_bash` and you have to just... trust that your path and so on will work and stuff will just get found somehow. > You have to let go of navigating your own filesystem. Your broader point makes sense in that I get how a user-navigable filesystem is attractive, especially in the context of store paths being exposed to users as they are embedded in binaries and scripts. But I think the above is an overstatement. Stuff on NixOS gets on your path the exact same way as it does on any distro: a bit of shell! Users can read through the `set-environment` script and the config NixOS generates for their shell in /etc and all that. They can check what binaries are on their PATH with `which -a` as usual. They can ask their shell where a given variable was defined using the usual tools it offers. And the human-readable part of the filesystem does exist, just on top of the Nix store. The symlinks under /nix/var/nix/profiles/... or /run/current-system/sw are about as human-friendly as Unix ever is, imo. Perhaps NixOS could do more to make those 'official', foreground them and document them, and even provide more loosely versioned paths to them like you suggest (making it easier to impurely manually build against them).
- lproven 3y ago
  I think you're missing multiple points here. Secondly, from my position as a tech writer (for about 25 years) overlapping for well over a decade with some 20-odd years as a software tech support person and trainer, I think you are dramatically over-estimating the level of understanding of the average Linux user. A Linux user can be expected to be a bit more clueful than a Windows user, but not much. They probably understand the concept of a "directory tree" and know that there are "files", some "executable", in "directories", one of which is "current", and stuff like that, but you can not rely on them grasping advanced concepts such as "search paths" and "links" (of different kinds, no less!) The idea that there's a second, "more standard" tree, and it's optionally overlayed on top of the flat software-managed Nix tree, made up of symbolic links, and that you don't need to know where things are because the software magically makes sure that the OS can find them... I'm sorry but after coming up on 40 years in tech, my reaction to that might be captured by the crying-laughing emoticon. You could no more explain that to the average distro-hopper than you could explain it to a Labrador dog. How it gets set? Don't care. A script is what I'd assume, sure, but that's no more important than the colour of the script's author's hair. I'm saying that, professionally, as a writer, I have now presented the concept to smart interested users that they let go of the filesystem hierarchy and just let the OS manage that, and I'd say about 9 out 10 of my readers responded "oh to h3ll with that! No WAY!" It is a step _much_ too far. It's comparable but worse than self-driving cars to these folks. To refer to memes again, you need the god-level intellect step of the intelligence meme: https://imgflip.com/i/45rmf2 https://imgflip.com/i/45rmf2 ... to grasp the concept that you don't need to know where files are so long as the OS knows. This is not one step too far. It is a two-year backpacking trip across all of Asia too far.