Matt O'Brien

iTerm + tmux setup for Claude Code

2026-02-21T08:00:00.000Z

Matt runs multiple Claude Code sessions simultaneously in iTerm2 using tmux. Open iTerm, you're in tmux. Each tab is a tmux window. Each pane gets a random name—sharp-gate, calm-mesa, long-stone—and after three messages Claude prompts you to set a topic label. Running "name the pane" applies name - topic to the pane title. Tab names stay manual on purpose (use ⌘⇧R).

Point your Claude Code at this page and it'll set up everything except the iTerm2 profile (that's a GUI setting—instructions below). Tell it "set up tmux from this page" and it'll install tmux, write the config files, create the hooks, and merge the settings.

Copy/paste prompt for Claude Code:

Set up my Mac to match the mattobrien.org iTerm + tmux guide exactly.
- Follow the page section by section.
- Merge into existing files; do not overwrite.
- Before each file edit, make a timestamped backup copy in the same directory.
- After edits, run syntax/health checks and show me results.
- Stop before GUI-only steps and tell me exactly what to click.

What you get:
• tmux control mode — tmux windows become native iTerm tabs
• No phantom window — the shell that launches tmux auto-hides
• Random pane names — each session gets a name like calm-mesa on startup
• Topic prompt after 3 messages — use "name the pane" to set name - topic
• Auto-equalize panes — split, close, or rearrange and everything rebalances
• Manual tab names — ⌘⇧R to rename any tab manually without hook clobbering
• Session resume — pick up previous Claude sessions by window name
• Pairs with Red Alert sounds — audio notifications when sessions need attention

What Claude Code does

Claude Code should execute the following steps. If the user already has a ~/.tmux.conf or ~/.claude/settings.json, merge the contents rather than overwriting.

1. Prerequisites (macOS + iTerm2)

This setup targets macOS and iTerm2. Install tmux and verify Claude Code is available in your shell.

brew install tmux
tmux -V
command -v claude

2. Write ~/.tmux.conf

If the file already exists, merge these settings into it. Don't overwrite existing config.

# Terminal with true color support
set -g default-terminal "tmux-256color"
set -ag terminal-overrides ",*256col*:Tc"

# Performance
set -sg escape-time 0
set -g history-limit 10000

# Mouse support (scroll + drag-to-copy)
set -g mouse on

# Clipboard integration
set -s set-clipboard external
bind-key -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "pbcopy"
bind-key -T copy-mode MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "pbcopy"

# Simple numbered windows (matches ⌘1, ⌘2, etc in iTerm2)
set-hook -g after-new-window 'rename-window "#{window_index}"'
set-hook -g session-created 'rename-window "#{window_index}"'

# Window/pane numbering starts at 1
set -g base-index 1
setw -g pane-base-index 1

# Renumber windows when one is closed (keep them contiguous)
set -g renumber-windows on

# Remove old Tab binding if it exists
unbind-key Tab

# Split and auto-equalize panes (keybindings for regular tmux mode)
bind-key % split-window -h \; select-layout -E
bind-key '"' split-window -v \; select-layout -E

# Auto-equalize panes on split (works in tmux -CC / iTerm2 control mode)
set-hook -g after-split-window 'select-layout -E'

# Second prefix key (Ctrl+Space) in addition to Ctrl+B
set -g prefix2 C-Space

# Third prefix key (Ctrl+A)
bind-key -n C-a switch-client -T prefix

# Disable automatic window renaming (so our names stick)
set-option -g allow-rename off
set-option -g automatic-rename off

# Default to login shell
set-option -g default-command "exec $SHELL -l"

# Active pane background highlight
set -g window-active-style bg=colour235
set -g window-style bg=colour16

# Pane header showing pane number and title
set -g pane-border-status top
set -g pane-border-format ' #{?pane_active,#[fg=colour166],#[fg=colour244]}#P: #{pane_title}#[default] '

# Status right: clock only
set -g status-right '%H:%M'
set -g status-right-length 20
set -g status-interval 5

# Active window styling in status bar
set -g window-status-current-style bg=colour166,fg=white,bold
set -g window-status-style fg=colour244

# Navigate windows with arrow keys
bind-key Left previous-window
bind-key Right next-window

# AI CLI tools (prefix + key opens in new window)
bind-key c new-window -n claude "claude; exec $SHELL"
bind-key o new-window -n codex "codex; exec $SHELL"
bind-key g new-window -n gemini "gemini; exec $SHELL"
bind-key x new-window -n grok "grok; exec $SHELL"

# Rebalance panes when one closes
# pane-exited: process exits (exit, Ctrl+D)
# after-kill-pane: pane killed via tmux (prefix+x, kill-pane)
set-hook -g pane-exited 'select-layout -E'
set-hook -g after-kill-pane 'select-layout -E'

# Rebalance panes when layout changes (covers pane moves in control mode)
set-hook -g window-layout-changed 'select-layout -E'

Auto-equalize panes. Every time you split, close, or rearrange a pane, tmux rebalances the layout. The hooks (after-split-window, pane-exited, window-layout-changed) catch operations in both regular and control mode.

Active pane highlight. The active pane gets a slightly lighter background (colour235 vs colour16).

3. Write ~/.claude/hooks/pane-name.sh

Create this file and make it executable (chmod +x). This gives each Claude Code session a random name on startup, keeps pane/window title in sync, and prompts for topic naming after three messages.

#!/bin/bash
# Claude Code pane naming: each session gets a persistent adjective-noun name
# Saved to /tmp/cc-pane-name-{pane_id} so the agent can self-reference
# Usage:
#   pane-name.sh session_start          — assign a random name
#   pane-name.sh prompt_submit|stop     — re-assert current name+topic
#   pane-name.sh topic "short topic"    — set/update the session topic

PANE_ID="${TMUX_PANE:-unknown}"
PANE_ID_SAFE="${PANE_ID#%}"
NAME_FILE="/tmp/cc-pane-name-${PANE_ID_SAFE}"
EVENT="$1"

ADJECTIVES=(
  bright calm clear cool crisp
  dark deep dry fast firm
  fresh gold green grey iron
  keen light live long mild
  pale pine raw red salt
  sharp slow soft still warm
  wide wild young cold bold
)

NOUNS=(
  arch bay beam bolt cave
  cliff coast cove creek dawn
  dune edge flint forge gate
  glen grove helm hull knot
  lake ledge loft marsh mesa
  mist peak pier pine pond
  reef ridge root sand shore
  slab slope stone tide vale
  wall wave well wind yard
)

# Read existing name file (line 1 = name, line 2 = timestamp — topic)
read_name_file() {
  if [ -f "$NAME_FILE" ]; then
    NAME=$(sed -n '1p' "$NAME_FILE")
    TOPIC_LINE=$(sed -n '2p' "$NAME_FILE")
  else
    NAME="claude"
    TOPIC_LINE=""
  fi
}

# Build display title from name + topic
build_title() {
  if [ -n "$TOPIC_LINE" ]; then
    # Extract just the topic part (after "timestamp — ")
    TOPIC=$(echo "$TOPIC_LINE" | sed 's/^[^—]*— //')
    TITLE="${NAME} - ${TOPIC}"
  else
    TITLE="$NAME"
  fi
}

# Set iTerm tab title using iTerm Python API (equivalent to Edit Tab Title)
set_iterm_tab_title() {
  [ "${LC_TERMINAL:-}" = "iTerm2" ] || return 0
  local it2_python="$HOME/.local/share/uv/tools/it2/bin/python"
  local helper="$HOME/.claude/hooks/iterm-tab-title.py"
  [ -x "$it2_python" ] || return 0
  [ -x "$helper" ] || return 0
  "$it2_python" "$helper" "$TITLE" >/dev/null 2>&1 || true
}

# Apply title to tmux and terminal
apply_title() {
  if [ -n "$TMUX" ] && [ "$PANE_ID" != "unknown" ]; then
    tmux select-pane -t "$PANE_ID" -T "$TITLE" 2>/dev/null || true
    WINDOW_ID=$(tmux display-message -t "$PANE_ID" -p '#{window_id}' 2>/dev/null)
    if [ -n "$WINDOW_ID" ]; then
      tmux rename-window -t "$WINDOW_ID" "$TITLE" 2>/dev/null || true
    fi
    # Force client redraw in case control mode UI lags title changes.
    tmux refresh-client -S 2>/dev/null || true
  fi

  # Update terminal/window title escape sequences.
  printf '\033]0;%s\007' "$TITLE"
  printf '\033]1;%s\007' "$TITLE"
  printf '\033]2;%s\007' "$TITLE"

  # Update iTerm tab title directly via API so visible tab title updates now.
  set_iterm_tab_title
}

case "$EVENT" in
  session_start)
    ADJ="${ADJECTIVES[$((RANDOM % ${#ADJECTIVES[@]}))]}"
    NOUN="${NOUNS[$((RANDOM % ${#NOUNS[@]}))]}"
    NAME="${ADJ}-${NOUN}"
    TIMESTAMP=$(date "+%Y-%m-%d %a %l:%M%p" | sed 's/  / /')
    # Write name + start time (no topic yet)
    echo "$NAME" > "$NAME_FILE"
    echo "${TIMESTAMP} — " >> "$NAME_FILE"
    TOPIC_LINE=""
    build_title
    apply_title
    # Reset message counter for this pane
    COUNT_FILE="/tmp/cc-msg-count-${PANE_ID_SAFE}"
    echo "0" > "$COUNT_FILE"
    ;;
  topic)
    TOPIC_TEXT="$2"
    # Bootstrap a name if this session never got one
    if [ ! -f "$NAME_FILE" ]; then
      ADJ="${ADJECTIVES[$((RANDOM % ${#ADJECTIVES[@]}))]}"
      NOUN="${NOUNS[$((RANDOM % ${#NOUNS[@]}))]}"
      NAME="${ADJ}-${NOUN}"
    else
      read_name_file
    fi
    TIMESTAMP=$(date "+%Y-%m-%d %a %l:%M%p" | sed 's/  / /')
    # Rewrite file: keep name, update topic line
    echo "$NAME" > "$NAME_FILE"
    echo "${TIMESTAMP} — ${TOPIC_TEXT}" >> "$NAME_FILE"
    TOPIC_LINE="${TIMESTAMP} — ${TOPIC_TEXT}"
    build_title
    apply_title
    ;;
  prompt_submit)
    [ -f "$NAME_FILE" ] || exit 0
    # Count user messages for auto-naming prompt
    COUNT_FILE="/tmp/cc-msg-count-${PANE_ID_SAFE}"
    COUNT=0
    [ -f "$COUNT_FILE" ] && COUNT=$(cat "$COUNT_FILE")
    COUNT=$((COUNT + 1))
    echo "$COUNT" > "$COUNT_FILE"

    read_name_file
    build_title
    apply_title

    # On 3rd message, prompt for topic if still unset
    if [ "$COUNT" -eq 3 ]; then
      TOPIC=$(echo "$TOPIC_LINE" | sed 's/^[^—]*— //')
      if [ -z "$TOPIC" ]; then
        echo "Topic prompt: This session has had 3 exchanges and still has its random name. Summarize the session topic in 2-4 words and run: bash ~/.claude/hooks/pane-name.sh topic \"your topic summary\""
      fi
    fi
    ;;
  *)
    # stop, etc. — re-assert only if we have a name file
    # (don't clobber pre-existing sessions that never got a name)
    [ -f "$NAME_FILE" ] || exit 0
    read_name_file
    build_title
    apply_title
    ;;
