6 ms·

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 el

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.
  - pxc 3y ago
    > 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. This is easy for me to believe :) > you can not rely on [Linux users] grasping advanced concepts such as "search paths" and "links" (of different kinds, no less!) Those are required for understanding how conventional Linux distros work, too, though. So the users who won't understand $PATH on NixOS are also users who don't understand how $PATH works on Ubuntu. I will admit that there's a difference here in that you can have a very half-assed understanding of Ubuntu, and even a half-assed understanding of NixOS probably has a higher skill/knowledge floor. And maybe I've unthinkingly assumed that half-assed understandings are worth less than they really are, at least psychologically. I have a very half-assed understanding of how my car works, but having it not be a complete wonder and mystery to me does give me more confidence in driving the thing— even if most of my knowledge of how it works is too incomplete to be practically useful and I'll always take it to a specialist if it has problems. > You could no more explain [the Nix symlink forest] to the average distro-hopper than you could explain it to a Labrador dog. Maybe the average distro-hopper matters because the average Linux user is a distro-hopper. But I think distro-hoppers are kind of a pathological case here, because distro-hopping is precisely the habit of throwing your hands up, blasting away your whole setup, and clicking Next Next Next instead of learning how your system works. Of course distro-hoppers are going to struggle to understand how their distros work! To distro-hop is to enact a commitment to not understanding your distro!! I also wonder if this is really true, and this is probably the part where I am just naive. But a forest of symlinks would be super easy to diagram perfectly faithfully, and I think a visual aid like that could go a really long way for the average person. > the concept that you don't need to know where files are so long as the OS knows. Have you seen this article, posted to HN to some infamy, about how zoomers don't expect to know/care where their files are, and are in fact somewhat baffled at the very question of where they've saved something? https://www.theverge.com/22684730/students-file-folder-directory-structure-education-gen-z https://www.theverge.com/22684730/students-file-folder-direc... I what that generational gap says for the viability (in terms of user acceptance) of the Nix store in all its ugly glory in the future. I want to be clear that I do think some of your suggestions for laying out the files differently (like Spack apparently does) are perfectly reasonable. There are technical and historical reasons that the store is hash-first, but maybe they're worth re-evaluating. Sometimes I think the real winner, some day, in terms of executing this idea beautifully and in a user-friendly way, will be on a 'brand new' OS where a different executable format and/or a different kind of filesystem can mean the Nix store or its equivalent doesn't need to be exposed as bare files at all. One Nix hacker has actually proposed doing something like that on top of the Linux kernel, but I think RedoxOS already uses some ideas like this.
