NixOS is not reproducible(linderud.dev)
linderud.dev
NixOS is not reproducible
https://linderud.dev/blog/nixos-is-not-reproducible/
168 comments
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
I agree. If all you need is Linux on a bog standard machine and would rather spend your time doing something else than tinkering on your OS, nix is not for you. Life is short and there are lots of things to do - we all have different priorities.
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.
> add some basic packages to configuration.nix
This includes understanding how nix configuration works, finding the packages you want, understanding how their configuration is mapped in to nix idiosyncratic way of configuring software which is not well documented, will most likely require you read the package and map yourself between the software doc and what nix changes, then properly structuring the config before applying it.
This is not in any way simple.
This includes understanding how nix configuration works, finding the packages you want, understanding how their configuration is mapped in to nix idiosyncratic way of configuring software which is not well documented, will most likely require you read the package and map yourself between the software doc and what nix changes, then properly structuring the config before applying it.
This is not in any way simple.
I pressed C-c accidentally during the upgrade(wrong terminal) and it broke the entire system(had to manually change a few files rebuild initramfs to be able to boot). I would take the complexity of Nix without a thought.
I know it's not the same thing but I am quite happy with opensuse tumbleweed and snapper snapshots. It won't save you from something that also breaks grub but for most everything else it'll be fine. I've only needed to revert to an earlier snapshot once (in 4+ years). I said I needed to but I didn't because I forgot I had the ability and fixed the issue in another way. (It was just having to download and install a wifi rpm without actually having wifi. Not a big deal.)
This is my reason as well. Except it was with Ubuntu. The straw that broke the camels back was that on the day of a uni project deadline an Ubuntu update totalled my system. So I went all in on NixOS. There are a ton of things to complain about but my system has been rock solid since. I won't ever look back.
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.
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.
Yes, the updates treated like a DB transaction are the main draw of Nix and I agree they're nice. However, Fedora and recently Manjaro started offering the so-called "immutable" versions that do nearly the same: you can install and delete and do whatever you like but you also have to explicitly opt in to commit those changes to your bootable image. If you don't do it they're just discarded after you reboot.
That's quite awesome and saves me from 99% of the problem you described... without having to learn the Nix's weird language or be willing to read cryptic error messages and get roasted on Reddit for not knowing them by heart.
That's quite awesome and saves me from 99% of the problem you described... without having to learn the Nix's weird language or be willing to read cryptic error messages and get roasted on Reddit for not knowing them by heart.
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?
but from the description they seem runtime errors. do you have a functional test of sorts after nix creates the new state?
Look at Debian's official instructions for how to upgrade to a new major release. The wiki page begins with this casual disclaimer:
"DANGER!!! DANGER!!! DANGER!!! DANGER!!! DANGER!!!
DANGER!!! DANGER!!! DANGER!!! DANGER!!! DANGER!!!"
The release notes for each version has the detailed instructions for how to upgrade from the previous version. They very strongly emphasize backing up the entire system, because the upgrade process is absolutely not guaranteed to leave the computer in a state that works correctly or boots at all, and there is no way to undo it.
That's what's different about NixOS: if the new configuration doesn't work properly, you can just choose the previous configuration in the bootloader menu. It's as straightforward and foolproof as switching to another branch in a Git repository. The whole point of NixOS is that you can have any number of system configurations in the Nix store and switch between them in a way that's atomic in the transactional sense.
If you know how Nix works, you can feel safe turning off the power supply at any point during a full system upgrade. You'll never end up in a state where half of the packages are upgraded. It's either upgraded or not. As far as I know there's no other distribution that works like this other than GuixSD.
"DANGER!!! DANGER!!! DANGER!!! DANGER!!! DANGER!!!
DANGER!!! DANGER!!! DANGER!!! DANGER!!! DANGER!!!"
The release notes for each version has the detailed instructions for how to upgrade from the previous version. They very strongly emphasize backing up the entire system, because the upgrade process is absolutely not guaranteed to leave the computer in a state that works correctly or boots at all, and there is no way to undo it.
That's what's different about NixOS: if the new configuration doesn't work properly, you can just choose the previous configuration in the bootloader menu. It's as straightforward and foolproof as switching to another branch in a Git repository. The whole point of NixOS is that you can have any number of system configurations in the Nix store and switch between them in a way that's atomic in the transactional sense.
If you know how Nix works, you can feel safe turning off the power supply at any point during a full system upgrade. You'll never end up in a state where half of the packages are upgraded. It's either upgraded or not. As far as I know there's no other distribution that works like this other than GuixSD.
NixOS supports adding tests which are selenium-style integration tests run on VMs
My general experience with Arch is that the up-to-date-ness is a double-edged sword, and you some times hit new bugs or incompatabilities. If it happens in nix i can simply just revert - you can select which OS build version you want to boot at startup - and wait a few days.
And for my eGPU setup it also gives me a lot more confidence to tinker and reboot - the barrier for me to do so is a lot lower when I know i can simply boot an older build of my OS instead of having to whip out the arch installer USB and arch-chroot into my root drive to fix a bricked install that no longer boots.
And for my eGPU setup it also gives me a lot more confidence to tinker and reboot - the barrier for me to do so is a lot lower when I know i can simply boot an older build of my OS instead of having to whip out the arch installer USB and arch-chroot into my root drive to fix a bricked install that no longer boots.
There is a Utopia of rolling release and Snapper/Btrfs which takes a snapshot of / each time you use your package manager so you can roll back. But SpiralLinux(can be Sid based, Snapper OOTB) was infuriating with my Nvidia/5k screen and Cachy(Arch based with Calamares) didnt install. I'm too lazy to do it with a major distro and I download prebuilt debs/rpms and dont want to fight Opensuse Leap which invented Snapper.
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.
maybe you want manjaro (week late arch) and dual root.
Has anyone implemented A/B root on Arch or a derivative?
If your filesystem is btrfs, you can use snapper and a pacman hook to do something equivalent but using less storage. See https://wiki.archlinux.org/title/Snapper
Not quite the same but very useful for me. Sometimes small patches to programs have big usability wins. In nix you can still update automatically, it adds your patch, automatically downloads the programs needed to compile (but still can be garbage collected afterwards), compiles and done
Maybe not great for production but for personal use, since I guess this patch could break. But in exchange for a few times it breaks, I get automatic patched updated
(Except for emacs where takes 40 minutes to compile, but schedule updated for night)
Maybe not great for production but for personal use, since I guess this patch could break. But in exchange for a few times it breaks, I get automatic patched updated
(Except for emacs where takes 40 minutes to compile, but schedule updated for night)
Updates are reversible and you have a list of every update you have ever tried to revert to.
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.
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.
"Repeatable builds" seems like what you want?
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.
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.
Read the page again.
What are they testing? 99% of what exactly?
What does "path" mean, does it inflate the number?
What are they testing? 99% of what exactly?
What does "path" mean, does it inflate the number?
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.
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.
Usually they aren't because of timestamps, processor features etc. After quite a bit of work Debian is now at 96% (or 93% when varying a few more things)
https://tests.reproducible-builds.org/debian/reproducible.ht...
https://tests.reproducible-builds.org/debian/reproducible.ht...
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
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.
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.
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.
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
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.
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.
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.
Improving the interaction with language ecosystems was one of the motivating reasons for how I approached the [rework][1] of Darwin support in nixpkgs. A lot of Rust stuff was simply impossible to build due to their SDK needs and how hard it was to override the SDK correctly, but that’s fixed now (with a few remaining cases that will be fixed in the final staging cycle before 24.11). I expect other ecosystems to benefit similarly, especially since Darwin support looks more like a native toolchain while still being built and provided by nixpkgs.
For example, Zed and Wezterm (previously failing intermittently on x86_64-darwin) now build on Darwin. Someone even has [Firefox building from source][2]. PyTorch will be able to support MPS, and MoltenVK will be able to use Metal 3 features if your system supports them.
[1]: https://github.com/NixOS/nixpkgs/pull/346043
[2]: https://github.com/NixOS/nixpkgs/pull/350384
For example, Zed and Wezterm (previously failing intermittently on x86_64-darwin) now build on Darwin. Someone even has [Firefox building from source][2]. PyTorch will be able to support MPS, and MoltenVK will be able to use Metal 3 features if your system supports them.
[1]: https://github.com/NixOS/nixpkgs/pull/346043
[2]: https://github.com/NixOS/nixpkgs/pull/350384
My flutter use case may be too pedestrian, but I have no issue with flutter using projects managed by nix.
A good summary of the pain points I have with Nix. I was introduced to it recently at DayJob because one of the engineers I work with is a huge advocate for it.
I think there's a good use case for a small subset of Nix + direnv to manage system packages for repositories. That's essentially what we use at DayJob - but all it does is install system packages necessary for a containerized workflow. However, even that level of complexity, even if it's just a small flake.nix and .envrc, can be cumbersome to end users and we actively seek to hide away that complexity as much as possible because anyone not a Nix expert that is presented to work with Nix is entering a deep rabbit hole of complexity that is probably ultimately unrelated to the problem they are trying to solve.
Part of this I think is a branding and documentation issue with Nix. As a counterexample: I work with Argo a lot and they handle this sort of situation better. There is ArgoCD, Argo Workflows, Argo Events, and Argo Rollouts. They are all under the Argo umbrella that do distinctive things with clearly demarcated roles. Unlike Nix, I never get confused when I'm searching for ArgoCD related docs. I don't have to worry that I'm going to happen on Argo Rollouts related stuff and somehow not understand that Argo Rollouts is not the piece of Argo that I'm trying to use right now. The lines between each of the technologies are clearly demarcated and there is no confusion about the best way to do XYZ in each of them.
Not so with Nix - if I'm new to Nix and I'm looking up how to structure something in a flake, not only is there different setups/configs for a build tooling setup vs a package management setup, but even within a build tooling setup for instance there are probably 4-5 canonical different ways to configure things, all with a ton of decisions. Heck, if I'm new to Nix it is probably not even immediately obvious that I should be doing it with a flake instead of The Old Way, and I might even start implementing something using The Old Way before finding out buried in some Github issue from years ago that I'm Doing it Wrong
Thing that makes Nix amazing: It's infinitely customizable and welcomes that philosophy
Thing that prevents Nix from succeeding: It's infinitely customizable and welcomes that philosophy
TL;DR Nix favors configuration over convention, oftentimes to its detriment
Final footnote. I am writing this on a personal x86 machine managed with nix-darwin. It functions, but the amount of nondeterministic calls out to homebrew and kludges required for it to work essentially defeats the purpose of managing the machine declaratively in the first place. All of the following extremely popular softwares available in nixpkgs - 1Password, VSCode, Firefox, Docker Desktop - don't work out of the box on this machine and require either compiling the package yourself, jumping through some hoops to get it to work with MacOS code signing, or require you to just entirely ignore the Nix aspect and have Nix shell out to Homebrew. There are also quite a few binaries of packages that are simply unavailable in Nix.
I think there's a good use case for a small subset of Nix + direnv to manage system packages for repositories. That's essentially what we use at DayJob - but all it does is install system packages necessary for a containerized workflow. However, even that level of complexity, even if it's just a small flake.nix and .envrc, can be cumbersome to end users and we actively seek to hide away that complexity as much as possible because anyone not a Nix expert that is presented to work with Nix is entering a deep rabbit hole of complexity that is probably ultimately unrelated to the problem they are trying to solve.
Part of this I think is a branding and documentation issue with Nix. As a counterexample: I work with Argo a lot and they handle this sort of situation better. There is ArgoCD, Argo Workflows, Argo Events, and Argo Rollouts. They are all under the Argo umbrella that do distinctive things with clearly demarcated roles. Unlike Nix, I never get confused when I'm searching for ArgoCD related docs. I don't have to worry that I'm going to happen on Argo Rollouts related stuff and somehow not understand that Argo Rollouts is not the piece of Argo that I'm trying to use right now. The lines between each of the technologies are clearly demarcated and there is no confusion about the best way to do XYZ in each of them.
Not so with Nix - if I'm new to Nix and I'm looking up how to structure something in a flake, not only is there different setups/configs for a build tooling setup vs a package management setup, but even within a build tooling setup for instance there are probably 4-5 canonical different ways to configure things, all with a ton of decisions. Heck, if I'm new to Nix it is probably not even immediately obvious that I should be doing it with a flake instead of The Old Way, and I might even start implementing something using The Old Way before finding out buried in some Github issue from years ago that I'm Doing it Wrong
Thing that makes Nix amazing: It's infinitely customizable and welcomes that philosophy
Thing that prevents Nix from succeeding: It's infinitely customizable and welcomes that philosophy
TL;DR Nix favors configuration over convention, oftentimes to its detriment
Final footnote. I am writing this on a personal x86 machine managed with nix-darwin. It functions, but the amount of nondeterministic calls out to homebrew and kludges required for it to work essentially defeats the purpose of managing the machine declaratively in the first place. All of the following extremely popular softwares available in nixpkgs - 1Password, VSCode, Firefox, Docker Desktop - don't work out of the box on this machine and require either compiling the package yourself, jumping through some hoops to get it to work with MacOS code signing, or require you to just entirely ignore the Nix aspect and have Nix shell out to Homebrew. There are also quite a few binaries of packages that are simply unavailable in Nix.
$ 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)
[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...
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)
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)
IMHO, a couple of major issues with this are some properties of Nix documentation websites, that make them not popup in search engines on certain queries.
In this particular case it would be great to have "nixos Android SDK" or "nixos adb" return either a hypothetical page like "NixOS.org/programs/adb" or at least "wiki.NixOS.org/pages/Android-SDK". There's a problem with "nixos.wiki" showing up instead. If both are controlled by the community, "NixOS.wiki" should instead do permanent redirects to "wiki.nixos.org" so that search engines would correctly show it.
Somebody really needs to work on this, this hurts the adoption A LOT.
Edit viraptor in the sibling said it is the fault of user they didn't use documentation. No, it is not. We've known for long that global search is much better interface to docs, the approach with custom UX and per-feature search (in Nix: programs, services, setup instructions, wiki, options, etc) just sucks and needs to support the efficient one.
In this particular case it would be great to have "nixos Android SDK" or "nixos adb" return either a hypothetical page like "NixOS.org/programs/adb" or at least "wiki.NixOS.org/pages/Android-SDK". There's a problem with "nixos.wiki" showing up instead. If both are controlled by the community, "NixOS.wiki" should instead do permanent redirects to "wiki.nixos.org" so that search engines would correctly show it.
Somebody really needs to work on this, this hurts the adoption A LOT.
Edit viraptor in the sibling said it is the fault of user they didn't use documentation. No, it is not. We've known for long that global search is much better interface to docs, the approach with custom UX and per-feature search (in Nix: programs, services, setup instructions, wiki, options, etc) just sucks and needs to support the efficient one.
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)
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.
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
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.
Please, see a sibling.
> 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).
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).
Yes, it isn't. But they did a lot to eradicate entropy in the builds and I believe they are able to reproduce base system images bit by bit.
Another attempt in that area is stal/ix, which is much more reproducible than nix, its store is content-addressable: https://stal-ix.github.io/
Another attempt in that area is stal/ix, which is much more reproducible than nix, its store is content-addressable: https://stal-ix.github.io/
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.
It's a fine point to make, but I get the feeling some people's perceptions (that Nix introductory docs are unclear) are out of date. From nixos.org, I click "Learn", "How Nix works", and it says in the first section that the hashes are "a cryptographic hash of the package’s build dependency graph".
https://nixos.org/guides/how-nix-works/
https://nixos.org/guides/how-nix-works/
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...
> 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.
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.
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.
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.
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.
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.
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?
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?
Not the parent, but you can have a base image + set of offline only setup scripts.
That doesn't satisfy the requirement "from source". Sure, you can build on a large binary blob that already contains everything you need, but then you are just moving the issue into the build process of that blob.
Also, 99% of container image build scripts (Dockerfiles, etc.) probably don't pin an exact base image and don't avoid pulling in external resources (e.g. packages from the base image distro's repositories).
I wouldn't call a system that makes it very easy to break reproducible build environments easier than just using nix to achieve that reproducibility.
Also, 99% of container image build scripts (Dockerfiles, etc.) probably don't pin an exact base image and don't avoid pulling in external resources (e.g. packages from the base image distro's repositories).
I wouldn't call a system that makes it very easy to break reproducible build environments easier than just using nix to achieve that reproducibility.
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).
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.
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.
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.
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.
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.
I think this is much of the problem. The complexities are hidden behind the abstraction, and I'd wager (naively) that most NixOS users at some point need to use an escape hatch. It makes sense that that complexity extends all the way to altering the OS itself, so that Nix has to perform less acrobatics.
> [...] and I'd wager (naively) that most NixOS users at some point need to use an escape hatch.
I don't think that is the case. In five years of using NixOS I never needed to reach for any of them, and I don't even know what would be available to me. Probably something about activation scripts? Again, I can't think of anything you might want to do with regard to system configuration that can't be done declaratively on NixOS.
I don't think that is the case. In five years of using NixOS I never needed to reach for any of them, and I don't even know what would be available to me. Probably something about activation scripts? Again, I can't think of anything you might want to do with regard to system configuration that can't be done declaratively on NixOS.
Fair enough. It could be that good. Is this use for commercial purposes? Do you have to interface with legacy systems or unusual stacks?
Mostly private use, I have 2 servers and a laptop configured with this: https://github.com/matrss/nixfiles. The servers host a bunch of different services from Nextcloud to a DoT-to-ODoH proxy and some more.
I've also introduced some light NixOS usage at work (3 hosts, one is an uptime-kuma instance, two are Forgejo Actions runners). For that I had to get some proprietary scanner software to run on it, which I could by just putting the extracted deb package in an emulated FHS environment and setting up a service for it, all declaratively.
Even for interfacing with legacy systems and unusual stacks I don't think you will need the escape hatch. Anything that is buildable on and above the abstraction-level of "ensure a file is present at some path with some content" should be doable declaratively, and that includes setting up an unusual software stack and running it in systemd services to communicate with some other legacy system or whatever.
The escape hatch is there to modify how NixOS itself behaves, and modifying that should only be necessary to extend NixOS' core functionality. A quick search revealed that impermanence (https://github.com/nix-community/impermanence) and in some cases sops-nix (https://github.com/Mic92/sops-nix) use it, but those fundamentally extend NixOS with ephemeral root storage support and secrets management, respectively.
I've also introduced some light NixOS usage at work (3 hosts, one is an uptime-kuma instance, two are Forgejo Actions runners). For that I had to get some proprietary scanner software to run on it, which I could by just putting the extracted deb package in an emulated FHS environment and setting up a service for it, all declaratively.
Even for interfacing with legacy systems and unusual stacks I don't think you will need the escape hatch. Anything that is buildable on and above the abstraction-level of "ensure a file is present at some path with some content" should be doable declaratively, and that includes setting up an unusual software stack and running it in systemd services to communicate with some other legacy system or whatever.
The escape hatch is there to modify how NixOS itself behaves, and modifying that should only be necessary to extend NixOS' core functionality. A quick search revealed that impermanence (https://github.com/nix-community/impermanence) and in some cases sops-nix (https://github.com/Mic92/sops-nix) use it, but those fundamentally extend NixOS with ephemeral root storage support and secrets management, respectively.
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.
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.
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.
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.
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.
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.
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.
> 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.
on nixos anything that you do has to be explicit in your config and thus it can be undone as needed.
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.
So TL;DR -- because most programmers can't describe a use-case if their lives depended on it.
> 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.
That's because "I think X sucks/is useless" isn't really a very useful comment in terms of the HN guidelines unless you're inviting discussion about the merits and drawbacks of the solution.
---
The other day, I upgraded my Ubuntu and it broke my display manager for some reason. I spent several hours debugging it. Given that investing in a niche technology where you won't get as much support as for e.g. Ubuntu (or even mac/win) has its own set of drawbacks, that isn't enough to make me switch to NixOS (problems like this really only ever happen every couple of years), but I do think that this isn't something that should normally happen. With NixOS, it would have been easy to rollback.
That's because "I think X sucks/is useless" isn't really a very useful comment in terms of the HN guidelines unless you're inviting discussion about the merits and drawbacks of the solution.
---
The other day, I upgraded my Ubuntu and it broke my display manager for some reason. I spent several hours debugging it. Given that investing in a niche technology where you won't get as much support as for e.g. Ubuntu (or even mac/win) has its own set of drawbacks, that isn't enough to make me switch to NixOS (problems like this really only ever happen every couple of years), but I do think that this isn't something that should normally happen. With NixOS, it would have been easy to rollback.
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.
[deleted]
So if it's not reproducable, what is it good for? To recreate similar environment easily?
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).
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.
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.
It is reproducible only with a narrow definition.
Usually "deterministic" is used instead to describe this.
Usually "deterministic" is used instead to describe this.
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 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.
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.
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.
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.
If NixOS works well for you, that's great! But from my perspective, the whole NixOS model adds unnecessary complexity and makes you learn ways to do things that don’t really translate to other Linux systems. The directory structure in NixOS is different and doesn't follow the FHS (Filesystem Hierarchy Standard) and the system uses a bunch of symbolic links that feel like "hacks" to keep some kind of compatibility with the FHS.
For example, if you want NixOS to recognize paths like /bin or /usr/bin in your scripts, you have to enable services.envfs.enable in your configuration.nix or in a .nix module. If something goes wrong in NixOS, you might run into multiple issues because the problem could be within NixOS, the underlying system, nixpkgs, upstream packages, or a mix of all these factors.
Sure, it might save you time in some situations, but when a problem pops up, you'll find yourself in a tricky spot since you’ll have to dig through all the layers of the system to find the root cause. On top of that, you’ll have to sift through the options and the documentation, which can often be pretty confusing.
For example, if you want NixOS to recognize paths like /bin or /usr/bin in your scripts, you have to enable services.envfs.enable in your configuration.nix or in a .nix module. If something goes wrong in NixOS, you might run into multiple issues because the problem could be within NixOS, the underlying system, nixpkgs, upstream packages, or a mix of all these factors.
Sure, it might save you time in some situations, but when a problem pops up, you'll find yourself in a tricky spot since you’ll have to dig through all the layers of the system to find the root cause. On top of that, you’ll have to sift through the options and the documentation, which can often be pretty confusing.
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.
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.
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...
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.
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.
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.
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.
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:
echo foobar
>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).
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.
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.
HPC under Inria. Giving how young Guix is, lots of companies rely on it.
>Tens or hundreds
You never wrote a single line or Scheme or Common Lisp and it shows.
No one writes thousands of nested lines down. They modularize it into functions because Lisp was basically made literally for that.
Get some Emacs modules and code, such as Mastodon.el. Look at the source code. Far easier to understand than any C or C++ codebase, not to mention Rust.
>Tens or hundreds
You never wrote a single line or Scheme or Common Lisp and it shows.
No one writes thousands of nested lines down. They modularize it into functions because Lisp was basically made literally for that.
Get some Emacs modules and code, such as Mastodon.el. Look at the source code. Far easier to understand than any C or C++ codebase, not to mention Rust.
> you end up not knowing what it's doing even if you're an "expert"
Oh you've tried Haskell then?
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.
Isn't most non-free stuff installed in /opt or in the user homedir these days anyway?
is this not the retcon of the century? hasn't reproducibility / consistency been an alleged selling point of nixos for a long time? it sure as hell isn't the ergonomics of the nix language, nor that of the ecosystem...
maybe
> A build is reproducible if given the same source code, build environment and build instructions
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).
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).
assuming that "build environment" includes more things than the author does (*it's* *not* *exactly* *a* *well-defined* *term*)
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
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.
My point is: without very precise definition of "same build environment" all discussion of reproducible builds are almost meaningless.
> 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.
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.
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.
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.
> as computers are deterministic
I have some bad news.
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.
simonask(1)
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!