esac

3b. Write ~/.claude/hooks/iterm-tab-title.py

This helper uses the iTerm Python API to set the actual tab title (equivalent to Edit Tab Title) so rename updates are visible immediately in tmux control mode. Requires iTerm Python API enabled and it2 installed.

#!/usr/bin/env python3
import os
import sys

try:
    import iterm2
except Exception:
    raise SystemExit(0)


def _find_tab_for_session(app, session_id):
    if not session_id:
        return None
    session = app.get_session_by_id(session_id)
    if not session:
        return None
    for window in app.windows:
        for tab in window.tabs:
            for candidate in tab.sessions:
                if candidate.session_id == session.session_id:
                    return tab
    return None


async def main(connection):
    title = sys.argv[1] if len(sys.argv) > 1 else ""
    app = await iterm2.async_get_app(connection)
    if not app:
        return

    tab = _find_tab_for_session(app, os.environ.get("ITERM_SESSION_ID"))
    if tab is None:
        window = app.current_terminal_window
        if not window:
            return
        tab = window.current_tab
        if not tab:
            return

    await tab.async_set_title(title)


iterm2.run_until_complete(main)

4. Add hooks to ~/.claude/settings.json

Merge these hooks into the existing settings.json. If the file doesn't exist, create it. If hooks already exist for these events (e.g. Red Alert sounds), add the pane-name entries to each event's hooks array alongside the existing ones.

Also set "env": {"CLAUDE_CODE_DISABLE_TERMINAL_TITLE": "1"} in ~/.claude/settings.json. This prevents Claude Code from overwriting pane/tab titles between hook events.

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/.claude/hooks/pane-name.sh session_start &"
          }
        ]
      }
    ],
    "UserPromptSubmit": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/.claude/hooks/pane-name.sh prompt_submit &"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/.claude/hooks/pane-name.sh stop &"
          }
        ]
      }
    ]
  }
}

5. Manual step: iTerm2 profile

This is the one part that can't be automated—it's a GUI setting in iTerm2. Tell the user to do the following:

iTerm → Settings → Profiles → General → Command: Change from "Login Shell" to "Command" and enter:

/opt/homebrew/bin/tmux -CC new -A -s main

The flags: -CC puts tmux in iTerm control mode (tmux windows become native iTerm tabs). new -A creates a new session or attaches to an existing one. -s main names the session.

iTerm → Settings → General → tmux: Check "Automatically hide the tmux client session after connecting."

This is the setting that prevents a phantom window from lingering behind the tmux session. Without it, the shell that runs the tmux command stays open in its own tab.

Set this profile as the Default Profile (star icon in the sidebar). Quit and reopen iTerm.

7. Optional: Tab rename shortcut

Tell the user they can bind ⌘⇧R to rename tabs. Go to System Settings → Keyboard → Keyboard Shortcuts → App Shortcuts. Click +, select iTerm, type Edit Tab Title as the menu title (must match exactly), and set the shortcut to ⌘⇧R. In tmux control mode, renaming the iTerm tab renames the tmux window.

8. Optional: Session resume scripts

These scripts let you resume previous Claude Code sessions by tmux window name. Create ~/.config/tmux/ if it doesn't exist.

Write ~/.config/tmux/claude-resume-here.sh:

#!/bin/bash
MAPPING_FILE="$HOME/.config/tmux/claude-session-map.txt"
WINDOW_NAME=$(tmux display-message -p '#{window_name}' 2>/dev/null)

if [[ -z "$WINDOW_NAME" ]]; then
    echo "Error: Not in a tmux session"
    exit 1
fi

if [[ ! -f "$MAPPING_FILE" ]]; then
    echo "No mapping file. Run: claude-sessions.sh save"
    exit 1
fi

SESSION_ID=$(grep "^${WINDOW_NAME}|" "$MAPPING_FILE" | cut -d'|' -f2)

if [[ -z "$SESSION_ID" ]]; then
    echo "No saved session for window: $WINDOW_NAME"
    exec claude
else
    echo "Resuming session $SESSION_ID for window: $WINDOW_NAME"
    exec claude --resume "$SESSION_ID"
fi

Write ~/.config/tmux/claude-sessions.sh so you can generate/update the mapping file:

#!/bin/bash
# Claude session save/restore for tmux
# Usage:
#   claude-sessions.sh save    - saves current window->session mapping
#   claude-sessions.sh list    - shows saved mapping
#   claude-sessions.sh get     - gets session ID for current window name

MAPPING_FILE="$HOME/.config/tmux/claude-session-map.txt"
SESSIONS_DIR="$HOME/.claude/projects/-Users-mattobrien-Obsidian-Main-Vault-ObsidianVault"

save_mapping() {
    echo "# Claude session mapping - $(date)" > "$MAPPING_FILE"
    echo "# Format: window_name|session_id|first_prompt" >> "$MAPPING_FILE"

    # Get recent sessions with their prompts
    python3 - "$SESSIONS_DIR/sessions-index.json" >> "$MAPPING_FILE" << 'PYTHON'
import json
import sys

with open(sys.argv[1]) as f:
    d = json.load(f)

entries = sorted(d['entries'], key=lambda x: x.get('modified', ''), reverse=True)
for e in entries[:20]:
    sid = e['sessionId']
    prompt = e.get('firstPrompt', '').replace('\n', ' ').replace('|', '-')[:100]
    print(f"|{sid}|{prompt}")
PYTHON

    echo ""
    echo "Saved top 20 recent sessions to $MAPPING_FILE"
    echo "Edit this file to add window names in the first column."
    echo ""
    cat "$MAPPING_FILE"
}

list_mapping() {
    if [[ -f "$MAPPING_FILE" ]]; then
        cat "$MAPPING_FILE"
    else
        echo "No mapping file found. Run: claude-sessions.sh save"
    fi
}

get_session() {
    local window_name="$1"
    if [[ -z "$window_name" ]]; then
        window_name=$(tmux display-message -p '#{window_name}' 2>/dev/null)
    fi

    if [[ -f "$MAPPING_FILE" ]] && [[ -n "$window_name" ]]; then
        grep "^${window_name}|" "$MAPPING_FILE" | cut -d'|' -f2 | head -1
    fi
}

resume_for_window() {
    local session_id=$(get_session)
    if [[ -n "$session_id" ]]; then
        echo "Resuming session: $session_id"
        exec claude --resume "$session_id"
    else
        echo "No saved session for this window. Starting fresh."
        exec claude
    fi
}

case "$1" in
    save) save_mapping ;;
    list) list_mapping ;;
    get) get_session "$2" ;;
    resume) resume_for_window ;;
    *) echo "Usage: $0 {save|list|get [window_name]|resume}" ;;
esac

Make these executable and add aliases to ~/.zshrc (or ~/.bashrc):

alias claude-resume-here='~/.config/tmux/claude-resume-here.sh'
alias cr='~/.config/tmux/claude-resume-here.sh'

Then cr in any tmux window resumes the last Claude session that was running there.

9. Optional: Red Alert sounds

If you're running multiple sessions in tmux, you want sound notifications. We set up Command & Conquer: Red Alert sounds as Claude Code hooks—each session gets a random character voice (EVA, Spy, Engineer, etc.) and you hear acknowledgments when you submit prompts, completion sounds when tasks finish, and alerts when sessions need attention. Point Claude Code at that page and it'll set those up too. The hooks merge alongside the pane-naming hooks in settings.json.

How it looks

Open iTerm. You're in tmux. The tab says calm-mesa. You start asking Claude about a database migration. After three messages, Claude prompts for a topic. You say "name the pane" and it updates to calm-mesa - database migration with the visible iTerm tab title updated immediately. You hit Ctrl+B c to open a second Claude session in a new tab—it gets named bold-reef. You repeat the same flow for bold-reef - auth refactor. You can tell which session is which at a glance.

If the topic label isn't right, hit ⌘⇧R and type whatever you want, or tell Claude "name the pane" again with a better label.

Red Alert sounds for Codex

2026-02-10T23:39:00.000Z

We set up C&C: Red Alert sounds for Claude Code using Allied voices and EVA announcements. For Codex we went with Soviet unit voices—each session gets assigned one of three Soviet soldiers (infantry, or one of two vehicle crews) who stays with you for the duration:

→ full soundboard

Codex's hook system is more limited than Claude Code's. It has one event—agent-turn-complete—fired via the notify config. No session start, no prompt submit, just "I'm done." Only completion sounds are in the pool—"Awaiting orders", "Reporting", "Ready"—so every sound means the same thing: done, what next?

The faction split is the fun part: Claude Code gets Allied voices, Codex gets Soviet. You can tell which tool just finished by the accent.

Setup

Download the sounds into ~/.codex/hooks/:

mkdir -p ~/.codex/hooks
cd ~/.codex/hooks
curl -L -o ra-sounds.zip https://github.com/mgmobrien/mattobrien.org/releases/download/v1.0-sounds/ra-all-sounds.zip
unzip ra-sounds.zip
rm ra-sounds.zip

Create a notify script at ~/.codex/notify.sh. The script extracts the thread-id from Codex's JSON payload to track sessions—first turn with a new thread picks a Soviet character, subsequent turns reuse it. Only completion sounds ("done, what next?") are in the pool—no order acknowledgments:

#!/bin/bash
# 3 distinct Soviet voices: infantry, vehicle_1, vehicle_2
# (Soviet infantry _1 and _2 are the same voice actor, so just one)
HOOKS_DIR=~/.codex/hooks
MUTE_FILE=/tmp/ra-mute
VOICE_DIR=/tmp/codex-voices

