I'm not sure if avoiding Home Manager is the right choice for everyone, but it worked well for me.
Home Manager isn't necessary for declarative management of the user environment -- Nix flakes can do this, too. A long time ago, I kept a single `flake.nix` in my home directory describing the packages that each of my machines needed, and ran `nix profile install .#packages.<machine>` to install them into my user profile. By doing things this way, I learned a lot about writing flakes, and this transferred to other places I used Nix.
What this doesn't do that Home Manager does is dotfile management, but that's actually why I avoided HM originally. First, HM's approach is a bit clunky for my taste: each change to the configuration must be followed by running `home-manager switch` for the changes to take effect. I found this to slow down the edit-and-test loop when making changes to my shell config, etc. Second, the idea of doing all configuration in the same Nix language is cool, but most of the documentation found online about configuring, etc., `git`, will refer to the tool's usual method of configuration.
So instead, I made a quick Python script that manages package installation with Nix, and dotfile management with GNU Stow. The dotfiles and Nix configuration all go into the same git repository in my home directory, so they are tracked together. I've been using this approach to manage several machines for a few years now, and it's been more than sufficient for my needs.
In addition to that home-manager does not have have the same value NixOS modules have. You are mostly translating configs and not receiving big parts which are normally copied from the documentation for free.
Oh! The lack of (what I now know is) Home Manager is what made me drop Nix not long after trying it out briefly a while ago (well, several years now, maybe 2015-16). I really liked the sound of having all my config declarative and managed through Nix, but it's almost all in home - not everything even has system-wide config, and anyway it's easier to version control.
So that's just to say I think it at least warrants a mention, it's helpful for a beginner to be aware of, even if they don't use it (once informed they can decide for themselves if they need that piece or not).
Some people may enjoy going through an enormous learning curve to do configuration like that, but the benefits there are pretty abstract and personal, and the pressure to make the onboarding any easier is very low. It's partly because these kinds of users are willing to (a) suffer through a lot in the name of learning and feel good about having done that, and (b) read and write what appears to be a dozen book-length tomes of documentation, that it doesn't get any easier for beginners. I know because I was also one of them in 2015-16 or thereabouts.
Nix doesn't need any more home-manager tutorials, because it doesn't need any more small-time tinkerers. It would benefit more from becoming essential to a bunch of businesses who will become invested in making their own developer experience acceptable at scale, and who will have to improve Nix to that end.
Pretty soon a bunch of people are going to realise they actually do need the exact same version of every tool in every toolchain on every machine in a team, to make use of the transformative caching abilities of tools like Bazel and Buck2. And if that catches on, I would not be surprised to see an alternative Nix frontend configured in Starlark, like every other tool in that arena. There's already a buck2-nix that generates dhall under the hood.
I do sometimes think Linux could do with being single user, and retaining a separate no-login non-user ('roles'?) permission system for 'mail', 'cups', and the like.
As far as I'm aware multi-user (as in human login users) Linux systems are almost entirely - literally - academic. Supporting it does leave some warts and complexity to be experienced by the majority single-user system users.
Im a beginner and am working through getting Nix + Home Manager + Darwin working. Currently I am only setting it up on a MacOS vm's so I can nuke everything, but the end goal is to install it on my host system and manage everything I can with it, including home-brew.
Yes, home-manager + darwin is added complexity that is making this harder for me; when I am encountering problems I am not always clear on where in the three systems it lies. But I probably wouldn't be journeying into Nix if it wasn't for home-manager + darwin; what I want is managing my workstation and setting up ad-hoc development environments, not configure servers.
I'm a beginner, and I set up my system with Home Manager and on MacOS Nix Darwin. It works extremely well, and both Home Manager & Nix Darwin are quite well-documented. The hardest part was figuring out the different arguments to various Nix functions (sometimes I wished Nix had types).
I started with just Nix-Shell in WSL with Home Manager. Then I have kept adapting that file for my Linux, OS X, and other needs. I didn't touch NixOS at all until years later. I'm really, really glad I started with Home Manager. It delivered value immediately, and I was instantly sold on the value proposition of a declarative file to manage dependencies with other associated benefits from the Nix world.
Quite the contrary. Home-manager is literally the only thing that's worth using Nix. Anything beyond that is far too esoteric, unsupported, non backward compatible and continuously broken.
My dotfiles managed by nix(-darwin) and home-manager breaks every time I update my pins, and I find myself having to bisect which commit introduced the issues. Given that, I just don't see how that would scale to a full OS, let alone to a team at work. 1000% better simpler with understandable Dockerfile and Kubernetes YAML manifests, or with Ansible YAML. At least every folk can StackOverflow and ChatGPT it to a working state, and have it work for a considerable amount of time without further maintenance.
Unless I'm misunderstanding something, this is precisely why I don't use Home Manager. I've literally never had my NixOS setup break over the course of many years.
Ya their comment does not match up to my experience at all. When I update my lockfile it very rarely breaks and if it does I just roll back a commit and wait a day and it's usually fixed.
This is... sort of the point, too. Rolling back is insanely easy - and it's version controlled so even if something obnoxious happened you (should) know the exact commit that broke something as well.
In the very worst case, you update components individually until you find the offending one.
I've used both NixOS and nix-darwin for 2 years professionally now as daily drivers, and have had generally nothing but great success. I'm not fearing an OS update actively breaking my environment (which I can't say the same for macOS, as much as I am a fanboy of Apple).
Sorry for the harsh words but you don't have any idea what you are talking about.
Some examples: managing patches for applications is doable with NixOS. With overlays they survive updates and if they no longer apply, build fail before they can have production impact. Doing the same with docker is a nightmare and different for every dockerfile without a common interface around it.
Ansible takes the previous state of the system into account which is terrible if you want to manage it fully declarative. Worst case in NixOS you do a reboot and your config applies almost no matter the previous state.
And that you can leave something running without maintenance is naive and it will start to slowly rot.
I think there’s a consensus around a gap Witt respect to documentation, forums, porcelain, etc. in Nix world.
But with all due respect, asserting that everything outside of home manager is “not worth using” is fertilizer.
The fact that smart companies (TailScale and Shopify come to mind, but there are zillions) are willing to cope with those (obnoxious) gaps is very, very strong evidence that there’s a lot worth using.
git was considered too hard, inadequately documented, maliciously baroque for years before GitHub happened.
Nix solves a harder (and more important) problem in a similar way.
Debian documentation has usually the same gap but there are many resources out there how to get things done but not necessarily the way debian intended which can break things on updates or name them unnecessarily hard.
While I can read it, I also think higher-contrast would be better. Always a bit weird when people take this kind of criticism as a chance to say they can deal with it fine and it must be a personal problem if you're not okay with it. Reminds me of ergonomic mice/keyboard discussions where people will start accusing you of having weak hands or something even though ergonomic improvements would benefit everyone.
Those look perfectly fine to me over here. It's probably a browser rendering difference or some day/night mode style difference. (Or this... https://colormax.org/color-blind-test/ )
It depends on the total contrast on your screen. Unfortunately...
On a high-contrast, high-brightness screen, white on black becomes glaringly bright and produces halos, while a pure white background actually hurts your eyes. So you default to gray-on-gray because that's what's pleasant, while higher contrasts are used in scenarios where you want glare.
(Games and photographs, mostly.)
On a low-contrast screen, which describes a lot of cheaper hardware, the exact opposite is true.
The real issue is it's all relative to what your display hardware can do, instead of using absolutes. HDR modes fix that, but HDR is still rare.
I found this interesting. I picked dup NixOS a few months back using configuration.nix and home.nix and completely avoided flakes all together because it was an experimental feature that will have breaking changes going forward.
I feel like this book jumps into flakes too soon. it should have more around the configuration.nix file, its purpose and uses, and then show systematically why one may need a home.nix file and then maybe show why something like configuration.nix/home.nix might not serve some users (and then introduction flakes for those individuals.)
i went this same route and was actually looking at flakes wondering "Why is everyone using something that's not stable"
it took a ton of time before I finally switched to flakes. They really need better messaging about this because the environments are incredibly complicated.. the possible choices are cumbersome.
The problems are a matrix of
- root daemon or non-root daemon
- nixos or non-nixos
- home-manager or non-home-manager
- what OS are you on?
- flakes or non-flakes
- stable or unstable
i'm happy with nix and love it but i definitely stumbled on al lof the mentioned
I'm expecting to receive my shiny new Framework 16 laptop in the new year. It will be my main workhorse/development machine. I vacillate between learning Nix and giving that a go, or sticking with Arch+Ansible to manage it.
I use NixOS as a daily driver. (My previous Linux of choice had been Arch).
I'd describe Nix as 95% wonderful, 5% hugely painful.
I learned Nix by using it on macOS/Linux before trying NixOS. I was concerned that NixOS would be very difficult to use.
It was easier to use NixOS than I expected; the main problems I ran into were when a tool would helpfully download some kind of binary, but since NixOS doesn't put its shared libraries where other Linuxes do, these programs wouldn't work. -- Though, for a popular-enough tool, most likely someone else already has a Nix package written that helps out.
There are other "escape hatches". e.g. I think something like distrobox could be used if native-on-NixOS stuff has problems. https://github.com/89luca89/distrobox
Nix can otherwise be difficult if you need to write some Nix code. There are several concepts in Nix which are foreign enough to how things have been done before; e.g. when building a package, it won't have access to $HOME; but, recent language tooling will often want access to $HOME. -- If something goes wrong, you may often need a wider and deeper understanding compared to if something goes wrong on a more typical Linux distribution.
For as difficult as it is, the trade-offs Nix makes are essentially "I'm going to put in a lot of effort now, so that I don't have to put in effort some time later". (This favours Nix when "effort later" is multiplied many times).
Overall, as a choice for "I need this to work right now", I'd recommend against NixOS (especially for someone who doesn't know Nix).
I use NixOS on a server and it is wonderful there where my needs are basic and on the well worn path.
But there's no chance I would want it on my development machine. Even something as simple as installing a python package that isn't in the main repo doesn't have a straightforward solution. There are half a dozen different approaches people take, almost none of them well documented. And most of them involve writing 50 lines of esoteric nix, your own derivation, or a complicated flake (which everyone says to use, but there isn't good documentation). Maybe it is great for those on the inside, but from the outside it looks like a disaster. And that's the last thing I want to deal with when I need a package installed to get my work done.
Flakes has an unfortunate past [1]. The fact that so many people are using Flakes now and treating them as stable makes it effectively impossible to make drastic changes, even though the design is flawed in many ways [2]. Nevertheless, the Nix team is discussing the stabilisation in recent weeks, with the tendency to not make breaking changes, but improving the design in the long term.
For some more context: Flawed as they are, Flakes solve a large number of problems Nix experiences without them. This is why I, and presumably many others, use them even in their current experimental state.
Personally, I don't believe there won't be any breaking changes, but I also believe that the stabilization of Flakes is still a ways away and hope that there will be a reasonable migration path.
I spent half of last week trying to make productive use of Nickel, and it's just... not a very fun experience.
Maybe it'll be better someday? We can hope. It's certainly incomplete right now, and the documentation is mostly nonexistent, but I don't think my use-case (incrementally replacing Nix) is supported at all.
At some point, my developer intuition says we'll get something with the core good ideas of Nix, but simplified.
The problem is that implementation of these ideas is fairly hideously complex for the intelligences of most current humans, and that simplifying that complexity requires even MORE intelligence (or more years of more people staring at the problem until the simpler picture becomes clearer).
I find Guix to be much easier to use. Simpler syntax, and it feels like there's more emphasis on being user-friendly. If enough people switched and helped with packaging, there would be basically no downsides. (a big "if", of course)
What I heard Eelco say in a recent conference is that 'nix build' will work with 'old flakes' but as soon as you do a 'nix flake update ' you might have to adapt your flake to the new conventions.
Users seem to love it, but... Why should I use it?
I have a number of personal machines, but I tend to mirror whatever I need to use at work; currently mostly Ubuntu.
Nix seems Great to help cleanup my ansible deployments, but it also seems problematic with the lack of LTS releases to where I couldn't potentially roll out at work.
So, it took me an inordinate amount of effort to get to this point, but I find managing my nixos laptop to be idiotically easy now. And, to be clear, I'm not a developer. I just want an easy to use config that I can port over to a new laptop when the time is right (and maybe port a similar config over to my desktop as well, once I get around to installing NixOS).
It's very weird, because I went from "WHY IN GOD'S NAME WOULD ANYONE WANT THIS?" to "my life is now measurably better" over the span of about 48 hours, and I have no idea what clicked. Something about adding flakes to the mix (NixOS + HM + flakes) broke the logjam. Or maybe it was simply how damned useful this config was to learn from:
I went from that to a per-user, per-machine (with defaults for each) config in about an hour, and I haven't fundamentally changed that setup since. I have no idea why it's so compelling to me, but the combination of being able to tell the machine how to configure itself in one place with the ease of adding software ... I'm going to spin up a config this weekend and put it on my kid's laptop. There are other tools to accomplish the same thing, but NixOS is just so easy ... and poorly documented ... and has weird CLI conventions ... and doesn't do a super job of garbage control ... and
The Nix package manager is to apt what Emacs/Vim are to Notepad.
Nix is a very powerful tool for dealing with packages. NixOS uses the package manager to manage the system configuration.
With a declarative config, you mitigate the risk of "I made this change, forgot what that change was" (or otherwise systems becoming out of sync with each other). Ansible also solves this, sure. (Though, NixOS forces a system into a target state).
Especially useful for working on more than one machine is the ability to conveniently install the same sets of packages everywhere. -- The standard thing to do is just run "install <package>" on each machine. Whereas with Nix, you can write a meta-package of packages you want, and either install this system-wide, or just have those packages added to PATH for when you need them.
With Nix, you pay an upfront cost, so that later you don't have to pay the cost later. -- It's a similar trade-off to using Ansible, or using a dotfile manager across machines.
Nix's reproducibility has benefits, too; before using Nix, when picking up a side project would often require that I'd update the code, as system package managers updated their package versions. -- With Nix, it's easy to retain references to old versions, and possible to have both old and latest versions of a package available on the same system.
