A few thoughts on productivity sans silos

I have been busy with RestructuredText, and all things text in general lately. I have undertaken an overall rejection of as many proprietary software packages as possible, when trying to be more productive. Results vary.

For instance, the main things - calendar and email - are scattered about three different email providers. Two of them are Big Data advertising firms, and I have been trying to get out of their orbit for a while now. The default Apple apps are convenient as I am heavily vested in their ecosystem, but of course, there is yet another email and set of apps for that.

Todo lists ? Many many choices, all trying to make their own silos. I stick with Apple, and am making my own - but more on that a bit later. At the moment, I reach for pen and paper just to bootstrap my grand ideas.

All I want is to be able to use plain text - to move my digital files, my notes, my oeuvre from one platform to another - and open source tools to manipulate them. Or, for those of you familiar with the Getting Things Done method, the top part of the flowchart below should flow into the bottom part as effortlessly and freely as possible :


I have been burned so many times in my short life by proprietary binary file formats where the vendors either :

  • Went out of business, or

  • Used exorbitant upgrade policies, such that perfectly working software had to be abandoned if I upgraded the system for any other reason, or

  • Added so many usefless features that the software became unusable, or

  • Only works on a specific computer or PDA that I no longer have, and so on, and so forth.

In my search to see how the open source community handles this, it seems that many people do not care or use plain text files in an ad-hoc way. Or, they use Emacs Org mode. Or their phone.

For my part, I have been trying to stay with Vim (actually, NeoVim). Vim is love. Vim is life. Vim is also lacking in any organisational structure, unless you add your own via plugins (or advanced buffer manipulation). I have not settled on one yet, but VimWiki is a crowd favourite. Outside of Vim, Sphinx could be bent into serving this role as well.

While I am still not totally comfortable, I am nearly done with provisioning my personal, private cloud. Between Fastmail (cool email provider with additional 10 GB storage) and Seafile (Python powered file sync and WebDAV server), I have been able to pass images back and forth between my phone and all of my computers. Even my Slackware (now FreeBSD) netbook :


This will make blogging and de-Googling so much easier when done, and I will have insurance against Apple to boot. I will continue to experiment, but after the inital learning curve to the plaintext way of doing things, I am very optimistic

I must not have enough Slack

So, as I am wont to do from time to time, I became sidetracked during my plans for world domination. It all started with the private cloud part of my journey. I have been planning for months on using NextCloud to host my own private cloud on my VPS, but it all blew up in my face - I could not get the install to work on FreeBSD. I want my private cloud to run on FreeBSD because I believe it is a superior server - and also, because of ZFS.

In a last minute scramble last weekend, I discovered Seafile. Seafile is a Dropbox replacement written in Python (another project near and dear to my heart) that provides both a web interface and a WebDAV interface. That WebDAV part allows for highly integrated remote sync with both iOS and Android devices, which would - once complete - allow me to seamlessly move files and pictures from my phone, tablet, Mac, and computers to the cloud. My cloud.

As I had done no research or planning ahead of time, my Seafile adventure continues - but I did get it working with Nginx and CertBot. I need to fine tune the Nginx config to get the web portal totally working.....

...which leads me to Slack. See, I also set up a Samsung N120 netbook to use as my out-of-band cloud portal specifically to use for my project. It did not have to be fancy, but it did need to be able to SSH into my cloud servers. As it is a 32-bit machine, and as I wanted variety, I loked for a Linux distro - only to find that many of them have all but abandoned 32-bit machines. There was Debian 32-bit, or a variety of half-baked, unmaintained attempts at a distro.

And then - I remembered Slackware.

I like Slackware a lot. It is a source-based distribution, and does not presume so much about what you may or may not want on your system. For this project, it was perfect. Or so I thought.... turns out, many things I needed had to be compiled from source. That is not a problem on a modern CPU, or even a desktop class 32-bit CPU. But on a Intel Atom N270 ? Nah. Python 3 took roughly two hours to build, Ruby 2.6.6 and Ruby 2.7.1 both took roughly two hours - each - as well. A few apps that had PyQt5 dependencies took a ton of time as well, and PyQt5 itself built in 4 hours and 31 minutes.

But what finally broke me - even after everything else worked - was Midori. All I wanted was a small lightweight browser that could run on this machine - which currently has 1 GB RAM. I can upgrade it to 2 GB, and no, I am not running Crysis or Minecraft anytime soon. But Midori had to build WebKit, and that - along with all the needed dependencies - took 21 hours and 45 minutes to build this past weekend.

