8 ms·

NixOS is not reproducible

112 points by udev4096 2y ago

_fsql 2y ago
NixOS is a terrible solution rather than a reproducible one. Adding a layer of complexity to simple text files that can be easily edited and having thousands of links that are links to other links is just stupid. Filling up disk space like crazy and using more machine resources on trivial tasks is not an elegant solution. Editing configuration.nix or any other module, reading all the idiotic variable definitions that were invented to change a simple variable in a text file, is boring. I don't know what the Nix designer (NixOS) had in mind when they thought that putting layer upon layer of complexity was a great solution. If something goes wrong in NixOS at the bottom layer, the nixos-rebuild command will produce weird errors. NixOS is an effort to make Linux complex and, in my opinion, useless. I could go on listing the shortcomings of NixOS, but I'll stop here...
- SuperSandro2000 2y ago
  [flagged]
- anthk 2y ago
  Guix, as NixOS, exists when an scientific experiment should have reproducible builds in every stage. On config files, Guile is not that difficult.
  - _fsql 2y ago
    Guile and Nix are horrible languages with shitty syntax, the difference is that one is general purpose (Guile) and the other is a mix of yaml and json, while Guile (Lisp) abuses parentheses and you end up lost in spaghetti code, in Nix you end up not knowing what it's doing even if you're an "expert". They are bad solutions and not very reproducible, because in NixOS you have to change every so often the shitty variables they use to set garbage and in Guix you have to fight if you need non-free software with the NonGuix channel and other kind of nonsense.
    - anthk 2y ago
      Losing parentheses is not an issue for any Lisp programmer. I remind you this is HN, guess on what was built on. >non-free software Non-free software should be the issue, not Guix itself. Not free software by default is NOT reproducible. Period. Useless for science.
      - agubelu 2y ago
        The reproducibility crisis in science has nothing to do with the supporting software itself not being reproducible.
        anthk 2y ago
        Both are needed. Look what happened with Excel in genomics. Once you can control every point of the pipeline, you are set. That means a discrete set of versions, dependencies and being able to rebuild and fix every point of software if bugs show up.
      - poincaredisk 2y ago
        >Non-free software should be the issue, not Guix itself Not the parent, but this approach from Guix maintainers is the reason why it's not an OS I would consider. I use free software almost exclusively, but I appreciate that nixos doesn't try to play the moral police and will let me easily run any non-free software I want. I don't like it, but sometimes using a non free tool is the easiest way to get the job done, and life is too short to get stuck on software idealism (at least for me).
        opan 2y ago
        You are free to use non-free software on Guix System, it's just not in the main channel or officially recommended. You'd likely figure it out fast enough if you wanted.
      - viraptor 2y ago
        > Not free software by default is NOT reproducible. Changing a licence on some software doesn't change the compilation. The licence is completely orthogonal to whether software is reproducible or not.
- womfoo 2y ago
  Can you recommend tools you prefer/use for achieving reproducibility/determinism?
  - im3w1l 2y ago
    I enjoyed thinking about the "how would I do it differently question", note would, as I have never actually tried it. Maybe something like this? All packages are defined as a tuple (dependencies, dev dependencies, base image, command list, file list). Builds are done by loading the base image into a virtual machine, copying the dev dependencies into the vm, running the commands, and then pulling the listed files out into the host. All packages of a given OS edition would use the same base image, I suppose. If a user wants to configure a package it will be done by putting a patch file in his configuration directory. The patch is applied to the built files.
    - viraptor 2y ago
      You're describing nixpkgs with an external builder in a VM. That's exactly what it would do. And that tuple is what nixpkgs packages really are (with some macros on top, but you're not forced to use them).
      - im3w1l 2y ago
        My impression of configuration in nix is that a lot of configuration that in any other distro would be handled by changing some /etc/file is instead done in a completely separate way by editing some nix file. So that's one user-visible way it differs from what I mentioned of using a patch for the /etc/file. Some simple example I found just now: https://unix.stackexchange.com/questions/489509/how-do-i-modify-my-hosts-file-in-nixos https://unix.stackexchange.com/questions/489509/how-do-i-mod...
        viraptor 2y ago
        There are patches which need to live in the repo by default anyway, so that's already supported, just not as random /etc location. https://github.com/NixOS/nixpkgs/tree/master/pkgs/by-name/aw/aws-gate https://github.com/NixOS/nixpkgs/tree/master/pkgs/by-name/aw...
- teh 2y ago
  I feel you (like many people) got burned by the steep learning curve. Empirically some pretty high powered companies use nix successfully. It's of course always difficult to know the counterfactual (would they have been fine with ubuntu) but the power to get SBOMs, patch a dependencies deep in the dependency stack, roll back entire server installs etc. really helps these people scale. nixpkgs is also the largest and most up to date package set (followed by arch) so there's clearly something in the technology that allows a loosely organised group of people to scale to that level.
  - attendant3446 2y ago
    I know it's not a proper measurement, but I can't remember the last time I missed something in AUR, but in my short time on NixOS I missed 2 apps and 1 app that disappeared in the NixOS channel upgrade.
  - _fsql 2y ago
    NixOS has very limited usage, with few companies adopting it for critical or commercial tasks. It is more common in experimental niches. One of the main issues with nixpkgs is that users have to rely on overlays for a package. This can lead to obscure errors because if something fails in the original package or a Nix module, it's hard to pinpoint the problem. Additionally, the overuse of links in the directory hierarchy further complicates things, giving the impression that NixOS is a patched and poorly designed structure. As someone who has tried Nix, uses NixOS, and created my own modular configuration, I made optimizations and wrote some modules to scratch my own itch. I realized I was wasting time trying to make one tool configure other tools. That’s essentially what NixOS does through Nix. Why complicate a Linux system when I can just write bash scripts and automate my tasks without hassle? Sure, they might say it’s reproducible, but it really isn’t. Several packages in NixOS can fail because a developer redefined a variable; this then affects another part of the module and misconfigures the upstream package. So, you end up struggling with something that should be simple and straightforward to diagnose.
- attendant3446 2y ago
  I agree with everything you just said. I really like the idea behind NixOS - write a config and apply it, all containerised, but I never had a chance to try it until recently when I got a new laptop at work. But after 3 months I updated my Ansible playbook, added things I needed for work, went back to Arch and couldn't be happier. With NixOS it felt like there was an extra maintenance fee for doing regular Linux things. It just wasn't worth it for me.
  - poincaredisk 2y ago
    I'm a bit surprised to read it - for me I configured my system years ago and it just "keeps working" (I very rarely need to edit my configuration, for trying new programs I just spawn a nix-shell). Though I agree that first time doing anything has an additional cost - for example configuring my HP printer was maybe three lines of nix code, but I had to spend some time with forums to write them. On the other hand, I now just reuse these lines everywhere and don't have to think about it at all. For me that's a lot of time saved. It's entirely possible you're using OS differently than I do, and cost/benefit calculation is different for you.
    - _fsql 2y ago
      If NixOS works well for you, that's great! But from my perspective, the whole NixOS model adds unnecessary complexity and makes you learn ways to do things that don’t really translate to other Linux systems. The directory structure in NixOS is different and doesn't follow the FHS (Filesystem Hierarchy Standard) and the system uses a bunch of symbolic links that feel like "hacks" to keep some kind of compatibility with the FHS. For example, if you want NixOS to recognize paths like /bin or /usr/bin in your scripts, you have to enable services.envfs.enable in your configuration.nix or in a .nix module. If something goes wrong in NixOS, you might run into multiple issues because the problem could be within NixOS, the underlying system, nixpkgs, upstream packages, or a mix of all these factors. Sure, it might save you time in some situations, but when a problem pops up, you'll find yourself in a tricky spot since you’ll have to dig through all the layers of the system to find the root cause. On top of that, you’ll have to sift through the options and the documentation, which can often be pretty confusing.
pjmlp 2y ago
I know Linux since Slackware 2, have lost count of how many distributions I have tried since that 1995's Summer, and still see no point on bothering with NixOS. EDIT: As usual in some Linux forums, I got a bunch of marketing replies about all the cool ideas NixOS is supposed to bring as if I haven't read about them myself in LWN and other Linux sources I routinely check on.
- anthk 2y ago
  With Guix and Nix you often you don't run IDE's in the traditional way. You write a declarative file with all the processes, dependencies and so on. I know it would suck for GUI programming with Java/C#/Vala, as often some packages are not granted as dependencies, such as gcc/autohell/libtool if you install some C++ iIDE, but that's it.
- SuperSandro2000 2y ago
  Most others just follow the same concept of running imperative commands and not much about them is revolutionary. NixOS gives that a new spin.
  - pdimitar 2y ago
    We know the beautiful theory. Show me something easy to onboard and use. I've learned no less than 500 separate tech pieces in my life, Nix and any others will have to make it worth my while in the first 10 minutes.
    - yjftsjthsd-h 2y ago
      If you've learned more than 500 things, why does the 501st need to be so much more special in order to be worth your time?
      - pdimitar 2y ago
        Because most of those that I have learned were bad at onboarding, and you do get sick of it after a while. I've improved no less than 25 projects' README's (sadly all private / corporate so I can't even advertise myself that way) by removing 50 lines of semi-useless prose and replacing them with 2 paragraphs 4 lines each and one small code block as a usage example. So TL;DR -- because most programmers can't describe a use-case if their lives depended on it.
