It seems like he is not aware of Nix or Guix, which is a travesty.
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).
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.
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.
Can you provide more info on that?
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.
$ time nix-env -qa > nixdb.txt
________________________________________________________
Executed in 470.40 secs fish external
usr time 25.11 secs 35.00 millis 25.07 secs
sys time 10.05 secs 27.00 millis 10.02 secs
$ ls -s nixdb.txt
736 nixdb.txt
Sure, Nix or Nixpkgs could have such (or a better) database native, but I don't see problem with above. Maybe someone cares to explain?
Thank you!
Here's the thing, Nix is to slow (even ignoring `nix-env`'s terrible search functionality which should just be removed). What that requires is some good old boring profiling and optimization work. If he were to contribute that to a distro/package manager that basically shares his vision, this would be much more useful to the world.
Cause, at the end of the day, the work isn't so much maintaining the package manager as maintaining the packages. That's simply too much work for anyone to do alone.
http://blog.williammanley.net/2020/05/25/unlock-software-fre... is good piece on why the ultimate issues with packaging are social, not technological. At this point, when the vast majority of devs don't seem to act as if there is a commons that even needs integration, I don't think any 1-person technological solution is going to be so good as to upend the social situation.
It's true that the commons needs people willing to put in time and effort on boring things, but they have to be boring in the first place. If the author were to show up and say "Hey, Nix, if you rearchitect in this massive way it may or may not bring big improvements" and sent in a pull request, it would be rightly rejected. But it's still possible that a few days of rearchitecture can deliver the same results as a year of profiling and microoptimizations. The point of distri, as I understand it, is to have something to point to and say, this architectural change will actually work, and it's worth implementing in an actually-used distro.
I agree with this great summary! I’m glad I got my points across :)
Thanks!
The author has a history of delivering quality OSS projects: i3, Debian Code Search, RobustIRC, gokrazy.