Bonus Drop #115 (2026-05-03): Terminal Velocity

OpenWarp; Macterm; rootshell; Rio; Foot

The awesome Ghostty got lib-ified and since then, it seems like there has been an explosion in new terminals (not all associated with libghostty). So we’ll talk about terminals today (with an attempt to not have them all be Mac-focused).

I used to say you’d pry WezTerm from my frostbitten Maine winter hands, but I already strayed and leaned into Kaku (a WezTerm fork that is adding a bit too much “AI” into it for my comfort level), so I’m now playing the terminal field for a while.

OpenWarp

This section is short since there’s no “just download this release image” yet, for it, and I cannot recommend folks do the bootstrapping necessary to try to get the community fork of the Warp browser working for them right now (you have to do some things that are as bad as — or worse than — sudo-curl-bash).

I mention it since it was news to a bunch of folks on Mastodon, and having a verison of Warp that doesn’t involve the Warp gaining access to any intellectual property or secrets you put into a terminal session seems like A Good Thing™.

If you don’t know what Warp is, it’s a true reimagining of “the terminal”, except that it involved them getting all your keystrokes, and the shoved a bunch of “AI” into it.

Provided the community releases are decent and highly configurable, it’ll be nice to re-test-out said reimagining again.

Macterm

Macterm is a native macOS terminal emulator/multiplexer built in SwiftUI that wraps libghostty as its terminal rendering backend, adding a thin project management layer on top.

It’s written almost entirely in Swift (97%) and targets macOS 26.0+. It recently migrated from Swift Package Manager to an Xcode project structure with Icon Composer assets. The build tooling uses the epic mise for task running, and they have swiftlint and swiftformat in the workflow. Tests recently migrated from XCTest to Swift Testing (the newer framework Apple introduced). So, if you were looking for a great macOS project to read through and emulate, this would be it.

So, about that multiplexing and workspace management layer… The app ships with a vertical project sidebar for organizing terminal sessions, unlimited split panes (horizontal/vertical with auto-tiling) — which is a lie b/c you are most certanly limited by screen real estate — persistent project/tab/pane state that survives restarts, a global “quick terminal” hotkey, a command palette for project management, and hot-reloadable config for themes/fonts/keymaps (and, I’m hoping that the config options — espcially fonts — get more robust, soon).

If you are averse to using anything that has had an assit from “AI”, then (a) abandon all Ghostty-related terminals, because it uses coding agents, and (b) don’t use this one since Claude is definitely a co-contributor.

Since it wraps libghostty you get a ton of crunchy goodness in an app that feels and looks like a real macOS app.

I’ve been using it for a few weeks for project work, but I have not stopped using Kaku (yet).

rootshell

Rootshell is free terminal emulator targeting iOS, iPadOS, macOS, and visionOS. Once more: AI Vegans might want to look away from this section.

The rendering engine is (unsurprsingly) libghostty and the SSH client is pure Swift with zero external dependencies; no libssh2 wrapper and no bundled OpenSSH binary. This implementation gets y’all jump host support, per-request agent forwarding approval granularity, and Keychain-stored credentials (yes, this is another macOS-only thing). Post-quantum crypto via ML-KEM hybrid key exchange and ML-DSA host key signatures is included, which is further along than most desktop SSH clients bother to be.

Session persistence – branded “Rootshell Roam” – is Mosh-compatible with STUN-based NAT traversal, and the transport layer supports QUIC (TLS 1.3) and KCP (AES-GCM-256) via tssh integration. Sessions survive app termination and reboots, and Multipath TCP handles WiFi-to-cellular handover without dropping your connection (sorry Linux folks, please show me your equivaelent?). The SSH VPN feature routes all device traffic through sshd over any of those transports – no server-side software beyond standard sshd needed – with Home Screen widgets, Dynamic Island integration, and Siri intents for connect/disconnect.

The local shell on iOS goes further than I’d expected: SFTP, SCP, curl with HTTP/2, jq, bat, native git via libgit2, Vim 9.2, the Helix editor with tree-sitter, and network tools (mtr, traceroute, ping with AS lookups) that work without a remote host. There’s also an (IGNORE-ABLE) AI agent layer with Claude, ChatGPT, and Gemini support that attaches to SSH/mosh/tssh sessions, a WebSocket voice agent via Gemini Flash, and an MCP server so Claude Code can execute commands through the app. Hardware key support covers YubiKey PIV, FIDO2, and Secure Enclave over NFC or USB-C, with keys staying on-device.

Quick pseudo-aside: there’s no visible monetization path here, which is worth keeping in mind if you’re thinking about depending on it for production workflows.