PhilipRoman 2y ago
Good article. I was really surprised that the hash is not based on built artifacts. In hindsight it makes sense, since making every package reproducible upfront would be a ton of work.
- SuperSandro2000 2y ago
  That will change with content addressed derivations but they are progressing slowly exactly because of this.
xterminator 2y ago
Ever since I started using Zig, making everything reproducible has never been as easy as just using the Zig build system.
BimJeam 2y ago
I once tried to use it but it simple was not able to use Android-SDK /adb in it. Then I never used it again and fell back to arch linux.
- exe34 2y ago
  $ nix-shell -p android-tools [nix-shell:~]$ adb --version Android Debug Bridge version 1.0.41 Version 35.0.1-android-tools Installed as /nix/store/dxdygi06ixq7y419hmc4skz4cdzbcnwf- android-tools-35.0.1/bin/adb Running on Linux 6.10.3 (x86_64)
  - fallingsquirrel 2y ago
    Sure, but it won't successfully connect to a real device unless you somehow know to also set `programs.adb.enable = true`.
    - viraptor 2y ago
      That's not nixos specific. You get special instructions for Ubuntu https://help.ubuntu.com/community/AndroidSDK https://help.ubuntu.com/community/AndroidSDK Arch https://wiki.archlinux.org/title/Android_Debug_Bridge https://wiki.archlinux.org/title/Android_Debug_Bridge Gentoo https://wiki.gentoo.org/wiki/Android/adb https://wiki.gentoo.org/wiki/Android/adb ... And the adb option is in the docs with a description of what to do https://nixos.org/manual/nixos/stable/options#opt-programs.adb.enable https://nixos.org/manual/nixos/stable/options#opt-programs.a...
      - fallingsquirrel 2y ago
        Yes, I know that and you know that. But GP wanted to install the package and move on with his life instead of debugging a connection that failed with no indication why on an unfamiliar OS. https://search.nixos.org/packages?channel=24.05&show=android-tools&from=0&size=50&sort=relevance&type=packages&query=android-tools https://search.nixos.org/packages?channel=24.05&show=android... > How to install android-tools? > environment.systemPackages = [ pkgs.android-tools ]; How was he supposed to know to ignore those instructions and go to a completely different set of docs and search for "programs.adb.enable"? Instead he gave up and switched to another distro where you install the package and it Just Works™. Even though NixOS's model is conceptually better, it loses out on tons of potential users because of usability problems like this. (I'm running NixOS btw)
SuperSandro2000 2y ago
[flagged]
- Foxboron 2y ago
  Calling it a "minor naming ambiguity" when people get surprised every time it gets pointed out is underselling the (albeit small) problem.
Alifatisk 2y ago
So if it's not reproducable, what is it good for? To recreate similar environment easily?
- ranguna 2y ago
  I've never tried nixos, but I'm very close to trying. For me the good points are what you said + having the full configuration of my system in a single place (no more looking at the bash history to understand what I did) and easy rollbacks (no more having to boot into a live usb to fix my broken system).
- viraptor 2y ago
  The "reproducible" as in the strict definition and reproducible for practical developer are different concepts. While bit-level reproducibility impacts everyone in some small way, normally devs care about whether the same versions are deployed everywhere and work the same for everyone. They ignore issues like function A being before function B in their shared library, but B before A on their coworker's machine. Or the fact that some debug symbol contains a timestamp. In general it's good for declarative management of systems and projects that can be deployed in a repeatable (even if not 100% reproducible) way.
- paulddraper 2y ago
  It is reproducible only with a narrow definition. Usually "deterministic" is used instead to describe this.
simonask 2y ago
[flagged]
- r4indeer 2y ago
  Personally, I like a lot of things about NixOS. Redeploying a machine has never been easier for me as all of my config is stored in a git repo in a few .nix files. I don't need to remember what I installed or configured somewhere in /etc five years ago, I can just look in the .nix file for that machine. Everything I configure or install is synced across my desktop and laptop through imports (unless specified), which makes the experience very seamless. When something goes wrong e.g. after an upgrade, I just reboot and choose the previous generation from the boot menu. If I just want to try out a package, I can get a temporary shell where that package is available. If I don't need it after all, it just gets garbage collected. When working on a project, I can use a dev shell where everything I need to build/test that project is isolated so I don't pollute my root namespace.
  - WJW 2y ago
    I like the benefits too, but honestly these are all problems that I simply don't have and the "costs" in learning the new system in the face of the terrible docs and fragmented community are quite high. I get a new computer once every few years and getting my usual programs installed is no more than a few hours work at most. I have 2 computers, one for work and one for private. Syncing installed programs is neither necessary nor particularly wanted; I don't want Steam on my laptop, nor do I want to run postgres on my private system. The only time an upgrade breaks stuff these days is when a kernel update needs the drivers to be recompiled. The command for that is stored in a file on my desktop and takes less than a minute to find, type in and wait until everything is fine again. Regarding unwanted packages and "namespace pollution", every once in a while I install a program that is used once or twice and then forgotten about. This doesn't impede my normal workflow at all. So the benefits of NixOS would be minimal for me, while the onboarding materials and documentation are pretty atrocious. The effort/reward ratio is just not there.
