Dispatches¶

What Randy Pausch's The Last Lecture Still Teaches Us Still

Some books comfort you. Others hold up a mirror.

The Last Lecture by Randy Pausch does a little of both.

Pausch was a computer science professor at Carnegie Mellon University. In 2006, he was diagnosed with pancreatic cancer. By September 18, 2007, after learning the cancer had returned and that he had only months left to live, he gave his now-famous lecture, "Really Achieving Your Childhood Dreams."

The talk became a book, but the real reason it endures is simpler than its title suggests:

That distinction matters. A lot of writing about mortality becomes soft around the edges. Pausch did something better. He stayed funny, practical, and honest about disappointment, work, family, and the ways adults drift from what once made them feel alive.

Today, him words feel especially clarifying because modern life is crowded with noise. We optimize calendars, answer messages at red lights, and confuse urgency with importance. We get very efficient at moving and very unclear about where we are going.

Pausch's voice cuts through that. He keeps asking a hard, useful question:

Ubuntu 26.04: How to Upgrade from 24.04 LTS

Ubuntu 26.04 LTS, Resolute Raccoon, was officially released on April 23, 2026.

If you're like me and want to upgrade now, here's a clean step-by-step process to do it on both Ubuntu Desktop and Ubuntu Server.

Before the Upgrade

Before you begin the upgrade, review the following checklist.

1. Back up anything you care about.
2. If the system is a VM, take a snapshot.
3. Make sure the current 24.04 LTS install is fully patched.
4. Make sure you have enough free disk space.
5. Be prepared to answer interactive prompts during the upgrade.

On Ubuntu Server, I would also review any third-party repositories or PPAs before you start. They are a common source of upgrade friction, and Ubuntu may disable them during the release upgrade anyway.

Update the current system first:

sudo apt update
sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo reboot

EditorConfig Deep Dive: Syntax, Properties, and Best Practices

Every shared repository eventually rediscovers the same avoidable argument: tabs or spaces, LF or CRLF, trim trailing whitespace or leave it alone, final newline or not. None of these questions are hard. They are just repetitive, noisy, and surprisingly good at wasting review time.

EditorConfig exists to move those decisions out of personal editor settings and into the repository itself. It is a simple, cross-editor standard for defining basic text file formatting rules so contributors using different editors and IDEs still save files in a consistent way.

This matters more than style bikeshedding. Inconsistent indentation creates ugly diffs. Inconsistent line endings break shell scripts and CI jobs. Trailing whitespace produces review noise that hides the change you actually care about. EditorConfig is not glamorous, but it solves a class of problems that should stay boring.

This guide covers how EditorConfig works, the syntax of .editorconfig files, the standard properties you can rely on, where editor support stands, and how to build a practical starter template for a modern repository.

Validity and Consequence

The porch light flickered in the stagnant heat.

"Well, that didn't feel a bit of good. What was you aimin' for with that?" I said, my skin prickling under the weight of her stare. "What were you aimin' for?"

I felt the hackles rise like a dog backed into a corner of the yard.

"Reckon you could find a different way to say your piece?" I stammered.

She spat into the dust, her eyes as cold and gray as a dry creek bed.

"Your feelin's are valid," she said, her voice a low rattle. "But your feelin's are your own, and I ain't sayin' they're wrong. Tho the way you went and acted on 'em sure is. Just 'cause you’re bleedin' don't give you the right to stain my floors."

The screen door slapped shut behind her.

Linux Kernel Sets Rules for AI-Generated Code

AI coding assistants were always going to force this conversation eventually. Tools like Copilot, ChatGPT, and Claude can draft code quickly, explain unfamiliar sections, and help contributors move through a patch faster than they could on their own. That is useful. It is also exactly the kind of shift that was bound to run into the Linux kernel's standards around trust, review, authorship, and licensing.

The kernel is not a project where code gets merged because it looks plausible. It is a project where contributors are expected to understand what they send, defend it under review, and stand behind it legally and technically. That is what makes the new guidance on AI-generated and tool-generated contributions worth paying attention to.

Signal vs. Noise

I can lose twenty minutes in the space between one text message and putting my phone back down. It starts innocently enough: a quick reply, a glance at a notification, one email that looks like it might matter. Then a chat badge catches my eye, a tab is still open from earlier, something needs clearing, something else looks interesting, and suddenly I am standing in the middle of my own day wondering where time went.

