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.
"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."
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 ?
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.
I only just found out about borg and restic, but the sites I looked at both mention "backup" prominently. And that makes sense. If I ever sign up for rsync.net, it will be so I can store long term backups of my stuff, which I might add to incrementally, but never really change.
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.
We still use duplicity because it allows us to use our own rsync backup servers, has encryption, compression and par2 optional (defaults to 10%). Every one of these is optional. Too bad it doesn't offer the ability to use compression algorithms other than gzip (lzma or zstd would be nice).
I'm a maintainer of the Unison package in Fedora and I'd love to know which version(s) of Unison you use day to day.
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.
This incompatibility is one of the reasons why I reduced my dependency on it, though I still use it for minor things.
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.
That can happen because unison uses OCaml's built in serialization, which isn't guaranteed to be stable across OCaml versions. It doesn't often change, but the representation of arrays was changed in OCaml 4.02, which meant unison compiled with 4.01 couldn't sync with unison compiled with 4.02. Debian bug discussing the issue: https://bugs.debian.org/802919
> which isn't guaranteed to be stable across OCaml versions
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.
> 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.
This was very upsetting when it happened. The same version of unison was incompatible with itself if they had been built with different but consecutively released versions of the ocaml compiler. I feel like using compiler versions like 4.01 and 4.02 is irresponsible when it's documented that they produce binary incompatible products, but that is how it was. https://marc.info/?l=unison-users&m=142286809310149
An ugly way around it is to compile your own version of unison. The good news, if I remember correctly, is that the binary can be built in one place and copied around to the other hosts (and say put in $HOME/bin.)
Thank you for your work! I use Unison on Fedora almost every day. The version is 2.40, which IIRC is the default you get from "dnf install unison".
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.
Thanks for your work!
At the moment I'm running unison on Gentoo, Fedora and even FreeBSD hosts.
There is even a ppc64le host running Fedora.
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.
I use it in Debian, which used to (until recently) package 2 versions in every release. This was convenient for me, a conservative user, who might run old-stable on some computers for months before upgrading to stable. I have used workarounds in the past (mount home directory in a container, and sync from within) so I'm fine with a single version in Debian.
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 :)
Yep, this is PITA as a user as well. 2.48.4 on Ubuntu 18.04 but finding about the same working version for Mac required additional hunting. But nevertheless Unison is awesome. Been using for the last 15 years or so <3
that was one of my biggest problems ~8 years ago. keeping the macports and the debian versions in sync was too tiresom, someday i just switched to rsync which worked well enough for my usecase.
