Great achievement by the NixOS Developers. Congratulations!

  • d3Xt3r@lemmy.nzM
    link
    fedilink
    arrow-up
    21
    arrow-down
    1
    ·
    1 year ago

    I thought NixOS was already reproducible, like, isn’t that the whole point? What’s the big deal here, and why is it a “great achievement” - does the Linux world now completely change? Does this revolutionize how Linux ISOs are built?

    • MonkCanatella@sh.itjust.works
      link
      fedilink
      arrow-up
      24
      ·
      1 year ago

      From my understanding, Nix is currently reproducible in that you can easily run an install with a script that gets you set up with the packages and configuration that you want, but the announcement is that they can verify the binaries that they ship are faithful to their source, and haven’t been tampered with anywhere in the build pipeline

      That is almost word for word would the body of the post says

    • Atemu@lemmy.ml
      link
      fedilink
      arrow-up
      9
      arrow-down
      1
      ·
      1 year ago

      There are different “levels” to reproducibility and there’s also a distinction between Nix/Nixpkgs and NixOS.

      You can talk about r13y in terms of functional r13y (same behaviour, though even here you can differentiate between “roughly same behaviour” and “exact same behaviour”) and binary bit-for-bit r13y.

      Nix/Nixpkgs are about producing individual binaries reproducibly. Functional r13y is the most important but binary r13y is a great boon for security testing as it makes verification simple and simplicity trumps when it comes to security.

      NixOS is about building functionally reproducible OS configuration. Because it uses Nixpkgs, the binaries contained in the OS inherit Nixpkgs’ binary r13y. As Nixpkgs becomes more binary-reprodicible, so does NixOS and here we can see the point where binary r13y of the packages in the minimal ISO has reached a point where it’s thought to be fully reproducible.

      The real meat of NixOS is functional r13y though; both kinds: You can reproduce a system with the exact same behaviour from a given Nixpkgs and NixOS config and you can use the same NixOS config with different revisions of Nixpkgs to produce systems which produce roughly the same behaviour.

    • completion@lemmy.one
      link
      fedilink
      English
      arrow-up
      8
      ·
      edit-2
      1 year ago

      I think the ISO specifically wasn’t reproducible but now it is.

      Nix packages are probably what you’re thinking of. They are reproducible

      • Corngood@lemmy.ml
        link
        fedilink
        arrow-up
        21
        ·
        1 year ago

        In general nix packages are not reproducible in the sense that the output will be bit-for-bit identical. When a package is built on two different machines, nix will run the same commands, with the same environment variables, using identical inputs (e.g. source tarballs). However there are various ways build systems, compilers etc can still be non-deterministic, and this effort is about fixing that.

        • Atemu@lemmy.ml
          link
          fedilink
          arrow-up
          5
          ·
          1 year ago

          In general nix packages are not reproducible in the sense that the output will be bit-for-bit identical.

          A large amount aren’t but, OTOH, a large amount also are because Nix does almost everything it can to set up an environment without easily preventable sources of non-determinism such as general filesystem access, networking or other means of communication with some uncontrolled system.

  • Tetsuo@jlai.lu
    link
    fedilink
    arrow-up
    7
    ·
    1 year ago

    If I remember correctly the F-Droid team on Android had a lot of trouble getting reproductible builds. I can’t imagine how difficult this would be for a whole system.