How I like to install NixOS (declaratively)

> This is a huge problem IMO, I can't run C/C++ or Python projects the "old way" and no one is willing to upend their build system and lock it into nix.

For Python I use uv to download & set up Python binaries outside Nix. To make them work I enabled nix-ld in my Nix config, so there's a default linker & libc they can access. Works well so far.

C/C++ is a PITA and I'm not a C/C++ developer, but I do find that I'm able to get around the issue 90% of the time using steam-run (although that feels kludgy as hell and I really wish there were a better option for getting linked libraries working normally). I think the real answer is to get good enough with nix to build a flake quickly for the project you're working with, but that seems like a lot to learn. Maybe easier if you're more familiar with C/C++ dependencies and build tools than me though.

Musnix looks really interesting. My whole audio setup looks like this in my nixconfig:

   hardware.pulseaudio.enable = false;
   services.pipewire = {
     enable = true;
     alsa.enable = true;
     alsa.support32Bit = true;
     pulse.enable = true;
     jack.enable = true;
   };

   hardware.bluetooth.enable = true;
   hardware.bluetooth.powerOnBoot = true;
   services.blueman.enable = true;

> This is a huge problem IMO, I can't run C/C++ or Python projects the "old way" and no one is willing to upend their build system and lock it into nix. Some languages work great and allow a clean barrier between system<>app. I use Clojure, Rust, Gleam, Go, Lua on nix without any issues, it does seem to be the C/C++ ecosystem and dynamic linked shared libraries that are the problem.

Depending on your individual use case you might find it sufficient to simply work on and compile software inside of Distrobox. It integrates nicely enough with the host system I think.

Personally, I usually do a small bit of hackery to get a good dev environment for C++ projects, using a combination of flakes and envrc. It's not exactly elegant, but you can re-use the Nixpkgs derivation for the actual dev shell. If you need to, you can even reuse the Nix patchPhase from the real derivation to apply NixOS-specific patches to your local tree temporarily.

The fact that it's possible to get a decent experience with not really that much effort kind of signals to me that it probably could be a lot better. On the other hand, maybe in a better Nix world, Nix could become even more integrated into both the dev and build process: with dynamic derivations the build process could be broken up into many smaller derivations and give Bazel-like behavior.

One thing I really enjoy about Nix is how easy it is to have different shells to use for different things without needing to pollute the system with tons of packages you needed for only one thing, but on the other hand the rest of the world doesn't integrate perfectly with this. For example, a lot of GUI text editors manage their own processes, so you can't just start a new window already inside of a shell. For VS Code derivatives the envrc extension kind of works, but it's a bit of a hack. A good improvement would be developer tools explicitly supporting this model, and as Nix seems positioned to continue to be gradually more relevant over time, I am hopeful it will become important enough for tools like VS Code to consider.

I have had a decent time, though. I have a mostly automated approach to getting working clangd and incremental compilation with pretty much any project, with just a little bit of mucking about with boilerplate.

> I know this says more about Musnix than Nix, but I think it highlights the advantages of configuring your system with a real programming language. All the "audio stuff" was able to fit behind a well-designed abstraction barrier.

I think it's a testament to Nix's promise. Abstraction with capital A!

It's most likely not C/C++ per se, but rather the eleventy billion ways different projects build these libraries.

Bazel for example builds everything in a well-contained sandbox and it all works, but only for the C/C++ libraries it builds natively. The magic ingredient is RPATH, but most Makefiles do not set it. However, one can add an extra build step with patchelf and inject an RPATH.

> Linux audio is a confusing disaster and I'd basically given up on Ubuntu

Have you considered buying a MacBook and valuing your free time more?

Another option is to run it ephemerally from the RAM. I have been doing this for my laptop and servers for years now. You can do so by declaring the following: https://github.com/ponkila/HomestakerOS/blob/main/nixosModul...

You need to then have a flake which defines a "package" like this: https://github.com/jhvst/nix-config/blob/main/flake.nix#L117...

Now you can run 'nix build .#starlabs' which will create you the files needed for kexec / PXE booting.

You can also write tests that these images actually boot ok: https://discourse.nixos.org/t/nixostest-with-flake-configura...

I started working on this stuff because I needed to somehow reliably update my homeserver. I live abroad 50 weeks a year, so I needed something reliable because I can't assume I have physical access to the computer. Even when the BMC firmware got screwed by ASRock motherboard firmware, I didn't need to sweat.

Now for the shameless plug: my company created a PXE server module which also supports flakes that assumes this ephemeral setup. It's described in here: https://github.com/majbacka-labs/nixos.fi

> I never really feel 100% confident that something is gonna work as I hope until I physically try it

I ended up in the same situation too, but discovered relatively quickly that NixOS makes it really easy to build clean VMs from your config that you can run and test against, then when validated, you apply the configuration to the actual hardware.

I'm doing this for all my servers managed with NixOS right now, and managed to prevent multiple issues being deployed, including something that would prevent a clean boot and since the host is headless, would have required me to connect monitor and keyboard in order to recover.

Really glad NixOS is setup the way it is, although you're right the learning curve is rough. At least I can easily re-install my infrastructure really trivially, which helps me sleep at night.

> I had _guessed_ that something like the "Building your own installer" section would work, but because of the nature of Nix I never really feel 100% confident that something is gonna work as I hope until I physically try it. Usually it does.

