These are my dotfiles (configuration files) for my NixOS setup(s).
Stylix (and base16.nix, of course) is amazing, allowing you to theme your entire system with base16-themes.
Using this I have 55+ themes (I add more sometimes) I can switch between on-the-fly. Visit the themes directory for more info and screenshots!
I wrote some reinstall notes for myself here (install.org).
TLDR: You should™ be able to install my dotfiles to a fresh NixOS system with the following experimental script:
nix-shell -p git --command "nix run --experimental-features 'nix-command flakes' github:zen2do/nixos-config"
Disclaimer: Ultimately, I can’t gaurantee this will work for anyone other than myself, so use this at your own discretion. Also my dotfiles are highly opinionated, which you will discover immediately if you try them out.
Potential Errors: I’ve only tested it working on UEFI with the default EFI mount point of /boot
. I’ve added experimental legacy (BIOS) boot support, but it does rely on a quick and dirty script to find the grub device. If you are testing it using some weird boot configuration for whatever reason, try modifying bootMountPath
(UEFI) or grubDevice
(legacy BIOS) in flake.nix
before install, or else it will complain about not being able to install the bootloader.
Note: If you’re installing this to a VM, Hyprland won’t work unless 3D acceleration is enabled.
Security Disclaimer: If you install or copy my homelab
or worklab
profiles, CHANGE THE PUBLIC SSH KEYS UNLESS YOU WANT ME TO BE ABLE TO SSH INTO YOUR SERVER. YOU CAN CHANGE OR REMOVE THE SSH KEY IN THE RELEVANT CONFIGURATION.NIX:
- configuration.nix for homelab profile
- configuration.nix for worklab profile
Separate Nix files can be imported as modules using an import block:
imports = [ ./import1.nix
./import2.nix
...
];
This conveniently allows configurations to be (*cough cough) modular (ba dum, tssss).
I have my modules separated into two groups:
- System-level - stored in the system directory
- System-level modules are imported into configuration.nix, which is what is sourced into my flake (flake.nix)
- User-level - stored in the user directory (managed by home-manager)
- User-level modules are imported into home.nix, which is also sourced into my flake (flake.nix)
More detailed information on these specific modules are in the system directory and user directory respectively.
In some cases, since I use nixpgs-unstable
, I must patch nixpkgs. This can be done inside of a flake via:
nixpkgs-patched = (import nixpkgs { inherit system; }).applyPatches {
name = "nixpkgs-patched";
src = nixpkgs;
patches = [ ./example-patch.nix ];
};
# configure pkgs
pkgs = import nixpkgs-patched { inherit system; };
# configure lib
lib = nixpkgs.lib;
Patches can either be local or remote, so you can even import unmerged pull requests by using fetchpatch
and the raw patch url, i.e: https://github.com/NixOS/nixpkgs/pull/example.patch.
I currently curate patches local to this repo in the patches directory.
I separate my configurations into profiles (essentially system templates), i.e:
- Personal - What I would run on a personal laptop/desktop
- Work - What I would run on a work laptop/desktop (if they let me bring my own OS :P)
- Homelab - What I would run on a server or homelab
- WSL - What I would run underneath Windows Subystem for Linux
My profile can be conveniently selected in my flake.nix by setting the profile
variable.
More detailed information on these profiles is in the profiles directory.
Some Nix commands are confusing, really long to type out, or require me to be in the directory with my dotfiles. To solve this, I wrote a wrapper script called phoenix, which calls various scripts in the root of this directory.
TLDR:
phoenix sync
- Synchronize system and home-manager state with config files (essentiallynixos-rebuild switch
+home-manager switch
)phoenix sync system
- Only synchronize system state (essentiallynixos-rebuild switch
)phoenix sync user
- Only synchronize home-manager state (essentiallyhome-manager switch
)
phoenix update
- Update all flake inputs without synchronizing system and home-manager statesphoenix upgrade
- Update flake.lock and synchronize system and home-manager states (phoenix update
+phoenix sync
)phoenix refresh
- Call synchronization posthooks (mainly to refresh stylix and some dependent daemons)phoenix pull
- Pull changes from upstream git and attempt to merge local changes (I use this to update systems other than my main system)phoenix harden
- Ensure that all “system-level” files cannot be edited by an unprivileged userphoenix soften
- Relax permissions so all dotfiles can be edited by a normal user (use temporarily for git or other operations)phoenix gc
- Garbage collect the system and user nix storesphoenix gc full
- Delete everything not currently in usephoenix gc 15d
- Delete everything older than 15 daysphoenix gc 30d
- Delete everything older than 30 daysphoenix gc Xd
- Delete everything older than X days
Didn’t think this would get that many stars on GitHub, yet here we are: