I’ve been curious about NixOS for quite some time. Reading about it I couldn’t see how the config sharing capabilities, setup, or rollabck would be better than Arch and sharing the list of installed packages, using downgrade or chroot.

So I decided to run NixOS in a VM and I’m still confused. An advantage I can see for NixOS is its better use of cores and parallel processing for packages install.

It’s clear that I’m missing something so please help me understand what it is.

Edit: Thank you to everyone in this great community! It’s always so nice to have a constructive and sane discussion.
After reading so many comments, they all confirm what I’ve read before and I may realize that my real problem is already having a stable system and no need for the great NixOS options that are very neat but would not benefit my specific and simplistic needs. That being said I can’t refrain myself from being curious and will continue testing NixOS.

The need for only 2 config files is the top of the iceberg but hiding more complex configuration to rely on. Not that I really have too much spare time but I do enjoy learning and tweaking NixOS. With its current development state, things are changing a lot so it can keep me busy for months. That’s probably what I was mostly looking for: another toy to play with.

Along my journey I will learn a lot about NixOS and may find a feature that will motivate my switch to it. Thanks again for all your precious feedback!

I’ll also take this opportunity to share the best help I’ve found so far to start with NixOS: https://github.com/MatthiasBenaets/nixos-config And his 3 hours (!) video: https://m.youtube.com/watch?v=AGVXJ-TIv3Y

  • @onlinepersona
    link
    English
    0
    edit-2
    6 months ago

    We have a rather severe shortage of reviewer time.

    That’s probably true, but the number of reviewers is very limited as well. Most people in the nixos org have no merge rights. Someone who creates package ABC and has it merged, is not able to merge changes onto package ABC without the stamp of approval from one of the few people with merge rights --> a small, select group of people are saddled with the final decision.

    The community could do with more people with merge rights or something like The Collective Code Construction Contract (C4).

    Nitpicks can be annoying but the people do it because they actually do care; quite a lot.

    Most of the nitpicks could be resolved by a linter and auto-formatter. It’s also quite annoying when a review is just a bunch of character modifications, renames, replacement of entire sections with no comment whatsoever. Or when knowledge is implied. “use mkDerivation (final: ...)” or “use path instead of ./.” like… OK, what does that even mean? Why isn’t mkDerivation {} or ./. OK and if there is a new standard/convention, why isn’t it mentioned somewhere that’s hard to miss like the the PR template, or linter or build output? Having it on nix.dev as a suggestion, is not the way to do it.

    What’s even worse is when you get one review like the above, change it, then get another review that again changes something according to undocumented convention, you change it, and another reviewer comes along with yet another such review. I don’t contribute to nixpkgs anymore, in part, for that reason.

    It… is?

    https://nixos.org/manual/nixos/stable/options

    The options and lib do it, but why not the rest? What about stdenv? What about fetchers? build-support?

    very top heavy decision making process harms the community.

    What kind of decisions are we talking about?

    How easy or hard is it to get a repo in the nix-community org? Who is allowed to make large changes to nixpkgs e.g review process, CI/CD, package naming, etc? There have been discussions in the community forum about adding linters and nix-fmt but no big-wig ever gave it the go-ahead, so it never happened.

    How was the official wiki nixxed anyway? Was that an RFC?

    The RFC process is the exact opposite of “top heavy”.

    When RFCs can simply be closed as “won’t resolve” or whatever the euphemism is for “no, not on my watch” without community consensus, then I’m not sure what else to call it.

    Though if I’m honest, a fresh contributor should rather get more of a feel for the processes and conventions for a bit before trying to implement a “great change” (as in: size and complexity) anyways

    I agree. Large and complex changes from newbies are difficult to integrate. But there are QOL changes from newcomers I’ve seen that (again) were just stalled or nitpicked to death. There have also been packages requested by a few people, a PR from a newcomer attached and it just never crossing the finish line. A reviewer left a comment, the PR creator made a change and asked if it was fine now, only to hear crickets.

    These difficulties just make me want to fork nixos.

    That won’t help anyone.

    I disagree. If the OG nix community won’t change (or won’t do it quickly enough), then that’s the beauty of opensource: the project can be forked.

    A great example of the tar-like movement of the OG nix community (or the maintainers? dunno) is the wiki. A member finally had enough and just started another one (https://nixlang.wiki/), which IMO already looks and feels much better than unofficial yet officially linked to nixos.wiki. That wiki seems to have come from the official wiki being killed, but then a need for a wiki arising and a nix community member taking it upon themselves to create it as the (for lack of better term) nix top dogs for whatever reason didn’t recreate it.

    I have sympathy for the long-time contributors (maintainers? although that seems to have another connotation in the nix community) to nix, nixpkgs, nixos, etc. There are a lot of moving parts, input, feedback, opinions, PRs, issues, and whatnot, but as a newcomer, there seems to be a resistance to change or at least an inability to take advantage of the good will and energy of the community.

    CC BY-NC-SA 4.0

    • Atemu
      link
      fedilink
      16 months ago

      The community could do with more people with merge rights or something like The Collective Code Construction Contract (C4).

      That is nicely written but we have mostly already implemented that. There’s some critical things like

      A new Contributor who makes a correct patch SHALL be invited to become a Maintainer.

      which we will not implement as commit access to Nixpkgs is security-critical. Anyone with commit access can push malware to thousands of users. We’re doing good here not handing that out to anyone who contributes a patch.

      Most of the nitpicks could be resolved by a linter and auto-formatter.

      https://github.com/NixOS/rfcs/pull/166

      It’s also quite annoying when a review is just a bunch of character modifications, renames, replacement of entire sections with no comment whatsoever. Or when knowledge is implied.

      As a reviewer, you cannot know the reviewee’s experience level. Simply ask and/or Google if you don’t know something. We don’t explain every little thing in detail that we comment on every 5 PRs. Nobody has time for that.

      Why isn’t mkDerivation {} or ./. OK

      I don’t know the context of the latter but the former is absolutely okay. It’s just a matter of taste really and reviewers are free to express theirs.

      Having it on nix.dev as a suggestion, is not the way to do it.

      Why? That’s official docs.

      What’s even worse is when you get one review like the above, change it, then get another review that again changes something according to undocumented convention, you change it, and another reviewer comes along with yet another such review. I don’t contribute to nixpkgs anymore, in part, for that reason.

      That happens sometimes. I’m guilty of that too to a degree. If all you receive are such nitpicks, it’s a good sign that the other aspects of your PR are good to go.

      Also note that this isn’t uniform among committers. Most don’t care about nits very much unless you’re doing something clearly out of the ordinary.

      Two of the most notorious committers who did this have gotten their wrists slapped recently btw.

      why not the rest? What about stdenv? What about fetchers? build-support?

      I don’t know how you imagine that to work? There is no generic way to document bespoke code (LLMs don’t count).

      How easy or hard is it to get a repo in the nix-community org?

      I don’t have much experience with that but the one time I did that I simply walked up to one of the nix-community admins at NixCon and asked them to. I imagine it works roughly the same without being in-person.

      Who is allowed to make large changes to nixpkgs e.g review process, CI/CD, package naming, etc?

      Anyone.

      Small obvious improvements with little to no downsides or room for opinion can just be done and everyone will thank you.

      For “larger” improvements with more room for controversy, you must go through the RFC process. See for instance https://github.com/NixOS/rfcs/pull/140

      How was the official wiki nixxed anyway? Was that an RFC?

      I don’t believe there ever was an official wiki? If so, that must have been ages ago.

      The inofficial one is still up FWIW https://nixos.wiki/.

      Edit: Looked it up and there was an official wiki at some point it was scrapped because it’s better to have the documentation in the Nixpkgs tree together with the code. In a sense, it still exists in the form of the official manual.

      When RFCs can simply be closed as “won’t resolve” or whatever the euphemism is for “no, not on my watch” without community consensus, then I’m not sure what else to call it.

      Not sure which one you’re referring to.

      There have also been packages requested by a few people, a PR from a newcomer attached and it just never crossing the finish line. A reviewer left a comment, the PR creator made a change and asked if it was fine now, only to hear crickets.

      Most of the issues you see can be traced back to limited reviewer capacity.

      If the OG nix community won’t change (or won’t do it quickly enough), then that’s the beauty of opensource: the project can be forked.

      Forking a project is a click of a button but that still won’t solve anything. All problems mentioned here are problems of the community around the project which we sadly haven’t found a way to clone yet. You’d have a project that is dead in the water because maintaining Nixpkgs is an insane amount of work that requires at least a community as large as the one around Nixpkgs.

      tar-like movement of the OG nix community (or the maintainers? dunno)

      Note that you’re talking about an entirely different set of people here than the rest of the post.

      A member finally had enough and just started another one (https://nixlang.wiki/), which IMO already looks and feels much better than unofficial yet officially linked to nixos.wiki

      The main difference is that it runs different (IMHO better) wiki software; wikijs instead of a weird mediawiki fork.

      It’s great that they set it up separately but I’d fully expect it to become the regular nixos.wiki at some point with most of the content copied over. I don’t think anyone wants to keep maintaining the old one’s technical aspects now that this exists.

      That wiki seems to have come from the official wiki being killed, but then a need for a wiki arising and a nix community member taking it upon themselves to create it

      No, it’s because nobody is really maintaining the technical aspect of the current unofficial wiki. The reason they went ahed and set up a new wiki is that it’s easier to start from scratch on a new domain than migrating the old wiki in-place; both from a technical and organisational PoV.

      as the (for lack of better term) nix top dogs for whatever reason didn’t recreate it.

      There is no such thing. I don’t even know who set the wiki up. It’s probably just some person who did it out of passion, just like https://nixlang.wiki/ now.

      You seem to be assuming some sort of authority structure where there really is none. For better or for worse, there is no person or group of people who call the shots. That’s not how we work.

      Most of the NixOS infra for instance was held together mostly by one person in their free time because nobody else stepped up. They’re in the process of transferring that role to a couple others who did eventually step up as we speak.

      It’s similar with a lot of things in the Nix community. The wiki is a good example. The person who set up the new one didn’t want to bother figuring out who in the world maintains the old one and how they could get the new one in place, so they created an entirely new one instead.

      there seems to be a resistance to change or at least an inability to take advantage of the good will and energy of the community.

      There will always be resistance to change. Not all change is good afterall. In moderation, conservatism is a good thing (actual conservatism that is, not the BS kind in current politics).

      I think what you’re feeling is mostly correct but it’s mostly due to lack of time and energy, not because we don’t want to change.

      The rate of change also isn’t uniform. Compared to the infra or Nix itself, Nixpkgs changes quite a lot IMHO.

      • @onlinepersona
        link
        English
        06 months ago

        I recognize the username and you’re a long-time contributor IINM. Your responses resemble those of other long-time contributors. I thank you for your contributions, I really do, but it seems that you have been involved for long enough to have learned how to live with certain things and now consider them normal.

        My opinions are my own and most likely do not represent those of the majority of newcomers (at least I hope they don’t otherwise you wouldn’t have many), but my experience contributing to nix repos has led to me deciding I won’t try and contribute anymore. You can’t make everyone happy so I might just be a statistic of course.

        Good day

        CC BY-NC-SA 4.0