this post was submitted on 18 Oct 2023
17 points (100.0% liked)
nixos
1245 readers
1 users here now
All about NixOS - https://nixos.org/
founded 4 years ago
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
after spending +3 years getting experienced and reading a lot of the source code (getting past the documentation/learning-curve problem), I can say there are at least two fundamental flaws, with nixpkgs moreso than nixos:
(Edit: Added 0)
The culture issue. See thread below
The messy mono-repo was never desgined to be searchable. It might feel searchable to a newby, but many teams have dumped tons of effort and slapped together lots of hacks to make niche-package-versions even halfway searchable. Devbox is doing a good job of fixing this, but its not there yet.
The monorepo design is unmaintainable/unscalable from a package maintainer standpoint. There's a ton of contributor burnout, there's no automated quality control on packages, to outsiders its not obvious how to report package-specific issues or how to edit/fix/contribute to a single package, and instead of 30min to publish a hello-world npm or cargo package, users need to make a PR on the core, and get it approved. Meaning publishing a hello-world package would get rejected anyways. The good news is flakes hub is fixing this, and I'm really excited for that.
The good is;
I'm not sure what you mean by "searchable"?
https://search.nixos.org/packages exists and it's generally pretty damn good.
There is contributor burnout and perhaps some quality issues here and there but the monorepo isn't the reason for that. In fact, it'd be a lot worse if we had hundreds of smaller repos instead as wide-reaching changes would become basically impossible with our current manpower.
There have been calls to fragment Nixpkgs for years but they've almost always been struck down because none of what was suggested would improve anything about our current maintenance issues.
You simply open an issue on GitHub. I don't know how it could be any more clear.
I just checked and we don't explicitly document this in CONTRIBUTING.md but I don't think we should need to. It's just too obvious IMO.
https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#how-to-create-pull-requests
FlakeHub fixes none of the maintenance issues of Nixpkgs.
You actually bring up a very good point that I missed; another problem, maybe the largest problem with nix, is the culture issue.
A comment like "what do you mean nixOS doesn't have good documentation??? we have tons of good documentation!" feels very similar to reading what you just said about "You could simply open an issue on Github, I dont know how it could be clearer". Neither of those are a question. They're not asking "how can we do better? (I'm sorry you, as a new user, had a hard time)". Those comments are statements, and they say "you [person struggling to report a package-specific issue] are the problem; our system doesn't need to change. YOU need to change".
This culture issue has real consequences. It's the reason Determinate Systems has a separately maintained nixpkgs-installer script, and separately maintained documentation. Its the reason I also have my own independently maintained nixpkg-installer and nixpkg-uninstaller script. _
Maybe you haven't had our problem because you're really skilled and familiar with nix/github/whatever. Maybe you haven't run into our problem because your use-case doesn't overlap with ours. I am glad you don't run into the problem. But that doesn't somehow make the problem not-a-problem.
Adopt a legacy codebase that is massive and requires EXACTLY ruby
2.6.0-rc1. On ubuntu, using rbenv, it takes a newby 30 sec to list all the available versions, and 30 sec to install ruby2.6.0-rc1.Try finding that version on search.nixos.org.
Even excluding versions, try searching for the extremely-commonly-needed "Core Foundation" package on search.nixos.org. I assure you the package does exist on nixpkgs, I've been using it for years. As a newby had to spend WEEKS looking through the source code and learning nix-lang quirks just to find it.
_
But more importantly please ignore those details and look at the bigger picture; we are on the same team. I'm not insulting or ignoring the massive accomplishments nix team has made. They (maybe you as well) are giants that have moved moutains and accomplished things I wouldve considered basically impossible. I want to help the core devs have LESS work. I want to have productive discussions about the trade-offs of federated vs monorepo, searchability, documentation improvements, installer scripts, etc.
But we can't.
Not until the discussion starts with "I agree there's a problem" instead of "there is no problem other than YOUR lack of skill"
Yup, figuring out how to install gcc 10 was a pain. Turns out I needed stdenvgcc10, but how would I have known that without reading like the entirety of nix pills? I don't want to read a manual for 2 hours to figure out how to do something basic. Not to mention nix pills is SO dense that as someone who can't learn from textbooks, its impossible.