> I think there's a word, or several, or maybe just a letter or two, missing here.
Oops, I certainly did accidentally a whole word there ;)
> What irks me a little is that the Nix folks I've spoken to seem to feel that they have simply fixed this issue now, and nothing more need be done. While in fact I think there is a lot more work to be done here, and maybe GoboLinux and Spack and things show the way.
I think you're probably right. I'm sure there are others in the Nix community who agree, but presenting a facsimile of a normal filesystem, or reversing the decision about the order in which to put hashes and the human-readable part of filenames (which has compatibility and performance implications that others will fight against it for), these things are pretty far outside what most people who love and contribute to Nix care about. And I don't mean that to say that Nix contributors are aloof, but to emphasize that the people on the Nix core team and other contributors to the ecosystem all have long laundry lists of features that solve problems that are deeply interesting to them or professional vital for them/their company. And those laundry lists don't include backwards-incompatible, far-reaching changes for the sake of what it feels like for newbies and casual users to look at the filesystem on NixOS for the first time.
I kinda suspect that if this changes in the Nix world it will be because Spack's approach becomes popular and widely praised for a long time, so that there is a long period in which the change is seen as an obvious choice despite it seeming like a 'minor' issue to technical stakeholders. But I can picture it happening.
> Hints at other approaches. As in: why not both? Maybe it's possible to have multiple _views_ of a filesystem, so via one API you "see" a flat namespace with hashed directories, and with another a conventional hierarchical one -- just as a Gmail account can be viewed as flat and hierarchical at the same time using an IMAP client.
GoboLinux does have a mechanism like this, IIRC, called 'GoboHide'. So if you run ./configure && make && make install on GoboLinux, autoconf and automake or whatever will find a /usr/lib, and if you run ls against that dir, it will succeed. But you won't see it with `ls /`. NixOS could add this kind of feature, but I'm store paths will still leak out in the settings screens of applications and the outputs of various commands, so it's not quite what we're looking for. That latter problem seems impossible to fix without patching applications, because hard coding store paths in them is an important part of how Nix works. That suggests to me that maybe the Spack way is better— at least then leakage of store paths isn't as shocking to users.
> madness of things like Btrfs volumes, layering another filesystem namespace on top of the Unix one, allowing insanity like multiple distros in one partition
Have you played with Bedrock Linux at all? That might be a fun one. That distro layers other distros together into a single functional whole. So in addition to living on a single partition, you also might have X11 from one distro, systemd from another, and command line utilities from a smattering of 3 others, all running as one system!
> Or installing Windows on Btrfs
I have also tried once to install macOS on ZFS, which apparently can be done. I might try again soon, since I have real Apple hardware to do it on. Last time I tried that on a Hackintosh but quickly ran up against my lack of macOS knowledge.