The good news ? The netbook has had one hell of a stress test. The bad news ? I needed to switch over to FreeBSD to be productive.

More to the point, I needed FreeBSD to be productive with this netbook without Debian. And by extension, Systemd. 2 million+ lines of code all stacking on top of PID 1 is not my idea of a lean, efficient environment for IoT and out-of-band access to cloud resources. While both Slackware and FreeBSD can offer a lean, mean, austere environment - FreeBSD has binaries that are ready to go.

In the meantime, I moved the blog files over to my Mac - three cheers for plaintext ! - and continued on from there. Once I finish getting the screenshots moved over, I will have some fun before-and-after pics to show off.

As for Slackware ? I believe I need to go back over the Principia Discordia and get more slack, as clearly, I did not have enough.

Fun with deployments, part 1 : Certbot

Yesterday, I finally accomplished a long term goal of mine - manually deploying my own website, with minimum of fuss and maximum control. Over the years, I have had not less than three WordPress sites blow up in my face due to brittle updates. Of the most recent five hosts I tried, two of them are no longer in business. In the meantime, precious time continued to pass....

I remember my first website on a shared host back in 1997 - some html, some css, some images - and indeed, being able to craft a website by hand is great skill to have. It is also time consuming. And on today's modern internet, you also need a certificate for SSL. Which is surreal, when I recall buying used records from Osaka in Japan and having them shipped to be from the other side of the world in 1997. People were just then starting to move from 40 bit to 128 bit encryption.

I try not to think about how naive and cavalier we were....

Traditionally, certificates were (and still are) very expensive. Many individuals, small businesses and organisations simply skipped them. I was very happy to hear about the Let's Encrypt inititiative as it really does address many pain points about cost (free as in beer), transparency (free as in freedom), and deployment (automated issuance and renewal)

When setting up this website, I used Nikola as a static site generator, and Nginx as the web server. Getting Certbot installed was easier than both of those to set up. Most distributions have a certbot meta package now - FreeBSD has that, and other modules per web server in addition. The Certbot site at certbot.eff.org has a nice helper page that will give you details on which combination of packages and commands are needed for a wide variety of Linux distribtuions.

On my web server, I only needed the base py37-certbot package. On my private cloud server that I am still setting up, I had to install py37-certbot-nginx as well - more on that adventure coming up. On a Windows VM that I expiremented with, I used a package that implemented the ACME protocol in .NET - there is no official package from the Certbot team ready to go, and no GUI one-click installers either.

Once installed, the Certbot is very fast. You will need to make sure that you have sorted out the A record of your desired domain name, though, because the bot will hard fail if you do not. Also, if you do not have access to install applications in general, then you are out of luck in general. You will also need a valid email address so that you can be reached if there is a problem. After this, you will be prompted to accept an agreement to the Terms of Service, then prompted for the domain that you are seeking a certificate for.

Certbot will let you set up multiple subdomains in the request, so that you can have both (your site here).com and (www.your site here).com. I have not yet tried a wildcard cert, but it seems possible.

After you do these things, the Certbot will run a program that reaches out to Let's Encrypt, validates that the server is the one you say it is, and issue a certificate. You will get a message informing you that either 1) something failed, or 2) that you now have a new certificate.

Make sure that you note the path that Certbot used to save the certificate, and also be aware that it comes in two parts - a public/private key pair (ending in .pem) that you will need to both secure and make a backup of, as well as refer to for any manual configuration of the web server. But as of the moment you see those files, your website certificate is live !

In my case, it all happened so fast, that I was able to actually fix the DNS records for my domain, immediately run the bot, get the certificate, and immediately refresh the page to see it kick in. Propagation is very fast, indeed.

What happens next ? Well, the theory is that if issuing certificates is automated, one can secure as site very quickly. Also, if renewing the certificates is also automated, then they will always be current. Indeed, a Let's Encrypt cert only lasts for 90 days - the expectation is that you will either create a script that seeks a renewal at regular intervals (up to five times in a seven day period) or manually run the script before your 90 days are up. But that never happens, so of course, the goal is to script a request to renew the cert. At that point, your site will maintain its security in an automated way for as long as it is running, and with no further intervention needed.....

