Zack Bartel

Tether: Linux + iPhone

Sun, 23 Aug 2026 00:00:00 +0000

I didn't miss macOS, but...

When I went to Linux full time I was surprised to not miss much from macOS.

tldr; I made Tether to do all the things I did miss.

No AirPlay kinda sucked, but the one thing I kept wishing I had was what Apple calls "Continuity": the ability to send and receive iMessages and SMS, share files, sync clipboard, and see notifications from my iPhone on my computer.

In particular, that thing where OTP codes sent to Mail or Messages autofill into the login form I'm waiting for on the Mac. It sounds small, but that was the one thing I really missed!

It is impossible to fully implement all of Continuity on Linux, but Tether's goal is to do all of it that is technically possible.

Before you ask, I know KDE Connect exists. It's great! If you're on Android you should definitely use it. The problem is that it didn't do what I wanted and it's roadmap indicated it never would.

Origins

Tether started its life filling the major holes. Clipboard sync was first, I wanted the OTP flow and I knew this was going to be required, and it was also the easiest. This let me copy / paste between macOS and Linux (Wayland) and forced the project to build out all the foundation I knew it would need later.

I knew the App Store was going to be a hurdle so I shipped the iOS app first with only support for clipboard sync. There was a very basic tetherd daemon for the linux side but that was it.

Security was a first class citizen from day one.

I never skipped out on safety. The networking between iOS and Linux has been mTLS from the start, and both sides must agree before anything can communicate. Since then I've done Opus and then Fable bug / security sweeps regularly.

After that, file transfer was the obvious next step and that went in quick and easy.

Wat

As for mail and browser stuff, I'm not very creative. To be honest I've kinda cheated here. I use Zen Browser (Firefox) and Betterbird (Thunderbird) and both support WebExtensions very well. So, I just made a browser and mail extension to deal with OTP stuff.

The mail extension looks for OTP codes and sends them to the browser extension which looks for OTP input elements and autofills OTP codes as they arrive from mail.

It actually works great! The problem is broad support: if you use a different mail client you're kinda out of luck for now. I'd LOVE if someone wants to help with that stuff, but it's so far out of my comfort that I'll stick with the backend side for now.

Bluetooth Breakthrough

My understanding to this point was that there was no interface to iMessage / SMS directly. You could always run a proxy on a Mac and send and receive texts through that, but in my opinion that is not a solution. I tried it. Even with Tailscale it was an unpleasant experience.

Then I ran across ancs4linux and later BlueFerry and I was completely shocked. In particular, erikwb's protocol documentation, which finally gave me enough information to understand what was happening.

There was a licensing issue, these projects are GPL and Tether is and always will be MIT, but I wanted a clean room implementation in C++ anyway. Personally, I think putting an interoperability protocol implementation behind a copyleft license is a little unfortunate! I'd rather see something like this usable by anyone, regardless of the license of the project using it (libtether?).