dannymi 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. Not really trust. Nix and Guix are not magic. You can still use ldd to figure out what (now exact!) library anything is gonna use. Guix and Nix use the rpath feature. And your profile directory in Guix is a normal directory called $HOME/.guix-profile . Currently, it has "bin" and "share" and "sbin" and "libexec" and "lib" and so on in there. That is what the end user uses. Entries in those do link to /gnu/store/xyz/bin/xyz (using regular symlinks), yes. >Instead of a flat directory tree with hashes, a consistent algorithm that categorises apps and puts them in a tree: One hash represents all the dependencies of that package, too. One directory name in Guix's /gnu/store encodes both the direct sources and all the dependencies, all the way up to a bootstrap root (the latter of about 250 Bytes of binary). If any of the dependencies of bash changes, the hash will change, too. That also means that you will have multiple /gnu/store/*-bash-5.1.16 in there in a normal system. But in your proposed case, you'd have to introduce some magical things which figure out and STORE the dependencies somehow differently in the background. Guix doesn't do that. It stores that in the file system, the end (as in directly in the file system, not as in "the system database blob is in file /foo"). No magical extra store. That said, it would be possible to only change the guix profile layout to be what you suggest, and then still have symlinks to /gnu/store/<hash>-xyz in there. Probably like 5 h of work, and end user programs most likely will work on the first try. Patches welcome. See guix/profiles.scm for what creates the profile. %user-profile-directory is $HOME/.guix-profile . profile-derivation is the function you want to change. You can also use guix on top of whatever other Linux distribution and try it out like that. The package manager (which makes the profiles) also supports containers--so you can safely try out whether your change works.
- lproven 3y ago
  > Not really trust. Nix and Guix are not magic. Did I say they were? I didn't mean to. I've researched Nix. I've written about it. Nix people contacted me to thank me for doing so. https://www.theregister.com/2022/12/13/nixos_2211_raccoon/ https://www.theregister.com/2022/12/13/nixos_2211_raccoon/ https://www.theregister.com/2021/12/03/nixos_linux_os_design/ https://www.theregister.com/2021/12/03/nixos_linux_os_design... The reader comments I get is that a non-human-readable filesytem (or only marginally so, by ignoring the hashes and looking in the new single-level hierarchy for recognisable fragments of names) is just too high. They don't have enough of a problem with how things are to choose a whole new method with this very high price. (Which is the same reason Plan 9 flopped, as I have both written about and spoken publicly at FOSDEM about this month.) https://fosdem.org/2024/schedule/event/fosdem-2024-3095-one-way-forward-finding-a-path-to-what-comes-after-unix/ https://fosdem.org/2024/schedule/event/fosdem-2024-3095-one-... https://www.theregister.com/2024/02/21/successor_to_unix_plan_9/ https://www.theregister.com/2024/02/21/successor_to_unix_pla... > You can still use ldd I submit that this is rocket science to the majority of Linux users and is not a sufficient answer. > And your profile directory in Guix is a normal directory I confess I've not looked at Guix yet. But saying that, I don't think having a normal homedir isolated in a partition full of alien weirdness is enough, TBH. > One hash represents all the dependencies of that package, too. I am not sure that I understand what this means, but is there any reason this could not be combined with my proposal? > That said, it would be possible to only change the guix profile layout to be what you suggest Interesting. Suboptimal but interesting. Would make it a little less intimidating, I suspect. > You can also use guix on top of whatever other Linux distribution Again, as I said, for most of us, it's a very cognitively expensive extra step to solve a problem we simply don't have.