....well, there was that one case where Let's Encrypt had to revoke 8+ million certificates, but that is a part of the bargain - if any of the certificates are compromised, they must be revoked. Otherwise, they are worthless. So far, Let's Encrypt have been very serious about maintaing the quality of the certs that they issue. In this incident, I understand that they simply send a message to Certbot running on those servers to renew. But if one were to set up a cron job to renew the cert once per week, the time exposed to an event like this would be fairly low.

In either case, I am happy that I was able to get this up and running on both my "cloud" servers. I think that, especially for individuals and small businesses, this is the way to go. Just because someone does not have a ton of money or a commerical enterprise does not mean that they cannot secure their web traffic. This project has been a wild success so far, and I thank the EFF and their partners for pulling this together.

At long last, the blog is vapourware no more!

So, it has finally happened. After trying to figure out the best way to share my thoughts with the world and share what I am up to, exactly - I have a blog up and running.

Oh, sure, WordPress is easy - and also insecure. Squarespace and Wix gave me so much trouble, even though I was totally willing to not have to geek out so hard to have a blog. But the more I looked at the landscape of possibility, the more I began to realise that I would need something very very different.

Static site generators - I was aware of this concept for a while, and came to this path because after dealing with the above bloated solutions, it was either this or :

  1. coding the site by hand, like it's 1997, or

  2. coding a quick and dirty Flask app. Not that there's anything wrong with that, I just really did not want to put yet another project on my plate, not until I at least finished a few that I already started...

Somehow, looking at people who use Sphinx to generate their website stretched my brain in the right direction. Serendipity ! I finally got my head around the static site generator concept. And I can type in Vim (neovim, more to the point) so the process is as simple as it can get. No browser crashing whilst trying to load some cleverdick javascript WYSIWYG pixel peep show. No fighting my iPad for screen space. No proprietary file formats. Just pure text, Python, and....

Ah, yes, setting up the site. But beyond that part, all is well. I can make it pretty later. I can style and theme it later. I can add pictures later. And there is no db config or anything weird either, just plain HTML autogenerated by Nikola.

Why Nikola ? For this use case, it is lighter than Sphinx. I want to lower the cognitive load of computing, and by focusing on tools that play nicely with ReStructured Text I can leverage one markup language for all my needs. Until I learn LaTex, that is. But Sphinx can generate LaTex.

At any rate, the next few posts will be about my raison d'etre, the grand schemes that I have for world domination, et cetera, ad infinitum. Thank you for visiting !

Scratching one's own itch

Today, I embark upon a new undertaking - a command-line to-do app. Sounds trivial, but it seems that so many modern productivity apps are actually marketing silos - you put your information and plans in, and when it is time to take it out, you must use their Sacred Ritual to retrieve your information to act on.

But what if that kills the momentum of actually taking action on your plans ? What if you need to get your information into a different environment on a different device in order to act upon it and get something done ?

Recently, I have been bitten by this once too many times. And so I figured, “fuck it, I’ll make my own tool“. Tasket (nee Needful) : https://gitlab.com/damiencalloway/tasket

For the longest time I was stuck on what I should do, for a project that would be meaningful, stuck on the concept of a Killer App that everyone would want to use. A mentor of mine suggested, instead, that I should seek to scratch my own itch. He then told me to read The Cathedral and the Bazaar (again) :


Indeed, this, along with the UNIX Philosophy, also suggests that one should seek to scratch their own itch in order to seek open-source enlightenment. The theory goes, that one will be more engaged with the project, and come up with the best solution to a problem if they are solving it for themselves. A bit counter-intuitive, but Eric Scott Raymond makes a very convincing argument.

The stated goal for the Needful project ? A simple, command line to-do list that is not captive - so that if I need to take the information out of that tool to act on it, I can. Eventually, I would like to bootstrap a second brain with the tool, but the Unix Philosophy favours small tools that do one thing well, versus one large monolithic tool - so we shall see where this ends.

This will be written in Python, and the journey shall be interesting. If I can get the tool to be as useful as the old-school Palm Pilot To-Do and Checklist apps I will be very happy.

And so it begins!

The much awaited blog of Damien Calloway - my spot on the web to post all of my digital shenanigans - is finally here. I plan to update this blog with all of the stuff I work on when I am not at work, as well as various philosophical musings, miscellany and sundry.

Speaking of which, and to kick things off, here is a link to a script that I spoke about at the May 2019 COhPY meeting :


This script is simple - it shows the date, time, and moon phase. Simple command line stuff, nothing too complicated. It uses os.sys to send commands to the shell, which displays the current date, calendar, and moon phase using date, cal, and pom, respectively.