Hacker News Reader

Comment by bongobingo1 | Hacker News Reader

Ive always loved the idea of nix, but feel like I've read numerous, if not horror, at least uncomfortable stories about the actual real-world experience after the initial "setup yak shaving" is done - which is often exciting for "us", it's the new project problem solving part before it falls into the boring "work" part.

If I have an arch system now, how useful is it to use Nix or Homemanager on a non-nixos linux system? I dont really want to dump a working system and duel booting always has whatever you need on the other system.

Do you get anything when not using NixOS to manage everything? What good is it if half my system is installed by pacman, half by asdf-per-project and the rest by nix? Has anyone gone down this route? What is the actual lived experience of half-assing it?

View on HN

It can get you two major things. Docker-like reproducibility for any development project in a much more convenient way. And the ability to try lots of software without installing it.

For me, the last one is a gamechanger, as I am no longer worried about littering my system with tons of dependencies. Say I want to convert an eBook I downloaded. I can quickly use Calibre for a one-off thing, with nix run nixpkgs#calibre.

I get Docker-actual reproducibility with Fedora Silverblue and toolboxes. Enter one of my Arch/Fedora containers, install Calibre without affecting the host. Even better than Nix because I can test custom distributions, rather than each environment simply being another NixOS.

In fact, I've departed from vanilla Silverblue, as now my base image is an actual, bona-fide Docker container as well.

I feel like the immutable Linux OS is the pragmatic approach, whereas NixOS is the pure, ideal way that requires a lot of changes to tools and workflow to work. Maybe even in this case, worse is better.

Yeah, Silverblue is pretty great. But Nix and Silverblue both require changes to your workflow. I like Nix more, but I don’t think one is objectively better.

I'm new to nix/nixos but gradually building up my environment.

it's like having your whole OS in git. it's amazing. want to try out some nightly build? no problem.

on most computers (personal, home computers) the various lib dirs get scary after a while. repoquery can help, but is kind of a hassle. if some executable `foo` depends on some specific behavior in some version of some library, it's fine. that weird library can stay in place, I can try out nightly's of foo, can always rollback to the system that used to work, and can flip to the new foo when it's ready.

I think it's a good practice to wipe and re provision from time to time to make sure provisioning and backups actually work, but like, you can screw around with _crazy_ things and not really have to worry about having to rebuild the whole thing. (well, I haven't yet) I still will, because that's how I am. but I can do it when I feel like it, not when I fucked up. it's so easy to un fuck a nix system.

I guess the big caveat is, this is a hobby. I haven't used nix for work. Back in the day, I did support docker in production when the kernel patches were coming pretty quickly. Finding the right balance of patch level, and libc version, that would support docker, and the other stuff that needed to run was a pretty complicated dance, and missing a step would be, not great. Knowing what I know now, even as a hobbyist, I probably could have made my life a lot easier back then.

Exactly, I have been a huge distro hopper to the point that having the same install for a month was already at the high end (though I did keep my home partition).

Now I have 2 years old NixOS installs on personal machines and they do not get bloated with packages that the package manager can no longer handle, and is basically always at a state as if it were freshly installed. It just “feels right”. To me, that makes the occasional edge cases worthwhile to suffer through (some binary package, mostly) - especially that in most cases something like steam-run is enough to make it work. When it isn’t, systemd-nspawn can boot you into any systemd distro you would want.

I also really like flakes. I know they are still experimental today - though hopefully that'll improve with this RFC - but they make it trivial to have an out of tree package. For example I just recently created a flake for a vendor OpenOCD fork [0] - and now I can reference that in my home-manager config or from some other project.

[0] - https://github.com/benpye/openocd/blob/mrs-2023-08-07/defaul...

This is already solved by Docker. I know Docker has a bunch of issues and Nix is clearly a more elegant design, but in practice Docker works fine (at least for my use case).

It's really not. Docker is a tool for binary distribution. Docker images are those binaries. Dockerfiles used to create Docker images don't have any mechanism to ensure reproducibility whatsoever. Unlike Nix, you can't take a Dockerfile and expect builds to succeed.

Furthermore, Docker images are monoliths that's isolated from the system. Instead of system administrators choosing the isolation boundaries that best fits their requirements, the image packagers put walls around each and every image. As a result, Docker containers are inflexible compared to traditional Unix applications. Piecing together multiple Docker containers is a clunky experience.

In contrast, Nix is an integrated build/configuration/deployment system. Entire systems down to the package level can be reproduced from Nix expressions.

It also gives system administrators power over the whole process. Administrators have control over things like how each components are pieced together, and where isolation boundaries are placed. They can even make tweaks to the package build steps.

