3 ms·

Nix fork Aux.computer fixes the political but not the technological objections

5 points by lproven 2y ago

deleted 2y ago
[deleted]
aendruk 2y ago
Related: https://forum.aux.computer/t/the-register-article-about-aux/636 https://forum.aux.computer/t/the-register-article-about-aux/...
- lproven 2y ago
  [Article author/submitter here] Thanks for that. I don't really want to join yet another forum -- and I hate web fora, and that includes Discourse -- to reply. Is there any point in replying here? Would anyone relay my comments, or ask people to come and read them?
licebmi__at__ 2y ago
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?

5 points by lproven 2y ago

deleted 2y ago

[deleted]

Related: https://forum.aux.computer/t/the-register-article-about-aux/636 https://forum.aux.computer/t/the-register-article-about-aux/...

lproven 2y ago
[Article author/submitter here] Thanks for that. I don't really want to join yet another forum -- and I hate web fora, and that includes Discourse -- to reply. Is there any point in replying here? Would anyone relay my comments, or ask people to come and read them?

licebmi__at__ 2y ago

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?