1. 87
    Add tag for Nix/NixOS meta

There have recently been quite a few posts about Nix and NixOS on this site, here are a few of them:

Since there seems to be a Nix post every other day, I think it’s entirely appropriate that a Nix/NixOS tag is created! These posts also seem to get a lot of engagement, so it’s clearly something people here are interested in. As for myself, I’d love to be able to look through Nix posts now that I am trying it out.

  1.  

  2. 30

    I support this idea, so that I may filter them.

    I don’t dislike Nix, but I’m also not interested in it either. Presently, I simply ignore the posts, though having the option to filter them would be nice.

    1. 2

      Yep, gimme more filtering powers!

    2. 7

      Thanks for this proposal! Just two days ago, I went looking for such a talk and fell back to full-text search of “nixos”, but searching for “nix” alone is difficult, as it’s often use in constructs like “nix to mean Linux and other Unices.

      1. 6

        I like this idea! Thank you for doing the due diligence to show why it might be useful. :)

        1. 4

          This sounds good to me. I’d prefer a slightly more generic tag that includes Guix and other related build systems / package managers (I remember hermes off the top of my head, and there was some other package manager in the scientific computing sphere), reproducible builds, bootstrappability. But I don’t really have good suggestions for such a tag name.

          1. 2

            Thanks for the hermes shoutout :). Note I use hermes every day, though patches are not happening fast because I am working on releasing a new project first.

            I do have plans for some future blog posts and posting them here, so a tag would be nice.

            1. 2

              I would love a more generic tag, but this discussion has come up before and we never settle on a good name.

              We might as well bite the bullet and tag nix since it covers 80% of the “declarative/reproducible build” content.

              1. 1

                We might as well bite the bullet and tag nix since it covers 80% of the “declarative/reproducible build” content.

                It doesn’t really, it just forward the confusion nixos has created with regard to reproducible builds and reproducible deployments. NixOS supports the latter, not the former.

                1. 1

                  Would you enlighten us and tell us what reproducible builds really are?

                  1. 2

                    Reproducible builds is bit-for-bit reproduction of build artifacts. There are people working on this from NixOS, but it’s by no means something that isn’t shared by Debian, OpenSUSE and Arch these days.

                    https://en.wikipedia.org/wiki/Reproducible_builds

                    1. 2

                      What is the confusion? Is that NixOS isn’t part of the Reproducible Builds™ group?

                      1. 1

                        They are, but conflating all of the mentioned articles to one “nixos” tag is misattribution. This isn’t unique to NixOS and they have not had a strong push towards deterministic compilation. Reproducible in the context of nixos is just system behavior, but people conflate the features to mean the same thing.

                      2. 1

                        Maybe something like reporoducible-systems?

                        1. 4

                          r13y :)? Fits considering Graham got the domain for NixOS.

                          https://r13y.com/

                          1. 2

                            No, lets not continue these number + letter combinations. First write down how you would explain to a new comer to the site and overall situation why plain english is inadequate.

                            1. 3

                              “English has too long words and makes for a poor UX in a tagging system”.

                              Then I’d promptly point towards your sentence where you replaced “and” with a pluss sign as a demonstration how written language works in practise.

                              1. 1

                                Then I’d promptly point towards your sentence where you replaced “and” with a pluss sign as a demonstration how written language works in practise.

                                Or, we could just use the word reproducibility. I guess I can’t agree with your starting axiom.

                                Another consideration, screen readers. These letter+number “words”, and I use that loosely, seem a worse option for those using screen readers. Have you considered those problems and how they fit into this choice?

                                1. 2

                                  The tag is explained with full complete English sentences if the tag is not clear enough. I do not understand the problem here.

                            2. 1

                              I enjoy this proposal in a genuine way.

                              1. 1

                                I love it! The question is how to give your suggestion more visibility so that it’s actually adopted.

                        2. 1

                          But, for reproducible deployments there’s NixOps, isn’t it ?

                          It’s on my list of stuffs to learn and experiment with, and I think the Nix project is claiming that it does just that.

                          1. 2

                            NixOS is for all intentions and purposes about reproducing system behavior and configurations. NixOPS is probably just more abstractions on top of the existing configurations to deliver them to machines.

                            None of this is reproducible builds.

                            1. 3

                              “None of this is reproducible builds”. That sounds really weird to my ears.

                              You may have your definition of reproducible builds.

                              My own is to have two identical binaries at the end of two builds with identical dependencies. And with this definition of reproducible builds in mind, for me Nix/NixOs is totally based and grounded in reproducible builds.

                              The identity of a build is represented by a hash, and you can identify two builds who would have the same result in the extent that they produce the same hash.

                              1. 1

                                And with this definition of reproducible builds in mind, for me Nix/NixOs is totally centered on reproducible builds.

                                The identity of a build is represented by a hash, and you can identify two builds who would have the same result in the extent that they produce the same hash.

                                It’s not a unique feature of NixOS and not something they have worked hard towards the past years. It feels like a severe missattribution to conflate all of these things to one “nixos” tag.

                                1. 1

                                  About attributing all those concepts to the nixos tag, as if Nixos was the only one… It is a concern I understand.

                                  But I cannot comment nor relate to something precisely about “not something they have worked hard towards the past years” : For me the /nix/store is so central, un-avoidable for any executable to run, that even if they happened not to work hard on it, even let’s say for several years, it would still be the ground on which reproducible builds depends inextricably on one another (other reproducible builds).

                                  1. 1

                                    For me the /nix/store is so central, un-avoidable for any executable to run, that even if they happened not to work hard on it, even let’s say for several years, it would still be the ground on which reproducible builds depends inextricably on one another (other reproducible builds).

                                    But /nix/store isn’t about reproducible builds. The checksums you see is just a hash over the dependency tree. Nothing about bit-for-bit identical build artifacts.

                                    1. 1

                                      If I may take a counter example, with your definition, let’s take a build (traditionnal) that would take as input the current date of the building of the executable, and would display it in a message at each startup. By design, without anyone being able to intervene, this build cannot be bit-by-bit identical on every machine, whether it be on NixOs or not. The date value in question would be always different.

                                      I’m interested, what would be an example of a serious (or insidious or…) issue you know about that could be hidden with current NixOs way of doing?

                                      1. 3

                                        First one is easy as Reproducible Builds defines SOURCE_DATE_EPOCH for the build to follow if it support Reproducible Builds. https://reproducible-builds.org/docs/source-date-epoch/. You can’t achieve reproducible builds in isolation. And it’s a conscious effort from both upstream and downstream to ensure reproducability,

                                        As for the second point, NixOS is still as vulnerable to supply chain compromises as any other distribution. Who compiles your packages, and where is that work done? Are you capable of verifying the work being done by the upstream NixOS packagers?