SuperHeavy256 2y ago
Why is every comment here negative?
- Paria_Stark 2y ago
  Hacker news showing its skill issues in force today I guess.
  - RandomThoughts3 2y ago
    The issue has more to do with Nix poor onboarding, dreadful documentation and difficulty articulating its value proposition. I personally think that the idea of Nix is fine but the execution is not there. Look even Bazel which is built on fairly similar concepts but only targets built where it makes more sense and has a far better configuration language still struggle with adoption. It’s clear that Nix which wants to make immutable something people actually mostly never tinker will have to fight an uphill battle.
  - agubelu 2y ago
    This is one of my main gripes with Nix. When something it's hard or unintuitive it's not Nix's fault, it's a skill issue on your part because you just "don't get it". It gets tiring quick.
  - IshKebab 2y ago
    Saying it's a skill issue just shows lack of imagination and ambition to make it better.
    - pirates 2y ago
      Or as they might phrase it, a skill issue.
- 0points 2y ago
  the "i dont get it" crowd found this thread
- elikoga 2y ago
Aleksana 2y ago
In fact, reproducing artifacts will have more uncertain factors without a correctly designed tool chain. Accidentally introducing timestamps is just one common case, others include the order of multi-threaded builds, Haskell's GHC compiler has had this problem for a long time, and sometimes Rust seems to be affected as well. There are also some tricky situations, which are related to the features of the file system. It is misleading to say that NixOS has complete reproducibility. However, NixOS is indeed more advanced in some aspects. You can reproduce a working development environment, you can easily test the build process you will deploy to CI locally, move your favorite configurations between computers, or share certain parts between them. This is the benefits of declarative package management (or package build system). Unreproducible situations do occur during the building process of packages (derivation), but these situations usually have nothing to do with functionality, and it is easy to see where the problem is with diffscope. We have specifically tracked and dealt with these issues. At present, they are still within a relatively controllable range. See https://reproducible.nixos.org/ https://reproducible.nixos.org/ https://github.com/NixOS/nixpkgs/issues?q=sort%3Aupdated-desc+is%3Aopen+label%3A%226.topic%3A+reproducible+builds%22 https://github.com/NixOS/nixpkgs/issues?q=sort%3Aupdated-des... I would also thank @anthk for introducing people to Guix. As a late sibling to Nix (the ecosystem), Guix is cleaner in handling the basic toolchain and does a better job in full source bootstrapping, which we are working hard to learn and improve. However, Guix and Nix have the same constraints, they can only reproduce the way the system is built and composed, not the artifact itself. We both track reproducibility problems, and there are interested maintainers actively addressing these issues. See https://issues.guix.gnu.org/search?query=reproducible https://issues.guix.gnu.org/search?query=reproducible When it comes to whether you should choose NixOS (or Guix), I think you should weigh your workflow, usage habits, and learning costs. Given the significant difference in the way of thinking, we can't make it painless for people to migrate from distributions like Debian/Arch or Ubuntu to NixOS. But if you really need it, I believe you will still come one day
- szundi 2y ago
  Probably much better repdoducibility than embedded developers trying to maintain thet while upgrading their ubuntus thy work on.
752963e64 2y ago
[dead]
petterroea 2y ago
It is completely fine that NixOS is not reproducable for me. I personally switched(from arch) because my old setup was very finicky(eGPU + optimus on the go for iGPU) and i was sick of random updates bricking stuff. I'm becoming too old to enjoy spending an hour+ tinkering with stuff that suddenly broke. Now it is hard to imagine going back. I just enjoy that applying all my customizations is a single action. But Linderud has a good point, and I think a community like HN is rightfully interested in busting myths like this. I didn't know how the hashes worked, I haven't needed to have a relationship to them. But now I do!
- 1oooqooq 2y ago
  how exactly does nix prevents updates from breaking your system? arch is as close to upstream as possible, so you're not updating from upstream either... are you just... not updating?
  - mrslave 2y ago
    It's more like the whole upgrade is either successful, or it is not, and you are not left in an indeterminate state. E.g. A depends on B. In a large update, B updates, something unrelated fails to install and the update fails, and now A doesn't run because it wasn't upgraded and the still installed old version of A depends on the no longer available previous version of B. In NixOS, you either enter the new environment with all packages updated, or you don't. In the situation where you discover run-time - not install-time - errors, you can simply roll back to the previous set of packages. If the new packages cause a system crash, you can enter previous states from the bootloader. Now none of this magically solves the software defects themselves. But it gives you a consistent system state that can be transactionally upgraded, or reentered at any time. And then you can raise the appropriate bug tickets. Your system configuration is in a single file and the need to reconfigure different services in a particular order is gone. Also your dependencies are all nicely pinned with Flakes. This makes importing arbitrary dependencies - open-source or proprietary - a breeze. This has removed any previous appetite we had for a monorepo, which was primarily to ease access to our other libraries. It's all very nice, once you are over the not insubstantial learning curve that is.
dwb 2y ago
It's a fine point to make, but I get the feeling some people's perceptions (that Nix introductory docs are unclear) are out of date. From nixos.org, I click "Learn", "How Nix works", and it says in the first section that the hashes are "a cryptographic hash of the package’s build dependency graph". https://nixos.org/guides/how-nix-works/ https://nixos.org/guides/how-nix-works/
blacklion 2y ago
> A build is reproducible if given the same source code, build environment and build instructions It is very strange definition. To me it is tautological, as computers are deterministic and if you have same build environment you will get same results by necessity. Same bits into input - some bits out of output. Edit: formatting.
- Foxboron 2y ago
  > as computers are deterministic I have some bad news.
