Hacker News Reader

Comment by Cyph0n | Hacker News Reader

+1 for NixOS. I used to find systemd a bit intimidating, but working with NixOS has made it all fit together somehow.

As an example, this is a systemd timer I have that periodically runs rclone to sync photos to Backblaze:

    systemd.services.rclone-photos-sync = {
      serviceConfig.Type = "oneshot";
      path = [ pkgs.rclone ];
      script = ''
        rclone \
          --config ${config.age.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";
        RandomizedDelaySec = "5m";
        Persistent = true;
        Unit = "rclone-photos-sync.service";
      };
      partOf = [ "rclone-photos-sync.service" ];
      wantedBy = [ "timers.target" ];
    };

View on HN

I had to write a systemd timer to rescan PCIe ports about ten seconds after the computer starts. I was able to add that to my NixOS config and it worked how I wanted, and it was great because if I had broken anything all I would have to do is reboot and choose an older generation.

I like so much about Nix and the Nix philosophy, but I'm a bit stuck on the perceived ugliness of the Nix language. It just feels so ... icky to me. I don't typically feel that way about languages. Even Erlang (while being bizarre) didn't/doesn't bother me that much.

Does anybody else have this problem? How do you get over it? (it seems like such a ridiculous reason to avoid picking up an otherwise good tech)

I think at this point it's a quasi Stockholm Syndrome for me, because I've grown to genuinely kind of like it.

I started making my own packages for Nixpkgs, and I have made dozens (maybe hundreds) of flakes, so I'm just kind of used to the language now. It's an ugly language, but once you write a lot of it, you get used to its quirks.

And there are some niceties, like being able to define a variable and use that variable to access and define fields, kind of like JavaScript:

   {
      blah = {
        ${myVar} = "something";
      };
    }

It's kind of fun to do that, because you can use something like flake-utils that lets you loop through all the platforms that Nix supports and reuse your structures.

Otherwise it's just kind of an awkward functional language. You get used to it.

You may wish to give Guix a try. Nix philosophy, but the language is Scheme.

That would all be one line in a crontab.

The article already explains the difference between cron and systemd timers, so I won't rehash that. Yes, systemd is more verbose, but that comes with advantages over cron. And if cron suits your usecases, it's a fine tool as well.

But with NixOS and this example specifically, you also get (at a minimum):

a) A declarative config without requiring an external tool like Ansible.

b) Any dependencies (rclone in this case) will be implicitly installed if not already present on the system.

c) If configuring a remote machine, this will copy over the encrypted rclone.conf file and decrypt it on the target.

d) And of course, it's trivial to version control and track changes to the config over time.

I want to use NixOS but man it’s a mess with its flakes vs no flakes debates. I’ve stuck with learning Ansible for now, but if flakes is ever properly built in I’d consider it.

Flakes are as stable as they can get imo. They are already widely adopted, so I don't see how they can ever completely walk the feature back. The unstable marker is only there because there are some edge cases to work around afaik.

And I agree that NixOS without Flakes is a worse experience overall.

Putting aside that this is all possible with nix and without systemd, the additional complexity strikes me as having hamstrung the linux community for the last decade. I hope reliable service management arises but I have yet to see the benefit.

In the meantime I'm just going to keep using void because I know how to fix it when it breaks. Systemd i have to google how to even find the service logs.... they certainly aren't easy to find via the filesystem any more.

Like I said, it is a bit intimidating at the start. But you soon realize it’s quite intuitive.

Finding logs for a specific service is a one-liner:

  journalctl -u rclone-photos-sync.service

Add -r (reverse) to return newest logs first. Add -b to limit logs to the current boot.

Here is a nice overview: https://www.digitalocean.com/community/tutorials/how-to-use-...

Well, above a level tools can't be designed to be discoverable without any form of help/learning, and I believe that's fine. They should rely on a "common knowledge base" as much as possible, and I believe systemd commands are done in a POSIX-y style, but you do have to occasionally read a man page or Google.

Do we expect an average dude to just pop into a cockpit and land a plane with no previous training?

That isn't inherently better.

The really nice thing about systemd timers is that as units you can get status of them and check the journal output the same as any other unit.

How is ‘persist’ realised with cron? What about ‘randomized delay’?

I'm not sure what 'persist' means here but at least some cron implementations have support for randomization in times or time intervals.

    the time when the service unit was last triggered is stored on disk. When the timer is activated, the service unit is triggered immediately if it would have been triggered at least once during the time when the timer was inactive. Such triggering is nonetheless subject to the delay imposed by RandomizedDelaySec=. This is useful to catch up on missed runs of the service when the system was powered down.

Reply on news.ycombinator.com