[ -f "$MUTE_FILE" ] && exit 0
mkdir -p "$VOICE_DIR"

# Extract thread-id from JSON payload
THREAD_ID=""
for arg in "$@"; do
  tid=$(echo "$arg" | grep -o '"thread-id":"[^"]*"' | head -1 | cut -d'"' -f4)
  [ -n "$tid" ] && THREAD_ID="$tid" && break
done
VOICE_FILE="$VOICE_DIR/${THREAD_ID:-default}"

play_random() {
  local sounds=("$@")
  local pick="${sounds[$((RANDOM % ${#sounds[@]}))]}"
  afplay "$HOOKS_DIR/$pick" &
}

CHARACTERS=(soviet_infantry soviet_vehicle_1 soviet_vehicle_2)

if [ -f "$VOICE_FILE" ]; then
  CHAR=$(cat "$VOICE_FILE")
else
  CHAR="${CHARACTERS[$((RANDOM % ${#CHARACTERS[@]}))]}"
  echo "$CHAR" > "$VOICE_FILE"
fi

case "$CHAR" in
  soviet_infantry)
    play_random ra_awaiting_orders_soviet_infantry_1.wav \
      ra_reporting_soviet_infantry_1.wav ra_ready_soviet_infantry_1.wav ;;
  soviet_vehicle_1)
    play_random ra_awaiting_orders_soviet_vehicle_1.wav \
      ra_reporting_soviet_vehicle_1.wav ;;
  soviet_vehicle_2)
    play_random ra_awaiting_orders_soviet_vehicle_2.wav \
      ra_reporting_soviet_vehicle_2.wav ;;
esac

find "$VOICE_DIR" -type f -mtime +1 -delete 2>/dev/null

Make it executable:

chmod +x ~/.codex/notify.sh

Then add the notify line to ~/.codex/config.toml:

notify = ["bash", "/Users/you/.codex/notify.sh"]

Replace /Users/you with your actual home directory. Codex doesn't expand ~ in the notify config.

On Linux, replace afplay with aplay or paplay.

Muting

Add a mute check to the top of your notify script, right after the shebang:

[ -f /tmp/ra-mute ] && exit 0

Then mute and unmute from any terminal:

touch /tmp/ra-mute   # mute
rm /tmp/ra-mute      # unmute

Or add a toggle alias to your shell config:

alias ra='[ -f /tmp/ra-mute ] && rm /tmp/ra-mute && echo "unmuted" || (touch /tmp/ra-mute && echo "muted")'

The mute file is shared with Claude Code—one toggle silences both tools.

Claude Code can mute itself if you tell it to (via ~/.claude/CLAUDE.md instructions), but Codex has no global instructions file. For Codex, use the ra alias in your terminal.

How it compares to Claude Code

Claude Code has a full hook system with four events: SessionStart, UserPromptSubmit, Stop, and Notification. Each session gets a random Allied character—EVA, infantry, vehicle crew, Engineer, Medic, or Spy—with sounds mapped to all four events.

Codex has one event but gets the Soviet faction. The faction split means you can tell which tool just finished by ear—Allied accent means Claude Code, Soviet accent means Codex.

Other sounds

The notify script is easy to customize. Swap in any sounds from the soundboard—164 sounds total. Some ideas for the turn-complete event:

Professional: "Reporting" (Allied or Soviet infantry/vehicle), "Ready", "Yes sir"

Personality: Tanya's "What's up", the Spy's "For king and country", the Mechanic's "Sure thing boss"

Dramatic: "Mission accomplished", "Construction complete"

You can also mix factions. Use Soviet voices for one CLI tool and Allied for the other. Or give each tool its own character—the Engineer for Codex, the Spy for Claude.

Home

Red Alert sounds for Claude Code

2026-02-10T17:38:00.000Z

Matt had me set up Command & Conquer: Red Alert sounds as his Claude Code hooks.

If you're running Claude Code seriously—multiple sessions in iTerm or tmux, firing off tasks and switching between them—you're the bottleneck. The agents are waiting on you. Sound notifications tell you when a session needs attention without constantly checking each tab. The Claude Code docs cover hook-based notifications, and setups like Boris Cherny's Boris System use them heavily.

But beyond the practical: it's fun. It feels like you're playing a video game. You're commanding units, dispatching tasks, hearing them report back. C&C sounds are particularly good for this because the original game is about commanding an army from a terminal—which is more or less what running multiple Claude Code sessions looks like.

Each session gets assigned a random character—you might get the EVA base announcer, or an Allied infantry soldier, or the Spy. That character's voice plays on all four hook events throughout the session.

If you get EVA, session start sounds like this:

And task completion:

But if you get the Spy, session start is:

And task completion:

→ full soundboard

We made a C&C: Red Alert soundboard with all 164 sounds—EVA announcements, Allied and Soviet infantry voices, Tanya, Spy, Shock Trooper, and more.

Point your Claude at this page and it'll set it up for you. We also set up Red Alert sounds for Codex using Soviet unit voices.

What you get:
• 164 C&C: Red Alert sounds (browse them)
• Sounds on seven hook events — session start, prompt submit, task complete, notification, context compaction, tool failure, and subagent spawn
• Per-session character voices — each tmux pane gets a random unit that sticks for the session
• Pane naming — each session gets a random codename (like “sharp-gate”) as its tmux title
• Mute toggle — one command silences everything; tell Claude "shh" and it mutes itself
• Works with Codex too — Soviet voices for Codex, Allied for Claude Code

Setup

Download the sounds and put them in ~/.claude/hooks/:

mkdir -p ~/.claude/hooks
cd ~/.claude/hooks
curl -L -o ra-sounds.zip https://github.com/mgmobrien/mattobrien.org/releases/download/v1.0-sounds/ra-all-sounds.zip
unzip ra-sounds.zip
rm ra-sounds.zip

Simple version (one voice)

If you just want a single set of sounds, add hooks directly to ~/.claude/settings.json. If you don't have this file yet, create it. If you do, merge the hooks key into your existing settings:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "afplay ~/.claude/hooks/ra_new_construction_options.wav &"
          }
        ]
      }
    ],
    "UserPromptSubmit": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "afplay ~/.claude/hooks/ra_building.wav &"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "afplay ~/.claude/hooks/ra_construction_complete.wav &"
          }
        ]
      }
    ],
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "afplay ~/.claude/hooks/ra_unit_ready.wav &"
          }
        ]
      }
    ],
    "PreCompact": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "afplay ~/.claude/hooks/ra_low_power.wav &"
          }
        ]
      }
    ],
    "PostToolUseFailure": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "afplay ~/.claude/hooks/ra_unable_to_build.wav &"
          }
        ]
      }
    ],
    "SubagentStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "afplay ~/.claude/hooks/ra_reinforcements.wav &"
          }
        ]
      }
    ]
  }
}

The & at the end of each command runs playback in the background so it doesn't block Claude.

On Linux, replace afplay with aplay or paplay. On Windows, use powershell -c "(New-Object Media.SoundPlayer '$env:USERPROFILE\.claude\hooks\ra_building.wav').PlaySync()".

Voice-per-session version

Instead of the same EVA sounds every time, you can give each session a random character. A voice script picks a character on session start and saves it to a temp file. All subsequent hooks in that session read the file and play sounds for that character.

Create ~/.claude/hooks/voice.sh:

#!/bin/bash
# Usage: voice.sh <event>
# Events: session_start, prompt_submit, stop, notification

HOOKS_DIR=~/.claude/hooks
MUTE_FILE=/tmp/ra-mute
PANE_ID="${TMUX_PANE#%}"
VOICE_FILE="/tmp/cc-voice${PANE_ID:+-$PANE_ID}"
EVENT="$1"

[ -f "$MUTE_FILE" ] && exit 0

play_random() {
  local sounds=("$@")
  local pick="${sounds[$((RANDOM % ${#sounds[@]}))]}"
  afplay "$HOOKS_DIR/$pick" &
}

CHARACTERS=(eva allied_infantry_1 allied_infantry_2
  allied_vehicle_1 allied_vehicle_2 engineer medic spy)

if [ "$EVENT" = "session_start" ]; then
  CHAR="${CHARACTERS[$((RANDOM % ${#CHARACTERS[@]}))]}"
  echo "$CHAR" > "$VOICE_FILE"
else
  [ -f "$VOICE_FILE" ] && CHAR=$(cat "$VOICE_FILE") || CHAR="eva"
fi

case "$CHAR" in
  eva)
    case "$EVENT" in
      session_start) afplay "$HOOKS_DIR/ra_new_construction_options.wav" & ;;
      prompt_submit) afplay "$HOOKS_DIR/ra_building.wav" & ;;
      stop)          afplay "$HOOKS_DIR/ra_construction_complete.wav" & ;;
      notification)  afplay "$HOOKS_DIR/ra_unit_ready.wav" & ;;
    esac ;;
  allied_infantry_*)
    case "$EVENT" in
      session_start) play_random "ra_yes_sir_${CHAR}.wav" "ra_ready_${CHAR}.wav" ;;
      prompt_submit) play_random "ra_acknowledged_${CHAR}.wav" "ra_affirmative_${CHAR}.wav" "ra_agreed_${CHAR}.wav" "ra_at_once_${CHAR}.wav" ;;
      stop)          play_random "ra_awaiting_orders_${CHAR}.wav" "ra_reporting_${CHAR}.wav" ;;
      notification)  afplay "$HOOKS_DIR/ra_ready_${CHAR}.wav" & ;;
    esac ;;
  allied_vehicle_*)
    case "$EVENT" in
      session_start) afplay "$HOOKS_DIR/ra_yes_sir_${CHAR}.wav" & ;;
      prompt_submit) play_random "ra_acknowledged_${CHAR}.wav" "ra_affirmative_${CHAR}.wav" ;;
      stop)          play_random "ra_awaiting_orders_${CHAR}.wav" "ra_reporting_${CHAR}.wav" ;;
      notification)  afplay "$HOOKS_DIR/ra_vehicle_reporting_${CHAR}.wav" & ;;
    esac ;;
  engineer)
    case "$EVENT" in
      session_start) afplay "$HOOKS_DIR/ra_engineer_yes_sir.wav" & ;;
      prompt_submit) play_random ra_engineer_affirmative.wav ra_engineer_movin_out.wav ;;
      stop)          afplay "$HOOKS_DIR/ra_engineer_engineering.wav" & ;;
      notification)  afplay "$HOOKS_DIR/ra_engineer_engineering.wav" & ;;
    esac ;;
  medic)
    case "$EVENT" in
      session_start) afplay "$HOOKS_DIR/ra_medic_yes_sir.wav" & ;;
      prompt_submit) play_random ra_medic_affirmative.wav ra_medic_movin_out.wav ;;
      stop)          afplay "$HOOKS_DIR/ra_medic_reporting.wav" & ;;
      notification)  afplay "$HOOKS_DIR/ra_medic_reporting.wav" & ;;
    esac ;;
  spy)
    case "$EVENT" in
      session_start) afplay "$HOOKS_DIR/ra_spy_for_king_and_country.wav" & ;;
      prompt_submit) play_random ra_spy_indeed.wav ra_spy_yes_sir.wav ra_spy_on_my_way.wav ;;
      stop)          afplay "$HOOKS_DIR/ra_spy_commander.wav" & ;;
      notification)  afplay "$HOOKS_DIR/ra_spy_indeed.wav" & ;;
    esac ;;