- tazjin 2y ago
  You're either assuming that "build environment" includes more things than the author does (it's not exactly a well-defined term), or you're not aware of the sources of non-reproducibility. It can be simple things (something includes timestamps in binaries, which can be worked around by pinning the time), and complex things (concurrent linking of binaries is done FIFO-style, and different compilation units finish at different times in different runs because of varying processor load).
  - blacklion 2y ago
    assuming that "build environment" includes more things than the author does (*it's* *not* *exactly* *a* *well-defined* *term*) It is exactly my point. What is "build environment"? This definition is crucial for defining "reproducible builds" and we cannot handwave it away.
    - viraptor 2y ago
      Normally the built environment means the software part - files on the disk which are part of the build process. Your hardware, network, time, location, language, etc. shouldn't influence the output. There's an explanation at https://reproducible-builds.org/docs/definition/ https://reproducible-builds.org/docs/definition/ which is a bit vague, but I haven't heard anyone seriously disputing that one in good faith. People doing the work know what this means.
poincaredisk 2y ago
Good points in the OP. Instead of joining the distro war in the comments, I'll just note that NixOs builds may not be reproducible - because they often reuse non-reproducible building blocks, like makefiles or compilers which are also not reproducible - but NixOs maintainers spend a lot of time helping to improve the overall ecosystem and make builds more reproducible for everyone.
- uecker 2y ago
  make and compilers are usually reproducible. Most Debian package are reproducible, so this is perfectly feasible.
  - Foxboron 2y ago
    You would think so, but after close to 10 years as a package maintainer it's clear to me that people don't know how make works when you do start doing anything else than `-j1`. The gcc compiler also fails to reproduce binaries with the LTO streamer backend if you use certain macros. This has the consequence of making cgo binaries unreproducible. As for Debian, we don't really know how many packages are reproducible. The CI they show is for fuzzing out issues, there are no system currently reproducing distributed packages.
  - diffeomorphism 2y ago
    Usually they aren't because of timestamps, processor features etc. After quite a bit of work Debian is now at 96% (or 93% when varying a few more things) https://tests.reproducible-builds.org/debian/reproducible.html https://tests.reproducible-builds.org/debian/reproducible.ht...
- throwayaw84330 2y ago
  I don't think it's fair enough. Look for example at their quoted source: https://reproducible.nixos.org/nixos-iso-minimal-r13y/ https://reproducible.nixos.org/nixos-iso-minimal-r13y/ -- the way nix works allows for a mechanism to (almost*) check the reproducibility of the system, and it can show how reproducible it is for a complete build (99%). In contrast, other distros like Debian have to rely on fuzzing to estimate this percent. Quoting from the FAQ: > We don't currently inject randomness at the filesystem layer, but many of the reproducibility issues are being exercised already. It isn't possible to guarantee a package is reproducible, just like it isn't possible to prove software is bug-free. It is possible there is nondeterminism in a package source, waiting for some specific circumstance.
kstenerud 2y ago
I'm having a hard time thinking of a case where 100% bit-for-bit reproducible builds would be a necessary thing. As long as I can rebuild and get a system that works the same way as before, I'm happy. And I don't even need Nix to do that; there are much simpler ways to do so.
- poincaredisk 2y ago
  They're not necessary, but it's a nice thing to have. On a level of a single binary, you can prove that the program you have has been built from a corresponding source code (no backdoor included). Which is very important if you want to increase the security of your supply chain (most people won't compile signal from source, for example).
- matrss 2y ago
  > As long as I can rebuild and get a system that works the same way as before, I'm happy. Bit-for-bit identical packages is the only way to guarantee it works the same way (in the absence of differences in hardware behaviour, otherwise reproducibility can't help you either). Yes, building in a functionally identical environment will probably be good enough even if the result isn't bit-for-bit identical, but then you still have to be able to rebuild said environment, and nix gives you the tools to at least get such a repeatable environment. Outside of nix and guix I am not aware of any tool that can do the same from source. So: > And I don't even need Nix to do that; there are much simpler ways to do so. Genuinely curious, what simpler ways are you referring to?
  - lostmsu 2y ago
    Not the parent, but you can have a base image + set of offline only setup scripts.
    - matrss 2y ago
      That doesn't satisfy the requirement "from source". Sure, you can build on a large binary blob that already contains everything you need, but then you are just moving the issue into the build process of that blob. Also, 99% of container image build scripts (Dockerfiles, etc.) probably don't pin an exact base image and don't avoid pulling in external resources (e.g. packages from the base image distro's repositories). I wouldn't call a system that makes it very easy to break reproducible build environments easier than just using nix to achieve that reproducibility.
pveierland 2y ago
This post does not do Nix justice, as it only references the extensional model of Nix. In the PhD of Eelco Dolstra, the extensional model (chapter 5) describes derivations with identity based on their inputs, while the intentional model (chapter 6) describes derivations with identity based on their outputs [1]. Due to the complexity of the intentional model, the extensional model has been the initially used one. The upgrade to content addressed derivations is ongoing (see blog posts via Tweag for an intro [2]). > Neither Nix or NixOS gives you these guarantees. With content addressed derivations you can guarantee that any party can recreate bit-by-bit identical copies of derivations, meaning that Nix can guarantee reproducibility. Beta testing of content addressability in Nix started in May 2021 [3]. [1] https://edolstra.github.io/pubs/phd-thesis.pdf https://edolstra.github.io/pubs/phd-thesis.pdf [2] https://www.tweag.io/blog/2020-09-10-nix-cas/ https://www.tweag.io/blog/2020-09-10-nix-cas/ [3] https://discourse.nixos.org/t/content-addressed-nix-call-for-testers/12881 https://discourse.nixos.org/t/content-addressed-nix-call-for...
- Foxboron 2y ago
  > With content addressed derivations you can guarantee that any party can recreate bit-by-bit identical copies of derivations It wouldn't guarantee anything. It would force you, and anyone else, to do massive rebuilds when some binary down the tree changes, or has a regression.
  - pveierland 2y ago
    My writing was imprecise, I meant to communicate that it makes it possible to trust the contents of a derivation, given that you know that the hash is correct, which can be verified independently in the cases where the derivation is reproducible. Content addressability makes it easier to establish and verify trust across systems. Given the degree to which the post is referenced, I do feel that it misses out by only describing input addressed derivations and not CA.
dzarasovlloyd 2y ago
[dead]
rssoconnor 2y ago
I could be wrong (and I probably am) but I feel like the term "reproducible build" has shifted/solidified since 2006 when Dolstra's thesis was first written (which itself doesn't really use that term all that much). As evidence the first wikipedia page on "Reproducible builds" seems to have appeared in 2016, a decade after Dolstra's thesis, and even that stub from 2016 appears to prefer to use the term "Deterministic compilation". Anyhow, when the Nix project originally spoke about "reproducible builds", what I understood was meant by that term was "being able to repeat the same build steps with the same inputs". Because of the lack of determinstic compilation, this doesn't always yield bit-by-bit identical outputs, but are simply presumed to be "functionally identical". There is, of course, no reason to believe that they will necessarily be functionally identical, but it is what developers take for granted every day, and if otherwise would be considered a bug somewhere in the package. With Nix, when some software "doesn't work for me, but works for you", we can indeed recursively compare the nix derivation files locating and eliminating potential differences, a debugging process I have used on occasion. I agree that "reproducible builds" now means something different, but that isn't exactly the fault of Nix advocates. I guess a new term for "being able to repeat the same build steps with the same inputs" is needed.
- pabs3 2y ago
  "Repeatable builds" seems like what you want?
pshirshov 2y ago
Yes, it isn't. But they did a lot to eradicate entropy in the builds and I believe they are able to reproduce base system images bit by bit. Another attempt in that area is stal/ix, which is much more reproducible than nix, its store is content-addressable: https://stal-ix.github.io/ https://stal-ix.github.io/
- Koshkin 2y ago
  > Yes, it isn't. It took me some time to get used to the way native speakers of English express agreement or disagreement with a negative statement. Agree: “No, it isn’t.” Disagree: “Yes, it is.”
  - pshirshov 2y ago
    Thank you for your valuable comment.
keeganpoppen 2y ago
is this not the retcon of the century? hasn't reproducibility / consistency been an alleged selling point of nixos for a long time? it sure as hell isn't the ergonomics of the nix language, nor that of the ecosystem...
- xyzsparetimexyz 2y ago
  maybe