The pure-Swift SSH reimplementation is the thing I’d want to think hardest about. Reimplementing SSH from scratch is a significant attack surface to get right, and an independent security audit of the stack doesn’t appear to exist yet. The PQ crypto additions are forward-looking but also newer code paths. If you’re SSHing into lab boxes and personal servers, the tradeoff looks pretty favorable. If you’re routing production access through it from day one, you’d want to weigh that more carefully. I’ve been putting it through paces on some home lab connections and it’s held up well – the QUIC transport in particular feels notably snappier on flaky mobile connections than vanilla SSH over TCP.

Install it and kick the tyres if you spend any time managing infrastructure from a phone or tablet. The local shell alone makes it useful even when you’re not connecting anywhere.

Rio

Rio (GH) is a GPU-accelerated terminal emulator written in Rust by Raphael Amorim that uses WebGPU (via wgpu) for rendering instead of the OpenGL or Metal paths you’ll find in Ghostty, Kitty, or Alacritty. On Linux it renders through Vulkan; on macOS it goes through Metal; on Windows it uses DirectX 12. The WebGPU abstraction layer is the super cool architectural choice here — it gives Rio a single rendering backend that maps to whatever the platform’s best GPU API happens to be, and it opens the door to running in a browser via WebAssembly (which Rio actually supports, though it’s more proof-of-concept than daily-driver territory).

The feature set is mid-pack for a modern GPU terminal. You get splits, tabs, ligatures, true color, Sixel and Kitty image protocol support, and configurable themes with transparency and optional background blur. Rio also supports RetroArch shader files for CRT-style aesthetics, which is either a neat trick or a gimmick depending on how you feel about scanlines. Configuration is TOML-based with no GUI preferences panel — you edit the file, Rio picks up changes. The current release is v0.2.37 (March 2026), and the project has been iterating steadily since its first release in 2023. It works on both Wayland and X11.

Rio does borrow heavily from Alacritty’s internals (the ANSI parser, event system, and grid implementation are acknowledged in the repo), and it hasn’t yet differentiated itself enough from the pack to make a compelling case for switching if you’re already settled on Ghostty, Kitty, or Alacritty. The WebGPU angle is definitely interesting but hasn’t translated into a measurable performance advantage — most benchmarks put Rio in the middle of the field. It’s a solo maintainer project (Raphael is candid about it being a side project with limited free time as a new parent), so the pace of development reflects that. The project is 100% worth watching if the WebGPU/WASM trajectory interests you, but it’s not the terminal I’d point someone toward if they just want the best Linux terminal experience today.

Foot

Foot is a Wayland-native terminal emulator written in C by Daniel Eklöf that takes a deliberately contrarian position in the GPU-accelerated terminal arms race: it doesn’t use the GPU at all. Foot does CPU-side software rendering and submits frames directly to the Wayland compositor. The result is a terminal with lower input latency and a smaller memory footprint than most of its GPU-accelerated competitors. Eklöf has written detailed benchmarks showing that, for typical terminal workloads, the overhead of setting up a GPU rendering pipeline actually costs more than it saves — the compositor is already doing the final compositing on the GPU anyway.

The latest release (March 2026) added a toplevel-tag option for the new xdg-toplevel-tag-v1 Wayland protocol (useful for compositor-side session management and window rules), split the color config into separate [colors-dark] and [colors-light] sections (replacing the old [colors]/[colors2]), 4-directional padding support, and preliminary background blur via the ext-background-effect-v1 protocol. The project also improved compatibility with Mutter/GNOME by adding virtual modifier support in keyboard events, which fixed several keybinding issues when running foot under GNOME’s Wayland session.

Foot’s server/client architecture is its most distinctive feature. You run foot --server once (typically at compositor login via systemd socket activation), then launch terminals with footclient. Every window shares the server’s loaded fonts and glyph cache, so subsequent terminals start near-instantly with minimal additional memory. The tradeoff is that all windows multiplex I/O on one thread (each gets its own rendering threads), and a server crash takes every window with it. URL handling is keyboard-driven rather than mouse-driven: Ctrl+Shift+O enters URL mode, where visible URLs get jump labels you type to activate. No tabs, no splits, no session management — foot explicitly delegates all of that to your compositor or tmux.

If you’re running Sway, Hyprland, River, or any tiling Wayland compositor, foot is purpose-built for your environment. It’s the default terminal in several Wayland-centric distros for good reason. The “no GPU” stance might sound like a limitation, but for the actual task of rendering monospaced text in a terminal, it turns out to be the right call more often than not.

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:

🐘 Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
🦋 Bluesky via https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy

☮️