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!
I understand your point of view, but I’ve been using Ubuntu LTS for over a decade and the only time it has broken on updates was hardware failure. I tried nix, but there is just too much to learn just to install an OS. If I needed 99.9% reproducibility I would go with it I guess but what I’m doing works for me and I don’t have to learn a whole new DSL just to install an OS
Idk, in terms of installation difficulty NixOS is about the same as any other distro I've installed. The process is roughly: boot the LiveCD, verify disk config, run nixos-generate-config, add some basic packages to configuration.nix, run nixos-rebuild switch, and restart. The first time I did it, I didn't even understand the most basic aspects of the language.
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?
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.
You can update both of them, but Arch breaks then you have to figure out how to manually roll back the packages that broke it. If NixOS breaks, you reboot and select the previous generation and it's all reversed for you.
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.
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.
I don't think it's fair enough. Look for example at their quoted source: 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.
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.
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.
I still haven't found time to work with Nix or NixOS, but I like it's concept.
At work, I'm maintaining a bunch of custom configured Linux images for our products. While building those images through Dockerfiles is pretty declarative, my pain starts with keeping the configuration of systems in the field up to date: half of the build instructions is duplicated in Ansible playbooks.
Conceptually, with Nix(OS), I could maintain a single, declarative configuration that I would use to create new images and simply push to existing machines an re-configure them.
But I don't see getting something like that production-ready in the near future. I'm currently thinking of only building base images with docker and doing all product-specific configuration through ansible.
> While building those images through Dockerfiles is pretty declarative [...]
There is nothing declarative about Dockerfiles, they are a list of imperative steps. Same for ansible playbooks, which are also often called declarative when they really aren't.
They are imperative steps with aspirational idempotency, and specifically Ansible is painfully slow to boot. I've noticed that order often becomes necessary in practice, so I'm not sure if this imperative nature is avoidable.
Some kind of imperative base is not avoidable. In the end a declarative abstraction must map to a list of instructions to follow, that's just how computers work.
But on the abstraction level of configuring a Linux system this imperative nature can be completely hidden, as demonstrated by NixOS. E.g. you can set `services.uptime-kuma.enable = true` in a NixOS configuration and it will fetch the package, setup a systemd service for it, setup a service user, and enable and start the service, without you having to care about any kind of ordering or the specific steps themselves. You can do the same for other services, and it doesn't matter in which order they are declared.
Of course someone has to first build the abstraction, which is service-specific most of the time. Though, NixOS provides lower-level options to define these service abstractions declaratively as well (think: declaring that a user account is present, or that a systemd service is setup with some configuration), so most of the time you still don't reach the imperative base underlying NixOS.
Did you try using „immutable“ infrastructure? I mean instead of updating existing container, you just spawn a new one with the new configuration, add it to the load balancer and decommission the old one?
I like the idea of it, but the Nix people seem to have really screwed the pooch. On the social front we have tedious community discussions about whether it is OK to be funded by a defence contractor, and on the technical front the switch to new Nix commands and flakes has left the documentation in a horrible mess. I think if things had gone differently over the last 18 months we could've seen some really significant adoption, but I have no hope of that any more.
I think one of the issues with Nix's community is that they see using Nix as a goal on its own, not as a means to an end.
99.5% percent of people don't use Docker because they have a passion for writing dockerfiles, or because they find the ideas behind Docker elegant. They use it as a tool to help build other things. Meanwhile, the Nix community keeps pushing out these ideas about how Nix _works_ ("reproducible builds!", "lazy evaluation!") but they don't seem to particularly care about making Nix easy to use for the majority of the population out there who may want to use Nix as tool and don't care about its technical merits.
On top, I think most projects would benefit from having more functional programming advocates in them. Nix suffers from the opposite problem: it would benefit from having _less_ passionate FP people in it. Nix the language is pretty inscrutable for lots of people.
I'm not sure this can really be simplified without changing a lot of the system. Or maybe even at all, without sacrificing some of the current features.
If your threshold is based on the inscrutable language, I'm not sure that can be really solved by anyone in nix community at this point. You're just looking for a different solution, and that's fine. But nixos still solves real, practical issues for many people.
I'm not saying that it doesnt. We use both Nix and NixOS at work.
I'm just saying that, if the goal is mainstream adoption, the core team should acknowledge that people will use Nix as a means to an end, and not for the sake of using it as they do.
Our contributor graph is still growing exponentially and seems mostly unaffected. I'm not too scared about it. There is a lot of work to do though. Especially if we want to go mainstream
Nope. Flakes are only mentioned in a handful of places in the official docs and almost always as "this accepts flake as input". Never as something you should try using (even the format is not explained).
OK, to be more accurate when I say "documentation" I really mean "widespread online messaging about Nix". At least everywhere I've looked, existing Nix users advocate for starting with flakes now on the basis that it will be the new normal soon.
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.
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.
Once I started using NixOS, I can't see the point of all the other distributions - it's so easy to modify/remove/overwrite something and mess up your install, whereas in NixOS, I tell it what I want the system to look like and it will bring it back. After every upgrade, my system is exactly the way it was before - nothing's moved, nothing's changed, I don't have to go reset some settings, etc. In a way, it's taken the adventure out of upgrades.
Yeah. I had been wanting what Nix does for years, but didn't know what Nix was until 2020? I always had this desire to create a shell script that would allow me to install a clean version of my system, but always got stuck at the part where you try to reverse your current OS state (config and packages) into a shell script. It's just too easy to do "apt-get install..." and
then forget about your original intent of having a thing that produces your OS state. NixOS (and its relatives) is way more annoying about getting you to declare your config to get the OS state, which is perfect for a person like me. Being able to rollback packages (no, not individual files or groups of files, but discrete packages) is nice too.
> it's so easy to modify/remove/overwrite something
For some reason, out of the corner of my eye, I thought you were describing this as a feature of Nix because I missed the "mess up your install" part. It's easy to modify/remove/overwrite a package in Nix in a non-destructive way though. Of the few packages that have been broken for me, I feel empowered to pull them down and modify them to add needed functionality. And as I've gotten more confident, doing overlays or whatever they're called instead.
yeah I meant e.g. edit a config file and forget that you did, or lose the original (nowadays you might be able to Google for it, and get the wrong version and make things even more confusing).
on nixos anything that you do has to be explicit in your config and thus it can be undone as needed.
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.
I have tried to use it for C++, iOS, Python, Flutter, Docker, MacOS binaries, an Ubuntu container, MacOS, and NixOS. In every case it became a time sink that failed to work due to broken packages and convoluted code.
Core issues are that:
(1) To meet nix’s goal of declarative package management, everything in nix wraps software to create a bespoke interface for nix. But the documentation for the nix interface is extremely spotty and inconsistent, where it exists at all.
(2) The language is a mix between functional and shell code, to create a declarative spec. This means many mental gear shifts while reading. This is made even worse by the nixpkgs API being inconsistent, with case-specific variants of functions (eg to set a property on a package you might need to call a language-specific property setter, which is very confusing when a package is built with multiple languages)
(3) Many packages are broken or unsupported on one OS or the other.
Because of these, it means that you need to be a coder AND have deep Linux knowledge AND deep Nix knowledge to use it for an extended period of time.
And then:
(4) Nix does not cleanly integrate with the packaging for a language, or expects running an AOT tool to generate a bespoke Nix derivation from the standard tooling
I and others have complained about Nix being too difficult to use for years, but the Nix community instead is more excited about flakes, which are even more convoluted than existing derivations and metastasize the existing architectural issues in nixpkgs into countless decentralized packages that will now need to be refactored if someone tries to overhaul the design of nixpkgs.
From my perspective, nix flakes are like if Linux was struggling with adoption because its internal and user APIs were undocumented and frequently broken, and the kernel developers got really excited about moving all the drivers out-of-tree into separate repositories because that’s “best practices”.
A killer cross-platform and project / system package management system with hermetic build environments would be a godsend. But nix’s practical implementation of that is too badly done for me to have ever been able to use it for anything but the tiniest most specialized of projects, or as a partial package manager for macOS (where I still have to install things manually or use homebrew).
There are a great many things that are theoretically possible with Nix, but I don’t know anything that I could practically recommend it for.
> Many packages are broken or unsupported on one OS or the other.
Report them. There's thousands of packages. Efforts like Zero Hydra Fails help, but there's still a lot to fix. If you raise an issue, it will be prioritised, because we'll know someone actually cares about it.
Keep in mind that's compared to a small percent of those packages available in other systems where you're on your own - not much different than on nixos with a broken package.
The worst case that comes to mind was iOS development. In that case there was supposedly packaging available that leveraged the Xcode cli, but it had ceased to be maintained and once I started fixing stuff, I began running into even deeper issues that made me question whether it ever truly worked.
In other cases it was things like mach-nix not working for certain Python packages, and evidently a refusal to upstream something like mach-nix that tried to work with default Python packaging upstream, and the default Python API being a mess to work with.
Thus in the latter case while from the nix POV nothing in nixpkgs was “broken”, it working as designed left me choosing between investing large amounts of time to figure out how to implement a derivation for the third-party Python script I wanted to work on or dealing with third-party tools. And I expected all that to be a rathole too. I wasn’t looking to push some tooling on the third-party maintainer or develop something I’d just throw away, I wanted to add a relatively simple feature. As it was I wound up spending the free time I had troubleshooting package management and ran out of time to actually get work done. I did file an issue with mach-nix, but the person who helped me also ran into problems.
This kind of “brokenness in depth” is exactly what I ran into when I tried to troubleshoot and fix nixpkg’s iOS support over a few months.
I have actually contributed a couple packages back, and I wrote a brew-like derivation adapter that may or may not still work on one of my macOS devices that worked with standard macOS installers/install archives (copy to Applications folder), but that got broken by an upstream update and fixing it became involved. Iirc whatever I did do to fix it made it unsuitable to upstream, and when I did get another macOS device, I didn’t even try to use nix for applications that weren’t immediately supported.
Most recently I tried to create an Ubuntu container with USB forwarding under NixOS. Once again: bespoke solution, scant documentation, and GPT-4o got confused. I failed, and spent less time copying my files off and installing Ubuntu than I did trying to get it to work under NixOS.
So this isn’t just one-off packages being broken that a maintainer needs to fix. It’s a deeply pervasive thing with the entire nix ecosystem that requires the community to internalize a need to make things work obviously and on the first try for common use cases.
I don’t know anybody whose problem is “people want to pay me to work on nix with no other output product to the work other than more nix”, so I can’t recommend nix to anybody as a solution. You can’t solve a problem with more problems. And after the container incident, I’m truly lost as to what people ARE doing with nix besides just developing nix, because I thought it was supposed to be most popular in Devops contexts.
And yet the very last thing I would entrust to nix at this point would be a production service whose infrastructure needs to be completely understood and rapidly fixable, because the abysmal documentation means a minor outage could turn into a major catastrophe while people google for some obscure forum post or decipher nixpkgs layer by layer.
Yeah, that would be a problem for a few reasons, but I'd point that rant at Apple "releasing" incomplete and broken sources. This whole area has been changed massively recently by a few Darwin heroes and will be released in 24.11. It's also going to be much easier to maintain in the future.
So if you're interested, try the new apple SDKs in a couple months.
FTR, it solves quite a few of my daily issues, especially in DevOps contexts where brew is unusable.
> FTR, it solves quite a few of my daily issues, especially in DevOps contexts where brew is unusable.
Perhaps there needs to be more explicit scope communicated. Right now the nix(os) website advertises several use cases that it just doesn’t seem ready for (but this has been the case for ~5 years now, so I don’t expect it will ever be ready).
When I’ve tried asking eg “is this ready for flutter development”, I was told yes, then immediately ran into brick walls when I started trying to develop with it.
And when it comes to filing a bug report, then I feel (or the maintainers will feel) that I’m obligated to grab logs, put in a certain amount of effort, format everything accordingly etc etc.
It’s just an exhausting amount of mental complexity to deal with right now, to the point it’s hard not to say “just use docker” is the right answer. However brute force and wasteful that may be in comparison.
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.
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.
Sometimes you just need to put in some work and understand what you're doing. The author needed to search for "adb" in the docs, not the whole attribute path. With the errors, they could debug the issue like they would on any other system.
But that search is for packages themselves and is correct - that's how you install it. It's not going to tell you about the configuration just like it doesn't for nginx, postgresql, or many other packages. Sometimes you "have to be this high to ride", or use a simpler system - but that comes with its own issues.
(Although in this very specific example it could just to make life easier - I'll send a PR next week unless someone does it first)
Why is this extra completion acceptable? On Debian I install the package adb and get the udev rules with it. I just need to connect a device and run adb commands.
Because nixos manages your system and nixpkgs only contains packages. Packages cannot do anything outside their installed location, so can't touch udev or groups to make the changes. There will be other apps split in the same way.
The benefit is that just adding some package will never break your own configuration.
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.
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].
> 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.
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.
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.
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.
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
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".
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.
> 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?
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).
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.
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.
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.
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).
> 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 samebuildenvironment you will get same results by necessity.
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).
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/ 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.
> 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.
There is a lot of randomness in a typical build system: randomly ordered lists, race conditions in multithreaded coded, timestamps in the filesystem, etc,
The worse kind of build systems can even include fetching files the internet. So, no, for all practical purposes actual computers are not deterministic and this is not tautological at all.
You can try to emulate determinism using some kind of virtual machine and run your build there (for example, see Hermit[1]), but it will never be perfect determinism and there are many practical downsides.
Randomly ordered lists (and randomized hashmaps) typically relay on PRNG. Seed of PRNG is part of environment. If you use hardware RNG, it is part of environment and should be "the same". Same with timestamps. If you download files from Internet, whole Internet is your environment (and by pre-condition it must be "the same"). Of course, it is unrealistic. So...
My point is: without very precise definition of "same build environment" all discussion of reproducible builds are almost meaningless.
Keep in mind the list may be random or non-deterministic because no explicit order was imposed, and the source of the data is non-deterministic.
For example listing files in a directory and adding them to a list for further processing, without explicitly sorting by some stable criteria like filename.
> all discussion of reproducible builds are almost meaningless.
I see people working on reproducible builds understanding exactly what they work on and having successful conference talks. I understand their goal too. It could be less vague in the explanation on the website, but... There's a common understanding you seem to be missing, but that doesn't make the discussions/work meaningless.
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.
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.
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...
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.
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.
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.
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.
With NixOS, you simply use Nix to configure a file that in turn configures other files that configure other packages, and you have to rely on the new path and variable definitions created by the maintainers of NixOS for upstream programs. So, you need to learn that if the program used A, in NixOS it's B -> A -> does the job (although it's not that simple). That's why, when you use NixOS, you feel like you're working twice as hard, while Arch Linux aims to be transparent by exposing the system structure without adding a ton of crap complexity like NixOS does.
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.
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.
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).
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.
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.
If Guix were an optimal solution, many companies would be using it, but that's not happening. It's just a niche experiment. And parentheses don't seem so bad when the code is one line, when tens or hundreds of lines won't be so fun.
I agree. I really think Nix would be a lot more approachable if it didn't have such a weird language. The fact that it is dynamically typed and declarative also means it is completely undiscoverable.
>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).
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.
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.
Well, with Haskell you know what it is oriented towards and you know what to expect, but Nix wants to control everything in the system by adding unnecessary complexity to the simple and making the complex even more complex.
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!
I understand your point of view, but I’ve been using Ubuntu LTS for over a decade and the only time it has broken on updates was hardware failure. I tried nix, but there is just too much to learn just to install an OS. If I needed 99.9% reproducibility I would go with it I guess but what I’m doing works for me and I don’t have to learn a whole new DSL just to install an OS
Idk, in terms of installation difficulty NixOS is about the same as any other distro I've installed. The process is roughly: boot the LiveCD, verify disk config, run nixos-generate-config, add some basic packages to configuration.nix, run nixos-rebuild switch, and restart. The first time I did it, I didn't even understand the most basic aspects of the language.
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?
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.
i guess i cannot imagine the kind of problems you were having before :)
but from the description they seem runtime errors. do you have a functional test of sorts after nix creates the new state?
You can update both of them, but Arch breaks then you have to figure out how to manually roll back the packages that broke it. If NixOS breaks, you reboot and select the previous generation and it's all reversed for you.
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.
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.
I don't think it's fair enough. Look for example at their quoted source: 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.
make and compilers are usually reproducible. Most Debian package are reproducible, so this is perfectly feasible.
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.
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.
I still haven't found time to work with Nix or NixOS, but I like it's concept.
At work, I'm maintaining a bunch of custom configured Linux images for our products. While building those images through Dockerfiles is pretty declarative, my pain starts with keeping the configuration of systems in the field up to date: half of the build instructions is duplicated in Ansible playbooks.
Conceptually, with Nix(OS), I could maintain a single, declarative configuration that I would use to create new images and simply push to existing machines an re-configure them.
But I don't see getting something like that production-ready in the near future. I'm currently thinking of only building base images with docker and doing all product-specific configuration through ansible.
> While building those images through Dockerfiles is pretty declarative [...]
There is nothing declarative about Dockerfiles, they are a list of imperative steps. Same for ansible playbooks, which are also often called declarative when they really aren't.
They are imperative steps with aspirational idempotency, and specifically Ansible is painfully slow to boot. I've noticed that order often becomes necessary in practice, so I'm not sure if this imperative nature is avoidable.
Some kind of imperative base is not avoidable. In the end a declarative abstraction must map to a list of instructions to follow, that's just how computers work.
But on the abstraction level of configuring a Linux system this imperative nature can be completely hidden, as demonstrated by NixOS. E.g. you can set `services.uptime-kuma.enable = true` in a NixOS configuration and it will fetch the package, setup a systemd service for it, setup a service user, and enable and start the service, without you having to care about any kind of ordering or the specific steps themselves. You can do the same for other services, and it doesn't matter in which order they are declared.
Of course someone has to first build the abstraction, which is service-specific most of the time. Though, NixOS provides lower-level options to define these service abstractions declaratively as well (think: declaring that a user account is present, or that a systemd service is setup with some configuration), so most of the time you still don't reach the imperative base underlying NixOS.
Did you try using „immutable“ infrastructure? I mean instead of updating existing container, you just spawn a new one with the new configuration, add it to the load balancer and decommission the old one?
Our products are hardware, I use docker to build and manage bootable images.
WIth Guix you can export these declarative files to docker coutainers, TGZ's ready to deploy everywhere (guix pack), vm's, build systems...
And you can do the same with Nix, not sure what your point is?
its
I like the idea of it, but the Nix people seem to have really screwed the pooch. On the social front we have tedious community discussions about whether it is OK to be funded by a defence contractor, and on the technical front the switch to new Nix commands and flakes has left the documentation in a horrible mess. I think if things had gone differently over the last 18 months we could've seen some really significant adoption, but I have no hope of that any more.
I think one of the issues with Nix's community is that they see using Nix as a goal on its own, not as a means to an end.
99.5% percent of people don't use Docker because they have a passion for writing dockerfiles, or because they find the ideas behind Docker elegant. They use it as a tool to help build other things. Meanwhile, the Nix community keeps pushing out these ideas about how Nix _works_ ("reproducible builds!", "lazy evaluation!") but they don't seem to particularly care about making Nix easy to use for the majority of the population out there who may want to use Nix as tool and don't care about its technical merits.
On top, I think most projects would benefit from having more functional programming advocates in them. Nix suffers from the opposite problem: it would benefit from having _less_ passionate FP people in it. Nix the language is pretty inscrutable for lots of people.
I'm not sure this can really be simplified without changing a lot of the system. Or maybe even at all, without sacrificing some of the current features.
If your threshold is based on the inscrutable language, I'm not sure that can be really solved by anyone in nix community at this point. You're just looking for a different solution, and that's fine. But nixos still solves real, practical issues for many people.
I'm not saying that it doesnt. We use both Nix and NixOS at work.
I'm just saying that, if the goal is mainstream adoption, the core team should acknowledge that people will use Nix as a means to an end, and not for the sake of using it as they do.
> and not for the sake of using it as they do.
You're creating your own ideas of why people do things and presenting them as facts. Please don't, it's neither useful in the discussion nor nice.
But they are right though. And casting them as 'not nice' is in itself not nice.
Are you relying what the authors personally told you, or would you like to point to where they wrote that online?
Our contributor graph is still growing exponentially and seems mostly unaffected. I'm not too scared about it. There is a lot of work to do though. Especially if we want to go mainstream
>on the technical front the switch to new Nix commands and flakes has left the documentation in a horrible mess
Did it ever happen? Last I've checked flakes were still experimental.
Nope. Flakes are only mentioned in a handful of places in the official docs and almost always as "this accepts flake as input". Never as something you should try using (even the format is not explained).
OK, to be more accurate when I say "documentation" I really mean "widespread online messaging about Nix". At least everywhere I've looked, existing Nix users advocate for starting with flakes now on the basis that it will be the new normal soon.
Most others just follow the same concept of running imperative commands and not much about them is revolutionary. NixOS gives that a new spin.
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.
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?
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.
Once I started using NixOS, I can't see the point of all the other distributions - it's so easy to modify/remove/overwrite something and mess up your install, whereas in NixOS, I tell it what I want the system to look like and it will bring it back. After every upgrade, my system is exactly the way it was before - nothing's moved, nothing's changed, I don't have to go reset some settings, etc. In a way, it's taken the adventure out of upgrades.
Yeah. I had been wanting what Nix does for years, but didn't know what Nix was until 2020? I always had this desire to create a shell script that would allow me to install a clean version of my system, but always got stuck at the part where you try to reverse your current OS state (config and packages) into a shell script. It's just too easy to do "apt-get install..." and then forget about your original intent of having a thing that produces your OS state. NixOS (and its relatives) is way more annoying about getting you to declare your config to get the OS state, which is perfect for a person like me. Being able to rollback packages (no, not individual files or groups of files, but discrete packages) is nice too.
> it's so easy to modify/remove/overwrite something
For some reason, out of the corner of my eye, I thought you were describing this as a feature of Nix because I missed the "mess up your install" part. It's easy to modify/remove/overwrite a package in Nix in a non-destructive way though. Of the few packages that have been broken for me, I feel empowered to pull them down and modify them to add needed functionality. And as I've gotten more confident, doing overlays or whatever they're called instead.
yeah I meant e.g. edit a config file and forget that you did, or lose the original (nowadays you might be able to Google for it, and get the wrong version and make things even more confusing).
on nixos anything that you do has to be explicit in your config and thus it can be undone as needed.
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.
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.
I have tried to use it for C++, iOS, Python, Flutter, Docker, MacOS binaries, an Ubuntu container, MacOS, and NixOS. In every case it became a time sink that failed to work due to broken packages and convoluted code.
Core issues are that:
(1) To meet nix’s goal of declarative package management, everything in nix wraps software to create a bespoke interface for nix. But the documentation for the nix interface is extremely spotty and inconsistent, where it exists at all.
(2) The language is a mix between functional and shell code, to create a declarative spec. This means many mental gear shifts while reading. This is made even worse by the nixpkgs API being inconsistent, with case-specific variants of functions (eg to set a property on a package you might need to call a language-specific property setter, which is very confusing when a package is built with multiple languages)
(3) Many packages are broken or unsupported on one OS or the other.
Because of these, it means that you need to be a coder AND have deep Linux knowledge AND deep Nix knowledge to use it for an extended period of time.
And then:
(4) Nix does not cleanly integrate with the packaging for a language, or expects running an AOT tool to generate a bespoke Nix derivation from the standard tooling
I and others have complained about Nix being too difficult to use for years, but the Nix community instead is more excited about flakes, which are even more convoluted than existing derivations and metastasize the existing architectural issues in nixpkgs into countless decentralized packages that will now need to be refactored if someone tries to overhaul the design of nixpkgs.
From my perspective, nix flakes are like if Linux was struggling with adoption because its internal and user APIs were undocumented and frequently broken, and the kernel developers got really excited about moving all the drivers out-of-tree into separate repositories because that’s “best practices”.
A killer cross-platform and project / system package management system with hermetic build environments would be a godsend. But nix’s practical implementation of that is too badly done for me to have ever been able to use it for anything but the tiniest most specialized of projects, or as a partial package manager for macOS (where I still have to install things manually or use homebrew).
There are a great many things that are theoretically possible with Nix, but I don’t know anything that I could practically recommend it for.
> Many packages are broken or unsupported on one OS or the other.
Report them. There's thousands of packages. Efforts like Zero Hydra Fails help, but there's still a lot to fix. If you raise an issue, it will be prioritised, because we'll know someone actually cares about it.
Keep in mind that's compared to a small percent of those packages available in other systems where you're on your own - not much different than on nixos with a broken package.
The worst case that comes to mind was iOS development. In that case there was supposedly packaging available that leveraged the Xcode cli, but it had ceased to be maintained and once I started fixing stuff, I began running into even deeper issues that made me question whether it ever truly worked.
In other cases it was things like mach-nix not working for certain Python packages, and evidently a refusal to upstream something like mach-nix that tried to work with default Python packaging upstream, and the default Python API being a mess to work with.
Thus in the latter case while from the nix POV nothing in nixpkgs was “broken”, it working as designed left me choosing between investing large amounts of time to figure out how to implement a derivation for the third-party Python script I wanted to work on or dealing with third-party tools. And I expected all that to be a rathole too. I wasn’t looking to push some tooling on the third-party maintainer or develop something I’d just throw away, I wanted to add a relatively simple feature. As it was I wound up spending the free time I had troubleshooting package management and ran out of time to actually get work done. I did file an issue with mach-nix, but the person who helped me also ran into problems.
https://github.com/DavHau/mach-nix/issues/560
This kind of “brokenness in depth” is exactly what I ran into when I tried to troubleshoot and fix nixpkg’s iOS support over a few months.
I have actually contributed a couple packages back, and I wrote a brew-like derivation adapter that may or may not still work on one of my macOS devices that worked with standard macOS installers/install archives (copy to Applications folder), but that got broken by an upstream update and fixing it became involved. Iirc whatever I did do to fix it made it unsuitable to upstream, and when I did get another macOS device, I didn’t even try to use nix for applications that weren’t immediately supported.
https://discourse.nixos.org/t/feedback-darwin-installapplica...
https://discourse.nixos.org/t/second-overlay-not-seeing-chan...
Most recently I tried to create an Ubuntu container with USB forwarding under NixOS. Once again: bespoke solution, scant documentation, and GPT-4o got confused. I failed, and spent less time copying my files off and installing Ubuntu than I did trying to get it to work under NixOS.
https://www.reddit.com/r/NixOS/comments/1ga6dbe/comment/ltce...
So this isn’t just one-off packages being broken that a maintainer needs to fix. It’s a deeply pervasive thing with the entire nix ecosystem that requires the community to internalize a need to make things work obviously and on the first try for common use cases.
I don’t know anybody whose problem is “people want to pay me to work on nix with no other output product to the work other than more nix”, so I can’t recommend nix to anybody as a solution. You can’t solve a problem with more problems. And after the container incident, I’m truly lost as to what people ARE doing with nix besides just developing nix, because I thought it was supposed to be most popular in Devops contexts.
And yet the very last thing I would entrust to nix at this point would be a production service whose infrastructure needs to be completely understood and rapidly fixable, because the abysmal documentation means a minor outage could turn into a major catastrophe while people google for some obscure forum post or decipher nixpkgs layer by layer.
/rant
> that leveraged the Xcode cli
Yeah, that would be a problem for a few reasons, but I'd point that rant at Apple "releasing" incomplete and broken sources. This whole area has been changed massively recently by a few Darwin heroes and will be released in 24.11. It's also going to be much easier to maintain in the future.
So if you're interested, try the new apple SDKs in a couple months.
FTR, it solves quite a few of my daily issues, especially in DevOps contexts where brew is unusable.
> FTR, it solves quite a few of my daily issues, especially in DevOps contexts where brew is unusable.
Perhaps there needs to be more explicit scope communicated. Right now the nix(os) website advertises several use cases that it just doesn’t seem ready for (but this has been the case for ~5 years now, so I don’t expect it will ever be ready).
When I’ve tried asking eg “is this ready for flutter development”, I was told yes, then immediately ran into brick walls when I started trying to develop with it.
And when it comes to filing a bug report, then I feel (or the maintainers will feel) that I’m obligated to grab logs, put in a certain amount of effort, format everything accordingly etc etc.
It’s just an exhausting amount of mental complexity to deal with right now, to the point it’s hard not to say “just use docker” is the right answer. However brute force and wasteful that may be in comparison.
$ 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)
Sure, but it won't successfully connect to a real device unless you somehow know to also set `programs.adb.enable = true`.
That's not nixos specific. You get special instructions for Ubuntu https://help.ubuntu.com/community/AndroidSDK Arch https://wiki.archlinux.org/title/Android_Debug_Bridge Gentoo 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.a...
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...
> 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)
Sometimes you just need to put in some work and understand what you're doing. The author needed to search for "adb" in the docs, not the whole attribute path. With the errors, they could debug the issue like they would on any other system.
But that search is for packages themselves and is correct - that's how you install it. It's not going to tell you about the configuration just like it doesn't for nginx, postgresql, or many other packages. Sometimes you "have to be this high to ride", or use a simpler system - but that comes with its own issues.
(Although in this very specific example it could just to make life easier - I'll send a PR next week unless someone does it first)
Why is this extra completion acceptable? On Debian I install the package adb and get the udev rules with it. I just need to connect a device and run adb commands.
Because nixos manages your system and nixpkgs only contains packages. Packages cannot do anything outside their installed location, so can't touch udev or groups to make the changes. There will be other apps split in the same way.
The benefit is that just adding some package will never break your own configuration.
For the same reason that people get used to quirks on Debian (or any other distro really) that then eventually get fixed.
Nobody's perfect, you live and you learn it. I use Hannah Montanix btw
https://youtube.com/watch?v=2DQla5j26Qc
nixos is open source, I'm sure they'd welcome your proposed changes! they accept patches on GitHub.
> no indication why on an unfamiliar OS.
to be fair, I feel exactly that way on Windows after not using it for two decades (I only use it as a thin client now).
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.
That will change with content addressed derivations but they are progressing slowly exactly because of this.
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
[2] https://www.tweag.io/blog/2020-09-10-nix-cas/
[3] https://discourse.nixos.org/t/content-addressed-nix-call-for...
> 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.
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.
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://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
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
Probably much better repdoducibility than embedded developers trying to maintain thet while upgrading their ubuntus thy work on.
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/
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.
> 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?
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).
Why is every comment here negative?
The NixCon is in session right now so all the core contributors are chatting in person.
the "i dont get it" crowd found this thread
Hacker news showing its skill issues in force today I guess.
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.
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.
Saying it's a skill issue just shows lack of imagination and ambition to make it better.
Or as they might phrase it, a skill issue.
So if it's not reproducable, what is it good for? To recreate similar environment easily?
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.
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).
Same bits into input - some bits out of output.
Edit: formatting.
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).
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/ 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.
> 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.
There is a lot of randomness in a typical build system: randomly ordered lists, race conditions in multithreaded coded, timestamps in the filesystem, etc, The worse kind of build systems can even include fetching files the internet. So, no, for all practical purposes actual computers are not deterministic and this is not tautological at all.
You can try to emulate determinism using some kind of virtual machine and run your build there (for example, see Hermit[1]), but it will never be perfect determinism and there are many practical downsides.
[1]: https://github.com/facebookexperimental/hermit
Randomly ordered lists (and randomized hashmaps) typically relay on PRNG. Seed of PRNG is part of environment. If you use hardware RNG, it is part of environment and should be "the same". Same with timestamps. If you download files from Internet, whole Internet is your environment (and by pre-condition it must be "the same"). Of course, it is unrealistic. So...
My point is: without very precise definition of "same build environment" all discussion of reproducible builds are almost meaningless.
Keep in mind the list may be random or non-deterministic because no explicit order was imposed, and the source of the data is non-deterministic.
For example listing files in a directory and adding them to a list for further processing, without explicitly sorting by some stable criteria like filename.
> all discussion of reproducible builds are almost meaningless.
I see people working on reproducible builds understanding exactly what they work on and having successful conference talks. I understand their goal too. It could be less vague in the explanation on the website, but... There's a common understanding you seem to be missing, but that doesn't make the discussions/work meaningless.
> as computers are deterministic
I have some bad news.
Ever since I started using Zig, making everything reproducible has never been as easy as just using the Zig build system.
Someone may have the problem that NixOS solves. I'm not sure who they are.
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.
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.
[dead]
[dead]
[flagged]
Calling it a "minor naming ambiguity" when people get surprised every time it gets pointed out is underselling the (albeit small) problem.
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...
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.
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.
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.
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.
With NixOS, you simply use Nix to configure a file that in turn configures other files that configure other packages, and you have to rely on the new path and variable definitions created by the maintainers of NixOS for upstream programs. So, you need to learn that if the program used A, in NixOS it's B -> A -> does the job (although it's not that simple). That's why, when you use NixOS, you feel like you're working twice as hard, while Arch Linux aims to be transparent by exposing the system structure without adding a ton of crap complexity like NixOS does.
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.
Can you recommend tools you prefer/use for achieving reproducibility/determinism?
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.
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).
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-mod...
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...
Guix, as NixOS, exists when an scientific experiment should have reproducible builds in every stage.
On config files, Guile is not that difficult.
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.
Those things (parentheses and free software) don't make Guix a bad solution. It's just not for you.
If Guix were an optimal solution, many companies would be using it, but that's not happening. It's just a niche experiment. And parentheses don't seem so bad when the code is one line, when tens or hundreds of lines won't be so fun.
Isn't most non-free stuff installed in /opt or in the user homedir these days anyway?
I agree. I really think Nix would be a lot more approachable if it didn't have such a weird language. The fact that it is dynamically typed and declarative also means it is completely undiscoverable.
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.
> 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.
How do I recompile binary blobs?
You don't. So the blob that is packaged and installed is identical to the one in the repository. Hence, it has no reproducibility issue.
Non-free does not mean compiled. Here's a non-free script which I grant you the right to view but not execute or copy:
Reproducible, compiled and free are all orthogonal.>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).
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.
The reproducibility crisis in science has nothing to do with the supporting software itself not being reproducible.
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.
> you end up not knowing what it's doing even if you're an "expert"
Oh you've tried Haskell then?
Well, with Haskell you know what it is oriented towards and you know what to expect, but Nix wants to control everything in the system by adding unnecessary complexity to the simple and making the complex even more complex.
Sounds like you want MacOS.
No, I like it practical and without such stupid design choices.
If only there were alternatives...
[flagged]