Whenever an application description begins with phrases like “runs on anything” and “is easy to setup”, attribute such bravado to the author’s lack of experience outside his development sandbox. Freehold comes as a tarball for “any Linux” and, naturally, won’t work on most of them out-of-the-box. Documentation for freehold mostly remained in it’s author’s head, as to what’s been provided to poor us unaccustomed to things that run on everything and are easy to setup is missing everything related to the installation, configuration and start-up of the application.

All these oversights are a sign of many bugs to come. Having said that, freehold has potential at least for Web UI aficionados. The application comes in two pieces: freehold server and freehold-sync client and another piece the author calls freehold client, which is not really a client but an API. So we have a developer with little experience outside a Docker container or somesuch. Probably for that exact reason this happens:

cd /tmp
wget -q https://bitbucket.org/tshannon/freehold/downloads/freehold_0.4_linux_amd64.tar.gz -O - | tar xz
cd freehold*

# ls -als
total 10596
    4 drwxr-xr-x   4 root root     4096 Sep  3  2015 .
   12 drwxrwxrwt. 38 root root    12288 Jul  8 02:14 ..
    4 drwxr-xr-x   4 root root     4096 Sep  3  2015 application
    4 drwxrwxr-x   3 root root     4096 Apr 22  2015 docs
10572 -rwxr-xr-x   1 root root 10823571 Sep  3  2015 freehold

# ./freehold
./freehold: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./freehold)

# dmidecode | grep -m1 CPU ; cat /etc/issue | grep [0-9] ; uname -r
Version:  Intel(R) Pentium(R) CPU G2020T @ 2.50GHz
CentOS release 6.5 (Final)
2.6.32-431.17.1.el6.x86_64

It would seem that freehold is seeking GLIBC 2.14 (likely among many other things that aren’t there) and I only have 2.12 on tap. This is why most applications include a list of basic system requirements, so sysadmins don’t go down the rabbit hole of endless updating and re-linking that will never get the app running and will break the server.

The server piece is a binary that doesn’t work (on my test box, at least) and comes with no instructions, prerequisites, or init scripts. Looking at the skimpy documentation just a little below the “easy to setup and get running”, the author proceeds directly to describing how awesome freehold is when it is actually working. When it’s not working, I suppose, it is slightly less amazing.

Of course there is also an option to build from source. However, to do so you will need to install the whole Go/CGO development bundle (and probably actually learn some Go and JSON in the process), which makes me think I’d rather get back to watching the “Vikings”.

I’ll set a cron job to remind me to check on the dude’s progress in a year or so, when he gets around to updating the docs and, hopefully, drops the “easy” and “everywhere” preambles. For now, advice from the recent issue of Linux Pro magazine notwithstanding, just stick with osync., rynsc, or lsync.