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!
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.
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.
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.
but from the description they seem runtime errors. do you have a functional test of sorts after nix creates the new state?
"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.
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.
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)
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.
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.
What are they testing? 99% of what exactly?
What does "path" mean, does it inflate the number?
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.
https://tests.reproducible-builds.org/debian/reproducible.ht...
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
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/
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.
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.
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
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.
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.
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.
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:~]$ 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)
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...
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)
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.
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)
The benefit is that just adding some package will never break your own configuration.
Nobody's perfect, you live and you learn it. I use Hannah Montanix btw
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).
> 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...
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.
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.
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.
And I don't even need Nix to do that; there are much simpler ways to do so.
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?
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.
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.
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.
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.
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 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'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.
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.
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 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.
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.
Did it ever happen? Last I've checked flakes were still experimental.
> 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.
on nixos anything that you do has to be explicit in your config and thus it can be undone as needed.
So TL;DR -- because most programmers can't describe a use-case if their lives depended on it.
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.
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.
Usually "deterministic" is used instead to describe this.
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...
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.
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.
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.
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.
Some simple example I found just now:
https://unix.stackexchange.com/questions/489509/how-do-i-mod...
On config files, Guile is not that difficult.
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.
Changing a licence on some software doesn't change the compilation. The licence is completely orthogonal to whether software is reproducible or not.
echo foobar
Reproducible, compiled and free are all orthogonal.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).
>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.
Oh you've tried Haskell then?
> A build is reproducible if given the same source code, build environment and build instructions
It is very strange definition. To me it is tautological, as computers are deterministic and if you have same build environment you will get same results by necessity.Same bits into input - some bits out of output.
Edit: formatting.
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*)
It is exactly my point. What is "build environment"? This definition is crucial for defining "reproducible builds" and we cannot handwave it away.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.
My point is: without very precise definition of "same build environment" 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.
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.
I have some bad news.
Redeploying a machine has never been easier for me as all of my config is stored in a git repo in a few .nix files. I don't need to remember what I installed or configured somewhere in /etc five years ago, I can just look in the .nix file for that machine. Everything I configure or install is synced across my desktop and laptop through imports (unless specified), which makes the experience very seamless.
When something goes wrong e.g. after an upgrade, I just reboot and choose the previous generation from the boot menu. If I just want to try out a package, I can get a temporary shell where that package is available. If I don't need it after all, it just gets garbage collected.
When working on a project, I can use a dev shell where everything I need to build/test that project is isolated so I don't pollute my root namespace.
I get a new computer once every few years and getting my usual programs installed is no more than a few hours work at most. I have 2 computers, one for work and one for private. Syncing installed programs is neither necessary nor particularly wanted; I don't want Steam on my laptop, nor do I want to run postgres on my private system. The only time an upgrade breaks stuff these days is when a kernel update needs the drivers to be recompiled. The command for that is stored in a file on my desktop and takes less than a minute to find, type in and wait until everything is fine again.
Regarding unwanted packages and "namespace pollution", every once in a while I install a program that is used once or twice and then forgotten about. This doesn't impede my normal workflow at all.
So the benefits of NixOS would be minimal for me, while the onboarding materials and documentation are pretty atrocious. The effort/reward ratio is just not there.