nnix.com

issy

David Emerson — Thu, 03 Sep 2026 00:00:00 +0000

Source lives at github.com/davidemerson/issy.

issy is a text editor that cares about typesetting, a little. It’s written in Zig, runs on Linux, macOS, and OpenBSD, and ships as a single binary. Current release is v1.4.1.

why

I spend a lot of my day staring at text, and I wanted something with my own hotkeys and my own style preferences. But not something bloated.

Most of all, I wanted a real print path. I want the PDF to look typeset, not like someone screenshot a terminal and hit print.

two themes

the default theme. black background, violet keywords, soft green strings, dim comments.

the paper theme. Solarized Light, warm cream background, violet keywords, cyan strings. Designed for readability in bright environments.

Every color in either theme can be overridden per-key in ~/.issyrc.

print to pdf

Ctrl+P (or --print on the command line) renders the current buffer to a real PDF 1.4 file.

Headless from the command line:

issy --font "Berkeley Mono.ttf" --print output.pdf source.py

The print theme is tuned for ink on white paper. Recommended fonts: Berkeley Mono, Iosevka, JetBrains Mono, Commit Mono. Font metrics are sanity-checked on load to be sure you’ve made a sensible choice.

multiple cursors

Ctrl+D selects the word under the cursor and adds a cursor at the next occurrence. Press it again to keep adding. Each press arms a rename: the word is highlighted at every secondary cursor, and the first character you type replaces it everywhere in one shot. From there, every edit, whether typing, Enter, Tab, backspace, delete, or paste, applies at all cursors simultaneously, and Ctrl+Z undoes the whole multi-cursor tick as one step.

incremental search

Ctrl+F enters search mode; each keystroke re-runs the search from the position where you started and jumps the cursor to the first match. While the prompt is open, every visible match is highlighted, the match at the cursor is underlined, and a dim 3/17-style counter sits after the pattern. Search is smart-case: all-lowercase patterns match case-insensitively, any uppercase letter makes the match exact. Tab toggles whole-word matching (shown as [w] in the prompt). Down or Ctrl+G walks to the next match, Up walks to the previous one, Enter confirms, and Escape cancels and returns the cursor to where it started.

keyboard and mouse selection

Shift with an arrow key extends the selection one character at a time; Ctrl+Shift+Left and Ctrl+Shift+Right grow it a word at a time. Click places the cursor, double-click selects the word under it, triple-click selects the line, and shift-click extends from the existing anchor. Drag past the viewport edge and the view autoscrolls.

system clipboard

Copy and cut push to the OS clipboard via OSC 52, so copying from an SSH session lands in the host clipboard without extra plumbing (tmux wants set -g set-clipboard on first). Copies over 100KB stay internal-only with a status notice.

Since v1.3.0 the read direction works too. Ctrl+V asks the terminal for the system clipboard over OSC 52, so text copied in any other application pastes straight in, and middle-click pastes the primary selection the same way.

wide glyphs

Wide text renders in place rather than as blanks, the cursor lands on the glyph you’d expect, and a click on either half of a wide glyph snaps to it.

path completion

Type a partial directory or filename and press Tab to auto-complete against what’s on disk.

swap files

While a buffer has unsaved changes, issy writes them to a sibling .<name>.swp file every couple of seconds, and removes it on save, reload, file switch, or clean exit (SIGTERM and SIGHUP shut down gracefully and clean up too).

Related: if the open file changes on disk underneath you (a git pull, another editor), Ctrl+R reloads, with a confirm prompt.

per-file cursor memory

Quit a file and issy remembers the cursor position at ~/.cache/issy/positions.txt; reopening the same file restores the caret automatically.

opt-in editing aids

Two behaviors I like but didn’t want to force on anyone, both off by default:

auto_close_brackets = true makes typing an opener insert the matching pair with the cursor between them, as one undo step.

wrap_indent = true makes soft-wrap continuation rows hang under the wrapped line’s own leading whitespace instead of a flat 2 columns.

install

one-line curl (linux, openbsd)

curl -sSL https://raw.githubusercontent.com/davidemerson/issy/main/install.sh | sh

Drops issy at ~/.local/bin/issy, verifies an Ed25519 signature over the release manifest against a public key baked into the script, verifies the binary’s SHA-256 against that signed manifest, seeds ~/.issyrc with commented defaults if you don’t already have one, records the release it just installed in ~/.cache/issy so the first launch doesn’t advertise an update you already have. Prebuilt binaries cover Linux amd64/arm64 and OpenBSD amd64. On platforms without a prebuilt (or when you invoke the installer on macOS), it falls through to zig build -Doptimize=ReleaseSafe from source, with either Zig 0.15.x or 0.16.x on PATH.

Flags: --prefix DIR to relocate, --version VER to pin to a specific release, --no-rc to skip the ~/.issyrc seed, --help for the rest. Prefer to read the script before piping it to a shell? Fetch it with -o install.sh and run it once you’re happy.

Prefer to skip the script entirely? The raw binaries (and the signed manifest to check them against) are attached to every GitHub release.

macos via homebrew

brew tap davidemerson/issy https://github.com/davidemerson/issy
brew install issy

The formula tracks tagged releases (vX.Y.Z), so upgrades are just brew upgrade issy, the same one-liner you’d use for any Homebrew package. No --fetch-HEAD, no uninstall-and-reinstall dance. CI rewrites the formula’s url and sha256 on every tag push via a release-tag job, so the versioned formula stays current without manual edits, and it stamps the release commit and its timestamp into the build so issy --version reports the real SHA and update notifications work.

Want the bleeding edge between releases? brew install --HEAD issy still builds from main, and brew upgrade --fetch-HEAD issy pulls the latest commit.

The formula pins its build dependency to zig@0.15 rather than the unversioned zig formula, which is a moving target: Homebrew bumped it to 0.16 mid-cycle, and at the time that broke the build. issy itself builds on both series now, but the pin keeps Homebrew builds from moving out from under us, carries Apple’s Xcode 26.4 TBD compatibility patch, and is kept in sync with the ZIG_VERSION used by CI.

Prebuilt macOS binaries aren’t shipped because cross-compiled Mach-O from Linux has no code signature and Apple Silicon refuses to run it. Homebrew, or the curl installer (which falls through to a source build on macOS), produces a native host-signed binary that runs on both Intel and Apple Silicon with no xattr or codesign workarounds.

openbsd

The curl installer downloads a prebuilt amd64 binary. Builds are verified on every push by a real OpenBSD 7.9 amd64 VM in CI (openbsd-test job); the full unit and integration suite must pass on OpenBSD before main accepts a merge. An editors/issy port was submitted to ports@openbsd.org at v1.3.1. Once it lands, pkg_add issy will be the preferred path.

Building from source: pkg_add zig then zig build -Doptimize=ReleaseSafe. bash and expect (also via pkg_add) are needed if you want to run the integration test suite.

build from source

Requires Zig 0.15.x or 0.16.x; CI exercises 0.15.2 and 0.16.0. Zig 0.16 moved most of std.fs under std.Io with an explicit capability argument and dropped a handful of std.posix calls. Rather than thread an Io handle through the editor, src/fsx.zig wraps the thirty-odd file, environment, and process operations issy uses and dispatches at comptime on the toolchain version, so the same source builds on both series. Anything outside them is rejected at compile time with an actionable error instead of a page of inscrutable ones.

git clone https://github.com/davidemerson/issy
cd issy
zig build -Doptimize=ReleaseSafe
install -m 0755 zig-out/bin/issy ~/.local/bin/issy

cross compile

Zig makes this trivial for Linux and macOS:

zig build -Dtarget=x86_64-linux-gnu
zig build -Dtarget=aarch64-linux-gnu
zig build -Dtarget=x86_64-macos
zig build -Dtarget=aarch64-macos

Or zig build cross to build all targets at once. The exception is OpenBSD: Zig doesn’t ship OpenBSD libc headers, and modern OpenBSD kills processes that make raw syscalls outside libc, so the OpenBSD release binary is built natively inside the CI VM instead of cross-compiled.

usage

issy [options] [file[:line]]

issy main.zig
issy src/editor.zig:42    # open at line 42
issy draft.md:5           # works for new files too: creates draft.md
issy newdoc.md            # start a new file at that path
issy                      # empty buffer

Command-line options:

Flag	Description
`--version`, `-v`	Print version and exit
`--help`, `-h`	Print usage and exit
`--config FILE`	Use a specific config file
`--theme NAME`	Override theme (`default`, `paper`)
`--font PATH`	TTF/OTF font for PDF output
`--no-config`	Skip loading config file
`--print FILE`	Export to PDF and exit (no TUI)
`--rollback`	Swap in the previous binary (if auto-update has run) and exit

keybindings

The ones you’d expect, mostly.

Key	Action
Ctrl+S	Save, from any mode (a buffer with no filename prompts for a path, with Tab completion)
Ctrl+Q / Ctrl+W	Quit (on unsaved changes: Enter or Ctrl+Q again discards, Ctrl+S saves and stays, Escape cancels)
Ctrl+Z / Ctrl+Y	Undo / redo (typing runs coalesce within 500ms, one step per word)
Ctrl+C / Ctrl+X	Copy / cut (also push to the OS clipboard via OSC 52)
Ctrl+V	Paste the system clipboard via OSC 52 (falls back to the internal clipboard if the terminal won’t answer)
Ctrl+Shift+V / Shift+Insert	Terminal-native paste of the clipboard / primary selection, as bracketed paste
Ctrl+A	Select all
Ctrl+F	Incremental search (Tab toggles whole-word, Up/Down walk matches)
Ctrl+G	Find next match
Ctrl+H	Search and replace (Tab switches fields, Enter replaces next, Ctrl+A replaces all as one undo step)
Ctrl+O	Open file
Ctrl+N	New empty buffer
Ctrl+P	Export to PDF
Ctrl+R	Reload file from disk
Ctrl+L	Go to line
Ctrl+D	Add cursor at next occurrence of word (and arm a rename)
Ctrl+Left / Ctrl+Right	Jump by word
Shift+Arrow	Extend selection by character
Ctrl+Shift+Left / Right	Extend selection by word
Ctrl+/ or F1	Show keybindings overlay

Middle-click pastes the primary selection at the click point.

configuration

The installer seeds ~/.issyrc on first run with every setting commented out, so you can see what’s available and uncomment what you want. Unknown keys are ignored; missing keys fall back to compiled-in defaults. The editor watches ~/.issyrc for mtime changes and reloads live, so edits to config land in the running editor without a restart. The reload is debounced until the new mtime has held still for a full tick, so a half-written file from a non-atomic external save is never applied. The full reference is in CONFIGURATION.md in the repo. A minimal example:

tab_width = 4
expand_tabs = true
line_numbers = true
right_margin = 100
cursor_style = bar
font_file = "/path/to/font.ttf"

[theme.paper]

Newer keys worth knowing about: swap_files and system_clipboard (both on by default, see above), auto_close_brackets and wrap_indent (opt-in, see above), and autoupdate (below).

syntax highlighting

C, C++, Zig, Python, JavaScript, TypeScript, Rust, Go, Ruby, Java, Shell, HTML, CSS, JSON, YAML, TOML, Makefile, Dockerfile, Markdown, and TeX/LaTeX. Twenty in total, which covers just about everything I touch on a given day. Language is detected by file extension or well-known filename (Makefile, Dockerfile, Gemfile, shell dotfiles like .bashrc).

Multi-line constructs carry across lines: C block comments, Python triple-quoted strings, JS/TS template literals, and Zig \\ line strings all highlight correctly, even when their opening delimiter is scrolled off-screen. The renderer keeps a per-line syntax-state cache so this stays cheap.

auto update

Release builds check for newer versions on startup. The check is an HTTPS request to a commit.txt asset on the latest GitHub release.

If you’d rather not have this, notify_updates = false disables the check entirely.

dotfiles

David Emerson — Mon, 27 Jul 2026 00:00:00 +0000

Updated scripts are maintained at github.com/davidemerson/dotfiles.

These dotfiles configure a workstation on Debian Linux, OpenBSD, or macOS from a single POSIX shell script. No Salt, Ansible, or other configuration management tools, just sh provision.sh. The script is idempotent and safe to re-run after pulling updates.

Supported platforms are Debian 13+, OpenBSD 7.8+, and macOS with Homebrew.

how it works

provision.sh detects the OS via uname -s and branches accordingly:

Debian Linux: installs packages via apt-get, configures sway (Wayland), foot, waybar, wofi, swaylock, mako. Logs in through greetd + tuigreet.
OpenBSD: installs packages via pkg_add, configures i3 (X11) with patched builds of st and dmenu, enables the xenodm login greeter.
macOS: installs packages via Homebrew (installing Homebrew itself if missing), deploys .zshrc, .wezterm.lua, and the shared configs. No window manager configuration.

On Linux and OpenBSD it runs as root and prompts for the username to provision (creating the user if needed, putting it in sudo or wheel, and setting bash as the login shell). It also prompts for a hostname and makes sure the hostname resolves in /etc/hosts, which prevents slow lookups. On macOS it runs as your normal user.

os-conditional blocks

Some config files need different content per OS. Rather than maintaining separate files, I use simple markers. From .bashrc:

# @@IF_OPENBSD@@
if [ "$(tty)" = "/dev/ttyC0" ]; then
	startx
fi
# @@END_IF@@
# @@IF_LINUX@@
if [ "$(tty)" = "/dev/tty1" ] && ! systemctl is-active --quiet greetd 2>/dev/null; then
	exec sway
fi
# @@END_IF@@

At deploy time, sed strips blocks for other OSes and removes the marker comments, leaving a clean config file. There is also a @@HOME@@ marker that gets replaced with the target user’s home directory (.issyrc uses it for an absolute font path). This replaces the Jinja2/Salt templating from the earlier version of this project with zero dependencies. .gitconfig uses the same trick to enable delta as the diff pager only on Linux, where it’s packaged.

file routing

Not every dotfile deploys on every OS:

Linux gets sway, swaylock, waybar, wofi, foot, and mako configs. Skips i3, i3status, dunst, .xinitrc, and .zshrc.
OpenBSD gets i3, i3status, dunst, .xinitrc, and the lock and volnotify scripts. Skips sway and friends, and .zshrc.
macOS gets .zshrc and .wezterm.lua instead of .bashrc/.bash_profile, and skips all window manager configs.
Everything else (git, ssh, tmux, issy, fonts, cursors, theming, .Xresources, and the workstation, shot, and sysinfo scripts) deploys on all three. Some of it is inert outside its home OS, which is fine.

One file is special: .config/workstation.conf is seeded once and never overwritten on re-runs, so each machine keeps its own values.

procedure

linux (debian)

VMWare Workstation settings (if applicable):

Enable Virtualize IOMMU to prevent keyboard lag.
Enable 3D Acceleration with ~2GB VRAM.
Enable Enhanced Keyboard if available to avoid Windows lock conflicts.

Standard Debian installation, selecting Desktop, SSH Server, and Standard System Utilities. Then:

su -
apt update && apt install git
git clone https://github.com/davidemerson/dotfiles.git
cd dotfiles/
sh provision.sh
reboot

After reboot, greetd presents tuigreet on vt7. Logging in runs /usr/local/bin/sway-session, a login shell wrapper so the session inherits the environment from .bashrc, which then launches sway. Mod4+Return opens foot. If greetd isn’t running for some reason, a tty1 console login starts sway on its own, so a broken greeter never locks me out of the desktop.

Beyond the desktop, the Linux run also sets the console font to Berkeley Mono (see below), masks gdm in favor of greetd, sets the timezone to America/New_York, pins NTP servers for systemd-timesyncd with a Cloudflare fallback, installs Sublime Text from the official apt repository, sets Google Chrome as the default browser through update-alternatives and the per-user xdg default, and installs open-vm-tools-desktop when it detects VMware.

openbsd

Standard OpenBSD installation. On smaller disks, ensure /usr/local has at least 2GB (the full install uses about 1.6GB in /usr/local).

pkg_add git
git clone https://github.com/davidemerson/dotfiles.git
cd dotfiles/
sh provision.sh
reboot

After reboot, xenodm presents a login on a solid black background. Logging in runs ~/.xsession, which launches i3. Mod4+Return opens st.

Why xenodm? The VMware SVGA adapter has no DRM/KMS driver on OpenBSD, so Xorg needs aperture access, which means running as root. xenodm provides that without making Xorg setuid. The provisioning script comments out xconsole in Xsetup_0 (otherwise i3 tiles it fullscreen as the only window) and keeps the script executable after editing it. xenodm reads ~/.xsession rather than ~/.xinitrc, so .xinitrc is mirrored to .xsession: the same i3 session launches whether you come in through xenodm or through startx (which .bashrc still runs automatically on a ttyC0 console login).

Beyond the desktop, the script does a fair amount of OpenBSD system configuration:

doas for the wheel group (permit persist :wheel).
Timezone set to America/New_York (same as Linux). The bar carries a separate UTC clock.
UTF-8 locale exported in .bashrc for proper Unicode in st and btop.
NTP: writes /etc/ntpd.conf with pool servers, time.cloudflare.com, the VMware host-time sensor, and HTTPS constraints, and sets ntpd -s so the clock steps at boot. OpenNTPD only steps at startup though; a running daemon just slews, so a VM that jumps mid-run (snapshot, suspend, clone) never catches up. A small clock-guard script runs from cron every 10 minutes, checks the vmt0 sensor delta, and restarts ntpd (with an rdate step) if the guest has drifted more than 10 seconds.
noatime: FFS partitions get noatime in fstab and remounted live, which skips access-time writes and reduces I/O.
Console font set to Spleen 8x16 where the display driver supports it (simplefb on VMware arm64 does not).
VMware Xorg config: when the script detects VMware it pins the vmware driver and sets a 4K default mode with a large virtual size. open-vm-tools isn’t packaged for OpenBSD, so there’s no dynamic host-window resize; use xrandr to switch between the listed modes.
Removes the default /etc/i3/config that conflicts with the user config.

Why i3 instead of sway on OpenBSD? OpenBSD on VMware uses a framebuffer with no DRM/GPU driver, which means sway (Wayland) can’t create a rendering backend. i3 on X11 works out of the box. The i3 config mirrors the sway config (same keybindings, colors, gaps, workspaces) and adds a few things of its own: thin 2px borders with no title bars, auto-floating for dialogs and pop-ups, and an st scratchpad terminal started at launch.

macos

git clone https://github.com/davidemerson/dotfiles.git ~/dotfiles
cd ~/dotfiles
sh provision.sh

Run as your normal user, not root. The script installs Homebrew if missing, then CLI tools, WezTerm, and the application casks. Since CoreText doesn’t scan ~/.fonts, the font is also copied to ~/Library/Fonts so WezTerm can find it.

sshd hardening

On Linux and OpenBSD, the script sets sshd to key-only auth (PasswordAuthentication no, KbdInteractiveAuthentication no). The candidate config is validated with sshd -t before it replaces the real one, so a bad edit can never lock you out. macOS keeps its own Remote Login settings.

manual steps after provisioning

Place the SSH key at ~/.ssh/id_d_nnix.pem (plus matching .pub). Both .ssh/config and .gitconfig reference that path, for auth and for commit signing. If you use a different key, edit .gitconfig, .ssh/config, and .config/git/allowed_signers in the repo first. If the private key has no sibling .pub, generate one with ssh-keygen -y, so workstation can tell when the key is already loaded.
Fill in ~/.config/workstation.conf if you want the workstation command (see below).
Sign in to 1Password and enable its browser integration in Chrome. Chrome is allow-listed by default, so there’s nothing else to configure.

what gets installed

Component	Linux	OpenBSD	macOS
Window Manager	Sway (Wayland)	i3 (X11)
Greeter	greetd + tuigreet	xenodm
Terminal	foot	st (patched)	WezTerm
Status Bar	waybar	i3bar + i3status
Launcher	wofi	dmenu (patched)
Lock	swaylock	i3lock via `lock` script
Notifications	mako	dunst
Volume	pamixer + wob	sndioctl via `volnotify`
Clipboard	wl-clipboard + cliphist	clipmenu
Privilege	sudo	doas	sudo
Browser	Google Chrome	Chromium
Password manager	1Password + CLI		1Password + CLI
Mail	Fastmail		Fastmail
Notes / Tasks	Joplin, Todoist		Joplin, Todoist
Media	VLC, Audacity	VLC, Audacity	VLC, Audacity
Meetings	Zoom		Zoom
Git GUI	GitHub Desktop (community)		GitHub Desktop
Networking	ZeroTier
AI CLI	Claude Code		Claude Code
Editor	issy (default), micro, nano, Sublime Text	issy (default), nano	issy (default), micro, nano
Shell	bash	bash	zsh
Multiplexer	tmux, herdr	tmux (base)	tmux, herdr
Remote shell	mosh	mosh	mosh
Fetch	pfetch + sysinfo	pfetch + sysinfo	pfetch + sysinfo
Firmware / ECC	fwupd, rasdaemon
Smart card	pcscd + libccid + opensc
Tools	htop, btop, nmap, screen, lsd, ethtool	htop, btop, nmap, screen, lsd	htop, btop, nmap, lsd
Font	Berkeley Mono	Berkeley Mono	Berkeley Mono

pfetch isn’t packaged on Debian or OpenBSD, so the script fetches the upstream script directly to /usr/local/bin. herdr ships prebuilt binaries only: Homebrew on macOS, a GitHub release binary on Linux, and no OpenBSD builds, so it’s skipped there. Claude Code installs per-user to ~/.local/bin/claude on Linux and macOS, and is skipped on OpenBSD.

desktop applications

On Linux the apps come from wherever upstream actually ships them, which is not consistent:

1Password from the upstream apt repo with debsig-verify, plus the op CLI. Mod4+p for quick access, Mod4+Shift+p for the main window, Mod4+Shift+z to lock.
Todoist (Mod4+t) and Joplin as official AppImages under /opt, each with a /usr/local/bin wrapper and a .desktop launcher.
Fastmail (Mod4+e) as the official Flatpak from Flathub.
VLC and Audacity from apt. Zoom from the official .deb, which self-updates in-app because there’s no upstream apt repo. GitHub Desktop is the community shiftkey build, since GitHub ships no official Linux app.

macOS gets the same set as official casks, including the genuine GitHub Desktop. OpenBSD gets VLC and Audacity from packages; none of the rest have OpenBSD builds, so they’re skipped.

built from source

Three things are compiled rather than installed from packages:

issy

issy is my text editor, and it’s the default EDITOR on all three platforms. The script builds it from the latest source with Zig. issy needs Zig 0.15.x (0.16 breaks it), so the script verifies any zig on PATH and otherwise installs a pinned one: zig@0.15 via Homebrew, pkg_add zig on OpenBSD, or the official 0.15.2 tarball on Linux. Re-runs compare the installed commit (from issy --version) against upstream HEAD and rebuild only when upstream is newer. If Homebrew already manages issy on macOS, brew keeps ownership and the script just runs brew upgrade. Configured via ~/.issyrc, which points at the Berkeley Mono font file for PDF printing.

st and dmenu (openbsd)

The stock st and dmenu packages stay installed as fallbacks (and for terminfo), but the binaries are replaced with builds from st-flexipatch and dmenu-flexipatch, pinned to specific commits, with config.h and patches.h kept in this repo.

st patches: clipboard (selection auto-copies to the system CLIPBOARD), keyboard-select (mouseless copy), scrollback with mouse wheel, anysize, bold-is-not-bright, boxdraw. dmenu patches: fuzzy match with highlighting, case-insensitive, centered, line-height padding, border.

The builds are stamped with the flexipatch commit plus the OS release, and rebuild when the pinned commit changes, when uname -r changes (a sysupgrade breaks old binaries), when the binary fails ldd, or when the on-disk binary isn’t ours (checked by looking for Berkeley Mono in strings output, because pkg_add -u reinstalls the stock package over the patched one).

the console font (linux)

The Linux console runs Berkeley Mono too. scripts/build-console-font.sh rasterizes bmv.otf into a ~16x32 PSF bitmap, which lands in /usr/share/consolefonts and gets set through console-setup’s FONT=. The greeter’s vt7 isn’t covered by console-setup, so a greetd.service drop-in runs setfont there as well. tuigreet’s password mask is • rather than the default ※, because Berkeley Mono has no glyph for U+203B. tuigreet also has no flag to suppress its window title, so scripts/patch-tuigreet-title.sh handles that, re-applied automatically after upgrades via an APT hook.

keybindings

Consistent across sway (Linux) and i3 (OpenBSD):

Key	Action
Mod4 + Return	Terminal (foot / st)
Mod4 + d	Launcher (wofi / dmenu)
Mod4 + b	Browser (Chrome / Chromium)
Mod4 + z	Lock screen
Mod4 + c	Clipboard history (cliphist / clipmenu)
Mod4 + Shift+q	Kill window
Mod4 + w	Kill window (alias)
Mod4 + Shift+e	Exit (with confirmation)
Mod4 + Shift+s	Shutdown (with confirmation)
Mod4 + j/k/i/l	Focus left/down/up/right
Mod4 + Shift+j/k/i/l	Move window
Mod4 + h/v	Split horizontal/vertical
Mod4 + 1-0	Switch workspace
Mod4 + Shift+1-0	Move to workspace
Mod4 + Shift+space	Toggle floating
Mod4 + m/n	Volume up/down
Mod4 + r	Enter resize mode
Mod4 + Shift+c	Reload config
Mod4 + Shift+r	Reload (sway) / restart (i3)

Linux adds the application bindings and Wayland screenshots:

Key	Action
Mod4 + t	Todoist
Mod4 + e	Fastmail
Mod4 + p	1Password quick access
Mod4 + Shift+p	1Password main window
Mod4 + Shift+z	1Password lock
Print / Shift+Print	Screenshot, full screen / select region

OpenBSD adds a few of its own:

Key	Action
Mod4 + Shift+m	Mute toggle
Mod4 + `	Scratchpad terminal
Print or Mod4 + p	Screenshot, full screen
Mod4 + Print or Mod4 + Shift+p	Screenshot, select region

helper scripts

Deployed to ~/.local/bin:

workstation (all OSes): one-shot mosh into the admin workstation. Loads the SSH key into the agent (using the Keychain on macOS), makes sure ~/.ssh/config has Host entries, probes the primary overlay path, falls back to the secondary automatically, and execs mosh. Targets live in ~/.config/workstation.conf (user, key, optional key fingerprint, hosts, labels, ssh aliases), which provisioning seeds once and never overwrites, so each machine can point somewhere different. The tracked copy is intentionally blank since the repo is public, and the script refuses to run until it’s filled in. workstation -h shows the configured paths; workstation <label> forces one.
shot (all OSes): screenshot to ~/pictures/screenshots, copied to the clipboard, with a notification. It picks its tooling from the session: grim/slurp and wl-copy under Wayland, scrot and xclip under X11. shot region for interactive selection. It only claims “clipboard” in the notification when the copy actually worked.
sysinfo (all OSes): appends CPU cores/sockets/threads, per-physical-disk usage, and the current epoch to the login fetch, styled to match pfetch.
lock (OpenBSD): screenshots the display, pixelates it with ImageMagick, and hands it to i3lock. Triggered by Mod4+z, by xss-lock on X screensaver idle, and by xautolock as a backup timer.
volnotify (OpenBSD): adjusts sndio volume and shows a dunst OSD with a progress bar. Stacks rather than piling up notifications.

On Linux, sway handles the equivalents natively: swayidle locks with swaylock at 15 minutes and again before sleep, powers outputs off at 30, and volume goes through pamixer with a wob overlay bar. The waybar volume module sits right of memory: scroll to change, left-click opens pavucontrol to pick an output device, right-click mutes.

clipboard and ssh-agent

Two small things that make the desktop behave like the terminal does.

On sway, wl-paste --primary --watch wl-copy mirrors the primary selection into the clipboard, so selecting text anywhere makes it pasteable with Ctrl+Shift+V, matching how patched st behaves on OpenBSD. wl-paste --watch cliphist store keeps a history, so a selection that clobbers something you copied earlier is recoverable; Mod4+c opens the history in a wofi picker.

On Linux and OpenBSD, .bashrc starts one shared per-user ssh-agent bound to a fixed socket in $XDG_RUNTIME_DIR and reuses it across every shell and the WM session it launches. Without it, a fresh sway or i3 session has no agent at all, and both workstation and SSH commit signing have nowhere to load the key. macOS uses the launchd agent instead. workstation will start the same shared agent itself if it can’t reach one.

maintenance and hardening (linux)

Beyond Debian’s stock fstrim, logrotate, and fwupd-refresh timers, configure_maintenance adds:

unattended-upgrades for all Debian updates (main, updates, security), removing unused dependencies and old kernels. It never auto-reboots; a needed reboot is flagged, not forced.
needrestart, report-only, so I know which services want restarting and whether the kernel needs a reboot.
Bounded logs: the persistent journal is capped at SystemMaxUse=1G.
smartmontools watching drive health.
A weekly health check: scripts/healthcheck installs to /usr/local/bin and runs from healthcheck.timer, logging reboot-required, disk usage, failed units, SMART/NVMe wear, ECC error counts, temperatures, and pending updates to the journal. Read it with journalctl -t healthcheck; the target user is added to the systemd-journal group so it doesn’t need sudo. Every probe is guarded, so it’s a harmless no-op wherever a subsystem is absent, like in a VM.

configure_hardening adds an nftables host firewall (default-deny inbound, allowing loopback, established/related, ICMP, SSH, mosh on UDP 60000-61000, and ZeroTier on UDP 9993, with outbound open), a conservative sysctl drop-in (kptr_restrict, dmesg_restrict, yama.ptrace_scope, no ICMP redirects or source routing, syncookies, fs.protected_*), zram compressed swap (zstd, half of RAM, so memory spikes stay off the NVMe), and systemd-oomd for graceful behavior under memory pressure.

fwupd is installed but the script never flashes firmware. That’s deliberate and stays out of band: fwupdmgr refresh && fwupdmgr update, by hand, when I mean it. rasdaemon is enabled to log ECC/MCE events, which is useful wherever the kernel EDAC layer sees a memory controller and a no-op otherwise.

shell environment

.bashrc (Linux/OpenBSD) and .zshrc (macOS) implement the same two-line prompt: user@host @ cwd on the first line, a blue >>> on the input line, and a right-aligned status badge (navy with a timestamp on success, inverted light gray with the exit code on failure). bash paints the badge onto the first line with cursor positioning; zsh uses RPROMPT, so it sits beside the input line instead.

Aliases in both:

alias ls='lsd -laF'
alias ll='lsd -laF'
alias la='lsd -la'
alias top='btop'

Both set EDITOR=issy, 20k lines of deduplicated history, and colored man pages via LESS_TERMCAP (light blue headings, navy standout). On Linux there’s also fzf (Ctrl-R for history, Ctrl-T for files) and fd, aliased from fdfind. Interactive logins print a minimal fetch: hostname header, pfetch (os, shell, uptime, memory), then sysinfo’s cpu, disk, and epoch lines. It’s suppressed inside tmux to avoid per-pane spam.

.bash_profile sources .profile (for PATH on OpenBSD) and then .bashrc.

theming

Everything uses one palette: grayscale plus navy #1f2d4d and light blue #8fb6e0/#bcd6f2, on black.

Font: Berkeley Mono Variable NNIX (~/.fonts/bmv.otf), mapped as the generic monospace family via ~/.config/fontconfig/fonts.conf, so every fontconfig client inherits it. It’s the terminal font in foot, st, and WezTerm, the UI font in sway, i3, waybar, wofi, swaylock, dmenu, mako, and dunst, and (rasterized to PSF) the Linux console font.
Cursor (Linux/OpenBSD): the plan9 Xcursor theme, vendored at ~/.icons/plan9 and set as the default for X11 (Xcursor.theme, ~/.icons/default), sway (seat xcursor_theme), and GTK.
Terminals: foot and WezTerm carry near-identical 16-color grayscale-plus-blue palettes (WezTerm’s whites are a touch brighter); the patched st has the palette compiled in.
tmux: matching status bar, navy active window, light blue pane borders. Splits with | and - keep the current path, and pane focus is j/k/i/l like the window managers.
btop: a custom nnix theme, plus vim keys. micro gets a matching nnix colorscheme.
GTK 3/4: prefer-dark plus the plan9 cursor. On Linux prefer-dark is also set as a system dconf default so libadwaita, the xdg portal, and Chrome follow it, and Qt apps are pushed dark with adwaita-qt/adwaita-qt6 via QT_STYLE_OVERRIDE.
Notifications: mako on Linux, dunst on OpenBSD, both black with a navy frame.
man pages: colored via LESS_TERMCAP exports.
Bars: waybar shows workspaces, window title, network, CPU, load and network histograms (loadgraph.sh and netgraph.sh, drawn in the same gray-to-blue ramp), RAM, volume, and two clocks, Eastern with a %Z label and UTC. i3status shows ethernet IP, CPU, load, and the same two clocks. The system clock is Eastern on both, and the UTC clock is an explicit per-module override.

git

.gitconfig signs commits and tags with the SSH key (gpg.format = ssh), verified against ~/.config/git/allowed_signers, and carries a set of defaults I want everywhere: main as the initial branch, fast-forward-only pulls, autoSetupRemote on push, pruning fetches, autostash on rebase, zdiff3 conflict style, and histogram diffs with move detection. On Linux it also uses delta as the pager and interactive diff filter. .ssh/config carries the GitHub identity, with UseKeychain on macOS.

repository structure

provision.sh              # the whole show (POSIX sh)
validate.sh               # checks all expected files exist
Makefile                  # make validate / provision / backup
DEPENDENCIES.md           # platform and package inventory
README.md, LICENSE
.gitignore                # excludes backups, SSH keys, session junk
scripts/
├── healthcheck               # weekly health check (Linux, → /usr/local/bin)
├── build-console-font.sh     # rasterizes bmv.otf into a console PSF
├── BerkeleyMonoNNIX.psf.gz   # the resulting console font
└── patch-tuigreet-title.sh   # drops tuigreet's window title
st/config.h, patches.h    # patched st build config (OpenBSD)
dmenu/config.h, patches.h # patched dmenu build config (OpenBSD)
dotfiles/
├── .bashrc, .bash_profile   # bash: prompt, aliases, ssh-agent, sway/startx autostart
├── .zshrc                    # zsh: same prompt and aliases (macOS)
├── .xinitrc                  # xrdb, cursor, caps→escape, key repeat, dbus + i3
├── .Xresources               # crisp Xft rendering, plan9 cursor
├── .gitconfig                # identity, SSH commit signing, defaults, delta
├── .ssh/config               # GitHub host entry
├── .tmux.conf                # tmux behavior + palette
├── .wezterm.lua              # WezTerm: font, palette, panes (macOS)
├── .issyrc                   # issy editor settings
├── .fonts/bmv.otf            # Berkeley Mono Variable NNIX
├── .icons/plan9/             # plan9 cursor theme
├── .local/bin/               # workstation, lock, shot, volnotify, sysinfo
└── .config/
    ├── sway/, waybar/, foot/, swaylock/, wofi/, mako/  # Linux desktop
    ├── i3/, i3status/, dunst/                          # OpenBSD desktop
    ├── fontconfig/fonts.conf                     # monospace = Berkeley Mono
    ├── gtk-3.0/, gtk-4.0/                        # dark theme + cursor
    ├── btop/                                     # nnix theme
    ├── micro/, sublime-text-3/                   # other editor settings
    ├── git/allowed_signers                       # SSH signature verification
    └── workstation.conf                          # per-machine, seeded once

make validate runs validate.sh, which checks that every expected file is present. make backup copies the existing dotfiles (.config, the shell rc files, .gitconfig, .ssh, .wezterm.lua, .xinitrc, .tmux.conf, .issyrc, .Xresources, .local) into a timestamped backups/ directory before you overwrite them.

notes

re-applying updates

cd /path/to/dotfiles
git pull
sh provision.sh

All operations are idempotent. Package managers skip installed packages, from-source builds skip when their stamps match, and files are overwritten with the current version (except workstation.conf).

after an openbsd sysupgrade

OpenBSD has no cross-release binary compatibility, so from-source binaries (st, dmenu, issy) stop loading after a sysupgrade. Run pkg_add -u first, then re-run provision.sh. Order matters: pkg_add -u reinstalls the stock st/dmenu over the patched builds, and the provision run detects that and rebuilds them.

vmware svga emulation

On Linux, sway launches with WLR_NO_HARDWARE_CURSORS=1 in .bashrc to work around VMware SVGA limitations. Remove this on bare metal.

windows lock command

If running VMWare on a Windows host, disable Win+L via registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DisableLockWorkstation set to 1.

additional references

hatband

David Emerson — Thu, 10 Sep 2026 00:00:00 +0000

Source lives at github.com/davidemerson/hatband. The site is hatband.link.

Hatband is a business card exchange app incapable of, and uninterested in, mining your data. It shows your contact details as a QR code, from the Lock Screen if you like, and remembers where you met the people you scan.

why

Exchanging contact information with someone you’ve just met, and don’t yet trust, is an unsolved problem.

The apps that do it well want your address book, and you hand over everyone you know so that a stranger can have your phone number. The rest assume you are one person with one set of details, and that seems unlikely too. I have a card for the day job, one for the things I build, and one for people I’d rather not have calling the day job.

So Hatband does two things

It collects nothing, and
it lets you carry more than one card.

personas

Your persona is the full set of fields: name, company, phone, email, website, GitHub, LinkedIn, Mastodon, Signal, Calendly, SSH key, GPG fingerprint, and anything custom you want to add.

how a card travels

A card is a QR code. Point a camera at it and you get a link to hatband.link with the card packed into the URL fragment, which a browser never sends to the server. The page decodes it in the browser, verifies the signature, and offers Add to contacts.

what someone without the app sees. This one is a compact card, the Lock Screen kind, which carries a fingerprint of the key rather than a signature.

The same card can go out as a .hatband file, as a bubble in Messages, or printed as SVG, PNG or a PDF card. Someone with the app lands in a review sheet, and those without get the web page.

what leaves the phone

Key lookups against WKD, keys.openpgp.org, GitHub and Mastodon; Safari for a link you tapped; Apple’s map tiles when the Where tab opens.

There is no Hatband server, and no analytics, heck, no third-party code at all: the app links nothing it didn’t write except Apple’s frameworks. Crash reports stay on the phone until you choose to share one. I have no way of knowing you installed it.

Scanned cards live in a Class A store, each sealed under a Keychain key that the app lock puts behind Face ID. They stay out of backups unless you opt in. Your own card is plaintext, so showing it never prompts. Export puts the seed, your card and everyone you’ve met into one file sealed with a passphrase.

the format

A card is a CBOR map with small integer keys, encoded deterministically and signed with Ed25519, about 256 bytes. It travels as https://hatband.link/#1<base32>, or as a file behind the magic bytes HB1\0.

get it

The App Store listing is apps.apple.com/app/id6809843834, live once review is through. iOS only for now.

Six Memos for the Next Milennium

David Emerson — Wed, 02 Sep 2026 00:00:00 +0000

Calvino, Italo. (1988). (rated 5/5) (recommended by Julian P.)

Picnic read, and yet a 5/5. Get a blanket, steal a dog, skip the food because someone in the park will sell you baklava if you wait long enough.

This is the Calvino version of This Craft of Verse (Borges) and it’s a lot of fun. The kind of book which expands your reading list because of its irresistable citations. For having read this, I am obliged now to read Paolo Zellini, Dante Aligheri, Carlo Emilio Gadda, Thomas Mann, Georges Perec, and perhaps Alfred Jarry (if I can find a translation).

There are five essays: Lightness, Quickness, Exactitude, Visibility, Multiplicity. Calvino died with this work in progress.

Multiplicity is my favorite, though I am partial for its references to Joyce and Borges.

Quickness contains a neat exposition of a story about Charlemagne, with different versions featuring different cadences by virtue of elaboration upon or omission of various themes. Calvino pragmatically and convincingly demonstrates how this cadence impacts a story.

Tons of notable passages,

The motor age has forced speed on us as a measurable quantity, the records of which are milestones in the history of the progress of bath men and machines. But mental speed cannot be measured and does not allow comparisons or competitions; nor can it display its results in a historical perspective. Mental speed is valuable for its own sake, for the pleasure it gives to anyone who is sensitive to such a thing, and not for the practical use that can be made of it. A swift piece of reasoning is not necessarily better than a long-pondered one. Far from it. But it communicates something special that is derived simply from its very swiftness.

Quickness, p. 45

On the innovation of art,

…we see how the sluggishness of the human consciousness in emerging from its anthropocentric parochialism can be abolished in an instant by poetic invention.

Lightness, p. 22

On the lapidary work of editing,

On folio 265 of the Codex Atlanticus, Leonardo begins to jot down evidence to prove a theory of the growth of the earth.

After giving examples of buried cities swallowed up by the soil, he goes on to the marine fossils found in the mountains and in particular to certain bones that he supposes must have belonged to an antediluvian sea monster. At this moment his imagination must have been caught by a vision of the immense animal as it was swimming among the waves. At any rate, he turns the page upside down and tries to capture the image of the animal, three times attempting a sentence that will convey all the wonder of that evocation.

“O how many times were you seen among the waves of the great swollen ocean, with your black and bristly back, looming like a mountain, and with grave and stately bearing!”

Then he tries to give more movement to the monster’s progress by introducing the verb volteggiare (to whirl).

“And many times were you seen among the waves of the great swollen ocean, and with stately and grave bearing go swirling in the sea waters. And with your black and bristly back, looming like a mountain, defeating and overwhelming them!”

But the word volteggiare seems to him to have lessened the impression of grandeur and majesty that he wants to evoke. So he chooses the verb solcare (to furrow) and alters the whole construction of the passage, giving it compactness and rhythm with sure literary judgment:

O how many times were you seen among the waves of the great swollen ocean, looming like a mountain, defeating and overwhelming them, and with your black and bristly back furrowing the sea waters, and with stately and grave bearing!

His pursuit of the apparition, which is presented almost as a symbol of the solemn force of nature, gives us an inkling of how Leonardo’s imagination worked. I leave you this image at the very end of my talk so that you may carry it in your memories as long as possible, in all its transparency and its mystery.

Exactitude, p. 79-80

Oh, and Dante has beautiful words.

Come per acqua cupa cosa grave / (Like some heavy thing in deep water)

Paradiso III.123

How to Guarantee a Life of Misery

David Emerson — Wed, 19 Aug 2026 00:00:00 +0000

Munger, Charlie. (1986). (rated 4/5)

Charlie Munger’s commencement address to the Harvard School, Los Angeles, June 13, 1986. Collected later as the first talk in Poor Charlie’s Almanack.

Full text here, via James Clear.

be unreliable

“Do not faithfully do what you have engaged to do. If you will only master this one habit you will more than counterbalance the combined effect of all your virtues, howsoever great. If you like being distrusted and excluded from the best human contribution and company, this prescription is for you. Master this one habit and you can always play the role of the hare in the fable, except that instead of being outrun by one fine turtle you will be outrun by hordes and hordes of mediocre turtles and even by some mediocre turtles on crutches.”

learn only from experience

“You can see the results of not learning from others’ mistakes by simply looking about you. How little originality there is in the common disasters of mankind -drunk driving deaths, reckless driving maimings, incurable venereal diseases, conversion of bright college students into brainwashed zombies as members of destructive cults, business failures through repetition of obvious mistakes made by predecessors, various forms of crowd folly, and so on. I recommend as a memory clue to finding the way to real trouble from heedless, unoriginal error the modern saying: “If at first you don’t succeed, well, so much for hang gliding.”

quit at the first, second, or third reverse

“there is so much adversity out there, even for the lucky and wise, this will guarantee that, in due course, you will be permanently mired in misery. Ignore at all cost the lesson contained in the accurate epitaph written for himself by Epictetus: ‘Here lies Epictetus, a slave, maimed in body, the ultimate in poverty, and favoured by Gods.’ “

minimize objectivity

“minimizing objectivity will help you lessen the compromises and burdens of owning worldly goods, because objectivity does not work only for great physicists and biologists. It also adds power to the work of a plumbing contractor in Bemidji. Therefore, if you interpret being true to yourself as requiring that you retain every notion of your youth you will be safely underway, not only toward maximizing ignorance, but also toward whatever misery can be obtained through unpleasant experiences in business.”

org

David Emerson — Mon, 03 Aug 2026 00:00:00 +0000

overview

There are three components to my system: task management, priority management, and storage. This is where I keep a record of how I run my system, for myself and others who might be interested.

task management

I’ve used Getting Things Done (GTD), this strangely cultish method by David Allen, since about the time it came out in 2001. That’s a long time now, basically since high school. It has become quite a habit for me, and I would highly recommend anyone start this habit sooner rather than later - you’ll get it wrong a number of times and eventually settle on the fixtures and features of the method which resonate with you. For me, the durable bits have been:

Inboxes
Next Actions
Recurring Actions
Dependencies (“waiting for”)
Tags
Ideas
Processing (Review)

Things I have not been able to get sticking in the last 20-something years of doing this:

Strategic work (why am I here, what do I care about, what do I do?). I am terrible at the existential stuff. This is true in life as well as GTD.
Tasks to Calendar (blocking time for minor tasks). I do this well for large tasks and projects, but small stuff snowplows sometimes, and I’m working on it.

If you’re just starting this journey yourself, it’s a great idea to get the original book, and to check out others’ summaries of their processes, like this one and the excellent GTD For Hackers. Keep in mind that when you read any account of such a method, you probably won’t implement things exactly as others have done. I suspect very few people read “Getting Things Done” and simply do all of it - you’ll figure out what 30% of the method works for you, and do that. You might hack the other 70% into something more bespoke for your own life and workflow.

Whatever you do, consistency and refinement is important, progress not perfection.

inboxes

Inboxes are the single most important part of the whole method. An inbox can be anything, but it’s always a dumping ground, functionally. My most-used inboxes are

the physical one on my desk at home (for physical things like papers and small objects)
the physical one on my desk at work
the digital one in my task application (I use Todoist)
a notebook I carry with me in my pack
a notebook I keep on my desk at home / at work

This is occasionally supplemented by any number of ephemeral or contingent inboxes. Maybe you’re traveling and all you have is a napkin. Maybe you’re in some random office you don’t keep stocked with your usual stuff and you grab a piece of paper from the printer and fill it with notes. Whatever.

The important thing is that you build a practice of processing these inboxes. Get stuff out of your head and into these inboxes so that you can stop thinking about that stuff, and do it with the assurance that you have a process by which you will process it into appropriate places later.

processing the inbox

I do this with everything that ends up in an inbox of mine:

Full size PDF version of the above is here.

On a regular basis, and this has a different meaning for you than it does for me, you need to process your inboxes. I process all my inboxes at least weekly. Each item in the inbox should be subjected to the above flowchart, no exceptions.

Processing can take anywhere from a few minutes to an hour or so. If it’s taking more time than an hour, you’re probably doing it wrong, or you’ve got a huge backlog. I go into detail about how I do my processing in the “processing” section below, but suffice it to say that what we’ve covered so far is:

thing(head, object, instruction, artifact) >
 inbox >
 processing workflow >
 next action / idea / recurring action / storage

lists

The lists, functionally, are super important. Their names less so, but I have selected names which remind me of their functions.

next actions

Next Actions is a list of tasks which are ready to be done. This means that they are already decomposed into a single, specific thing which needs to be done and which is unencumbered by other dependencies. If you need a phone number to call someone to make an appointment for something, put it in the action to avoid such a dependency. Friction kills forward motion. As an example:

"Make an appointment with dentist"

is less good than,

"Schedule a regular cleaning with the dentist"

is less good than,

"Call 212-293-3847 and schedule regular cleaning with Joe Dentist"

This might sound silly and pedantic, but trust me, you’ll learn fast that having the information you need at hand to do the thing you need your future self to do will make that thing more likely to get done. I don’t have a universal standard to apply here other than to say that if you think you need a piece of information to accomplish that action in the future, you should put it in the action itself. If that seems daunting or pointless, it’s possible the action is not in fact a Next Action, but needs to be further decomposed into smaller steps which can be accomplished separately or are dependent on serial execution (serial dependency).

Most things on Next Actions need a date on which you’ll do them, or by which you’ll do them, whichever works for you. It’s ok if some things don’t have dates associated with them, so long as you have validated that they are in fact actionable, and you have some plan or cadence on which you’ll pick one of them up and do it, like a block of time for getting these things done.

recurring actions

Recurring Actions are subject to the same criteria as Next Actions, except they occur at regular intervals. You might need to clean out your old public key identities annually, for example, or write your friend for their birthday on the day each year, or do your GTD processing weekly. The point is simple, but subtle: separate your recurring actions list from your Next Actions list to avoid clutter. Even though they’re similar, it’s way too easy to lose important one-time tasks in a sea of recurring ones you’ll inevitably build over time.

Obviously, since recurring actions need a period on which they will recur, everything in here needs a date for completion or it doesn’t make sense for this list.

ideas

Ideas, in my world, are not subject to as stringent a criteria as actions. Some of them could be actions, but are not actionable yet. Some of them are whole projects, or large amounts of effort which will definitely require decomposition in the future before I can act on them. It’s ok, just get them into your Ideas list, and tag them appropriately (more on tags later) and you’ll revisit them when appropriate.

A few examples of things I keep on my Ideas list:

Books people have told me to read (and who recommended them, so I can follow up)
Things I want to make/build in the future
Gift ideas for people, even vague ones which might not be fully developed yet into something makeable / buyable
Places I want to visit, and how I found out about them

This is easily the most diverse category of processed items outside my “reference / storage” category. What distinguishes Ideas from mere storage, however, is the possiblity that they’ll be actionable in the future. If something is truly not going to promote action, ever, then it should be archived off into storage, or deleted.

Nothing in Ideas needs to have a date. Some things might, but it certainly isn’t required. Ideas are part of a review process for potential promotion to Actions, so they are fine to be left undated when appropriate.

dependencies (“waiting for”)

This is a list of things that would be Next Actions, except that you delegated them to others, or need others to do them, and you’re waiting on that to happen. Everything in here needs a date on which you’ll follow up with the entity intended to be doing the action.

You delegate more than you think you do, even if you don’t have a traditional relationship of delegation with someone, as might a person in a corporate org structure. That insurance quote you’re waiting on? The book you must read which gets published on February 11 next year? The dates you’re waiting on from your mother so you can plan a visit to see her? All these things are effectively delegations or dependencies which should be tracked here.

This is the one list I implement as a tag rather than as a place, because dependencies arise in every context and I don’t want four copies of the same list. Anything blocked on someone else gets waiting-for, wherever it already lives. The waiting, undated view exists to catch the failure mode: a dependency with no follow-up date is a dependency you have silently stopped tracking, so that view should always be empty.

implementation

Everything above is method. This is how it’s actually built, in Todoist, as of this writing. I keep this section current because a method you can’t locate in the tool is a method you don’t have.

structure

One project per context. Inside each, the lists are sections, not separate projects:

Personal, dayjob, consulting, Board Service each contain next, recurring, and ideas.
FDCP is a property and keeps sections per trade (procurement, exterior, interior, and so on) plus a recurring section for the maintenance backbone.
Genuinely shared projects stay separate and untouched, because collaboration is one of the two things that earns project status.

Nothing sits unsectioned. An unsectioned task is a task in no list, which is the same as a task in no system.

The rules that keep this from sprawling again, checked quarterly:

Not more than ten top-level projects.
Not more than ten sections per project.
A project must be shared with someone, or must hold information that cannot commingle with anything else. Otherwise it is a tag. This is the same test as before, but written down now, because an untested heuristic drifts.

views

The lists are where things live; the views are how I see across them. Each maps to a step in a review.

Today — today | overdue, everything due across every context.
Next actions — every next section, plus FDCP’s trade sections.
Next: undated — the same, filtered to items with no date. Most next actions should have a date; this is the backlog that quietly stopped being actionable.
Waiting for and Waiting, undated — the dependencies list and its failure mode.
Ideas — every ideas section.
Recurring — every recurring section. Mostly used quarterly to catch rot, since recurring tasks accumulate references to tools you stopped using years ago.
People — @p-*, everything tied to a human.
Weekly review — a single multi-query view rendering inbox, waiting-for, undated next actions, and ideas in one screen. Four steps of the weekly review in one click.

A note on filter syntax, since it took some checking: section names match across all projects, so /next returns every next-actions section at once, and tag prefixes support wildcards, so @p-* works. Those two facts are what make one flat set of views cover an arbitrary number of contexts.

processing

The processing habit is what allows all of this to work. With assured processing, you will rest easy knowing that things you commit to your inboxes, and thence to various lists, will not be lost. If you do not build a processing habit, this whole thing just becomes a pile-up of things you know you should do but which will get lost, along with the whole point of having a system for, uh, getting things done.

If you feel or sense that your processing habit is not well or regularly implemented, you’ll lose faith in your inbox system, which will cause a feedback into your offloading habit. You’ll start trying to remember stuff lest you drop it, and that’ll inevitably cascade into forgetting stuff, and dropping it anyway.

Anyone with any reasonable amount of things they’re responsible for cannot mentally track them all. Get stuff out of your head (the inbox habit) and process it so you are assured of the integrity of your system, and feel good committing important things to its functioning.

daily review

Every day, I do the following, all of which are very basic:

Clean out my email inbox, processing emails according to my inbox workflow.
Review the Next Actions which are scheduled for the day, and defer them or reschedule them if they are not able to be done.
Check off the things I’ve done, to keep status updated.
If I took notes or created especially nonstandard inboxes (random slips of paper, artifacts in my bag, pockets, etc), get those processed according to my inbox workflow.

weekly review

Weekly review is more complicated, and takes about an hour for me, normally at the end of a Friday as I’m closing out my week:

Clear off my desk, process anything that should be an inbox item.
Empty my todoist inbox, in case anything fell through the cracks (“Inbox” is the default project Todoist commits something to when it has no other direction, so sometimes things end up in there by default or mistake.)
Review all Next Actions (Next actions) to ensure things are completed which were completed, and to reschedule, reshuffle, or elaborate on other tasks in there before next week starts. Then check Next: undated and either give those items a date or admit they belong in Ideas.
Review Delegations (Waiting for) to be sure nothing is falling through the cracks, particularly to be sure everything has a date on which you will follow up about that thing. Waiting, undated should be empty.
Review Projects under way. Where you have projects in lists or systems outside your main actions/delegations/recurring/ideas, make sure to prune, elaborate, and update those weekly. Often for me, these are in a project management system, but they also might be projects broken out from the main lists because of the clutter they would otherwise produce.
Review current-week calendar: use it as a prompt for tasks, projects, or things you didn’t commit to your system in the moment, but should.
Review next-week calendar: use it as a prompt for tasks, projects, or things you need to commit to your system before next week occurs. Also reorder and deconflict next week while you’re at it, since you’re probably quadruple booked for something.
Update any status dashboards, particularly the ones you owe folks you work with. This might not be relevant to you, but it’s a good time to do it if you must.
Review your Ideas list. Promote things to Actions where appropriate, or elaborate on things which have new details.

quarterly review

Quarterly, I only do a few things, but they are more time consuming when they need to be done:

Rethink any Projects which should be demoted to tags, or tags which should be promoted to projects. Apply the test rather than the vibe: shared, or cannot commingle, or it’s a tag. Check the counts against the caps while you’re in there.
Work the Recurring view end to end. Recurring tasks rot in a way one-time tasks don’t, because nothing forces you to reread them. Look for references to tools you no longer use, recurrence strings that have accreted junk over the years, and tasks whose whole premise has expired.
Clean up old stuff to storage where it’s no longer needed.
Make sure any integrations between systems (such as calendar integrations with your task management app, availability integrations with the links you send out for scheduling, or any agent connectors with access to your mail and tasks) are working and properly configured. For anything holding an OAuth grant, confirm the scope is still the minimum you need and revoke what isn’t.

annual review

I’m terrible at this, but I do make a stab at doing the stuff I consider “existential”. What do you do? What do you want to be doing? What even are you? Honestly, it usually devolves into an extra-big rethink of my org structure annually, and I can’t claim to have had any profound insight into my being, but maybe you’ll have more luck. The GTD Methodology formally treats this with more detail and weight if you’re interested in trying yourself, it’s called “Focus Horizons” there.

For my part, I spend about half a day per year just carefully thinking through my system and updating stuff like this page with how I’ll modify it or what I need to do better. My system is too tactical to get wrapped up in the big stuff.

priority management

This one isn’t complicated, but it’s a handy tool when deconflicting the stuff you think you need to do (the whole body of your tasks) with the reality of time, and how much you can accomplish. Some people like to use OODA loops (I don’t), some people like to use matrices (I do). What you use isn’t important, just make sure you have a good way to apply some criteria with which you’re familiar to the tasks you’ll soon have in excrutiating detail from the above processes.

Here I’ve outlined the two systems I personally use. They are both 2x2 matrices, don’t be too confused, there’s nothing to this. Heck, you don’t even need to actually fill out the matrix with tasks, unless that’s your jam. I personally just use these frameworks as ways to think about any given task I’m presented.

Impact-Effort Matrix

There are four boxes in this 2x2 matrix, high/low impact, and high/low effort. I rank things to be done according to this criteria:

(do first) High Impact, Low Effort: Quick Wins. These are the tasks or projects that you should tackle first. They offer the highest return on investment for your effort.
(do second) High Impact, High Effort: Major Projects. These items are important but require significant time and resources. Plan and execute them after the quick wins.
(do third) Low Impact, Low Effort: Fill-ins. These can be done when you have spare time. They won’t make a big difference but are easy to complete.
(do last, defer) Low Impact, High Effort: Thankless Tasks. These tasks require a lot of effort but don’t provide much return. Avoid or minimise these tasks whenever possible.

Eisenhower Matrix

Similar to the Impact-Effort Matrix, this is a 2x2, but ranking importance (instead of impact) and urgency (instead of effort). It also includes delegation and deletion concepts, which can be helpful if what you need is a filter more than an order of operation.

(do soon) Important and urgent: do it. These are the tasks that you want to do as soon as possible. Crises, pressing problems and other things where not acting now has negative consequences.
(schedule) Important but not urgent: schedule it. Find a time for these tasks and do them then. This quadrant is typically where deep work happens – tasks that contribute to your projects or long-term goals.
(delegate) Urgent but not important: delegate it. If you can, find someone who can do these tasks for you. If you can’t delegate it, schedule it but always try to do the important-but-not-urgent tasks first. These are often administrative tasks or things that have deadlines but aren’t critical.
(delete) Not urgent and not important: don’t do it. These tasks aren’t worth your time and you shouldn’t do them at all. Avoidance activities, busy work and entertainment goes into this quadrant.

storage & reference

This is where the output of tasks goes, where documents I generate, code I produce, photos I store, and reference materials I want to keep hang out. Nothing in here is necessarily actionable, that’s why it’s reference or for storage.

The biggest challenge for me has been to find a method which is extensible to an almost arbitrary scope while remaining accessible to my recollection of where things should be. I have implemented a system inspired by Johnny Decimal

Rules:

not more than three levels deep for folders
not more than ten subcategories per second or third level taxonomy
where used, dates are in YYYY-MM-DD format. This is very important for sorting and filtering
rules were meant to be broken sometimes, as when photos are simply better stored by date, and when reading is better stored by the Dewey Decimal Categories.

Like the Library of Babel, this results in a taxonomy which is very large, but not infinite, so you can at least orient yourself a bit.

I keep a PDF reference of my folder structure here, both for my own records and for anyone who would like to use it to make their own folder structure.

top level

I have a full-time job, a side-gig or two, and, naturally, a personal life. As such, I’ve implemented projects as the first layer of my taxonomy.

000 - [Reserved for Management]
100 - Emerson
200 - Extended Family
500 - Consulting, Company Management
501 to 899 - Consulting, per-customer
900 - [Reserved]
901 to 999 - Full-time Employment & Board Work

second level

Areas are the second layer of my taxonomy. There are never more than ten areas per project. Under 100 Emerson each area starts with 100 and possesses a decimal identifier, such as 10 for Personal Administration. The combined title for personal administration, when is 110 Personal Administration. Here’s what I have under 100 Emerson

110 Personal Administration
120 Home, Auto, Staff
130 Reading
140 Technology
150 Multimedia
160 Projects, Travel, Hobbies
170 Archives
180 Offspring

third level

Categories are the third layer of my taxonomy. There are never more than ten categories per area. As an example, within 110 Personal Administration I have the following categories:

111 Tax Returns
112 Trust & Will
113 Insurance
114 Identification & Representation
115 Personal Plans
116 Personal Investments
117 Templates & Design Assets
118 Health Information

reading

I use the standard Dewey Decimal high level categories for digital reading material which I store. Note that this is different than my reading list, for which I have a web app hosted here.

132.01 Computer Science, Information, General Works
132.02 Philosophy & Psychology
132.03 Social Sciences
132.04 Language
132.05 Pure Science
132.06 Technology
132.07 Arts & Recreation & Travel
132.08 Literature
132.09 History & Geography
132.10 Leadership and Business

Projects

Within 160 Projects, I give each project a random unique three-digit alphanumeric suffix. This allows me to have a large space of potential project names. As an example:

160.a15 org
160.p4j chainsaw logmilling
160.w6b welding cart

photos & music

Photos & Music (generally referred to as media) are somewhat exempt from decimalization, since I’ve found no better way to store them than by-date. Dates are always in YYYY-MM-DD format.

uncertainty

David Emerson — Mon, 27 Jul 2026 00:00:00 +0000

overview

I added a measurement uncertainty engine to C47 on my DM42n. Enter the variables of a formula along with their standard uncertainties, and the calculator returns the result together with the uncertainty of that result, plus a budget showing which input is responsible for the error.

This is compliant with ISO/IEC Guide 98-3, the standard for stating measurement uncertainty. This is something you’d normally need a spreadsheet for, and rarely find in a basic calculator.

I got my inspiration here from DB48X, another firmware for the same hardware, which has an uncertain number type that propagates a standard deviation through operations. It lacks the rest of the ISO/IEC 98-3 stuff like sensitivity coefficients, a ranked budget, an expanded uncertainty with its coverage factor, effective degrees of freedom.

Oh, and I tried to make this run on the DM42 also, which is a capacity feat.

space

The DM42 has 704 KB of internal flash for the program. The firmware ships in numbered packages, which are different subsets of the features chosen to fit:

package	flash used	free	engine
1	721,808 / 720,896	over by 912	out
2	720,680 / 720,896	216	out
3	719,528 / 720,896	1,368	out
4	699,040 / 720,896	21,856	in

Package 1 does not fit, and did not before I touched it: upstream is 784 bytes over on that package today. So three of the four have no room and the feature is compiled out of them.

The source keeps a calibrated table of what each option costs. Mine is 6,448 bytes of flash, measured by building package 4 twice with the option on and off.

step

The C47 uses a fifteen point stencil, exact for polynomials to degree fourteen, and then takes its step as h = x × 10⁻¹⁶. A central difference trades truncation error against rounding error and the balance sits near ε^(1/(p+1)); function values come back at 34 digits, so the optimum for that stencil is around 10⁻², not 10⁻¹⁶. At 10⁻¹⁶ the result is rounding noise and all fourteen orders are thrown away.

The firmware’s own checked-in test expectation for the first derivative of x³ at 5, which is 75:

74.99999999999999999893939393939394

20 digits out of 34. The second derivative gets 7.5, since dividing by h² amplifies the same noise.

So I did not reuse it. A two point central difference at h = max(|x|,1) × 10⁻¹¹ measures 22.6 digits using two evaluations instead of fifteen. Nearly three decades better for an eighth of the work. The sophistication was in the wrong place since the step decides whether the stencil matters at all.

Reading it also turned up four defects, the worst being that f’ and f“ returned a silently wrong answer for any program taking its input as a named variable. Fixed upstream now.

use

The UNCT menu structure looks as follows:


U.EDIT	the input table, one row per variable: u(x) and degrees of freedom
U.CORR	correlations, if the inputs are not independent
U.P	level of confidence, 95 or 0.95, both work
U.CALC	y in Y, u_c(y) in X
U.EXP	k in Y, U in X
U.BUDG	the ranked budget
U.Y	which variable is the measurand, for a formula written with =

A run is short. Pick the formula with EQN, then:

U.EDIT      fill in u for each variable
99 U.P      99 % confidence
U.CALC      50.000838 mm, u_c = 32 nm
U.BUDG      lS 25 nm, dtheta 16.68, d 9.7, dalpha 2.9

U.EDIT. One row per variable, u(x) in the first column and degrees of freedom in the second. Four of the six rows fit on screen.

U.CALC on the GUM’s end-gauge example. 50.000838 mm in Y, 3.171×10⁻⁵ mm in X, which is 31.71 nm.

U.EXP at 99 %. k = 2.9208, U = 9.262×10⁻⁵ mm, the GUM’s 93 nm.

The budget. Six inputs ranked by what they contribute, LS at 62.2 % down to alphaS at nothing.

The combined number tells you how wrong you are; the budget tells you which measurement to go improve. Here it is LS, the calibration of the reference gauge, and no amount of care with the thermometer would help.

tests

The GUM contains its own worked examples in Annex H, with published answers. That is an unusually good acceptance test, because it was written by the people who defined the method.

The engine reproduces H.1, the calibration of an end gauge, giving 50.000838 mm with a combined uncertainty of 32 nm. It reproduces H.2, simultaneous resistance and reactance, which is the correlated example and exercises the covariance terms. It reproduces H.3, a thermometer calibration, both with and without the correlation between the fitted intercept and slope.

The GUM notes that including second order terms raises H.1’s uncertainty from 32 nm to 34 nm. This engine is first order by construction, so 32 nm is its correct answer, and getting 34 would mean the sensitivities were wrong. Encoding the number the approximation should produce, rather than the most precise number in the document, is the difference between a test that checks the method and a test that checks nothing.

cost


flash	6,448 bytes
static memory	40 bytes
arena, on first use	about 2.2 KB
evaluations per budget	2 per variable, plus one, except an `=` equation which is 2 per variable

He Was a Crook

David Emerson — Mon, 27 Jul 2026 00:00:00 +0000

Thompson, Hunter S. (1994). (rated 4/5)

Thompson’s obituary for Richard Nixon, published in Rolling Stone on June 16, 1994.

Full text here, via archive.is.

Thompson simply declined to participate in the elder statesman obituary. The thesis is in the title and he spends the rest of it refusing to soften.

It’s not “The Kentucky Derby is Decadent and Depraved,” there’s less invention here and less of the gonzo apparatus; the contempt does most of the work, and it’s contempt with thirty years of receipts in tow.

A 4 rather than a 5 because sustained hatred is a narrow instrument, and there are stretches where the venom is running ahead of the writing.

The Middle Passage: From Misery to Meaning in Midlife

David Emerson — Mon, 27 Jul 2026 00:00:00 +0000

Hollis, James. (1993). (rated 4/5)

Extremely compact. It’s a bit over a hundred pages and there’s nothing padding it out, no anecdote stretched to fill a chapter, no idea restated three times for the benefit of an imagined skimmer. Hollis says the thing and moves on. I wish more books in this territory were built this way, and the parsimony is a good part of why this one is useful.

It’s Jungian, and if that’s going to bother you it will bother you early. It didn’t bother me.

Not every reader is going to relate to every element of the middle passage Hollis illuminates. Some of what he describes is plainly someone else’s life and not mine. That seems like the right expectation to bring to a book of this kind rather than a flaw in it. What’s here is practical, and there’s an element of being seen in it, at least in part, which is most of what I’d ask for.

The Miracle of Mindfulness: An Introduction to the Practice of Meditation

David Emerson — Mon, 27 Jul 2026 00:00:00 +0000

Nhat Hanh, Thich. (1975). (rated 3/5)

A light book and a good overview of introductory practice. Nothing in it is difficult to pick up, which I take to be the point.

If I’m meditating, I think I’m more of a minimalist, along the lines of TM. The practices here are more active, more involved, and more engaged with the world, in that they’re trying to cultivate awareness in the middle of ordinary activity rather than apart from it. There are times in my day when I could use something like that. I still prefer the simplicity of a mantra and a moment outside the bustle.

Montessori: The Science Behind the Genius (queued)

David Emerson — Mon, 27 Jul 2026 00:00:00 +0000

Lillard, Angeline Stoll. (2017). (rated NR/5) (recommended by Julian P.)

Nonviolent Communication

David Emerson — Mon, 27 Jul 2026 00:00:00 +0000

Rosenberg, Marshall. (2015). (rated 3/5) (recommended by Julian P.)

Helpful and practical, particularly for deescalation and for discussions which have already gone contentious. It gives you something to do when a conversation is heating up, which is more than most books of this kind manage.

It is also clearly awkward and stilted for everyday use. I don’t think that makes it useless every day, but it does mean you can’t expect to speak this way and convey a direct message at the same time. Sometimes the direct message is the thing that’s needed, and this is not the technique for that.

The anecdotes are sometimes hilarious, mostly in a stilted, awkward way. The examples read like transcripts from a place where nobody is ever in a hurry and everyone has agreed in advance to be patient. Strange, but useful nonetheless, and I remember the odd ones better than I’d remember reasonable ones.

The Odyssey (Wilson translation)

David Emerson — Mon, 27 Jul 2026 00:00:00 +0000

Homer. (2017). (rated 3/5)

I read this because I hadn’t read this translation yet, and because I was going to see the Nolan movie.

Fitzgerald is the translation I read before, both for the purpose of reading the work itself and for the purpose of reading Ulysses, where the correspondences aren’t literal but are buried well enough to be independent of translation anyway.

Wilson is less beautiful than Fitzgerald. There’s no doubt in that for me. It is also far more readable: vernacular, less flowery, less interested in being grand. Frankly, the average student who’s being made to read Homer should be handed the Wilson, since it makes the story accessible without, to my memory, messing with anything important.

If you’re the kind who has to read it again, or wants to, Fitzgerald is worth a try as well. The language is beautiful and you’ll already know the plot.

This Is How You Lose the Time War (queued)

David Emerson — Thu, 04 Jun 2026 00:00:00 +0000

El-Mohtar, Amal. (2019). (rated NR/5) (recommended by Dustin D.)

slab bench

David Emerson — Mon, 25 May 2026 00:00:00 +0000

overview

I’m making a bench from one of the white oak slabs I chainsaw-milled and later kiln-dried. The slab finishing, base design, and fabrication are captured here.

Note that my work environment is primitive, so don’t judge my finishing techniques too harshly. I basically picked a good string of days and set up a couple sawhorses in the carport. It’s not a clean room.

slab dimensions

dimension	value
thickness	48 mm
length	1720 mm
width	388 mm
total finished surface (both faces + all edges)	~17 ft² (~1.55 m²)

finishing

The plan was Rubio Monocoat Oil Plus 2C in Dark Oak. I switched to Real Milk Paint Dark Half because Rubio is fussy about temperature and humidity during application and the 5-day cure, and my carport is fussy about nothing. Unsatisfied with the tung oil finish, I sanded everything off and pivoted again.

sanding

Random-orbital sander with hook-and-loop discs. Through 150 grit on both faces, both end grains, and all four edges.

80 grit to knock down planer marks and any cup, until it read flat against a straightedge.
100 grit to remove the 80-grit scratch pattern.
120 grit to refine.
150 grit.

Between grits, I vacuumed the slab and the floor and wiped with a dry rag. I checked each step under a raking light at the edge of the slab and re-sanded any swirls or remaining mill marks before stepping up.

first coat (flood)

Vacuumed sanding dust off everything. Wiped with a clean dry rag.
Flooded the surface with Dark Half from the can, using a foam brush. Generous, kept it wet without puddling. End grain pulled it in fast and got more.
Waited 40 minutes.
Wiped the excess off with a clean cotton rag in firm passes, until the surface read uniformly oiled but not wet.
Let it sit four hours.

the mistake

I sanded the slab to 220 grit between the first coat and the next, and kept sanding between the coats after that. This is wrong. Real Milk Paint says so directly - don’t sand between coats of tung oil. Partially-cured oil doesn’t abrade like a film finish. It gums up, smears across the surface, loads the disc, and turns into a hazy slurry of oil and sawdust that obscures the grain underneath.

I kept going anyway. Second coat with 220 grit beforehand, then 400, then 600. By the end the slab looked like it had been wiped with mud. Pigment streaks, no grain definition, a soft uneven film instead of the deep clear figure I’d built up.

the recovery

Citrus solvent dissolves uncured and partly-cured tung oil. It’s also the thinner inside Dark Half itself, so I knew it was compatible with whatever was on the slab. I doused the surface with straight citrus solvent (d-limonene degreaser) and worked it with cotton rags until the goop lifted off. It took a lot of rubbing, and I had to keep at it before the surface layers fully cured - once tung oil is hard, citrus solvent doesn’t lift it cleanly anymore.

The deep tung oil from the first coat survived. It had penetrated into the grain and cured down there well before the surface mess started up top. End state: the slab is back to bare-feeling wood, sanded to 150 grit, with Dark Half permanently saturating the fibers below. The grain reads clean, the pigment that absorbed into the open pores is still in place, and the slab is darker than raw white oak with no streaky topcoat.

rebuilding the finish

I rebuilt the finish properly. Real Milk Paint’s directions for their thinned tung oil products call for 3 to 5 thin wipe-on coats for everyday-use furniture, no abrasion between coats. The wood was already saturated below the surface from the original first coat, so the later coats absorbed less and built surface sheen more than they would have on raw wood.

After the strip, I let the slab sit overnight in the carport so any residual citrus solvent could flash off. I did not sand again before recoating. The strip left the surface in a good state, and the pigment that absorbed into the open pores of the wood was sitting just below the surface - sanding at that point would have scrubbed off some of that pigment and lightened the slab unevenly. Raised grain from the solvent wipe-down laid back down under the next coat’s penetrate-and-wipe pass on its own.

Then, for each coat:

Apply Dark Half thin with a lint-free cotton rag (an old undershirt works), not a foam brush. Just enough to wet the surface evenly, no flood.
Let it soak 15 to 30 minutes.
Wipe all excess off with a clean dry cotton rag. The surface should feel dry to the touch when you’re done, not tacky.
Wait 24 hours before the next coat. Real Milk Paint allows as little as 2 to 3 hours between coats of their solvent-thinned blends, but overnight is safer and there’s no rush.
Repeat until you’ve built three more coats on top of the existing first-coat penetration.

No sanding between coats. Not orbital, not by hand, not steel wool. If a coat dries with a nib or a speck, dampen a rag with a little Dark Half on the next pass and the irregularity dissolves back into the new coat.

After the final coat the slab cured for 30 days. Tung oil is touchable in a day or two but doesn’t reach full hardness for about a month. Once it was cured I put a paste wax topcoat over it - Real Milk Paint’s Soft Wax is the matched pairing, and any beeswax-and-carnauba furniture wax (Liberon Black Bison, Briwax) does the same job. Wax on cured tung oil gives a smooth hand-feel, adds abrasion protection for a surface that gets sat on, and brings the satin sheen up a touch without going glossy. It’s sacrificial and needs a refresh every couple of years.

oily rag disposal

Tung oil rags will spontaneously combust. They cure by oxidation, oxidation produces heat, heat speeds the oxidation, you get a runaway in a few hours and a fire in the rag pile.

Everyone seems to have various disposal methods involving the trash, but this seems cumbersome, and I put them in the fire pit and burn them.

base

The base is two rectangular end frames joined by a single spine that runs the length of the bench along the underside of the slab, all of it built from rectangular tube steel, 1.5“ x 0.75“, 0.125“ wall, and finished black.

I designed this as splayed trapezoidal ends with a low stretcher down at the floor, and built it square instead. Vertical legs, and the connecting member moved up under the slab where it also does the work of carrying the fasteners. The wider footprint of a splay buys side-to-side stability that a bench this heavy doesn’t especially need, and the low stretcher was one more thing to catch a foot on.

The slab is 1720 mm long and the bench seats two adults comfortably. Finished height is 18“ (457 mm) at the top of the slab, which is on the tall side for a bench and right for slipping up to a 30“ table. Slab is 48 mm thick, so the steel frame stands 409 mm.

design

dimension	value
tube section	1.5" x 0.75", 0.125" wall
finished bench height (top of slab to floor)	457 mm (18")
steel frame height	409 mm
end frame width	280 mm
end frame inset from each slab end	250 mm
spine length (between end frames)	1220 mm
slab overhang past each end frame (lateral)	54 mm per side
leveling feet	M8 threaded inserts, 4 corners total

Each end frame is a plain rectangle: two vertical legs, a top tube against the underside of the slab, and a bottom tube on the floor carrying the leveling feet. No splay and no cross-bracing. Side-to-side, the mass of the slab and the width of the frames handle it. Long-axis stability comes from the slab plus the spine.

The spine runs from one end frame to the other, welded to the middle of each top tube and sitting tight against the underside of the slab. Because it’s up at slab level rather than down at the floor, there’s nothing between the legs for feet to find when someone slides up to the bench.

Fasteners pass up through the spine and through each end frame’s top tube into the slab, so the load is spread along the centerline instead of hanging off four corner points. White oak across a 388 mm wide slab can move 3 to 5 mm with the season, so the fastening has to let the slab breathe across its width rather than pinning it rigid in both axes - bolt a slab down hard in both directions and it cracks, or it tears the fasteners out.

I’m using steel knife-thread inserts (the kind with aggressive external wood threads and an internal hex drive), not brass press-ins. Brass strips out of oak under load. The inserts seat flush in the underside of the slab and are reversible: I can lift the base off any time.

cuts and welds

Cuts are all done on a chop saw with a metal-cutting blade. Everything is square-cut, which is the advantage of dropping the splay: no angle setup, and every joint is flat against flat.

Top and bottom tubes: 280 mm long, ends cut square, two of each.
Legs: cut to stand the frame at 409 mm overall, square at both ends.
Spine: 1220 mm, ends cut square, welded to the middle of each top tube.

I tack-welded both frames on a flat surface (the concrete slab of the carport works, with the tubes shimmed level). Once everything was square I ran full welds at each joint. MIG is what I have - the welds are heavier than TIG but they grind out fine. After welding I checked the frames were still flat and not pulled by the heat, then tacked the spine between them and welded that out.

Threaded inserts for the leveling feet: drill 9 mm holes in the underside of the bottom tubes at each corner, weld M8 nuts inside, then thread in M8 leveling feet with plastic bases. The plastic keeps the steel off the floor and lets me dial out any rocking.

finishing the steel

The plan was bright steel kept bright: scotch-brite to a uniform satin, then clear oil-based polyurethane over it. I went black instead.

Bright bare steel wants to be the thing you look at, and the slab is the thing worth looking at here. A dark frame gets out of the way and lets the top read as the object, which is also why the base is deliberately plain. The other half of it is upkeep. Clear coat over bright mild steel is a maintenance finish in a humid climate: any break in the film, any fingerprint left under it, and rust blooms where you can see it through the clear.

Grind all welds flush with a flap disc.
Strip mill scale from every surface. 60-grit flap disc to start, then 120.
Wipe every surface down with acetone on a lint-free rag. Same drill as the slab dust-removal step, and gloves stay on from here.
Coat it black, thin coats rather than one heavy one.

Raw mild steel flash-rusts fast in humid air, especially in a carport, so the degrease and the first coat still want to happen in the same session, within an hour or two rather than the next morning. Bare hands are the other thing to watch: fingerprints leave salts and oils that come back through a finish weeks later.

assembly

The frame and the slab were joined once both finishes had cured.

Flip the slab upside down on a moving blanket.
Set the frame on the underside, positioned with 250 mm of slab overhang at each end and centered side-to-side.
Mark the fastener locations through the steel, then lift the frame back off.
Drill pilot holes at each mark, depth set with a tape flag on the bit so nothing punches through the 48 mm slab.
Set the frame back in position and run the fasteners up through the spine and the end frames into the slab, by hand first.
Snug everything down. Not gorilla-tight - the slab needs to be able to move across its width with the season.
Flip the bench upright and level it with the M8 feet on whatever floor it lands on.

It comes apart the same way it went together, so moving it is a matter of backing out the fasteners and carrying two pieces instead of one heavy awkward one.

finished

Portraits: John Berger on Artists (reading)

David Emerson — Tue, 19 May 2026 00:00:00 +0000

Berger, John. (2015). (rated NR/5) (recommended by Julian P.)

Fantastic book. I am not done with this yet, but I think I know what score it’s getting. I’m not sure whether or not this is a definitive text about art, but it is a worthwhile read about the human condition. In fact, Berger’s occasional bypass of the subject at hand might be the most charming characteristic of the book, for in parallax we see the art as more than an object.

In other words, you don’t have to care about any of these artists or works to enjoy this book, and if you do care about them, all the better.

Introduction to Civil War

David Emerson — Sun, 17 May 2026 00:00:00 +0000

Tiqqun. (2010). (rated 3/5) (recommended by Julian P.)

Lots of pretty words, lots of cool ideas, and I’m not sure where any of this leads us. A worthwhile, pleasant read on a lazy Sunday though. I would love to debate this with someone who has more investment in making the people indigestible to Empire.

Naturally, I could not help but love the characterization of Bloom.

The Transmission of Affect

David Emerson — Sun, 17 May 2026 00:00:00 +0000

Brennan, Teresa. (2004). (rated 4/5) (recommended by Harper Z.)

The book is interdisciplinary, for sure: psychoanalysis, endocrinology, theology, classical philosophy, social theory. The argument is large, the material in the last couple chapters is sketchier than the first several. Historical claims about premodern openness are more asserted than demonstrated, but the central provocation (affects are not your private property) is pretty cool, strange, and easily understood experientially.

Conversations with Adam and Natasha (queued)

David Emerson — Mon, 13 Apr 2026 00:00:00 +0000

Laing, R.D.. (1977). (rated NR/5)

Fleabag: The Scriptures (queued)

David Emerson — Mon, 13 Apr 2026 00:00:00 +0000

Waller-Bridge, Phoebe. (2019). (rated NR/5) (recommended by Julian P.)

McSweeney's #81 (queued)

David Emerson — Mon, 13 Apr 2026 00:00:00 +0000

Various. (2026). (rated NR/5)

The Economy of Cities (queued)

David Emerson — Mon, 13 Apr 2026 00:00:00 +0000

Jacobs, Jane. (1969). (rated NR/5)

nnix.com

David Emerson — Tue, 07 Apr 2026 00:00:00 +0000

overview

I migrated from Gemini in September 2024, and not everything came along for the ride, so this is a bit of a reset. I like Gemini a lot, but maintaining a content bridge to the web was a pain, and the audience with native Gemini clients is tiny, so interoperability with others is poor.

The web isn’t such a bad place if you have discretion.

This site is a collection of plaintext markdown files stored in git (I use GitHub for this at writing). When I push a change to the main branch of the repository hosting these files, a GitHub action kicks off and compiles the markdown files into html using Zola, a static site generator. There’s also a separate action that validates the build on pull requests, so I can catch breakage before it hits production.

You don’t need wordpress for a few pages. Heck, you don’t need wordpress for even a hundred pages. I’m not saying it’s a bad idea, just that it’s convoluted to design, maybe more expensive, and definitely harder to administer than this kind of setup, which can be run in an S3 bucket from a github repository.

The entire site, without graphics, is under 80 kb. I will not permit it to exceed 128 kb, but this is a personal constraint. It’s not Gemini-small, but it’s in the spirit of one of my favorite sites on the web.

If you want something similar, follow this doc. I’m sure I will too when I want to remember what I did with this thing years from now.

assumptions

You have a domain, foo.com or the like (idk $10/year?)
You have an AWS Account (free)
You have a GitHub Account (free)
You know some stuff about DNS and can poke your way around the AWS Console.

AWS S3

You have an S3 bucket, foo.com, in us-east-1. It has ARN arn:aws:s3:::foo.com and static website hosting is turned on. The static website origin is at:

http://foo.com.s3-website-us-east-1.amazonaws.com/

I have a bucket policy which defaults to public access:

{
  "Id": "Policy1726679145347",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1726679140826",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::foo.com/*",
      "Principal": "*"
    }
  ]
}

Remember to change the “Resource” line to your actual ARN, which is probably not truly foo.com.

AWS CloudFront

There’s a cloudfront distribution at:

https://d3mip7fsd83s7mvq5.cloudfront.

with ARN:

arn:aws:cloudfront::8986388484237:distribution/E4DE38M2FUA4N

It points to the foo.com bucket origin above and has a foo.com CNAME attached to it with a custom certificate.

foo.com Certificate

CloudFront needs a cert, so we have AWS ACM issue one for foo.com. ECDSA P-256 certs now work with CloudFront, but RSA 2048 is still the safe default if you don’t want to think about it.

foo.com A record

We use the A record alias feature in Route53 to point to the CloudFront distribution for foo.com. This only works once the custom CNAME and certificate are in place, of course.

AWS Bucket Policy Setup

We created a new policy by logging on to AWS Console and going to IAM > Policies > Create policy. Switch from the visual editor to JSON and paste the following snippet. Remember to update your bucket ARN names under “Resource”:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AccessToWebsiteBuckets",
      "Effect": "Allow",
      "Action": [
        "s3:PutBucketWebsite",
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:GetObject",
        "s3:ListBucket",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::foo.com",
        "arn:aws:s3:::foo.com/*"
      ]
    },
    {
      "Sid": "AccessToCloudfront",
      "Effect": "Allow",
      "Action": [
        "cloudfront:GetInvalidation",
        "cloudfront:CreateInvalidation"
      ],
      "Resource": "*"
    }
  ]
}

Once the policy is created you need to create a new user under IAM > Users. Give it a name such as foo-com-github-user. On the “Set Permissions” step select “Attach Policies Directly” and find the policy we created in the last step.

From the list of users click on your newly created account and then open the Security Credentials tab. Under Access keys select > Create access key and choose Command Line Interface (CLI). Click “I understand the above recommendation” and then Create access key. Note the Access Key ID and Secret Access Key.

GitHub Setup

Next we need to create the Github Actions workflows. We need workflow files in the .github/workflows directory of our repository. This can be done by navigating to the Actions tab in GitHub or by committing the files from your machine.

First, store your AWS credentials and CloudFront distribution ID as GitHub secrets. Go to your repo’s Settings > Secrets and variables > Actions, and add:

AWS_ACCESS_KEY_ID — the access key you recorded earlier
AWS_SECRET_ACCESS_KEY — the corresponding secret key
CLOUDFRONT_DISTRIBUTION_ID — the ID of your CloudFront distribution (e.g. E4DE38M2FUA4N)

deploy workflow

.github/workflows/publish.yaml handles building and deploying on push to main:

name: Build and Publish to AWS

on:
  push:
    branches:
      - main
  workflow_dispatch:

permissions:
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    timeout-minutes: 10

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - name: Install Zola
        uses: taiki-e/install-action@v2
        with:
          tool: zola@0.22.1

      - name: Build Zola Site
        run: zola build

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Sync to S3
        run: |
          # HTML/XML/JSON: short cache, revalidate often
          aws s3 sync public/ s3://foo.com \
            --delete \
            --cache-control "max-age=300, must-revalidate" \
            --exclude "*" \
            --include "*.html" \
            --include "*.xml" \
            --include "*.json"

          # Static assets: long cache, immutable
          aws s3 sync public/ s3://foo.com \
            --cache-control "max-age=31536000, immutable" \
            --exclude "*.html" \
            --exclude "*.xml" \
            --exclude "*.json"

      - name: Invalidate CloudFront cache
        run: |
          aws cloudfront create-invalidation \
            --distribution-id ${{ secrets.CLOUDFRONT_DISTRIBUTION_ID }} \
            --paths "/*"

The S3 sync uses two passes with different cache-control headers. HTML and other frequently-changing files get a short 5-minute cache with must-revalidate, while static assets (images, CSS, fonts, JS) get a one-year immutable cache. CloudFront invalidation ensures the CDN picks up new content immediately after deploy.

The workflow_dispatch trigger lets you kick off a deploy manually from the GitHub Actions tab, which is handy when you need to redeploy without a code change.

PR build check

.github/workflows/pr-check.yaml validates the site builds on pull requests:

name: PR Build Check

on:
  pull_request:
    branches:
      - main

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 10

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - name: Install Zola
        uses: taiki-e/install-action@v2
        with:
          tool: zola@0.22.1

      - name: Build Zola Site
        run: zola build

This is just a build check — no deploy. It catches broken templates or bad markdown before you merge to main.

Zola init

Clone your GitHub repo to a machine on which you can install Zola. This is easiest on a MacOS or Linux machine, but you can do it in Windows too.

Follow the Zola install instructions and then navigate to the cloned repo directory on your local machine and execute:

zola init

… in the root directory of the repo. That gets a basic site framework which the “zola build” command in the above github workflow can work upon.

Commit/push the changes to your repo back up to GitHub, and you should see the action execute in GitHub, hopefully with success - check out https://github.com/youruser/foo.com/actions page for status.

If the action is not successful, just read the logs and see what went wrong.

adding a template and other basics

I host the template I use on github.com. It’s a basic one, but a good place to start so you know how things fit together when working.

favicon

You need a favicon. I don’t get in to the whole static size thing because I’m not fancy enough to care about old browsers, so I recommend simply uploading an svg version of your favicon to /static/favicon.svg which transforms to /favicon.svg when the site is compiled. You’ll need to specify this favicon file in your /templates/head.html.

og:image

If you want your site to render an og:image when it gets posted to the various social sites, you need to upload an og:image of the correct size (1200x630 pixels) and refer to it in /templates/head.html. I put mine at /static/nnix.png which transforms to /nnix.png at compile time, and I refer to it in /templates/head.html which places it on the head for all my various pages.

icons

There are innumerable icons you can add for various purposes, such as mobile device icons and preview pages. Don’t overthink this, your website doesn’t need very many of these unless you’re hosting a webapp, which we aren’t. Check out the ones I have in /static/ and steal from there as you see fit. Examples include:

Android 192x192 icon
Apple Touch icon
MS Tile 150x150 icon
Safari Pinned Tab icon

bimi

There’s a BIMI icon in my template for this site, but that’s an email thing. It makes your emails look branded from you. It’s really not interesting for most people, I’d just forget about it. I did this because I can, not because I needed to.

writing projects

I mainly use my website as a project listing. It’s got one main directory for the “bloglike” stuff, which is basically a page per project which generates a table of contents for the project directory page. This main directory is /content/projects/. Images are stored in /static/images which, when rendered, becomes /images.

Otherwise, there’s a main page located at /_index.md which renders to /index.html, and it’s just a landing page for my site.

note

Use GitHub secrets for all credentials and distribution IDs. The workflow examples above reference secrets, so nothing sensitive is committed to the repo. This means your repo can be public without leaking keys.

Mountain in the Sea

David Emerson — Mon, 30 Mar 2026 00:00:00 +0000

Nayler, Ray. (2023). (rated 3/5) (recommended by Julian P.)

This is a good story, well written, a light read for vacation without being superficial. The device of the octopus as an alternative intelligence is not particularly well developed, and is almost peripheral to the story of human conquest and greed. There’s a side plotline about robotic fishing vessels (which aren’t so robotic after all) which could almost justify being the main plotline, as it’s far more interesting than the octopus colony.

All in all, though, it deserves its popularity. A worthwhile read.

How to Change Your Mind

David Emerson — Wed, 18 Mar 2026 00:00:00 +0000

Pollan, Michael. (2018). (rated 3/5) (recommended by Julian P.)

A relatively fast read given the page count, and I always like Michael Pollan’s style. This might be the single best consolidated history of psychedelics I have read, and I’ve read a few. It is also modern enough to contain the contemporary history, which is in rapid flux since the reboot of research in the early 2000s.

He tempers the mystical without disparaging it, which I think is important for a practice which may have real scientific benefits but comes from both genuine and ulterior movies mystically.

Lunario sentimental

David Emerson — Mon, 23 Feb 2026 00:00:00 +0000

overview

One of my favorite books, a lecture by Jorge Luis Borges on writing, cites a Leopoldo Lugones work for which I can find no English translation.

“The Argentine poet Lugones, way back in the year 1909, wrote that he thought poets were always using the same metaphors, and that he would try his hand at discovering new metaphors for the moon. And in fact he concocted many hundreds of them. He also said, in the foreword to a book called Lunario sentimental, that every word is a dead metaphor.”

Borges, This Craft of Verse, p. 22 (The Metaphor)

I am intrigued! Let’s get a translation out in the world.

timeline

24 December 2024

we're up to page 71 in translation work

25 December 2024

poetry typesetting template complete

01 January 2025

we're up to page 201 in translation work

06 January 2025

we're finished with initial translation work

7 January 2025

typesetting all poetry begins

13 January 2025

the poetry typesetting is progressing well, about 50%, and I've developed a typesetting method for the plays, which was something of a task, since the dramatist package does not get along well with XeLaTeX inside of a book document type

14 January 2025

poetry typesetting complete

15 January 2025

prose typesetting complete

February 2026

endnotes, fidelity pass against the 1909 original, bilingual chapter titles, cover finalized, font licensing resolved, final typographic refinements. 278 pages, ready for print

original

The original work was published in 1909, and has since entered the public domain. You can download it here.

The work contains 37 pieces:

four plays
four works of prose
29 poems

translation

Spanish to English translation was done by Oskarina Perez. I hired her for her familiarity with the genre and the author.

I did English editing work, in consultation with Oskarina.

The chapter titles are kept in the original Spanish throughout the book, with English translations appearing in the table of contents. I like this convention for translated poetry — the Spanish titles have a sonic quality that English tends to flatten. “Jaculatoria Lunar” is better than “Lunar Ejaculatory Prayer.” The table of contents gives you both, so nobody’s locked out.

43 endnotes cover classical references, obscure vocabulary, foreign phrases, and translation choices. They live in the back of the book to keep the poems clean on the page.

typesetting

I typeset the work in XeLaTeX, to provide modern font support.

body font

EB Garamond was chosen for its wide character support and, well, because it’s beautiful.

Since this stuff matters, here’s how I’ve configured EB Garamond in fontspec:

\setmainfont{EBGaramond}
    [
        UprightFont = EBGaramond-Regular,
        ItalicFont = EBGaramond-Italic,
        BoldFont = EBGaramond-Bold,
        BoldItalicFont = EBGaramond-BoldItalic,
        Ligatures = {Common, Rare},
        StylisticSet = 6,
        Numbers = Proportional,
        Numbers = OldStyle
    ]

I initially held off on Ligatures = Rare because I wasn’t sure I could justify it ergonomically, but I’ve come around. The discretionary ct and st ligatures — where the letters get a connecting swash arc between them — are gorgeous and period-appropriate for a 1909 text. Words like “sentimental,” “architecture,” “distinction” all pick up these elegant old-style joins. It’s subtle enough that most readers won’t consciously notice, but it gives the text a distinctly hand-set, early-20th-century feel.

title font

Six Caps is the title font — an ultra-condensed display face under the SIL Open Font License. I had been using HFF High Tension, which is based on “Bamberg” from a Dover Circus Alphabets book, but the licensing was ambiguous for commercial use. Six Caps has the same dramatic vertical compression and reads almost identically on a shelf, with the benefit of being unambiguously open source.

poetry

The poetry is set using the poetry package. There’s really no trick to this, a poem looks as follows in the code,

\poemlinenumsfalse
\centerpoemoff
\begin{poem}
\textit{Che cotesta córtese opinione} \\
\textit{Ti fian chiavata in mezzo della testa.} \\!
\end{poem}

plays

Plays were a bigger deal. I like the dramatist package a lot, but it doesn’t work inside a book document type in XeLaTeX. So I made my own environment to format the plays, headers, and dramatis personae sections. Here’s what it looks like in the preamble:

% Play environment with acts and scenes
\newenvironment{play}[1]{
    \section*{#1} % Title of the play
    \setlength{\parindent}{0pt} % No indentation
    \setlength{\parskip}{0.6\baselineskip}
    \obeylines
}{
    \setlength{\parindent}{1em} % Restore default indentation
    \setlength{\parskip}{0pt} % Restore default spacing
}

% Commands for structured formatting — consistent across all plays
\newcommand{\act}[1]{%
    \bigskip\bigskip
    \centerline{{\Large\spacedsc{Act #1}}}
    \medskip
}
\newcommand{\scene}[1]{%
    \bigskip
    \centerline{\spacedsc{Scene #1}}
    \medskip
}
\newcommand{\character}[1]{%
    \textbf{#1.---}\hspace{1em} % Bold character names with em dash
}
\newcommand{\stage}[1]{%
    \textit{(#1)} % Italics for stage directions
}

% Dramatis Personae Environment — centered block with small caps heading
\newenvironment{dramatispersonae}{%
    \par\bigskip
    \begin{center}
    \spacedsc{Dramatis Personae}\\[0.75\baselineskip]
    \begin{tabular}{@{}r@{\kern 1em}l@{}}
}{%
    \end{tabular}
    \end{center}
    \bigskip
}

\newcommand{\dpline}[2]{%
    \textit{#1} & #2 \\[3pt]
}

And here’s what a play looks like in code:

\begin{play}{ }

\begin{dramatispersonae}
    \dpline{Dalinda}{23 years old, blonde. Sister of Jacinto.}
    \dpline{Jacinto}{26 years old. Brother of Dalinda.}
    \dpline{Reinaldo}{20 years old. Friend of Jacinto and Dalinda's fiancé.}
\end{dramatispersonae}

\act{I}

\scene{1}

\character{Jacinto} This is an example dialogue line.

\character{Reinaldo} \stage{Turning to Jacinto} This is another example.

This ends up looking as follows when compiled:

publication

TBD

The Critical Writings of James Joyce (queued)

David Emerson — Mon, 23 Feb 2026 00:00:00 +0000

Mason, Ellsworth. (1959). (rated NR/5)

In the Shape of a Human Body I am Visiting the Earth (reading)

David Emerson — Mon, 23 Feb 2026 00:00:00 +0000

Various. (2017). (rated NR/5)

Poetry compilation from McSweeney’s, “Poems from Far and Wide”.

Joyce and Feminism (queued)

David Emerson — Mon, 23 Feb 2026 00:00:00 +0000

Scott, Bonnie Kime. (1984). (rated NR/5)

Not Without Laughter (queued)

David Emerson — Mon, 23 Feb 2026 00:00:00 +0000

Hughes, Langston. (1930). (rated NR/5)

The Long Harpoon (queued)

David Emerson — Mon, 23 Feb 2026 00:00:00 +0000

Watson, Arthur C. (1929). (rated NR/5)

Tribe (queued)

David Emerson — Mon, 23 Feb 2026 00:00:00 +0000

Junger, Sebastian. (2016). (rated NR/5)

burn box

David Emerson — Thu, 19 Feb 2026 00:00:00 +0000

overview

The burn box is a place to burn small papers safely indoors. It’s a small open-topped steel box, four panels welded to a base plate, and the base is drilled with vent holes so the fire can pull fresh air in from underneath while it’s going.

The panels are stamped a word to a face: LIFE EXISTS AND IDENTITY. (Whitman, ofc)

build

The panels are thin sheet steel, tacked at the corners first and then welded out, with the vent holes drilled through the base after the box was closed up.

Thin metal difficult. It’s far less forgiving on flux core MIG than thick metal is. On heavy stock you have plenty of latitude in both time and power: you can dwell, you can run hot, and the mass around the puddle carries the heat off. None of that is true on thin material. Dwell a half second too long or run a touch too hot and you’re not welding anymore, you’re cutting a hole and then trying to fill it back in.

Cryopolitics: Frozen Life in a Melting World

David Emerson — Thu, 19 Feb 2026 00:00:00 +0000

Radin, Joanna. (2017). (rated 4/5) (recommended by Harper Z.)

Sick book! A collection of articles about the ways in which our ability to cool ourselves, our food, our industry, etc is a hallmark of the anthropocene. It’s not the whole story, but it is an often overlooked narrative, and no opportunity is wasted here to tell that story.

The piece on the history of refrigerated transport in the British Empire is especially good. I had not considered the ways in which that country would have been motivated to develop such a supply chain, but it makes a lot of sense.

The Death and Life of Great American Cities

David Emerson — Thu, 19 Feb 2026 00:00:00 +0000

Jacobs, Jane. (1961). (rated 4/5)

Jane Jacobs has a lot of hot takes. She’s funny and well-written and an astute observer of human uses for a city. This book is fluffy, don’t let the size intimidate you away from a relatively fast read.

In terms of content, variety is the name of the game here. The most interesting things she covers are:

The pernicious effects of financing on development, and the distinction between cataclysmic money (total redevelopment) and gradual money (optimization and minor improvement) as it relates to neighborhood health.
The myth of the automobile as a cause of ill.
What constitutes healthy and unhealthy mixes of commercial, industrial, and residential uses.
The failure of the Radiant City, or really anything planned in advance rather than facilitated over time.
Healthy and unhealthy scales at which blocks, buildings, and neighborhoods operate, and boundaries which both inhibit their health and support their health by providing beneficial constraint.

She hates a lot of things, most things, really. That said, much of what she wrote in 1961 came to pass and reads as prescient in 2026.

If you can read only one chapter, read the last chapter. It is really well written, and summarizes well her position on the relationship of the city to human habitation. In fact, the last chapter might best be read first, even if you plan to read the rest of the book.

“In real life, barbarians (and peasant) are the least free of men – bound by tradition, ridden by caste, fettered by supersitions, riddled by suspicion and foreboding of whatever is strange. ‘City air makes free,’ was the medieval saying, when city air literally did make free the runaway serf. City air still makes free the runaways from company towns, from plantations, from factory-farms, from subsistence farms, from migrant picker routes, from mining villages, from one-class suburbs.”

Attached (queued)

David Emerson — Sun, 01 Feb 2026 00:00:00 +0000

Levine, Amir. (2010). (recommended by Julian P.)

The I Ching or Book of Changes

David Emerson — Thu, 15 Jan 2026 00:00:00 +0000

Baynes, Cary. (1967). (rated 2/5)

It’s fine, but there are more comprehensible resources out there for this sort of thing. This translation is too esoteric for the modern reader, relatively. The method of casting is the same whatever you use, so get a resource you can understand for the actual reading. This one’s definitive, but not necessarily relatable.

Inventing Kindergarten (queued)

David Emerson — Tue, 23 Dec 2025 00:00:00 +0000

Brosterman, Norman. (1997). (rated NR/5) (recommended by Julian P.)

meteorite patterns

David Emerson — Thu, 18 Dec 2025 00:00:00 +0000

procedural Widmanstätten pattern generator

I keep the repo here up to date.

This project generates large-format, purely vector, procedurally generated meteorite-like surface patterns and outputs them as PDF files suitable for print, CNC, laser, or further vector processing.

They look like this:

The algorithm was inspired by a slice of the Muonionalusta meteorite, discovered in northern Sweden in 1906. Muonionalusta is an iron-nickel meteorite that exhibits a Widmanstätten pattern when etched, revealing interlocking crystalline phases formed by extremely slow cooling over millions of years.

This generator models the statistical and structural properties visible in etched meteorite slices. It establishes dominant crystallographic directions, draws layered cross-hatching, introduces imperfect, double-etched strokes, accounts for missing material and discontinuities, and basically establishes large-scale grain regions with local variation.

The result is a pattern that looks geologic and crystalline.

output characteristics

Arbitrary size PDF (limited only by memory/time)
No rasterization, no textures, no images
Every run produces a unique pattern by default
Optional deterministic regeneration via seed

method

The image is synthesized as the superposition of several independent line families, each representing a dominant crystallographic direction.

Each family is generated using the following components:

directional angles

A small set of dominant line orientations is defined (~45°, ~135°, minor orthogonal components). Each stroke family samples from a weighted angular distribution with tight variance, producing strong directional bias without mechanical regularity.

parallel strokes

For each direction, an infinite set of nearly parallel lines is generated, spacing is randomized using a log-normal distribution, lines overshoot the page and are clipped implicitly

This mimics the irregular lamella spacing seen in etched iron-nickel alloys.

grain modulation field

A low-frequency fractal noise field (FBM over value noise) is evaluated across the surface.

This grain field modulates stroke width, stroke opacity, dropout probability, ghost-stroke offsets.

This produces large-scale “crystal regions” where texture coherently shifts.

imperfection

No line is perfectly straight, and lateral jitter is applied along the normal direction, and jitter is smooth, not noisy, to avoid cartoon effects. Additional “ghost strokes” are drawn nearby to simulate double-etching.

gaps, loss

Segments of strokes are randomly dropped based on local grain intensity, producing broken lines, etched voids, and discontinuities characteristic of physical material removal.

randomness

By default: Each run uses a cryptographically strong random seed. You will never get the same output twice unless you use the same seed.

For reproducibility: You may supply an explicit seed. The seed used is printed after generation. Reusing the seed reproduces the pattern exactly.

output

Generated PDFs are automatically timestamped using UTC:

meteorite-YYYY-MM-DD-HH-MM-SS.SS.pdf

Example:

meteorite-2025-12-18-14-03-22.17.pdf

use

dependencies

pip install reportlab

run

python3 meteorite.py

The script will generate a new, unique pattern, write a timestamped PDF, print the output path and seed.

deterministic regeneration

generate_meteorite_pdf(
    W=3000,
    H=1800,
    seed=123456789
)

coordinates, scale

PDF units are points (1/72 inch), but since the output is vector, you may treat units as arbitrary.

For example: 36×24 inches → 2592×1728 points

Large architectural panels are feasible. I’m also thinking hipster graph paper or notebook paper.

log bench

David Emerson — Tue, 16 Dec 2025 00:00:00 +0000

overview

I chainsaw-milled some slabs from a tree which died in my yard, of lightning strike. The piece at the top of the log was nothing special for nice furniture, but still large enough to make a simple bench from.

process

Cut the log to rough dimensions with a chainsaw
Plane the log flat. This took a lot of planing because there was such a prominent cup to the end piece.
Seal with deck polyurethane. I hope this can take the weather
Cut steel scrap for a base, weld
Assemble

base design

shoe rack

David Emerson — Tue, 16 Dec 2025 00:00:00 +0000

overview

Shoes accumulate near outside doors, it’s just the way of things. When you have a bunch of outside doors, you have a bunch of shoe piles. The one in the mudroom was particularly egregious.

process

Measure your shoes. You don’t need a rack larger than your largest shoes. This rack is built for men’s size 13 or so, with a maximum height of 15-16“
Most shelves don’t need to be the height of your boots. Make one shelf for tall boots, one for mid boots, and many shelves for regular low shoes, which require not more than 8“ clearance from the ground
Weld up the frame, remembering to keep everything square (weld inside beads last to help with warping).
Weld on large casters with brakes, all four corners
Grind and sand the frame to clean it up
Paint frame
Cut poplar shelves to size
Finish poplar shelves with stain (“dark half” tung oil and half thinner) and polyurethane for water resistance
Assemble, revel in order

photos

Catching the Big Fish

David Emerson — Mon, 01 Dec 2025 00:00:00 +0000

Lynch, David. (2007). (rated 3/5) (recommended by Julian P.)

A book on meditation and reflections upon meditation by David Lynch, proponent of Transcedental Meditation and all around cool person, from the sounds of it. Also has two interviews, brief, at the end, with Ringo Starr and Paul McCartney, both interesting in the context of meditation.

Worth reading if you’re into TM.

Meteorites

David Emerson — Mon, 01 Dec 2025 00:00:00 +0000

Bevan, Alex. (2002). (rated 3/5) (recommended by Julian P.)

The preface says, “This book is written for people who are not scientists” which is perfect for a book which came alongside a meteroite present that I love and had next to me while I read a book which is plenty informative on the matter of meteorites without being written for scientists alone.

Small Houses

David Emerson — Mon, 01 Dec 2025 00:00:00 +0000

Jodidio, Philip. (2025). (rated 3/5) (recommended by Julian P.)

Excellent mostly visual reference if you’re thinking about building a small cabin or dwelling or office or whatnot. What people can do with small spaces, for reasons aesthetic and economic, is far more interesting in many ways than what people can do with large ones.

hearth

David Emerson — Wed, 19 Nov 2025 00:00:00 +0000

My hearth, heavily used in winter because of wood heating, was unstable due to a floating (separate from main slab) foundation under the concrete block pile which surrounds the stove. The block pile is sinking a little faster than the house, and the hearth is the interface, which cracks tiles very quickly after they are installed, almost seasonally.

The originally specified hearth dimensions were also inadequate for safely containing embers, which would readily roll further than the tile surface from the elevated wood stove.

Let’s try steel plate! It has no grout lines to clean, it’s not flammable, and it won’t crack when the slab shifts.

I used 0.25“ thick AR400 steel plate. This hearth weighs about 383 pounds, so get yourself some lifting magnets and some friends to move it around if you have a similarly large dimensional requirement.

First, we measure out the hearth size (paper tape)

Then demolition

Then leveling concrete so the surface is perfectly flat

Then we plasma cut a piece the correct size and grind off all the mill scale and oil and stuff. This is the hard part. It takes a really long time to grind a piece of steel that large.

Once the steel is complete cleaned up with a grinder, the oxide process (cold gunblue):

Clean the whole steel surface with alcohol or some power degreaser that leaves no residue. Clean a few times, thoroughly.
Load a spray bottle which features a fine mist mode with cold bluing solution. I used Birchwood Presto Black BST4.
Spray the whole surface with the solution from the mist bottle. Spray evenly, everything you want oxided.
Wait 90 seconds.
Use a hose to rinse off the oxide solution thoroughly.
Use a leafblower or compressed air to dry the surface thoroughly.
Repeat oxide process. I did one coat using the spray bottle, and then did two more coats (waiting 90 seconds, rinsing, and drying between coats) simply dumping and wiping the oxide solution on with paper towel. This gives a cool mottled effect from the spray, a runny effect from the dumping, and an even effect from the wiping.
When you’re happy with the finish, do a final rinse and dry.
Coat the steel thoroughly with a protective oil, I use Ballistol or Renaissance Wax. For this hearth, particularly Renaissance Wax, since it’s dries matte.

This is what the finish looks like close-up. I love the tool marks from grinding, and I am very happy with the appearance of the oxide.

The plate fit perfectly in the floor.

All done, though the steel does get a little darker over the next few days under the wax finish.

No Man is an Island

David Emerson — Wed, 19 Nov 2025 00:00:00 +0000

Donne, John. (1631). (rated 4/5)

A neat collection of John Donne’s work. His meditations (on illness) are the best here: funny, hypochondriac, wise, and relevant.

The Psychoanalysis of Fire (reading)

David Emerson — Wed, 19 Nov 2025 00:00:00 +0000

Bachelard, Gaston. (1938). (rated NR/5)

oracle

David Emerson — Tue, 18 Nov 2025 00:00:00 +0000

get your fortune here.

McSweeney's #77

David Emerson — Mon, 06 Oct 2025 00:00:00 +0000

Various. (2025). (rated 3/5)

The usual, in a good way.

I liked “The Orts” by Emily Crossen and “Merlin” by Matthew Rohrer.

Circe

David Emerson — Thu, 02 Oct 2025 00:00:00 +0000

Miller, Madeline. (2018). (rated 3/5) (recommended by Elizabeth B.)

Do I have trouble with novels in the first person? Perhaps!

The story is fun though. In an traditional epic sense, we meet Circe as a rather undeveloped character, a powerful witch type in her palace on a remote island.

Miller provides the missing back-story, and makes her a much more complicated, interesting individual.

I also did not know or remember that her son (with Odysseus) kills Odysseus, even in original canon. That’s a typically dramatic and curious twist!