4 ms·

> 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 a

by 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.

lproven 3y ago
> 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: https://unix.stackexchange.com/questions/742392/can-i-use-btrfs-subvolumes-for-trying-multiple-linux-distributions-without-commi https://unix.stackexchange.com/questions/742392/can-i-use-bt... Or installing Windows on Btrfs: https://www.lilysthings.org/blog/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.
- pxc 3y ago
  > 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.

by pxc 3y ago

lproven 3y ago

> 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: https://unix.stackexchange.com/questions/742392/can-i-use-btrfs-subvolumes-for-trying-multiple-linux-distributions-without-commi https://unix.stackexchange.com/questions/742392/can-i-use-bt... Or installing Windows on Btrfs: https://www.lilysthings.org/blog/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.

pxc 3y ago
> 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.