112 points by udev4096 2y ago

NixOS is a terrible solution rather than a reproducible one. Adding a layer of complexity to simple text files that can be easily edited and having thousands of links that are links to other links is just stupid. Filling up disk space like crazy and using more machine resources on trivial tasks is not an elegant solution. Editing configuration.nix or any other module, reading all the idiotic variable definitions that were invented to change a simple variable in a text file, is boring. I don't know what the Nix designer (NixOS) had in mind when they thought that putting layer upon layer of complexity was a great solution. If something goes wrong in NixOS at the bottom layer, the nixos-rebuild command will produce weird errors. NixOS is an effort to make Linux complex and, in my opinion, useless. I could go on listing the shortcomings of NixOS, but I'll stop here...

SuperSandro2000 2y ago
[flagged]
anthk 2y ago
Guix, as NixOS, exists when an scientific experiment should have reproducible builds in every stage. On config files, Guile is not that difficult.
- _fsql 2y ago
  Guile and Nix are horrible languages with shitty syntax, the difference is that one is general purpose (Guile) and the other is a mix of yaml and json, while Guile (Lisp) abuses parentheses and you end up lost in spaghetti code, in Nix you end up not knowing what it's doing even if you're an "expert". They are bad solutions and not very reproducible, because in NixOS you have to change every so often the shitty variables they use to set garbage and in Guix you have to fight if you need non-free software with the NonGuix channel and other kind of nonsense.
  - anthk 2y ago
    Losing parentheses is not an issue for any Lisp programmer. I remind you this is HN, guess on what was built on. >non-free software Non-free software should be the issue, not Guix itself. Not free software by default is NOT reproducible. Period. Useless for science.
    - agubelu 2y ago
      The reproducibility crisis in science has nothing to do with the supporting software itself not being reproducible.
      - anthk 2y ago
        Both are needed. Look what happened with Excel in genomics. Once you can control every point of the pipeline, you are set. That means a discrete set of versions, dependencies and being able to rebuild and fix every point of software if bugs show up.
    - poincaredisk 2y ago
      >Non-free software should be the issue, not Guix itself Not the parent, but this approach from Guix maintainers is the reason why it's not an OS I would consider. I use free software almost exclusively, but I appreciate that nixos doesn't try to play the moral police and will let me easily run any non-free software I want. I don't like it, but sometimes using a non free tool is the easiest way to get the job done, and life is too short to get stuck on software idealism (at least for me).
      - opan 2y ago
        You are free to use non-free software on Guix System, it's just not in the main channel or officially recommended. You'd likely figure it out fast enough if you wanted.
    - viraptor 2y ago
      > Not free software by default is NOT reproducible. Changing a licence on some software doesn't change the compilation. The licence is completely orthogonal to whether software is reproducible or not.
womfoo 2y ago
Can you recommend tools you prefer/use for achieving reproducibility/determinism?
- im3w1l 2y ago
  I enjoyed thinking about the "how would I do it differently question", note would, as I have never actually tried it. Maybe something like this? All packages are defined as a tuple (dependencies, dev dependencies, base image, command list, file list). Builds are done by loading the base image into a virtual machine, copying the dev dependencies into the vm, running the commands, and then pulling the listed files out into the host. All packages of a given OS edition would use the same base image, I suppose. If a user wants to configure a package it will be done by putting a patch file in his configuration directory. The patch is applied to the built files.
  - viraptor 2y ago
    You're describing nixpkgs with an external builder in a VM. That's exactly what it would do. And that tuple is what nixpkgs packages really are (with some macros on top, but you're not forced to use them).
    - im3w1l 2y ago
      My impression of configuration in nix is that a lot of configuration that in any other distro would be handled by changing some /etc/file is instead done in a completely separate way by editing some nix file. So that's one user-visible way it differs from what I mentioned of using a patch for the /etc/file. Some simple example I found just now: https://unix.stackexchange.com/questions/489509/how-do-i-modify-my-hosts-file-in-nixos https://unix.stackexchange.com/questions/489509/how-do-i-mod...
      - viraptor 2y ago
        There are patches which need to live in the repo by default anyway, so that's already supported, just not as random /etc location. https://github.com/NixOS/nixpkgs/tree/master/pkgs/by-name/aw/aws-gate https://github.com/NixOS/nixpkgs/tree/master/pkgs/by-name/aw...
teh 2y ago
I feel you (like many people) got burned by the steep learning curve. Empirically some pretty high powered companies use nix successfully. It's of course always difficult to know the counterfactual (would they have been fine with ubuntu) but the power to get SBOMs, patch a dependencies deep in the dependency stack, roll back entire server installs etc. really helps these people scale. nixpkgs is also the largest and most up to date package set (followed by arch) so there's clearly something in the technology that allows a loosely organised group of people to scale to that level.
- attendant3446 2y ago
  I know it's not a proper measurement, but I can't remember the last time I missed something in AUR, but in my short time on NixOS I missed 2 apps and 1 app that disappeared in the NixOS channel upgrade.
- _fsql 2y ago
  NixOS has very limited usage, with few companies adopting it for critical or commercial tasks. It is more common in experimental niches. One of the main issues with nixpkgs is that users have to rely on overlays for a package. This can lead to obscure errors because if something fails in the original package or a Nix module, it's hard to pinpoint the problem. Additionally, the overuse of links in the directory hierarchy further complicates things, giving the impression that NixOS is a patched and poorly designed structure. As someone who has tried Nix, uses NixOS, and created my own modular configuration, I made optimizations and wrote some modules to scratch my own itch. I realized I was wasting time trying to make one tool configure other tools. That’s essentially what NixOS does through Nix. Why complicate a Linux system when I can just write bash scripts and automate my tasks without hassle? Sure, they might say it’s reproducible, but it really isn’t. Several packages in NixOS can fail because a developer redefined a variable; this then affects another part of the module and misconfigures the upstream package. So, you end up struggling with something that should be simple and straightforward to diagnose.
attendant3446 2y ago
I agree with everything you just said. I really like the idea behind NixOS - write a config and apply it, all containerised, but I never had a chance to try it until recently when I got a new laptop at work. But after 3 months I updated my Ansible playbook, added things I needed for work, went back to Arch and couldn't be happier. With NixOS it felt like there was an extra maintenance fee for doing regular Linux things. It just wasn't worth it for me.
- poincaredisk 2y ago
  I'm a bit surprised to read it - for me I configured my system years ago and it just "keeps working" (I very rarely need to edit my configuration, for trying new programs I just spawn a nix-shell). Though I agree that first time doing anything has an additional cost - for example configuring my HP printer was maybe three lines of nix code, but I had to spend some time with forums to write them. On the other hand, I now just reuse these lines everywhere and don't have to think about it at all. For me that's a lot of time saved. It's entirely possible you're using OS differently than I do, and cost/benefit calculation is different for you.
  - _fsql 2y ago
    If NixOS works well for you, that's great! But from my perspective, the whole NixOS model adds unnecessary complexity and makes you learn ways to do things that don’t really translate to other Linux systems. The directory structure in NixOS is different and doesn't follow the FHS (Filesystem Hierarchy Standard) and the system uses a bunch of symbolic links that feel like "hacks" to keep some kind of compatibility with the FHS. For example, if you want NixOS to recognize paths like /bin or /usr/bin in your scripts, you have to enable services.envfs.enable in your configuration.nix or in a .nix module. If something goes wrong in NixOS, you might run into multiple issues because the problem could be within NixOS, the underlying system, nixpkgs, upstream packages, or a mix of all these factors. Sure, it might save you time in some situations, but when a problem pops up, you'll find yourself in a tricky spot since you’ll have to dig through all the layers of the system to find the root cause. On top of that, you’ll have to sift through the options and the documentation, which can often be pretty confusing.

pjmlp 2y ago

I know Linux since Slackware 2, have lost count of how many distributions I have tried since that 1995's Summer, and still see no point on bothering with NixOS. EDIT: As usual in some Linux forums, I got a bunch of marketing replies about all the cool ideas NixOS is supposed to bring as if I haven't read about them myself in LWN and other Linux sources I routinely check on.

anthk 2y ago
With Guix and Nix you often you don't run IDE's in the traditional way. You write a declarative file with all the processes, dependencies and so on. I know it would suck for GUI programming with Java/C#/Vala, as often some packages are not granted as dependencies, such as gcc/autohell/libtool if you install some C++ iIDE, but that's it.
SuperSandro2000 2y ago
Most others just follow the same concept of running imperative commands and not much about them is revolutionary. NixOS gives that a new spin.
- pdimitar 2y ago
  We know the beautiful theory. Show me something easy to onboard and use. I've learned no less than 500 separate tech pieces in my life, Nix and any others will have to make it worth my while in the first 10 minutes.
  - yjftsjthsd-h 2y ago
    If you've learned more than 500 things, why does the 501st need to be so much more special in order to be worth your time?
    - pdimitar 2y ago
      Because most of those that I have learned were bad at onboarding, and you do get sick of it after a while. I've improved no less than 25 projects' README's (sadly all private / corporate so I can't even advertise myself that way) by removing 50 lines of semi-useless prose and replacing them with 2 paragraphs 4 lines each and one small code block as a usage example. So TL;DR -- because most programmers can't describe a use-case if their lives depended on it.