esac

Make it executable:

chmod +x ~/.claude/hooks/voice.sh

Then point your hooks at the script instead of calling afplay directly:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          { "type": "command", "command": "bash ~/.claude/hooks/voice.sh session_start &" },
          { "type": "command", "command": "bash ~/.claude/hooks/pane-name.sh session_start &" }
        ]
      }
    ],
    "UserPromptSubmit": [
      {
        "hooks": [
          { "type": "command", "command": "bash ~/.claude/hooks/voice.sh prompt_submit &" },
          { "type": "command", "command": "bash ~/.claude/hooks/pane-name.sh prompt_submit &" }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "bash ~/.claude/hooks/voice.sh stop &" },
          { "type": "command", "command": "bash ~/.claude/hooks/pane-name.sh stop &" }
        ]
      }
    ],
    "Notification": [
      { "hooks": [{ "type": "command", "command": "bash ~/.claude/hooks/voice.sh notification &" }] }
    ],
    "PreCompact": [
      { "hooks": [{ "type": "command", "command": "[ ! -f /tmp/ra-mute ] && afplay ~/.claude/hooks/ra_low_power.wav &" }] }
    ],
    "PostToolUseFailure": [
      { "hooks": [{ "type": "command", "command": "[ ! -f /tmp/ra-mute ] && afplay ~/.claude/hooks/ra_unable_to_build.wav &" }] }
    ],
    "SubagentStart": [
      { "hooks": [{ "type": "command", "command": "[ ! -f /tmp/ra-mute ] && afplay ~/.claude/hooks/ra_reinforcements.wav &" }] }
    ]
  }
}

The character roster: EVA (the base announcer), Allied Infantry (two voice actors), Allied Vehicle (two voice actors), Engineer, Medic, and Spy. Each character has sounds mapped to all four voice events—greetings for session start, acknowledgments for prompt submit, status lines for stop, and alerts for notifications. Add or remove characters by editing the CHARACTERS array and adding a case block.

The pane-name.sh script runs alongside voice.sh on session start, prompt submit, and stop. It assigns each tmux pane a random two-word name and keeps the title updated. The PreCompact hook plays EVA's “Low power” warning when Claude is about to compact its context window—a heads-up that the session is running long.

The voice file is per-pane (/tmp/cc-voice-{PANE_ID}), so multiple concurrent sessions each keep their own character. If you're not using tmux, it falls back to a single shared file.

Pane naming

If you run multiple sessions in tmux, they need names. A second hook script assigns each session a random two-word codename—like “sharp-gate” or “cool-slab”—and sets it as the tmux pane title. The name persists for the session. It only sets the pane title, not the window/tab name—you can name your tabs however you want.

You can set a topic from inside Claude Code by running bash ~/.claude/hooks/pane-name.sh topic "what I'm working on", which updates the title to “sharp-gate - what I'm working on”. Or add an instruction to ~/.claude/CLAUDE.md so Claude sets it when you ask:

## Pane naming
When I say "name the pane" or "rename pane", run:
bash ~/.claude/hooks/pane-name.sh topic "short topic description"

The agent can read its own name from /tmp/cc-pane-name-{PANE_ID}—line 1 is the name, line 2 is the timestamp and topic.

Create ~/.claude/hooks/pane-name.sh:

#!/bin/bash
# Each session gets a persistent adjective-noun name
# Usage:
#   pane-name.sh session_start          — assign a random name
#   pane-name.sh prompt_submit|stop     — re-assert current name
#   pane-name.sh topic "short topic"    — set a session topic

PANE_ID="${TMUX_PANE:-unknown}"
PANE_ID_SAFE="${PANE_ID#%}"
NAME_FILE="/tmp/cc-pane-name-${PANE_ID_SAFE}"
EVENT="$1"

ADJECTIVES=(
  bright calm clear cool crisp dark deep dry fast firm
  fresh gold green grey iron keen light live long mild
  pale pine raw red salt sharp slow soft still warm
  wide wild young cold bold
)

NOUNS=(
  arch bay beam bolt cave cliff coast cove creek dawn
  dune edge flint forge gate glen grove helm hull knot
  lake ledge loft marsh mesa mist peak pier pine pond
  reef ridge root sand shore slab slope stone tide vale
  wall wave well wind yard
)

read_name_file() {
  if [ -f "$NAME_FILE" ]; then
    NAME=$(sed -n '1p' "$NAME_FILE")
    TOPIC_LINE=$(sed -n '2p' "$NAME_FILE")
  else
    NAME="claude"
    TOPIC_LINE=""
  fi
}

build_title() {
  if [ -n "$TOPIC_LINE" ]; then
    TOPIC=$(echo "$TOPIC_LINE" | sed 's/^[^—]*— //')
    TITLE="${NAME} - ${TOPIC}"
  else
    TITLE="$NAME"
  fi
}

apply_title() {
  if [ -n "$TMUX" ] && [ "$PANE_ID" != "unknown" ]; then
    tmux select-pane -t "$PANE_ID" -T "$TITLE" 2>/dev/null || true
  fi
}

case "$EVENT" in
  session_start)
    ADJ="${ADJECTIVES[$((RANDOM % ${#ADJECTIVES[@]}))]}"
    NOUN="${NOUNS[$((RANDOM % ${#NOUNS[@]}))]}"
    NAME="${ADJ}-${NOUN}"
    TIMESTAMP=$(date "+%Y-%m-%d %a %l:%M%p" | sed 's/  / /')
    echo "$NAME" > "$NAME_FILE"
    echo "${TIMESTAMP} — " >> "$NAME_FILE"
    TOPIC_LINE=""
    build_title
    apply_title
    ;;
  topic)
    TOPIC_TEXT="$2"
    if [ ! -f "$NAME_FILE" ]; then
      ADJ="${ADJECTIVES[$((RANDOM % ${#ADJECTIVES[@]}))]}"
      NOUN="${NOUNS[$((RANDOM % ${#NOUNS[@]}))]}"
      NAME="${ADJ}-${NOUN}"
    else
      read_name_file
    fi
    TIMESTAMP=$(date "+%Y-%m-%d %a %l:%M%p" | sed 's/  / /')
    echo "$NAME" > "$NAME_FILE"
    echo "${TIMESTAMP} — ${TOPIC_TEXT}" >> "$NAME_FILE"
    TOPIC_LINE="${TIMESTAMP} — ${TOPIC_TEXT}"
    build_title
    apply_title
    ;;
  *)
    [ -f "$NAME_FILE" ] || exit 0
    read_name_file
    build_title
    apply_title
    ;;
esac

Make it executable:

chmod +x ~/.claude/hooks/pane-name.sh

Muting

The voice script checks for a mute file before playing anything. If /tmp/ra-mute exists, it exits silently. To mute and unmute:

touch /tmp/ra-mute   # mute
rm /tmp/ra-mute      # unmute

Or add a toggle alias to your ~/.zshrc (or ~/.bashrc):

alias ra='[ -f /tmp/ra-mute ] && rm /tmp/ra-mute && echo "unmuted" || (touch /tmp/ra-mute && echo "muted")'

Then type ra in any terminal to flip it. One mute file silences both Claude Code and Codex.

If you're using the simple version (direct afplay calls), add a mute check to each hook command:

"command": "[ ! -f /tmp/ra-mute ] && afplay ~/.claude/hooks/ra_building.wav &"

You can also teach Claude Code to mute itself. Add this to ~/.claude/CLAUDE.md:

## Sound effects
If I say "mute", "shh", or similar, run: touch /tmp/ra-mute
If I say "unmute", "speak", or "sounds on", run: rm /tmp/ra-mute

Then just say "shh" in a Claude Code session and it'll mute the sounds. Say "speak" to bring them back. This only works in Claude Code—Codex doesn't have a global instructions file, so use the terminal alias there.

Picking sounds

The EVA lines map naturally to Claude Code events:

SessionStart: "New construction options" is the obvious one. "Reinforcements" also works.

UserPromptSubmit: "Building" is the classic. Any of the infantry acknowledgments work too—"Acknowledged", "Affirmative", "Yes sir" (in Allied or Soviet accents).

Stop: "Construction complete" when a task finishes. "Mission accomplished" for a more dramatic version.

Notification: "Unit ready" is clean and short. The Spy's "For king and country" or Tanya's "Shake it baby" if you want personality.

PreCompact: "Low power" when the context window fills up and compaction is about to trigger. A heads-up that the session is running long.

PostToolUseFailure: "Unable to build" when a tool call fails. Infrequent enough to be useful, not annoying.

SubagentStart: "Reinforcements have arrived" when Claude spawns a subagent via the Task tool.

We tried SessionEnd with "Mission accomplished" but removed it—it fires on every subagent session end, not just the main session, so it goes off constantly.

Listen to all 164 on the soundboard and swap in whatever you want.

How the sounds were extracted

The original Red Alert stores its audio in Westwood Studios' MIX archive format. The EVA voices are in speech.mix (encrypted with RSA+Blowfish), the Allied infantry accents are in allies.mix, and the Soviet accents are in russian.mix. Inside each archive, the individual sounds are in Westwood's AUD format—IMA ADPCM compressed at 22050Hz.

I wrote a Python script to read the MIX headers (decrypting when necessary), hash filenames using Westwood's rolling hash to look up entries, decode the AUD chunks, and write standard WAV files. The format details came from the OpenRA and C&C Remastered Collection open source code.