Docker can't substitute Nix. It's not a matter of elegance. Their features and capabilities are wildly different.

I agree for the most part except I don't find that this matters in practice:

> Dockerfiles used to create Docker images don't have any mechanism to ensure reproducibility whatsoever

simply generate it once and keep it as an immutable artefact

I don’t know the value of half-assing it, but committing your full ass is amazing. Don’t abandon a working system, but the next time you wait a whole three weeks to pacman -syu and your GPG keys are out of date and everything goes to hell… give it a shot.

Honestly, it’s Home Manager that really adds the maximum value, and getting all the way there takes a full weekend, but what were you gonna do anyway?

I don’t know the value of half-assing it, but committing your full ass is amazing.

Indeed. As no less than Ron Swanson rendered unto us - an exemplar in classic American yarn form:

https://youtu.be/k6hZ9KdG1QU

... wise words.

> Honestly, it’s Home Manager that really adds the maximum value

I feel like Nix does have such killer features, but they are different for everyone.

For me it was:

- system management (nixos + nix-darwin. I wish there was something like nix-darwin for non-nixos linux distros, binding daemon systemd units and desktop files into the "hosting" distro)

- on-the-spot running without globally installing for one shot tasks (nix-shell -p iotop --run iotop)

- "just works" project environment (default.nix+shell.nix or flakes)

These are the ones that made me tip over and decide to go from tiptoeing to full tilt

I don't really see the appeal of avoiding to install programs. What's the benefit, exactly?

Not needing root is a game changer.

Another benefit is that "traditional" package managers may litter your system with configuration files and post-install scripts (for the software you are installing and all of its dependencies), some of which can persist even after uninstalling the packages.

Nix prevents that by design.

One less thing to manage and think about, including cleaning up after myself. It may pull dependencies that I don't care about or want exposed e.g that would be picked up by some other thing as with traditional package managers (e.g a configure script would pick installed stuff). apt-get autoremove --purge or pacman -Rsc become a distant memory.

It's fire and forget and I can just focus on what I'm set to do.

Once I'm done with the one shot task, it disappears and could be garbage collected for all I care.

Some tools I did promote to being part of my user env but crossing that bar is a very deliberate thing, some are promoted to systemwide (root) and the bar for that is even higher.

It removes a ton of mental deadweight.

Yeah, nix-darwin is incredible. Use cases you mentioned are great; for me, I love being able to use my NixOS machine and MacBook to seamlessly carry around the same dev environment.

https://github.com/dustinlyons/nixos-config

> I wish there was something like nix-darwin for non-nixos linux distros

It's in early stages, but it exists now: https://github.com/numtide/system-manager

> but what were you gonna do anyway?

go outside, talk to friends, do something productive, etc...

I use home-manager on Ubuntu on my work machine. You have to pay the full learning curve of Nix. Once you do, it works just fine. I think there comes a natural pressure to use Nix for as much as possible and slowly cut down one's dependency on the "base" system when you go this route. Maybe that's just because I want to see my investment in Nix pay off.

I would say that the biggest benefit you get is the hugeness and currentness of nixpkgs and the fact that it becomes a lot less important what software you have "installed".

It's fine, just be sure you know where your tools are coming from (use the which command a lot when unsure). Nix might have more up to date or bleeding edge software, although since you're on arch in my experience nix can lag even arch by a little bit.

Fully reproducible environments with home manager and nixos are neat but IMHO you can just use ansible to do the same thing on debian, arch, etc. if those systems have the packages you need.

When you inevitably find software that isn't in nix (or are packaging your own software), be prepared to take a quantum leap in complexity as you now need to fully understand the nix language and its concepts like derivations. This isn't necessarily hard but it is not documented well at all, and there are factions in nix at odds with each other (flakes vs. nix-env) which make learning it even more confusing.

> When you inevitably find software that isn't in nix (or are packaging your own software), be prepared to take a quantum leap in complexity

I think this is where most of the "i went back" posts I read came from. That and hitting issues with programs that expect to be able to write to some XDG dirs.

> When you inevitably find software that isn't in nix (or are packaging your own software), be prepared to take a quantum leap in complexity as you now need to fully understand the nix language and its concepts like derivations. This isn't necessarily hard but it is not documented well at all, and there are factions in nix at odds with each other (flakes vs. nix-env) which make learning it even more confusing.

Exactly this was why I am so hesitant to switch to nix. I tried to dig into the details of nix, language, derivation and whatnot, but documentations and community discussions are, in my experience pretty segregated that left me confused, and I eventually went back to arch.