PhilipRoman 2y ago

Good article. I was really surprised that the hash is not based on built artifacts. In hindsight it makes sense, since making every package reproducible upfront would be a ton of work.

SuperSandro2000 2y ago
That will change with content addressed derivations but they are progressing slowly exactly because of this.

xterminator 2y ago

Ever since I started using Zig, making everything reproducible has never been as easy as just using the Zig build system.

BimJeam 2y ago

I once tried to use it but it simple was not able to use Android-SDK /adb in it. Then I never used it again and fell back to arch linux.

exe34 2y ago
$ nix-shell -p android-tools [nix-shell:~]$ adb --version Android Debug Bridge version 1.0.41 Version 35.0.1-android-tools Installed as /nix/store/dxdygi06ixq7y419hmc4skz4cdzbcnwf- android-tools-35.0.1/bin/adb Running on Linux 6.10.3 (x86_64)
- fallingsquirrel 2y ago
  Sure, but it won't successfully connect to a real device unless you somehow know to also set `programs.adb.enable = true`.
  - viraptor 2y ago
    That's not nixos specific. You get special instructions for Ubuntu https://help.ubuntu.com/community/AndroidSDK https://help.ubuntu.com/community/AndroidSDK Arch https://wiki.archlinux.org/title/Android_Debug_Bridge https://wiki.archlinux.org/title/Android_Debug_Bridge Gentoo https://wiki.gentoo.org/wiki/Android/adb https://wiki.gentoo.org/wiki/Android/adb ... And the adb option is in the docs with a description of what to do https://nixos.org/manual/nixos/stable/options#opt-programs.adb.enable https://nixos.org/manual/nixos/stable/options#opt-programs.a...
    - fallingsquirrel 2y ago
      Yes, I know that and you know that. But GP wanted to install the package and move on with his life instead of debugging a connection that failed with no indication why on an unfamiliar OS. https://search.nixos.org/packages?channel=24.05&show=android-tools&from=0&size=50&sort=relevance&type=packages&query=android-tools https://search.nixos.org/packages?channel=24.05&show=android... > How to install android-tools? > environment.systemPackages = [ pkgs.android-tools ]; How was he supposed to know to ignore those instructions and go to a completely different set of docs and search for "programs.adb.enable"? Instead he gave up and switched to another distro where you install the package and it Just Works™. Even though NixOS's model is conceptually better, it loses out on tons of potential users because of usability problems like this. (I'm running NixOS btw)

SuperSandro2000 2y ago

[flagged]

Foxboron 2y ago
Calling it a "minor naming ambiguity" when people get surprised every time it gets pointed out is underselling the (albeit small) problem.

Alifatisk 2y ago

So if it's not reproducable, what is it good for? To recreate similar environment easily?

ranguna 2y ago
I've never tried nixos, but I'm very close to trying. For me the good points are what you said + having the full configuration of my system in a single place (no more looking at the bash history to understand what I did) and easy rollbacks (no more having to boot into a live usb to fix my broken system).
viraptor 2y ago
The "reproducible" as in the strict definition and reproducible for practical developer are different concepts. While bit-level reproducibility impacts everyone in some small way, normally devs care about whether the same versions are deployed everywhere and work the same for everyone. They ignore issues like function A being before function B in their shared library, but B before A on their coworker's machine. Or the fact that some debug symbol contains a timestamp. In general it's good for declarative management of systems and projects that can be deployed in a repeatable (even if not 100% reproducible) way.
paulddraper 2y ago
It is reproducible only with a narrow definition. Usually "deterministic" is used instead to describe this.

simonask 2y ago

[flagged]

r4indeer 2y ago
Personally, I like a lot of things about NixOS. Redeploying a machine has never been easier for me as all of my config is stored in a git repo in a few .nix files. I don't need to remember what I installed or configured somewhere in /etc five years ago, I can just look in the .nix file for that machine. Everything I configure or install is synced across my desktop and laptop through imports (unless specified), which makes the experience very seamless. When something goes wrong e.g. after an upgrade, I just reboot and choose the previous generation from the boot menu. If I just want to try out a package, I can get a temporary shell where that package is available. If I don't need it after all, it just gets garbage collected. When working on a project, I can use a dev shell where everything I need to build/test that project is isolated so I don't pollute my root namespace.
- WJW 2y ago
  I like the benefits too, but honestly these are all problems that I simply don't have and the "costs" in learning the new system in the face of the terrible docs and fragmented community are quite high. I get a new computer once every few years and getting my usual programs installed is no more than a few hours work at most. I have 2 computers, one for work and one for private. Syncing installed programs is neither necessary nor particularly wanted; I don't want Steam on my laptop, nor do I want to run postgres on my private system. The only time an upgrade breaks stuff these days is when a kernel update needs the drivers to be recompiled. The command for that is stored in a file on my desktop and takes less than a minute to find, type in and wait until everything is fine again. Regarding unwanted packages and "namespace pollution", every once in a while I install a program that is used once or twice and then forgotten about. This doesn't impede my normal workflow at all. So the benefits of NixOS would be minimal for me, while the onboarding materials and documentation are pretty atrocious. The effort/reward ratio is just not there.