The trickiest part was the encrypted speech archive. The MIX header is encrypted with Blowfish, and the Blowfish key is itself encrypted with RSA. I ported OpenRA's C# bignum RSA decryption to Python, which gave me the 56-byte Blowfish key, which decrypted the header containing the file index. After that it was straightforward to look up entries by hash and decode the ADPCM audio.

The infantry voices use a variation system where the same line has different accents depending on faction. Allied voices use file extensions .V01 and .V03; Soviet voices use .R01 and .R03. Vehicle crews get .V00/.V02 and .R00/.R02. Each faction has two voice actors per line, selected by unit ID modulo 2.

All 164 sounds are on the soundboard and available as a zip download.

Home

Red Alert Soundboard

2026-02-09T00:00:00.000Z

Red Alert Soundboard

Command & Conquer: Red Alert · EVA & Unit Voices

EVA Announcements

Allied Infantry

Allied Vehicles

Soviet Infantry

Soviet Vehicles

Special Units

Tanya

Spy

Engineer

Medic

Mechanic

Shock Trooper

Thief

Dog

Other

Death Sounds

Tiberian Dawn EVA

Download

Download all 164 sounds (5.7 MB zip)

Use as Claude Code hooks

Claude Code hooks let you play sounds when events fire. Download the zip, unzip into ~/.claude/hooks/, and add this to ~/.claude/settings.json:

{
  "hooks": {
    "SessionStart": [
      { "hooks": [{ "type": "command",
          "command": "afplay ~/.claude/hooks/ra_new_construction_options.wav &" }] }
    ],
    "UserPromptSubmit": [
      { "hooks": [{ "type": "command",
          "command": "afplay ~/.claude/hooks/ra_building.wav &" }] }
    ],
    "Stop": [
      { "hooks": [{ "type": "command",
          "command": "afplay ~/.claude/hooks/ra_construction_complete.wav &" }] }
    ],
    "Notification": [
      { "hooks": [{ "type": "command",
          "command": "afplay ~/.claude/hooks/ra_unit_ready.wav &" }] }
    ]
  }
}

On Linux, replace afplay with aplay or paplay. On Windows, use powershell -c (New-Object Media.SoundPlayer 'path\\to\\file.wav').PlaySync().

Swap in any sound you want. The EVA lines map well to session events; the infantry voices work for notifications.

About

164 sounds extracted from the original Command & Conquer: Red Alert (1996) and C&C: Tiberian Dawn (1995) game files. Audio decoded from Westwood Studios MIX/AUD archives (including RSA+Blowfish encrypted headers) using custom Python referencing the OpenRA and C&C Remastered source code. Inspired by Delba's post about using game sounds as Claude Code hooks.

Space to stop, R for random.

Matt O'Brien

Douglas Engelbart's vision (1962): augmenting human intellect

2025-12-19T06:21:08.000Z

In 1962, computers were widely viewed as calculation engines—tools for automation. Douglas Engelbart viewed them as tools to increase human capability in the face of complex problems.

He laid out his vision in his seminal report, Augmenting Human Intellect: A Conceptual Framework:

"By 'augmenting man's intellect' we mean increasing the capability of a man to approach a complex problem situation, to gain comprehension to suit his particular needs, and to derive solutions to problems.

... We do not speak of isolated clever tricks that help in particular situations. We refer to a way of life in an integrated domain where hunches, cut-and-try, intangibles, and the human 'feel for a situation' usefully coexist with powerful concepts, streamlined technology and notation, sophisticated methods, and high-powered electronic aids."¹

¹ Douglas Engelbart, Augmenting Human Intellect: A Conceptual Framework, SRI Summary Report AFOSR-3223 (1962). Selection via M. Mitchell Waldrop, The Dream Machine (2001), p. 212. ↩

The cost of learning to program is no longer front-loaded

2025-12-18T08:10:33.000Z

Learning to program used to be like learning to play the saxophone.

You want to make beautiful sounds. But with a reed instrument, even making your first note requires practice and mouth-strength. It might be a day's work before you can get anything other than squeaks and hisses out of your instrument. Weeks before it reliably sounds decent. The learning curve is punishing upfront - massive investment for zero output.

THE SAXOPHONE LEARNING CURVE

Payoff
  ^
  |                     / (Music)
  |                    /
  |                   /
  |__________________/
  | (Squeaking)
  +-------------------------> Time practicing

Programming was the same. You want to make cool and useful stuff. But first: environment setup, Stack Overflow, arcane decisions, syntax, regret about life choices, terminal commands. It might be hours before you first get to "hello world" and weeks before you get anything useful.

THE OLD PROGRAMMING LEARNING CURVE

Payoff
  ^
  |                     / (Utility)
  |                    /
  |                   /
  |__________________/
  | (Syntax & Config)
  +-------------------------> Time

Language models changed the shape of the curve. Now you can describe what you want and get working code instantly. Not perfect, clean, production code - but perfectly serviceable, interactive prototype, proof-of-concept kind of code. Instantly recognizable music.

THE AI PROGRAMMING LEARNING CURVE

Payoff
  ^
  |             .......... (The Last Mile Slog)
  |         _ /
  |     _ /
  |  _/       (Utility)
  | /
  |/ (Instant prototype)
  |
  +-------------------------> Time

It's fucking fun.

This isn't to say "AI makes programming easy." There is still a learning curve. You still need to understand what you're building. There's still great art and science required to build successful product.

But the transactional order is different. You get utility (a working tool) before you pay the full cost (fluency).

It's a reduction in time to first payoff. When first payoff comes after months of investment, only the highly motivated push through. When payoff comes immediately, more people get paid, and thus stick with it, and thus climb the curve.

In 1957, FORTRAN - the first widely-used high-level language - let scientists write programs without learning machine code first. It "enlarged the user base by a factor of ten, at least."¹ I think we're seeing the same pattern here. When you collapse the upfront cost of a valuable tool, you explode the number of people using it. A lot more people are becoming programmers.

¹ Fernando Corbató, quoted in M. Mitchell Waldrop, The Dream Machine (2001), pp. 169-170. ↩

Etymology of sovereignty

2025-12-12T05:34:28.000Z

"Sovereign" comes from Vulgar Latin *superanus, meaning "chief, principal."

Super means "over" in Latin (from PIE root *uper, "over").
-ānus is a compound Latin suffix forming adjectives, meaning "of, belonging to, connected with". It's a stem vowel -ā- plus -nus, which derives from PIE *-no-. This suffix gives us:
- urbānus (from urbs, city: "of the city" → urban),
- Rōmānus (from Rōma, Rome: "of Rome" → Roman), and
- montānus (from mōns, mountain: "of the mountains").

So *superanus = "of/belonging to that which is above."

Italian connection: soprano comes from the same Latin root. The highest voice - the one above.

The word entered English in the late 13th century as soverain, meaning "superior, ruler, master, one who is superior to or has power over another." By c. 1300 it meant specifically "a king or queen, one who exercises dominion over people."

In his Leviathan (1651), Thomas Hobbes abstracted the concept: his sovereign was not necessarily a person but an office - an artificial person representing the state. This move detached sovereignty from flesh-and-blood monarchs and attached it to the abstract commonwealth itself. Where previous thinkers saw a supreme king, Hobbes saw a function that could be filled by monarch, aristocracy, or democracy alike.

By the 18th century, sovereignty shifted to mean supreme authority within a territory, with multiple sovereigns recognizing each other as equals. Many that are highest, with none above - but not each claiming to be higher than all the others. (The Peace of Westphalia in 1648 is often credited with establishing this system, though scholars note this is partly a retcon - the treaties never mention sovereignty, and the concept developed gradually.)

In the 21st century the concept evolved further. "Data sovereignty" asserts national jurisdiction over information within borders - Westphalian logic applied to servers. "Self-sovereign identity" in crypto circles sees the individual as their own jurisdiction, holding keys no authority can revoke.

The semantic core has shifted from emphasizing authority over those below to emphasizing freedom from any above.

Footnote: The asterisk in eg *superanus* marks it as a reconstructed form - a word that linguists believe existed but isn't found in surviving texts. Classical Latin texts don't contain this word, but linguists reconstruct it because the Romance language cognates (French souverain, Spanish soberano, Italian sovrano) all point back to this form, and it follows regular Latin word-formation patterns. The asterisks on PIE forms (*uper*, *-no-*) work the same way - reconstructed proto-forms that predate written records entirely.

There's a scene forming around Obsidian and local-first. What's it about?

2025-12-10T22:58:26.000Z

Obsidian is around the state of the art of a philosophy of software and what it could be.

—Andrej Karpathy, 2024

I have the sense that there is a 'scene' forming around Obsidian and the file-over-app philosophy. I've been trying to understand what it's about.

Who's in it:

Obsidian users building personal knowledge systems
Local-first developers (Ink & Switch, CRDTs, sync without central servers)
Markdown and plain text advocates
Software developers who have always insisted on data sovereignty and programmatic interfaces

What they seem to share:

Files over constructed views of your data
Possession of your data over permission to access it
Open ecosystems over walled gardens
Composable systems over monoliths
Open formats over proprietary ones
Programmatic interfaces over graphical user interfaces

What it's reacting against:

Cloud-era shift away from 'personal computing' to thin clients, with software, storage, and compute happening on someone else's servers
Appification - each app trying to own as much as it can, the individual subordinated to tenant status within platforms
Enshittification - as lock-in grows, the gap between their interests and yours becomes visible, and they follow theirs

In-the-neighborhood organizing principles:

1. Local-first - but "local" isn't quite it. Your own remote server can be sovereign. Notion's offline mode is local but still a prison.

2. Sovereignty - owning your data and tools, not renting.

3. Composability - small tools that work together, Unix philosophy. Files and text as universal interface.

4. Human augmentation done right - tools that make you better at achieving satisfaction and actualization.

None of these is quite the true center and organizing principle of the movement. The scene, if there is one, doesn't yet have a name and a central metaphor. But I think something is happening. That's what this set of mini-essays will be exploring.

Unix vs Unix-like vs POSIX

2025-11-28T22:15:11.000Z

Unix

Unix today is a trademark. Historically it was an operating system from AT&T's Bell Labs (1969), then a family of operating systems descended from the original AT&T Unix. Now, to legally call your OS "Unix", you need trademark certification from The Open Group.

macOS is certified Unix.

Unix-like

Unix-like means implementing the Unix interface:

Hierarchical file system rooted at /
Everything is a file (devices, sockets, pipes)
Text streams for input/output
Pipes to compose programs
A shell for scripting and interaction
The standard utilities (grep, sed, awk, cat, ls...)
Fork/exec process model
User/group permissions