One of the most underrated features of Nix imo is the testing story. You absolutely can be confident that something will work!

https://nixcademy.com/posts/nixos-integration-tests/

> It does have a really harsh learning curve though.

Would it be possible to automatically translate all Nix build scripts into a language that is more ergonomic and fun to work with?

Glad to hear that the article describes exactly what you need :)

Try out building an installer and run it in a VM, it only takes a few minutes!

> I have recently adopted Nix and NixOS and it's been truly fantastic. It does have a really harsh learning curve though. Big downsides, but for me the upsides are so huge that it's worth it.

It's huge. I tried learning and exploring Nix Darwin. Went through at least half a dozen blog posts with "step by step" instructions. All different. All had some fatal error at some point even on a new install of macOS that was from moderate to impossible to find coherent help on.

I dtarted my Linux journey 3 weeks ago with Arch and Ansible to create a declarative system. The installing-part however was tricky, because I have a second disk with Windows and I want to use secure boot. And if I wanted to use Ansible, I would have to create a specific ISO. And then I would have to manually define the disk I want to use or run into the risk of formatting the wrong one and lose a lot of data.

Then I found NixOS, which is like Ansible, but better, because Ansible only adds information to a system, but NixOS also ensures that anything that is not declared is removed as well.

After three weeks, I realized that the effort to declaratively (or automate an imperstively) install the OS is such a lot of work that does not pay off if you're not going to install multiple systems each week or month.

How many commands does it take to actually install NixOS? You partition the disk which take 3 commands. Then you format it, which takes 3 commands. Then you mount the disks, which takes 3 commands. Then you install it, download your configuration and apply it, which is another 2-3 commands.

It takes 5 minutes vs whatever effort you put into creating a declarative installer and keeping that up to date. I also had to think of the time it would cost me to actually figure out HOW a declarative installation would work and the tools I would require. I reckon that the first 24 system would essentially be free (opposed to the 2 hours or so it would cost me to figure out declarative OS installations).

I decided that for me, it is not worth it, although I am the type of personality that just hates not automating things.

Interesting, I’m not sure how you managed to get conflicts between packages, that’s a violation of the Nix model. If you describe the issue more I’d like to dig into it, even if you don’t use Nix any longer it’d be nice to fix the issue for those who do.

> Almost none of the packages the author listed get used, including zsh

Just to clarify: the point of having packages like lshw and zsh available is not for the case of performing the automated installation (where, yes, they are not used), but for the case where I want to interactively poke around in a booted installer to inspect the target system.

> Note that the author used disko to partition the disk declaratively. Disko won't work for a machine with very limited ram, because disko run in the installer, and needs to install tools to the ram to do the partition.

This is only true if you use the disko-install tool, which is a horrible footgun[^1]. The safest approach is to just use the default disko command, then nixos-install.

[^1]: https://github.com/nix-community/disko/issues/947

The beauty of nix is that you can trivially build a custom installer - I do it all the time, for each different host. Since it is simple to do, you can choose to make trivial changes. You do not have to, but you definitely can.

I built something like this a few years ago. Essentially how it worked is you'd specify the path to a nix flake in the kernel parameters, and once the installer was booted it would pull that flake and run it (which ran the installer, formatted the disks and restarted the system). It was part of a larger project but I wonder how the nix team would feel about a small binary that would be included in the default installer image that does this

The language and the compiler infrastructure is for me the biggest problem. It's very hard to understand what is going wrong when it goes wrong. Most advice feel like copy pasting existing code without knowing what it does.

Learning this also complicates things as I am feeling overwhelmed with all the things needed for simple configuration structures instead of starting out with a simple program.

The language is bad but the module system is even worse. It’s another language implemented in the nix language. Zero hopes of an LSP or any kind of editor assistance. God have mercy on your soul if the docs for your piece of work are lacking.

Not a controversial opinion even in the nix community as far as I know.

I think a lot of people including myself feel this way.

I really like the Nix model of derivations and approach to deterministic builds. It's the language IMO that prevents it from getting mainstream adoption.

I think they would be best served by picking a subset of an FP language that already has good ergonomics and tooling.

it's the biggest painpoint. I got used to it, but still don't like it that much. I think there are some efforts to build some kind of VM so, in theory, you could put any language on top.

https://snix.dev/

Have you looked at Guix?

> I don't want to have to dig into a config file for every little aspect of my OS to be in working order

When I see comments like this about NixOS I feel like I must have been using a different breed of distro before and switched to a different NixOS than you did.

My experience has been that other distros—even the supposedly stable ones like Debian—are disasters waiting to happen with no clear way of understanding what goes wrong when you do an upgrade and it breaks. Instead of one config file to troubleshoot I have hundreds of config files that I don't even know about that might be at fault. Or it could be not even a config file, it could be that there's a version mismatch that can't be resolved.

For me NixOS's config file is a breath of fresh air. If something on my system breaks it's because I made a change to that single config file. If something on my system isn't working yet it's fixable in that single config file.

The system is far from perfect, but it's much better than the black magic that other distros lean on.

I think having to debug to find problem of your system is frustrating. But with NixOS, I at least won't be afraid of "breaking the system" or doing something "irreversible". This is totally a peace of mind when tinkering with my setup.

The Guix documentation is such a breath of fresh air after struggling with NixOS.