3 ms·

The writer of the article doesn’t seem to understand how nix works, which in some way is even more convoluted that “trusting the PATH” as he portrays it, but it

The writer of the article doesn’t seem to understand how nix works, which in some way is even more convoluted that “trusting the PATH” as he portrays it, but it works so good that once you get it, it totally makes you think you were “doing it wrong” as he quotes flox’s CTO. Thus no, aux doesn’t try to fix the nix store path, as it’s not understood to be broken. I’m just a participant on the project as much as the rest of my life allows it, but as I understand the goal of aux is to change the governance structure, and how it maps to projects like nixpkgs with its huge state and nixos modules.

lproven 2y ago
> The writer of the article doesn’t seem to understand how nix works I am the writer and the submitter too. I have written about Nix before, and received thanks and praise for my articles from the Nix community. Examples: https://www.theregister.com/2022/12/13/nixos_2211_raccoon/ https://www.theregister.com/2022/12/13/nixos_2211_raccoon/ https://www.theregister.com/2024/03/23/flox_1_nix/ https://www.theregister.com/2024/03/23/flox_1_nix/ https://www.theregister.com/2021/12/03/nixos_linux_os_design/ https://www.theregister.com/2021/12/03/nixos_linux_os_design... I think that I do more or less understand it, at the trivial level of what it's for and what it does and how it achieves it. For those reading, as in that thread on Discourse and indeed here, to fail to appreciate that means that you've not understood the point of my article. Nix achieves its goals. I am not disputing that. I am saying that the cost of that is just too high. That cost is losing a filesystem layout that to ordinary humans is readable, makes sense, is navigable, and most of all, is maintainable and can be modified, used, changed, and updated, by hand if Nix fails in some unforeseen way. This, though, is fixable. That would give the fork a goal and a chance. Without that, I don't think it has one.
- jljljl 2y ago
  I think this is a good point -- The ideal state is probably something that is immutable where you need it, and mutable where you may need to make frequent changes. Making small tweaks to your configuration should be easier than needing to write and re-evaluate Nix expressions. We took a similar approach with our product (Devbox): Immutable package store (powered by Nix) to guarantee correctness, coupled with mutable project state. Here's a post where we explain our thinking: https://www.jetify.com/blog/do-repeat-yourself-global-packages-considered-harmful/ https://www.jetify.com/blog/do-repeat-yourself-global-packag...
  - srid 2y ago
    I read that blog post, and came off not quite understanding how it is a similar approach. Specifically where it says, > Devbox installs packages globally in the immutable Nix store and creates a local virtual environment based on your project devbox.json config Is this "local virtue environment" different to a nix develop shell (which uses, for instance, $PATH environment pointing to nix store paths)? If so, in what ways?
  - licebmi__at__ 2y ago
    I get the point of in-mutability, I keep this kind of hybrid environment where I abuse the different include systems of software to keep mutable files that can be easily changed. I guess the different module systems could make it easier, but I still fail to see what this has to do with the nix store, or more so, with the names of the paths in the nix store, everything there is the inmutable part. Some times, and I guess a lot of times since I use home-manager, I do want my configs to be inmutable, at least the permanent part that is shared between my devices.
