Comment by Cyph0n
1 month ago
How is it not a light abstraction? If you're familiar with systemd, you can easily understand what the snippet below is doing even if you know nothing about Nix.
systemd.services.rclone-photos-sync = {
serviceConfig.Type = "oneshot";
path = [ pkgs.rclone ];
script = ''
rclone \
--config ${config.sops.secrets."rclone.conf".path} \
--bwlimit 20M --transfers 16 \
sync /mnt/photos/originals/ photos:
'';
unitConfig = {
RequiresMountsFor = "/mnt/photos";
};
};
systemd.timers.rclone-photos-sync = {
timerConfig = {
# Every 2 hours.
OnCalendar = "00/2:00:00";
# 5 minute jitter.
RandomizedDelaySec = "5m";
# Last run is persisted across reboots.
Persistent = true;
Unit = "rclone-photos-sync.service";
};
partOf = [ "rclone-photos-sync.service" ];
wantedBy = [ "timers.target" ];
};
In my view, using Nix to define your systemd services beats copying and symlinking files all over the place :)
The value brought by NixOS is on line 6.
NixOS let you build the abstraction you want, and mix them with abstractions provided by others, and this single line illustrates this point extremely well as `sops` is not yet part of NixOS.
Secret management would likely come in NixOS in the future, but in the mean time you can add either use https://github.com/Mic92/sops-nix or https://github.com/ryantm/agenix to make it possible to manage files which have content that should not be public.
Other package managers also provide some abstraction over the packages, and would likely see the same systemd configuration abstracted the same way in post-install scripts. Yet, the encrypted file for `rclone.conf` would come as a static path in `/etc`.
You could resume NixOS as having moved the post-install script logic before the installation, yet this tiny detail gives you additional abilities to mix the post-install scripts and assert consistency ahead of making changes to the system.
Hah I just wrote something similar today to periodically push backups to another server from my NAS.
I agree the systemd interface is rather simple (just translate nix expression to config file). But NixOS is a behemoth; Completely change the way how every package is built, introduce a functional programming language and filesystem standard to somehow merge everything together, and then declare approximately every package to ever exist in this new language + add a boatloat of extra utilities and infra.
I was referring to working with systemd specifically on NixOS. But yes, the Nix ecosystem is not easy to learn, but once it clicks there is no going back.
Not easy to learn is a bit of a red herring imo. Its also a disproportionate amount of stuff to hold in your head once you have learned it for what it is.
An OS is first of all is a set of primitives to accomplish other things. What classic worse-is-better Unix does really well is do just enough to make you able to get on with whatever those things are. Write some C program to gather some simulation data, pipe its output to awk or gnuplot to slice it. Maybe automate some of that workflow with a script or two.
Current tools can do a bit more and can do it nicer or more rigorously sometimes, but you loose the brutal simplicity of a bunch of tools all communicating with the same conventions and interfaces. Instead you get a bunch of big systems all with their own conventions and poor interop. You've got Systemd and the other Redhat-isms with their custom formats and bad CLI interfaces. You've got every programming language with it's own n package managers. A bunch of useful stuff sure, but encased in a bunch of reinvented infrastructure and conventions.