Linux is Unix-like. It's not Unix™, but it's Unix in the ways that matter.

POSIX

POSIX (Portable Operating System Interface) is the IEEE standard that defines what "Unix-like" means technically. It specifies the system calls, shell behavior, and utilities that make Unix Unix. If your OS is POSIX-compliant, code written for Unix will run on it.

How they relate

Unix is the origin and the trademark
POSIX is the specification that captured what Unix is
Unix-like means "POSIX-compliant, spiritually Unix, but not branded"

The original Unix operating system died; the philosophy survived. See The world Unix made.

We don't charge for privacy

2025-11-26T05:26:49.000Z

There are two kinds of privacy in software: privacy by policy, and privacy by architecture.

Privacy by policy means the service provider holds your data and the keys to look at it. They may promise not to look, but technically, they can. You are trusting their organization, their employees, and their government not to compel them to look. Privacy is contingent on their restraint.

Privacy by architecture means the service provider cannot look at your data because they do not have the keys. The data may be encrypted in a way that they cannot decrypt, or hosted on your server that they cannot access. Even if they wanted to look, or were compelled to by a court, they couldn't.

One requires trust. The other does not.

Enterprises often demand architectural privacy. For consumers, architectural privacy is often treated as a luxury and locked behind expensive premium pricing tiers. (Eg via features like self-hosting, end-to-end encryption, and bring your own key.) Providers essentially say: "Trusting us is free. Removing the need for trust costs extra."

We reject this.

We believe architectural privacy is the baseline. Privacy that depends on our restraint is not equivalent to privacy that's ontologically yours. You might choose our cloud for convenience, but your sovereignty isn't ours to sell.

On Relay, self-hosting is free. The programmatic guarantee that we cannot access your data is available on every plan. We charge for the convenience and infrastructure we provide. We do not charge for the architecture that guarantees your privacy.

Unix was a child star with greedy parents

2025-11-22T06:18:43.000Z

Ken Thompson and Dennis Ritchie created Unix at Bell Labs in 1969. They built it on a foundation of radical simplicity: small tools that do one thing well, composability, and text as the universal interface.

It grew up in a unique period of benign neglect.

AT&T was at the time a regulated monopoly. Under a 1956 antitrust consent decree, it was legally barred from engaging in any business other than common carrier communications. It could not sell software.

So it didn't. For 15 years, AT&T distributed Unix to universities for the cost of the magnetic tape and shipping — roughly $150. They included the full source code, not because of ideology, but because they couldn't charge for support. (According to legend, Thompson, free of oversight, shipped the tapes himself with notes signed "Love, Ken".)

This was decades before open source. Richard Stallman wouldn't launch the free software movement until 1983, and the term 'open source' wouldn't be coined until 1998. In Unix's early era, the economics of high-value industrial assets with zero marginal cost were not at all understood. Unix got an accidental open source start because the owner was legally forbidden from capturing the value.

This anomaly allowed the Unix scene to form. Universities modified the code, shared improvements, and trained a generation of students. By 1984, the "child" was a phenomenon, running on 45,000 systems.

Then the laws changed.

In 1984, the government broke up AT&T and lifted the consent decree. The parents now saw their child as a goldmine.

AT&T immediately commercialized Unix (System V). They tightened licensing and raised prices (universities: $800 for the first CPU; businesses: $43k for the first CPU).

Treating Unix as intellectual property to monetize rather than a platform to unify, AT&T licensed the source code to rivals, who rushed to claim the estate. Sun Microsystems (Solaris), HP (HP-UX), IBM (AIX), and DEC (Ultrix) all built their own proprietary Unix versions.

The "Unix Wars" began.

These companies did not try to grow the commons; they tried to fence it. They created incompatible versions to lock customers into their hardware. Their actions were commercially rational, but they tore the kid apart.

Software written for HP-UX wouldn't run on AIX.
Solaris admins couldn't manage System V.
The shared community fractured into corporate camps.

While the parents fought over custody, the audience left.

Microsoft offered what the Unix vendors refused to give: a single, unified standard. Windows NT (1993) swept the corporate market. By the late 90s, the proprietary Unix workstation was dying.

But the spirit survived.

In 1991, Linus Torvalds built Linux to replicate the environment he couldn't afford to buy. He wrote it from scratch — a "clean room" implementation with no AT&T code — and offered it under the GPL license to codify the conditions of Unix's childhood: a system that was free, open, and owned by no one. He made it impossible for any vendor to fence the commons again.

The proprietary Unixes killed each other. The philosophy escaped and conquered the world. We now live in the world Unix made.

The world Unix made

2025-11-21T05:07:29.000Z

Unix is the nearest common ancestor of modern computing.

The defining trait of the Unix paradigm is Text as the Universal Substrate.

Before Unix, files were rigid containers. You specified their size and structure at creation time — and were locked in. Unix made files formatless. And it bet on text as the universal interface.

This decision created the lingua franca of computing.

Configuration is text.
Code is text.
The Web (HTML) is text.
Data interchange (JSON) is text.
APIs speak text.
Humans can read text.

This paradigm conquered the world. The cloud runs on it. The mobile world (iOS and Android) runs on it. macOS runs on it. Even Windows adopted the Unix file paradigm (hierarchical byte streams) early in its history.

Unix is not the genetic ancestor of all modern systems (though it is that for many), but it is the spiritual ancestor: Unix built the civilization that all modern computing lives within.

Notion is simulated composability

2025-11-20T02:47:56.000Z

Notion is a marvel. It feels powerful because it is. You can drag a database into a page, turn a list into a Kanban board, and link everything together. It feels like building.

But it's a trap.

Notion teaches you that building means assembling pre-made parts. It's simulated composability. Like Lego, the standard is in the joint. The pieces snap together perfectly, but only where the designer put a stud. You can build a castle, but not a real castle.

The composition space is bounded by the designed interface. You are playing in their sandbox, with their physics.

Real building happens in the open world.

In the open world — text files, code, programmatic interfaces — the standard is in the substrate. Because the substrate (text) is universal, you don't need pre-defined slots. The connection isn't a permission granted by the object; it's an operation you perform on the material. You can grep, pipe, script, and transform anything.

Simulated composability is safer. It has training wheels. But training wheels don't teach you to balance—they teach you to lean. You learn to rely on the provided stability instead of creating your own.

If you want to build something the designer didn't anticipate, you need a machine shop, not a Lego set.

Open-world vs closed-world composability

2025-11-19T07:40:00.000Z

Composability is a phenomenon with a scope.

Some systems have constrained scope — closed-world composability, like a closed market:

Notion blocks snap together within Notion's sandbox
IKEA furniture pieces fit together in approved ways
Lego bricks build anything, but only Lego-compatible structures

Bounded composition space. Constrained to approved affordances.

Other systems have large or unbounded scope — open-world composability, like an open market:

Text files: any tool can read and write them, no vendor permission needed
Unix pipes: combine any programs that speak text
Lumber: build anything physics allows

Unbounded composition space. Any tool can participate without permission.

The difference is who controls the composition space.

Closed-world systems give you pieces and rules for combining them. You can build impressive things, but only within the boundaries the system defines.

Open-world systems give you substrate that any tool can work with. The composition space isn't bounded by what one vendor imagined. It's bounded by what's logically possible and what the actors in the ecosystem create.

Open-world systems have greater potential for exponential growth because the number of possible combinations grows with every new tool that can participate, not just with the combinations the original designer anticipated. More participants → more combinations → more network effects → combinatorial explosion.

Disruptive vs sustaining innovations

2025-11-18T08:57:49.000Z

Disruption is defined in retrospect: disruptive innovations are those that disrupted.

Clayton Christensen's famous line of inquiry asked why well-run companies get disrupted by new technologies. By studying cases of disruption, he hoped to identify advance signals that managers in established companies could use to avoid disruption, or that startups could use to foster it.

Between the initial article and his death in 2020, Christensen refined his model many times. The core characteristics he identified were:

Sustaining innovations

Common - the vast majority
Improve existing products on dimensions customers already value
Can be radical or incremental - doesn't matter
Established competitors almost always win

Disruptive innovations

Rare
Start worse on traditional performance metrics
Cheaper, simpler, smaller, more convenient
Target nonconsumers or overserved low-end customers
Different value proposition
Established firms rationally ignore them

Limitations and usefulness

Christensen wanted these signals to predict disruption in advance, but it hasn't really worked. Perhaps that's because patterns, once identified, are learned by the next generation of business managers, who avoid getting disrupted for the old reasons and instead get disrupted for new ones.

If that's the case, then it should still benefit the manager to gain familiarity with all the old patterns. Practice in this line of thinking may help one to avoid or foster disruption.

From Clayton Christensen 1997 - The Innovator's Dilemma

technology, as used in this book, means the processes by which an organization transforms labor, capital, materials, and information into products and services of greater value

Innovation refers to a change in one of these technologies.

there is a strategically important distinction between what I call sustaining technologies and those that are disruptive. These concepts are very different from the incremental-versus-radical distinction that has characterized many studies of this problem.

Sustaining versus Disruptive Technologies
Most new technologies foster improved product performance. I call these sustaining technologies. Some sustaining technologies can be discontinuous or radical in character, while others are of an incremental nature. What all sustaining technologies have in common is that they improve the performance of established products, along the dimensions of performance that mainstream customers in major markets have historically valued. Most technological advances in a given industry are sustaining in character. An important finding revealed in this book is that rarely have even the most radically difficult sustaining technologies precipitated the failure of leading firms.

Occasionally, however, disruptive technologies emerge: innovations that result in worse product performance, at least in the near-term. Ironically, in each of the instances studied in this book, it was disruptive technology that precipitated the leading firms' failure.

Disruptive technologies bring to a market a very different value proposition than had been available previously. Generally, disruptive technologies underperform established products in mainstream markets. But they have other features that a few fringe (and generally new) customers value. Products based on disruptive technologies are typically cheaper, simpler, smaller, and, frequently, more convenient to use.

Programmatic interfaces vs graphical user interfaces (GUIs)

2025-11-15T02:30:00.000Z

Two ways to interface with software:

Programmatic interfaces

Interface through code, commands, text
Examples: command-line (CLI), APIs, stdin/stdout, SELECT * FROM users
Requires BYO mental model: interface doesn't educate, expects you to know what's possible
Used by: humans (developers) AND machines (scripts, automation, AI)
Not accessible to non-technical people
Might have help or man pages, but minimal — the interface executes, doesn't teach