In 90% of the cases it is as easy as modifying the earlier version’s version and hash. I think learning nix from outside-in is perhaps easier - grep for something you are looking for, and as if it were a language and you are a small kid, imitate that.

Though I will give you that there is enough complexity in specifying which nixpkgs/flake gets built, where is it places, etc as is, especially with the `nix-\w+` vs `nix \w+` variants being slightly different, to the point that I always have to look it up in the man page/in my history whether I need -A and the like.

Sorry to be blunt but I've seen nearly exact comments as yours and they come off as someone who hasn't really used Nix and doesn't understand the value proposition and the problems it solves.

I've used Ansible for years, then moved to Nix and have been on it for a year and a half. Yes the configuration language is more complex than Ansible's but it's also way more consistent and predictable. The bit of complexity comes with a lot of additional benefit. Ansible half-asses it, only giving you idempotency if you stay within certain boundaries in how you write configs. And a leaky system is a system that will break. Making it even worse is that you are building on top of a moving target with a distribution underneath that will break your Ansible scripts regularly as the system changes. Ansible is a huge mess and not suitable for the job IMHO.

With NixOS, the entire system is controlled by config, so there is only one source of truth for the state of the system, unlike Ansible. This is a fundamental flaw. Ansible is a hack on top of pre-existing setups.

With Nix, my system only gets more stable with time. It's the opposite of anything I've ever used, where systems get crufty and have to be reinstalled every couple years. Since the state of the system is fully determined by your config, you can always get to an exact state without a bunch of extra shit missing or added.

And the language isn't really that hard for anyone who's done a bit of programming. It's certainly easier than most general purpose languages, as it's static data 90% of the time with a bit of logic thrown in when needed.

fwiw nixpkgs has significantly more packages than arch (including the aur), and those packages are also significantly more up to date. No other repo comes close to nixpkgs in this regard. This has been the case for quite some years now.

https://repology.org/

I also like that packages in Nixpkgs goes through code review.

How many of these are duplicates or just multiple versions though?

Repology already attempts to account for that, and Nixpkgs normal policy is one version per package unless there are specific reasons for it to be otherwise. Nixpkgs doesn't duplicate packages just to have alternative build options or whatever like the AUR does.

iiuc the “non unique” section on repology accounts for this. nixpkgs is almost twice the size of the aur if you count like this.

> It's fine, just be sure you know where your tools are coming from (use the which command a lot when unsure). Nix might have more up to date or bleeding edge software, although since you're on arch in my experience nix can lag even arch by a little bit.

That'll depend if you're on stable or not. If you're on stable and you need something from unstable that's also possible without any real risk of breakage on NixOS.

Also, once you've learned the ins and outs of Nix (which TBH I didn't find as hard as others, there's tons of examples) it's usually pretty simple to update software yourself--relatively risk-free. For example, I've been keeping Minecraft on the cutting edge for my kid by occasionally updating a URL and hash. A lot of the modules provide a 'package' option to make that easier.

Yep, a lot of the time it’s as simple as overriding the src and version of a given package -though if the package has patches to build on Nix it can be more work.

> Do you get anything when not using NixOS to manage everything?

Sure, I think the biggest benefit is being able to get a temporary environment for a project. You can have all of your dependencies pinned, even for languages that don't have package managers, and for mixed-language projects. You can get easily get a shell that contains the exact compiler versions, libraries, etc. from a single config file, and it's isolated from the rest of the system. I guess it's kind of like having a lighter-weight container.

It's no lighter than a process running in docker, on a Linux machine at least. With docker you have a whole root filesystem packaged up and a process inside it is executed on your system with certain kernel namespacing to set its root filesystem, users, network access, limits on memory and CPU usage, etc.

With nix instead of a tarball being the root filesystem it's a bunch of symlinks to stuff in the nix store directory--the process you run is exactly the same as whatever you're running in docker.

One crucial difference is that nix does nothing for network isolation, you have to do all that on your own (if you need it).

Nix doesn't do network, PID or filesystem isolation.

That's a feature. I don't normally want any of those.

You don't have to use them, docker has flags to disable things like network isolation. If you want to go deeper systemd-nspawn doesn't isolate anything (network, pid, user, etc.). And if you are some anti-systemd zealot the plain old chroot command does what you want too (and has done so for decades).

Except none of those solutions are package managers, are they? The thing that's nice about nix is that you can just specify which packages you want by name, and easily get them in your path.

My thoughts exactly. Container-based development environments has a Cygwin-like clunkiness to it. But even clunkier because of the default lack of access to the host system, and the additional burden of having to manage multiple containers.