SuperHeavy256 2y ago

Why is every comment here negative?

Paria_Stark 2y ago
Hacker news showing its skill issues in force today I guess.
- RandomThoughts3 2y ago
  The issue has more to do with Nix poor onboarding, dreadful documentation and difficulty articulating its value proposition. I personally think that the idea of Nix is fine but the execution is not there. Look even Bazel which is built on fairly similar concepts but only targets built where it makes more sense and has a far better configuration language still struggle with adoption. It’s clear that Nix which wants to make immutable something people actually mostly never tinker will have to fight an uphill battle.
- agubelu 2y ago
  This is one of my main gripes with Nix. When something it's hard or unintuitive it's not Nix's fault, it's a skill issue on your part because you just "don't get it". It gets tiring quick.
- IshKebab 2y ago
  Saying it's a skill issue just shows lack of imagination and ambition to make it better.
  - pirates 2y ago
    Or as they might phrase it, a skill issue.
0points 2y ago
the "i dont get it" crowd found this thread
elikoga 2y ago

Aleksana 2y ago

In fact, reproducing artifacts will have more uncertain factors without a correctly designed tool chain. Accidentally introducing timestamps is just one common case, others include the order of multi-threaded builds, Haskell's GHC compiler has had this problem for a long time, and sometimes Rust seems to be affected as well. There are also some tricky situations, which are related to the features of the file system. It is misleading to say that NixOS has complete reproducibility. However, NixOS is indeed more advanced in some aspects. You can reproduce a working development environment, you can easily test the build process you will deploy to CI locally, move your favorite configurations between computers, or share certain parts between them. This is the benefits of declarative package management (or package build system). Unreproducible situations do occur during the building process of packages (derivation), but these situations usually have nothing to do with functionality, and it is easy to see where the problem is with diffscope. We have specifically tracked and dealt with these issues. At present, they are still within a relatively controllable range. See https://reproducible.nixos.org/ https://reproducible.nixos.org/ https://github.com/NixOS/nixpkgs/issues?q=sort%3Aupdated-desc+is%3Aopen+label%3A%226.topic%3A+reproducible+builds%22 https://github.com/NixOS/nixpkgs/issues?q=sort%3Aupdated-des... I would also thank @anthk for introducing people to Guix. As a late sibling to Nix (the ecosystem), Guix is cleaner in handling the basic toolchain and does a better job in full source bootstrapping, which we are working hard to learn and improve. However, Guix and Nix have the same constraints, they can only reproduce the way the system is built and composed, not the artifact itself. We both track reproducibility problems, and there are interested maintainers actively addressing these issues. See https://issues.guix.gnu.org/search?query=reproducible https://issues.guix.gnu.org/search?query=reproducible When it comes to whether you should choose NixOS (or Guix), I think you should weigh your workflow, usage habits, and learning costs. Given the significant difference in the way of thinking, we can't make it painless for people to migrate from distributions like Debian/Arch or Ubuntu to NixOS. But if you really need it, I believe you will still come one day

szundi 2y ago
Probably much better repdoducibility than embedded developers trying to maintain thet while upgrading their ubuntus thy work on.

752963e64 2y ago

[dead]

petterroea 2y ago

It is completely fine that NixOS is not reproducable for me. I personally switched(from arch) because my old setup was very finicky(eGPU + optimus on the go for iGPU) and i was sick of random updates bricking stuff. I'm becoming too old to enjoy spending an hour+ tinkering with stuff that suddenly broke. Now it is hard to imagine going back. I just enjoy that applying all my customizations is a single action. But Linderud has a good point, and I think a community like HN is rightfully interested in busting myths like this. I didn't know how the hashes worked, I haven't needed to have a relationship to them. But now I do!

1oooqooq 2y ago
how exactly does nix prevents updates from breaking your system? arch is as close to upstream as possible, so you're not updating from upstream either... are you just... not updating?
- mrslave 2y ago
  It's more like the whole upgrade is either successful, or it is not, and you are not left in an indeterminate state. E.g. A depends on B. In a large update, B updates, something unrelated fails to install and the update fails, and now A doesn't run because it wasn't upgraded and the still installed old version of A depends on the no longer available previous version of B. In NixOS, you either enter the new environment with all packages updated, or you don't. In the situation where you discover run-time - not install-time - errors, you can simply roll back to the previous set of packages. If the new packages cause a system crash, you can enter previous states from the bootloader. Now none of this magically solves the software defects themselves. But it gives you a consistent system state that can be transactionally upgraded, or reentered at any time. And then you can raise the appropriate bug tickets. Your system configuration is in a single file and the need to reconfigure different services in a particular order is gone. Also your dependencies are all nicely pinned with Flakes. This makes importing arbitrary dependencies - open-source or proprietary - a breeze. This has removed any previous appetite we had for a monorepo, which was primarily to ease access to our other libraries. It's all very nice, once you are over the not insubstantial learning curve that is.

dwb 2y ago

It's a fine point to make, but I get the feeling some people's perceptions (that Nix introductory docs are unclear) are out of date. From nixos.org, I click "Learn", "How Nix works", and it says in the first section that the hashes are "a cryptographic hash of the package’s build dependency graph". https://nixos.org/guides/how-nix-works/ https://nixos.org/guides/how-nix-works/

blacklion 2y ago

> A build is reproducible if given the same source code, build environment and build instructions It is very strange definition. To me it is tautological, as computers are deterministic and if you have same build environment you will get same results by necessity. Same bits into input - some bits out of output. Edit: formatting.

