Nice writeup, thanks for that.
For the dotfiles, I use home-manager, which allows for almost all my user configuration to be built by Nix as well.
I’m also wondering if there’s a better setup for Spacemacs, as it’s the biggest source of trouble for me still. Different packages look for dependencies all over the place, and there’s no simple hook to fix it. I’m also using neovim configured via nix, and that’s been rock-solid for a long time now.
idk if it’s just me but I get a connection refused (from switzerland)
Same in the UK, can’t connect to site.
The domain has been expired today morning
Registry Expiry Date: 2019-06-03T04:24:55Z
And nothing in the web archive
I put a copy of the site up at https://ipfs.io/ipfs/QmUXh4A6VbQisRbtgb7PX4LxHb9V6hJfWhSs63qkmUjDtA since I still had it in my tab.
Sorry about the domain expiration. I just renewed it.
I’ll take a closer look at home-manager, it indeed sounds very powerful.
I’ve started poking at Bauer for automating setting up an Emacs configuration, but haven’t actually followed through enough to get a proper customized configuration yet. Will be very interested in any completed follow-up.
For what it’s worth I have a fairly nixified Emacs setup that may or may not be interesting.
One thing I’m planning to do on my own laptop and server to further ensure reproducibility is to have root on tmpfs to force NixOS to bootstrap the system on each startup. This way I will only have
/nix partitions actually present on disk.
I’m already doing this for all my NixOS containers by starting them with
--ephemeral option and root pointing to an empty folder on tmpfs which works very good.
How would that work? Wouldn’t you need an internet connection before booting the system?
Also, what do you mean by “NixOS containers”? Do you mean “container”
for VMs created by
No, as long as your system configuration is built and is located in your /nix/store which is the case unless you nuked your nix store and reboot the system, which would make the system unbootable anyway You are not building your configuration at boot, you just activating it.
If you look in config files of your boot loader (like grub or systemd-boot), you will see different system generations with the
init kernel parameter set to different scripts located in nix store, looking something like this
init=/nix/store/<hash>-nixos-system-hostname-19.03pre-git/init. This script is able to populate your root filesystem and activate particular system configuration from scratch.
So, basically, from a user perspective, nothing should change except that anything you will put in, say, /etc folder will disappear after reboot. This way you can make sure that you can recreate your system configuration because, basically, that’s what you are doing every time you boot the machine. This is assuming you trust that everything under nix store can be reproduced
By “NixOS containers” I mean declarative systemd-nspawn containers that can be defined in your system configuration file: https://nixos.org/nixos/options.html#containers. They use the same concept of init script that can activate a system configuration from the empty root, but they are running as systemd services.
@uvNikita thanks for the explanations
Can you share the container config? Do you think it would make sense to have an option for containers to be stateless and using ramdisk?
/etc/nixos? Doesn’t it need to be a file or do you have configured NixOS to use a configuration file from
Yes, I definitely think it make sense to have such option! I’m working on porting my local modifications to the upstream containers module, not sure when it will be ready though. I can share my personal module that sets up the containers if you want, but I’m not sure how useful it will be as is though.
I’m using krops (https://cgit.krebsco.de/krops/about) to deploy my configuration which can be described as a “stateless NixOps”, so the system configuration is just a git repository which can be located anywhere. This way I can deploy configuration to my laptop from anywhere as long as I have ssh connection to it. Mostly I just deploy it through local ssh connection (root@localhost).
That said, krops puts system config in
/var/src indeed, but it’s not strictly required since I need the configuration to be there only for cache purposes (I can repopulate it anytime).