That is the strange part about modern distraction. It rarely feels dramatic while it is happening. It feels ordinary. A buzz on the phone. A red dot on an app. A message that might need a reply. A scroll that promises to take only a second. Most of it is small enough to justify in the moment, but together it becomes a weather system.

Lately, I have been trying to separate what is asking for my attention from what deserves it.

Noise is the stuff that asks for my attention without earning it. It is the constant stream of alerts, chat notifications, text messages, newsletters I do not remember signing up for, promotional emails pretending to be useful, app badges, algorithmic feeds, and the endless scroll that turns curiosity into a kind of low-grade drift. Noise is not always bad in isolation. Sometimes it is funny, interesting, or even useful. Sometimes it is a person I care about, reaching out for a perfectly good reason. The problem is not that every interruption is worthless. The problem is that everything now arrives with the confidence of something urgent.

Signal is quieter. It is deep work that needs a little room before it opens up. It is an unhurried conversation with someone I love. It is reading something that changes the shape of my thinking. It is being present with my family, making something with my hands, going for a walk, writing, learning, listening, or simply letting my mind be still long enough to notice what I have been carrying.

The signal usually does not shout. That is why I have to protect it.

39N

Use 1Password SSH Agent for SSH Keys and Git

If you already trust 1Password with API keys, database passwords, and tokens, your SSH keys are the next obvious secret to get out of ~/.ssh/. The 1Password SSH agent lets OpenSSH and Git use keys stored in your vault instead of private key files on disk, which makes day-to-day Git authentication cleaner without turning your home directory into a small museum of long-lived keys.

The important nuance is this: the op CLI is part of the workflow, but the actual SSH agent is provided by the 1Password desktop app. That matters because it keeps the model honest:

• 1Password stores the private key item
• The desktop app brokers SSH authentication
• OpenSSH talks to the 1Password agent
• Git keeps using SSH exactly the way it always has

If you are already using 1Password for local development secrets, this is the same idea applied to Git access. The application code stays boring, the SSH client stays boring, and the secret moves into the vault where it belongs. If your main goal is application secrets rather than Git access, the companion post is Use 1Password CLI for Local Development.

Use 1Password CLI for Local Development

If your local development workflow still depends on .env files full of live credentials, you are not doing configuration management, you are just normalizing secret sprawl. The 1Password CLI, op, gives you a better model: keep secrets in a vault, inject them into a child process only when needed, and let your terminal stay fast without turning your laptop into a plaintext key dump.

This post is intentionally about local development only. No CI runners, no GitHub Actions, no Kubernetes side quests. Just a developer workstation, a terminal, and a sane way to run Python, Go, PowerShell, Zsh, and Bash without leaving credentials all over the filesystem.

After MkDocs 1.x: Fragmentation, Risk, and What Comes Next

For more than a decade, MkDocs, especially when paired with Material for MkDocs, became the default answer for engineering documentation. It was simple enough for technical writers, familiar to Python-centric platform teams, and polished enough that most organizations never needed to build a documentation frontend of their own. That consensus has now fractured. As of 2026, teams still running MkDocs 1.x are no longer just choosing a mature stack, they're accepting a growing maintenance, compatibility, and software supply chain risk.

MkDocs earned its position because it solved the right problem at the right level of complexity. It gave teams a straightforward content model, a single configuration file, a Python packaging story that fit naturally into existing developer environments, and a clean separation between content, theme, and deployment. Material for MkDocs then raised the ceiling dramatically. Search, dark mode, responsive navigation, blog support, admonitions, tabs, code annotations, and a broad plugin ecosystem turned what began as a documentation generator into a complete publishing stack.

For engineering organizations, that combination was unusually efficient:

• Technical writers could stay in Markdown.
• Engineers could treat docs like any other Git-based project.
• Platform teams could build and deploy sites with the same CI pipelines used elsewhere.
• Open-source programs could publish polished public documentation without standing up a custom app.

In practice, MkDocs plus Material became the reference architecture for documentation in many Python-centric and infrastructure-heavy teams. It wasn't the only option, but it was often the least controversial one.