Am I out of touch?
No, it’s the forward-thinking generation of software engineers that want elegant, reliable, declarative systems that are wrong.
NixOS is the most boring distro I’ve ever used.
I configured everything across multiple machines and now it just works.
Sure I guess if you can manage to get everything to work in the first place which involves following sixteen different guides across twenty-three different websites all of which with conflicting information.
How, tho?
Seriously, how do you even get started? It’s like the tutorials are all, “This is a basic ‘Hello World’ module/flake. Now, you are a master.” I would love to figure it out, but I need a little more hand holding.
I HIGHLY recommend forking a nix-config that uses flakes, home-manager, and whatever window manager you prefer. Since Nix is so versatile (and the documentation of flakes and home-manager are BAD), I found it absolutely crucial to reuse a well-architected config and slowly modify it in a VM to sketch out my config until it was stable enough to try on a real machine.
Yeah, I’ve had the same experience multiple times, people have been raving about it but I can’t find a tutorial that is as noob-friendly as I’d need it.
I’m suprised I havnt seen people using nix for docker images more.
I went through a NixOS phase, and for a user that isn’t trying to maintain a dev environment, it’s a bloody lot of hassle.
I’m all behind immutable distros even though I don’t particularly have the need for them, but declaritive OSs are kinda niche.
for a user that isn’t trying to maintain a dev environment, it’s a bloody lot of hassle
I agree but I prefer it to things like ansible for sure. I’m also happy to never have to run 400 apt install commands in a specific order lest I have to start again from scratch on a new system.
Another place I swear by it is in the declaration of drives. I used to have to use a bash script on boot that would update fstab every time I booted (I mount an NFS volume in my LAN as if it were native to my machine) then unmount it on shutdown. With nix, I haven’t had to invent solutions for that weird quirk (and any other quirks) since day one because I simply declared it like so:
{ config, lib, pkgs, inputs, ... }: { fileSystems."/boot" = { device = "/dev/disk/by-uuid/bort"; fsType = "vfat"; }; fileSystems."/" = { device = "/dev/disk/by-uuid/lisa"; fsType = "ext4"; }; swapDevices = [ {device = "/dev/disk/by-uuid/homer";} ]; fileSystems."/home/mrskinner/video" = { device = "192.168.8.130:/volume/video"; options = ["x-systemd.automount" "noauto"]; fsType = "nfs"; }; fileSystems."/home/mrskinner/Programming" = { device = "192.168.8.130:/volume/Programming"; options = ["x-systemd.automount" "noauto"]; fsType = "nfs"; }; fileSystems."/home/mrskinner/music" = { device = "192.168.8.130:/volume/music"; options = ["x-systemd.automount" "noauto"]; fsType = "nfs"; }; }
IMO, where they really shine is in the context of declarative dev environments where the dependencies can be locked in place FOREVER if needed. I even use Nix to build OCI/Docker containers with their definitions declared right inside of my dev flake for situations where I have to work with people who hate the Nix way.