Just to be clear, Cygwin is a great project. But it's not something I'd actively choose over a native Linux system if I had the choice of operating systems.

It’s a lot lighter in terms of disk space. Yes, drives are cheap, but even so, bringing in a different version of debian-slim for every executable gets bloaty. I routinely reclaim 10s (sometimes 100s) of gigs with a podman system reset.

Also in RAM. You don’t want to runa whole-ass container for `ls`.

No a process running in docker or on your host is going to use the same amount of RAM. There is no RAM dedicated to a running container on Linux--it's just a process that's flagged with some metadata to tell the kernel that it should be isolated in certain ways, like with a unique root filesystem.

Loading in the whole container though does increase the necessary RAM — with nix, two versions of the same executable can link to the same hash, but it is unlikely to be the case with Docker.

Your kernel is fine at managing the container root filesystem and paging in and out parts as necessary. It's not just loading gigabytes of root fs into memory and calling it good.

Files still take up space on disk.

Paging still has a cost.

By lighter-weight, I simply mean conceptually, not necessarily computationally.

The biggest advantage is the ability to reproduce your mutable environment‽ You get more advantages when the whole environment is reproducible.

I am forced to run both, work needs Intune which needs Ubuntu (I'd use NixOS everywhere if I could). Here is my config, but be warned it'll probably confuse a newcomer: http://codeberg.org/jcdickinson/nix

My config/flake is cleaved in two: one for NixOS (which isn't used for Ubuntu) and one for "Generic Linux" (which is used everywhere). I used to have nix-darwin in there too, but Intune on Ubuntu has allowed me to retire the work Mac.

The second-half is where the real value lies (my NixOS config is actually really minimal, just enough to get into sway). I use home-manager to manage all my dotfiles. I switched work laptops recently and nix+home-manager brought up the environment in less time than it took to install Ubuntu - and that's a full desktop replica (Gnome plugins, hotkeys, installed apps, nvim config, and everything).

The next big benefit is direnv integration. Direnv itself is bloody fantastic, but add nix to the mix and you have a whole new level of magic. If there is an in-tree flake I can just echo `use flake` to establish a dev environment with all dependencies, at the right version, through the mere act of cd'ing into that dir. If there's no in-tree flake (as is the case with my work repos), I can use one of my dev-shells with e.g. `use flake $HOME/Nix#cmg-js` (assuming I've cloned my config to ~/Nix).

There's no real reason for me to use NixOS on my own machine, but I do love the boot speed and the ability to roll back. I'm pretty fearless when changing my OS config. The nature of Nix means very little beyond what you explicitly demand is installed, and it keeps snapshots of your previous configs. It's not mandatory at all, though. Home-manager is where it shines.

> Do you get anything when not using NixOS to manage everything? [...] Has anyone gone down this route?

Yeah, for sure! I don't use Nix this way very much on Linux because I mostly just use NixOS. But I use Nix this way on macOS at work every day, because that's the Unix desktop that's available to engineers there.

By not going full NixOS, the tradeoff is that you suffer some minor integration issues, and in return you get some more escape hatches. This is a pretty good option for some people imo.

Declarative system config on non-NixOS is a bit more work, because you either have to write your own sort of metapackages with buildEnv¹ or use a third-party module system like Home Manager, System Manager (that one's in very early stages, so pronably skip it if you're a newbie), or Nix-Darwin. The latter are really nice, but you might have to think about how they plug into things like your OS's bashrc file sometimes, and sometimes their install procedures are kinda wonky.

The other main integration quirk to watch out for on non-NixOS is 3D graphics acceleration. Check out nixGL and you'll be covered for that.

Using Nix for nifty per-project development environments, though, is pretty smooth and basically identical whether you're on NixOS or not. If that's an interesting use case for you, Nix on non-NixOS is worth checking out.

Nix as a package manager for CLI tools that don't depend on the base system, or trying out software without permanently installing it, is also kinda nice on other distros. It's especially nice for running newer software on top of stale distros, but it can also take you in the other direction, which might sometimes be useful on Arch.

I think the head first approach of just committing to daily driving NixOS can be good for some people, and it certainly was for me. But learning your way around the Nix language and developer tools by focusing on developer environments and oddball packages on a foreign OS can definitely make for an easier, lower stakes learning process.

> What good is it if half my system is installed by pacman, half by asdf-per-project and the rest by nix?

If you're not using Nix for any per-project stuff, you're definitely missing some value, as that's likely among the first low-hanging fruit you'll encounter on your Nix journey.

That said, stacking Nix with other package managers and only using it where it makes most sense is totally viable. On macOS, I use it in combination with light use of pkgsrc and Homebrew. You can definitely do the same kind of thing on Linux.

I'm running home-manager on arch and it's fantastic. I'm only using it for cli/tui programs, as I've had trouble getting gui software to correctly create desktop entries which show up in my menus. You can use it alongside pacman just fine.

In the worst case scenario, you can just manually create files in your home directory if needed, so putting them under .local/share something should get you desktop entries (though depending on the desktop/window manager you may need a restart).

Yeah, I'd much rather just install with pacman than manage them manually though.

These options got GUI icons to appear for me (on Manjaro, an Arch derivative):

  targets.genericLinux.enable = true;
  xdg.mime.enable = true;
  xdg.systemDirs.data =
    [ "${config.home.homeDirectory}/.nix-profile/share/applications" ];

It depends on what you're hoping to get out of it. I mostly-whole-ass it, but I still use the mac app store and homebrew for a few things. Most projects are Nix by this point.

It's hard to tell from how you say it; if you aren't using it for any projects and would just be using it for a slice of your system/user packages, I suspect you'll end up not really seeing what the fuss is about. If you will try to use it with some projects, I'd start there and see how it goes.

(It should be fairly low stakes. If it doesn't stick, you won't disrupt yourself that much. If it does stick, you'll have a better sense of what you want to hand over to it and why.)

How do you personally use Nix on a project, any tips? Do you use flakes? What are first steps/basic scaffolding? I am eager to get into Nix but not ready to go full on (I'm also on Mac but some devs may be on Linux)

Is it possible with complex projects like based on Electron? Is it reasonable to use Nix in Docker (eg. I am on Mac but want to build it like it's on CI)?

> How do you use Nix on a project, any tips?

Combining nix with direnv is a popular combo for dev environments. Example: https://determinate.systems/posts/nix-direnv

If you haven't worked with nix before, the quick start here is a good place to start https://zero-to-nix.com/

> How do you use Nix on a project, any tips? What are first steps/basic scaffolding? I am eager to get into Nix but not ready to go full on (I'm also on Mac but some devs may be on Linux)

Not sure I can boil it down to tips, but: more or less any time I need to do something regularly that involves third-party code, I'll be using Nix to manage it. Specifics depends on the project. There are templates around (and templating is built into flakes via `nix flake init`), but I haven't used those much myself.

Maybe a sense of general patterns helps?

Most of my projects have at least a shell.nix (devShell expression in flake.nix) for setting up an environment to work on the project. I.e., add appropriate deps to path, define some utility shell functions, start up database servers and so on.

Sometimes that's all. For example, my blog just has a shell.nix for providing dependencies like hugo, gist, make, jq, etc., defining some helper functions for scaffolding new posts and such, and then I use Makefile targets for creating a dev build, production build, and publishing.

If it's something others might use, I'll generally have a default.nix/flake expression for building the package. Then I can use that for testing it, for integrating it in other projects or my own systems or whatever.

I'll often have one or more expressions for ~testing it. (If I have more than one, the first might be a straight test, and the 2nd might be a performance suite comparing it against similar tools, for example.)

If I'm researching several potential alternatives, I may build a Nix expression that builds all of them, pulls them all into scope, and then invokes them all to compare whatever I care about. Then I can readily repeat the same check locally, or go run it a bunch in CI.

If it's something I have CI set up for, I may bother to have a ~normal build that runs against pinned dependency versions whenever I make code changes, and then also set up a ~canary build that regularly re-runs my project's main/master against the latest nixpkgs so that I get some notice if something I depend on happens to be broken.

> Is it possible with complex projects like based on Electron?

I'm not familiar with the Electron packaging, sorry. I know it's doable because we've got a number of electron packages, but I don't have perspective on how easy it is and whether it's working on Linux and macOS or just the former.

> Is it reasonable to use Nix in Docker (eg. I am on Mac but want to build it like it's on CI)?

Sure. There's an official Nix container image, and some of our gitlab CI jobs use it. IIRC it's a little tricky to install Nix in a container imperatively, but I think the state of that has improved since the last time I needed to fiddle with our setup.

Thanks, this is super helpful!

> If I have an arch system now, how useful is it to use Nix or Homemanager on a non-nixos linux system? I dont really want to dump a working system and duel booting always has whatever you need on the other system.

100%, I recommend people to start with home-manager before NixOS as it's easier to escape the Nix when you're out of depth than if you're on NixOS. It'll manage your user systemd units and everything else within your user, it's great.

Reply on news.ycombinator.com