Serendipity35

There is a particular kind of quiet that settles over a terminal window at 8 a.m. on a Tuesday when you are the only person on earth who can see what is happening on the other end of it. No support ticket. No status page to refresh. Just you, a config file, and a decision about who, exactly, gets to talk to the thing you just built.

I spent part of this morning doing precisely that — flipping a setting called `gateway.bind` from `loopback` to `lan`, watching a self-signed certificate mint itself into existence, and approving a device pairing request from my own phone as if I were a bouncer checking my own ID at a door I installed myself. It is, by any reasonable measure, boring infrastructure work. And it is also, I have come to think, one small answer to a question my Serendipity35 co-conspirator Ken raised in this space a few months back in 'Your AI Is Not Free'"?: if free AI makes you the product, what does *running your own* make you?

Most people's relationship with artificial intelligence today is one of tenancy, not ownership. You open ChatGPT, or Claude.ai, or the Gemini app, and you are a guest in someone else's skyscraper — a very nice skyscraper, with excellent amenities, but a skyscraper nonetheless, and the lease terms are the landlord's to write and rewrite. Your prompts, your corrections, your half-finished thoughts typed in at midnight: all of it lives on servers you will never see, governed by a privacy policy you almost certainly didn't read past the second paragraph. "Free" is a business model, not a gift, and Ken said as much in this space not long ago.

OpenClaw — the open-source project I've been quietly building on both my Mac Studio and my nexttroll.com domain this week — offers a different architecture, and it is worth walking through precisely because the architecture is the point. You run the gateway process yourself. You supply your own API keys to whichever model you choose to pay for — Anthropic, Google, whoever earns your dollar this quarter — and you pay for compute the way you pay for electricity, metered and legible, rather than a flat-rate subscription that obscures what any single conversation actually cost. Your logs, your memory files, your configuration: all of it sits as plain files on a disk I can `ls` myself, not as an abstraction behind someone else's login screen.

There is a second piece of this worth dwelling on, because it is the part that actually excited me: **Skills**. In a cloud AI product, the vendor decides what the assistant is allowed to do, and you are notified of new capabilities the way you are notified of app updates — after the fact, and without a vote. In OpenClaw, a Skill is a modular, inspectable procedure — a little packaged competence — that you add, edit, or write outright. You are not a user of a product anymore. You are closer to being the systems administrator of a very small, very personal machine — which, if you have read this blog for any length of time, you will recognize as exactly the seat I have always preferred.

None of the actual sovereignty here lives in anything glamorous. It lives in bind modes, auth tokens, TLS certificates, device pairing approvals — the unglamorous plumbing that determines who can reach your AI and what it is permitted to see. I spent a genuinely irritating stretch of this morning discovering that a browser will flatly refuse to hand over "device identity" to anything served over plain HTTP from a LAN address, because modern WebCrypto requires what's called a secure context, and no amount of arguing with a curl command changes that. The fix — self-signed TLS, a certificate warning to click through, a pairing request to approve — was ten minutes of real friction. It was also, I noticed afterward, the first time all week I understood *exactly* why a piece of software was refusing me, rather than just accepting that it had.

That, I think, is the actual shape of "AI democracy" here — and I want to be precise about what I mean by it, because it is not a claim that everyone will run an identical assistant, or that we're all about to become network engineers. It means the tools required to configure and own a working AI assistant no longer live exclusively behind a computer science degree or a corporate badge. The barrier moved. It used to be technical. Now it is largely a matter of persistence — a willingness to sit through the boring, occasionally maddening reps of learning why a thing is broken before you can fix it. I have written before about training a 5K at seventy: nobody hands you the fitness. You do the unglamorous mileage, and it accrues.

I'll concede the honest caveats, because a post that skips them isn't worth the pixels. This is real effort, not a weekend hobby — there were dead ends this week, a Rust compiler grinding through hundreds of crates in the background the whole time as a reminder that not everything gets easier. And this is not full independence, whatever the word "sovereignty" might suggest. I am still, at the end of the day, paying Anthropic for the actual intelligence doing the thinking; I have relocated the boundary of control, not abolished my dependence on a large company entirely. Self-hosting an AI gateway doesn't make you off the grid. It makes you legible to yourself, which is a smaller and more honest promise.

