8 ms·

Is NixOS truly reproducible?

248 points by pabs3 2y ago

opan 2y ago
Although I'm aware many distros care somewhat about reproducible builds these days, I tend to associate it primarily with Guix System, I never really considered it a feature of NixOS, having used both (though spent much more time on Guix System now). For the record, even in the land of Guix I semi-regularly see reports on the bug-guix mailing list that some package isn't reproducible. It seems to get treated as a bug and fixed then. With that in mind, and personally considering Guix kind of the flagship of these efforts, it doesn't surprise me if anyone else doesn't have perfectly reproducible builds yet either. Especially Nix with the huge number of things in nixpkgs. It's probably easier for stuff to fall through the cracks with that many packages to manage.
jchw 2y ago
I think this debate comes down to exactly what "reproducible" means. Nix doesn't give bit-exact reproducibility, but it does give reproducible environments, by ensuring that the inputs are always bit-exact. It is closer to being fully reproducible than most other build systems (including Bazel) -- but because it can only reasonably ensure that the inputs are exact, it's still necessary for the build processes themselves to be fully deterministic to get end-to-end bit-exactness. Nix on its own doesn't fully resolve supply chain concerns about binaries, but it can provide answers to a myriad of other problems. I think most people like Nix reproducibility, and it is marketed as such, for the sake of development: life is much easier when you know for sure you have the exact same version of each dependency, in the exact same configuration. A build on one machine may not be bit-exact to a build on another machine, but it will be exactly the same source code all the way down. The quest to get every build process to be deterministic is definitely a bigger problem and it will never be solved for all of Nixpkgs. NixOS does have a reproducibility project[1], and some non-trivial amount of NixOS actually is properly reproducible, but the observation that Nixpkgs is too vast is definitely spot-on, especially because in most cases the real issues lie upstream. (and carrying patches for reproducibility is possible, but it adds even more maintainer burden.) [1]: https://reproducible.nixos.org/ https://reproducible.nixos.org/
- sa46 2y ago
  > It is closer to being fully reproducible than most other build systems (including Bazel). How so? Bazel produces the same results for the same inputs.
  - jchw 2y ago
    Bazel doesn't guarantee bit-exact outputs, but also Bazel doesn't guarantee pure builds. It does have a sandbox that prevents some impurities, but for example it doesn't prevent things from going out to the network, or even accessing files from anywhere in the filesystem, if you use absolute paths. (Although, on Linux at least, Bazel does prevent you from modifying files outside of the sandbox directory.) The Nix sandbox does completely obscure the host filesystem and limit network access to processes that can produce a bit-exact output only. (Bazel also obviously uses the system compilers and headers. Nix does not.)
    - dijit 2y ago
      Uh, Either my understanding of Bazel is wrong, or everything you wrote is wrong. Bazel absolutely prevents network access and filesystem access (reads) from builds. (only permitting explicit network includes from the WORKSPACE file, and access to files explicitly depended on in the BUILD files). Maybe you can write some “rules_” for languages that violate this, but it is designed purposely to be hermetic and bit-perfect reproducible. EDIT: From the FAQ[0]: > Will Bazel make my builds reproducible automatically? > For Java and C++ binaries, yes, assuming you do not change the toolchain. The issues with Docker's style of "reproducible" (meaning.. consistent environment; are also outlined in the same FAQ[1] > Doesn’t Docker solve the reproducibility problems? > Docker does not address reproducibility with regard to changes in the source code. Running Make with an imperfectly written Makefile inside a Docker container can still yield unpredictable results. [0]: https://bazel.build/about/faq#will_bazel_make_my_builds_reproducible_automatically https://bazel.build/about/faq#will_bazel_make_my_builds_repr... [1]: https://bazel.build/about/faq#doesn’t_docker_solve_the_reproducibility_problems https://bazel.build/about/faq#doesn’t_docker_solve_the_repro...
0x457 2y ago
IIRC any package that uses Java isn't reproducible because system time and fixing it to epoch permamently causes issues in some application builds. * there're maven and gradle plugins to make builds reproducible.
- yjftsjthsd-h 2y ago
  Can you force it to some time other than 0? Ex. I've seen some packages force timestamps to the git commit timestamp, which is nice but still fixed.
  - Cyph0n 2y ago
    This is an approach you can use when building Docker images in Nix flakes: https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0407f7f595ca205a4f6/flake.nix#L77 https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0...
- layer8 2y ago
  Can you elaborate on the root causes?
- arjvik 2y ago
  What issues? I'm not aware of any Java build process that checks timestamps.
  - paulddraper 2y ago
    JARs are archives, and archives have timestamps. You can remove those with some extra work.
    - gf000 2y ago
      Just add a post-process step that sets the output artifacts' timestamps (including its content)? Wouldn't that work?
      - 2y ago
vlovich123 2y ago
> Our most important finding is that the reproducibility rate in nixpkgs has increased steadily from 69% in 2017 to about 91% in April 2023. The high reproducibility rate in our most recent revision is quite impressive, given both the size of the package set and the absence of systematic monitoring in nixpkgs. We knew that it was possible to achieve very good reproducibility rate in smaller package sets like Debian, but this shows that achieving very high bitwise reproducibility is possible at scale, something that was believed impossible by practitioners4 I think people in this thread are focusing on the wrong thing. Sure, not all packages are reproducible, but the project is systematically increasing the percentage of projects that are reproducible while ALSO adding new projects and demonstrating conclusively that what was considered infeasible is actually readily achievable. > The interesting aspect of these causes is that they show that even if nixpkgs already achieves great reproducibility rates, there still exists some low hanging fruits towards improving reproducibility that could be tackled by the Nix community and the whole FOSS ecosystem. This work is helpful I think for the community to tackle the sources of unreproducible builds to push the percentage up even further. I think it also highlights the need for automation to validate that there aren't systematic regressions or regressions in particularly popular packages (doing individual regressions for all packages is a futile effort unless a lot of people volunteer to be part of a distributed check effort).
- sublimefire 2y ago
  Some interesting related stats from Debian also show good reproducibility progress https://tests.reproducible-builds.org/debian/reproducible.html https://tests.reproducible-builds.org/debian/reproducible.ht...