Anyway, now that the truly hard problem was solved, implementation went about as smooth as you could expect a bluetooth integration would go (it's still a complete shit show in 2026). Problem after problem with no clear explanation, an automatic kicking machine, and a bunch of carefully tracked edge cases compensating for bluetooth's inadequacies.

But we got there.

And Tether now supports: iMessage, SMS, Notifications, Contact sync on Linux. In addition to its previous: File Transfer, Clipboard Sync, OTP handling.

And my damn text OTP codes FINALLY autofill in the web browser!

Why?

While I did scratch my own itch with this project, I genuinely want Tether to be for everyone. I don't get anything out of people using it other than the satisfaction of knowing that something I built is useful.

Contributions are welcome! Bugs, feature requests, translations, documentation, really anything would be wonderful.

If you're on Linux with an iPhone, I really hope you give it a try.

fenriz: A fast, stable tiling Wayland compositor

Sun, 19 Jul 2026 00:00:00 +0000

I wrote a Wayland compositor.

Yes, that's an unhinged thing to do. Hear me out.

I've been on Hyprland for a while and I want to be clear up front: it's fantastic. If you're a Linux power user, it's probably what you should be running. It does everything, it looks incredible, and the community is enormous. I recommend it to people all the time.

I just didn't want most of it. And it breaks too often.

The eye-candy tax

Hyprland's whole personality is the eye-candy, the blur, the bounce, the wobble, the buttery animation on every window open. It's genuinely beautiful and I turned all of it off. I don't want my windows to spring into place. I want them to be in place.

What I actually use is the boring part: tiling, floating, fullscreen, pinning, workspaces. The primitives. That's the whole compositor as far as I'm concerned, and it turns out the primitives are maybe five percent of what a modern compositor ships. I was paying the eye-candy tax, in animation frames and in config bloat, for features I actively disabled.

The other tax was breakage. The Hyprland ecosystem moves fast, which is great when you want the newest thing and less great when a routine update changes a config key out from under you and your bar or your idle daemon stops working for a few days. I don't really want the new fancy, I want the cool old thing that works, and I want it to keep working.

The clamshell thing

Here's the one that finally broke me: clamshell mode. Laptop, external monitor, shut the lid. The internal panel should turn off, the windows should stay where they are, and opening the lid should put everything back. That's it. That's the whole feature.

I could never get it to work right on Hyprland. Not for lack of trying, I had a script for it that sometimes worked. Hyprland broke their config (again) so then I had a hundred-line Lua script for it, with a debounce token written to a temp file because a single suspend/resume fires enough monitor events to reload my shell three times. It reads /proc to check the lid. It juggles enable/disable across lid switches and hotplug and docking. And it still occasionally left me with a black internal screen or windows on the wrong monitor.

I'm not dunking on Hyprland here. Search "hyprland clamshell" and you'll find a dozen people with a dozen different scripts, all slightly broken in different ways. It's a genuinely hard problem to bolt on from the outside. But I decided the right place to solve it was inside the compositor, where you actually own the output state, instead of in a Lua script racing against event storms.

fenriz

So I wrote fenriz. It's a small, fast tiling Wayland compositor built on wlroots and SceneFX. Dwindle tiling, floating, fullscreen, pinning, per-window rules, ten workspaces, a Hyprland-style config file, and a small IPC socket for status bars. It reads your config, tiles your windows, and otherwise does nothing you didn't ask for.

That's it in action, running my Quickshell setup for the bar, with vim open on fenriz's own source. Thin borders, no blur, no bounce. The windows are just there.

And clamshell works. It's not a script and there's nothing to configure. Each workspace lives on an output; when a screen goes away - lid, cable, suspend - its workspaces move to a surviving screen with layout and focus intact, and slide back when it returns. The internal panel turns off when the lid shuts with an external connected, and back on otherwise. Suspend-on-lid is left to logind, which already gets it right. I open and close my laptop lid all day and never think about it, which is exactly how much I want to think about it.

Should you use it?

Probably not, honestly. Use Hyprland. It's more capable than fenriz in every direction that isn't "boot up, tile some windows, close the lid, don't break." It has a real community and it isn't maintained by one d00d.

But in the meantime I have the compositor I always wanted. It does exactly what I want and nothing else, and I have full control. It's my daily driver. It hasn't surprised me yet. My config hasn't broken once :)

I am way open to feedback if anyone is actually interested in using it. It's a small codebase and I can make changes quickly. If you want to try it, here's the repo.

Quickshell Takes Over, Don't Be Like Me

Sat, 18 Jul 2026 00:00:00 +0000

I deleted my whole desktop and rebuilt it.

Not the compositor. That one I already built. I mean everything sitting on top of it: the bar, the launcher, notifications, the wallpaper, the idle timer, the lock screen, the polkit agent, bluetooth, clipboard history. All of it. It's now one Quickshell config, and I regret nothing.

The pile

Here's what a normal, sane Hyprland setup looks like, and what I was running until recently:

waybar for the bar
rofi / wofi for the launcher
swaync for notifications
hyprpaper for the wallpaper
hypridle for the idle timer
hyprlock for the lock screen
hyprpolkitagent for polkit prompts
hyprwat for menus (I wrote that one)
bluetui / blueman for bluetooth
cliphist for clipboard history

Every one of these is good software. Most of them are great. I'd recommend any of them to a friend. The problem was never any single tool, the problem was that I had ten of them, each with its own config format, its own theme file, its own idea of what a rounded corner should look like, and its own update that breaks on a Tuesday.

Themeing that pile so it looks like one coherent thing is a part-time job. You change your accent color and you're editing a CSS file, a Lua-ish config, three INI files, and a YAML document, and afterwards the notification daemon still looks like it wandered in from a different operating system.

Here's the launcher, my rofi/wofi replacement. Fuzzy app search with frecency ranking, an inline calculator, an address book, clipboard history, all behind one keybind:

And the wallpaper picker, because of course I replaced hyprpaper too:

One design language

That was the real itch. I didn't want ten tools that mostly match. I wanted one Theme.qml where I change a color and the entire desktop changes with it, the bar, the launcher, the lock screen, the OSD, all of it, because they're all the same program drawing to the same screen.

Quickshell makes that possible. It's a QML host for building your desktop shell out of Wayland protocols directly, no scripting a bar to shell out to nmcli and parse the output with awk. The battery widget talks to UPower. The network widget talks to NetworkManager over D-Bus. The lock screen speaks ext-session-lock-v1. The idle timer uses ext-idle-notify-v1 and actually honors inhibitors, so fullscreen video doesn't dim on me mid-movie. It's the real protocols, not a pile of scripts pretending to be an integration.

Here's the bar and the control center. Bar across the top, everything in one place:

And because it's all one program, the accent color is derived from the wallpaper. Swap the wallpaper and the whole desktop, bar, launcher, control center, bluetooth menu, follows it. Purple background, purple UI. Change to a green one and the launcher goes green too:

The stuff that was annoyingly hard

Two things did not want to be replaced.

The lock screen was the big one. I wanted my fingerprint and my password to work at the same time, so I could swipe a finger or just type. Turns out a single stacked PAM service runs its modules one after another, which is exactly what produces that miserable "press Enter to fall through to the fingerprint reader" dance. The fix was two separate PAM services, one per auth method, run concurrently. Obvious in hindsight. Not obvious at 1am.

The other was idle inhibition. Quickshell can't own the org.freedesktop.ScreenSaver D-Bus name that windowed browser video uses to say "don't sleep," so I wrote a small Go daemon that does. It brokers the inhibits, ignores audio-only ones, captures clipboard selections too, and exits when the shell exits. That's the one piece of glue I couldn't avoid, and honestly it was fun to write.

Should you do this?

No.

Every tool I replaced is maintained by people who are better at it than I am, and if it breaks, they fix it. Now when my desktop breaks, the person who fixes it is me, at 1am, with a fingerprint reader that won't cooperate. I signed up for that maintenance bill on purpose, because I like knowing exactly how my computer works and I like everything looking like it belongs together.

But if you just want a nice desktop that works, use the pile. It's a great pile.

Don't be like me.

C++ is Great (again)!

Mon, 24 Nov 2025 00:00:00 +0000

C is my favorite programming language.

It always has been and probably always will be. It allowed me to build cool stuff at a young age, create iOS and Mac software (via Objective-C), contribute to the Linux kernel, and work on embedded systems on airplanes.

When I first learned C++ in college, it was great. It was like having a super-charged version of C. Classes, inheritance, and polymorphism, it felt modern and powerful.

I last used C++ heavily around 2010. At that time the Template Metapocalypse was in full swing. That experience made me not like programming.

I was tired of dealing with the complexities. The syntax was verbose, error messages unusable, build systems a nightmare, and the community divided over best practices. I moved on to other languages: Go, Java/Scala, Swift, Python, Javascript, but I would often miss the power of C++.

Whenever I had to use JNI or some other FFI (Foreign Function Interface), I felt weak. I don't want to have to wait for some third-party library to bind to my favorite language. I want to write high-performance code directly. But at that time I just didn't feel like C++ was a reasonable choice.

C++11 was on the horizon, promising to fix many of the issues, but the complexity of the language had already scared off many developers.

I took a long break from C++.

Necessity is the mother of invention.

Fast forward to 2024, and I found myself needing to write some high-performance code for a project that couldn't tolerate garbage collection pauses. Python was too slow, Go's GC was unpredictable, and Rust's learning curve felt steep (and frankly I don't like it - Arc<Mutex<DeezNutz>>).