- licebmi__at__ 2y ago
  Good to be proven wrong. And yeah, as you say I fail to understand your article. I mean, most of the stuff is exactly where you expect it to be even if it’s actually a link to the store, nix store doesn’t supersedes the whole filesystem. I can accept that there’s loss of information, I guess it might matter sometimes if a binary is in “/bin” or in “/sbin” but so far I don’t see how the regular filesystem structure or even gobo’s would help, to fix your software, at least if you want to keep immutability, which is a another can of worms. And even then, if you hack something depending on these paths, IMO you are back to the “doing it wrong” part. Am I missing something here?
  - lproven 2y ago
    > And yeah, as you say I fail to understand your article. Please do explain, then. I always try to be as clear as I can, time and deadlines permitting. > I mean, most of the stuff is exactly where you expect it to be even if it’s actually a link to the store What does that mean? > nix store doesn’t supersedes the whole filesystem. It absolutely does on NixOS, which is all I have looked at. I have absolutely no need of Nix on top of any other distro; indeed, I can't even imagine what I'd use it for. I suggest reading the comments on the article, which it seems to me are strongly in agreement with my points. (Believe me, this is not a general rule: they very often aren't!) Nix solves a problem I personally do not have, which is why I don't use the tool or the distro. Since the docs and the fora and indeed entire products such as Flox assume everyone has the problem, they don't spell out what it is and why fixing it matters. > so far I don’t see how the regular filesystem structure or even gobo’s would help That is a mind-boggling comment to read. Unix is a ~50 year old OS, with millions of users. Its filesystem is at the core of the OS design and its layout is known to millions of people. If a project comes along and throws it out, it has to have an exceptionally good reason. Nix does not. Gobo does. Gobo says "Mac OS X does this better. We aim to equal and exceed what NeXT did." And it does, in its own terms: it... 1. Replaces the Unix filesystem hierarchy with a new one that is cleaner and more readable. 2. But crucially, it is not only more human-readable, it also gives better isolation. 3. It also allows radically simpler packaging tools. 4. And it bestows the ability to have multiple concurrent versions of entire software subsystems. Nix delivers only points 2 & 4. It reduces #1 and it does the reverse of #3. In other words: it gives isolation and the concurrent versions, but it does so via more complex packaging tools that need users to learn a whole new programming language, and it eliminates the familiar FHS and replaces it with a new flat programmatically-defined one that is almost unreadable to humans.

lproven 2y ago

> The writer of the article doesn’t seem to understand how nix works I am the writer and the submitter too. I have written about Nix before, and received thanks and praise for my articles from the Nix community. Examples: https://www.theregister.com/2022/12/13/nixos_2211_raccoon/ https://www.theregister.com/2022/12/13/nixos_2211_raccoon/ https://www.theregister.com/2024/03/23/flox_1_nix/ https://www.theregister.com/2024/03/23/flox_1_nix/ https://www.theregister.com/2021/12/03/nixos_linux_os_design/ https://www.theregister.com/2021/12/03/nixos_linux_os_design... I think that I do more or less understand it, at the trivial level of what it's for and what it does and how it achieves it. For those reading, as in that thread on Discourse and indeed here, to fail to appreciate that means that you've not understood the point of my article. Nix achieves its goals. I am not disputing that. I am saying that the cost of that is just too high. That cost is losing a filesystem layout that to ordinary humans is readable, makes sense, is navigable, and most of all, is maintainable and can be modified, used, changed, and updated, by hand if Nix fails in some unforeseen way. This, though, is fixable. That would give the fork a goal and a chance. Without that, I don't think it has one.

jljljl 2y ago
I think this is a good point -- The ideal state is probably something that is immutable where you need it, and mutable where you may need to make frequent changes. Making small tweaks to your configuration should be easier than needing to write and re-evaluate Nix expressions. We took a similar approach with our product (Devbox): Immutable package store (powered by Nix) to guarantee correctness, coupled with mutable project state. Here's a post where we explain our thinking: https://www.jetify.com/blog/do-repeat-yourself-global-packages-considered-harmful/ https://www.jetify.com/blog/do-repeat-yourself-global-packag...
- srid 2y ago
  I read that blog post, and came off not quite understanding how it is a similar approach. Specifically where it says, > Devbox installs packages globally in the immutable Nix store and creates a local virtual environment based on your project devbox.json config Is this "local virtue environment" different to a nix develop shell (which uses, for instance, $PATH environment pointing to nix store paths)? If so, in what ways?
- licebmi__at__ 2y ago
  I get the point of in-mutability, I keep this kind of hybrid environment where I abuse the different include systems of software to keep mutable files that can be easily changed. I guess the different module systems could make it easier, but I still fail to see what this has to do with the nix store, or more so, with the names of the paths in the nix store, everything there is the inmutable part. Some times, and I guess a lot of times since I use home-manager, I do want my configs to be inmutable, at least the permanent part that is shared between my devices.
licebmi__at__ 2y ago
Good to be proven wrong. And yeah, as you say I fail to understand your article. I mean, most of the stuff is exactly where you expect it to be even if it’s actually a link to the store, nix store doesn’t supersedes the whole filesystem. I can accept that there’s loss of information, I guess it might matter sometimes if a binary is in “/bin” or in “/sbin” but so far I don’t see how the regular filesystem structure or even gobo’s would help, to fix your software, at least if you want to keep immutability, which is a another can of worms. And even then, if you hack something depending on these paths, IMO you are back to the “doing it wrong” part. Am I missing something here?
- lproven 2y ago
  > And yeah, as you say I fail to understand your article. Please do explain, then. I always try to be as clear as I can, time and deadlines permitting. > I mean, most of the stuff is exactly where you expect it to be even if it’s actually a link to the store What does that mean? > nix store doesn’t supersedes the whole filesystem. It absolutely does on NixOS, which is all I have looked at. I have absolutely no need of Nix on top of any other distro; indeed, I can't even imagine what I'd use it for. I suggest reading the comments on the article, which it seems to me are strongly in agreement with my points. (Believe me, this is not a general rule: they very often aren't!) Nix solves a problem I personally do not have, which is why I don't use the tool or the distro. Since the docs and the fora and indeed entire products such as Flox assume everyone has the problem, they don't spell out what it is and why fixing it matters. > so far I don’t see how the regular filesystem structure or even gobo’s would help That is a mind-boggling comment to read. Unix is a ~50 year old OS, with millions of users. Its filesystem is at the core of the OS design and its layout is known to millions of people. If a project comes along and throws it out, it has to have an exceptionally good reason. Nix does not. Gobo does. Gobo says "Mac OS X does this better. We aim to equal and exceed what NeXT did." And it does, in its own terms: it... 1. Replaces the Unix filesystem hierarchy with a new one that is cleaner and more readable. 2. But crucially, it is not only more human-readable, it also gives better isolation. 3. It also allows radically simpler packaging tools. 4. And it bestows the ability to have multiple concurrent versions of entire software subsystems. Nix delivers only points 2 & 4. It reduces #1 and it does the reverse of #3. In other words: it gives isolation and the concurrent versions, but it does so via more complex packaging tools that need users to learn a whole new programming language, and it eliminates the familiar FHS and replaces it with a new flat programmatically-defined one that is almost unreadable to humans.