There's an irony sitting underneath all of this that I don't want to paper over: the assistant that helped me research and draft this very post — reading through nineteen pages of my own back catalog to get the voice roughly right, checking a Gemini API key against my own config, watching a build compile in the background — is the same private, locally-configured AI this post is about. I did not write every sentence above; I directed the machine that wrote most of them, on hardware I own, with API keys I hold, in a conversation that will live in a file on my own disk when we're done. Consider this piece Exhibit A, not just an argument.

So — not an answer, but a question worth carrying to your own terminal, wherever it happens to sit: if you actually knew, with certainty, where your last conversation with an AI physically lived — whose disk, whose jurisdiction, whose future data breach — would you have said anything differently to it?

 

David Pogue on Substack writes that "When you do a Google search these days, you generally see an AI Overview panel above the search results. It’s intended to summarize the answers to your query, so you don’t have to click any links. The first problem: By Google’s own calculations, the AI Overviews are incorrect 28% of the time. The bigger problem: AI is an environmental disaster. It’s already a monstrous energy hog, and its appetite is doubling every six months."

 He gives some data about this data center power situation:

• 4,200 data centers that AI companies have built and 1,500 more are going up as you read this
• By 2030, AI will consume 945 terawatt-hours of electricity. That is enough to power every household in California, Texas, Florida, New York, Ohio, and Pennsylvania combined. Almost incomprehensible.
• 60% of that power will come from polluting power sources.
• Don’t care about the environment? How about your power bill? AI’s power needs have driven up electricity costs as much as 15% in the last year, with another 8.5% hike coming by the end of 2026.
• Add in more rolling blackouts during heat waves this summer.

But it’s not just Google, because almost every big company is eager to add AI to their products.

Pogue's note of hope is that a few people, like Sheila Morovati, are trying to make AI optional. Morovati is the founder and president of a nonprofit called HabitsofWaste.org. Her movement is called Opt-In AI with a goal of no AI at all unless someone asks for it. The default setting should be the most sustainable and least annoying option.

More at Rise Up, People! Make AI Optional! - David Pogue

 

There is a distinct, sharp flavor to the air at 7:00 AM on a race morning. It is an eclectic mix of adrenaline, Icy-Hot, and the squeak of synthetic race bibs. But last weekend, standing on a wooden riser an hour after the start with two other finishers, the air felt a bit different. For the first time in fourteen years, I was back on the podium.

At age 70, standing there with an age-group award hanging around my neck, my mind did what it always did after decades spent in operating systems, development and design--it looked to the Dev process, and the Prod result. Fourteen years is an eternity in the technology sector. Fourteen years ago, the cloud was a novel corporate transition, deep learning was mostly academic, and the smartphone was just beginning to corral us all into interpersonal isolation.

I spent my career trying to ride the rocket of overwhelming technical information or, at least, watch where it was headed. But as I caught my breath and looked down at my silver medal, I realized that the grueling, quiet process of training for a 5K road race at seventy is perhaps the most perfect metaphor we have for coping with the relentless acceleration of modern information technology.

When you are 25, you can run a 5K on raw talent and a bad diet. I did. You can sprint, redline your heart rate, and force your way to the finish line through sheer kinetic stubbornness.

When you train at 70, sprinting is a fast track to a torn quad or a zillion other structural failures. You learn to respect your physiological redline even if it is maddeningly slow. You focus heavily on pacing, aerobic threshold, and efficient energy expenditure. You make the effort and run as hard as you ever might have run --you just don't go as fast anymore.

The tech world operates in a state of permanent sprint. Every week brings a large language model, a new framework, or an interface that threatens to render yesterday's skills obsolete. If you try to sprint after every single shiny object in the tech ecosystem, you will suffer cognitive burnout. Coping with tech acceleration requires us to embrace our aerobic base of lifelong learning--choosing a sustainable pacing strategy over frantic, reactive sprinting.

In my IT days, I spent time on optimization--making sure old code could run on new infrastructure, new code could run in a legacy environment, or that software upgrades didn't brick any of those resources.

