The problem I see with NixOS on a typical personal server is that you have to setup all these things using nix expressions, from which the actual configuration files are generated.

That means if you e.g. want to install postfix, instead of learning about main.cf you have to learn the syntax of the nix configuration wrapper for postfix, and postfix having hundreds if not thousands of options, many referring to external files/databases, you have to hope that whoever did this configuration wrapper, supported all the features of postfix that you want to use.

I am using nixpkgs on macOS, and I run a personal server with mail (for a bunch of people), web (for a bunch of sites), DNS (for a bunch of domains), etc. and while I would love to switch to declarative configuration, I fear I would run into shortcomings with the configuration wrappers for the various software packages I use.

I am curious if anyone have experience to share?

lots of services defined in the NixOS options will have an "escape hatch" option named something like `extraConfig`. this usually lets you append verbose text to a complex config file, like in the case of Postfix where the options couldn't conceivably cover everything.

you can also always just write a static file to /etc if you want or need to:

    environment.etc.foo-config = {
      target = "foo.conf";
      text = ''
        enable_spline_reticulator = true
      '';
    };

    systemd.services.foo = {
      after = [ "network-online.target" ];
      wantedBy = [ "multi-user.target" ];

      serviceConfig = {
        ExecStart = ''
          ${pkgs.foo}/bin/food \
            --config /etc/foo.conf
        '';
        User = "foo";
        Restart = "on-failure";
      };
    };