allan-a 3y ago
> 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 This is a nice illustrative example that works well when the only difference between software packages is semantic versions. The reality is that there can be many variants of packages and using something like a hash of package inputs is very practical. Take for example a library called GDAL, which has an insane amount of configure flags. It is quite common for scientific software to be tuned and package maintainers cannot supply a one-size-fits-all solution.
- lproven 3y ago
  OK. For clarity, I am not anti-hash or anything. For instance, we could still embed the hash in the directory name, in much the same way that many Linux programs use build numbers. /gonix/apps/console/editors/vim/9.1~246dea34451dbdda21 The core things that I'm getting at here are: 1. Put the human-readable part first because humans see that first. 2. Retain hierarchical layouts. For humans this makes things more manageable and accessible, while for programs, as long as it's computationally-parseable the impact is negligible. 3. Lean in to the hierarchy. If it's necessary to duplicate slightly different versions of dependencies for different programs, then put them inside that program's hierarchy. That's one of its reasons for existing. 4. Embed the hash anywhere a simple regex can find it, no problem; tab-completion can sort that out. All I am trying to suggest is that a Nix/Guix/successor/replacement type tool could focus more on ordinary joes who find it hard to remember the difference between `/bin` and `/usr/bin` as it is, and make stuff human-readable first and machine-readable second.
  - tgamblin 3y ago
    FWIW this is what Spack does, and it uses a store layout like nix/guix. here are some chunks of the spack install tree path. All you really need is the hash, but we provide a bit more. $ spack find -p ... cmake@3.27.9 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/cmake-3.27.9-x6g5fl54kgt4nqmgnajrtfycivokap2p cmake@3.27.9 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/cmake-3.27.9-x4bznyafesvpdbplqhmnwwvy2zj5fdzs coreutils@9.3 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/coreutils-9.3-vlwyg7d3ysxfoom3erl6ai4yy7fuf2jn curl@8.4.0 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/curl-8.4.0-zjz6twa32vxnevika34kkrxjwo27z6vj curl@8.6.0 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/curl-8.6.0-da5tk7aqaqp6zdligjmahzwohzut65qc diffutils@3.9 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/diffutils-3.9-lau4vo7zlsktmbhyn3pf3x72nxhihsaq double-conversion@3.3.0 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/double-conversion-3.3.0-zihvj7vzedapjprk76awr7qied3k45n6 emacs@29.2 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/emacs-29.2-x5v4wdhp4vfsuxquadackqckdvxrppwi expat@2.5.0 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/expat-2.5.0-hmdysf6hcrzuhcxu7fkecpvskzxecgps findutils@4.9.0 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/findutils-4.9.0-atynmdjhdjpb2ipurlk7cxtdep77m7mu fish@3.6.1 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/fish-3.6.1-sg3ws3rmbfgdfyhvjnhd5agepguj4yf2 flex@2.6.3 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/flex-2.6.3-quw6ammnjxfutqtqcifvjfsp5nyqpeab freetype@2.11.1 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/freetype-2.11.1-ue2ofutkkawtzvcl47pqts4lasm5lgha gawk@5.2.2 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/gawk-5.2.2-jld7vb24rls64nbzkyxcp4alluyedfzv gdbm@1.23 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/gdbm-1.23-amtpuskagocirjhffgqrjas3bfbnzixi ... You can also customize the install tree paths[1] with format strings; the default is: config: install_tree: root: $spack/opt/spack projections: all: "{architecture}/{compiler.name}-{compiler.version}/{name}-{version}-{hash}" One reason `nix` uses `/nix/HASH` is because it results in shorter paths and avoids issues with long paths. We use sbang[2] to avoid the most common one -- that long shebangs don't work on some OS's (notably, most linux distros). [1] https://spack.readthedocs.io/en/latest/config_yaml.html#config-yaml https://spack.readthedocs.io/en/latest/config_yaml.html#conf... [2] https://github.com/spack/sbang https://github.com/spack/sbang

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

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.
- pxc 3y ago
  > 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. This is easy for me to believe :) > you can not rely on [Linux users] grasping advanced concepts such as "search paths" and "links" (of different kinds, no less!) Those are required for understanding how conventional Linux distros work, too, though. So the users who won't understand $PATH on NixOS are also users who don't understand how $PATH works on Ubuntu. I will admit that there's a difference here in that you can have a very half-assed understanding of Ubuntu, and even a half-assed understanding of NixOS probably has a higher skill/knowledge floor. And maybe I've unthinkingly assumed that half-assed understandings are worth less than they really are, at least psychologically. I have a very half-assed understanding of how my car works, but having it not be a complete wonder and mystery to me does give me more confidence in driving the thing— even if most of my knowledge of how it works is too incomplete to be practically useful and I'll always take it to a specialist if it has problems. > You could no more explain [the Nix symlink forest] to the average distro-hopper than you could explain it to a Labrador dog. Maybe the average distro-hopper matters because the average Linux user is a distro-hopper. But I think distro-hoppers are kind of a pathological case here, because distro-hopping is precisely the habit of throwing your hands up, blasting away your whole setup, and clicking Next Next Next instead of learning how your system works. Of course distro-hoppers are going to struggle to understand how their distros work! To distro-hop is to enact a commitment to not understanding your distro!! I also wonder if this is really true, and this is probably the part where I am just naive. But a forest of symlinks would be super easy to diagram perfectly faithfully, and I think a visual aid like that could go a really long way for the average person. > the concept that you don't need to know where files are so long as the OS knows. Have you seen this article, posted to HN to some infamy, about how zoomers don't expect to know/care where their files are, and are in fact somewhat baffled at the very question of where they've saved something? https://www.theverge.com/22684730/students-file-folder-directory-structure-education-gen-z https://www.theverge.com/22684730/students-file-folder-direc... I what that generational gap says for the viability (in terms of user acceptance) of the Nix store in all its ugly glory in the future. I want to be clear that I do think some of your suggestions for laying out the files differently (like Spack apparently does) are perfectly reasonable. There are technical and historical reasons that the store is hash-first, but maybe they're worth re-evaluating. Sometimes I think the real winner, some day, in terms of executing this idea beautifully and in a user-friendly way, will be on a 'brand new' OS where a different executable format and/or a different kind of filesystem can mean the Nix store or its equivalent doesn't need to be exposed as bare files at all. One Nix hacker has actually proposed doing something like that on top of the Linux kernel, but I think RedoxOS already uses some ideas like this.