Foxboron 2y ago
> as computers are deterministic I have some bad news.
tazjin 2y ago
You're either assuming that "build environment" includes more things than the author does (it's not exactly a well-defined term), or you're not aware of the sources of non-reproducibility. It can be simple things (something includes timestamps in binaries, which can be worked around by pinning the time), and complex things (concurrent linking of binaries is done FIFO-style, and different compilation units finish at different times in different runs because of varying processor load).
- blacklion 2y ago
  assuming that "build environment" includes more things than the author does (*it's* *not* *exactly* *a* *well-defined* *term*) It is exactly my point. What is "build environment"? This definition is crucial for defining "reproducible builds" and we cannot handwave it away.
  - viraptor 2y ago
    Normally the built environment means the software part - files on the disk which are part of the build process. Your hardware, network, time, location, language, etc. shouldn't influence the output. There's an explanation at https://reproducible-builds.org/docs/definition/ https://reproducible-builds.org/docs/definition/ which is a bit vague, but I haven't heard anyone seriously disputing that one in good faith. People doing the work know what this means.

poincaredisk 2y ago

Good points in the OP. Instead of joining the distro war in the comments, I'll just note that NixOs builds may not be reproducible - because they often reuse non-reproducible building blocks, like makefiles or compilers which are also not reproducible - but NixOs maintainers spend a lot of time helping to improve the overall ecosystem and make builds more reproducible for everyone.

uecker 2y ago
make and compilers are usually reproducible. Most Debian package are reproducible, so this is perfectly feasible.
- Foxboron 2y ago
  You would think so, but after close to 10 years as a package maintainer it's clear to me that people don't know how make works when you do start doing anything else than `-j1`. The gcc compiler also fails to reproduce binaries with the LTO streamer backend if you use certain macros. This has the consequence of making cgo binaries unreproducible. As for Debian, we don't really know how many packages are reproducible. The CI they show is for fuzzing out issues, there are no system currently reproducing distributed packages.
- diffeomorphism 2y ago
  Usually they aren't because of timestamps, processor features etc. After quite a bit of work Debian is now at 96% (or 93% when varying a few more things) https://tests.reproducible-builds.org/debian/reproducible.html https://tests.reproducible-builds.org/debian/reproducible.ht...
throwayaw84330 2y ago
I don't think it's fair enough. Look for example at their quoted source: https://reproducible.nixos.org/nixos-iso-minimal-r13y/ https://reproducible.nixos.org/nixos-iso-minimal-r13y/ -- the way nix works allows for a mechanism to (almost*) check the reproducibility of the system, and it can show how reproducible it is for a complete build (99%). In contrast, other distros like Debian have to rely on fuzzing to estimate this percent. Quoting from the FAQ: > We don't currently inject randomness at the filesystem layer, but many of the reproducibility issues are being exercised already. It isn't possible to guarantee a package is reproducible, just like it isn't possible to prove software is bug-free. It is possible there is nondeterminism in a package source, waiting for some specific circumstance.

kstenerud 2y ago

I'm having a hard time thinking of a case where 100% bit-for-bit reproducible builds would be a necessary thing. As long as I can rebuild and get a system that works the same way as before, I'm happy. And I don't even need Nix to do that; there are much simpler ways to do so.

poincaredisk 2y ago
They're not necessary, but it's a nice thing to have. On a level of a single binary, you can prove that the program you have has been built from a corresponding source code (no backdoor included). Which is very important if you want to increase the security of your supply chain (most people won't compile signal from source, for example).
matrss 2y ago
> As long as I can rebuild and get a system that works the same way as before, I'm happy. Bit-for-bit identical packages is the only way to guarantee it works the same way (in the absence of differences in hardware behaviour, otherwise reproducibility can't help you either). Yes, building in a functionally identical environment will probably be good enough even if the result isn't bit-for-bit identical, but then you still have to be able to rebuild said environment, and nix gives you the tools to at least get such a repeatable environment. Outside of nix and guix I am not aware of any tool that can do the same from source. So: > And I don't even need Nix to do that; there are much simpler ways to do so. Genuinely curious, what simpler ways are you referring to?
- lostmsu 2y ago
  Not the parent, but you can have a base image + set of offline only setup scripts.
  - matrss 2y ago
    That doesn't satisfy the requirement "from source". Sure, you can build on a large binary blob that already contains everything you need, but then you are just moving the issue into the build process of that blob. Also, 99% of container image build scripts (Dockerfiles, etc.) probably don't pin an exact base image and don't avoid pulling in external resources (e.g. packages from the base image distro's repositories). I wouldn't call a system that makes it very easy to break reproducible build environments easier than just using nix to achieve that reproducibility.

pveierland 2y ago

This post does not do Nix justice, as it only references the extensional model of Nix. In the PhD of Eelco Dolstra, the extensional model (chapter 5) describes derivations with identity based on their inputs, while the intentional model (chapter 6) describes derivations with identity based on their outputs [1]. Due to the complexity of the intentional model, the extensional model has been the initially used one. The upgrade to content addressed derivations is ongoing (see blog posts via Tweag for an intro [2]). > Neither Nix or NixOS gives you these guarantees. With content addressed derivations you can guarantee that any party can recreate bit-by-bit identical copies of derivations, meaning that Nix can guarantee reproducibility. Beta testing of content addressability in Nix started in May 2021 [3]. [1] https://edolstra.github.io/pubs/phd-thesis.pdf https://edolstra.github.io/pubs/phd-thesis.pdf [2] https://www.tweag.io/blog/2020-09-10-nix-cas/ https://www.tweag.io/blog/2020-09-10-nix-cas/ [3] https://discourse.nixos.org/t/content-addressed-nix-call-for-testers/12881 https://discourse.nixos.org/t/content-addressed-nix-call-for...

Foxboron 2y ago
> With content addressed derivations you can guarantee that any party can recreate bit-by-bit identical copies of derivations It wouldn't guarantee anything. It would force you, and anyone else, to do massive rebuilds when some binary down the tree changes, or has a regression.
- pveierland 2y ago
  My writing was imprecise, I meant to communicate that it makes it possible to trust the contents of a derivation, given that you know that the hash is correct, which can be verified independently in the cases where the derivation is reproducible. Content addressability makes it easier to establish and verify trust across systems. Given the degree to which the post is referenced, I do feel that it misses out by only describing input addressed derivations and not CA.

dzarasovlloyd 2y ago

[dead]

rssoconnor 2y ago

I could be wrong (and I probably am) but I feel like the term "reproducible build" has shifted/solidified since 2006 when Dolstra's thesis was first written (which itself doesn't really use that term all that much). As evidence the first wikipedia page on "Reproducible builds" seems to have appeared in 2016, a decade after Dolstra's thesis, and even that stub from 2016 appears to prefer to use the term "Deterministic compilation". Anyhow, when the Nix project originally spoke about "reproducible builds", what I understood was meant by that term was "being able to repeat the same build steps with the same inputs". Because of the lack of determinstic compilation, this doesn't always yield bit-by-bit identical outputs, but are simply presumed to be "functionally identical". There is, of course, no reason to believe that they will necessarily be functionally identical, but it is what developers take for granted every day, and if otherwise would be considered a bug somewhere in the package. With Nix, when some software "doesn't work for me, but works for you", we can indeed recursively compare the nix derivation files locating and eliminating potential differences, a debugging process I have used on occasion. I agree that "reproducible builds" now means something different, but that isn't exactly the fault of Nix advocates. I guess a new term for "being able to repeat the same build steps with the same inputs" is needed.

pabs3 2y ago
"Repeatable builds" seems like what you want?

pshirshov 2y ago

Yes, it isn't. But they did a lot to eradicate entropy in the builds and I believe they are able to reproduce base system images bit by bit. Another attempt in that area is stal/ix, which is much more reproducible than nix, its store is content-addressable: https://stal-ix.github.io/ https://stal-ix.github.io/

Koshkin 2y ago
> Yes, it isn't. It took me some time to get used to the way native speakers of English express agreement or disagreement with a negative statement. Agree: “No, it isn’t.” Disagree: “Yes, it is.”
- pshirshov 2y ago
  Thank you for your valuable comment.

keeganpoppen 2y ago

is this not the retcon of the century? hasn't reproducibility / consistency been an alleged selling point of nixos for a long time? it sure as hell isn't the ergonomics of the nix language, nor that of the ecosystem...

xyzsparetimexyz 2y ago
maybe