Taking Notes.

I’ve always taken a keen interest in note-taking in general and recently I’ve been obsessed with how other people do it.

There tends to be a push toward avoiding information silos while at the same time making your content available or at least putting it online where it can be found, (even if you specifically aren’t writing for mass consumption).

As for me, I keep see-sawing between the convenience and ubiquity of online silos and the “privacy” of self-hosting.

I’ve gone from keeping all my notes in a single text file (not quite as ambitious as this, but close) to a private dokuwiki, back to individual text files to moving them all online to my Google Drive.

Currently, I am migrating most of my notes out of Google a into a single folder of markdown files managed by Joplin, an open-source note solution that allows you to sync your notes to a back-end you control (Dropbox or better yet, NextCloud).

I like self hosting because

1. There’s a matter of some pride in saying “I built/maintain this” (even if if is an open-source project from github) and

2. There’s no chance of a big company closing up shop or switching from free to a paid or subscription model on you.

I’ve discovered that while I’d love to say I’ve been managing my notes in a single location for years, the truth is what keeps my note-taking process interesting useful is migrating it periodically. Migrating allows me to updates notes, combine notes and prune old notes. With each iteration of my notes system I have left a little pile of notes behind. A collection of notes that no longer serve me and can be discarded.

But make no mistake, so far, self-hosting is still a lot of work. Maintaining your own backups and updating your platforms. Patching bugs and working around limitations takes up a lot of time. But in the end – is it all worth it?

I’m still trying to answer that question.

Until the next system comes along.

Read My Feed

Two weeks ago I stopped using TinyTinyRSS as my RSS feed reader. I love having self-hosted apps and the privacy and control they provide, but honestly I wasn’t real worried about someone snooping my RSS feeds or contaminating my OPML.

I’ve been making a move back to some cloud-based apps recently to avoid the maintenance and backup space that my self-hosted apps require. I decided to try two popular feed readers and see how they compared. I left myself a reminder in Google Keep (see? NOT everything is self-hosted) to give it two weeks to decide which feed reader I was going to stick with. I disabled my TTRSS instance and opened two new tabs with Feedly and inoreader

The first thing I noticed was how similar they both looked to my default layout in TTRSS. This was going to be easy – they look almost the same! I imported my OPML file and away I went.

While both apps performed admirably, I was struck by how much MORE they both wanted to do for me.

Feedly wanted to help me find new feeds in which I might be interested. It offered a secure area for my Private Business Content. It allowed me to perform power searches for keywords and let me mark articles to be read later. The free account limited me to 100 feeds, but I’ve only got about 75, so I was OK.

Inoreader let me most of the same things and offered unlimited feeds. I could also automatically tag and organize items as they came in. Inoreader also keeps my old articles (Feedly stops indexing articles older than 30 days).

Both of these apps offer a paid version with even more features. Features I didn’t investigate because I wasn’t interested in paying for something that was working just fine on my self-hosted app.

So today my reminder popped up. I was to decide which app I was going to stick with.

What did I decide?

I decided to re-enable my self-hosted TTRSS instance and go back to something that was never broken in the first place.

While TTRSS may not offer all the bells and whistles of the competition (maybe? – TTRSS does have a fair amount of plug-ins), it does exactly what I want for the price I want to pay. It’s performed admirably for three years or more and I can’t think of a better reason to change. I’ve checked out some options and I recommend highly each of the above to anyone who doesn’t have the desire or server space to self-host.

But for me, it’s back to TTRSS. Another open-source success story.

Cleveland Givecamp 2017

I made it to Cleveland Givecamp this year after many years of wanting to go but never having the guts.

I added this to my LinkedIn page:

Technical Volunteer, Cleveland GiveCamp Jul 2017

I volunteered at Cleveland GiveCamp and assisted “The Valentine Project” in refreshing their web presence. I served as site admin by managing hosting, DNS, loading the initial CMS and database and configuring email. I handled site security by configuring SSL and hardening user accounts. I also assisted with scrum-style checklists and documentation to deliver a finished product in just over 24 working hours from July 21-23, 2017.

It’s a pretty good summary of how I spent my weekend.


All-in-all I had a good time. I was assigned to The Valentine Project.
We were to design and publish a new website. I volunteered to handle the admin stuff since no one else on the team seemed to know how to get that started. (Plus, in a moment of panic on Friday night I realized I was the only one not assigned some programming-style task)

DNS was a nightmare (as always) so with some help from the “Green Shirts” I set everyone up with entries in their HOSTS files so they could at least see the WordPress site I set up and get started. CloudFlare was used for DNS. (a move questioned by more than just myself). Eventually I figured out the nameservers, got them pointed to the correct place and got the DNS sorted out and the new site started showing up under the old domain name.

After six hours Friday night, just over twelve hours Saturday and about six more hours on Sunday. We had a working site complete with SSL, new email accounts and strong passwords (I was a stickler for security – which earned me some praise from team-mates)

At the end I delivered a 3 page document to the non-profit detailing the domain registrar, DNS details, hosting account links and credentials, new email addresses and passwords and site details.

When asked why they’d need this document, I explained that if a document with similar details for their existing were prepared for us on Friday, we may have been able to finish hours earlier. Whether they understood the contents or not – it’s prudent to keep a document like this in a safe place in case they need to move hosting or change their domain (among other things)

The clients were amazing people – Saturday night they brought beer and champagne. They provided cookies and gave us each a personalized thank you note on Sunday at the conclusion of GiveCamp.

It was a fun experience. I felt like I was able to really help out (even though it was all back-end and security stuff) by providing them a safe, reliable platform on which to build their new web presence. One of the project managers mentioned that if it wasn’t for me, our group would not have passed the security check each group must pass before turning over their results. He also leaned on me a bit near the end to help steer things to the finish line (it was his first year volunteering too).

Will I do it again next year? Right now, I don’t know. But I sure had fun.

The Case for /usr/bin/env bash

Not every system has binaries in the same location!

From Ycombinator

clarry 708 days ago
Are there any situations where you wouldn’t be able to find bash in /bin/bash?
Yes there are.
OpenBSD for instance installs third party software under /usr/local. Bash is not a part of the base system.
env(1) on the other hand is a POSIX standard utility and comes with the OS.

kirubakaran 708 days ago
[in addition to what clarry said] Habit of using /usr/bin/env becomes more important in other use-cases, such as invoking Python interpreter.

nnnnni 708 days ago
Exactly. I often use “#!/usr/bin/env python2” to specify python 2.x on my systems where python 3 is the default.