- mikepurvis 2y ago
  What's even crazier is that Nix builds are this reproducible for free. Like, joe random developer can: nix build nixpkgs#vim nix build nixpkgs#vim --rebuild The first invocation will substitute binaries, and the second will rebuild those locally and validate the bit for bit reproducibility of the results. In Debian there is significant ceremony and special tools/wrappers required to set up the reproducible environment, so no one would bother to use it unless they were specifically working on the https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds initiative.
IHLayman 2y ago
How this article discusses reproducibility in NixOS and declines to even mention the intensional model or efforts to implement it are surprising to me, since it appears they have done a lot of research into the matter. If you don’t know, the intensional model is an alternative way to structure the NixOS store so that components are content-addressable (store hash is based on the targets) as opposed to being addressed based on the build instructions and dependencies. IIUC, the entire purpose of the intensional model is to make Nix stores shareable so that you could just depend on Cachix and such without the worry of a supply-chain attack. This approach was an entire chapter in the Nix thesis paper (chapter 6) and has been worked on recently (see https://github.com/NixOS/rfcs/pull/62 https://github.com/NixOS/rfcs/pull/62 and https://github.com/NixOS/rfcs/pull/17 https://github.com/NixOS/rfcs/pull/17 for current progress).
- mikepurvis 2y ago
  You still need to trust something though. It's just that instead of trusting the signing of the binaries themselves, you trust the metadata that maps input hashes (computed locally) to content hashes (unknown until a build occurs). The real win with content addressing in Nix is being able to proactively dedupe the store and also cut off rebuild cascades, like if you have dependency chain A -> B -> C, and A changes, but you can demonstrate that the result of B is identical, then there's no longer a need to also rebuild C. With input addressing, you have to rebuild everything downtree of A when it changes, no exceptions.
  - im3w1l 2y ago
    Is B remaining the same something that happens often enough for it to matter?
    - mikepurvis 2y ago
      I haven’t studied it, but yes I would imagine so. For example if a python build macro changes but the sphinx output remains unchanged, you get out of rebuilding thousands of packages that throw off sphinx docs as part of their build.
SilentM68 2y ago
In my case, I define, "reproducible," to mean, "immutable." After a few days of testing, I broke NixOS. Simple test was swapping different Desktop Environments, eventually broke Nix, thus I'm not at the point where I'd agree with Nix being truly reproducible, at least not in that context :(
- tmnvdb 2y ago
  Those things are not the same though. Reproducible just means it will break again if you configure your system in the same way.
- bsimpson 2y ago
  One problem is that the applications themselves are impure. Just running KDE litters a bunch of dotfiles into your user folder, even for settings you didn't adjust. This is true for many applications. If you had an empty home folder and passively tried a handful of desktops, you'd no longer have an empty home folder. Hopefully your environment is resilient to clutter being leaked into your home folder, but if your filesystem isn't truly immutable, rolling back to a particular Nix config might not get you the exact state your system was in when you first built that. There's a project that wipes all local changes when you restart your machine, with the goal of making Nix systems more reproducible. I think it's called Impermanence.
  - alfiedotwtf 2y ago
    I do all my stuff in temporary docker containers, and when I’m done, the container gets blown away. If the point of Nix is to keep a filesystem immutable as long as every app sticks to certain rules, is it actually the right till for the job? Sorry… I actually don’t know much about Nix given I’ve been using VMs and now containers for over a decade, so just trying to understand the problem that nix actually solves
    - alfiedotwtf 2y ago
      Just chatgpt’d it. I see… what I’m thinking about more was NixOS. Ok, I think I see how it could work, but I’d apps aren’t really isolated, then couldn’t a system still get to a broken if it spills out? At the moment I’m using Ansible for the host and Docker for guests, but I see NixOS as combining these two lasers so everything just runs on the host? Is that fair to say how NixOS works? If so and I have it wrong, maybe I should check it out and I’ve been sleeping on Nix all this time
jf 2y ago
Aside from this being a great article with lots of interesting details, it's also a rare example of a headline that does NOT follow "Betteridge's law of headlines"
- Ericson2314 2y ago
  I got scared and then I was unexpected releaved! (-- A Nix maintainer)
advisedwang 2y ago
Is anyone actually implementing the concept of checking hashes with trusted builders? This is all wasted effort if that isn't needed. I've seen it pointed out (by mjg59, perhaps?) that if you have a trusted builder, why don't you just use their build? That seems to be the actual model in practice. Reproducibility seems only to be useful if you have a pool of mostly trustworthy builders and somehow want to build a consensus out of that. Which I suppose is useful for a distributed community but does seem like a stretch for the amount of work going in to reproducible builds.
- c0balt 2y ago
  > is anyone actually implementing [..] Not for NixOS as far as I can tell. You only have this for source derivations where a hash is (usually in a PR) submitted and must be reproducable in CI. This specific example however has the problem that linkrot can be hard to detect unless you regularly check upstream sources.
  - mschwaig 2y ago
    You also couldn't feasibly do that for derivations that actually build packages, instead of fixed output derivations only, because if you the update the package set to include a newer version of the compiler, which would often produce a different output, in addition to having to rebuild everything, you would have to update all of the affected hashes. What you should be able to do in the future with a system like nix plus a few changes is use nix as a common underlying mechanism for precisely describing build steps, and then use whatever policy you like to determine who you trust. One policy can be about having an attestation for every build step, another one can be about two different builders being in agreement about the output of a specific build step. That way you can construct a policy that expresses reproducibility, and reproducibility strengthens any other verification mechanism you have, because it makes it so that you can aggregate evidence from different sources. and then have different build hosts
    - c0balt 2y ago
      > You also couldn't feasibly do that for derivations that actually build packages, [..] you would have to update all of the affected hashes. You can actually, changes to stdenv are possible and "just" a lot of work. You will regularly see them between releases or on unstable and they cause mass rebuilds. This doesn't just affect a compiler but also all stdenv tooling as these changes tend to cause rebuilds across nixpkgs. This would be verifiable but it obviously multiples the amount of compute spent. Hint: If you look at PRs for nixpkgs you will notice labels indicating the required amounts of rebuilds, e. G., rebuild-darwin:1-10. See for example https://github.com/NixOS/nixpkgs/pull/377186 https://github.com/NixOS/nixpkgs/pull/377186 with the rebuild-darwin:5001+ label.
jonhohle 2y ago
I work on a matching decomp project that has tooling to recompile C into binaries matching a 28 year old game. In the final binaries created by compiled with gcc 2.6.3 and assembled with a custom assembler there appear to be unused, uninitialized data that is whatever was in RAM when whoever compiled the game created the release build. Since the goal is a matching (reproducible) binary, we have tools to restore that random data at specific offsets. Fortunately our targets are fixed
- fngjdflmdflg 2y ago
  What even causes this to happen? ie. what dev tool would add random data from RAM to a binary? Is this likely a bug or is there some reason for it like needing to reach a specific file size somewhere?
  - dezgeg 2y ago
    By accidentally writing out uninitialized memory contents to the file with the game still working. It's even worse in DOS era where there is no memory protection so uninitialized memory can contain data used by other processes, so for example parts of source code can get leaked that way. There's a big list of those in https://tcrf.net/Category:Games_with_uncompiled_source_code https://tcrf.net/Category:Games_with_uncompiled_source_code
    - jonhohle 2y ago
      Yeah, this was originally all DOS and Windows 3.1 utilities for writing programs that would run on MIPS. The data is small enough that it isn’t relevant, just not reproducible through standard build tools because it was never meant to be bitwise reproducible.
  - aidenn0 2y ago
    Simply calling write() on a C struct can do that, if there is any padding in the struct. Then, of course, there are bugs.
- tuananh 2y ago
CamouflagedKiwi 2y ago
> Our most important finding is that the reproducibility rate in nixpkgs has increased steadily from 69% in 2017 to about 91% in April 2023. The high reproducibility rate in our most recent revision is quite impressive, given both the size of the package set and the absence of systematic monitoring in nixpkgs. That's one way to read the statistic. Another way you could read the graph is that they still have about the same number (~5k) of non-reproducible builds, which has been pretty constant over the time period. Adding a bunch of easily reproducible additional builds maybe doesn't make me believe it's solving the original issues. > We knew that it was possible to achieve very good reproducibility rate in smaller package sets like Debian, but this shows that achieving very high bitwise reproducibility is possible at scale, something that was believed impossible by practitioners. Maybe I miss some nuance here, but why is Debian written off as being so much smaller scale? The top end of the graph here suggests a bit over 70k packages, Debian apparently also currently has 74k packages available (https://www.debian.org/doc/manuals/debian-reference/ch02.en.html https://www.debian.org/doc/manuals/debian-reference/ch02.en....); I guess there's maybe a bit of time lag here but I'm not sure that is enough to claim Debian is somehow not "at scale".
- dartos 2y ago
  Are they mostly the same 5k packages as 2017? That seems to be the crux of it.
- vlovich123 2y ago
  According to https://tests.reproducible-builds.org/debian/reproducible.html https://tests.reproducible-builds.org/debian/reproducible.ht... (which is what the article links to btw) there are ~37k packages tracked for reproducible builds which is ~2.7x smaller than Nix's 100k packages.
- gf000 2y ago
  This is not really a Nix-issue to begin with. It's a bit like asking what percentage of Nix-packaged programs have Hungarian translation -- if Nix packages some more stuff the rate might decrease, but it's not Nix's task to add that to the programs that lack it. Nix does everything in its power to provide a sandboxed environment in which builds can happen. Given the way hardware works, there are still sources of non-determinism that are impossible to prevent, most importantly timing. Most programs depend on it, even compilers, and extra care should be taken by them to change that. The only way to prevent it would be to go full-on CPU and OS emulation, but that would be prohibitively expensive.
wg0 2y ago
Let me guess... No?
rssoconnor 2y ago
I'll repeat my comment from last time this came up.[0] 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. [0]https://news.ycombinator.com/item?id=41953155 https://news.ycombinator.com/item?id=41953155
- steve-chavez 2y ago
  I think you want to link to https://news.ycombinator.com/item?id=41956044 https://news.ycombinator.com/item?id=41956044.
- naasking 2y ago
  > 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. Yes, the only possible differences result from either a compiler bug or a program bug that depends on undefined behaviour, in which case "anything can happen" as they say. As others have noted, parallel compilation depends on non-deterministic thread-scheduling, so this non-determinism can't be solved unless you restrict all compilation to be single-threaded. It's still not the only possible source of non-determinism though.
TacticalCoder 2y ago
[dead]
mhh__ 2y ago
I guess this is a tangent, but Nix to me feels like the right idea with the wrong abstraction. I can't explain / it would take a serious bit of genius to come up with an alternative worth switching to. Has anyone done any better?
- Ericson2314 2y ago
  You can use the low level stuff without the language to forge your own journey. https://github.com/NixOS/nix/blob/master/doc/manual/source/store/drv.md https://github.com/NixOS/nix/blob/master/doc/manual/source/s... I am working on the docs for this as we speak.
- zanecodes 2y ago
  I agree, I feel like Nix is kind of a hack to work around the fact that many build systems (especially for C and C++) aren't pure by default, so it tries to wrap them in a sandboxed environment that eliminates as many opportunities for impurity as it reasonably can. It's not solving the underlying problem: that build systems are often impure and sometimes nondeterministic. It also tries to solve a bunch of adjacent problems, like providing a common interface for building many different types of package, providing a common configuration language for builds as well as system services and user applications in the case of NixOS and home-manager, and providing end-user CLI tools to manage the packages built with it. It's trying to be a build wrapper, a package manager, a package repository, a configuration language, and more.
  - gf000 2y ago
    > It's not solving the underlying problem: that build systems are often impure and sometimes nondeterministic It's not Nix's job, imo. Those compilers should be fixed. And all the other "features" come for free from Nix's fundamental abstractions, I don't feel it would overstep its boundaries anywhere.
  - throwawayqqq11 2y ago
    Purity becomes a hard goal when ever you hit the real world at build or runtime. By definition, you have to bridge 2 domains. Imagine constant time compute and constant memory constrains, required in cryptography, being applied to the nix ecosystem. Yes, this is an artifical example but it shows that purity is harder to define and come by, then some people think. Maybe someday these constraints actually do apply to nix goal of reproducibility. With ever changing hardware that purity is a moving target so nix imo will always be an approach to purity and bundling so much tooling is to be expected. Still, you can legitimately call it a hack :)
tuananh 2y ago
so looks like reproducibility rate of nixos is not that high, roughly similar with debian? https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds
- dpc_01234 2y ago
  At this point almost all major package managers try to not introduce any non-reproducibility, so it comes down to package itself building deterministically. Nix just have an architectural sandboxing and isolation that enforces is maybe a bit better. But the moment e.g. ArchLinux devs fix determinism and upstream it in certain package, it will become deterministic in NixOS and others, and vice versa, so there is not going to be a lot of differences between distros at this point. Everyone agrees that deterministic builds are a good thing.
GeezNuts 2y ago
Certainly not all packages are reproducible, but the project is systematically increasing the percentage of projects that are reproducible while ALSO adding new projects and demonstrating conclusively that what was considered infeasible is actually very readily achievable.
rednafi 2y ago
Is it somewhat reproducible? Yes. But what did it cost? Usability.
__MatrixMan__ 2y ago
> there exist no reproducibility monitoring at the scale of the Nix package set (nixpkgs) I think it would be fairly easy to do this monitoring with a bit of community participation. At least I'd enable telemetry ¯\_(ツ)_/¯. By default the pkz57 in /nix/store/pkz57...-nushell-0.97.1 is a hash of the build inputs for that package. If you hash the contents of that dir, you get an identifier for the build output. If we then make a big list of such pairs as built by different people on different machines at different times, and capture the frequency of each pair we'll either see this: /nix/store/pkz5..., sha256:0drrxa..., 121 users or we'll see this: /nix/store/pkz5..., sha256:0drrxa..., 100 users /nix/store/pkz5..., sha256:gvpbk5..., 20 users /nix/store/pkz5..., sha256:1fwwfe..., 1 user The former being an indicator that the build is reproducible, and the latter giving hints about why not (supposing these users are willing to share a bit more about the circumstances of that build). I'd call it a "build chromatograph". I expect that knowing whether you're one of the 100 or the odd-man-out could be relevant for certain scenarios.
- gf000 2y ago
  I'm not sure the "distribution" would be all that helpful. A single compiler that does some parallel work and collect the results of that work in a list in order of completion (and similar) are probably the most common cause of non-determinism. Given that, your chromatograph would be mostly "determined" by the source code's peculiarities, instead of the offending compiler itself. (E.g. I have n classes a compiler would process in parallel, so given a single point of timing non-determinism n! different combinations could possibly exist (assuming they all cause a different outputs). The only information I could conclude from such a distribution is that there is a common sequence of completing tasks). But your idea is cool, and simply reporting back non-matching local builds would be helpful (I believe the binary property of whether a different output could be built is the only relevant fact) -- also, if we were to mark a package as non-reproducible, we could recursively mark everything else that has it as a (transitive) input.
  - __MatrixMan__ 2y ago
    I think there are only a few cases where it would be helpful: - one hash to rule them all, perfectly reproducible - a big mess, consider avoiding it - just two or four cohorts, package maintainer may want to investigate - everbody agrees on the output hash except for you, something local is compromized I don't anticipiate peering into the mess and coming up with many useful conclusions. > if we were to mark a package as non-reproducible, we could recursively mark everything else that has it as a (transitive) input. I like that idea, to sort of carve out a space within the already-pretty-reliable nixpkgs which can be expected upon to be perfectly reproducible. I'd strive to get my packages included in that set, and to select my dependencies from it.
ninetyninenine 2y ago
>As part of my PhD, and under the supervision of Théo Zimmermann and Stefano Zacchiroli, I have empirically studied bitwise build reproducibility in nixpkgs over a time period of 6 years. Why spend only 6 years on the most interesting topic of all mankind? I spent 10 years analyzing this.
lrvick 2y ago
I would note that stagex is 100% reproducible, and full source bootstrapped. Every artifact is reproduced and signed by multiple maintainers on independently controlled hardware and this has been the case since our first release around this time last year. https://codeberg.org/stagex/stagex https://codeberg.org/stagex/stagex
est31 2y ago
Note that NixOS's "build" step often actually doesn't do any compilation. Often it's just downloading a binary from github releases and runs NixOS's specific binary tools on it to make it look for libraries in the right places. So if that process is reproducible, it's a different statement from a Debian package being reproducible, which requires build inputs in the preferred form of modification (source code).
- IngoBlechschmid 2y ago
  You are right, but I would not agree with this appearing "often". I get the impression that the nixpkgs community tries quite hard to truly compile from source even quite complex projects like Firefox and LibreOffice.
- max-privatevoid 2y ago
  Completely false. Building from the actual source code is strongly preferred and usually easier than patching a binary that wasn't built for such an environment.
pmarreck 2y ago
It's massively closer than any other solution in this regard (nods to other Nix-inspired distros like Guix, Lix, etc.) Honestly, I believe every software developer owes it to themselves to read the original Nix paper. It's quite digestible and lays out a lot of what it brings to the table. I came away from it wondering why it took so long to realize it... which is a property I've found true of every new important discovery. https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf If you want, you can even ask an LLM to sum up its main points for you. Or to sell it to you. =) https://chatgpt.com/share/67ae1a08-7354-8004-8200-e956cb6b59db https://chatgpt.com/share/67ae1a08-7354-8004-8200-e956cb6b59... I would like to say one thing about using Docker to "solve" this problem though: Once you think of builds in terms of functions, you realize that a Docker image is basically just the cached artifacts of a build that "just so happened" to work correctly. Consider a function that only occasionally produces a correct value: A Docker image is one of those values.
- tlavoie 2y ago
  Thanks for the paper, will check it out! (Still skeptical that we should encourage LLM summarization though, suspect people would gain more and actually learn things from reading papers.)
  - pmarreck 2y ago
    By all means, read the paper then! It's quite readable, and one of the best papers in software development IMHO
beebaween 2y ago
I've genuinely never really understood the appeal of Nix. I even attempted to use this to build and "maintain" the machines we used at an offsite factory and even then with just a basic electron app, a python installation and very basic mac configs Nix proved to be a complete nightmare.

248 points by pabs3 2y ago

opan 2y ago

Although I'm aware many distros care somewhat about reproducible builds these days, I tend to associate it primarily with Guix System, I never really considered it a feature of NixOS, having used both (though spent much more time on Guix System now). For the record, even in the land of Guix I semi-regularly see reports on the bug-guix mailing list that some package isn't reproducible. It seems to get treated as a bug and fixed then. With that in mind, and personally considering Guix kind of the flagship of these efforts, it doesn't surprise me if anyone else doesn't have perfectly reproducible builds yet either. Especially Nix with the huge number of things in nixpkgs. It's probably easier for stuff to fall through the cracks with that many packages to manage.

jchw 2y ago

I think this debate comes down to exactly what "reproducible" means. Nix doesn't give bit-exact reproducibility, but it does give reproducible environments, by ensuring that the inputs are always bit-exact. It is closer to being fully reproducible than most other build systems (including Bazel) -- but because it can only reasonably ensure that the inputs are exact, it's still necessary for the build processes themselves to be fully deterministic to get end-to-end bit-exactness. Nix on its own doesn't fully resolve supply chain concerns about binaries, but it can provide answers to a myriad of other problems. I think most people like Nix reproducibility, and it is marketed as such, for the sake of development: life is much easier when you know for sure you have the exact same version of each dependency, in the exact same configuration. A build on one machine may not be bit-exact to a build on another machine, but it will be exactly the same source code all the way down. The quest to get every build process to be deterministic is definitely a bigger problem and it will never be solved for all of Nixpkgs. NixOS does have a reproducibility project[1], and some non-trivial amount of NixOS actually is properly reproducible, but the observation that Nixpkgs is too vast is definitely spot-on, especially because in most cases the real issues lie upstream. (and carrying patches for reproducibility is possible, but it adds even more maintainer burden.) [1]: https://reproducible.nixos.org/ https://reproducible.nixos.org/

sa46 2y ago
> It is closer to being fully reproducible than most other build systems (including Bazel). How so? Bazel produces the same results for the same inputs.
- jchw 2y ago
  Bazel doesn't guarantee bit-exact outputs, but also Bazel doesn't guarantee pure builds. It does have a sandbox that prevents some impurities, but for example it doesn't prevent things from going out to the network, or even accessing files from anywhere in the filesystem, if you use absolute paths. (Although, on Linux at least, Bazel does prevent you from modifying files outside of the sandbox directory.) The Nix sandbox does completely obscure the host filesystem and limit network access to processes that can produce a bit-exact output only. (Bazel also obviously uses the system compilers and headers. Nix does not.)
  - dijit 2y ago
    Uh, Either my understanding of Bazel is wrong, or everything you wrote is wrong. Bazel absolutely prevents network access and filesystem access (reads) from builds. (only permitting explicit network includes from the WORKSPACE file, and access to files explicitly depended on in the BUILD files). Maybe you can write some “rules_” for languages that violate this, but it is designed purposely to be hermetic and bit-perfect reproducible. EDIT: From the FAQ[0]: > Will Bazel make my builds reproducible automatically? > For Java and C++ binaries, yes, assuming you do not change the toolchain. The issues with Docker's style of "reproducible" (meaning.. consistent environment; are also outlined in the same FAQ[1] > Doesn’t Docker solve the reproducibility problems? > Docker does not address reproducibility with regard to changes in the source code. Running Make with an imperfectly written Makefile inside a Docker container can still yield unpredictable results. [0]: https://bazel.build/about/faq#will_bazel_make_my_builds_reproducible_automatically https://bazel.build/about/faq#will_bazel_make_my_builds_repr... [1]: https://bazel.build/about/faq#doesn’t_docker_solve_the_reproducibility_problems https://bazel.build/about/faq#doesn’t_docker_solve_the_repro...

0x457 2y ago

IIRC any package that uses Java isn't reproducible because system time and fixing it to epoch permamently causes issues in some application builds. * there're maven and gradle plugins to make builds reproducible.

yjftsjthsd-h 2y ago
Can you force it to some time other than 0? Ex. I've seen some packages force timestamps to the git commit timestamp, which is nice but still fixed.
- Cyph0n 2y ago
  This is an approach you can use when building Docker images in Nix flakes: https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0407f7f595ca205a4f6/flake.nix#L77 https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0...
layer8 2y ago
Can you elaborate on the root causes?
arjvik 2y ago
What issues? I'm not aware of any Java build process that checks timestamps.
- paulddraper 2y ago
  JARs are archives, and archives have timestamps. You can remove those with some extra work.
  - gf000 2y ago
    Just add a post-process step that sets the output artifacts' timestamps (including its content)? Wouldn't that work?
    - 2y ago

vlovich123 2y ago

> Our most important finding is that the reproducibility rate in nixpkgs has increased steadily from 69% in 2017 to about 91% in April 2023. The high reproducibility rate in our most recent revision is quite impressive, given both the size of the package set and the absence of systematic monitoring in nixpkgs. We knew that it was possible to achieve very good reproducibility rate in smaller package sets like Debian, but this shows that achieving very high bitwise reproducibility is possible at scale, something that was believed impossible by practitioners4 I think people in this thread are focusing on the wrong thing. Sure, not all packages are reproducible, but the project is systematically increasing the percentage of projects that are reproducible while ALSO adding new projects and demonstrating conclusively that what was considered infeasible is actually readily achievable. > The interesting aspect of these causes is that they show that even if nixpkgs already achieves great reproducibility rates, there still exists some low hanging fruits towards improving reproducibility that could be tackled by the Nix community and the whole FOSS ecosystem. This work is helpful I think for the community to tackle the sources of unreproducible builds to push the percentage up even further. I think it also highlights the need for automation to validate that there aren't systematic regressions or regressions in particularly popular packages (doing individual regressions for all packages is a futile effort unless a lot of people volunteer to be part of a distributed check effort).

sublimefire 2y ago
Some interesting related stats from Debian also show good reproducibility progress https://tests.reproducible-builds.org/debian/reproducible.html https://tests.reproducible-builds.org/debian/reproducible.ht...
mikepurvis 2y ago
What's even crazier is that Nix builds are this reproducible for free. Like, joe random developer can: nix build nixpkgs#vim nix build nixpkgs#vim --rebuild The first invocation will substitute binaries, and the second will rebuild those locally and validate the bit for bit reproducibility of the results. In Debian there is significant ceremony and special tools/wrappers required to set up the reproducible environment, so no one would bother to use it unless they were specifically working on the https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds initiative.

IHLayman 2y ago

How this article discusses reproducibility in NixOS and declines to even mention the intensional model or efforts to implement it are surprising to me, since it appears they have done a lot of research into the matter. If you don’t know, the intensional model is an alternative way to structure the NixOS store so that components are content-addressable (store hash is based on the targets) as opposed to being addressed based on the build instructions and dependencies. IIUC, the entire purpose of the intensional model is to make Nix stores shareable so that you could just depend on Cachix and such without the worry of a supply-chain attack. This approach was an entire chapter in the Nix thesis paper (chapter 6) and has been worked on recently (see https://github.com/NixOS/rfcs/pull/62 https://github.com/NixOS/rfcs/pull/62 and https://github.com/NixOS/rfcs/pull/17 https://github.com/NixOS/rfcs/pull/17 for current progress).

mikepurvis 2y ago
You still need to trust something though. It's just that instead of trusting the signing of the binaries themselves, you trust the metadata that maps input hashes (computed locally) to content hashes (unknown until a build occurs). The real win with content addressing in Nix is being able to proactively dedupe the store and also cut off rebuild cascades, like if you have dependency chain A -> B -> C, and A changes, but you can demonstrate that the result of B is identical, then there's no longer a need to also rebuild C. With input addressing, you have to rebuild everything downtree of A when it changes, no exceptions.
- im3w1l 2y ago
  Is B remaining the same something that happens often enough for it to matter?
  - mikepurvis 2y ago
    I haven’t studied it, but yes I would imagine so. For example if a python build macro changes but the sphinx output remains unchanged, you get out of rebuilding thousands of packages that throw off sphinx docs as part of their build.

SilentM68 2y ago

In my case, I define, "reproducible," to mean, "immutable." After a few days of testing, I broke NixOS. Simple test was swapping different Desktop Environments, eventually broke Nix, thus I'm not at the point where I'd agree with Nix being truly reproducible, at least not in that context :(

tmnvdb 2y ago
Those things are not the same though. Reproducible just means it will break again if you configure your system in the same way.
bsimpson 2y ago
One problem is that the applications themselves are impure. Just running KDE litters a bunch of dotfiles into your user folder, even for settings you didn't adjust. This is true for many applications. If you had an empty home folder and passively tried a handful of desktops, you'd no longer have an empty home folder. Hopefully your environment is resilient to clutter being leaked into your home folder, but if your filesystem isn't truly immutable, rolling back to a particular Nix config might not get you the exact state your system was in when you first built that. There's a project that wipes all local changes when you restart your machine, with the goal of making Nix systems more reproducible. I think it's called Impermanence.
- alfiedotwtf 2y ago
  I do all my stuff in temporary docker containers, and when I’m done, the container gets blown away. If the point of Nix is to keep a filesystem immutable as long as every app sticks to certain rules, is it actually the right till for the job? Sorry… I actually don’t know much about Nix given I’ve been using VMs and now containers for over a decade, so just trying to understand the problem that nix actually solves
  - alfiedotwtf 2y ago
    Just chatgpt’d it. I see… what I’m thinking about more was NixOS. Ok, I think I see how it could work, but I’d apps aren’t really isolated, then couldn’t a system still get to a broken if it spills out? At the moment I’m using Ansible for the host and Docker for guests, but I see NixOS as combining these two lasers so everything just runs on the host? Is that fair to say how NixOS works? If so and I have it wrong, maybe I should check it out and I’ve been sleeping on Nix all this time

jf 2y ago

Aside from this being a great article with lots of interesting details, it's also a rare example of a headline that does NOT follow "Betteridge's law of headlines"

Ericson2314 2y ago
I got scared and then I was unexpected releaved! (-- A Nix maintainer)

advisedwang 2y ago

Is anyone actually implementing the concept of checking hashes with trusted builders? This is all wasted effort if that isn't needed. I've seen it pointed out (by mjg59, perhaps?) that if you have a trusted builder, why don't you just use their build? That seems to be the actual model in practice. Reproducibility seems only to be useful if you have a pool of mostly trustworthy builders and somehow want to build a consensus out of that. Which I suppose is useful for a distributed community but does seem like a stretch for the amount of work going in to reproducible builds.

c0balt 2y ago
> is anyone actually implementing [..] Not for NixOS as far as I can tell. You only have this for source derivations where a hash is (usually in a PR) submitted and must be reproducable in CI. This specific example however has the problem that linkrot can be hard to detect unless you regularly check upstream sources.
- mschwaig 2y ago
  You also couldn't feasibly do that for derivations that actually build packages, instead of fixed output derivations only, because if you the update the package set to include a newer version of the compiler, which would often produce a different output, in addition to having to rebuild everything, you would have to update all of the affected hashes. What you should be able to do in the future with a system like nix plus a few changes is use nix as a common underlying mechanism for precisely describing build steps, and then use whatever policy you like to determine who you trust. One policy can be about having an attestation for every build step, another one can be about two different builders being in agreement about the output of a specific build step. That way you can construct a policy that expresses reproducibility, and reproducibility strengthens any other verification mechanism you have, because it makes it so that you can aggregate evidence from different sources. and then have different build hosts
  - c0balt 2y ago
    > You also couldn't feasibly do that for derivations that actually build packages, [..] you would have to update all of the affected hashes. You can actually, changes to stdenv are possible and "just" a lot of work. You will regularly see them between releases or on unstable and they cause mass rebuilds. This doesn't just affect a compiler but also all stdenv tooling as these changes tend to cause rebuilds across nixpkgs. This would be verifiable but it obviously multiples the amount of compute spent. Hint: If you look at PRs for nixpkgs you will notice labels indicating the required amounts of rebuilds, e. G., rebuild-darwin:1-10. See for example https://github.com/NixOS/nixpkgs/pull/377186 https://github.com/NixOS/nixpkgs/pull/377186 with the rebuild-darwin:5001+ label.

jonhohle 2y ago

I work on a matching decomp project that has tooling to recompile C into binaries matching a 28 year old game. In the final binaries created by compiled with gcc 2.6.3 and assembled with a custom assembler there appear to be unused, uninitialized data that is whatever was in RAM when whoever compiled the game created the release build. Since the goal is a matching (reproducible) binary, we have tools to restore that random data at specific offsets. Fortunately our targets are fixed

fngjdflmdflg 2y ago
What even causes this to happen? ie. what dev tool would add random data from RAM to a binary? Is this likely a bug or is there some reason for it like needing to reach a specific file size somewhere?
- dezgeg 2y ago
  By accidentally writing out uninitialized memory contents to the file with the game still working. It's even worse in DOS era where there is no memory protection so uninitialized memory can contain data used by other processes, so for example parts of source code can get leaked that way. There's a big list of those in https://tcrf.net/Category:Games_with_uncompiled_source_code https://tcrf.net/Category:Games_with_uncompiled_source_code
  - jonhohle 2y ago
    Yeah, this was originally all DOS and Windows 3.1 utilities for writing programs that would run on MIPS. The data is small enough that it isn’t relevant, just not reproducible through standard build tools because it was never meant to be bitwise reproducible.
- aidenn0 2y ago
  Simply calling write() on a C struct can do that, if there is any padding in the struct. Then, of course, there are bugs.
tuananh 2y ago

CamouflagedKiwi 2y ago

> Our most important finding is that the reproducibility rate in nixpkgs has increased steadily from 69% in 2017 to about 91% in April 2023. The high reproducibility rate in our most recent revision is quite impressive, given both the size of the package set and the absence of systematic monitoring in nixpkgs. That's one way to read the statistic. Another way you could read the graph is that they still have about the same number (~5k) of non-reproducible builds, which has been pretty constant over the time period. Adding a bunch of easily reproducible additional builds maybe doesn't make me believe it's solving the original issues. > We knew that it was possible to achieve very good reproducibility rate in smaller package sets like Debian, but this shows that achieving very high bitwise reproducibility is possible at scale, something that was believed impossible by practitioners. Maybe I miss some nuance here, but why is Debian written off as being so much smaller scale? The top end of the graph here suggests a bit over 70k packages, Debian apparently also currently has 74k packages available (https://www.debian.org/doc/manuals/debian-reference/ch02.en.html https://www.debian.org/doc/manuals/debian-reference/ch02.en....); I guess there's maybe a bit of time lag here but I'm not sure that is enough to claim Debian is somehow not "at scale".

dartos 2y ago
Are they mostly the same 5k packages as 2017? That seems to be the crux of it.
vlovich123 2y ago
According to https://tests.reproducible-builds.org/debian/reproducible.html https://tests.reproducible-builds.org/debian/reproducible.ht... (which is what the article links to btw) there are ~37k packages tracked for reproducible builds which is ~2.7x smaller than Nix's 100k packages.
gf000 2y ago
This is not really a Nix-issue to begin with. It's a bit like asking what percentage of Nix-packaged programs have Hungarian translation -- if Nix packages some more stuff the rate might decrease, but it's not Nix's task to add that to the programs that lack it. Nix does everything in its power to provide a sandboxed environment in which builds can happen. Given the way hardware works, there are still sources of non-determinism that are impossible to prevent, most importantly timing. Most programs depend on it, even compilers, and extra care should be taken by them to change that. The only way to prevent it would be to go full-on CPU and OS emulation, but that would be prohibitively expensive.

wg0 2y ago

Let me guess... No?

rssoconnor 2y ago

I'll repeat my comment from last time this came up.[0] 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. [0]https://news.ycombinator.com/item?id=41953155 https://news.ycombinator.com/item?id=41953155

steve-chavez 2y ago
I think you want to link to https://news.ycombinator.com/item?id=41956044 https://news.ycombinator.com/item?id=41956044.
naasking 2y ago
> 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. Yes, the only possible differences result from either a compiler bug or a program bug that depends on undefined behaviour, in which case "anything can happen" as they say. As others have noted, parallel compilation depends on non-deterministic thread-scheduling, so this non-determinism can't be solved unless you restrict all compilation to be single-threaded. It's still not the only possible source of non-determinism though.

TacticalCoder 2y ago

[dead]

mhh__ 2y ago

I guess this is a tangent, but Nix to me feels like the right idea with the wrong abstraction. I can't explain / it would take a serious bit of genius to come up with an alternative worth switching to. Has anyone done any better?

Ericson2314 2y ago
You can use the low level stuff without the language to forge your own journey. https://github.com/NixOS/nix/blob/master/doc/manual/source/store/drv.md https://github.com/NixOS/nix/blob/master/doc/manual/source/s... I am working on the docs for this as we speak.
zanecodes 2y ago
I agree, I feel like Nix is kind of a hack to work around the fact that many build systems (especially for C and C++) aren't pure by default, so it tries to wrap them in a sandboxed environment that eliminates as many opportunities for impurity as it reasonably can. It's not solving the underlying problem: that build systems are often impure and sometimes nondeterministic. It also tries to solve a bunch of adjacent problems, like providing a common interface for building many different types of package, providing a common configuration language for builds as well as system services and user applications in the case of NixOS and home-manager, and providing end-user CLI tools to manage the packages built with it. It's trying to be a build wrapper, a package manager, a package repository, a configuration language, and more.
- gf000 2y ago
  > It's not solving the underlying problem: that build systems are often impure and sometimes nondeterministic It's not Nix's job, imo. Those compilers should be fixed. And all the other "features" come for free from Nix's fundamental abstractions, I don't feel it would overstep its boundaries anywhere.
- throwawayqqq11 2y ago
  Purity becomes a hard goal when ever you hit the real world at build or runtime. By definition, you have to bridge 2 domains. Imagine constant time compute and constant memory constrains, required in cryptography, being applied to the nix ecosystem. Yes, this is an artifical example but it shows that purity is harder to define and come by, then some people think. Maybe someday these constraints actually do apply to nix goal of reproducibility. With ever changing hardware that purity is a moving target so nix imo will always be an approach to purity and bundling so much tooling is to be expected. Still, you can legitimately call it a hack :)

tuananh 2y ago

so looks like reproducibility rate of nixos is not that high, roughly similar with debian? https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds

dpc_01234 2y ago
At this point almost all major package managers try to not introduce any non-reproducibility, so it comes down to package itself building deterministically. Nix just have an architectural sandboxing and isolation that enforces is maybe a bit better. But the moment e.g. ArchLinux devs fix determinism and upstream it in certain package, it will become deterministic in NixOS and others, and vice versa, so there is not going to be a lot of differences between distros at this point. Everyone agrees that deterministic builds are a good thing.

GeezNuts 2y ago

Certainly not all packages are reproducible, but the project is systematically increasing the percentage of projects that are reproducible while ALSO adding new projects and demonstrating conclusively that what was considered infeasible is actually very readily achievable.

rednafi 2y ago

Is it somewhat reproducible? Yes. But what did it cost? Usability.

__MatrixMan__ 2y ago

> there exist no reproducibility monitoring at the scale of the Nix package set (nixpkgs) I think it would be fairly easy to do this monitoring with a bit of community participation. At least I'd enable telemetry ¯\_(ツ)_/¯. By default the pkz57 in /nix/store/pkz57...-nushell-0.97.1 is a hash of the build inputs for that package. If you hash the contents of that dir, you get an identifier for the build output. If we then make a big list of such pairs as built by different people on different machines at different times, and capture the frequency of each pair we'll either see this: /nix/store/pkz5..., sha256:0drrxa..., 121 users or we'll see this: /nix/store/pkz5..., sha256:0drrxa..., 100 users /nix/store/pkz5..., sha256:gvpbk5..., 20 users /nix/store/pkz5..., sha256:1fwwfe..., 1 user The former being an indicator that the build is reproducible, and the latter giving hints about why not (supposing these users are willing to share a bit more about the circumstances of that build). I'd call it a "build chromatograph". I expect that knowing whether you're one of the 100 or the odd-man-out could be relevant for certain scenarios.

gf000 2y ago
I'm not sure the "distribution" would be all that helpful. A single compiler that does some parallel work and collect the results of that work in a list in order of completion (and similar) are probably the most common cause of non-determinism. Given that, your chromatograph would be mostly "determined" by the source code's peculiarities, instead of the offending compiler itself. (E.g. I have n classes a compiler would process in parallel, so given a single point of timing non-determinism n! different combinations could possibly exist (assuming they all cause a different outputs). The only information I could conclude from such a distribution is that there is a common sequence of completing tasks). But your idea is cool, and simply reporting back non-matching local builds would be helpful (I believe the binary property of whether a different output could be built is the only relevant fact) -- also, if we were to mark a package as non-reproducible, we could recursively mark everything else that has it as a (transitive) input.
- __MatrixMan__ 2y ago
  I think there are only a few cases where it would be helpful: - one hash to rule them all, perfectly reproducible - a big mess, consider avoiding it - just two or four cohorts, package maintainer may want to investigate - everbody agrees on the output hash except for you, something local is compromized I don't anticipiate peering into the mess and coming up with many useful conclusions. > if we were to mark a package as non-reproducible, we could recursively mark everything else that has it as a (transitive) input. I like that idea, to sort of carve out a space within the already-pretty-reliable nixpkgs which can be expected upon to be perfectly reproducible. I'd strive to get my packages included in that set, and to select my dependencies from it.

ninetyninenine 2y ago

>As part of my PhD, and under the supervision of Théo Zimmermann and Stefano Zacchiroli, I have empirically studied bitwise build reproducibility in nixpkgs over a time period of 6 years. Why spend only 6 years on the most interesting topic of all mankind? I spent 10 years analyzing this.

lrvick 2y ago

I would note that stagex is 100% reproducible, and full source bootstrapped. Every artifact is reproduced and signed by multiple maintainers on independently controlled hardware and this has been the case since our first release around this time last year. https://codeberg.org/stagex/stagex https://codeberg.org/stagex/stagex

est31 2y ago

Note that NixOS's "build" step often actually doesn't do any compilation. Often it's just downloading a binary from github releases and runs NixOS's specific binary tools on it to make it look for libraries in the right places. So if that process is reproducible, it's a different statement from a Debian package being reproducible, which requires build inputs in the preferred form of modification (source code).

IngoBlechschmid 2y ago
You are right, but I would not agree with this appearing "often". I get the impression that the nixpkgs community tries quite hard to truly compile from source even quite complex projects like Firefox and LibreOffice.
max-privatevoid 2y ago
Completely false. Building from the actual source code is strongly preferred and usually easier than patching a binary that wasn't built for such an environment.

pmarreck 2y ago

It's massively closer than any other solution in this regard (nods to other Nix-inspired distros like Guix, Lix, etc.) Honestly, I believe every software developer owes it to themselves to read the original Nix paper. It's quite digestible and lays out a lot of what it brings to the table. I came away from it wondering why it took so long to realize it... which is a property I've found true of every new important discovery. https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf If you want, you can even ask an LLM to sum up its main points for you. Or to sell it to you. =) https://chatgpt.com/share/67ae1a08-7354-8004-8200-e956cb6b59db https://chatgpt.com/share/67ae1a08-7354-8004-8200-e956cb6b59... I would like to say one thing about using Docker to "solve" this problem though: Once you think of builds in terms of functions, you realize that a Docker image is basically just the cached artifacts of a build that "just so happened" to work correctly. Consider a function that only occasionally produces a correct value: A Docker image is one of those values.

tlavoie 2y ago
Thanks for the paper, will check it out! (Still skeptical that we should encourage LLM summarization though, suspect people would gain more and actually learn things from reading papers.)
- pmarreck 2y ago
  By all means, read the paper then! It's quite readable, and one of the best papers in software development IMHO

beebaween 2y ago

I've genuinely never really understood the appeal of Nix. I even attempted to use this to build and "maintain" the machines we used at an offsite factory and even then with just a basic electron app, a python installation and very basic mac configs Nix proved to be a complete nightmare.