Training a 70-year-old body is an intense exercise in refactoring. The joints are stiffer, muscle mass naturally declines, and recovery loops take twice as long. The default settings of your youth are, at best, just an annoying memory. You have to actively invest in mobility work, strength training, and strict recovery cycles just to maintain baseline performance. Your stopwatch now records time more like a calendar.

Navigating modern IT infrastructure requires us to consciously refactor our mind. The user interfaces of today don't look like the command lines or desktop environments we grew up configuring. To be functional, we have to deliberately loosen our rigid mental models, accept that our personal processing speed has changed, and invest in assistive technology in our environments.

Fourteen years ago, my running report card was inside a cheap Casio runners watch. Today, my wrist is strapped to a device that tracks VO2 max, heart rate variability, stride power, and sleep architecture. In training mode, this unrelenting device excoriates me out loud for being "Too Slow," "Too Fast" (really rarely that one), or "Pace within target range" as I lumber along.

The data is only useful if you know how to filter the signal from the noise. If I noticed every minor dip in my training metrics, I would never lace up my shoes. I had to learn which data mattered for long-term durability and which data were just distractions.

The acceleration of technology has created an information flood. We are bombarded with notifications, algorithmic opinions, and an endless stream of digital noise. Coping doesn't mean disconnecting entirely; it means developing strict personal filtering protocols. It means knowing which metrics actually improve your digital life and ignoring the rest.

Standing on that podium, I looked at the younger runners finishing behind (the few) and ahead (the many) of me. In running, as in technology, it is easy to look at the speed of the world around you and feel a creeping sense of obsolescence. Endurance sports, though, reveal a beautiful truth: the race is both intensely communal and deeply solitary. You are running with the pack, and share their energy--but you are ultimately executing your own race plan.

The tech revolution can leave older generations feeling like technology spectators as younger digital natives zoom all around them. But my return to the podium reminded me that experience compounds. Fourteen years of absence didn't mean I lost the ability to compete; it meant I had fourteen years of accrued wisdom regarding pacing, emotional resilience, and consistency fighting against old-age decline.

We don't need to write the algorithms to benefit from them, nor do we need to build the networks to find meaningful space within them. We just have to stay on the course, run our race, and remember that if you stay consistent long enough, the finish line will provide its own rewards.

---

Fifty years ago, a pair of college dropouts named Steve Jobs and Steve Wozniak fundamentally shifted human history. The significance of 1976 to Apple Computers cannot be overstated: it was the literal ground zero of the personal computing revolution. On April 1, 1976, Apple Computer was formed, and by July, the duo unveiled the Apple I at the Homebrew Computer Club. Selling for a diabolical $666.66, the Apple I was just a bare motherboard. But it funded Wozniak’s next masterpiece: the 1977 Apple II, a fully realized, consumer-friendly machine featuring color graphics, expansion slots, and an integrated keyboard.

Fast forward to July 14–19, 2026. While modern Apple users await iterative upgrades to sleek aluminum slabs, retrocomputing diehards are descending upon the University of Illinois Springfield for KansasFest (KFest) 2026. Now in its 38th consecutive year, KFest remains the ultimate pilgrimage for hackers, programmers, and enthusiasts keeping the 8-bit dream alive.

This year’s convention is a historic milestone, marking the 40th anniversary of the Apple IIGS, the 16-bit pinnacle of the Apple II line released in 1986.The event features a packed schedule of legendary guests, collaborative hackathons, and hardware swap meets:In-Person Keynote: Apple Employee #12, Dan Kottke, is headlining the event live to share stories from the foundational garage days of Apple. Dan Hillman, the engineer who co-led the development of the Mega II chip (which squeezed an entire Apple IIe onto a single piece of silicon), is making a rare virtual appearance.

The Global Gathering: For those unable to travel to Illinois, KFest 2026 is also hosting an official virtual-only weekend event on July 31 – August 1, 2026.

A History Born of Crisis...

KFest wasn't always an independent nonprofit. It originally launched in 1989 as an official Apple II developers' conference organized by Resource Central, a publisher of Apple II magazines. When Apple decided to completely discontinue the Apple IIGS in late 1992 and the final Apple IIe in November 1993, corporate support evaporated. The market plummeted, and Resource Central faced a severe financial crisis by 1995. This (Low-Def) video was thought to be of the last ever KFest.