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.
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.
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.
—
/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`).
It's just a small wrapper but it shows you most of the targets available.
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.
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.