I’ve been on a team where two co-chair leads bickered and eventually split. I was a member in both of the new teams (two projects) and both turned out great for different reasons.

I plan to do the same with Nix and Aux even if everyone else picks sides. And I’m glad the link was posted here.

Agreed, it must take after its parent haha

Absolutely, I didn’t mean my comment as excuse or justification. I personally don’t want any sponsored people on the board. Defense contractor or otherwise.

I’m still trying to disentangle the “stirring up drama” part though.

I don’t know what AstroTurf means. Jon might be in the wrong, and I’ll edit my comment to put bad stuff at the top once I’m caught up. I’m just giving the info I have. If you have some let me know.

If AstroTurf means a bot, check my history here and on Github (jeff-hykin)

Edit: turns out this story goes way beyond Jon, all of Nix is in flux right now. My personal experience is kind of irrelevant.

Edit edit: just read this: https://discourse.nixos.org/t/nixos-foundation-board-giving-power-to-the-community/44552

Original Post:

As a first-hand account; Jon has been the nicest of all the maintainers I’ve had interactions with ( ~7), probably followed by Ryan Mulligan. The only reason I remember Jon’s name (I usually just recognize maintainers by their profile pictures) is because a couple years ago, as part of this thread I was reading this github issue with a really rude/attacking user. I remember reading Jon’s response and thinking “This is one of the most patient FOSS devs on all of Github”.

However, take ^that as-is, because I am not up to date on anything recent. I just wanted to provide the small bit of insight I do have.

Here’s some of my interactions for those who like to judge for themselves:

• https://discourse.nixos.org/t/update-nix-to-unstable/9550/5?u=jeff-hykin
• https://discourse.nixos.org/t/nixpkgss-current-development-workflow-is-not-sustainable/18741/20
• https://discourse.nixos.org/t/clarification-on-package-names-and-versions/9819/4?u=jeff-hykin

Might not look like it, but they’re clipped in.

So you’d roll off the ledge, crack your head against the rock face and then bleed out, NOT fall to your death 👌.

I know climbers who would absolutely do this and tell no one. Adrenaline is its own reward.

That’s good to see a lot of the statistics are close, and I appreciate the sources.

That said, for a full picture, I think you should mention that the average 20 year old doesn’t have 18 gunshot wounds (365 wounds per 400 per year, is about 9.1 wounds per person per decade, or 18.2 wounds per 20 years per person)

So I’d appreciate if you include a bullet point about that.

• “at least 1 out of 400 shot everyday”
• 365 shots per 400 people per year
• or 9.1 shots per 1 person per decade

The AVERAGE American has over 9 gunshot wounds? Man things are getting bad in the US.

Note: The other statistics seem to mostly check out (see another guy’s comment about that), which is great. It’s just weird the gun one is so astronomically inaccurate.

deleted by creator

Yep, most things with nix require this level of elbow grease to get done. Chkno did a great job explaining it. Honestly his response is worth putting in the docs IMO

A huge time saver/helper can be searching the nix discourse. But don’t be afraid to ask. You might get grumpy answers but Nix is hard so dont feel bad about it.

The expected approach is to go to the nixpkgs github and post an issue. The issue will ask you to tag the maintainers, which requires looking them up using search.nixos.org or by using the nix repl (nixpkgs.yourThing.meta.maintainers).

If you want to update it yourself, you can usually use the nix repl to find out where the relevent code is with builtins.unsafeGetAttrPos "yourThing" nixpkgs. Once you know where it is you can fork the nixpkgs github and change it. You can then use/test your fork directly with any of the normal nix commands. For nix-env i blelieve its nix-env -iA something -I url_to_your_github_fork_as_a_tar_file. There’s another flag for using the local folder (instead of a url to a tarball) but I forget what it is.

Oh cool! I didn’t know about that. Maybe I can work eith the other person who is doing that.

If many people report a problem, the correct response is never “no, you’re wrong, that’s not a problem”. There’s no technical aspect to it, that is just common dececency when talking to another human.

That’s the culture issue with Nix.

It doesn’t mean an issue will never be “wont-fix” or that a issue won’t genuinely be a skill-issue. It means it’s not hard to say “I’m sorry, I disagree with adding support for that feature” or “here’s a tutorial for [skill issue]” instead of saying “no, you’re wrong, what you reported is not a problem”. When you mention editing the CONTRIBUTING.md you’re not offering help, you’re just setting up a punchline for an “[but even that wouldn’t help this IDIOT]”. There’s no sincerity, no sympathy or attempt to understand.

I don’t know how to explain it any more clearly… you’re not convincing anyone to help you on those “big issues” with words like “you really should have discovered the issues tab”.

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 ruby 2.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”

Agreed, flakes are the way. Its just making them searchable hasn’t been easy/realistic until recently.

Also I feel like flakes are kind of tainted by always pulling in nixpkgs as a massive dependency chain. I think there should be a standard library separate from the packages, and nixpkgs.lib is 80% pure functions. So I’ve been working on making a “lib” flake that

1. Is 100% pure (no stdenv)
2. is versioned
3. doesnt link/depend on all of nixpkgs

I know it still won’t be practical to avoid depending on nixpkgs, but I think its a step towards breaking up nixpkg into organized/managable chunks.

I worry some about devbox being closed source with their package indexing soltuion. I talked with them on a video call and they seem like great guys. And they said they’d pull the indexing part out of their private repo and make it open source so I could help work on it. They openly talked about their design and have blog posts about it too. But that was 2 maybe 3 months ago and I still haven’t heard back. I should maybe ping them. The real downside is they’ve got an unusual amount of “lock in”. Devbox is not a tool that enhances nix, its just a tool that uses nix under the hood. However they do solve the ease-of-use problem which is a really big deal (they make some tradeoffs though).

Flakes hub, by Determinate Systems, I have absolutely 0 concern about. They’re truely just enhancing nix, and even if they dissapeared the packages already on flakeshub would still effectively work because they’re distrubuted. Flakeshub is just a registry for standarized searching of flakes by individual people. Publishing is built on top of github actions which I’m not the biggest fan of. But there are ways of running github actions locally.

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)

0. The culture issue. See thread below

1. 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.

2. 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;

• The pros still outweigh the cons. My projects from 3 years ago that I haven’t touched still work (0 bitrot) first try, no manual install/setup needed.
• people have put a ton of effort into nix. Its truely amazing how many things work in nix despite how absurdly difficult it is to get things working with nix
• it is pretty much as reproducable as it can be and nothing else is even remotely close.