I can't praise Unison enough.
I've been using it every day for over 10 years and is easily one of the most useful pieces of software I've ever come across.
I've donated multiple times over the years.
Unison was the first backup binary that we built into the rsync.net platform - breaking our original design goal of only offering client agnostic SSH and the tools that would run over that.
Shortly afterward we also added rdiff-backup. Both of these tools were quite popular and we saw a lot of interest back in 2005 - 2010 but we see very little use or interest in them now.
All of the interest in backup clients is now in rclone[1], restic[2] and borg[3].
restic was easy - you can point it at any SFTP capable host.
borg and rclone, on the other hand, we had to (like unison and rdiff-backup) build and maintain on the rsync.net server side.
All of these (save rclone, which is a binary executable) are python scripts. But we don't have a python interpreter (or any interpreter) in our very locked down platform. Can anyone guess how we do that ?
[1] https://github.com/rclone/rclone/issues/3254
Like you did with attic and borg? Quoting you on January 2016:
> We solved the problem by (cx)freezing the attic and borg python tools into binary executables. So, still no python in our environment (reducing attack surface) but the ability to run attic and borg just like they are meant to be run.
As seen here: https://news.ycombinator.com/item?id=10925123
But Unison is for syncing, which means maintaining eventually consistent replicas of a changing directory tree (up to some pragmatic exceptions and manual tweaks). The whole point of Unison is to turn multiple devices into a single failure domain, which requires a separate system for storing safe backups.
Also, open source but non free license but duplicacy, in my opinion is technically superior to restic.
In Fedora (and I think this applies in Debian too) we have to maintain 3 versions because Unison isn't interoperable across minor releases. For this reason we package 2.13, 2.27 and 2.40, and I think there is discussion about packaging the latest release too. Keeping these ancient (esp 2.13) versions going is a pain to say the least.
The last straw came when it turns out that unison was incompatible with the same version, if that version had been built on a different system. I can't remember the details but there was some library version difference that results in a unison that has the same version number but wouldn't talk to one from another system without crashing.
Drove me crazy.
Oh, so OCaml is a toy language from academics. I've read so many good things about it over the years, but no one mentioned that aspect of it. There should be a law about putting a warning in Big Red Letters on the box so someone doesn't make the mistake of using it in a large, long lived project.
What? Why did you conclude so?
> but no one mentioned that aspect of it.
Really? Did you open the documentation? It's stated explicitly.
https://caml.inria.fr/pub/docs/manual-ocaml/libref/Marshal.h...
> There should be a law about putting a warning in Big Red Letters on the box so someone doesn't make the mistake of using it in a large, long lived project.
It's documented, and it's not intended to be used for serialization, you use it in very particular cases, for example for faster object sharing with IPC for multicore. We use Json or S-expressions or other stuff for that purposes.
I really don't know why unison people don't switch to a proper serialization.
My use-case is that I run Unison on two computers running Fedora, to implement a form of "sneakernet" file sync. Work computer <-> usb thumb drive <-> home computer.
I wasn't aware that the exact version of Unison was so important. Will start paying attention to that.
Ouch! FWIW, Thanks for all your work.
On Fedora I'm using unison251-text from the croadfeldt/Unison COPR. On Gentoo it's net-misc/unison-2.51.2, on FreeBSD it's unison-nox11-2.51.2 from pkg.
But you package for Fedora, which is "upstream" for RHEL (if I'm not mistaken) with their 10 year life cycles, so I'm sure RHEL customers would love you to keep as many versions available as possible :)