I reluctantly opened up a C++ project, expecting the same old frustrations. What I found instead was a revelation.

Modern C++ is a different language.

The C++ I discovered was not the C++ I had left behind. C++11, C++14, C++17, and C++20 had fundamentally transformed the language. The improvements weren't just incremental, they were transformative.

Auto type deduction means I'm no longer writing std::vector<std::string>::iterator everywhere. Now it's just auto. The compiler figures it out, and my code is cleaner and more maintainable. It feels like I'm writing Python, but with all the performance of C++.

Lambda functions changed everything about how I write callbacks and functional-style code. Before, I'd create a functor class or a separate function. Now I can write inline lambda expressions that capture variables from the surrounding scope. Threading code went from painful to pleasant.

Speaking of which, the standard threading library finally arrived. No more pthread or platform-specific APIs. std::thread, std::mutex, std::atomic—it's all there, cross-platform, and actually usable. I can write concurrent code that works on Windows, Linux, and Mac without conditional compilation everywhere.

But the feature that truly won me back was smart pointers. std::unique_ptr and std::shared_ptr eliminated most of my memory management headaches. No more agonizing over when to call delete. No more memory leaks from forgotten cleanup in error paths. RAII (Resource Acquisition Is Initialization) finally felt natural and automatic. I know there's a lot of RAII hate out there, but for me it's very natural and makes sense. If it doesn't for you, that's okay too.

// old way - error prone
Widget* w = new Widget();
// ... do stuff ...
delete w; // Did I remember? What if there was an exception?
// new way - automatic cleanup
auto w = std::make_unique<Widget>();
// ... do stuff ...
// automatically cleaned up, exception safe

The ecosystem caught up too.

It's not just the language. The tooling improved dramatically. CMake became tolerable. Package managers like Conan and vcpkg emerged. Compiler error messages, while still pretty bad, are lightyears better than the template error novels of 2010.

LSPs made code completion and navigation great. Clang format standardized code style. Sanitizers made debugging memory issues trivial. The whole development experience modernized. All of these things made editting code in nvim a joy.

AI assistants are a secret weapon.

Here's something unsurprising: AI coding assistants have made C++ significantly more approachable. Those cryptic template errors that used to send me down rabbit holes for hours? I paste them into Claude or ChatGPT and get a clear explanation and fix in seconds.

Writing boilerplate for move constructors, copy assignment operators (did i forget the third &?), or template specializations? The AI generates it correctly while I focus on the actual logic. Debugging subtle lifetime issues with references and pointers? The AI spots the problem I've been staring at for twenty minutes.