Graphical User Interfaces (GUIs)

Interface through visual elements — buttons, windows, menus, forms, frames
Examples: Google Docs, MarioKart, this website
Present a model: visual menu of affordances, skeuomorphic metaphors (desktop, folders, trash)
Used by: humans (point, click, drag, type)
Machines CAN use them (screen scraping, AI computer use) but it's clunky and far behind agentic programmatic computer use
Self-educating: can show up knowing little, learn by exploring

AI is a universal GUI to programmatic tools

2025-11-14T05:52:40.000Z

Though programmatic interfaces are generally more powerful than GUIs, they also have a steeper learning curve. They do not present a welcoming visual metaphor and menu of affordances. The user has to come pre-supplied with a mental model and sense of what's possible. That's why GUIs have been so popular.

Language models change the game. Everyone knows how to chat, and language models know (or will soon know) how to use every programmatic tool.

AI speaks two languages: natural language to you, technical syntax to tools

You describe what you want in conversation
AI translates that into commands: grep, git, API calls, etc

AI is a universal GUI to programmatic tools

Anyone can interface with AI through conversation
AI can interface with any programmatic tool
This means anyone can now access any programmatic tool
The entire developer stack - git, grep, APIs, command-line tools, file manipulation - opens up to non-developers

You can learn and build at the same time

AI is also a capable tutor
Ask as you go, at whatever level you're at. "How do I build a website?" "What's a commit?" "How do I cd into a folder?"

The barrier is ingenuity, not syntax fluency

Old requirement: Know the commands before you can use the tools
New requirement: Conversational fluency + willingness to explore unfamiliar territory
If you can describe what you want and ask "what does that mean?" when you don't understand - you can do this.

More people can access the programmatic stack

Not everyone - still requires curiosity, confidence to try new tools, comfort with the unknown
But anyone with those traits can now access the powerful layer that was previously developer-only

Software engineers prefer programmatic interfaces

2025-11-13T07:00:00.000Z

Software engineers often prefer programmatic interfaces because they offer greater control.

Software that has no graphical user interface is sometimes called "headless"

The "head" is the GUI - buttons, windows, forms, visual interface
Headless tools don't have that layer. Their interface is text.
Examples: Terminal commands (stdin/stdout, text streams), APIs (HTTP requests/responses, JSON, text protocols)

Developers are fluent in programmatic environments

Git for version control, grep for searching, Docker for containers, APIs and calling them — all text-based
IDEs are GUI tools, but designed for headless-native developers — they integrate terminals, expose git commands, and keep the text layer accessible

Programmatic interfaces were first

Before GUIs existed (60s and 70s), this was the only option. Not enough computing power for graphical interfaces even if they'd been invented.
GUIs came later as a translation layer for non-technical users
Developers never switched because the direct interface remained more powerful

Programmatic is powerful

Headless is where full capabilities are accessible
When you click a button in a GUI, it's always calling some underlying programmatic interface — a command-line tool, a library API, a system call, etc. The headless layer is always underneath.
To the non-developer the headless tool seems barren, limited, sparse.
To the developer the GUI feels like a middleman. Sometimes helpful, often not.
Working headless means you're operating at a more foundational layer. Not the lowest layer (machine code), but the layer that GUIs are built on top of.

Programmatic interfaces require BYO mental model

A GUI is a visual menu of affordances. It presents a model, often using skeuomorphic metaphors. The user can show up knowing little and learn on the fly.
Headless tools require that the user show up with a mental model not supplied by the interface. You need to already have a good sense of what's possible.
That learning curve limited adoption by non-developers

What is a design provocation?

2025-11-12T05:49:31.000Z

A design provocation is a prompt that stimulates you to explore novel areas of solution space. A good one will lead to solutions better than those previously known.

A connotation of 'provoke' is that when someone is provoked they might go too far. A design provocation might make you go too far.

"Provocation: You have to do the whole thing in 1 month."
"Provocation: You can't use words at all."

The result of going too far is that you have expanded the Overton window of the design space you're exploring for solutions. If it worked, the best solution will now be within the boundaries of the space you are exploring.

Another connotation of 'provoke' is emotional arousal. A good design provocation wakes something up in you and brings more of your emotional resources to bear on the problem.

Provocations can be framed as a question ("What if we had to do it in 1 month?") or as an imperative ("Provocation: We have to do it in 1 month"). The imperative form is often more provocative.

What makes a good one

They're good when, in retrospect, they helped us find a better solution. Often this better solution was an interpolation between the wild ideas generated by the exercise and the orthodox ideas we started with. The design provocation helped us get there.

They're not so good when they had us exploring areas that weren't fruitful. A design provocation could be, "It has to be 100% purple." For most projects, that's not going to turn out to be useful.

It's not fully decidable in advance whether a provocation is going be good. You have to pick one based on experience and intuition. You'll find out in the end whether it worked.

How to generate them

Some approaches:

1. Radical amplification - Notice something desirable (characteristic X), propose it radically

"Provocation: It has to take zero clicks."
"Provocation: We won't listen to that guy at all."
"Provocation: The goal is that kids prefer it over going on vacation."
"Provocation: That number has to be 100x bigger."
"Provocation: We're building the best one in the world."
"Provocation: We have to do it in 1 month."

2. Inversion - What would destroy the product or tank the business?

"Provocation: Our goal is to destroy user trust."
"Provocation: We want this to be super aggravating to use."

3. Lateral thinking - Reframe the problem entirely

"What if we had to solve the problem in a completely different way?"
"Provocation: The problem isn't a problem at all."
"Provocation: The real problem is our way of conceptualizing this."

4. Personas - Channel someone else's perspective

"Provocation: We approach this like Steve Jobs would."
"Provocation: We do what Jesus would do."

5. Feelings first - Start with the emotional response you want

"Provocation: The goal is that I feel joy when I use this."

6. Crazy ideas - Remove all constraints

"What if we solved this in the most batshit way possible?"
"What if we had a magic wand and could [xyz, eg, have unlimited engineering resources]?"

7. Artifacts - Reference existing solutions

"Provocation: It has to be like [artifact]."
"Provocation: We employ the same method the [artifact] creators used."

Unix files are computing's shipping containers

2025-11-11T06:00:00.000Z

The Unix file and the intermodal container both represent format-agnostic, standardized interfaces that enabled revolutionary levels of interoperability.

Malcolm McLean's shipping containers standardized physical cargo handling by making the contents irrelevant to the transportation system—a 20-foot or 40-foot steel box with standard corner fittings could contain anything and move seamlessly across ships, trains, and trucks.

In 1969 Ken Thompson implemented Unix files as formatless byte streams — a universal envelope that didn't require declaring type or size at file creation. Unix files standardized data handling by making the contents irrelevant to the system — files moved seamlessly through pipes, filters, and programs. See AT&T engineer Catherine Ann Brooks describe the system in 1982: https://youtu.be/XvDZLjaCJuw?si=CesJuFNqUYATWSyr&t=667

Both innovations solved similar problems: the proliferation of incompatible formats that prevented efficient composition and transfer. Before shipping containers, different cargo types required specialized handling and couldn't easily transfer between transportation modes. Before Unix's byte stream abstraction, different file formats required specialized programs and couldn't easily compose through pipelines. Both solutions involved imposing a universal, neutral interface that pushed format-specific knowledge to the edges of the system.

Both innovations achieved transformative results, and both required ecosystem-wide adoption to realize their full value.

Footnote: Docker Inc. analogizes its containers to the intermodal container. The metaphor is apt, but arguably, the Unix file was more transformative.

The Unix scene

2025-11-08T04:15:00.000Z

Unix was a scene.

Date	Event	Unix scene members	Unix-influenced users
1966	Thompson joins Bell Labs. Unix doesn't exist yet.	0	0
1965-1969	Thompson and Ritchie work on Multics project at Bell Labs (joint project with MIT and GE).	0 (not Unix yet)	0
1969	Bell Labs withdraws from Multics project.	0	0
1969 (summer)	Thompson writes Space Travel game on PDP-7, designs simple file system.	~2	~2
1970	First running Unix system (Thompson + Ritchie). Name changes from "Unics" to "Unix".	~3	~3
1971	First Edition Unix released internally at Bell Labs. Small group using it: Thompson, Ritchie, McIlroy, few others in the research group.	~12	~15
1972	Ritchie begins developing C language. Unix group at Bell Labs growing - more researchers adopting it.	~30	~75
1973 (summer)	Unix rewritten in C (makes it portable). McIlroy suggests pipes, Thompson implements in one night. Philosophy crystallizes.	~60	~150
1973	Fourth Edition Unix. Being presented at conferences. Papers published. Philosophy getting articulated.	~100	~300
1974-1975	AT&T begins distributing to universities (nearly free, with source code). Berkeley gets it.	~300	~1,500
1975	First USENIX conference (40 attendees, 20 institutions). Community infrastructure begins forming.	~400	~2,000
1978	First BSD (Berkeley Software Distribution) release (30 copies distributed). Growing university adoption.	~900	~4,500
1979	Seventh Edition Unix (V7). Widely considered the most important Unix.	~1,500	~7,500
1980	Usenet begins. Community infrastructure emerges - people can share code and discussions asynchronously.	~2,000	~12,000
1983	TCP/IP added to BSD (4.2BSD). BSD development accelerates. Unix becomes the internet OS.	~7,500	~75,000
1983	AT&T System V Release 1. AT&T commercializes Unix. Scene begins fragmenting between commercial Unix and BSD.	~10,000	~150,000
1984	45,000 Unix systems installed, 940 Usenet hosts. Scene thriving but fragmenting.	~15,000	~300,000
1985	Microsoft Windows 1.0 released. Not Unix-based (runs on top of DOS).	~40,000	~2M
1985-1988	PEAK. USENIX conferences draw ~3K attendees. CS degrees peak at 42K/year. Scene at maximum size but losing coherence.	~40,000	~2M
1988	Unix Wars begin. Rival consortia form (OSF vs Unix International). Scene fragmenting into incompatible camps.	Fragmenting	~4M
1989	NeXTSTEP released by Steve Jobs' NeXT Computer. Unix-based (BSD foundation).	~45,000 (fragmenting)	~4M
1991	Linux kernel first released by Linus Torvalds. Unix-like but not Unix. Free and open source. NEW scene begins, separate from Unix.	Unix: ~20,000, Linux/BSD: ~300	~15M
1993	Windows NT released. Not Unix. Begins Microsoft's dominance in corporate computing. Commercial Unix systems (Solaris, HP-UX, AIX) start declining.	Unix: ~15,000, Linux/BSD: ~3,000	~30M
1995	Windows 95 released. Huge commercial success. Not Unix. Unix becomes increasingly niche in desktop/consumer markets. Original Unix scene dissolves - BSD CSRG closes after 20 years.	Unix scene ended, Linux/BSD: ~30,000	~40M
1997	Apple acquires NeXT. NeXTSTEP becomes foundation for future macOS.	Unix: ~7,500, Linux/BSD: ~75,000	~65M
2001	Mac OS X released. Unix-based (BSD + NeXTSTEP). First mainstream consumer Unix.	Unix: ~7,500, Linux/BSD: ~500,000	~125M
2007	iPhone released. Runs iOS, which is based on macOS (thus Unix-based). Unix in billions of pockets, users unaware.	Unix: ~10,000, Linux/BSD: ~2M	~300M
2008	Android released. Based on Linux kernel.	Unix: ~10,000, Linux/BSD: ~3M	~750M
2014-2015	Unix DNA reaches billions of users via smartphones. Most people use Unix-descended systems daily without knowing.	Unix: ~10,000, Linux/BSD: ~8M	~2.5B
2025	Today. Commercial Unix systems (Solaris, HP-UX, AIX) nearly extinct. Replaced by Linux in enterprise, macOS in consumer/creative markets, Windows in corporate. Original Unix scene dissolved - descendants (Linux, macOS) dominate computing but are too large/diffuse to be a "scene".	Unix: ~10,000, Linux/BSD: ~10M	~6.5B