another useful escape hatch is that you can run Docker/Podman containers declaratively. I have some things I want the flexibility to upgrade on a different cadence than NixOS itself (such as my family's "production" Jellyfin server) that I just run as standalone Docker containers with volume mounts for their data.

From a quick search, it seems you can use `services.postfix.config` and pass key-value pairs as arbitrary options. Not familiar with this service, but usually if a given one has more complex syntax, there is a “pass-through” option that will simply append to the given config file whatever text you provide, as well as as the sister reply says you can create manually additional files.

And then there is the re-use of things between services, for example DKIM’s generated public key should be made available as a TXT record by the DNS server, the SSL certificate kept up-to-date by the web server should be used by both the smtp and imap servers, though it may need to include the full chain, and services may need to be relaunched, if the certificate is updated, etc.

I was hoping to hear from someone who had managed to get a “full” server running (with SMTP, IMAP, DKIM, DNS, DNSSec, HTTPS via ACME, etc.), because while I know that I can output raw configuration files, it seems like an extremely daunting task to weave all this together in something semantically meaningful.

Right now I have /etc under git control and a Makefile that handles all dependencies between the various pieces (i.e. to ensure proper files are regenerated/indexed as needed, and services relaunched when dependencies are updated).

With one exception (nginx, because it's very well supported) I always just use raw config files and ignore the options. For TVL[0] we've written a bunch of NixOS modules[1] ourselves where the upstream one was either not flexible enough, or deviated strongly from how we wanted things to work.

Nix is the kind of tool that lends itself well to solutions that are more complicated than the problem, but once you get comfortable with the tool it's easy to sidestep that. Despite these warts it's 100% worth the investment.

[0]: https://code.tvl.fyi/about/

[1]: https://cs.tvl.fyi/depot/-/tree/ops/modules

I think a better solution (long-term) is actually a redesigned way of doing service declarations where we're dealing with composable bits of data that describe services (so that a module isn't all-or-nothing anymore). Too much on the plate to design that though ...

I love the principles behind Nix, and I like to use it to provide development environments (through nix-shell locally and then using the same setup in CI). But some things can be moderately painful to get going.

I've been using NixOS for a year now, and I have a definite love/hate relationship. Many times I miss the simplicity of Arch, where I understood _everything_ about my system and how it was configured.

NixOS is like learning everything all over again, but in a weird, poorly documented language+standard lib that nothing else uses.

I think when you are super comfortable with it, is when it becomes truly amazing. But that takes a lot of dedicated time and effort.

There are efforts to improve documentation, but it still is lacking (I think the biggest problem is that Nix is so big, not just the OS but it can be utilized as a build system).

Just with NixOS is not exactly clear how can you for example build your custom image.

I think https://nix.dev/ is approaching the documentation from the right direction.

There are also many pieces that people built that you need to find.

For example some things that I found accidentally:

* https://github.com/nix-community/poetry2nix

* https://github.com/matthewbauer/nix-bundle

* https://github.com/cleverca22/not-os

Unfortunately those side projects often have even worse documentation.

I think having mini images would be awesome.

e.g. if you want a Nix container with a shell environment, git, and htop:

    docker run -ti nixery.dev/shell/git/htop bash

What I'd really like, as a learning resource, is a "Nix for apt/yum users" or a "Nix for Ansible" users guide. There is the cheat sheet (https://nixos.wiki/wiki/Cheatsheet) but it's just not enough.

For example, I wanted to just... create an arbitrary directory in my home directory (~/workspace). Does Home Manager do this? If so, how? Do I just have a shell script that is called within a package? That seems excessive. Is this not a use case for Nix? It looks like it can do arbitrary tasks across the system but the documentation is so bogged down with theory that it takes forever to find practical applications.

You are definitively trying to do too much at the same time. Before using Home-Manager (that is a community project, it is not endorsed by NixOS except by allowing to be hosted on the nix-community group on GitHub), I stayed at two years playing with only NixOS. It is only after I got comfortable with Nix and NixOS that I decided to migrate my configuration to Home-Manager. Not saying that you need that much time to use HM, just that HM assumes that you're know a reasonable good amount about Nix and NixOS.

So I would say, start with less: try NixOS first, it is kinda easy to use compared to other "advanced" Linux distros like Arch and Void. The easy things are really easy, the hard things can be really hard at first but I don't think you need to know much about Nix to be proeficient on NixOS nowadays. Also yeah, you will need to search some things, but since the scope is reduced it is easier to find answers.

I've never used it to manage visible directories in my ~/, but for ~/.gitconfig? Absolutely :).

nixpkgs (which you can use on macOS or any Linux distro), quite little, you can get up to speed in 15min as a Homebrew replacement:

    nix-env -qas ruby             # 'q'uery 'a'vailable 'search'
    nix-env -I ruby.              # install by package name (not recommended)
    nix-env -iA nixpkgs.ruby_3_0  # install by "attribute", recommended
    nix-env -q                    # 'q'uery (i.e list installed)
    nix-env -e ruby               # uninstall (like deleting a git ref)
    nix-env -q
    nix-collect-garbage           # cleanup, like `git gc`
    # etc...

    $ cat shell.nix
    {
      pkgs ? import <nixpkgs> {}, # you can have multiple of these with different names to have e.g a mix of stable and unstable
    }:
    let
      openssl = pkgs.openssl; # just an example of how to set a var
    in pkgs.mkShell {
      buildInputs = [
        openssl
        pkgs.ruby_3_0 # or reference attires directly
      ];
    }
    $ nix-shell
    (nix) $ ruby --version
    ruby 3.0.1p64 (2021-04-05) [x86_64-darwin17]
    (nix) $ openssl version
    OpenSSL 1.1.1k  25 Mar 2021
    (nix) $ exit
    $ openssl version # back to the system one
    LibreSSL 2.8.3

NixOS, it's barely different, only generalised to the whole OS, but it's a bit tougher, because there's this abstraction via configuration that generates e.g systems files or other configurations that you'd operate with directly otherwise on a traditional distro. But the minute you screw things up, having the generation selector to pick and boot on straight in the boot loader you can see the absolutely unparalleled value of the proposition.

We've been actively trying to remove mentions of it from the documentation.

If you want something "installed" use home-manager. If you just want something for quick dev use nix-shell.

It's like... here are all the amazing reasons to do declarative config... and here's how you do everything using nix-env -I. Good luck figuring out how to translate it into a NixOS config so you can get all the benefits of declarative config that we just described!

Guix has a command that converts an imperative profile to a declarative one. Check out the `--export-manifest` option for `guix package`: https://guix.gnu.org/manual/en/guix.html#Invoking-guix-packa...

Adding this to nix-env's replacement would be a sound approach imo. Maybe we could have one that also emits a little message for each package which is used in a NixOS module, directing users to a `programs.whatever` option instead of just dumping it in their `environment.systemPackages` list

Fwiw, you can already have nixos-rebuild read the home-manager configs for all of your users and deploy them as part of the normal NixOS config update process using the included NixOS module.

——

1: https://github.com/svanderburg/nix-processmgmt

Another example is nixops 2.0.

      (final: prev: {
        nixops = inputs.nixops.defaultPackage.${prev.system};
      })

      nixops.url = "github:NixOS/nixops";

   nixops --version
  NixOps @version@

What you wanna do for projects that don't offer a flake.nix or a ready-made overlay is to use a fetcher like in the Emacs example, but write your own overlay function that invokes Nixpkgs' `callPackage` function on whatever Nix expression inside the repo represents the package you want, or imports them from a release or default.nix as appropriate. Home-manager uses this to define its own little overlay[3], the one that gets used in its flake.nix, and its package is just its default.nix[4].

Unfortunately, in the pre-flakes world, you just have to read the Nix code and figure out how to translate things to get the attributes you want into scope. For example, this works for nix-processmgmt:

      (final: prev: {
        nix-processmgmt-tools = (import (
          (builtins.fetchTarball "https://github.com/svanderburg/nix-processmgmt/archive/6def8584c6b028c922c550859a07b989d21d6f73.tar.gz")
            + "/tools/default.nix")
          { pkgs = prev.pkgs; }
        );
      })

I think maybe the reason instructions aren't given for some projects is that they see those parts of the guide as mostly for beginners or casual experimenters, and they expect advanced or ‘serious’ users to be able to figure it out without much trouble. To some extent I think this is because different people choose to pin packages in the pre-flakes world through a variety of different mechanisms, and the authors of these packages and tools don't know in advance how you want to do it.

In the case of nix-processmgmt, I think Sander doesn't actually expect to have any users! In such cases, an imperative install that users are expected to play with for a little while and then just throw away is supposed to be enough.

You're right, though, that it's odd and disappointing that instructions for the preferred way of doing things are sometimes simply not given. A polite pull request or issue report would probably be well-received. My recommended strategy, if you get stuck, would be to ask for help getting those packages into scope declaratively on Discourse or Matrix, and then to offer the authors of these out-of-tree packages pull requests to modify their READMEs accordingly. :)