dannymi 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. Not really trust. Nix and Guix are not magic. You can still use ldd to figure out what (now exact!) library anything is gonna use. Guix and Nix use the rpath feature. And your profile directory in Guix is a normal directory called $HOME/.guix-profile . Currently, it has "bin" and "share" and "sbin" and "libexec" and "lib" and so on in there. That is what the end user uses. Entries in those do link to /gnu/store/xyz/bin/xyz (using regular symlinks), yes. >Instead of a flat directory tree with hashes, a consistent algorithm that categorises apps and puts them in a tree: One hash represents all the dependencies of that package, too. One directory name in Guix's /gnu/store encodes both the direct sources and all the dependencies, all the way up to a bootstrap root (the latter of about 250 Bytes of binary). If any of the dependencies of bash changes, the hash will change, too. That also means that you will have multiple /gnu/store/*-bash-5.1.16 in there in a normal system. But in your proposed case, you'd have to introduce some magical things which figure out and STORE the dependencies somehow differently in the background. Guix doesn't do that. It stores that in the file system, the end (as in directly in the file system, not as in "the system database blob is in file /foo"). No magical extra store. That said, it would be possible to only change the guix profile layout to be what you suggest, and then still have symlinks to /gnu/store/<hash>-xyz in there. Probably like 5 h of work, and end user programs most likely will work on the first try. Patches welcome. See guix/profiles.scm for what creates the profile. %user-profile-directory is $HOME/.guix-profile . profile-derivation is the function you want to change. You can also use guix on top of whatever other Linux distribution and try it out like that. The package manager (which makes the profiles) also supports containers--so you can safely try out whether your change works.

lproven 3y ago
> Not really trust. Nix and Guix are not magic. Did I say they were? I didn't mean to. I've researched Nix. I've written about it. Nix people contacted me to thank me for doing so. https://www.theregister.com/2022/12/13/nixos_2211_raccoon/ https://www.theregister.com/2022/12/13/nixos_2211_raccoon/ https://www.theregister.com/2021/12/03/nixos_linux_os_design/ https://www.theregister.com/2021/12/03/nixos_linux_os_design... The reader comments I get is that a non-human-readable filesytem (or only marginally so, by ignoring the hashes and looking in the new single-level hierarchy for recognisable fragments of names) is just too high. They don't have enough of a problem with how things are to choose a whole new method with this very high price. (Which is the same reason Plan 9 flopped, as I have both written about and spoken publicly at FOSDEM about this month.) https://fosdem.org/2024/schedule/event/fosdem-2024-3095-one-way-forward-finding-a-path-to-what-comes-after-unix/ https://fosdem.org/2024/schedule/event/fosdem-2024-3095-one-... https://www.theregister.com/2024/02/21/successor_to_unix_plan_9/ https://www.theregister.com/2024/02/21/successor_to_unix_pla... > You can still use ldd I submit that this is rocket science to the majority of Linux users and is not a sufficient answer. > And your profile directory in Guix is a normal directory I confess I've not looked at Guix yet. But saying that, I don't think having a normal homedir isolated in a partition full of alien weirdness is enough, TBH. > One hash represents all the dependencies of that package, too. I am not sure that I understand what this means, but is there any reason this could not be combined with my proposal? > That said, it would be possible to only change the guix profile layout to be what you suggest Interesting. Suboptimal but interesting. Would make it a little less intimidating, I suspect. > You can also use guix on top of whatever other Linux distribution Again, as I said, for most of us, it's a very cognitively expensive extra step to solve a problem we simply don't have.

