This was a new challenge for me. A classroom full of adults all with that look -- the drift between eager to learn and anxious about learning.  I was the instructor in  a reskilling program at the Carnegie Library in New Jersey. My job was to teach web development to displaced workers who had spent years in jobs in factories and retail. Their faces told that displacement part well. They were all sitting in the left seat on the runway and they had no idea how to fly an airplane.

I've taught across the learning spectrum — computer newbies who couldn't find the power button, college sophomores writing their first iOS app, certification candidates cramming Open Source Unix for a credential, and mid-career professionals trying to recompile their job opportunities through code. Each group arrives on their stairway landing with different fears and different metaphors they use to make sense of the landscape. The fundamental transaction is always the same: a person on the edge of their competence, looking st a gap, and asking someone they barely know to help them build a bridge

When you teach a true beginner, you can't start with abstractions. You have to find the concrete thing they already understand and build from there. In a Basic Computer Literacy course, I explained differences in database servers by comparing them  to a Diner during the breakfast rush — requests come in, the cook (server) handles them in turn, things get backed up (queues), the grill needs more people cooking (scaling and replication). The metaphor clicked because the Diner experience was shared among them all.  I wasn't just teaching them something new; I was using language and examples they all knew fluently.

AI does something remarkably similar. When I ask it to explain a Kubernetes deployment strategy, it doesn't launch into a whitepaper. It asks what I already know, or it guesses based on context, and it finds the analogical handhold. It's not always right — sometimes the metaphor is strained, sometimes it assumes I know Docker when I barely know what a container is. But the impulse is identical: meet the learner where they are, and move forward.

The intermediate learner is a different creature entirely. They've built something that works, which gives them confidence, but they haven't yet built something that fails spectacularly. Teaching them means letting them wander into the goo of complexity and then helping them get unstuck so they can find their way out. I taught iOS development to students who could get a button to change color but couldn't yet reason about memory management or delegation patterns. The temptation is to hand them the answer, but the actual teaching happens in the struggle —in the moment where they stare at structs and classes and realize the Xcode tool they used to create them now demands the language be understood.

AI struggles here. Not because it lacks the knowledge, but because it lacks the patience for productive frustration. When a student is circling a concept, a human teacher reads the confusion and lets the silence hang. AI, optimized for helpfulness, tends to fill that silence with the answer. It's like having a tutor who can't stand to watch you squirm and teaches very little. Squirming is often where the learning happens.

The advanced learner is easier in some ways and harder in others. By the time someone is studying for an Open Source Unix certification or architecting a web application, they know what they don't know. The teaching relationship becomes collaborative. You're not handing down knowledge from Olympus; you're comparing notes with someone who has a different vantage on the same mountain.

Here AI shines. It has read more documentation than any human could memorize. It can rattle off the difference between FreeBSD's jail system and Linux containers, cite the relevant man pages, and suggest edge cases I hadn't considered. It's like having a colleague who never sleeps and has perfect recall of every technical manual ever written. There is an incompleteness to it.  The advanced learner isn't just looking for information; they're looking for judgment. They want to know whether a particular architectural choice is wise, not just possible. They want someone to say, "We tried that in 2019 and it was a disaster." AI has no 2019. It has no disaster. It has only patterns and probabilities, a knowledge structure without synthesis --a long way away from wisdom.

The reskilling audience taught me the most about what learning actually requires. These were people who had been told by the economy that their skills no longer mattered, and now they were being asked to bet on themselves one more time. The emotional stakes were enormous. A syntax error wasn't just a syntax error; it was confirmation of their fear that they weren't smart enough for this. A working script wasn't just a working script; it was evidence that they could still grow, still adapt, still matter.

No AI can see that fear. No AI can offer the look across a desk that says, "I know this is hard, and I know you're scared, and I'm not going anywhere until you get it." The human teacher is not just a source of information; they're a witness. They bear testimony to the student's struggle and eventual triumph. They create a context in which failure is survivable because someone else is watching and believes it will be okay.

And yet AI is always there. It doesn't get tired, doesn't judge, doesn't carry the baggage of its own bad day into the interaction. A student who is embarrassed to ask a "stupid question" in front of a human will happily ask AI the same thing at 2 AM, phrasing it awkwardly, getting a patient answer, and trying again. There is no shame in the machine. For learners who have been corralled by shame before — by classrooms where they fell behind, by colleagues who made them feel small — AI is a sanctuary.

