Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

No mention of the fucky /nix/store paths for everything? I haven't used a lot of other distros, especially recent ones (my list: Slackware, Redhat, Ubuntu, Debian), but Nix is a drastic departure from the standard FHS and Linux conventions.

Don't get me wrong - I love NixOS! I'm gradually switching my infrastructure to NixOS. There are very necessary reasons for Nix's departures. But it is jarring, and if we want converts we have to manage expectations properly!



view as:

That's true! Whenever I demo Nix for someone in person, the first trick I do is

> Look ma, no /usr/lib

and right after that it's a chat about the Nix store, and then a tour of what all those ugly hashes let you achieve.

I guess when I wrote that comment I was mostly thinking about what it's like to administer NixOS on a personal system over the moderate term, not the initial shock and wonder of hiking through the glorious Nix symlink forest under /nix/var/nix/profiles for the first time. :)


My personal administration involved a lot of digging through installed software's FHS to figure out how things worked. Especially coming up through Slackware. It's probably a learning style thing.

Mutable distros you directly edit stuff in /etc, then build your knowledge on top of that foundation. Whatever better practices you end up adopting, you're still ultimately modifying files in /etc (and probably elsewhere). A NixOS beginner shouldn't be touching config files, and can't even do things like replace a binary with a shell script wrapper to understand when and how a program is run by a different program.

So I see that departure as a pretty huge one, that will affect someone learning Linux on NixOS for many years, as they need to dig through NixOS specific docs to understand how they're supposed to configure something, rather than falling back to the regular packaging docs. Whereas with Debian you only need Debian documentation to know how to install a package, but after that the upstream package documentation tells you everything else.

As an aside, I feel like NixOS asks a fundamentally different question - "how can we mitigate Linux/Unix's complexity" rather than the traditional mutable distro question of "how can we best interact with Linux/Unix's complexity".

(Also, that sounds like a great approach to explaining NixOS!)


Another thing is that the nixos option searcher[1] links to the nix source code that implements the option, so you can go digging through how things work. It's definitely an extra layer of abstraction vs editing /etc/foorc but I have copied what those things do into my configuration.nix and made changes to poke at stuff.

1: https://search.nixos.org/options


A few times, I have privately used NixOS modules' source code to answer questions about how to configure software that I do not use, in response to questions posed by users of other distros. It's an awesome resource! :D

> My personal administration [prior to NixOS] involved a lot of digging through installed software's FHS to figure out how things worked. [...] Mutable distros you directly edit stuff in /etc, then build your knowledge on top of that foundation.

That's true. Once you have found your footing with the Nix language and figured out some basics of how to navigate the NixOS modules in Nixpkgs, the latter becomes a rich source of examples on how to configure everything on a modern Unix-like system, from mounting a btrfs subvolume in your initrd via systemd/dracut integrations to setting up PipeWire to emulate PulseAudio. But while NixOS can still teach you a lot about how a working Unix-like system is put together and how its stack is configured, the most useful point of entry for such exploration is very different from what you might be used to on other distros.

You can also learn by exploring the Nix profiles and the Nix store of a working system, much like you would walk through the FHS on a ‘normal’ Linux system— after all, all of your system-wide config files can eventually be hunted down in the Nix store. If you run `ps` on a NixOS system, you'll see explicit references to RC files for lots of programs that are wrapped to point to specific config files, and for running persistent services. But it's probably not as useful as going directly to the Nixpkgs source, once you've learned to read a little Nix.

> A NixOS beginner shouldn't be touching config files, and can't even do things like replace a binary with a shell script wrapper to understand when and how a program is run by a different program.

That's an interesting thought. I didn't come to NixOS as a beginner in the Linux world; NixOS was not my first distro. (I think that's true for most of us in the community.) With NixOS, neither the paradigm nor the community really encourages the kind of monkey patching, that kind of learning by brute intervention on a running system. Even so, I think it would be possible (if perhaps a bit perverse) to write a textbook or a course like ‘Learning Unix with NixOS’. I think using a read-write store as a teaching tool before showing the reader how to use Nix itself to wrap programs that live in the Nix store would be fine.

> [NixOS users] need to dig through NixOS specific docs to understand how they're supposed to configure something, rather than falling back to the regular packaging docs.

Right, NixOS definitely changes the sort of ‘order of recourse’ users will want to make when configuring a piece of software. I'd say it looks something like this:

  1. Is there an existing NixOS module for configuring the software I want to use?
  2. If so, does the module have any high-level options that look so convenient that I should try them right away?
  3. Is there any additional, special configuration that I need to do?
If the answer to (1) is no, or the answer to (3) is yes, then it's definitely necessary to consult the upstream documentation on the software you want to use. In the case that a module exists but you need special config, there will always be a way for you to pass configuration options defined upstream directly to the application through your NixOS configuration.

A NixOS fanatic might frame this

> Whereas with Debian you only need Debian documentation to know how to install a package, but after that the upstream package documentation tells you everything else.

in an alternative way:

> Whereas Debian only helps you to install the package, NixOS will also help you perform common configuration tasks. It's only when you need to perform peculiar configuration tasks for your specific needs that you really have to dive into the upstream documentation.

At the same time, knowledge of some upstream component (e.g., Xorg, connman, OpenSSH, etc.) always remains applicable with NixOS, if you want it to be. Everything that's configurable under /etc/something/or/other on Debian remains configurable on NixOS in a straightforward way, either by specifying key-value type config in the Nix language or (in the worst case) by embedding a config file snippet in your NixOS configuration.

> As an aside, I feel like NixOS asks a fundamentally different question - "how can we mitigate Linux/Unix's complexity" rather than the traditional mutable distro question of "how can we best interact with Linux/Unix's complexity".

I think this is well put, and it's what I was getting at above with the idea that thinking about the particular structure of some program's RC file is a last resort in NixOS. But it's not entirely one-sided! The NixOS module system serves not just to shield users from that complexity when they don't need to confront it, but also to teach them about it when they do. For me, that's one of the reasons that learning the Nix language and exploring the Nixpkgs codebase is so worth it.


I guess I kind of think of that as like "Lisp has a lot of brackets!" true, but something someone looking into potentially using it knows already.

Legal | privacy