Blog

Timerfd can be emulated with eventfd

Sat, 22 Sep 2018 00:00:00 -0400

I wrote an article about how timerfd can be emulated with eventfd.

Don't speak public protocols, ship mobile libraries instead

Sun, 03 Jun 2018 00:00:00 -0400

I wrote a hot take about not speaking public protocols, but shipping mobile libraries.

Monads are inferior to function arguments for effect control

Sun, 20 May 2018 00:00:00 -0400

I wrote a very hot take about how monads are inferior to function arguments for effect control.

Honestly it’s pretty incoherent and I just wrote it to get it down, but if you think you can understand my jargon-heavy manic prose, feel free to click through.

Simple, Fast, Easy Parallelism in Shell Pipelines

Mon, 18 Jan 2016 00:00:00 -0500

I wrote an article about parallelism in shell pipelines.

Docker Considered Harmful

Fri, 01 Jan 2016 07:00:00 -0500

I wrote an article about how bad Docker is.

Terminals are weird

Sat, 20 Dec 2014 16:00:23 -0500

I wrote an article about the quirks of terminals.

Plain text configuration for GNOME

Sat, 20 Dec 2014 16:00:23 -0500

For a number of reasons, I like to keep my configuration in plain text. Plain text can be edited with my favorite text editor, and it can be version controlled with the same tools as source code.

I am also a fan of the GNOME desktop. GNOME uses the gsettings API for configuration; theoretically, this API could be directly backed by plain text paths. For performance reasons, however, dconf was created to back this API.

dconf is basically a hierarchical {dictionary,map,hash-table}, with /unix/style/paths, each path containing some number of key-value pairs. Most of the time, the dconf database is compiled onto disk as a raw datastructure, and mmap’d in for lightning speed lookup.

I can use the following command to write out the dconf database recursively as plain text, starting from the root:

dconf dump / > ~/.config/dconf/user.d/everything.conf

The result of the dump looks something like the following:

[org/gnome/settings-daemon/peripherals/keyboard]
repeat-interval=uint32 27
delay=uint32 318

[org/gnome/desktop/input-sources]
xkb-options=['caps:ctrl_modifier']

Of course, most of the settings in dconf are irrelevant to me, or are machine specific. I want to find the ones that I actually care about. I can do this by grepping the dump from dconf, or dumping sub-paths.

dconf dump / | grep terminal > ~/.config/dconf/user.d/myterminalsettings.conf
dconf dump /org/gnome/terminal

The paths tab-complete, so it’s easy to do some exploration with the latter option. However, the latter option dumps only partial paths, so you’d need to edit it before loading it back in. (Or dump it to a nested directory and develop a more elaborate script for loading that uses find(1)…)

It’s a bit silly to manually guess at which configuration option is which. So another option is to watch the dconf database as it changes:

dconf watch /

Now change a setting with the graphical interface, and it’ll be printed to STDOUT! You’ll have to do a small bit of munging to get this into the same format as dconf dump prints, though. It might be simpler to just dump the path printed.

After narrowing down the dump, I delete the settings that I don’t care about, and neatly comment and arrange the rest in multiple files in ~/.config/dconf/user.d/. You can see my configuration at my dotfiles repo on Github.

Now, if I want to load those settings back in, it’s simple:

cat ~/.config/dconf/user.d/* | dconf load /

I actually really like this approach. I can have all the nice features of a plain text configuration, without the overhead.

There is also an option, built in to dconf, to store the configuration as plain text, monitor those files for changes, and compile them progressively at runtime into the fast binary file that it uses by default. This is designed to support filesystems where mmap doesn’t work well. (like NFS) Unfortunately, using this requires changing files in =/etc= at the moment, which I wanted to avoid. It would be useful if someone would add straightforward support for enabling this from =~/.config=.

The Excellence of libvirt

Sat, 20 Dec 2014 16:00:23 -0500

I wrote an article about libvirt.

A Nexus 7 as a primary computer

Thu, 15 May 2014 00:00:00 -0400

For about a year and a half, I had no laptop, only a 2012 Nexus 7 with a Bluetooth keyboard and a desktop I’d built previously.

At the time, I was a student living on campus. I was always only a short distance away from my room and desktop. My need for portable computing was limited to when I was out working with a group; most of my work would be done on my desktop whether I had a laptop or not. So, I was able to try out this maybe-inefficient approach without too much inconvenience.

This was motivated by my belief that the combination of an ARM tablet and Bluetooth keyboard is technically superior to a traditional laptop. It is more portable and flexible, has a longer battery life, and the main portion of it can be carried in a pocket. There is no technical reason why this hardware cannot be used in the same way as a laptop or netbook, with a full operating system. It’s only the software (that is, Android) running on this hardware that stops it from conquering the market.

Thus, I tried to install GNU/Linux on the Nexus 7. I installed several different images, produced by several different projects. For a short time I used desktop Ubuntu 13.04 running xmonad, Firefox, urxvt, and other GNU/Linux applications. Unfortunately, support for the hardware was poor, and a bug made using the touch-screen nearly impossible, so I reluctantly reverted to Android.

By far, the Android application I used the most was VX Connectbot for SSH access to my desktop. I work primarily in a tmux sesssion with vim and bash even today, so this suited me. Besides my browser, Firefox for Android, I didn’t consistently use any other Android apps for getting work done.

However, I believe this made it unusually easy for me to work on the tablet. I believe someone who does most of their work in a graphical environment would find an Android tablet, even with an external keyboard, difficult to use productively. Mobile applications usually have only a small feature set. The Android graphical shell’s capability for multitasking is limited. Android apps, even browsers, almost totally lack keyboard shortcuts, which forced me to stay close to the touchscreen. SSH allowed me to bypass these limitations by leaving the host operating system and connecting to another.

I now own a laptop and use it instead of a tablet. I like having access to a real browser that has keyboard shortcuts. And while most of my work is terminal or command-line based, it’s now clear to me that friction in what remains can be a powerful bottleneck. Specifically, looking up documentation online or doing research was prohibitvely difficult on the tablet. It was impossible to have documentation and a terminal open side by side, without using a terminal browser, all of which have rather poor user interfaces. This is of course a basic feature of any graphical desktop.

While I still think the hardware is good, the software doesn’t match it. This is sad, because the GNOME project is producing a top-notch, free software interface that would be great on the Nexus 7 or any other tablet, while still providing all the features of a traditional desktop and laptop interface. Sadly, hardware vendors aren’t adventurous enough to make use of the quality free software around them, and are sticking with Android. For now, I think I’ll be sticking with a laptop until a tablet with good hardware support in GNU/Linux appears. At that time I will experiment again with a tablet as a primary computer.

A modern Unix mail setup

Thu, 15 May 2014 00:00:00 -0400

I have tried to get my mail in the traditional Unix way, with an MTA, MDA, MRA, MUA, all that stuff. It was a huge pain. With some more modern programs, though, I can have a setup that still follows the Unix philosophy of single-purpose programs working together, while being a lot easier to understand.

There are four main programs in my setup:

offlineimap: fetch mail from servers
notmuch: index and search local mail
alot: read indexed mail
msmtp: send mail to servers

`offlineimap`

offlineimap connects to the IMAP servers for my gmail and self-hosted mail accounts and downloads any new mail, according to its account, into a subdirectory of ~/mail/, in Maildir format.

I also use this offlineimap-notify script, which just wraps offlineimap to pop up notifications when new mails are downloaded. As expected, these notifications are sent over D-Bus, and are displayed by a daemon which follows the Desktop Notifications Specification. (I use dunst.)

offlineimap is configured to run notmuch new when it finishes syncing. If notmuch changes anything in the mail directories, offlineimap will sync it back to the IMAP servers. This means read-status, folder location, deletion-status, etc. are synced back to the IMAP servers and available to other clients (like my phone).

`notmuch`

notmuch indexes the email living in the subdirectories of ~/mail/ and allows for fast search and tagging over them. It’s implemented on top of xapian, a text indexing and searching library. When notmuch new is run, notmuch inspects the directories it’s responsible for indexing and adds any new mail that’s appeared there to the index. Since read-status, folder location, and deletion-status are present in the Maildir format, notmuch also adds appropriate tags to represent this information internally. Then, notmuch search tag:inbox will show all the mail in my inbox, and notmuch search "tag:inbox tag:unread" will show all the unread mail in my inbox.

`alot`

When first opened, alot runs notmuch search "tag:inbox AND NOT tag:killed" and displays the results. I can navigate the results with vi-style bindings, open a specific email, and look through all the emails in that thread.

I can also compose and send mail. Composition of mail starts with alot generating a mostly-blank temporary file, with the contents depending on whether I’m sending a new mail or replying to an existing one (in the latter case, it will automatically include and quote the existing mail). As is typical, alot then runs $EDITOR tempfile, so I can compose my mail in vim or Emacs or whatever I please. When I close my editor, the updated file appears in alot, and I can add attachments or reopen my editor to do more edits. When I hit send, the file is passed to msmtp, which reads the headers to learn To, From, etc.

I also use nottoomuch-addresses.sh to get contacts tab-completion when beginning to compose an email. This builds up a database of contacts from my notmuch index. This is a stop-gap solution for me, I hope. I’d rather use the contacts in my CardDAV account, provided by ownCloud, but this database is currently close to empty. Thus I may switch over to using pyCardDav for contacts completion at some point.

`msmtp`

msmtp connects to the configured SMTP server to send the email. With multiple configured accounts, it chooses the account and corresponding server based on the provided “From” address.

msmtp provides sendmail emulation. sendmail is very frequently executed by other programs that wish to send mail. So sometimes I use the command-line program mail, from s-nail, to send small emails or attachments, since it just calls out to sendmail Likewise when I started toying with kernel development, git send-email worked out of the box, and when I tried sending mail from Emacs, it also worked with no setup. I’m sure I’ll run into other Unix utilities that also invoke sendmail, and pleasingly work with no additional configuration thanks to my use of msmtp.