PS: You don't necessarily _have_ to use overlays for these. You can also drop expressions that use builtins.fetchTarball and then use `callPackage` or import from those sources directly into lists of packages like `environment.systemPackages`.

—

1: https://github.com/gytis-ivaskevicius/flake-utils-plus

2: https://github.com/nix-community/emacs-overlay#quickstart

3: https://github.com/nix-community/home-manager/blob/master/ov...

4: https://github.com/nix-community/home-manager/blob/master/de...

> Unfortunately, in the pre-flakes world, you just have to read the Nix code and figure out how to translate things to get the attributes you want into scope

This has been my approach, I always kind of assumed that there must be a better way but at least I feel a little better knowing that there isn't really. I haven't spent much time with flakes because I mostly only use Nix as a package manager/operating system but this helped me see how even if I'm not personally writing packages that I want to re-use I can still get a lot of value from flakes, so getting that setup is probably my next step!

Imo entirely removing imperative package management would be a mistake, although imperatively managing a file that gets sourced in your declarative config (a bit like /var/dpkg/selections on ol' Debian) instead of putting the whole profile manifest in the Nix store and leaving it at that would be better.

I'm curious what you get out of this that you don't get from just adding/removing packages in your home-manager config? Is it just a matter of it being quicker to do nix-env -iA instead of updating your config and running home-manager switch? Or is there some other benefit?

But mostly I use it as a beachhead for people to eventually jump ship, helping them climb the first step of the ladder:

"see? It's easy to install and use, you'll be quite autonomous. And if you feel it's not your thing just ignore it or rm -rf /nix"

Then I bait them with e.g shell.nix just enough to tease their curiosity.

So instead of feeling overwhelmed by a whole new arch and contractually tied by configs they feel free, empowered, and curious.

That's definitely a factor. I think since I keep my Nix configurations in source control, somehow modifying the configuration feels more ‘official’, and it also usually comes with extra steps like committing and pushing.

The other thing I like is that it makes it very easy to tell if I actually want/need something: if I find myself installing something over and over (because I periodically purge my profile), I know for sure that it's time to add it to my config. This way I end up pulling less crap I don't actually use into my setup in an enduring way.

Maybe I'd also feel the same way about invoking things via `nix run` or `nix-shell` over time, and that would motivate me to incorporate them into my config ‘for realsies’ by declaring them.

> instead of updating your config and running home-manager switch?

I'm not currently a home-manager user on NixOS. Before home-manager was a thing, I used to define groups of packages using buildEnv and store them in an overlay for very simple de-facto declarative package management, so something like:

  nix-env -iA pxc-tui-apps

I'm switching to home-manager in my new setup, but one thing I still like about `nix profile install ...` (the flakes-based/next-gen replacement for nix-env, currently) is that it's user-mode/unprivileged, and it doesn't involve rebuilding my whole system (or anything other than the dependencies of just the package I want), even if my nixpkgs checkout/channel/flake registry or whatever has changed. `home-manager rebuild switch` is also unprivileged and also doesn't involve updating my whole system, but unfortunately home-manager doesn't support flakes just yet. You can use it on flakes-based setups on NixOS and macOS via the home-manager NixOS and nix-darwin modules, respectively... but then you're giving up the other benefits I like, because you have to invoke nixos-rebuild after all!

If `nix profile` were some day removed along with `nix-env`, but I had a user-level declarative environment management tool (like home-manager or something more tightly integrated), I could probably get by with just a little discipline about how I choose to edit my configurations and manage sources of Nix expressions and be pretty happy.

But I think the problems with `nix-env`/`nix profile` are pretty solvable, and I think lacking any imperative solution at all will likely put some ‘winnable’ new users off.

I do agree that `nix-env` itself sucks and needs to go, though. `nix-env --upgrade` doesn't really do what people expect, and there's no real reason to use/prefer it over just removing/reinstalling a package. The way that `nix-env` thinks about versions is basically insane, since Nixpkgs doesn't have any real version metadata and `nix-env` just parses attribute names to get the versions back out. `nix-env --query` is clunky and slow (but the new `nix search` is awesome and crazy fast!). `nix-env` was a cool thing for its time, and it's actually how `home-manager` manages its profiles on the backend (which is why flake support is still lacking; enabling flakes disables `nix-env` for your user). But it's like an imitation of `rpm`, and it was made before Nix had a real userbase and opportunities to think about what operations/abstractions/metadata were desirable at that level.

One of the things that's cool about Nix's design is that its design allows you to just bypass the hardest and most annoying problem that faces traditional package managers: dependency resolution. If you want a package manager that's guaranteed to give you solutions that are correct and complete, you need a SAT solver for dependency resolution, and that's NP-complete. By leveraging its quasi-content-addressable derivation approach, Nix gets to avoid resolving dependencies like traditional package managers do— the thing you need is the thing you were built against, and that's that! Similarly, by leaning hard into the Nixpkgs monorepo so that almost all packages live on it and all third-party package sources are built as de facto overlays on top of it, Nix has been able to totally avoid having to think about versions.

Compared to formats like DEB or RPM, Nix packages have very, very little metadata. Nix packagers don't have to declare things like acceptable version ranges for dependencies, what packages provide, what package names ought to be considered equivalent, what other packages it's incompatible with, or even what version number a package has. But `nix-env`'s `-q`, -i`, and `-u` options all imitate the `rpm` CLI, where all of that kind of metadata is necessary and present. And `nix-env` makes all that stuff work by assuming the structure of Nixpkgs and operating on Nix attributes representing packages directly. And it doesn't really make sense in the Nix world as it exists.

Flakes is the first attempt to revisit all these questions the community has basically punted on like ‘how do we want to relate packages to each other in a way that's not monorepo-centric?’, ‘what kind of metadata do we actually want to have for publishable Nix source package artifacts?’, ‘how should Nix code repositories advertise what features/tooling (packages, shell environments, modules, overlays, whatever) they support?’, ‘do we want Nix to actually be able to reason about versions?’, etc. (This also possibly reintroduces the question of dependency resolution. Hopefully not?) I think once we have real, considered answers for questions of that kind, grounded in the experience of the community so far, we can build an imperative frontend to Nix that makes sense and is nice to use.

In the context of within nix packages that's correct. In the context of nix usage that is not.

I start a project, I need it to use Ruby 2.7.x, OpenSSL 1.1, node 14.x because that's what the project is compatible with, and I need that to happen on both Darwin, Linux, on whatever cpu arch. Pinning the hashes of "whatever I built it with" won't work.

Worse, some software such as e.g Ruby encodes their platform at build time (because it matters, because #ifdefs) so currently I'm on darwin20 but specifying "ruby" pulls in RUBY_PLATFORM==darwin17. Nix is currently helpless in face of that.

> and it doesn't involve rebuilding my whole system

True. One thing I'm 100% sure is that nix-env -i will do just that and nothing else, whereas nixos-rebuild switch might include something else pending I might have forgotten about because it relies on globals.

> Worse, some software such as e.g Ruby encodes their platform at build time (because it matters, because #ifdefs) so currently I'm on darwin20 but specifying "ruby" pulls in RUBY_PLATFORM==darwin17. Nix is currently helpless in face of that.

Right, right. That's a real problem. Gentoo Portage has mostly a big monorepo kinda like Nixpkgs, and in it you can find multiple versions of many pieces of software. Maybe the sensible future in the Nix world would be:

1. Our package attributes include version metadata, perhaps through something like ‘subflakes’ within the repo.

2. Nixpkgs includes multiple versions of major pieces of software.

3. Nixpkgs' top-level remains basically as it is now, in that for the most part only the latest version of something is used as a dependency. Alternatively, we use some kind of a ‘lock file’ that gets published with Nixpkgs. This way `nix profile install` still doesn't have to perform any dependency resolution for packages inside nixpkgs, so its behavior stays fast and predictable.

4. You can add version constraints in defining packages for use outside Nixpkgs, in `nix shell` environments, etc.

Does that seem like the way to go for you, or is your ideal picture something else?

I hear you. I understand nix-env as it exists needs to go, and I can only trust you on the support side. I did not know about home-manager.

Doing my homework, from home-manager README, I can read:

> Before attempting to use Home Manager please read the warning below.

> Unfortunately, it is quite possible to get difficult to understand errors when working with Home Manager, such as infinite loops with no clear source reference. You should therefore be comfortable using the Nix language and the various tools in the Nix ecosystem.

> Home Manager targets NixOS unstable and NixOS version 20.09 (the current stable version), it may or may not work on other Linux distributions and NixOS versions.

> Also, the home-manager tool does not explicitly support rollbacks at the moment so if your home directory gets messed up you'll have to fix it yourself.

On top of being third party (for now?), all of this really does not bode confidence in the tool and severely raises the bar for adoption when all one wants is to install tmux globally for their user (IOW a bunch of symlinks in ~/.nix-profile/bin that "just works").

But the best one is this in the manual:

> This manual will eventually describes how to install, use, and extend Home Manager.

There is no section in the manual describing the usage of the tool. The Getting Started seems to be solely about development and contributing. The terse examples in the README is what made me search for the manual, and I could only get a grasp of what they entail because I have NixOS experience. Seriously, if this is deemed "general public availability" quality, this is borderline user hostile.

So, I do note the envisioned deprecated-ness of nix-env but I will continue to use that as a first rung to help people climb the ladder when I introduce people to nix until there is a suitably accessible and reliable replacement.

Indeed I successfully used it as a beachhead for people to eventually jump ship:

"see? It's easy to install and use, you'll be quite autonomous. And if you feel it's not your thing just ignore it or rm -rf /nix"

Then I bait them with e.g shell.nix (which feels like Gemfile) or nix-shell -p --run (which feels like docker run) just enough to make it relatable while teasing their curiosity.

So instead of feeling overwhelmed by a whole new arch complete with a foreign config system and an alien language, and contractually tied by configs they feel confident, uncommitted, free, empowered, and curious, and that much more likely to transition to the next rung up.

> If you just want something for quick dev use nix-shell.

That I 100% agree with, which is why I immediately described it as well. It's the hook to the next rung.

> In some cases Home Manager cannot detect whether it will overwrite a previous manual configuration.

That, to me, is a problem. I fully acknowledge the limitations and caveats of nix-env, and duly highlight them when introducing people to nix, but this means home-manager is not the tool I need, in git parlance it's way too much "porcelain" and not enough "plumbing". It feels invasive when you're still in the process of getting acquainted.

I do not want home-manager to handle launchd, nor .gitconfig. I do not use nix-darwin or NixOS, _on purpose_, as I use nixpkgs as an additional tool, an extension of existing systems.

I am fine if nix-env has some of its features revamped, or is deprecated and replaced by a better tool but in terms of some of its existing use cases it is exactly the tool needed, i.e merely allow users or root to make a package persistent and widely available for the user or for root in their PATH, as if it were a native package, and with no other side effects.

I hope you understand these are legitimate needs.

Old version of fwup packaged. Can override to get newer version, but needed to add another dependency to make tests pass (and it gets built locally rather than being cached)

Pain getting my environment to include the right Python packages so I can run the gigalixir command line tool.

Have to workaround an oddity to do with how Erlang is packaged so that I don't get lots of warnings when anything is compiled:

    shellHook =
    ''
      export ERL_LIBS=""
    '';

I'm not completely sure but I think this approach is preferred because shellHook only runs in `nix-shell` but if you ever wanted to `nix-build` a release it might not run.

Because shellHook allows on executing any code, there's no standardized way to undo what it executes, so those tools don't execute that part.

Writing Haskell in it was a joy, but Ruby was pure pain. I actually never could get RoR to run (this might have changed), so I gave up and went to OSX for that stuff.

Stack (Haskell) was awesome because it’s Nix aware, enabling it to create its own env to handle C deps on it’s own.

The biggest benefit for using poetry is the dependency resolver which is much smarter than in pip and actually finds packages that match the version requirements (although looks like mach-nix also has a smart resolver.

Other benefits are:

* nice CLI

* ability to package application and upload to PyPI

* poetry can still be used by people who don't use Nix

Regarding non-python dependencies, this is solved by overrides file[1]. That way most of the time you don't have to think about it. You can also override the override in your project as well.

[1] https://github.com/nix-community/poetry2nix/blob/master/over...

How does the Nix ecosystem compare with AUR? Would you still recommend making the switch?

By sheer happenstance, I blogged earlier this week about one particular killer feature that doesn't get enough air time: https://news.ycombinator.com/item?id=27344677

My not-flake-yet configuration can be found at https://github.com/rraval/nix

Encouraging to know that it's possible.

I'll explore your links.

Nixpkgs itself is several times the size of the base Arch Linux package collection, and by ‘non-unique’ package count, Nixpkgs is also much larger than the AUR. In addition to Nixpkgs, you can find Nix packages in several community ‘overlays’ for Nixpkgs as well as Nix's own user repositories.

You can check to see whether everything you currently use/need is conveniently available for NixOS in a comprehensive-ish way through the combination of these two web search tools:

• for Nixpkgs/NixOS: https://search.nixos.org/packages?channel=21.05

• for NUR: https://nur.nix-community.org/

NixOS also includes native Flatpak support.

Fwiw, packaging most things for Nix is very easy. I left Arch in ~2010 because at the time the package management stack and default repos on Arch basically sucked compared to most distros I'd used and liked, and from then on I decided that if I wanted software that wasn't in my distro's repos I'd just package it myself. After taking a little time to learn the tools on whatever distro I was using, I never missed Arch or the AUR. Compared to other distros, packaging normal software from source is usually exceptionally easy on NixOS.

If I were you I'd just dive right in and hit Nix's channel on Matrix with the Nixpkgs manual in hand if I found something I wanted to use that wasn't already packaged. But you can fall back on the options outlined above.

I only ran into one hiccup: NixOS has an open pull request for supporting plymouth for silent boot with a LUKS encrypted drive. For now, I am stuck with an ugly password prompt when I turn my computer on.

Edit: Relocating /boot to a flash or SD-card is also a way to accomplish deniability of a cryptroot.

Is there some way I can boot-to-git-configuration? So I could do this in RAM on someone else's hardware, like a network boot?

Yes, the NixOS installer is a live disk with all the features of NixOS. I have booted configurations directly from IPFS in the installer, and many nix commands and functions support git (or GitHub) natively.

You can declaratively specify your whole infrastructure from software configuration to remote machines with their own VMs.

For example here's my nix function for matrix: https://0x0.st/-2CA.nix

It does a whole bunch of stuff.

First it reads in the hostname and domain from the system configuration and put that in a variable to be used when configuring the subdomains later.

Then it opens up your firewall, starts a postgres service, creates the matrix db/user, configures nginx for matrix.hortname.domain, gets your SSL certificate (and sets up automatic renewal), sets up matrix, and lastly a hosted web client at element.host.domain. All services run under their own users on the host system.

It's zero configuration, I just import that to any machine that I want and it's running a matrix server with all appropriate ancillary configuration done.

Mutable state like database contents, including their password databases, don't go in the Nix store either.

Kind of. It works very well if you own multiple computers that you want to be configured similarly (like a dotfiles repo on steroids).

It doesn't work so well for I borrowed my coworker's computer for 5 minutes and want to use my own Vim configuration.

However, Nix does also supply the "nix run" command, which allows you to use software without installing it permanently (but without NixOS' configuration support).

> Is there some way I can boot-to-git-configuration? So I could do this in RAM on someone else's hardware, like a network boot?

Yes. You could either build an image with a service that git clones your configuration and switches to it, or you could build an image containing a prebuilt snapshot of your configuration.

Either approach should be possible for basically any medium (USB drive, DVD, netboot, whatever). That said, for the build-and-switch setup I'd recommend something that can give at least /nix/store a writable partition (to avoid having to rebuild/redownload the whole world on every reboot).

You could use something like nixos-shell[1] to spin up a headless VM of your machine into your current shell.

[1]https://github.com/Mic92/nixos-shell

    /run/current-system -> /nix/store/95n5xr5n8bw6xbab8fiz6cqc6mydryg8-nixos-system-Sweetpea-21.11pre291991.ea7d4aa9b82

Let's say I want to change something. I edit /etc/nixos/configuration.nix, then run "nixos-rebuild build", which produces this:

    /nix/store/0fhxjqbv20psbkjvw70wni9ww2cxfqgm-nixos-system-Sweetpea-21.11pre292748.6933d068c5d

When I'm ready to change, I run "/nix/store/0fhxj.../bin/switch-to-configuration". This step actually changes the /run/current-system symlink, updates /etc, restarts any daemons that were updated, etc. Obviously, if your configuration has a new kernel, that won't be applied until you reboot.

In practice, we almost always just run "nixos-rebuild switch", which does the build and switch in one go.

This whole process is entirely idempotent and reversible; I can switch back to any configuration I've ever built (unless I've since removed them to save space, of course). GRUB also displays a list of every configuration you've ever built, so you can always boot into a stable configuration even if you've somehow made a royal mess of things.

I'm impressed that it manages restarting everything on the fly without a reboot on a running system.

All in all, the service management stuff is handled very gracefully imo. I've never run into real trouble with it (and one time I had a power outage in the middle of a `nixos-rebuild switch`).

You don't need to do all three: you can skip the bootloader if you want to try something temporarily, and you can skip activation if you want to wait with that until the next reboot. There are also some changes that can't be activated without a reboot, such as changing the kernel.

> Does it take time/have to download things?

Building has to download or build stuff that isn't in the cache. But contrary to, say, Docker it understands the build graph, so it only rebuilds actual dependees.

Activation depends on how many services you've changed, and how quickly they restart. Updating the bootloader is nearly instant.

Where's a good place to start? Some of the configs people are throwing about are quite involved and look like they need a bunch of specialist knowledge.

Thanks for taking the time to explain. Can't wait to start trying this out.

Then just start adding software that you want to be able to use. Search for it first in the NixOS options[1]. If you see it there, enable it and configure it using the options that make sense to you. If you don't see it there, search for it in the package collection[2], then use the name you find for it there to add it to `environment.systemPackages` in your `configuration.nix` file.

Just kinda take it easy and continue with that process until you have an environment that's more or less comfy. Then you're free to revisit your config and think about stuff like tying it in with your dotfiles, using Nix to manage your home directory, services you might want to run, etc.

—

1: https://search.nixos.org/options?channel=21.05&

2: https://search.nixos.org/packages?channel=21.05&

What do you mean without config support? It runs a nix derivation which can be arbitrarily complex. Do you mean your /etc/nixos/configuration.nix file? Because you are not really using it either, only for creating a derivation that will become your system. A nix-shell of a user will by default use the user’s channel and may not do anything with the global config.

It is possible though, if you have the same config and use channels at the same revision (or use flakes) nix will know all packages it needs. You could fetch them and then either provide that machine as a cache, or use nix copy to copy the packages.

It's just a small wrapper but it shows you most of the targets available.

Yes, and you can specify your .vimrc, your vim plugins, the users you want setup, their SSH keys, your systemd config, etc.

> Is there some way I can boot-to-git-configuration?

Bootstrapping a system is the one place where you still need to do a bit of work, but it's not bad.

I personally have a script in my Nix config repo which pulls my config down to disk, sets up symlinks, and then switches to the new config. From there everything then goes through standard Nix tooling.

It should be relatively straightforward to also mount /home from a separate USB stick partition, but I haven't tried.

I ultimately find it easier to have one host that is keeping track of all configurations and pushing my changes to all hosts since I otherwise end up with a lot of machines with different changes I've been working on.

Package managers typically have a concept of a “selected set” or something o that nature which is often simply a file that contains all the packages the user wants to install on a new line at some places. Simply copy that file and do a world update with the package manager and it will install all those packages an their dependencies and typically uninstall what is not needed.

It can also be used to apply patches to packages (which are then automatically carried over when the upstream package is updated).

Do you mean system configuration in /etc, or also user configuration in /home?

In the latter case I do not see how this can ever be implemented, even if an exhaustive list be provided with each package in it's description, quite a bit of software will arbitrarily add new files under new names as part of it's confguration.

Usually one simply copies one's entire `~/.config` directory along.

> It can also be used to apply patches to packages (which are then automatically carried over when the upstream package is updated).

True, but this is also a feature of any source-based system.

The real advantage to me seems to be that it is a source-based system but with a central repository for identically configured packages to avoid compilation in many cases.

NixOS covers /etc, and Home-Manager covers /home. But in practice many applications support configuration from /etc as well, and you will tend to prefer just managing it from there when using NixOS.

> In the latter case I do not see how this can ever be implemented, even if an exhaustive list be provided with each package in it's description, quite a bit of software will arbitrarily add new files under new names as part of it's confguration.

Hm? If you use Nix to manage the application's configuration then Nix is the only program allowed to change the configuration directly.

> Usually one simply copies one's entire `~/.config` directory along.

Not the same thing. Nix allows you to express relationships between different application configurations (why does program A try to connect to localhost:9267? oh, ripgrep says that program B is binding that port for RPC...), and lets you stack configurations (so that defaults can be updated automatically, or you can change a specific value for a specific machine without having to maintain two completely separate copies).

It's like the difference between giving a new employee access to your source code, vs saying "here's an optimized stripped build, and here's a copy of Ghidra, have fun!".

> True, but this is also a feature of any source-based system.

In the same sense that you can copy your dotfiles around manually, sure. The difference is that Nix allows you to patch the package definition itself dynamically. AUR/PKGBUILD (the only other source-based system I'm familiar with to be fair, not sure if Gentoo handles this differently) allows you to patch the /application/, but you still need to copy the PKGBUILD and backport all upstream changes.

Nix lets you pin your whole dependency tree, and Nixpkgs includes facilities for managing the configurations of many applications, including integrations with their plugin systems that explicitly manage external runtime dependencies, like stuff your vim configuration might call at the CLI. Without that stuff, reproduction can often fail in practice.

And in the case of NixOS, you can also reproduce things like running services and their configurations, which users exist, etc. Those are OS and configuration management features, not package management.

Linuxbrew installing at /home/linuxbrew/.linuxbrew/ is a bit of a joke too.

https://github.com/NixOS/nixpkgs/issues/95903

https://github.com/NixOS/nixpkgs/pull/125184

https://github.com/NixOS/nix/pull/4867

There's also not-directly-related cross-functional need here on the install process:

https://github.com/NixOS/nix/pull/4289