> 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!!
Fair point. :-)
> 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 think there's a word, or several, or maybe just a letter or two, missing here.
But yes, I thought of that, too.
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.
The (to me) madness of things like Btrfs volumes, layering another filesystem namespace on top of the Unix one, allowing insanity like multiple distros in one partition:
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.
> 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
Spack supports the notion of arbitrary "views" of the store, which can be defined declaratively [1]. Apparently we need to write more highlight blog posts and submit them here b/c people don't seem to know about this stuff :)
For example, if you want to make a view that included only things that depend on MPI (openmpi, mpich, etc.), but not things built with the PGI compiler, in directories by name, version, and what compiler was used to build, you could write:
That puts all your zlib installs in a short name-version directory, most things in directories named by the package and version and a subdirectory for what compiler it was built with, and for packages that depend on MPI it also adds the MPI implementation (openmpi, mpich, etc.) and its version to that.
You can choose to map everything into a single prefix too:
view:
default:
root: ~/myprefix
That is useful for what we call a "unified" environment where there is only one version of any particular package -- it basically converts a subset of a store into an FHS layout.
There are options for choosing what types of links to use and what types of dependencies to link in, e.g., you could exclude build dependencies if you didn't want the cmake you built with to be linked in.
> Apparently we need to write more highlight blog posts and submit them here b/c people don't seem to know about this stuff
100% you do. I find the term a bit odd, but I've been a "Linux professional" for coming up on 30 years now and I've never even heard of this stuff before.
There is _so much_ in the Linux world that is just badly explained, or not explained, and it's very hard to find cogent explanations. Trying to find them, summarise them, and in some cases, just write them myself is a large part of my job...
And it's a huge field.
One of the reasons some things dominate the headlines is that the creators spend a significant amount of time and effort on outreach. On just talking about what they are doing, why.
That's why there are tonnes of stories about GNOME, KDE, systemd, Flatpak, Snap, Btrfs, ZFS, etc. They talk. They explain.
It's also why there are next to none about Nix, Guix, Spack, and legions of others. They don't.
To pick a trivially small example: Nix talks about being declarative, but it doesn't explain what "declarative" means. And it mentions "purely functional" but it doesn't explain that either. Those things right there are worth about 1000-2000 words of explanation per word. Omit that, and the original message becomes worthless, because it becomes insiders-only.
As it happens through decades of reading about Lisp and things, I more or less get it, but not well, and I struggle to explain it.
> 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.
> these things are pretty far outside what most people who love and contribute to Nix care about.
I suspect you're right. :-(
I have sympathy for the "servers as cattle" approach, but then again, the Linux world is in danger of forgetting where it comes from: from enthusiasts having fun. From people hacking around, learning, exploring, for a laugh, partly because it's free.
And as a vegetarian since my teens, but a sysadmin since my 20s, I have more sympathy for cattle than sysadmins. Sysadmins have choices, and can learn from their forerunners' mistakes. If they don't: tough. Sympathy gone.
I know about GoboHide, yes.
> Have you played with Bedrock Linux at all?
I know of it, but I haven't. I should.
> I have also tried once to install macOS on ZFS, which apparently can be done.
Well, could once. Probably not any more: Apple backed away from ZFS about 15 years ago or so.
It installs and creates filesystems just fine. The only part I haven't successfully tested myself within the last year or two is actually booting from it.
> I have sympathy for the "servers as cattle" approach, but then again, the Linux world is in danger of forgetting where it comes from: from enthusiasts having fun. From people hacking around, learning, exploring, for a laugh, partly because it's free.
One thing I believe deeply is that no one ever really masters the Unix environment without living in it. Without a solid foundation of interactive use, programming with the shell as your REPL, puttering around your filesystem with `cd`, you'll never properly learn your way around. 'Learning Linux' in a 'cloud-native' context tends to mean being alienated from all of that, and I think it profoundly hampers the development of fluency and comfort with the system.
To get that from a box (server or desktop), it has to be a home to you, and homes aren't disposable (the Impermanence framework for NixOS aside).
I do think NixOS has a place there, in keeping computing fun and exciting. For me, it was the first truly interesting distro (at least among those I'd consider usable/practical for me) in a long time. (This was back in 2015 or so.) I was a desktop Linux hobbyist before I took up any devops-related work, and for several years, NixOS singlehandedly breathed new life into that hobby for me. As far as I can tell, this is not an uncommon reaction to NixOS among enthusiasts, if not among casual Linux users.
I knew it was around -- I have written about ZFS several times -- but if it's not in the kernel I didn't think you could boot from it any more, and in recent versions of macOS you can't readily add new kernel extensions any more.
(It is possible, by disabling some of the security settings, but it's very much not trivial.)
> no one ever really masters the Unix environment without living in it.
An interesting take. I can't really argue with that.
> NixOS has a place there, in keeping computing fun and exciting
Fair point. :-)
> 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 think there's a word, or several, or maybe just a letter or two, missing here.
But yes, I thought of that, too.
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.
The (to me) madness of things like Btrfs volumes, layering another filesystem namespace on top of the Unix one, allowing insanity like multiple distros in one partition:
https://unix.stackexchange.com/questions/742392/can-i-use-bt...
Or installing Windows on Btrfs:
https://www.lilysthings.org/blog/windows-on-btrfs/
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.
This isn't over. There's some distance to go yet.