C++ has always had a steep learning curve with tons of gotchas: the rule of three, the rule of five, argument-dependent lookup, template SFINAE, undefined behavior landmines. AI assistants act like an expert pair programmer who knows all these pitfalls and helps you avoid them. They catch my mistakes before they cause the old headaches.

It's ironic: C++ became easier to write precisely when we got AI tools trained on decades of C++ code, patterns, and best practices. The accumulated wisdom of the C++ community is now available on-demand, making the language's complexity manageable in a way it never was before.

They still can't do the hard code, I recently wrote a Wayland + EGL backend for Dear ImGui and the AI was totally useless, but they handle the tedious stuff that used to make C++ a chore.

C++ is great again.

I'm writing C++ daily now, and I'm enjoying it. I never, ever would have thought I'd say that again. I am having fun, and getting excited about programming things I couldn't do in other languages.

The language gives me the control and performance I need without the tedious manual memory management and verbose boilerplate that drove me away. It's the super language and probably always will be.

Modern C++ found the sweet spot: it kept the zero-cost abstractions and raw power, but added the ergonomics that developers expect in 2024. It's not perfect of course, the language is still complex, and there's legacy baggage, but it's legitimately great.

If you walked away from C++ years ago, give it another look. You might be surprised at what you find.

If you wish you could learn C++ and harness its power without the frustrations, now is the time, fire up Antigravity and get going.

The king has reclaimed its throne.

Hyprwat: A Wayland native menu tool for Hyprland

Mon, 06 Oct 2025 00:00:00 +0000

What is Hyprwat?

Hyprwat is a menu tool designed specifically for Hyprland and Wayland compositor. It allows users to create and manage customizable menus that can be accessed directly from the Hyprland environment.

It creates a popup menu at your cursor position where you can select from a list of options. It also has built-in support for WiFi network selection, audio input/output device selection, wallpapers, and custom menus. Custom menus can be defined using simple YAML configuration files.

The name is inspired by some javascript bashing video I saw many years ago. But, also like "What do you need?"... because it's a menu tool.

Right now you can:

Create a list of key / value pairs that show up in a menu, the selected value is printed to stdout.
Create an input menu, where the user can type in a value that is printed to stdout.
Create password menu, where the user can type in a masked value that is printed to stdout.
Select from available WiFi networks (dbus + NetworkManager).
Select audio input/output devices (pipewire).
Select wallpaper (hyprpaper).
Create custom menus with a bunch of GUI controls using YAML configuration files.

What does it look like?

Integrate with powerprofilesctl to switch power profiles:

Change wallpapers and lockscreen:

Connect to wifi networks:

Why?

I created hyprwat to fill a gap in the Wayland ecosystem for a simple, flexible, and visually appealing menu system that can be easily integrated into various use cases. Particularly, for waybar I needed a menu selection for wifi networks, power profiles, pavcontrol, etc.

Then, I wanted an easier way to switch wallpapers and lockscreen and found the existing solutions too hard, so I just added it into hyprwat. I'll keep doing this, it's fun.

My first attempt used SDL2/3 and ImGui, but I didn't like the menu being a window (there's no layer shell support in SDL). So I rewrote it using pure Wayland protocols and EGL for rendering.

If nothing else it's a pretty cool cpp wrapper for Wayland protocols.

Returning to Linux

Wed, 05 Feb 2025 00:00:00 +0000

Mac OS X is getting worse

Update: Liquid Glass is awful, and the number of bugs in all of Apple's platforms is no longer acceptable. My 2017 iMac Pro was working fine for what I needed. Yes, it's old but for what I do (edit C code in vim, play chess online) it was great. But after installing Tahoe it's noticeably slower, buggier, and plaqued with permission popus and "unexpected error" dialogs. My Apple TV is annoying now, there are too many clicks to do anything, it's slower, the remote stopped working correctly. My watch is slower, battery life worse, again with the UI taking more taps to do what I used to be able to do. Hopefully the post-Allan Dye era will be a renaissance for Apple software like the post-Johny Ive era is for hardware.

Apple's hardware is by far the best on the market, but I feel the software has been deteriorating for some time. Gatekeeper is becoming more and more invasive, and the constant permissions dialogs are getting annoying.

For average users It's probably all for the better, but as a developer I no longer want to use a computer I can't make software (freely) for and share with people.

In addition, I feel I've become too reliant on iCloud and some other overpriced Apple services.

I love the Mac. Some of the most important software I've ever written was for Apple OSs. When Mac OS X first came out it seemed like the perfect OS. I was an Apple and Unix geek so it felt magical.

I Love Linux

I was a Linux desktop user for many years before switching to Mac OS X in 2009.

My dad and I installed a Redhat distribution with kernel version 1.1.0 around 1995, and I've been using Linux on and off ever since. As a kid, I was absolutely fascinated by the idea of open source software and the ability to modify and share code freely.