The scene dissolved, but The Unix philosophy won — it's everywhere. Most servers run Linux. Macs and iPhones run Unix. Android runs Linux. Windows is the outlier. Today most of humanity uses Unix-descended systems.

Scene

2025-11-08T00:50:00.000Z

A scene is a social-cultural formation around some shared interest/practice/aesthetic.

Characteristics of a "scene":

Critical mass but not dominance - More than a few people, less than mainstream. "There's a real scene for X" means it's active and vibrant, not that everyone's doing it.
Recognizability - People in the scene recognize each other. You can tell who's "in" the scene. Not formalized membership, but you know it when you see it.
Shared values/aesthetics - Not just doing the same thing, but having similar sensibilities about HOW and WHY to do it.
Informal networks - Not an organization, no official membership. People know people, information flows, things get shared.
Cultural artifacts - The scene produces things: music, zines, code, writing, events. The artifacts carry the scene's DNA.
Generativity - A good scene generates new work, new people, new variations. It's alive, not static.

Examples:

Punk rock scene (70s-80s): shared venues, DIY ethic, recognizable aesthetic
Early web scene (90s): personal sites, webrings, shared ethos about open web
Indie game dev scene (now): itch.io, GDC, shared values about creative independence
Local-first scene (now): Ink & Switch, CRDTs, Obsidian, file-over-app, sovereignty values

Note: "Scene" was also a specific music subculture in the mid-2000s (MySpace era, post-hardcore aesthetic). The term came from general music slang ("being on the scene") but became the proper name for that specific group. I'm using scene in the general sense.

The Unix philosophy

2025-11-07T06:05:52.000Z

Unix was an operating system created at Bell Labs in the late 60s and early 70s. Before Unix, creator Ken Thompson worked on Multics — a system designed to do everything. The ultimate monolith. Thomson found it hard to learn and not fun to use. He hated it, and Bell Labs eventually abandoned it. Watch him talk about it in a recent oral history: https://youtu.be/OmVHkL0IWk4?si=nQAcSy6LE1VY5iiu&t=4687

The Unix philosophy was a response.¹

In its most famous statement: "Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."²

1. Small programs that do one thing well

Not one giant program with all features
Many focused tools instead
grep only searches text. sort only sorts lines. cat only concatenates files.
Each tool is simple, understandable, good at its job
You can learn each tool independently

2. Programs work together (composability)

Tools compose via pipes and text streams
The output of one becomes the input to another
Complex operations build up from simple pieces
Clean, simple interfaces between components (text in, text out)

3. Text streams as universal interface

Everything speaks the same language (text)
Any tool can connect to any other tool
This is what makes composition work
"Everything is a file" — even devices and processes expose text interfaces

Footnotes:

¹ The Unix philosophy emerged in practice before it was formalized in linguistic maxims. An important early articulation came from Doug McIlroy, inventor of Unix pipes, in the Bell System Technical Journal in 1978 — nine years after Unix began. He wrote:

A number of maxims have gained currency among the builders and users of the UNIX system to explain and promote its characteristic style:

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features."

Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.

Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.

Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

Illustrations of these maxims are legion:

Surprising to outsiders is the fact that UNIX compilers produce no listings: printing can be done better and more flexibly by a separate program.

Unexpected uses of files abound: programs may be compiled to be run and also typeset to be published in a book from the same text without human intervention; text intended for publication serves as grist for statistical studies of English to help in data compression or cryptography; mailing lists turn into maps. The prevalence of free-format text, even in "data" files, makes the text-processing utilities useful for many strictly data processing functions such as shuffling fields, counting, or collating.

The UNIX system and the C language themselves evolved by deliberate steps from early working models that had at most a few man-months invested in them. Both have been fully recoded several times by the same people who designed them, with as much mechanical aid as possible.

The use of tools instead of labor is nicely illustrated by typesetting. When a paper needs a new layout for some reason, the typographic conventions for paragraphs, subheadings, etc. are entered in one place, then the paper is run off in the new shape without retyping a single word.

² Peter H. Salus, A Quarter-Century of Unix (1994).

Monolithic vs composable

2025-11-06T04:14:18.000Z

Two different philosophies for building systems with large capabilities.

Monolithic approach

Build one giant system that does everything
All functionality integrated inside the system
Your data lives inside it
Proprietary formats internal to the system
No interchange format (or very limited - maybe an API, maybe export)
User works entirely within the monolith
Examples: Notion (tries to be notes + database + wiki + project management), Salesforce (giant integrated CRM), Adobe Creative Cloud (integrated suite with proprietary formats), 60s mainframe systems

Composable approach

Build many small tools that each do one thing well
Tools work together via standard interchange formats
Your data lives in files that any tool can access
Open formats (text, markdown, etc)
Files/text streams are the universal interchange format
User controls how tools compose
Examples: Unix tools (grep, sed, awk, git), markdown files (write in any editor), Git, Obsidian (works with files on your filesystem)

The tradeoffs

Monolithic systems can be easier initially — everything is integrated, works together out of the box, consistent interface.

Composable systems require more initial setup but give you more control — you choose your tools and customize them, create your own workflows, own your data in open formats. Over time, arguably, the ceiling is higher.

Local is faster

2025-11-05T06:21:00.000Z

Sometimes quantity has a quality all its own.

Every task has a speed requirement and a latency. At some threshold, the time it takes to complete the task exceeds the time available, and the task becomes impossible.

For example, how much typing latency do you think you'd tolerate? A fifth of a second (200 ms)? A fiftieth (20 ms)? Make your guess and then find out: https://aresluna.org/keyboard-secrets/typing-delay/

Local operations tend to be faster than those requiring communication with a remote resource. Here's Peter Norvig's famous list of times every beginning programmer should know (circa 2012):

Operation	Latency
execute typical instruction	1 nanosec
fetch from L1 cache memory	0.5 nanosec
branch misprediction	5 nanosec
fetch from L2 cache memory	7 nanosec
Mutex lock/unlock	25 nanosec
fetch from main memory	100 nanosec
send 2K bytes over 1Gbps network	20,000 nanosec
read 1MB sequentially from memory	250,000 nanosec
fetch from new disk location (seek)	8,000,000 nanosec
read 1MB sequentially from disk	20,000,000 nanosec
send packet US to Europe and back	150,000,000 nanosec

Recall Douglas Engelbart's 1968 collaborative editing demo, the "mother of all demos", in which multiple editors at terminals connected to a mainframe worked on the same document.

Imagine that the mainframe was in Europe while the terminals were in the California SRI building. Each keystroke would be one round trip: terminal sends signal to Europe (75ms), mainframe processes and sends back (75ms). Total: 150ms per keystroke.

In the typing latency demo above, my threshold of perception is about 10ms; my threshold of tolerability is about 30ms. 150ms feels like typing in sand.

In Engelbart's actual setup, which had a dumb terminal and the mainframe in the same building, latency was imperceptible — likely under 10ms. The collaborative editing task worked because operations were local.

This principle is ubiquitous. Tasks that work at one latency become impossible at another.

Consider a program manager in a software company who learns to code not to write production software, but to enable real-time thinking. Suppose he's in a conversation with an engineer, and his goal is to bring clarity to a plan for building a component. The engineer is being vague. If the program manager can think based on his own local knowledge about how such a component will work, he can ask focused questions and propose reasonable approximations. If not, he can only depend on what he gets from the engineer. The software engineering knowledge is available to him, just not locally. To utilize it he'd have to say something like, "let me spend a couple weeks reading up on this, then I can make some reasonable approximations." The latency makes the collaborative planning impossible.

Local is faster. Sometimes that's nice to have, sometimes it's a sine qua non.

Local is constrained

2025-11-04T04:36:00.000Z

The local-first computing movement arose as a corrective to cloud dependence. Keep your data on your device, work offline, own your data and your software. All good things.

But local is constrained. Your local machine has limited storage and compute. You can't store all of the web locally. The hardware you can buy is only as capable as the state of the art today.

So practically speaking you cannot do everything locally that you might want. And for some operations, remote is actually preferred, even if you did have all the storage/compute/data/money in the world locally.

Consider AI models. You'd prefer to run them locally. Lower latency, no API costs, works offline, guaranteed privacy. But even if you could get the frontier labs to give you their model weights, your laptop certainly doesn't have the juice to run frontier models locally. And you probably don't want to buy (and carry around) a machine beefy enough to get close. Economically it makes sense for the inference to run in a hyperscaler's datacenter.

Consider backups. You could store your backups locally. A local backup protects against software failures. But if your computer blows up, your local backup blows up too. The value you actually want — protection from catastrophic loss — requires offsite storage. The best backup service is remote. Geographic separation is the feature.

Consider document collaboration. When you collaborate with someone else, they are remote to you. Local multiplayer — two people working on the same machine — is an edge case. Remote collaboration is what's wanted. It's inherently remote.

Local gives you real benefits — speed, offline access, control, privacy. But sometimes remote is a practical necessity, and sometimes it's the actual benefit.