I've come to think of it this way: human teaching is like running with a partner. They set the pace, they encourage you when you flag, they notice when you're about to redline and suggest a slower target. They share the struggle. AI teaching is like a treadmill. It's always ready, always consistent, never judgmental. It will run with you for as long as you want, at whatever pace you choose. But if you trip, it won't catch you. If you need to stop and cry, it won't hand you a towel and tell you about the time it felt the same way.

The best learning probably happens in the space between — where AI handles the informational heavy lifting, the patient repetition, the infinite availability, and the human handles the witness, the belief, the judgment born of scars. I taught a zillion students over the years, and I remember the ones who were struggling more vividly than the ones who breezed through. I remember the looks of "Aha" in the BCL class when the diner metaphor clicked. I remember the woman in the reskilling program who cried when her first PHP form actually submitted a POST. AI will never remember any of it. But it will be there for the next one, and the next, and the next, patient and tireless and empty.

Perhaps that's the real comparison. We teach because we were taught. The chain of human knowledge is also a chain of human care. AI is a tool — an extraordinary one, a transformative one — but it's not a link in that chain. It's a convenience that returns what we ask of it, without ever understanding why the question mattered.

 Building something yourself that the world insists you should buy as a subscription feels like victory --it feels good!.

Open any tech newsletter today, the narrative is entirely about corporate gatekeeping. You are told that to participate in the "AI revolution," you need to pony up twenty or thirty dollars a month per seat for a sterile, browser-based chatbot that lives on a corporate server farm, tracks your data, and updates its personality out from under you. If you decide to go the developer route and tinker with your own integrations, you are warned of the dreaded "sticker shock"—accidental loops that can run up a hundred-dollar-a-day bill before you’ve even finished your morning coffee.

It all feels a bit like those early days of dial-up network computing.

Back then, if you wanted to access the wider digital world, you had to navigate a gauntlet of compounding costs. First, you’d pay connect-time charges to dial into a supporting public data carrier like Sprint (which operated the early Telenet network). Then, you might subscribe to an access utility just to route to non-local numbers without being billed by the minute by the phone company. And finally, once your modem successfully squealed its way through the pipe, you paid a premium, by-the-minute surcharge just to access the content and mainframe forums of CompuServe or The Source. If you lingered too long reading a thread, the meter was always running, and your monthly bill would arrive looking like a car payment. About the only survivor of that primordial era still ticking today is AOL.  And, yes, even though AOL dialup was retired almost a year ago, AOL Desktop Gold is still available and runs under Windows right up through Windows 11.

Today’s AI ecosystem has resurrected that exact same billing anxiety. If you set up a custom AI integration, every single turn of the conversation is billed by the character. If you ask your system to monitor a database, check your server health, or help you debug a script, the "connect-time" starts ticking, and the API charges pile up rapidly.
But by setting up a virtual private  flat-rate FreeBSD "pipe" for twenty dollars a month—the modern equivalent of finding a local, non-toll access number—and pairing it with an open-source gateway like OpenClaw, we’ve effectively bypassed those premium mainframe surcharges.
It is the modern equivalent of an offline reader for complex computing functions. Utilizing a technique called prompt caching—which essentially allows the AI to remember the context of our ongoing conversation for fractions of a penny rather than re-reading the whole book every time we speak— the billing meter has been tamed and the data keeps flowing.

Instead of watching the meter spin up dollar signs all day, our actual daily API token costs have plummeted to mere pennies.
When you look at the actual ledger, the results are almost comical. For about one dollar a day—the combined cost of our flat-rate FreeBSD server hosting, our open-source gateway platform, and our optimized, highly active token access—we have a completely private, personal dedicated AI presence available all the time.
 

The geeky technical details of how the caching works and how the gateway maps those commands and what they all do, are subjects for a later post. For now, standing in my digital workshop, I’m just enjoying the view. It is proof that with a little consistency, a respect for pacing, and a refusal to run the race at a corporate sprint, you can still stake-out a remarkably advanced corner of the future on a lunch-money budget.

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?

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.