In college I worked at the OSU Open Source Lab, where I was introduced to ion3. I was instantly hooked on tiling window managers and used ion3 for years. This was the ultimate developer experience.

i use arch btw

After a completely unrelated need arose to have a Linux development environment, I decided to dip my toe in the water. I bought a $300 Acer laptop and installed Arch, and Kali (I work in cybersec).

The funniest thing about the whole process is how awful the pre-loaded Windows experience was. Their beloved OOBE experience is a joke. It took me hours to get the system into a usable state, and it was unusably slow.

Anyway, I missed ion3, tried i3 (it's not for me), and then found Hyprland. It's amazing. I can't believe how amazing it is. It is absolutely perfect for me. I can't impress upon you enough how amazing Hyprland is.

Hyprland did take days to setup, but that's what I wanted. Although, you can get up and running in a matter of minutes, tweaking everything to be just how I wanted it took a while. And (hopefully) I'll keep improving it forever. If you don't want that there are plenty of good alternatives (xfce).

The other thing is, this setup is SO FAST. Even on a budget laptop, everything is snappy and responsive.

A non-exhaustive list of things I use

Hyprland / Wayland (tiling window manager)
Ghostty (terminal)
Neovim (for everything)
hypr*
- hyprpaper
- hypridle
- hyprlock
Waybar (status bar)
Rofi (app launcher)
Thunderbird (email - I can't find anything better)
- aerc was pretty cool but there is way too much html email these days
Zen (browser)
Bitwarden (password manager)
Thunar (file manager)
A bunch of hacks to get iCloud CardDav and CalDav working

Anyway,

I'm back on Linux full time now, and I couldn't be happier. It's not just for developers anymore. time.Now().Format("2006") is the year of the Linux desktop.

Why I Stopped Trying to Improve at Chess

Tue, 14 Mar 2023 00:00:00 +0000

I've played chess off and on since I was a kid

I remember the excitement of learning the rules, beating my dad (he let me win), the thrill of my first rated victory, and the countless hours spent poring over strategies and tactics. Over the years, I reached a respectable level of play, competing in local tournaments and climbing the ranks.

However, as time went on, I found myself increasingly frustrated. The more I studied and practiced, the more I realized how much there was to learn. Chess is a game of infinite complexity, and no matter how hard I tried, I felt like I was hitting a ceiling. My progress slowed to a crawl, and the joy I once found in the game began to wane. What was really the kicker was when I hit an all-time high rating of 1895 (chess.com) and then promptly dropped back down to 1700 within a few weeks. It was disheartening to see my hard work seemingly unravel and never quite reach the heights I once had.

I was spending nights and weekends reading books, doing tactics puzzles, and analyzing games, but it felt like I was running in place. The more I learned, the more I realized how much I didn't know. It was a humbling experience, but also a frustrating one. I began to question whether the time and effort I was putting into chess was worth it.

Games weren't fun anymore; they felt like chores. I found myself dreading the start of a game, which used to be adrenaline filled excitement. The pressure to improve and perform well was taking the joy out of the game. I started to see chess as a source of stress rather than a source of enjoyment.

Then, one night I said "fuck it"

and decided to just blitz out a bunch of games. It made me realize that chess was supposed to be fun, not a source of frustration. I'm never going to be a grandmaster and I don't have to feel like I should aspire to that. I started playing for the sheer enjoyment of the game, without worrying about my rating or performance. I played casual games with friends, tried tricky and trappy gambits online, and simply enjoyed the process of playing. The thrill of finding a brilliancy, laughing at silly blunders that lost me games. I can't understate how upset I would typically get if I made a mistake and/or lost a game.

This realization reinvigorated my play. I once again look forward to starting a game, tough situations in the mid-game, king-and-pawn endgames. The joy for the game returned! I know I will probably not improve my rating much for the remainder of my playing days, but I really don't care. What I care about is being in a community of people who love the game as much as I do, and enjoying the process of playing. Chess is a beautiful game, and I'm grateful to have it in my life, even if I'm not the best player out there.

I love the English Opening

Thu, 05 May 2022 00:00:00 +0000

I fell out of love with 1.d4 and the London System.

I'll always have a soft spot for it in my heart as it's responsible for a lot of my early chess success. But I'm not a system player, and the London System felt like playing chess on autopilot.

On paper, it makes sense. Low theory, solid structure, you can play it against almost anything. Just put your pieces on their natural squares: Bf4, e3, Nf3, Nbd2, Bd3, c3 and then what? London players always fall down here.

I'd clawed my way up to around 1600, feeling pretty good about my chess. My London was solid, my Queen's Gambit sharp, and I could navigate the gambits well enough to stay out of danger. Then something shifted.

Once I reached a certain rating threshold everyone knew their theory. I would get crushed with 1.e4 by opponents who had memorized the best lines.

Suddenly, every opponent knew their theory cold. They'd rattle off the first fifteen moves without thinking. They'd steer me into playing their game. And I realized: I was spending more time memorizing opening lines than actually improving at chess.

I needed a change. But I wasn't about to become that guy.

Except it felt soulless. Every game looked the same. I wasn't responding to what my opponent was doing; I was just executing a setup regardless of what was happening on the other side of the board. It was chess on autopilot.

And the players I encountered who played the London? They had this glazed look in their eyes during the opening, like they were going through a checklist. "Bf4, check. E3, check. Nf3, check." No spark, no creativity, no actual chess decisions until move 15.

I distinctly remember sitting across from an opponent who played the London against my King's Indian setup, and I could see him mentally running through his system. He wasn't looking at my position. He was following a recipe. When I threw in an early ...Ne4 to disrupt his flow, he sat there for twenty minutes because he'd never actually learned to think in the opening. He'd only learned to deploy.

I refused to become that player. I'd rather memorize theory than give up on actually playing chess in the opening.

But there had to be a better way.

Hello 1.c4

That's when I discovered the English Opening, and it completely transformed my game.

The English Opening (1.c4) seemed almost too quiet when I first looked at it. After years of fighting for the center with 1.e4 or 1.d4, starting with a flank pawn felt... indirect? But then I started playing it, and I realized: this was everything the London pretended to be, but actually delivered.

The English gets you out of theory fast, not because you're ignoring your opponent's moves, but because you're creating unique positions they haven't memorized. There's no "English System" where you mindlessly deploy pieces to predetermined squares. Every game demands actual chess thinking from move one.

Why It Catches Everyone Off Guard

Here's the beautiful thing: most players at the club level have prepared something against 1.e4 and 1.d4. They've got their Sicilian or French or King's Indian or Nimzo-Indian ready to go.

But 1.c4? They pause. You can see it on their face. "Wait, what's he doing?"

They're out of their prep by move two. Not because you've done something gimmicky, but because the English is genuinely flexible and can transpose to many different structures. They can't just follow their memorized lines - they have to actually evaluate the position.

One of my favorite moments was against a 1900-rated player who clearly had a Najdorf repertoire memorized to move 25. After 1.c4, he thought for fifteen minutes on move one. He ended up playing 1...e5, we reached a Reversed Sicilian, and suddenly I was the one playing Sicilian structures (from the better side!) while he struggled with positions he'd never studied.

Aggressive or Positional: Your Choice

What really sold me on the English is its flexibility - and this is where it completely diverges from something like the London.

The London commits you to a specific structure and plan. You're playing for a slow positional squeeze almost every game. Sure, sometimes you get a kingside attack going, but you're fundamentally locked into a style.

The English? It can be whatever you need it to be.

Against a King's Indian setup, I can play the Botvinnik System (my favorite) with g3, Bg2, and Nc3, building for a slow positional grind where I control the center from afar.

Against a symmetrical structure (1.c4 c5), I can play aggressively with Nc3, g3, Bg2, e4!, blasting open the center and creating tactical complications.

Against the more classical setups with ...e5, I can reverse my beloved Sicilian structures and play for the same types of attacks my opponents used to play against me, except now I have an extra tempo.

The choice is mine. I'm responding to what's on the board, reading the position, making real chess decisions. You know, actually playing chess.

Getting Out of Theory, Into Chess

Here's the thing about theory: it's useful until it isn't. And at some point, every opening becomes about understanding ideas rather than memorizing moves.

The English forced me to understand chess rather than memorize it. Because there's no set "system," I had to learn:

How to control the center from a distance
When to break with d4 or e4 vs. when to keep the pawn structure fluid
How to evaluate transpositions (Is this Reversed Sicilian better than a normal one? Should I allow this transposition to a Queen's Gambit Declined?)
How to handle space disadvantages when opponents claim the center with ...e5 and ...d5

These are real chess skills. Pattern recognition, positional understanding, strategic thinking. Not "if he plays ...Na5, I play b4, and if he takes, I play a3." And it has made me a much better player overall.

The Freedom of Flexibility

Maybe the best part? No two English Opening games feel the same.

With the London, every game felt like déjà vu. Same structure, same pieces on the same squares, same middlegame ideas.

With the English, I might get a Reversed Dragon one game, a Hedgehog structure the next, a Symmetrical Variation the game after that, and occasionally it transposes into something completely different like a Catalan or Queen's Indian.

It keeps chess fresh. It keeps me engaged. And it keeps my opponents off-balance.

The Dirty Little Secret

Want to know the truth? The English has plenty of theory. There are whole books on the Symmetrical Variation alone. The Reversed Sicilian lines can get incredibly deep.

But here's the difference: your opponents haven't studied it.

At the club level, nearly everyone has studied the Open Sicilian or the Najdorf or the French Defense. Almost nobody has studied the Symmetrical English or the Reversed Dragon in depth. So even though theory exists, you're functionally out of book by move five.

And unlike the London, where being "out of book" just means you're playing generic moves, being out of book in the English means you're in rich, complex positions where understanding matters more than memory.

My Rating Thanks Me

Since switching to the English, my rating has climbed steadily. It didn't at first, I took a big hit, but in the long run it has gotten me farther than I think the London could have. More importantly, I've improved at chess in general.

I'm not winning because I memorized better lines. I'm winning because I'm making better decisions, understanding positions more deeply, and outplaying opponents in the middlegame.

The opening gets me to playable, interesting positions where both sides have chances. Then the game is decided by who understands chess better, not who memorized more theory the night before.

And I've avoided becoming a London player, which frankly might be the biggest victory of all.

Tired of Theory?

If you're facing the theory wall, if you're tired of memorizing, if you want to play chess instead of reciting it, give the English a try.

Just promise me one thing: don't treat it like the London. Don't look for a "system" you can play mindlessly. The English demands that you think, that you evaluate, that you respond to what your opponent is doing.

That's what makes it beautiful.

Start with 1.c4, follow basic opening principles, and see where the game takes you. You might be surprised at how much chess you've been missing while you were memorizing theory.

And you definitely won't end up with that glazed London System look in your eyes.

Kubernetes Loves Go

Tue, 18 Jan 2022 00:00:00 +0000

I've been working with Kubernetes and Go for years now. There's something deeply satisfying about this combination. Kubernetes gives you this incredibly powerful orchestration platform, and Go provides the perfect language to extend it. The two were made for each other, and nowhere is this more apparent than when you need a custom controller to solve a particularly gnarly scaling problem.

One Pod Per User

Our system had an unusual but deliberate architecture: one pod per user. Each user would "reserve" a pod for their exclusive use during a session. Think of it like a personalized sandbox environment, isolated, secure, and fully theirs.

There were a lot of challenges. These pods weren't instant. Startup time was significant enough that we couldn't just spin them up on-demand. Users expect immediate access, so we needed a pool of pre-warmed pods sitting ready to go.

Why Standard Scaling Wasn't Enough

My first attempt was using Kubernetes' Horizontal Pod Autoscaler with custom metrics from Prometheus. After all, that's what it's for, right? But as time went on it became clear that HPA wasn't sophisticated enough for what we needed.

Our scaling logic had to account for:

Time-based patterns: We needed different pool sizes at 2 PM versus 2 AM. User demand followed predictable daily rhythms.
Velocity and acceleration: A steady increase in reservations required different handling than a sudden spike. If someone tweeted a link to our service and we got a flood of new users, we needed to scale fast.
Smart pool management: The pool couldn't just be "any X pods." We needed to track which pods were reserved, which were ready, and which were warming up.

Standard metrics-based scaling gave us crude reactive behavior. We needed something predictive and loaded with business logic.

The Custom Controller

This is where Go and Kubernetes really shine together. I decided to build a custom controller (technically an operator, since it manages a custom resource) using the excellent controller-runtime library.

None of this is the actual code, but here's a simplified version.

The Custom Resource Definition

I wanted it to be cute, so I defined a CRD to represent our pod pool:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: podpools.scaling.example.com
spec:
  group: scaling.example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                minPoolSize:
                  type: integer
                  minimum: 0
                maxPoolSize:
                  type: integer
                  minimum: 1
                targetReadyPods:
                  type: integer
                  minimum: 0
                scaleUpVelocityThreshold:
                  type: number
                scaleUpAccelerationThreshold:
                  type: number
                timeBasedScaling:
                  type: array
                  items:
                    type: object
                    properties:
                      hourStart:
                        type: integer
                      hourEnd:
                        type: integer
                      targetPoolSize:
                        type: integer
                podTemplate:
                  type: object
                  x-kubernetes-preserve-unknown-fields: true
            status:
              type: object
              properties:
                readyPods:
                  type: integer
                reservedPods:
                  type: integer
                warmingPods:
                  type: integer
                currentVelocity:
                  type: number
                currentAcceleration:
                  type: number
                lastScaleTime:
                  type: string
                  format: date-time
  scope: Namespaced
  names:
    plural: podpools
    singular: podpool
    kind: PodPool
    shortNames:
    - pp

This CRD let us declare a PodPool resource with all the knobs I needed: time-based scaling windows, velocity thresholds, and the pod template to use.

The Controller Logic

The controller's reconciliation loop is the brain of the operation. Here's the core logic I implemented in Go:

func (r *PodPoolReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {

    // find the PodPool
    podPool := &scalingv1.PodPool{}
    if err := r.Get(ctx, req.NamespacedName, podPool); err != nil {
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }

    // list all pods managed by this pool
    pods := &corev1.PodList{}
    if err := r.List(ctx, pods, 
        client.InNamespace(req.Namespace),
        client.MatchingLabels{"pool": podPool.Name}); err != nil {
        return ctrl.Result{}, err
    }

    // pods by state
    ready, reserved, warming := r.categorizePods(pods.Items)

    // calculate reservation velocity and acceleration
    velocity, acceleration := r.calculateMetrics(podPool, len(reserved))

    // determine target pool size based on time of day
    targetSize := r.getTimeBasedTarget(podPool)

    // check for spike conditions
    if velocity > podPool.Spec.ScaleUpVelocityThreshold || 
       acceleration > podPool.Spec.ScaleUpAccelerationThreshold {
        targetSize = r.calculateSpikeTarget(targetSize, velocity, acceleration)
    }

    // scale the pool
    currentTotal := len(ready) + len(warming)
    if currentTotal < targetSize {
        r.scaleUp(ctx, podPool, targetSize-currentTotal)
    } else if currentTotal > targetSize && len(ready) > podPool.Spec.TargetReadyPods {
        r.scaleDown(ctx, podPool, ready[podPool.Spec.TargetReadyPods:])
    }

    // update state
    podPool.Status.ReadyPods = len(ready)
    podPool.Status.ReservedPods = len(reserved)
    podPool.Status.WarmingPods = len(warming)
    podPool.Status.CurrentVelocity = velocity
    podPool.Status.CurrentAcceleration = acceleration

    return ctrl.Result{RequeueAfter: 10 * time.Second}, r.Status().Update(ctx, podPool)
}

The beauty of this approach is that everything is declarative. I could define different scaling behaviors for different environments just by creating different PodPool resources.

Measuring Velocity and Acceleration

The most interesting part was tracking reservation velocity and acceleration. I kept a sliding window of reservation timestamps in the controller's memory (later moved to the PodPool status for persistence):

func (r *PodPoolReconciler) calculateMetrics(podPool *scalingv1.PodPool, currentReserved int) (float64, float64) {
    now := time.Now()

    // reservation history from status or cache
    history := r.getReservationHistory(podPool)

    // add current count
    history = append(history, ReservationDataPoint{
        Timestamp: now,
        Count: currentReserved,
    })

    // keep only last 5 minutes
    cutoff := now.Add(-5 * time.Minute)
    history = filterAfter(history, cutoff)

    // calculate velocity (reservations per minute)
    velocity := 0.0
    if len(history) >= 2 {
        deltaCount := history[len(history)-1].Count - history[0].Count
        deltaTime := history[len(history)-1].Timestamp.Sub(history[0].Timestamp).Minutes()
        velocity = float64(deltaCount) / deltaTime
    }

    // calculate acceleration (change in velocity)
    acceleration := 0.0
    if len(history) >= 3 {
        midpoint := len(history) / 2
        recentVelocity := calculateVelocityBetween(history[midpoint:])
        olderVelocity := calculateVelocityBetween(history[:midpoint])
        acceleration = recentVelocity - olderVelocity
    }

    return velocity, acceleration
}

This gave us real-time awareness of not just how many reservations were happening, but how fast the rate was changing. When acceleration spiked, we knew something unusual was happening and could preemptively scale.

The Results

The controller worked beautifully. During normal hours, the pool would smoothly adjust based on our time-based configuration. During the night, we'd have just enough pods to handle occasional use. During peak hours, the pool would be pre-scaled.

But the real magic happened during spikes. When (hypothetically) some CEO accidentally tweeted a direct link to our service, the controller would detect the acceleration in reservations and immediately start scaling up. The pool would stay ahead of demand.

Why I Love This Stack

This project exemplified everything I love about Kubernetes and Go together. Kubernetes provides this amazing extension mechanism through CRDs and controllers. It doesn't try to solve every problem. Instead, it gives you the tools to solve your own problems in a native, first-class way.

Go makes building these controllers almost effortless. The controller-runtime library handles all the boilerplate of watching resources, managing work queues, and handling retries. The type safety catches bugs at compile time. The standard library has everything you need. And the resulting binary is a single executable that's trivial to containerize and deploy. This is why I love Go.

I could have built a separate service that called the Kubernetes API to manage pods, but making it a proper operator meant it integrated seamlessly with the rest of our Kubernetes infrastructure. We could use kubectl to inspect pool status, GitOps to manage pool configurations, and RBAC to control access.

If you're working with Kubernetes and facing a scaling problem that doesn't fit the standard tools, don't be afraid to build a custom controller. With Go and controller-runtime, it's easier than you might think, and the results can be truly powerful.

Callout: The Boxing App

Mon, 17 Aug 2020 00:00:00 +0000

I started boxing when I was in high school. My football coach didn't want some of us to have too much free time on our hands during the winter, and I got my ass kicked in wrestling. So, he took us to the local gym and taught us the basics. I'd go on to compete in Golden Gloves, becoming a long time member of a local gym, and continuing the practice on and off into my 30s. Despite what you'd think, I've met some of the most compassionate and empatheic people in my life in boxing gyms. It's been a big part of my life.

Since I put the gloves down, I've wanted a better way to train at home. So much so that I actually wrote a C program to help.

What I really wanted was someone, or something to call out punch combinations during a "round".

Callout

So I wrote Callout - The Boxing App.

The idea is pretty simple, but nothing like it exists. You select or create punch combinations to be called during a round, and iOS SpeechSythesizer does the rest. You can customize the speed, rest time, and variance of combinations called. You can even create your own combinations.

It's available on the App Store for free with an in-app purchase to unlock all features.