raek · HackerTrans

I saw just now that there are also system units (started with "systemctl enable --now syncthing@USER_NAME_HERE.service", note the lack of --user). If you use those then you don't need to activate linger. Using those is probably considered the more standard way of doing things on an unattended server.

raek

5 anni fadiscuss

Regarding backups... Syncthing is great for propagating changes to all devices, but does not offer much in terms of backups and previous versions of files. (And I'm fine with that. I consider that to be out of scope for Syncthing.)

I've been thinking about solving the backup part by letting one of the devices perform btrfs snapshots on its storage. Does anyone know about any write-up that describes or compares such solutions?

Setting up a cron job / timer unit that commits the synced folder to a git repo is also an alternative, but has some disadvantages: stores contents twice (once in the sync folder, once in the git object database), and pruning older versions is difficult (git is mainly built to keep all history).

raek

5 anni fadiscuss

More information: https://docs.syncthing.net/users/autostart.html#using-system...

The Debian/Ubuntu packages ship all the needed files. You only need to activate them.

raek

5 anni fadiscuss

On Ubuntu (and probably other distros that use Systemd as well) you need to enable the user service manually once for your user:

    systemctl --user enable --now syncthing.service

This will start syncthing whenever your user session is active. By default that means when you login. If you run this command:

    sudo loginctl enable-linger $USER

Then your user service manager will be started at boot and run regardless if you are logged in or not. (The default behavior makes more sense on desktop and laptop computers.)

raek

7 anni fadiscuss

For you language nerds: the author Gretchen McCulloch also hosts a podcast, Lingthusiasm! (https://lingthusiasm.com/)

raek

12 anni fadiscuss

You don't use another interface when thinking "IO type" instead of "IO monad". It's all about what words you use to explain the types of the interface.

For example, when you write 1 + 2 you are probably thinking of (+) being addition on integers. But a mathematician could also think of (+) as the operator from the group (Z, +, 0). Groups (a concept in abstract algebra) generalize integers, but you do not need to know group theory to do arithmetic. But it's the same operator nevertheless! Just two ways of talking about it.

Similarly, when you write putStrln "Hello " >> putStrLn "world!", the "IO type" way of thinking says: (>>) is an operator that glues two IO actions together. The resulting combined action performs the argument actions sequentially from left to right. The operator has the type IO a -> IO b -> IO b.

But you can think of (>>) in more general terms. It is not meaningful only for the IO type. It is meaningful for any type that happens to be a monad! That insight may be useful eventually, but probably not for a beginner Haskell programmer just wanting to do some IO!

raek

12 anni fadiscuss

Exactly. You only need to know about some primitive operations (like putStrLn and getLine), and ways to combine them (like >>, >>=, and return).

This was my point when I wrote my "IO tutorial" (not a monad tutorial!): http://blog.raek.se/2012/10/19/haskell-io-in-five-minutes/

comments