4 ms·

He is. Check out the Q&A of his 2020 ArchConf presentation. He explains why NixOS does not fit Hus needs.

by CameronNemo 6y ago

Ericson2314 6y ago
Buried after a talk, yay.
- Ericson2314 6y ago
  I found https://static.conf.archlinux.org/2020/archconf/talks/distri%3A%20researching%20fast%20Linux%20package%20management/6387_distri.mp4 https://static.conf.archlinux.org/2020/archconf/talks/distri... Let me quote a thing starting at 26:49: > The performance improvements distri provides, definitely some of them can apply to Nix. I think there are some low hanging fruit in Nix. The other isuess do reflect some persistent rhetorical issues we've had with explaining Nix: > There was little differentiation with Nix vs NixOS. (Some of his philosophical difference could be resolved by just using Nix.) > There was no recognition that the "nix language part of Nix" is cleanly layered away from the layers that actually do the work of running jobs and moving files around, and can be replaced like Guix does. So I do want our materials to highlight this so experimenters realize Nix is less of an all-in proposition than it sounds (if one is already willing to do the extra work of blazing their own trail).
  - makebackupstoo 6y ago
    A few blog posts on "how to make your own guix!" would be really neat. I'm not as deep as I'd like to be, but roughly it's a simply a matter of outputting a derivation that `nix-daemon/nix-build` can handle, right?
    - Ericson2314 6y ago
      I do want to add a section to the Nix manual that describes what it is (data model, key abstractions, etc.). Everything today is some variation on "how to use it".
- orhmeh09 6y ago
  What are you mad at? You seemed frustrated he was unaware, and now you find that he was aware, you’re mad that the information on his state of awareness was difficult for you to find? Why does it matter to you? Or are you disappointed that his assessment does not match your opinion of Nix et al.?
  - Ericson2314 6y ago
    I'm relieved he is aware. I'm disappointed that the overhead of trying new things here is higher than I think it needs to be, because making these things from scratch means doing lots of not-innovative between the resesrchy bits. I care because there are very few people who care this much about packaging, and if our efforts were less divided it would go a lot further. I'm a little disappointed by what feels like a superficial take on Nix, but I am quite used to that now. And indeed, our documentation is bad about at explaining the essence of the thing.
makebackupstoo 6y ago
I have yet to see Michael discuss Nix without spreading inaccurate, flatly wrong information about it (Nix does not have post-install hooks, and `nix-env -i` being slow and unrecommended is a known meme that is addressed in upcoming tooling). Nix fulfills every single requirement Michael has put forward (except the squash>tar thing, which I still don't understand). That's all there is to this. I sympathize with Ericson's frustration. It's exhausting watching people re-invent inferior solutions to Nix, instead of just hopping in and fixing or using Nix. Of course, John Ericson is one of the few people motivated, qualified (and maybe has the buy-in) to make changes in Nix. I'm thankful for that on-going work.
- st1ck 6y ago
  fast, but more typing: `nix-env -iA nixos.packageName`
- Ericson2314 6y ago
  > I'm thankful for that on-going work. Thank you!
- rofrol 6y ago
  >`nix-env -i` being slow and unrecommended is a known meme that is addressed in upcoming tooling Can you provide more info on that?
  - Ericson2314 6y ago
    It evaluates the build plan for everything we have, and then searches the things that were evaluated. The new unstable CLI has an evaluation cache at least. What most people do today is look for keys in the object and just evaluate what they need. (The Nix language is lazily evaluated so you can explore like this pretty well out of the box in the repl.) Or, they just grep Nixpkgs :D. ------- All of this, problems and solutions alike, is a weird situation to be in. I still stand by "just get rid of nix-env -i", but I want there to be better solutions too. Nixpkgs seems overly complex, and is in some ways, but the fact its trying to herd a gazillion upstream packages that don't meaningfully coordinate makes this harder to fix than it should be.

He is. Check out the Q&A of his 2020 ArchConf presentation. He explains why NixOS does not fit Hus needs.

Ericson2314 6y ago

Buried after a talk, yay.

Ericson2314 6y ago
I found https://static.conf.archlinux.org/2020/archconf/talks/distri%3A%20researching%20fast%20Linux%20package%20management/6387_distri.mp4 https://static.conf.archlinux.org/2020/archconf/talks/distri... Let me quote a thing starting at 26:49: > The performance improvements distri provides, definitely some of them can apply to Nix. I think there are some low hanging fruit in Nix. The other isuess do reflect some persistent rhetorical issues we've had with explaining Nix: > There was little differentiation with Nix vs NixOS. (Some of his philosophical difference could be resolved by just using Nix.) > There was no recognition that the "nix language part of Nix" is cleanly layered away from the layers that actually do the work of running jobs and moving files around, and can be replaced like Guix does. So I do want our materials to highlight this so experimenters realize Nix is less of an all-in proposition than it sounds (if one is already willing to do the extra work of blazing their own trail).
- makebackupstoo 6y ago
  A few blog posts on "how to make your own guix!" would be really neat. I'm not as deep as I'd like to be, but roughly it's a simply a matter of outputting a derivation that `nix-daemon/nix-build` can handle, right?
  - Ericson2314 6y ago
    I do want to add a section to the Nix manual that describes what it is (data model, key abstractions, etc.). Everything today is some variation on "how to use it".
orhmeh09 6y ago
What are you mad at? You seemed frustrated he was unaware, and now you find that he was aware, you’re mad that the information on his state of awareness was difficult for you to find? Why does it matter to you? Or are you disappointed that his assessment does not match your opinion of Nix et al.?
- Ericson2314 6y ago
  I'm relieved he is aware. I'm disappointed that the overhead of trying new things here is higher than I think it needs to be, because making these things from scratch means doing lots of not-innovative between the resesrchy bits. I care because there are very few people who care this much about packaging, and if our efforts were less divided it would go a lot further. I'm a little disappointed by what feels like a superficial take on Nix, but I am quite used to that now. And indeed, our documentation is bad about at explaining the essence of the thing.

makebackupstoo 6y ago

I have yet to see Michael discuss Nix without spreading inaccurate, flatly wrong information about it (Nix does not have post-install hooks, and `nix-env -i` being slow and unrecommended is a known meme that is addressed in upcoming tooling). Nix fulfills every single requirement Michael has put forward (except the squash>tar thing, which I still don't understand). That's all there is to this. I sympathize with Ericson's frustration. It's exhausting watching people re-invent inferior solutions to Nix, instead of just hopping in and fixing or using Nix. Of course, John Ericson is one of the few people motivated, qualified (and maybe has the buy-in) to make changes in Nix. I'm thankful for that on-going work.

st1ck 6y ago
fast, but more typing: `nix-env -iA nixos.packageName`
Ericson2314 6y ago
> I'm thankful for that on-going work. Thank you!
rofrol 6y ago
>`nix-env -i` being slow and unrecommended is a known meme that is addressed in upcoming tooling Can you provide more info on that?
- Ericson2314 6y ago
  It evaluates the build plan for everything we have, and then searches the things that were evaluated. The new unstable CLI has an evaluation cache at least. What most people do today is look for keys in the object and just evaluate what they need. (The Nix language is lazily evaluated so you can explore like this pretty well out of the box in the repl.) Or, they just grep Nixpkgs :D. ------- All of this, problems and solutions alike, is a weird situation to be in. I still stand by "just get rid of nix-env -i", but I want there to be better solutions too. Nixpkgs seems overly complex, and is in some ways, but the fact its trying to herd a gazillion upstream packages that don't meaningfully coordinate makes this harder to fix than it should be.