allan-a 3y ago

> 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 This is a nice illustrative example that works well when the only difference between software packages is semantic versions. The reality is that there can be many variants of packages and using something like a hash of package inputs is very practical. Take for example a library called GDAL, which has an insane amount of configure flags. It is quite common for scientific software to be tuned and package maintainers cannot supply a one-size-fits-all solution.

lproven 3y ago
OK. For clarity, I am not anti-hash or anything. For instance, we could still embed the hash in the directory name, in much the same way that many Linux programs use build numbers. /gonix/apps/console/editors/vim/9.1~246dea34451dbdda21 The core things that I'm getting at here are: 1. Put the human-readable part first because humans see that first. 2. Retain hierarchical layouts. For humans this makes things more manageable and accessible, while for programs, as long as it's computationally-parseable the impact is negligible. 3. Lean in to the hierarchy. If it's necessary to duplicate slightly different versions of dependencies for different programs, then put them inside that program's hierarchy. That's one of its reasons for existing. 4. Embed the hash anywhere a simple regex can find it, no problem; tab-completion can sort that out. All I am trying to suggest is that a Nix/Guix/successor/replacement type tool could focus more on ordinary joes who find it hard to remember the difference between `/bin` and `/usr/bin` as it is, and make stuff human-readable first and machine-readable second.
- tgamblin 3y ago
  FWIW this is what Spack does, and it uses a store layout like nix/guix. here are some chunks of the spack install tree path. All you really need is the hash, but we provide a bit more. $ spack find -p ... cmake@3.27.9 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/cmake-3.27.9-x6g5fl54kgt4nqmgnajrtfycivokap2p cmake@3.27.9 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/cmake-3.27.9-x4bznyafesvpdbplqhmnwwvy2zj5fdzs coreutils@9.3 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/coreutils-9.3-vlwyg7d3ysxfoom3erl6ai4yy7fuf2jn curl@8.4.0 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/curl-8.4.0-zjz6twa32vxnevika34kkrxjwo27z6vj curl@8.6.0 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/curl-8.6.0-da5tk7aqaqp6zdligjmahzwohzut65qc diffutils@3.9 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/diffutils-3.9-lau4vo7zlsktmbhyn3pf3x72nxhihsaq double-conversion@3.3.0 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/double-conversion-3.3.0-zihvj7vzedapjprk76awr7qied3k45n6 emacs@29.2 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/emacs-29.2-x5v4wdhp4vfsuxquadackqckdvxrppwi expat@2.5.0 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/expat-2.5.0-hmdysf6hcrzuhcxu7fkecpvskzxecgps findutils@4.9.0 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/findutils-4.9.0-atynmdjhdjpb2ipurlk7cxtdep77m7mu fish@3.6.1 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/fish-3.6.1-sg3ws3rmbfgdfyhvjnhd5agepguj4yf2 flex@2.6.3 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/flex-2.6.3-quw6ammnjxfutqtqcifvjfsp5nyqpeab freetype@2.11.1 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/freetype-2.11.1-ue2ofutkkawtzvcl47pqts4lasm5lgha gawk@5.2.2 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/gawk-5.2.2-jld7vb24rls64nbzkyxcp4alluyedfzv gdbm@1.23 ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/gdbm-1.23-amtpuskagocirjhffgqrjas3bfbnzixi ... You can also customize the install tree paths[1] with format strings; the default is: config: install_tree: root: $spack/opt/spack projections: all: "{architecture}/{compiler.name}-{compiler.version}/{name}-{version}-{hash}" One reason `nix` uses `/nix/HASH` is because it results in shorter paths and avoids issues with long paths. We use sbang[2] to avoid the most common one -- that long shebangs don't work on some OS's (notably, most linux distros). [1] https://spack.readthedocs.io/en/latest/config_yaml.html#config-yaml https://spack.readthedocs.io/en/latest/config_yaml.html#conf... [2] https://github.com/spack/sbang https://github.com/spack/sbang