mr's Preposter.us Blog

Modern Computers Can't Be Trusted

Tue, 07 Sep 2021 12:57:04 -0500

a post about Modern Computers Can't Be Trusted by mr

Object of my dZire

Thu, 16 Sep 2021 00:29:23 -0500

a post about Object of my dZire by mr

RAIN-PSP 0.1

Fri, 12 Nov 2021 22:58:43 -0600

a post about RAIN-PSP 0.1 by mr

Cray Cray

Mon, 06 Sep 2021 14:41:16 -0500

a post about Cray Cray by mr

Ghost Trap

Sun, 12 Feb 2023 10:32:24 -0600

a post about Ghost Trap by mr

The most preposterous thing I could do

Sun, 12 Feb 2023 12:21:41 -0600

a post about The most preposterous thing I could do by mr

Good Enough Software

Tue, 14 Feb 2023 05:45:56 -0600

a post about Good Enough Software by mr

Move On

Tue, 14 Feb 2023 09:13:42 -0600

a post about Move On by mr

Getting Real

Tue, 21 Feb 2023 09:05:35 -0600

a post about Getting Real by mr

SyncThing -> rsync

Fri, 24 Feb 2023 08:41:15 -0600

a post about SyncThing -> rsync by mr

Restoring posts the Hitchcock way

Fri, 24 Feb 2023 15:50:25 -0600

a post about Restoring posts the Hitchcock way by mr

Grado GW100x

Thu, 09 Mar 2023 10:41:21 -0600

a post about Grado GW100x by mr

SE/3D - Introduction

Thu, 09 Mar 2023 15:27:17 -0600

a post about SE/3D - Introduction by mr

The Human Web

Fri, 24 Mar 2023 06:51:55 -0500

a post about The Human Web by mr

Personal Virtual Machines

Sat, 1 Apr 2023 06:42:52 -0500

a post about Personal Virtual Machines by mr

If you want to end crime, end law

Mon, 3 Apr 2023 07:07:06 -0500

a post about If you want to end crime, end law by mr

Note to self 1 - Things to read when time allows

Thu, 13 Apr 2023 08:00:24 -0500

a post about Note to self 1 - Things to read when time allows by mr

The Small Computing Congress

Thu, 27 Apr 2023 06:20:14 -0500

a post about The Small Computing Congress by mr

Links 052023

Tue, 30 May 2023 06:19:46 -0500

a post about Links 052023 by mr

Carbonite control panels

Thu, 15 Jun 2023 07:09:45 -0500

a post about Carbonite control panels by mr

The big plan

Fri, 16 Jun 2023 06:40:23 -0500

a post about The big plan by mr

Random Halloween 2023 Hacking

Thu, 22 Jun 2023 10:16:26 -0500

a post about Random Halloween 2023 Hacking by mr

The past and future of Free Software

Mon, 26 Jun 2023 10:27:53 -0500

a post about The past and future of Free Software by mr

Appless monitoring and control of the Bluetti EB3A

Wed, 02 Aug 2023 15:47:45 -0500

a post about Appless monitoring and control of the Bluetti EB3A by mr

Jason Wants to Start a Car Company

Wed, 06 Sep 2023 10:26:15 -0500

a post about Jason Wants to Start a Car Company by mr

Speederbike

Thu, 14 Sep 2023 22:44:14 -0500

a post about Speederbike by mr

=?utf-8?Q?Leia=E2=80=99s_Blaster?=

Thu, 14 Sep 2023 22:56:44 -0500

a post about =?utf-8?Q?Leia=E2=80=99s_Blaster?= by mr

Antifacist Torches

Thu, 14 Sep 2023 23:04:47 -0500

a post about Antifacist Torches by mr

Training Pendant

Mon, 18 Sep 2023 09:42:01 -0500

a post about Training Pendant by mr

Laserdisc adventure part 1

Thu, 21 Sep 2023 18:54:12 -0500

a post about Laserdisc adventure part 1 by mr

Type-O

Thu, 5 Oct 2023 09:34:43 -0500

a post about Type-O by mr

NaBloPoMo

Wed, 1 Nov 2023 22:21:07 -0500

a post about NaBloPoMo by mr

Writing Prompts

Thu, 2 Nov 2023 20:04:50 -0500

a post about Writing Prompts by mr

Type-O Prototype Hardware

Fri, 3 Nov 2023 22:45:10 -0500

a post about Type-O Prototype Hardware by mr

Type-O Case

Sat, 4 Nov 2023 20:28:39 -0500

a post about Type-O Case by mr

Race To The Bottom

Sun, 5 Nov 2023 20:51:55 -0600

a post about Race To The Bottom by mr

The Skinny

Mon, 6 Nov 2023 20:33:38 -0600

a post about The Skinny by mr

=?utf-8?Q?Photodump:_Luke=E2=80=99s_Lightsaber?=

Tue, 7 Nov 2023 23:34:29 -0600

a post about =?utf-8?Q?Photodump:_Luke=E2=80=99s_Lightsaber?= by mr

Photodump: Luke Lightsaber

Tue, 7 Nov 2023 23:37:57 -0600

a post about Photodump: Luke Lightsaber by mr

Type-O Prototype Progress

Wed, 8 Nov 2023 21:58:47 -0600

a post about Type-O Prototype Progress by mr

Seeing Red

Thu, 9 Nov 2023 22:26:54 -0600

a post about Seeing Red by mr

Ethical AI

Fri, 10 Nov 2023 00:01:16 -0600

a post about Ethical AI by mr

Reopening the Library

Sat, 11 Nov 2023 21:50:18 -0600

a post about Reopening the Library by mr

Type-O First Keystrokes

Sun, 12 Nov 2023 20:30:16 -0600

a post about Type-O First Keystrokes by mr

Tonight

Mon, 13 Nov 2023 22:52:25 -0600

a post about Tonight by mr

Halloween 2024 Hint

Wed, 15 Nov 2023 22:50:48 -0600

a post about Halloween 2024 Hint by mr

The Producer

Thu, 16 Nov 2023 21:18:57 -0600

a post about The Producer by mr

A Deer Hunter

Sat, 18 Nov 2023 21:11:20 -0600

a post about A Deer Hunter by mr

Type-O All Keys On-Board

Sun, 19 Nov 2023 20:42:51 -0600

a post about Type-O All Keys On-Board by mr

Typo-O Asynchronicity

Mon, 20 Nov 2023 23:24:35 -0600

a post about Typo-O Asynchronicity by mr

Honey I shrunk the lcd

Tue, 21 Nov 2023 22:23:49 -0600

a post about Honey I shrunk the lcd by mr

The halting problem

Wed, 22 Nov 2023 22:55:56 -0600

a post about The halting problem by mr

Why write a search engine

Sun, 26 Nov 2023 05:17:22 -0600

a post about Why write a search engine by mr

Chuck Marten

Mon, 27 Nov 2023 23:25:34 -0600

a post about Chuck Marten by mr

Aleph

Sun, 10 Dec 2023 07:10:54 -0600

a post about Aleph by mr

Baby Telepathy

Sun, 10 Dec 2023 07:56:15 -0600

a post about Baby Telepathy by mr

Universal Stompbox

Tue, 2 Jan 2024 15:54:25 -0600

a post about Universal Stompbox by mr

NETBACK

Wed, 31 Jan 2024 09:50:30 -0600

a post about NETBACK by mr

Markdown With Verbs

Sun, 11 Feb 2024 08:30:06 -0600

a post about Markdown With Verbs by mr

DONOR-1 Resurrection

Sun, 18 Feb 2024 08:32:29 -0600

a post about DONOR-1 Resurrection by mr

The Journal

Tue, 27 Feb 2024 08:26:28 -0600

a post about The Journal by mr

Progress and patience

Thu, 21 Mar 2024 00:31:17 -0500

a post about Progress and patience by mr

Automation is anticapitslist

Sun, 24 Mar 2024 07:52:43 -0500

a post about Automation is anticapitslist by mr

Automation is anticapitalist

Sun, 24 Mar 2024 11:20:06 -0500

a post about Automation is anticapitalist by mr

Preposterous as community media engine

Thu, 28 Mar 2024 06:12:17 -0500

a post about Preposterous as community media engine by mr

The distributed video streaming idea

Fri, 29 Mar 2024 15:07:57 -0500

a post about The distributed video streaming idea by mr

Reducing the compute-memory bottleneck with JSFSX

Fri, 05 Apr 2024 09:48:12 -0500

a post about Reducing the compute-memory bottleneck with JSFSX by mr

The Next Thing

Thu, 18 Apr 2024 23:56:57 -0500

a post about The Next Thing by mr

Forevernote II

Mon, 22 Apr 2024 08:44:51 -0500

a post about Forevernote II by mr

The History of Cyberspace Part One

Tue, 23 Apr 2024 00:06:18 -0500

a post about The History of Cyberspace Part One by mr

An Operating System for the Web

Sun, 5 May 2024 23:46:13 -0500

a post about An Operating System for the Web by mr

JS/OS Graphical User Interfaces

Sat, 25 May 2024 00:10:14 -0500

a post about JS/OS Graphical User Interfaces by mr

Ergonomics

Sat, 1 Jun 2024 10:28:15 -0500

a post about Ergonomics by mr

EmailiOS

Fri, 14 Jun 2024 06:29:59 -0500

a post about EmailiOS by mr

Membership Card Part 1

Mon, 17 Jun 2024 18:46:31 -0500

a post about Membership Card Part 1 by mr

The future is not an aesthetic

Fri, 05 Jul 2024 10:55:21 -0500

a post about The future is not an aesthetic by mr

The simplest thing that could possibly play WPR

Thu, 11 Jul 2024 08:22:47 -0500

a post about The simplest thing that could possibly play WPR by mr

Micro Channel Architecture

Sat, 27 Jul 2024 07:46:35 -0500

a post about Micro Channel Architecture by mr

More thoughts on starting a car company

Wed, 21 Aug 2024 13:02:01 -0500

a post about More thoughts on starting a car company by mr

People post the weirdest shit on their blogs

Sun, 8 Sep 2024 07:24:56 -0500

a post about People post the weirdest shit on their blogs by mr

Changes 2024

Sun, 15 Sep 2024 07:14:18 -0500

a post about Changes 2024 by mr

Greetings from ElementaryOS

Sun, 24 Nov 2024 08:38:02 -0600

a post about Greetings from ElementaryOS by mr

OSW - Operating System for the Web

Sun, 24 Nov 2024 09:46:05 -0600

a post about OSW - Operating System for the Web by mr

As the dust settles

Tue, 10 Dec 2024 09:12:33 -0600

a post about As the dust settles by mr

And now for a brief media test

Tue, 10 Dec 2024 09:39:58 -0600

a post about And now for a brief media test by mr

Still buggin

Sun, 15 Dec 2024 21:12:27 -0600

a post about Still buggin by mr

Gave Up

Mon, 16 Dec 2024 07:00:03 -0600

a post about Gave Up by mr

ElementaryOS - Photos plus iPhone

Wed, 18 Dec 2024 06:46:44 -0600

a post about ElementaryOS - Photos plus iPhone by mr

Tangara - First Impressions

Wed, 18 Dec 2024 23:01:19 -0600

a post about Tangara - First Impressions by mr

Sunset

Thu, 9 Jan 2025 15:39:12 -0600

a post about Sunset by mr

Server Migration 2025

Fri, 10 Jan 2025 06:36:03 -0600

a post about Server Migration 2025 by mr

Server Migration 2025 Part 2

Fri, 10 Jan 2025 06:44:13 -0600

a post about Server Migration 2025 Part 2 by mr

Server Migration 2025 Complete

Fri, 10 Jan 2025 07:01:21 -0600

a post about Server Migration 2025 Complete by mr

Tangara after about a month

Mon, 13 Jan 2025 05:24:29 -0600

a post about Tangara after about a month by mr

Dad

Sun, 19 Jan 2025 10:27:29 -0600

a post about Dad by mr

Smartphones were a mistake

Wed, 12 Feb 2025 11:07:16 -0600

a post about Smartphones were a mistake by mr

Orangestorm Giga

Tue, 4 Mar 2025 15:50:27 -0600

a post about Orangestorm Giga by mr

Tesla Minus Tesla

Wed, 05 Mar 2025 09:37:24 -0600

a post about Tesla Minus Tesla by mr

12 Inch Discs

Wed, 05 Mar 2025 18:35:43 -0600

a post about 12 Inch Discs by mr

Prepping as Retirement Plan

Wed, 5 Mar 2025 23:19:47 -0600

a post about Prepping as Retirement Plan by mr

RSScue Me

Thu, 6 Mar 2025 08:45:22 -0600

a post about RSScue Me by mr

Installing Klipper on the Ender 5 Plus

Thu, 6 Mar 2025 11:53:06 -0600

a post about Installing Klipper on the Ender 5 Plus by mr

The Do Programming Language (DRAFT)

Fri, 07 Mar 2025 07:45:54 -0600

a post about The Do Programming Language (DRAFT) by mr

Bamboo Construction Set

Sat, 8 Mar 2025 07:16:31 -0600

a post about Bamboo Construction Set by mr

The lunch tray project management system

Sun, 16 Mar 2025 23:22:59 -0500

a post about The lunch tray project management system by mr

Thanos

Wed, 19 Mar 2025 08:31:12 -0500

a post about Thanos by mr

KGL Mainframe

Thu, 03 Apr 2025 09:20:42 -0500

a post about KGL Mainframe by mr

Zen and the Art of Software Maintenance

Fri, 04 Apr 2025 08:28:56 -0500

a post about Zen and the Art of Software Maintenance by mr

Windows95

Sun, 06 Apr 2025 09:40:37 -0500

a post about Windows95 by mr

Digital Casting

Mon, 07 Apr 2025 07:57:57 -0500

a post about Digital Casting by mr

Private, High-Quality Web Search with Kiwix

Thu, 10 Apr 2025 09:34:31 -0500

a post about Private, High-Quality Web Search with Kiwix by mr

Programming in a human language

Fri, 25 Apr 2025 08:00:23 -0500

a post about Programming in a human language by mr

The end of the world as we know it

Thu, 1 May 2025 07:40:05 -0500

a post about The end of the world as we know it by mr

Electrons for peace

Fri, 16 May 2025 08:42:06 -0500

a post about Electrons for peace by mr

Typewriter Bar

Wed, 21 May 2025 12:17:24 -0500

a post about Typewriter Bar by mr

Weird in Public

Thu, 22 May 2025 08:23:32 -0500

a post about Weird in Public by mr

Things I wish I could get done for Preposter.us

Thu, 22 May 2025 08:35:15 -0500

a post about Things I wish I could get done for Preposter.us by mr

What's Next? 2025

Sat, 24 May 2025 10:13:10 -0500

a post about What's Next? 2025 by mr

Traditional CPU vs. DASL Machine

Wed, 28 May 2025 07:44:19 -0500

a post about Traditional CPU vs. DASL Machine by mr

Seymour Mark I Hardware

Thu, 29 May 2025 07:54:05 -0500

a post about Seymour Mark I Hardware by mr

Re-testing Elementary Mail

Tue, 17 Jun 2025 08:00:38 -0500

a post about Re-testing Elementary Mail by mr

Dr. StrangeLLM or: How I learned to stop worrying and love the bomb

Fri, 27 Jun 2025 09:00:50 -0500

a post about Dr. StrangeLLM or: How I learned to stop worrying and love the bomb by mr

Framework 12 and ElementaryOS

Fri, 04 Jul 2025 09:38:52 -0500

a post about Framework 12 and ElementaryOS by mr

The Pager

Sat, 05 Jul 2025 08:41:47 -0500

a post about The Pager by mr

Focus on writing with Apostrophe

Thu, 10 Jul 2025 09:05:43 -0500

a post about Focus on writing with Apostrophe by mr

Thought amplification vs. thought trampflication

Wed, 23 Jul 2025 07:02:20 -0500

a post about Thought amplification vs. thought trampflication by mr

The autonomous solar-powered Universal Basic Income thing

Sun, 27 Jul 2025 09:57:18 -0500

a post about The autonomous solar-powered Universal Basic Income thing by mr

Why our technology is so harmful

Thu, 28 Aug 2025 07:21:16 -0500

a post about Why our technology is so harmful by mr

Shooting

Mon, 13 Oct 2025 07:49:47 -0500

a post about Shooting by mr

The Last Laptop

Mon, 27 Oct 2025 10:41:01 -0500

a post about The Last Laptop by mr

Cancer

Wed, 31 Dec 2025 05:12:01 -0600

a post about Cancer by mr

New Year

Thu, 01 Jan 2026 06:58:25 -0600

a post about New Year by mr

Making circuit boards with a 3018 Mill

Fri, 02 Jan 2026 08:39:17 -0600

a post about Making circuit boards with a 3018 Mill by mr

New board who dis?

Sat, 3 Jan 2026 10:47:21 -0600

a post about New board who dis? by mr

Moar RSS

Sun, 04 Jan 2026 15:10:13 -0600

The point of this post is to test my initial attempt at including the full body of these posts in the RSS feed generated by Preposter.us.

Since I don't have a proper testing environment configured, we're doing it live!

If this doesn't work, I'll probably put more effort into setting up such an environment, but I'd love to avoid it as I'd rather spend any energy directect toward Preposter.us into a rewrite.

Jason J. Gullickson, 2026

Dem Bones

Mon, 5 Jan 2026 18:49:49 -0600

Register Duct

Tue, 06 Jan 2026 07:58:28 -0600

We have a forced-air HVAC system and two of the registers (the hole where the air comes out) are placed almost directly below outside windows. It's helpful to deflect this air away from the cold window in the winter, so we bought some injection-molded plastic adjustable baffles and those worked fine for a couple years.

Last year both of them broke; one salvageable and the other, not.

Instead of just buying more I decided to design some of my own, since it's more fun for me to make things than to buy things, and since I'm custom designing it they can be made to fit just right.

The basic design is similar to the store-bought models with the difference of being a single piece of plastic and having a complete base instead of having no base on the side where the air comes out. I think both of these changes will make the part a bit stronger than the original.

The other difference is that the new model will be printed in white whereas the original was transparent.

Both are attached to the grate using magnets, but I plan to use somewhat stronger metallic magnets embedded in the printed part as opposed to the flexible kind found on the original unit.

This sort of thing is one of my favorite types of 3D printing, making parts for an old house that fit just right. It's a subset of making parts that no longer/never did exist, and it's beautiful.

Jason J. Gullickson, 2026

Bad Baby Beaver

Thu, 8 Jan 2026 07:52:55 -0600

GitPrintable

Fri, 9 Jan 2026 00:21:00 -0600

Way back when Thingiverse was pretty much the only game in town for sharing 3D models for printing. When the printer company that owned it started to do uncool things, the site got uncool as well and a bunch of us who used it started thinking about how important it was to have something like this and how dangerous it was to trust it to a single company.

There were some experiments in creating something else, but in the end we mostly ended-up with more sites run by different printer companies.

One of the ideas I had at the time was to make something based on Git, so that it could be distributed instead of being a single site under the control of a single entity. Of course the extent of most people's experience with Git (if they have any at all) comes from Github which erases the naturally distributed nature of Git.

I've been revisiting these ideas as of late for various reasons and thinking about what I'd want out of something like this today. Of course what matters to me probably doesn't overlap with the majority of people using 3D printers anymore, but that's OK. You can't please everyone and when you try you often please no one.

When I think about the way I work I often start by "sketching-out" a new design in a so gle OpenSCAD file and either drop it into an existing general-purpose Git repository for models or create a new repo specifically for the project. For me, the least disruptive way to interact with a website for sharing models would simply be to add the site as a git remote and push a branch to it whenever I want to publish or re-publish something, kinda like Heroku.

The receiving server could then render some HTML based on the contents of the repository and add it to a search index others can use to find models on the site. It could be as simple as that.

If you wanted to get fancy, you could establish some conventions around how the repository is laid-out, placing printable files in a designated directory and design/source files in another, parsing OpenSCAD files to provide parametric customization, etc. You could even parse slicer setting files to create printer profiles for each member and even generate gcode directly. The possibilities are almost endless.

It poses a somewhat high technical barrier for publishers, but for people looking for models it could be as easy as using any other site.

I'm going to start experimenting with this locally and see how hard it is to get a basic publishing/indexing server running. If I can get that far maybe I'll setup a public server for others to experiment with. I want to retain the distributed nature of git, which I think means mostly providing a means for linking the search index of multiple sites. I have a few ideas for this but exactly how it will work will depend on what I use to implement the index.

Jason J. Gullickson, 2026

Spangly

Sat, 10 Jan 2026 14:06:44 -0600

Alpha Bits

Sun, 11 Jan 2026 15:19:53 -0600

We do a lot of printing at KGL and over the years we've experimented with using 3D printing to make parts for 2D printing. In the last couple years we've done some 2D printing with LEGO, but didn't find existing LEGO parts that could be used to print text.

So we started by taking a printable brick and trying to turn it into "type".

Using OpenSCAD it was fairly straightforward to take an existing model of a LEGO-compatible part and subtract the letter "A" from it to test the idea. After a print or two, we had something that looked like it might work.

The next step was to 3D print a set so we could 2D print a test sheet. We didn't sweat the details such as alignment, etc. because the goal here was just to see how the transfer worked. If it appeared to have potential, we'd work on refinement next.

Jamie annotated the proof and I took that back to OpenSCAD for refinement.

Since I generated the set algorithmicly I didn't want to tweak the position of each letter by hand. I did some digging and learned about the textmetrics() function which gives you the dimensions (among other things) of the object that will be generated by a given invocation of the text() function. With this, it would be fairly straightforward to center each letter on it's LEGO tile.

However, this function isn't currently available in the release builds of OpenSCAD, so I had to get my hands on a nightly/development-snapshot build. I was kind of dreading this because I've built OpenSCAD from scratch before and at least back then, it wasn't fun.

Fortunately I found that this is no longer needed. You can install it via flatpak (which is the prefered way to install things on ElementaryOS) and so in a few minutes I was ready to go.

As it turns out I didn't need the textmetrics() function after all. After cleaning-up my code from various experiments I found that simply specifying the alignment of the text manually moved all the letters damn close to center. This is a major improvement, so for now I'm going to leave it as-is until we do another test (2D) print.

The other tweak was reducing the height of the part slightly. I don't know if the model we're using is just a little different from the real LEGO part, or if it's a matter of (3D) printing tolerance, but the printed parts were just a little taller than the off-the-shelf parts which is a big deal when (2D) printing something this way. I'm not sure exactly how much we need to shave off, so I created a 0.25mm disc and subtracted it from the top of the part.

Finally, there's one remaining improvement needed. The print bed I used for these has a texture to it, and that texture is visible on the (2D) print. I tried to address this by switching back to the original glass bed on my Ender 5+ (Tony), but this only reminded me of why I stopped using that bed (bad adhesion). So before I print another run of these parts I'm going to pick-up a smooth PEI bed for Tony.

More to come.

Jason J. Gullickson, 2026

This Coffee Is Good

Mon, 12 Jan 2026 07:56:12 -0600

I make my coffee at home with a Bialetti coffeemaker. I tried a "moka pot"-style coffeemaker from another brand back in the 90's and found it made strong but bitter and very inconsistent coffee. This turned me off to the moka pot, but my friend Tristan mentioned his Bialetti one day a couple years ago and I decided to give it another try.

I'm glad I did because the results are excellent, and I haven't looked back once. I still have my vintage Braun on stand-by (I'm afraid to use it daily because it's become something of a collector's item and spare carafes are a fortune), but I've donated every other coffeemaker I had and completely switched to the Bialetti.

I use Raven Espresso from our local roaster Nunatak Coffee. I grind this medium-fine in a nice burr grinder I picked-up a few years back and I usually use tap water. The result is a potent but smooth cup, really a half or third "American" cup of coffee, but each sip explodes into gallons of flavor.

I still enjoy regular coffee when I'm out-and-about and of course love a good cappuccino or other concoction when I'm somewhere with a trusted barista, but at home it's always the Bialetti.

The only challenge has been the rare occasion where we have guests who drink coffee too. This almost never happens, but when it does the limited capacity of the Bialetti does mean I spend a lot of time making each cup. This isn't the worst thing that could happen, as it gives me time for a little needed mindfulness when we have company. Also Bialetti coffee, which is similar to espresso, isn't everyone's cup of tea, but I've found cutting it with equal-to-double parts hot water produces something like an Americano which most coffee drinkers find acceptable.

Jason J. Gullickson, 2026

That Secret Book Project

Tue, 13 Jan 2026 14:45:54 -0600

Over winter break I finished the first draft of a book I'm writing about software (and eventually, hardware I guess). I haven't said a lot about it publicly because I want the book to speak for itself.

That said, it's been really hard not talking about something that I've spent so much time working on, so I decided it was OK to talk about writing the book instead of talking about the book itself.

I think I started working in earnest back in November of 2025 but the ideas for the book have been percolating for years. Last year I started experimenting with the ideas that would eventually find their way into the book, spurred-on by both other books I'd been reading and conversations with others, Primarily Preston, about programming, about computers and the roller-coaster of working in this field (long before I was even "working"). I took the excuse of NaNoWriMo to force myself to write a little of the book virtually every day in November, and while I didn't complete it by the end of the month, I had enough done that it had enough momentum behind it to carry the work through the first draft.

It was hard to decide what exactly would amount to finishing the first draft. On one hand, I considered it to be whatever it was when I reached the last page, since I deliberately refused to do any editing until the first draft was complete. On the other hand, there's a lot of "holes" left behind from the process of avoiding editing, which means the first draft isn't complete in the sense that someone else could read it from start to finish and know everything that will eventually be in there.

So maybe I cheated? I dunno.

The next task is to decide when the first edit should be complete. I deliberately took a break from the project for a couple weeks to clear my head, but I'm considering setting a deadline for that edit at the end of January 2026 (about two/three weeks). This would normally seem too soon, but I might have some time to write near the end of the month so it's not impossible.

Since I don't know how much work the editing will be, it's hard to say if this is realistic. I suppose I could just treat it like a timebox and consider whatever shape it is at the end of the month to be the first edit. I don't know if there's strict rules for this, I haven't really reached the editing stage of book project before, so this is kind of new. I also don't know how many edits I should expect, but my current plan is to do two edit passes and then produce pre-release edition that I can circulate to a small, diverse group of readers who are willing to help me figure out what might remain before committing to a larger release.

Jason J. Gullickson, 2026

The Last Linux

Wed, 14 Jan 2026 07:57:55 -0600

ElementaryOS will probably be the last version (distro, etc.) of Linux (GNU/Linux, yes I know) I use. It is, in my opinion the best Linux for personal computers and while I will run Linux on other things (servers, embedded devices, etc.), Elementary will be the Linux I myself use on a personal computer until I'm done using Linux this way.

I don't want to seem unappreciative for what Linux and Free Software have done for computing. I'm keenly aware of what it was like before we had a free and open source alternative to proprietary commercial operating systems. But I'm just as familiar with what came before all that, when a personal computer was something you could buy (or build!), for the cost of something like a single car payment, and once you had it you had everything you needed to begin making it into exactly what you needed.

My work, when I'm able to choose it, is now focused on resuming that path of personal computing, and I don't see Linux as a part of that. It is simply too big, too complicated and is, let's face it, "owned" by the exact same type of people it was created to free us from in the first place.

It will take time to bring us back on the personal computing path we had before it was appropriated by capitalists in the 80's. In the meantime, ElementaryOS is a fine place to work, made by fine people who understand that personal computers are more about people that computers, and appear (at least to me) to be one of the very few groups of people producing technology at the moment who are not willing to sell-out the people who use their software for some small profit or temporary security.

Jason J. Gullickson, 2026

Seiko SRPG33

Thu, 15 Jan 2026 15:24:19 -0600

I decided to start looking for a new mechanical watch when I got fed-up with my Withings Scanwatch Horizon. Like many things made today, the Withings is a beautiful piece of hardware crippled by mediocre-to-bad software.

I started by making a wishlist. I knew for sure that I wanted something that didn't need batteries (let alone a smartphone), but I thought a lot about what I really needed from a watch beyond that and came up with this list.

* Self-winding ("Automatic")

* Alarm

* Rotating bezel

* Water resistant

* Numeric dial

* Illuminated hands

* Durable (not a "fashion watch")

I spent about a year looking for a watch like this with no luck. There was one or two that had these features, but they had a lot more and were very expensive which I felt disqualified them from the "durable" requirement.

This made me reflect on the list and really think about what I need. The first thing to go was the alarm since we have a dog and he's always awake earlier than I need to be.

Next to go was the bezel. This was a harder cut because I really use the heck out of the bezel on the Withings to measure elapsed time, but I just couldn't find a watch that had one that wasn't a "diver's watch" or missing one of the other more important items on the list (usually the numeric dial). Weirdly I found a watch similar to the one I finally settled on that had a rotating bezel but it wasn't for measuring time but orientation. Neat, but I'd rather use a full-blown compass.

By making those two cuts I was able to find a perfect match in the Seiko SRPG33.

Jamie bought me one for xmas, and I have to say that I absolutely love it. It is the first watch I've owned with a NATO band. The band is extremely comfortable and might double as a small tourniquet. The only complaint I have about the band is that due to the way it mounts, it blocks the little window on the back of the watch where you could otherwise marvel at it's clockwork.

The dial is very easy to read even when it's on the nightstand and the illumination is sufficient even for my 50+ year old eyes. It's heavy enough to feel like a quality piece of machinery but light enough to wear comfortably all the time.

I wasn't sure if I'd move enough to keep it wound (especially in the winter), but so far that has not been a problem. I gave the crown a few twists when I first set the time and date and I haven't wound it since.

Speaking of date, the day/date is large and crisp and I especially like how high-contrast it is to the subdued dial. I panicked when I first set it thinking it was a non-English version but as it turns out, it's multilingual. One downside is that so far I haven't had to adjust the date (31 days in December) so hopefully I remember how to set it when we get to the shorter months.

One minor disappointment is that I thought it might tick. I'm not sure if that would just drive me crazy but I had kind of expected to hear or feel that and thought it might be relaxing.

I haven't tested the water resistance beyond some light splashing (not really the time of year for submersion) but I will say that I prefer the feel of the NATO band when it's wet compared to the metal or leather bands on my other watches.

I'm glad I took the time to find the right watch. It's something that is very intimate for me, and while I had to forego some features, I think in the end the result is better for it. This probably has influenced my thinking about features in other realms as well, and reinforces for me the joy of simple tools.

Jason J. Gullickson, 2026

SE/3D 2026

Fri, 16 Jan 2026 10:47:00 -0600

I was going to write more about making circuit boards using the little CNC mill today but as I was working on a new board design in KiCAD I got excited about my idea for a tiny, integrated, portable maching for making such things, SE/3D.

This was the start of today's post, but you can see it has strayed a bit...

I wrote about SE/3D ~~last year~~ a few years ago, and had hoped I might at least get it working as a 3D printer in time to go to the Midwest Reprap Festival. As usual, I got sidetracked/re-prioritized/etc. and didn't make a lot more progress after that post. Today I'm reinvigorated, partially by doing the sort of work I want to do on such a machine, but probably also due to some beautiful work I've seen lately by people recreating the SE/30, even building completely new machines.

I will admit that part of my passion for the SE/3D design comes from feelings I can't explain about the SE/30. Maybe it's simply nostalgia, but I think there's more to it than that. I didn't own one when it was "contemporary", I only worked on one occasionally while in school (most of my time there was spent inside Boarland Turbo C++ on a 386DX40). Years later I bought one off Ebay and used it to run an Internet site (DNS, Mail, Web) to prove it could be done, but it wasn't something I used for everyday work. Yet I've always been drawn to the machine, the form-factor, the operating system and it's applications...

So there is for sure something "romantic" about my desire to use that same form to build my personal universal fabrication machine.

Something I'm reconsidering for SE/3D is the operating system. By default I had assumed this would be some form of Linux, or maybe something new I create myself, but I'm wondering if in 2026, HaikuOS might be an option?

I love Haiku, and I think it would be a perfect fit for such a machine, but for a long time the only CPU it worked with was X86, and for many reasons I won't be using an X86 processor in SE/3D. But last year I started hearing that someone is working on getting Haiku running on RISC-V, and I just happen to have a nice little RISC-V SBC sitting on the workbench...

If that works, I would be very happy to base the machine on HaikuOS. Many of the tools I rely on in Linux run on Haiku (I don't completely understand how, but I'll take it) so I don't think application software will be a major barrier, and if it is well then I'll have an excuse to play with writing Haiku/BeOS software again I guess...

Jason J. Gullickson, 2026

Downlink 2006-01-16

Fri, 16 Jan 2026 15:26:56 -0600

"Downlink" was a regular feature of my blog years (decades?) ago. At the end of each week I close things out by posting all the open pages in my browsers. For 2026 I'm going to try to bring it back, assuming I don't forget...

(note: some of these may only be reachable from the KGL LAN)

* http://3dp.kratzgullicksonlabs.com/?printer=4104c56ab8a91f385eb6019bc277a9d0#/

* http://flatcam.org/

* https://github.com/mikelachaine/flatcam-2025

* https://www.circuitsnips.com/circuit/rp2350-microcontroller-core-circuitry-bread-modular-2

* https://www.opensubtitles.com/en/subtitles/5695922-x-men-2000-dvdrip-axxo-avi

* https://www.printables.com/model/1234213-cable-spool-holder-gridfinity

* https://blog.prusa3d.com/adrian-bowyer_127066/

* https://pine64.org/documentation/STAR64/_full/

* https://forum.pine64.org/showthread.php?tid=18276

* https://www.armbian.com/star64/

* https://www.bluettipower.com/products/ac200l

* https://www.bluettipower.com/products/b300

* https://www.electricaltechnology.org/2025/12/wire-30a-125v-nema-tt-30-receptacle-rv.html

* https://hackaday.com/2025/01/14/new-frontiers-for-nissan-leaf-motor/

* https://learn.adafruit.com/esp32-s3-reverse-tft-feather/storage

* https://learn.adafruit.com/esp32-s3-reverse-tft-feather/advanced-serial-console-on-linux

* https://docs.circuitpython.org/en/latest/shared-bindings/displayio/

* https://docs.circuitpython.org/en/latest/shared-bindings/terminalio/index.html

* https://learn.adafruit.com/adafruit-max17048-lipoly-liion-fuel-gauge-and-battery-monitor/python-circuitpython

* https://docs.circuitpython.org/projects/max1704x/en/latest/api.html

* https://en.wikipedia.org/wiki/Floating_Point_Systems

* http://code.kratzgullicksonlabs.com/jason/the-convivial-codeworker/src/branch/main/projects/whom.py

* https://github.com/elementary/mail

* https://theanarchistlibrary.org/library/anonymous-desert

* https://commandmasters.com/commands/yt-dlp-common/

* https://github.com/TheRealBolle/SE30

* https://tinkerdifferent.com/

* https://www.harborfreight.com/20-gallon-parts-washer-with-high-flow-pump-58679.html

* https://www.printables.com/model/444111-snail-lamp

* https://www.whambamsystems.com/products/flexi-plate-with-pre-installed-pex-build-surface-377-x-370-creality-ender-5-plus_

* https://tonsky.me/blog/tahoe-icons/

* https://stackoverflow.com/questions/73863407/how-do-i-format-time-in-micropython

* https://www.ammoman.com/blog/category/guns-101/

* http://code.kratzgullicksonlabs.com/jason/cnc_pcb_tools

* https://www.haiku-os.org/blog/kallisti5/

* https://github.com/chrisdiana/TinyCity

* https://duckduckgo.com/?q=techno-viper&kd=-1&t=epiphany&ia=web

* https://www.ebay.com/sch/i.html?_nkw=techno+viper&_sacat=0&_from=R40&_trksid=p2332490.m570.l1313

* https://makertube.net/w/qamYNF1Pqcw7iWrHxVznuC

* https://bandcamp.com/the_rectifier

* https://learn.adafruit.com/adafruit-si4713-fm-radio-transmitter-with-rds-rdbs-support/python-circuitpython

* https://docs.micropython.org/en/latest/library/framebuf.html

* https://docs.micropython.org/en/latest/library/asyncio.html#tcp-stream-connections

* https://docs.micropython.org/en/latest/library/machine.ADC.html

* https://docs.micropython.org/en/latest/library/machine.RTC.html

* https://docs.micropython.org/en/latest/library/time.html

* https://docs.micropython.org/en/latest/esp8266/tutorial/ssd1306.html

* https://docs.micropython.org/en/latest/reference/packages.html

* https://docs.micropython.org/en/latest/library/machine.html#machine.lightsleep

* https://randomnerdtutorials.com/micropython-oled-display-esp32-esp8266/

* https://github.com/stlehmann/micropython-ssd1306

* https://raw.githubusercontent.com/micropython/micropython-lib/refs/heads/master/micropython/drivers/display/ssd1306/ssd1306.py

* https://www.fredscave.com/32-micropython-working-with-files.html#opening-a-file

* https://github.com/dhylands/rshell

* https://www.pythontutorials.net/blog/micropython-repl-run-file/

* https://www.geeksforgeeks.org/python/constructors-in-python/

* https://randomnerdtutorials.com/esp32-esp8266-analog-readings-micropython/

* https://github.com/jjg/t5fyntmbta/tree/main

* https://codeberg.org/jjg/cnc3-3018pro

* https://en.wikipedia.org/wiki/Axial_flux_motor

* https://spectrum.ieee.org/axial-flux-motor

* https://cults3d.com/en/3d-model/gadget/axial-flux-motor

* https://mecrisp.sourceforge.net/

* https://pandoc.org/MANUAL.html#pandocs-markdown

* https://docs.python.org/3/tutorial/classes.html#a-first-look-at-classes

* https://blog.tommy.sh/posts/quick-tip-hone-in-on-the-perfect-fit-with-a-goldilocks-array/

* https://learn.adafruit.com/circuitpython-text-editor-on-the-go/code-walkthrough

* https://oshpark.com/

* https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior

* https://www.consoleroms.com/roms/sega-genesis/sonic-the-hedgehog/download

* https://www.nature.com/articles/s44184-025-00171-5

* https://en.wikipedia.org/wiki/Preferential_attachment

* https://mymissionspecific.com/

* https://www.ducati.ms/threads/supermono-build.755313/?nested_view=1

* https://www.youtube.com/watch?v=VgEOeogf_cs

* https://t0mg.github.io/tinytron/

* https://github.com/BelfrySCAD/BOSL2/wiki/threading.scad#section-generic-threading

* https://gbppr.net/2600/v42n2-library.html

* https://iffybooks.net/25-projects-in-2025/

* https://www.amazon.com/BIQU-Frostbite-235x235mm-Temperature-Removable/dp/B0FG328QPT?s=industrial

* https://github.com/schollz/croc

* http://music.kratzgullicksonlabs.com/web/index.html#!/details?id=26309f0f2892dc96b9adabd3dbbf94f5&serverId=2fa1d671443b466e87f1f55f4955a739

* https://www.youtube.com/watch?v=zc3sPoqOFG8

* https://www.opensubtitles.com/en/subtitles/7469743-jurassic-world

* https://us.elegoo.com/cart

Jason J. Gullickson, 2026

Something New Is happening

Sun, 18 Jan 2026 00:55:38 -0600

The General-Purpose Communicator

Mon, 19 Jan 2026 09:46:11 -0600

I think it might be time to create a general-purpose communicator. A as-simple-as-possible device capable of communicating as reliably as possible with other devices like itself as well as ideally other types of communications devices.

There's many things like this, but in my opinion they have unacceptable limitations.

I'm thinking something based around a software-defined radio (SDR) so that it can adapt to communicate with most any sort of wireless system. In the most extreme scenarios I think that good-old-fashioned analog voice communications (CB/ham radio, etc.) are always going to hold the line so whatever this is and whatever sort of "digital" capabilities it might provide should be supplemented with the ability to fall-back to these methods of communication.

I don't know much about SDR, so I don't know how reasonable it is to have a device that can reconfigure itself like this without the need for a full-blown general-purpose computer and the associated software, etc. If possible the ideal would be to make all that's necessary self-contained within the device, but if that means cramming a whole computer with associated screen/keyboard/etc. and the power demands all that places on such a system then I'm not sure that's the way to go. Alternatively if it's possible to store several configurations that have been built in advance that allow the device to reconfigure itself in a self-contained way, that might be good enough.

On top of the SDR and basic analog voice radio capabilities I'd put some level of digital communication facility as well. If possible this would re-use the SDR hardware for other types of wireless communication (WiFi, etc.) but again I don't know the practical limits of this technology. Digital modes open up the possibility for store-and-forward based networks which have advantages over the "realtime" nature of analog voice comms, and of course there's options for keeping messages more private as well (although I wouldn't recommend relying on this, nothing beats a one-time-pad). Something along the lines of a microcontroller running Micropython should be more than enough for this task and easily fit within any imaginable power budget.

Something that might be helpful is a way to share location information among devices. I'm not sure if this means including a GPS receiver (maybe another thing that the SDR could do?). There's lots of imaginable applications for this but if it adds too much complexity it's not a requirement.

Other nice-to-haves would be a case big enough to house a solar panel capable of topping-up the battery and sturdy enough for field use. Something as large as an old-fashioned Walkie-Talkie handset would be fine for this and provide plenty of room for batteries and excess case material.

Jason J. Gullickson, 2026

Me Mail

Tue, 20 Jan 2026 08:12:06 -0600

A lot of my "personal workflow" is built around Internet Email. Maybe it's old-fashioned, but I prefer it for a lot of reasons both technical and others.

However, as email has fallen out of favor the range and quality of email software has decreased. I thought maybe I could personally invest in the ElementaryOS Mail application (potentially in money and labor) but I'm starting to wonder if maybe it's time for me to write my own email client? Doing so would allow me to try a few things that I've always wanted in a mail client, and also means I could build it using whatever tool I want without inheriting a "tech stack", codebase, features I don't want, etc.

The first thing I would do is separate authoring and reading mail so that when I want to write a message I am not first confronted with my inbox. This sort of distraction is exactly the opposite of what I want when I'm trying to initiate a communication, but virtually every piece of communications software works this way.

The next thing I might do is decouple any sort of technical troubleshooting from the authoring process. When I send a message I don't want to be forced to immediately fight with the underlying email system if something goes wrong. Conversely, I want it to be obvious and trivial to dive-into that problem at a later time when I'm up for fighting with it. Most mail programs present a dialog when mail fails to send, and if you don't address the problem immediately, it can be very hard to find your way back after dismissing this message.

Let's consider format for a moment. Both plain text and HTML email should be possible, but both should be cleanly constructed and properly encoded. Working on Preposter.us, I've seen the "raw" form of email messages sent from many clients and the amount of nesting/nasty HTML and missing plain text is a source of frustration for me trying to parse these messages. I might even consider authoring all messages in plain text, and allow markup to be entered directly as HTML tags...

What else?

Obviously all the cleverness seen in contemporary "email" like Googles gmail are out. No AI (unless you consider spell check to be intelligent), no moving mail around automatically, etc.

Some sort of simple and obvious mechanism for moving any "local" data would be important. I'd prefer to avoid that altogether and keep any "state" in IMAP structures but minimally things like unsent mail might need to be stored locally and therefore should be easy to discover, move to another computer and access there without complex and deliberate export/import tools.

I don't think I want any anti-spam or other safety/security features in the client itself. I think those things are best left to the mail network. I'm a bit torn about handling inbound HTML email because so many nasty things can be embedded in it. My first thought is to present it raw, and make it easy to open the message in a separate web browser which can more thoroughly implement the various protections needed when opening any HTML content. I think this is both more robust and less redundant than rendering HTML inside the email application.

I don't know off-hand how I'd go about building this unless I write it as a console/terminal application. If I'm to forgo rendering HTML as described above, this might be an option. I do feel like it would be preferable to have a GUI application when such an interface is available, but right now I don't have a programming environment for GUI applications that I want to work in. I suppose I could start in the console and then re-write for the GUI if something I like comes along.

Jason J. Gullickson, 2026

Phonodex

Wed, 21 Jan 2026 10:36:43 -0600

I have a small collection of vinyl records, but even with a small collection it's hard for me to keep track of what I have, and suffer the tyranny of choice when I'm trying to select something to play.

With electronic media it's easy to solve these problems, and at one time I started keeping a list of my records so I could at least remember what I have, but that doesn't help me find what I'm looking for.

This inconvenience is compounded by where I store my records, a very nice looking cabinet but low to the ground. Additionally, the spines of the sleeves are often in shadow and hard to read (if they can be read, some of my records are pretty old).

So in addition to some sort of searchable database of albums I need a way to find the one I'm looking for in the physical world.

The idea I came up with is pretty simple, and probably easy to implement but I haven't gotten around to it yet. I want to install a high-density LED strip in the record cabinet on the bottom of the shelf above the records. This strip is then connected to the database software, and when an album is selected in the software, the LED nearest the physical record illuminates.

I doubt there is an LED strip with sufficient "resolution" to illuminate each record on the shelf individually, but that's OK. Even getting close is sufficient to narrow the search enough to quickly select the title.

This of course depends on the physical records being in predictable locations. This is handled by the same mechanism. When a record is selected for play, its marked as "off the shelf", and when it is to be returned, "return it" is selected in the software and the LED indicating the correct position is illuminated. My records are sorted by genre, then alpha by artist and finally by release date. Again even though the LED can't precisely select the location I can place it precisely within the nearby records.

Aside from this basic mode of operation, this automation opens the door for additional modes. For example, a "shuffle" mode could randomly select a record to play (a clever shuffle could keep track of what was listened to any only suggest fresh albums). A "collection" mode could select titles based on various groupings (for example, showing other records by artists on a compilation). The possibilities are somewhat endless.

Implementation-wise there's may ways to actually build this, which is probably why I haven't started yet. The hardware side is pretty simple, although I want to make sure that the selection of the LED strip controller doesn't over-constrain software implementation options. The harder part to decide on is the software side, it could be nothing more than a REST API that other tools talk to, or something using parts of HomeAssistant, or maybe my primary digital media management software Jellyfin. I'm just not exactly sure which way I want to go with it yet.

Jason J. Gullickson, 2026

Friendly Finder

Thu, 22 Jan 2026 15:42:43 -0600

WARNING: Potential spoilers for One Battle After Another ahead!

In the film One Battle After Another the characters use devices to identify people they can trust. I'll try not to give too much away, but the basic idea is that if your device plays a certain tune, you can trust the person you're talking to.

I thought this was a clever idea and wondered if it was based on a real thing. So far I've had no luck finding such a thing.

I put the question to the Fediverse and someone pointed out the similarity to the COVID infection tracking apps from the pandemic. This reminded me that I had already designed a device like this and got me thinking maybe it could be "refactored" to serve this new purpose.

Sadly, I'm unable to find a repository for that project. It might have been mixed-into some other general-purpose repo, or worse some random "projects" folder that wasn't checked into source control.

That's OK, because I remember the basics of the hardware (it was based on a particular ESP32 dev board) and chances are the firmware was probably obsolete by now anyway.

So how might this work? If I start from the ESP32, it seems logical that the radio communication be Bluetooth (probably BLE). I don't remember exactly how BLE works but I seem to recall that a device can scan for other devices and get a list of MACs (or some other physical address), so this might be a basis of trust, if these addresses are stored in a "trusty" list on each parties device.

This probably isn't enough to establish trust since these things can likely be faked, but it might serve as a first step in establishing that (and also avoid having conversations with every toaster and dishwasher in the room).

So if the address is on your list, maybe you exchange a message with a key, and the other does the same, and if they match a "lock" on the other's side, we start to think this person might be OK.

But I think there needs to be something more, something that isn't entirely contained in the device lest someone simply steal the device and appear trusted.

In the film I think there was a verbal password exchange. This is probably sufficient, but I feel like it's kind of risky because it relies on human memory, which at least in my case has limits, especially in times of stress.

Jason J. Gullickson, 2026

(a little) Power to the People

Fri, 23 Jan 2026 09:42:47 -0600

A couple years ago we decided to give our parents small Bluetti "solar generators" for xmas. At the time I'm not sure they really saw the value in it. We said "just leave it plugged-in and if the power goes out you can use it to charge your phone and run some lights".

The motivation for these gifts came from talking to my cousins who live in North Carolina about their experience during a hurricane. They live in the mountains and were not terribly impacted directly by the storm, but their power was out as well as any land-based communications. They wanted to keep in touch to let people know they were OK, and stay abreast of developments with the recovery efforts in the valley. Their phones worked, but because modern phones suck, they ran out of battery power within 24 hours.

They were also without electric light and heat, but most of these folks have candles and wood stoves so that wasn't the problem it otherwise might have been.

So people like them in the mountains drove down into the valley to charge their phones and see what was going on and in the process go caught-up in the disaster.

Hearing these stories I realized that while these small "solar generators" would not provide complete standby power for a household, they could easily provide power to keep phones running for days (some weeks) as well as provide electricity for other niceties like lights, tools and other things.

In my cousin's case, this would have made a huge difference.

So we decided to get some of these units for our folks, the smallest unit Bluetti made at the time (we chose Bluetti because we have some and are familiar with how to use them) and figured worst case they wouldn't need it, but if they liked them they could always add more capacity, or add solar panels, etc.

Two or so years passed and I more or less forgot about all this, but then I got a text from my mom this morning with a photo of the little unit with an electric blanket and her phone plugged into it. She said that she was so excited because the power went out and she got a chance to try this thing out.

Bear in mind that this morning it is -18F here, and loosing power under these condition would normally be terrifying, but here she is appreciating it because it gave her a chance to appreciate a gift from years ago.

You might expect this story to have a point, and maybe it does, but I don't have a specific one in mind. It just made me really happy to see that this made her happy, kept her a little safer and turned something that might have been scary into something fun. I think there are ways to make scary things fun, and a little preparedness is often a part of that.

Jason J. Gullickson, 2026

Downlink 2006-01-24

Sat, 24 Jan 2026 11:13:51 -0600

A day late because yesterday was an arctic adventure.

* https://www.bluettipower.com/products/ac2a?variant=46297958416603

* https://sendcutsend.com/

* https://www.police1.com/legal/articles/the-castle-doctrine-and-indianas-controversial-new-law-FRxbimuYLTKSgBFB/

* https://www.grievelaw.com/wisconsingun/laws/castledoctrineexplained/

* https://app.leg.wa.gov/rcw/default.aspx?cite=9A.16.110

* https://blog.adafruit.com/2026/01/22/autodesk-burns-the-village-to-feed-ai-and-the-cloud-cuts-7-of-workforce/

* https://www.theguardian.com/commentisfree/2026/jan/21/ice-minnesota-trump

* https://bsky.app/profile/margaret.bsky.social/post/3mcyca2lhmy2j

* https://crimethinc.com/2026/01/21/from-rapid-response-to-revolutionary-social-change-the-potential-of-the-rapid-response-networks

* https://en.wikipedia.org/wiki/Family_Radio_Service

* https://risingsun4x4club.org/xf/threads/frs-base-station.29672/

* http://code.kratzgullicksonlabs.com/

* https://en.wikipedia.org/wiki/One_Battle_After_Another

* https://palmettostatearmory.com/1000-rounds-of-pmc-bronze-9mm-fmj-124-grain-ammo.htm

* https://www.investigativepost.org/2026/01/16/buffalo-mayor-to-ban-city-cooperation-with-ice-others/

* https://en.wikipedia.org/wiki/Transponder

* http://www.runoffgroove.com/littlegem.html

* https://github.com/miguelgrinberg/microdot

* https://en.wikipedia.org/wiki/Modern_technique#External_links

* https://f3d.app/

* http://3dp.kratzgullicksonlabs.com/?printer=8ce580623bed8e5f9fe2b7a43c0179e4#/

Jason J. Gullickson, 2026

Another Project

Sun, 25 Jan 2026 18:28:37 -0600

Jason J. Gullickson, 2026

The KGL Multidimensional Print Shop

Mon, 26 Jan 2026 18:47:25 -0600

To celebrate Jamie & I's 25th anniversary we decided to get a space for our printing activities. At KGLMPS we'll be working with printing technologies that span centuries.

Now seemed like a good time to do this.

I'll have a lot more to say about this soon.

Jason J. Gullickson, 2026

The Interenet Is Slow

Tue, 27 Jan 2026 07:56:19 -0600

The Internet isn't slow, but it often feels slow because websites are slow.

Websites are slow because... well I honestly don't know all the reasons but I do know how they are slow, and I know they don't have to be. Allow me to show you.

Search

Searching the web is probably one of the fastest of the slow websites. The results are somewhat fast, but finding what you want might not be. Most contemporary "search engines" are not search engines at all but "suggestion engines", or more honestly "marketing engines". They will make it easy and quick to find what they want you to find, what makes the the most money, but if what you really want is something else, you will have to work for it.

A fast search website would quickly connect you with what you asked for and nothing you didn't ask for. This involves asking in a more specific way, but you'll find that once you're used to it finding what you're actually looking for is so much quicker and so much less distracting that you'll wonder how you ever tolerated using the marketing engine to find things.

Shopping

Online shopping, when it's serving the interest of the shopper is really a specialized subset of Search, and a shopping experience which builds on the person-orientation of the search engine described above feels much faster than what we're used to now. It requires far less software and therefore far less hardware than contemporary shopping websites therefore reducing operating costs and at least theoretically reducing the costs of goods.

Some will say that there is value to shopping that isn't "laser-focused" on immediately finding exactly what you're looking for, and perhaps this is true. However I don't think it's good to add drag to people who are shopping for what they need just to make the experience more valuable to those who are shopping as a form of entertainment itself. Separating these activities would allow people to complete the needful tasks with minimum time and expense, and I think it could improve the "shopping as entertainment" activity as well if it were carried-out in a way divorced from shopping for necessities.

Let's get technical for a moment...

A transactional, relational database is the ideal tool for building an online store. A catalog of products from a collection of vendors selected by a list of customers integrated through purchase transactions, it's hard to thing of a better use for an RDBMS. Several performant RDBMS's are available and the best in my opinion is PostgreSQL.

A PostgreSQL database housing the data can be made interactive with a fairly simple web application written only in HTML and PHP. It could amount to perhaps as few as six pages. For the customer: Catalog, Cart, Orders and Account; for the Shopkeeper: Orders and Customers. These pages could be served using the NGINX web server, and the entire thing could run with an average sub-second response time with a catalog of thousands of items on a server the equivalent of a Raspberry Pi.

Media/Entertainment

This might seems like a challenging thing to make fast, but those of you who know me know that this is an area where I've done some of my best work. A media website, be it music, videos, photos or what have you can be another simple database coupled with a large-capacity storage system and a means of conforming the stored media to the needs of the web browser reproducing them (this is often called "transcoding").

As always we start with PostgreSQL to store the data, mostly "metadata" (information about the media) but also typical "account" information for the people using the website, their relationship to the media files and perhaps albums/playlists/etc.

To interact with this data I propose three pages: Account, Collection and Search. There may be a need for an "administrator" interface, but I don't want to jump to that conclusion.

Socializing

As of late my belief is that online systems whose primary purpose is social interaction were a mistake, so I don't really want to help make more of them. Some might consider this a cop-out and argue that there's something about online social networks that requires complex software and large, scalable infrastructure that would make them incompatible with the rest of the systems described here. I of course disagree, and one need only look at the size and scope of the Fediverse for an example.

The Fediverse runs on software capable of good performance on the Raspberry Pi-scale hardware I'm using for these examples, and I think compatible software could be written even leaner than what's out there today (although I could be wrong, there are some pretty extreme examples already). So I won't pursue an example here, but when I build the rest of the software described in this post, maybe I'll throw it in just for fun.

Reference

By reference I'm referring to storing, locating, retrieving and maintaining finished documents. This is distinct from more dynamic systems where change is constant but there is some overlap.

This sort of system is one where an RDBMS like PostgreSQL doesn't make a lot of sense, and historically consumes more resources than simply serving the documents from disk. So what I propose here is a hybrid, which uses PostgreSQL for any necessary administrative data, and perhaps as a search index (although I'm not completely sure about that) and then uses a standard filesystem the documents.

The more I think about this one, the more I think it might just be another form of Media. I'm going to leave this here for now and consider combining those two.

Banking

What do we want out of online banking? To check account balances, to view transactions, to transfer money between accounts and perhaps manage account information or other "metadata".

This is another choice application for an RDBMS. Most banks don't actually use their websites or apps to directly manipulate account data (that is done by more trustworthy systems) so most of the data stored in the website's database will be limited to what's needed to display the pages, authenticate members, etc. Perhaps this database will be used as a "caching" layer between the website and the real back-end systems to limit their workloads, but for the most part what's needed to provide a fast banking website is simple.

Four pages: Accounts (the bank kind like checking, savings, etc.), Transactions, Statements and Account (the website kind). For the bankers I can see three pages: Customers, Accounts and Transactions. I don't know much about being a banker, but here again I imagine the "real" banking stuff will be handled within the real back-end system.

What Else?

There are probably billions of websites, and while I think the categories above cover a lot of them I'm sure there's other types that I've overlooked. If I add "personal websites" to the list, I think this list covers most of the websites I use on a daily basis, so I think it's a good start. That said, if there's something important that I left out that doesn't roughly fit into one of the categories above, let me know and I'll think about it.

What I want to do next is implement working examples of each type of website described above running on hardware equivalent of a Raspberry Pi and see if I can prove that they can be fast. I've got more ideas to follow, but one step at a time.

Jason J. Gullickson, 2026

Online Social Networks with a Purpose

Wed, 28 Jan 2026 08:03:33 -0600

Yesterday while I was writing about rewriting the web, I kind of glossed-over (online) social networks because I thought they did more harm than good. I qualified this by referring specifically to websites with no purpose other than socializing. I gave that more thought overnight and I'd like to explore it a bit further because I think there's some good that can come of it.

I often draw an analogy between Facebook and "the bar nobody likes but everyone can agree on". This is more of an explanation as to why anybody continues to use Facebook, but the bar analogy is interesting in the context of places of social intercourse and purpose.

Note: Feel free to substitute "bar" with coffeeshop, bowling alley, shopping mall or any other physical location where people meet that has a purpose other than being only a place for people to meet.

Where the bar analogy falls-down as a comparison to Facebook is that a bar has a purpose: to sell hooch. People congregate, meet, become friends, start fights, share experiences and all sorts of other things at the bar, but the bar would cease to exist if it wasn't able to make money selling drinks.

Having a purpose also constrains who you might be socializing with. People in any bar are either: people who like alcoholic drinks or people who are friends with people who like alcoholic drinks. In many cases the filtering is even more specific, selecting for a specific range of drinks (beers vs. cocktails), activities (watching sports, playing pool, etc.) and atmosphere. This "pre-selection" process matters as it increases the potential for compatibility between patrons as well as reducing the chances of conflict.

I think this purpose is critical, and explains why such online meeting places become toxic when they have no obvious and visible purpose.

Don't get me wrong, I know Facebook has a purpose in this sense, one that pays the bills, but it's never been honest and up-front about this purpose because if it had, nobody would have ever walked through the front door. Facebook's purpose is to spy on the people who go there, and it stays in business by selling the information about you that it secretly gathers. Would you go to a bar if there was a sign on the door that said:

"Drinks are free so long as you give us permission to sell everything about you and your friends to people who want to take everything you have, your mind, body, soul and treasure, many of which want to imprison or kill you"

I wouldn't, and I don't think most people would.

But that's Facebook's purpose, and how Facebook pays the bills. The same is essentially true for all websites whose only purpose is to be a "social network", it appears to be the best way to cover the costs of running a singular planet-scale site.

Contrast this to websites that serve a more obvious purpose in addition to being a place to hang-out. Special-interest forums, for example, can become "spicy" but general the conflicts tend to self-correct when everyone involved remembers why they are there in the first place (a common interest). These conflicts are at times severe, and occasionally do fracture personal relationships but as far as I know they have never led to the installation of fascist dictators or the fall of democracy.

At least not yet.

All this is to say that I don't think online spaces for socialization are harmful or worthless. I myself have benefited greatly from such spaces, but when I reflect on something close to four decades of interacting with people in cyberspace the good ones have always been places that had a purpose other than simple congregating people for not other reason than congregating them, and the absolute best have been where we were working together on something to benefit the common good.

Jason J. Gullickson, 2026

ghost.town

Thu, 29 Jan 2026 07:57:16 -0600

Somewhere around the end of the 1990's a friend told me a story about someone having a conversation with their email autoresponder. As the story goes, my friend gave somone his email address one night when he was on vacation. When he returned from the trip a week later, he found a series of emails from this person, the first sent the day after he shared his email address. The amusing part was that when his autoresponder responded to the first email, the other person responded to this response without realizing that it was a machine. Bizzarely this process repeated several times before the person on the other end finally figured out what was going on.

This got me thinking: given the great volumes of correspondence stored in an email archive, could an autoreponder mine this data to produce an even more convincing, perhaps even useful response?

What I came-up with was a simple algorithm that would examine the inbound message and then piece-together a response by searching for similarities in previous email conversations (of which Gmail users had years worth of stored in an "archive" folder by then). This resembled what would now be called a Markov Chain.

I never built this, not for any particular reason other than I didn't think the results would be useful beyond being amusing.

Over the years I revisited the idea and considered it in different contexts. The most intriguing to me was the idea of ingesting historical correspondence to generate theoretical replies to contemporary questions from historical figures. Again I didn't pursue it, because it seemed to be distasteful, as it felt like waking the dead.

Of course today something like this would be trivial to implement using an LLM trained on the letters and other communications.

This leads to a very weird thought: what if you created a number of such creatures, perhaps hundreds or thousands and gave them their own social network in which to communicate with each other?

The network would be composed of such "digital ghosts" only, no interaction with the living (although the living could observe). It would, of course require some "stimulation" as such models do not normally engage in spontaneous action, but it's not hard to imagine how to simulate the type of stimulus one of these individuals might experience in the physical realm (reading a newspaper, consuming a meal, etc.). With an appropriate set of stimuli applied to each entity on a regular basis a steady stream of emissions would be fed into the network.

Like any social network these ghosts would have "friend/follow" relationships, resulting in the output of one being fed into the input of others, resulting in a continuous cascade of conversation. Some relationships might be "seeded" (for example, I'm sure that Thomas Jefferson would follow Ben Franklin) and others might happen organically through network interactions.

One thing I'm not sure about is allowing the output of each ghost to be fed back to itself as input, allowing it to evolve. This seems like a reasonable step, but also, these are ghosts, and maybe they should stop learning after death.

Like the other ideas in this train of thought I'm never going to build this. The most obvious reason is that I find LLM's abhorrent. There's probably lots of other reasons these ideas are bad as well, otherwise why wouldn't I have realized them in the past? Regardless of my own personal reasons, I respect that nature has a reason for creating us to die, and far be it for me to second-guess her judgment.

Jason J. Gullickson, 2026

CybreCredit

Fri, 30 Jan 2026 07:09:16 -0600

Ever since I wrote that post about making the web fast I've been running thought experiments for the various websites I described and for many of them there is a shared keystone: the banking site.

In the original post I assumed that a banking site would be a thin veneer over the top of an existing, traditional, banking system but when I started thinking about building some of the other websites I found that I need a way to provide that banking function and I don't happen to operate a bank that I can "skin" with a website and electronic interface.

So I started thinking about how I would implement such a thing "from scratch", and came-up with CybreCredit. The most obvious way for me to describe it is to walk-through the process of using it, so here we go...

To begin, you visit the website of a CybreCredit branch and enter your email address. You'll receive an email with a link you can click to log-in.

This email-based, passwordless authentication is used throughout all of the websites I'll be describing in this series. I hate passwords, and authentication itself is something I want to eliminate as much as possible and the only complication I can see to this mechanism is handling email address changes smoothly.

Since this is your first time logging-in a new account will be created for you with a $200.00 credit limit. You'll be prompted to enter a PIN which will you'll be required to present for any transaction that places a charge against your account. Once you select a PIN you'll be taken to the Transactions page. This page displays your remaining credit at the top along with a list of transactions for the current month. It also contains a "New" button you can use to create a new transaction for things like sending money to a friend, transferring funds to another account, etc.

Selecting a transaction from the transaction list displays the Transaction Detail page which includes the transaction date, amount, account the transaction was made with and detailed information about the transaction provided by the person or system who created it. This page also includes a "Dispute" button that can be used to challenge transactions that you're not sure about (transactions can only be disputed during the month in which they take place, after that they are permanent).

In addition to the Transaction List and Transaction Detail pages there is an Account page where you can provide additional details about yourself as well as download statements and find information about to paying-off your balance.

At this point you're ready to buy some things!

When you visit an ecommerce site and make a purchase, you need only provide:

* Your CyberCredit account name (branchname@your.email@yourdomain.com)

* Your PIN

The ecommerce site will then process the sale like so:

1. Check your available credit to make sure you have enough for the purchase

2. Fulfill the purchase

3. Charge the final purchase amount against your account

Steps 1 and 2 are simple REST-style HTTP requests against the branch's CybreCredit API. Two requests are needed in case something goes wrong during the fulfillment process to prevent getting charged for something that wasn't delivered, etc.

The final transaction amount will include a 1% transaction fee that goes to an account owned by the branch. CybreCredit doesn't charge interest because charging interest is a sin, so operating costs are covered by a simple, flat fee applied to all transactions. Whether this is presented as a fee to the buyer or "baked-in" to the price of goods is up to the vendor's discretion, but it will always be 1% forever.

Back at the branch, the requests are displayed as a transaction in the transaction list. Only one transaction is displayed as the initial "auth" request will be replaced by the actual charge request once it's completed.

Once a month all transactions are rolled-up into a statement that is available for download from the Account page and the transaction list is cleared. After the statement is generated you'll get an email indicating that the statement is available and a request to pay your outstanding balance. There is no penalty for unpaid balances other than the fact that the balance is carried-over into the next month, reducing the available credit. Each time you pay-off the balance, your credit limit will be increased by the amount of the payment.

I find this interest-free/debt-oriented approach interesting because it allows people to dip their toes into the system without having to invest any real currency. You can try things out with little risk beyond spending some of your time. It is a little tricky because of course there is a high likelihood that accounts will accumulate debt that is never paid-off, but as far as I can tell it's only ever the branch's problem (buyers get their goods, sellers get their payment) and by keeping the initial credit limit fixed and somewhat low the risk is somewhat predictable. This, coupled with the fact that I imagine at least the early shopping experiences in this experiment will be digital goods with at least potentially zero costs after producing the first unit make the whole gamble somewhat safe (I think).

How do you pay-off your balance? The simplest way is to remit a payment to the branch in whatever currency they accept. Another way is to provide services to other members who compensate you by transferring funds to your account. You could also open an ecommerce site and sell products.

"just open an ecommerce site" might sound like I'm ignoring the significance of the cost of such an endeavor but I have some ideas about how to make that a lot more accessible that I'll talk more about in a future post about CybreMall.

The last thing I'll mention about CybreCredit in this post is branches. In order to keep scale in check, the system is designed so that the size of a given server is limited. I'm not exactly sure what this limit is yet but it will be a matter of how many accounts or transactions-per-minute the reference hardware can reliably sustain. My SWAG is 1000 accounts. So CybreCredit is designed to work in a distributed fashion, and by including the branch name in account names it's fairly simple to determine which branch should process a given transaction. Exactly how two branches coordinate such a transfer is something I need to think about more (I have a few ideas but I want to simulate things a bit more), but this allows the system to grow without a huge up-front investment and reduces the "blast radius" of outages or failures.

I must admit that this kind of feels like it might be illegal, or at least be subject to some sort of regulation, but on the other hand I don't see how it's any different from the "in-game" currencies used by things like Fortnite or any other game in which you can buy in-game credit using meat-world currency. For now I'm not going to worry about it because at this point it's all theoretical, but if someone knows more about this than I do I'd love to hear from them.

Jason J. Gullickson, 2026

Downlink 2026-01-30

Fri, 30 Jan 2026 07:17:16 -0600

Damn I just noticed I totally butchered the title of the last Downlink... I need to pay more attention to what I'm doing...

* https://jasongullickson.com/downlink-2006-01-24.html

* https://www.reddit.com/r/turntables/comments/1d7060j/teac_tn180_or_audio_technica_atlp60x/

* https://teacusa.com/products/tn-180bt-a3-turntable

* https://duckduckgo.com/?q=AT-LP60X&kd=-1&t=epiphany&ia=shopping&iax=shopping

* https://www.turntablelab.com/products/teac-tn-180bt-semi-automatic-turntable-w-bluetooth-cherry

* https://www.turntablelab.com/search?options%5Bprefix%5D=last&q=AT-LP60X

* https://pypi.org/project/printguard/

* https://lithub.com/

* https://mplsintheblind.org/posts/2026-01-26/

* https://www.php.net/manual/en/install.unix.debian.php

* https://stackoverflow.com/questions/19674456/run-postgresql-queries-from-the-command-line

* https://www.w3tutorials.net/blog/systemd-start-service-at-boot-time-after-network-is-really-up-for-wol-purpose/

* https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html?__goaway_challenge=meta-refresh&__goaway_id=a05dffc318a6f60efffeb7d6b93b654b

* https://stackoverflow.com/questions/58577325/how-to-automatically-restart-systemd-service-on-failure

* https://github.com/BelfrySCAD/BOSL2/wiki/threading.scad

* https://bandcamp.com/the_rectifier

* https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Transformations

* http://3dp.kratzgullicksonlabs.com/?printer=8ce580623bed8e5f9fe2b7a43c0179e4#/

* http://code.kratzgullicksonlabs.com/jason/universal-combat

* http://mainframe.kratzgullicksonlabs.com/

* https://www.youtube.com/watch?v=efozROpM-vE

* https://kyoshoamerica.com/rccar/miniz/mini-z%20awd%20subaru%20impreza%20wrc%202008%20readyset%2032657wr.html

* https://cults3d.com/en/3d-model/game/subaru-alcyone-svx-hamzaf3d

* https://cults3d.com/en/3d-model/various/subaru-svx-pre-supported

* https://cults3d.com/en/3d-model/art/96-subaru-svx-acylone-miniz-xmod-body-shell

* https://cults3d.com/en/users/printinghub/received-makes

* https://cults3d.com/en/3d-model/game/subaru-svx-1992-printable-car-in-separate-parts

* https://cults3d.com/en/3d-model/game/subaru-svx-gauderio

* https://cults3d.com/en/3d-model/home/subaru-svx-wheels-shop

* https://cults3d.com/en/search?q=subaru%20svx

Jason J. Gullickson, 2026

31 days, 31 posts

Sat, 31 Jan 2026 14:23:52 -0600

Sometime near the end for 2025 I was talking with Jamie about how there's nowhere to go on the Web to learn about new or cool things or to find inspiration without being bombarded by the hellish state of the world. Don't get me wrong, we both understand the importance of being aware of these things, but we also deeply value consent, and sometimes you need to learn about something cool without having Donald Trump forced down your throat so you can rechage your batteries and have capacity to do constructive things about what is happening to us all.

So at the end of December I decided that I would try to write at least one post per day in January, and they would all be something fun or cool or at least constructive. There were a few days where it was impossible for me to say anything positive, so I doubled-up on other days to reach the final count of 31.

Today I'm writing this from downtown Beaver Dam rom what I refer to as The Kratz-Gullickson Laboratories Multi-Dimensional Print Shop (KGLMDPS). I'm surrounded by ways to print things: a Provisional Press making Lego prints, a Woodzilla press making lino prints, an old-fashioned washing mangle making... I'm not sure what to call them but also a photocopier, a Creality Ender 5+ 3D printer and soon an OrangeStorm Giga (once I can get some help moving it out of the lab...). It's an eclectic mix of old and new, well-defined and hybrid processes and all of it creative and invigorating.

This is a commercial space, smack dab in the middle of downtown and it really hit me today what a difference it makes to be working in a place where you can walk to everything you need. At home we are walking distance from some essentials, and overall Beaver Dam is a small enough town that you can get around on foot for the most part, but being right downtown is different.

Just across the atrium is Bones in Jars (we're in the same building), across the street is my favorite book and antique store (the same place I scored a nice set of Baby Advents and learned how to re-foam loudspeakers), next door to that is our friend's shop knitting supply shop Firefly Fibers, then a Mexican grocery and around the corner is our indie bookstore Rosalie Book Boutique, Ooga Brewing Company, Nunatak Coffee, the list goes on.

There's also a lovely river walk and a small park on the corner just downstream from the dam, and even on winter days like this there's locals and visitors strolling the walks. Yesterday there was a vigil/protest for the victims and against the occupation of ICE and all of this is food for creative thought. It's not hard to think about things we can do in our little space to help everyone.

Jason J. Gullickson, 2026

The Garbage Movie

Sun, 01 Feb 2026 08:41:36 -0600

This morning I was talking with Wes about how what I love about making art films is that it removes most of the barriers that get in the way when making non-art films. I remarked that even the budget and equipment barriers are gone now because you could literally dig through the garbage and find the equipment you need to meet the minimum criteria for an art film: moving pictures.

Then the though occurred that you could not only get the equipment for free from the trash, but you could probably get people to pay you to take it.

The idea is this:

Setup an e-waste collection event that requires a payment of $5 per piece of e-waste. Only accept e-waste that includes the things you need to shoot the film (cameras, computers, monitors, lights, etc.). Announce this via some form of online thing (Craigslist, Facebook Marketplace, etc.) and run it for a half a day or whatever it takes to get the equipment you need. By the end of the day you'll have not only the gear you need to shoot but a budget as well.

Open-source software plays a big role in this, because virtually any junk computers can run the software you need to edit, mix, master and release a digital film. This would have not been possible if you had to somehow pay for the software you need to install on the garbage computers. It also allows you to use footage captured on virtually any available camera, write the script, print the cue cards, make movie posters, master DVD's, etc.

Bonus points, film the e-waste event itself as a documentary to show other filmmakers how it's done; maybe write a book, or perhaps even begin a new filmmaking movement.

Double-bonus points if you actually shoot the film you set-out to shoot in the first place.

We'll give this a shot sometime in the future, but if you decide to give this a try I would love to hear about it and promote your project.

Jason J. Gullickson, 2026

White Fire

Mon, 02 Feb 2026 07:47:41 -0600

I was going to start a new tradition of posting a song on the first of each month, but then I forgot about that yesterday.

Better late than never.

Jason Tiffany, 2020

jmail

Tue, 03 Feb 2026 07:25:59 -0600

Yesterday I was reaching-out to an old friend who I've lost contact with over the last few years. Our primary method of contact was Facebook, and I've since been locked-out, so that was that. Then I was listening to some of his music and realized I might be able to contact him via Bandcamp, and sent him a message.

I didn't hear back, and I have no way of knowing if it's because his contact info at Bandcamp is out-of-date, or maybe he doesn't want to write me back, or maybe he sent me an email and it was eaten by the beast...

This got me thinking about how much I wish Internet email still worked. I've complained about this a million times so I won't go deep into it again, but tl;dr Google destroyed it with Gmail.

There are of course other ways to communicate electronically but they are all so fractured and incompatible and faction-developing and hardware-intensive that there's still nothing like Internet email used to be: universal, usable from anywhere, on virtually any computer or device, across the shittiest of networks, etc.

I could propose creating something new to take its place, but how would that be any different from all the other things I just complained about in the previous paragraph? I guess I could make a list and check it off...

* Works on virtually anything

* Works over even the shittiest network

* Universal (should probably define this more)

* Compatible despite factions

Let's start at the top

Works on virtually anything

Whatever this is, it needs to have low enough hardware requirements that it can work on anything. What does that mean? Right off the top of my head the best fit I can think of for that is Micropython, since it has both incredibly low hardware requirements and enough features to write a network application. That's still a higher than ideal bar (not likely to work on 8-bit micros... I don't think at least) but it's pretty low, and should work on most of the things that people connect to the Internet these days.

Works over even the shittest network

To me this means compact messages (in terms of data size), possibly "chunkable" (so the whole thing doesn't need to be delivered at once) and probably a store-and-forward network so messages can "hopscotch" their way across the network even when connectivity is intermittent. This is how Internet email originally worked (and maybe does to some extent still, but I don't think so). It's also how Meshtastic works (although I'm not sure it uses any sort of "chunking"). Meshtastic might seem like exactly what I'm looking for but it fails a number of the other criteria because it always requires some specialized hardware even if you use it with a "commodity" device*.

What I have in mind would be designed for TCP/IP networks, at least initially, but it would be smart to keep alternatives in mind so that it's easy to add support for other networks, or at least easily create "bridges" that could allow messages to traverse other types of networks or transports**.

Universal

What I mean by this is the ability to send messages to other people regardless of choices like computer and phone brands, operating systems or even "client applications". For example Signal is great, but you can't send messages to people using Signal from anything but Signal, which means you can only use devices Signal supports. This limits the use of Signal to a prescribed set of devices, and leaves you at the mercy of Signal's developers to keep things up-to-date, to implement Signal in a way that's reasonable for you, etc. Consider Internet email on the other hand: there's a million different email clients and they could all sent messages to one-another (back when most people used Internet email). Part of this is designing a "protocol" that can be implemented by anyone, and part of it is including a universal addressing scheme to direct messages in a way that isn't tied to a specific piece of client, server or networking.

Compatible despite factions

This is somewhat addressed by using a public, shared protocol as described above, but it might need to go further than that. The purpose of this requirement is to design the system in a way so that it can't be co-opted by one person or one company the way that Google co-opted Internet email. This might be the hardest requirement because it can't simply be designed to defend against a known threat but must anticipate potential future threats to sovereignty of the system.

I don't have a perfect answer to this off the top of my head, but making it easy to make clients and other software that are compatible with the protocol might go a long way to "outrun" anyone trying to capture the system, and actively avoiding "profit centers" (ways to make money off controlling the system) might help as well. Keeping the resource requirements low might help as well, because if it's easy to use the system yourself then you're less likely to want to delegate that to some third party. Other conveniences like keeping spam and other abuses at bay might help as well.

Solution Time!

One possible system could be built on JSFS federation. Messages are composed however you like and POSTed to a local JSFS instance at the JSFS address of the recipient:

POST http://localhost:7301/.com.jasongullickson/inbox/

The local instance attempts to push the jnode change and message data as jblocks to its' known peers. If this fails due to the network being down or the peers being unreachable, it retries***.

JSFS authentication, federation (especially propagation) has been discussed in detail elsewhere, so I won't go into much more detail than this here.

On the recipient side, the client polls the "inbox" at whatever frequency the person running the client feels is appropriate. Since it's polling against another local JSFS instance, polling frequency has no impact on the network.

GET http://localhost:7301/.com.jasongullickson/inbox

Is it really that simple? Let's work the list

[X] Works on virtually anything

A Micropython implementation of JSFS with federation is in the works, which as discussed earlier would run on almost any piece of hardware with network capabilities. A client capable of sending and receiving messages in the way described above using such a JSFS instance is easily within the capabilities of being realized in Micropython as well.

[X] Works over even the shittiest network

JSFS federation natively provides store-and-forward functionality which should be suitable for any type of network connectivity no matter how intermittent, and the block-orientation of JSFS storage (as well as deduplication) should function well even over high-latency and low-bandwidth networks as well as fast, always-on connections.

[X] Universal

JSFS addresses do not depend on any external infrastructure for resolution. They bear a resemblance to DNS names (and are compatible with them), but by no means are they dependent on DNS. JSFS federation automatically circulates the jnode structures which are used by JSFS to resolve addresses to data in the form of jblocks, and anything capable of running a JSFS instance can participate in the network.

[?] Compatible despite factions

Certainly the proposed implementation traverses factorization in the form of device or operating system fractures, but I'm not sure exactly how it repels other types of attack on the network. I think by running locally via Micropython the technical and administrative overhead is low enough to avoid the trap of delegating this to a corporation, and given the meager resources needed to run a functional communications system (even large message size and volume would be fairly reasonable by contemporary hardware and networks) things like "free hosting" traditionally used to capture systems like this have less appeal.

The big hole I see is any active form of defending against abuse. It seems like I've solved this to some degree before with JSFS but I don't recall the details off-hand. This would need to be addressed if this solution is going to be resistant to companies or other entities which would use providing these features as a way to compel people to delegate hosting, etc. to a third party.

What's Next(tm)?

I think I've made a reasonable case for using JSFS to build a new communications system to provide a means of communication akin to that we once enjoyed via Internet email. I still don't think it's quite as good (if nothing else it won't solve the problem for existing devices that only support Internet email) but it addresses all of the things that I personally find limiting about other electronic forms of communication.

Given this I think it's worth experimenting with. First I will need to complete the implementation of JSFS with federation for Micropython, but after that a simple proof-of-concept should be fairly straightforward to construct.

Jason J. Gullickson, 2026

* I could certainly be ignorant to things about Meshtastic that invalidate this claim.

** Technically, a store-and-forward system would allow for lots of physical transports since a node could store a message in one physical location and then travel physically to a different location to connect to a separate network and forward the message, essentially a physical transport or "automatic sneakernet".

*** How long it retries could be client-selected, or a network default or both, I haven't thought it through enough yet to say for sure what's best.

Universal Combat

Wed, 04 Feb 2026 06:18:46 -0600

I think we've all wondered at one point or another "Who would win a fight between X and Y?". Universal Combat is a computer game that simulates a fight between any two combatants*

The game is text-based. The player can select from a number of pre-defined combatants or add new ones by filling out a simple form.

The form consists of the following questions:

* Name

* Pronoun (how they announcer will refer to them if not by name)

* How strong are they compared to an average human?

* How smart are they compared to an average human?

* How emotional are they compared to an average human?

* Are they an inanimate object?

* When were they born/created?

* List some of their parts (optional)

Some of this is self-explanatory but I'll go into detail about a few of them.

The "stats" (strength, smarts and emotion) are expressed as a multiple of the combatants traits compared to an average human. For example, an average human has a strength of 1, so a heavyweight boxer might have a strength of 1.8 or 2. A human's level of emotion is 1, a brick's level of emotion is maybe -10. These are not intended to be precise and the person adding the combatant to the game shouldn't stress over it too much. If all else fails use the weight of the new combatant relative to the weight of an average human for its strength.

Combatants can be inanimate objects just as in real life you can fight a brick. The brick won't fight back, but if you keep punching it you'll certainly get hurt, and if you keep going, chances are you won't win.

Parts is a list of parts that will be used to describe the fight in more detail. It's entirely optional as the announcer can simply say "Joan Rivers punches the chair", but it's more fun if to say "Joan Rivers uses her hand to hit the chair on the seat".

I'll point out that these fights are entirely hand-to-hand and while you could certainly add something like a Sherman Tank as a combatant, it will just sit there and do nothing since you can't combine it with a tank pilot to make it do something. You can also create an Army Sniper combatant but during the fight they will not be a thousand yards away with a rifle but standing next to their opponent in the arena with little more than perhaps gloved hands.

As you may have gathered the fight is described blow-by-blow in a way that resembles a radio broadcast of a boxing match or football game. Combat happens second-by-second and the action of the combatants happens simultaneously as in a real fight (as opposed to turn-based with some sort of initiative determining who goes first). The combat algorythm determines who strikes when and how and what the effects are. A fight ends when one combatant is physically destroyed or so emotionally devastated that they loose the will to fight.

The algorithm is not random and the outcome of each fight is deterministic, but not necessarily predictable. I'm not going to give it all away yet because I don't want to spoil the fun, but what I'll say is that it doesn't involve "rolling dice" like other simulations and uses something that I think it unique in the realm of combat simulation or role playing games.

Jason J. Gullickson, 2026

* ...and maybe more?

The Digital Bug-Out Box

Thu, 05 Feb 2026 07:20:59 -0600

I could have sworn that I've written about this before, but looking back over the posts in this blog, I don't see it....

Most people have a fire safe for their important papers where they keep things like passports, titles, diplomas, small valuables, irreplaceable photos and family memories etc. These are often small boxes that are designed to survive a fire and can easily be taken with you should you need to suddenly leave your home due to some emergency.n

The Digital Bug-Out Box (DBOB) is a version of this for your electronic valuables.

Think about how many of the things you hold dear or depend on exist in electronic form. Photos, home movies, financial statements, medical information, etc. What would happen to these things if you suddenly had to leave your house, apartment, etc.? Maybe some of these things are in "the cloud", but I think all of us are starting to doubt trusting cloud providers completely to take care of our precious, personal or private information.

Beyond these obvious things, there's a lot of other data we cherish and depend on. Music collections, books, films, personal projects and even video games often exist now online in the form of electronic files.

Imagine if you could have something like a fire safe that automatically kept these electronic things safe.

This idea came to me when I was using a Raspberry Pi to monitor one of my Bluetti solar generators. It was awkward having the little computer board just sort of dangling off one of the USB ports of the Bluetti for power, and I thought that maybe there's enough room inside the case to cram it inside there. Once I thought about this, I realized that if I crammed the Raspberry Pi inside the case, I would have a self-contained, portable general-purpose computer or "server" that could be used when the power goes out or taken almost anywhere. So I started thinking about what I might do with such a thing and the idea of using it to preserve precious electronic files was born.

Since then I've experimented with designs that go much further than simply slapping two off-the-shelf components together. The current design is modular, allowing the amount of backup power, storage and computing resources to be customized to some degree.

The most basic configuration consists of a roughly 300Wh of standby capacity, DC output via USB-A and C, 100W solar charging input and maybe an inverter for AC output (I'm not 100% sure this is worth it). On the compute side a single board computer with a multicore RISC-V processor with WiFi and Bluetooth connectivity and 1TB of redundant storage would be standard. Physically, the device resembles a large lunchbox or small cooler with a sturdy case and an integrated handle. Weight is around 15lbs depending on exactly what components are used.

I've considered making it fire-resistant but there are some very hard problems combining useful levels of fire resistance with a device that has electrical and radio connections, so for now I'm setting that aside. If there is a demand for it, a variant could be designed that provides fire resistance perhaps at the cost of loosing some connectivity options.

Under normal conditions the device works similar to a NAS. While atached to utility power, it maintains it's internal charge and connects to the local WiFi network. To other devices on the network it looks like a regular storage device (a network drive), and a "client" application is available that can be installed on computers and phones to automatically back them up to the device.

In addition to simple file storage, the device also appears as a network printer. When you print to the device, it stores the document as a PDF. This allows virtually any type of information to be stored on the device in format that can later be read by almost any type of computer. These files can be accessed directly via the network drive, or though a web-based search interface hosted by the device. The device also provides other web-based applications for viewing photos, watching videos and listening to music. It's possible to provide other applications although I'm cautious about this because the applications must be written to run efficiently, otherwise they could jeopardize the primary utility of the device.

When the power goes out, or when you have to hit the road, the device can provide it's own WiFi network you can connect to. Once connected, you can continue to use the device just like before.

I've considered some additional functionality as well that would allow these devices to work together. It's not hard to imagine a scenario where several groups of people come together with these devices and could benefit from being able to share resources and/or expand their network coverage across a larger area. So long as measures are taken to ensure the privacy of personal data, there's no reason this sort of collaboration couldn't be part of the system, and I have several designs in mind for implementing just such a thing.

When time allows I'll complete a prototype unit and do some field testing. Personally, I think the most challenging part for me is creating the device and os-specific client software since I long ago gave-up mobile device application development. I'd like to think there is some "universal" application interace I could target to develop these programs, but given that they will, by their nature, need access to most of the data on the devices I don't think that's an option. The network filesharing and "printer" interfaces for storing files on the DBOB could cover a lot of this, but they require conscious effort on the part of the person using it and that feels less than ideal for a device that is intended to be as helpful as possible in an emergency.

Jason J. Gullickson, 2026

Stone Soupercomputer II

Fri, 06 Feb 2026 07:13:30 -0600

The Stone Soupuercomputer was an early Beowulf-class cluster assembled from whatever way laying-around. It's name is a reference to the story about a soup made from a stone (and whatever else the village had available). At the time, the primary motivation for creating this system was a lack of budget, but since then it's also been a way to make hardware that would otherwise be destined for the dump useful again.

I built a similar system out of scrap machines in the 90's when I was working as a consultant and it not only taught me a lot about high-performance computing, it also ran a few practical applications at speeds higher than any of the single high-end servers we had at the time.

Over the year's I've experimented with building various HPC clusters, perhaps the largest of my own was an 8-node, 32-core machine built out of discarded G5 ProLiant DL360's.

The downside to these scrap supercomputers is primarily the cost to operate them. Older hardware tends to be less energy-efficient, which tends to add-up when you start building clusters. For example, that DL320-based system could theoretically pull about 6KW running at full speed, and idled around 1KW. When we were using this system to help find a vaccine for COVID-19, my utility bills doubled.

I have experimented with using ARM and other lower-power machines but that gets into the real of "new" hardware, which defeats the purpose of the Stone Soupercomputer. Not only this, these devices are simply not as well-made as discarded workstations or enterprise equipment and while the old machines tend to have slower processors our outdated GPU's, etc. they are often equipped with good amounts of RAM and solid I/O subsystems, both key to high-performance applications.

After talking with my friend Matt (and the the fediverse) about the trade-offs of designing & building new laptops vs. reviving old ones, I started to think about ways to use old hardware in general, and specifically how I might make a cluster built from older, less energy-efficient hardware use less power.

Here's what I've come-up with so far:

Modern Software

Contemporary Linux distros provide a lot more in the way of power management than the old versions did. Some energy-efficiency gains could be had simply by upgrading the operating system on these old machines and putting some work into tuning these settings. There may be limits due to older machines having less hardware support for power management, but I think you could knock the numbers down a bit just by spending time tuning the software.

Coordinate software power management with workload scheduling

The way clusters like this are used is very different from how you use a personal computer or even a server. They tend to run large, scheduled jobs that run for a long time. To do this they employ cluster management software that keeps track of the overall system's capacity, health and schedules where the individual tasks that make-up the overall job will run.

Normally power management software has to "guess" when you will need the most power from your computer but on a supercomputing cluster this is usually well-known in advance. Minimally we can assume that if the job scheduler doesn't have a job running, the system can essentially be "parked". This knowlege could be used to put nodes in the cluster to sleep or even turn them completely off (if it's possible to wake them back up again from the scheduler). Given that these jobs run for days or weeks, the small amount of latency associated with booting-up a node won't have a large impact on the overall time the job takes. At the other end of the job, nodes can be powered-off as the work for the job winds-down, and there may be even more efficiency to be found in how the work is structured.

For example: a large simulation might distribute "chunks" of the world being simulated to each node in the network. As these nodes complete their work they might write-out the results to their local disk, where at the end of the job the results are collected and collated. If instead each node moved it's output to a central location, it could power-down sooner than it could if it had to wait until the entire job was complete.

There are countless ways to optimize hardware utilization when it is an objective in designing HPC workloads. Much of the software in this space (not only the jobs themselves but the infrastructure software) is designed for an always-on environment, so I think there's a lot of room for improvement here.

External Power Management

Building on the last section, what about hardware that can't turn itself off, or be turned back on by the scheduler? For this I'm imagining simple software-controlled outlets that can physically remove power from the nodes (or even other equiptment like switches) in the cluster. Versions of this capable of handling 15A are very inexpensive and can be controlled via a simple REST interface. Most bring the additional advantage of providing power useage data, so it would be possible to know exactly how much electricity is being used.

The scheduler could use these outlets to coordinate safely shutting-down equiptment with removing power altogether, allowing the cluster to idle-down to amost zero energy use. Even machines capable of wake-on-lan can't reach zero.

Another option is to involve a standby power source that can be controlled by the scheduler. Aside from preventing work from being lost during power outages, even an off-the-shelf Bluetti power station could be used to enhance power management.

For example, such a device could intelligently switch between running the cluster on grid power to battery power to "time shift" drawing power from the grid to times when demand is lower. This not only reduces the cost of electricity but could also be used to draw power when renewable energy is most avaliable.

Another option is to add solar panels to the mix and power the cluster directly from the sun when it's available.

A third way that a device like this could be helpful is by allowing "oversubscription" of a lower-power circuit by the cluster. For jobs that the scheduler knows won't last longer than the available standby power, the cluster could draw more amps from the battery than the circuit supplying it would allow. For example, if the power station has a 10KWh capacity, it could deliver 2KW to the cluster for for a five hours job even if it's fed by a 15A (1800W) circuit. The power station can do this because it can "backfill" the additional power from the energy stored in the battery, then replenish this after the job is complete. The net energy consumed is the same but by allowing a lower-power circuit to be used the cluster can operate in more common environments and possibly from lower-energy sources like solar, wind, etc.

Coordination with HVAC

The last thing I'll mention is that net energy use could be lowered by coordinating the clusters activities with broader environmental effects related to heating and air conditioning. The most obvious form of this is offsetting the need for heating a space by reclaiming the heat generated by the cluster. To a degree this happens automatically as a thermostat will turn a furnace on less often if the cluster is heating the air in the same room. A step further would design the system such that the heat from the cluster is more evenly distributed (perhaps vented into the intake side of a forced-air heating system) and ensuring that the thermostat is able to take this secondary heat generation into consideration.

A more advanced form of this might more directly integrate the HVAC with the cluster. For example, consider a liquid-cooled system that places it's radiator in the HVAC system stream or maybe even integrates in a direct way with a heatpump system to re-use the existing plumbing. It's not hard to imagine how the heat differentials produced in a predictable way by such a system might be used to offset energy use elsewhere in the broader system.

Another option is to move that heat outdoors, in climates where outdoor temperatures are low enough to make a difference. The bluntest way to do this would be to move the cluster to a non-climate-controlled space outdoors in the winter, but it's not hard to imagine slightly more convenient ways to accomplish the same thing.

What's Next(tm)?

This is just a few things that came to mind when I started to reconsider using old hardware again. I've used these things most of my life but at some point I stopped because I thought the ecological impact of increased energy use justified discarding the old equipment in favor of new hardware and new designs. But now I'm reconsidering this, because there is simply a lot of this old stuff around, and while it is recycled to some degree, there's still a lot of waste.

This is compounded by the processes used to create new things. A friend who worked at a scrap yard referred to it as an "above-ground mine". She often mused about how wasteful it is in terms of both finance and life to dig metals out of the ground when all the metal we'd ever need has already been dug up, refined and is now sitting on the ground waiting to be used.

Maybe the same applies to computing hardware. Maybe all the compute we'll ever really need has already been made, and we simply need to find ways to re-use it? I think reviving The Stone Soupercomputer as a proof of concept is one way I can help test this theory.

Jason J. Gullickson, 2026

Downlink 2026-02-06

Fri, 06 Feb 2026 07:20:41 -0600

Right day, right title this time!

* https://www.turntablelab.com/products/teac-tn-180bt-semi-automatic-turntable-w-bluetooth-cherry

* https://pine64.org/documentation/STAR64/_full/

* https://github.com/BelfrySCAD/BOSL2/wiki/threading.scad#module-threaded_rod

* https://github.com/BelfrySCAD/BOSL2/wiki/constants.scad#constant-slop

* https://www.turntablelab.com/collections/portable-turntables/products/audio-technica-at-sb727-sound-burger-turntable?variant=40264679653466

* https://www.turntablelab.com/search?q=The+Dead+Milkmen

* https://duckduckgo.com/?q=10t85+microswitch+metal+roller+right+angle+spdt&iar=images&kd=-1&t=epiphany

* https://duckduckgo.com/?q=robie+sr+robot+omnibot&kd=-1&t=epiphany&ia=web

* https://omnibot2k.com/omnibot/omniinfo.html

* https://omnibot2k.shop/index.php?main_page=index&cPath=3

* https://en.wikipedia.org/wiki/Omnibot

* https://daboodesigns.com/collections/robotics

* http://www.theoldrobots.com/zpr.html

* https://duckduckgo.com/?q=unaibomber%5C&t=epiphany&kd=-1&ia=web

* https://en.wikipedia.org/wiki/Network-attached_storage

* https://duckduckgo.com/?q=omnibot+tape+programming&t=epiphany&kd=-1&ia=web

* https://www.theoldrobots.com/prog2.html

* https://github.com/jkoets/robot-tape-command

* http://code.kratzgullicksonlabs.com/jason/robot-tape-command/src/branch/main/USER_GUIDE.md

* https://github.com/charmbracelet/wish

* https://codeberg.org/jjg/viperboard

* https://store.micro-swiss.com/products/micro-swiss-ng-revo-direct-drive-extruder-for-creality-ender-5?_pos=4&_sid=138a5f672&_ss=r

* https://duckduckgo.com/?q=e3d+revo+parts&t=epiphany&kd=-1&ia=web

* https://www.filastruder.com/products/revo-cr-heatercore?_pos=19&_sid=63a8bada9&_ss=r&variant=39740011184199

* https://www.filastruder.com/products/e3d-revo-sprite-for-creality-printers-heatercore?_pos=57&_sid=63a8bada9&_ss=r

* https://en.wikipedia.org/wiki/Stone_Soupercomputer

* https://en.wikipedia.org/wiki/Beowulf_cluster

* https://duckduckgo.com/?q=proliant+dl360+g5&kd=-1&t=epiphany&ia=web

* https://foldingathome.org/diseases/infectious-diseases/covid-19/

* https://hackaday.com/2018/03/21/everyone-needs-a-personal-supercomputer/

Jason J. Gullickson, 2026

Early Birthday

Sat, 7 Feb 2026 19:27:48 -0600

Thanks ma!

Jason J. Gullickson, 2026

The Print Shop

Sun, 08 Feb 2026 14:42:17 -0600

A friend on the fediverse asked me a very good question during a discussion about work, and the problems of doing quality work when you're abstracted-away from the people who actually need and use the things you make:

"What kind of things do you envision building for direct customers?"

This seemed like a question that I should have an immediate answer for, but I no longer do. The reason is that so many of the things I would have responded with have been well... enshitified, and while I could try to do unshitified work in these areas, I don't think I could escape the gravity well of the enshitifiers, especially if I were doing so in the sort of professional or commercial setting necessary for it to be a way to make a living.

I spent almost a week thinking about this before I had any new ideas.

During that time I worked on other things and tried to pay attention to what I enjoyed doing that wasn't squarely in the cross-hairs of enshitification. The activity that stood-out was spending time at The KGLMPS, designing things to print and working on the machines.

During this time I talked to a number of friends who have complemented the design and fabrication work that Jamie and I have done together, much of it involving 3D printing but including related work as well with electronics and such to produce decorative items, furniture, props, etc. Some of these friends have purchased some of the things we've created and others have commissioned us to help them produce things of their own design, desire or interest.

All this got me thinking that maybe this is the answer to my friend's question about work. But what exactly is "this"?

You could call it "3D printing", but I don't think that's it. It's not only an oversimplification, but saying "I want to be a professional 3D printer" doesn't convey the range of design, engineering, testing and finishing that goes into this work. It often includes elements of drafting, CAD, CAM, mechanical, software and electrical engineering.. I think it also limits the imagination of people who I'd like to work with because I wouldn't want them to think we could only realize things through a single process.

So what I need to think of is a name for the service of helping produce something someone wants or needs, with a narrow enough scope to limit it to things we can enjoy producing but wide enough to let people's imagination run wild enough to get excited about what we can do. I want to find a term for this that conveys the excitement, the creativity and the collaborative nature of what we do as well. I also want to frame it in such a way as to make it clear that it's a dynamic thing, something that can't really be captured and enshittified. If the process becomes something that can be turned into something that doesn't require creativity and care then it's not something we'd likely continue to do.

I'm not sure what to call it, but I'm sure that it happens to fit-in with what we've stared at KGLMPS. This could be a coincidence or it could be a self-fulfilling prophecy, but regardless of what you call it I think it's awesome.

We're going to be on a little trip for the next week or so and one of the things I'm going to noodle-on while in new, stimulating environments is what the next step looks like along this path. When we return I plan to start implementing whatever we manage to come-up with.

Related: Don't expect to see much here other than weird photos until we get back.

Jason J. Gullickson, 2026

CA 1

Mon, 9 Feb 2026 16:57:54 -0800

Consent-Based Authorization

Wed, 11 Feb 2026 20:13:16 -0800

Forgive me, I'm typing this one with my thumbs.

Consent-Based Authorization (CBA) is a means of requiring consent in order to access a resource. This differs from other schemes which require separate authentication and authorization steps in a number of important ways. It provides a number of advantages over existing schemes which will become more apparent as I describe a real-world scenario:

An author publishes a document which requires consent to the system and shares the URI for this document.

A reader accesses this URI and receives a prompt that access requires consent. Consent can be requested by providing one of several communications methods (email address, SMS number, etc.). The reader provides an email address and requests consent.

The system sends a message to the author via a communication method provided by the author when the document was published. The message indicates that this is a consent request for a specific URI and includes metadata about the reader's request that the author can use to decide whether or not they consent to the access. Once the author decides, the reader is notified via the communications method they provided and if consent is granted this message contains a augmented version of the URI that includes a token. This new URI is refereed to as a Consent URI or CURI (pronounced "curry").

If consent was granted, the reader now has 24 hours to access the document via the CURI. If the CURI is accessed after 24 hours have passed, the reader will again be prompted for a communications method to request consent. If the reader provides the same method as before, they will be able to access the document immediately. If not, the author is contacted to provide consent and the cycle begins again.

Why is this better than current approaches?

Consent is an agreement between two people. CBA involve third-parties, it doesn't require the reader to create an account on the system storing the document nor does it delegate this authentication to "yet another system".

Consent must be reaffirmed. Just because it was OK for the reader to access the document now doesn't mean it will be OK tomorrow. It can also be revoked immediately if the Author deems it necessary.

Consent cannot be delegated. CURI's can be shared, but can only be used by others if the details of the readers communication method are shared as well. This requires a significant amount of trust and discourages sharing with just anyone.

CBA respects privacy. The only communications information "permanently" stored in the system is the Author's, and even this is deleted if the document is removed. Readers communication information is stored only long enough to send the consent response (24 hours max), after that it is deleted. Anywhere else a reader's communications information is needed (for example, accessing the CURI) a cryptographic hash of the data is used instead. Passwords are never used, let alone stored.

The idea for CBA came to me when thinking about ways to continue publishing things on the web and sharing links that are accessible by people but resistant to unwanted advances in web scraping for the purpose of training LLM's. There's been a few attempts at this, but all of the ones I've seen rely on either client-side programmatic things that only work in certain browsers or delegating the task to some (usually private, corporate) third party. The blunt solution is to make the resources "private" but that requires either creating a new authority yourself (and requiring readers to create yet another username and password) or again delegating that authority to and trusting a third party,

CBA does away with authentication and focuses only on authorization and to the best of my knowledge is the only mechanism that does this. By doing so it provides both the ability to share URL's publicly that are durable as well as protection from access by random traffic. It makes granting access a personal choice between two people, a human-scale operation.

CBA is also fairly easy to implement. I've already started figuring out how to implement it in JSFS, but it could be implemented in other HTTP services as well. I won't try to explain the technical details until I have a real keyboard handy but I'll post a follow-up once I can demonstrate it in JSFS and provide pointers to how it might be implemented in other HTTP-based services.

Jason J. Gullickson, 2026

CA 4

Thu, 12 Feb 2026 17:08:30 -0800

CA 5

Fri, 13 Feb 2026 15:51:09 -0800

CA 6

Sat, 14 Feb 2026 19:04:55 -0800

Hello, Operator

Sun, 15 Feb 2026 05:47:38 -0800

hello-operator is a command-line file sharing tool. Using it looks like this:

$ hello-operator

Operator > what's your number?

< T-6-5000

Operator > what city are you calling from?

< madison, wi

Operator > and what city are you calling?

< green bay, wisconsin

Operator > ok hon, what number do you want to call?

< k-1640

Operator > one moment please...

Operator > your call has been connected, have a nice day!

< ?

say: send text

package: send a file

goodbye: hang-up

< say hi

k-1640 > hello, joe!

< package

> What's the filename?

< ~/Music/satisfaction.flac

k-1640 > Receiving .................... Done!

< goodbye

dialtone

When Hello, Operator starts, it attempts to connect to a "switchboard": a known server on a public Internet address. If a switchboard cannot be reached it says "we're sorry, your call cannot be completed at this time. Please try again later".

Once it connects to a switchboard it asks for your number, city and state name. This is what it will use to uniquely identify your node (if the city-state are already taken it will say "that line is in use, try another"). Once an unused city-state combo is found it is written to a local config file and the "calling from" question won't be asked again.

Next it asks for the "number", this is used to encrypt the data sent over the connection. Technically this can be anything, but it's more fun (and easier to remember) if you use a phone number.

At this point the switchboard attempts to connect the two nodes. If the connection is successful, commands can be used to send text and files directly and securely between the two nodes. If not, the operator responds with "Your call cannot be completed as dialed, please check the number and dial again".

How does this work?

When the operator connected to the switchboard, the switchboard noted the IP address you are connecting from and the random network port that was opened by your router/firewall for incoming connections (this is how any webserver/etc. sends data back to your computer). When you gave the operator your city-state, this IP-Port combination was stored in a database in the switchboard under that name. The same thing happened when the person you want to send files to ran hello-operator.

Once you provided the "number" you want to call to the operator, it looked-up the IP-Port for the city-state you requested in the switchboard database. If found, the operator attempts to send a message to the address associated with the city-state over its network port in the database, encrypted using the number you provided. If the message is able to reach the node, this "destination node" then attempts to decrypt the message. It should decrypt to a special "line test" message that the operator on the other end will use to repeat a similar test in the other direction. If this conversation is successful in both directions the call is considered connected.

At this point commands like "say" and "package" send data directly to the receiving node as if the two machines were on the same routable network until one sends the "goodbye" command.

Why?

I've been frustrated for a long time by the fact that something as simple as sharing a file has become so difficult, and in most cases requires setting up an account with and trusting a third-party. There are some tools that are supposed to work without doing that, but they often require messing with your router/firewall (which for me isn't an option) or they simple fail to work for mysterious reasons.

I think hello-operator will traverse most firewalls automatically and while it requires a you to use a public "switchboard", the switchboard doesn't require an account and stores no data of significance.

I have some more thinking to do about how the city-state naming could be abused, but if it becomes a problem storing it is a convenience that could be eliminated.

Once the call is connected the switchboard is out of the picture, but if you want total control you can run your own switchboard as the system requirements would be incredibly low and it could be run on the tiniest of ISP/VPS providers. The only really valuable thing it needs is a known, public IP address and port.

There is no transport security per-se, but any data transferred between the nodes is encrypted on the sending node using the "phone number" key. This key is never stored on either device, only in the caller's mind (which is why something memorable like a phone number is used). Not that privacy is the primary objective, but because the key is never stored electronically, this may be more secure than any other electronic filesharing system that (at least that I'm aware of). This also makes the switchboard simpler as it doesn't need to do the CPU-intensive work of encrypting/decrypting data and doesn't even require an SSL/TLS certificate.

Jason J. Gullickson, 2026

CA 7

Mon, 16 Feb 2026 15:30:17 -0800

CA 8

Tue, 17 Feb 2026 17:28:24 -0800

CA 9

Wed, 18 Feb 2026 11:48:44 -0800

My Pong

Fri, 20 Feb 2026 18:16:45 -0600

pong

I've always loved Italian design and wondered why it seems like everything designed in Italy is beautiful. I've started to study this and along the way got distracted by early videogame consoles. I of course knew about Pong, but I didn't know that there were numerous Pong-like games designed and sold around the world in the pre-cartridge days.

This fascination started with the ping-o-tronic, which I ran across during my aforementioned studies of Italian design. The games themselves are the sort of ball-and-paddles games you'd expect but the external design of the hardware is quintessentially Italian.

Under the hood the original version was built from a little discreet 7400 series logic and a lot of analog electronics. Later iterations used a sort of "pong-system-on-a-chip", the AY-3-8500.

There were a number of game systems based around this chip (chipset?), but my favorite turns out to be the East German Bildschirmspiel 01.

Not only does it have an awesome name, but there's just something about the "German-ness" of a machine intended for entertainment that I love.

For reasons I can't explain this has inspired me to take a swing at designing my own take of game console based on these chips. I haven't settled on a design just yet, but I want to do something whose physical form draws from my own culture and put a spin on the standard games that reflects something personal as well. If this infatuation lasts long enough to yield any results, I'll certainly share them.

Jason J. Gullickson, 2026

Soundburger

Sat, 21 Feb 2026 16:16:25 -0600

We needed some music at the print shop and vinyl didn't seem practical but Jamie correctly pointed-out that listening to vinyl would force us to take a break occasionally. How could I argue with this wellness advice?

I wanted something compact and self-contained, but I've found most portables and all-in-one record players to be bad, not only from a sonic perspective but they are also hard on records. This is fine but I've grown picky and if it's something I'm going to spend hours listening to I'd need to find something better. After an exhaustive search I found one all-in-one player that I thought would be perfect (Andover SpinPlay) but at over $700 it's beyond what I could justify spending.

I considered restoring some vintage gear since you get a lot more quality for the money (especially when it comes to listening to vinyl), but given that I still havent finished restoring the yard sale turntable I picked-up last summer, I didn't think anyone would be happy with waiting an infinite amount of time for me to finish such a project.

So back to the Internet I go hunting for something that will fit the physical and budgetary needs and also not sound terrible and also not ruin our records.

I initially didn't consider component systems because I didn't want to waste too much space with a sprawling web of gear (we need the room for printing after all) but then I remembered that I had another (vintage) Model One that is mostly unused in the library. These little radios sound surprisingly good for the tiny amount of room they occupy, so if I could couple this with a turntable (ideally without needing an external preamp) that might be constrained to consuming an acceptable amount of space.

I still didn't want to spend a fortune on the turntable, which meant making some compromises. I'm very spoiled to have a restored vintage Marantz at home so I had to accept that I wasn't going to find something approaching that level of quality without creeping-up on the amount I already rejected for the all-in-one. After more searching I narrowed it down to two contenders which might not seem to be remotely related, the Teac TN-180BT and the Audio-Technica Soundburger.

The Teac had a few things going for it including a wood deck that would be a close match for the cabinet on the Model One. On the other hand, it's fairly large, and for a number of reasons I wasn't sure about the sound quality.

The Soundburger on the other hand was a complete wildcard. It was lacking almost anything I'd look for in a decent turntable but it was also tiny, and interesting, which made me more excited about taking a chance on it than the more traditional xyz.

Since I was compromising on quality anyway I decided it wouldn't make much difference in that department between the two decks, so I decided to gamble on the 'burger. Having listened to it for a couple days now, I have to say I'm happy with that decision.

Let me start by saying that from a sound quality perspective, I'm unable to hear the 'burger's limits within the limits of the Model One. That may be due to the Model One's sonic envelope as much as anything, but for the types of music we listen to at the shop this is a totally satisfying level of quality. I had concerns that it might sound as bad as some of the cheap portables I've had before and I can say that with this combination that is not the case.

The only audible deficit I could find was during the last track of The Crow soundtrack (side C) where it seemed like maybe the 'burger wasn't able to hold the playback speed constant and correct. I'm not sure what exactly the cause of this was (I thought maybe the battery was dying but that wasn't it), and I haven't noticed this on any of the other dozen or so records we've listened to, but I thought it was worth mentioning.

So it sounds as good as anything else I could have hooked-up to the Model One, and if I was going to take the Model One out of the picture the cost goes up about $500. That's a fair deal IMHO.

Now on to how the Soundburger is different from every other record player or turntable I've ever owned.

As you can see it doesn't have a normal 12" platter but instead a tiny (4 inch?) platter that the record balances on and hangs waaaay over on the edges. The player sort-of "clamps" around the record during playback. A small "open" lever is pressed to open the clamp revealing the tone arm and platter.

I put "clamps" in quotes because it doesn't actually apply any pressure to the top of the record but only surrounds it.

Before loading a record the tone arm needs to be swung out of the way. At the end of the swing the tonearm will "click" into a parking position leaving room to load an LP. The arm is small and light and feels fragile so the first time I did this I was overly-cautious, but if you persist you'll feel a solid "click" as the arm depresses a switch which disables the spindle motor and locks safely into place.

The tonearm rests on a round rubber "puck" when stored. This puck doubles as both an adapter for 45's and a record clamp for LP's. In either case it needs to be removed from it's storage place before a record can be loaded.

Once the arm and puck are out of the way you drop a disc onto the spindle like any other turntable. Then the puck is slid snugly onto the spindle clamping the record in place and finally the lid can be closed and locked back into position.

A press of the "power" button turns the LED next to it from red to white and moving the tonearm out of it's "parked" position sets the record spinning. At this point you drop the needle in the groove like any other turntable.

The 'burger is not an automatic so the record just keeps spinning when you get to the end of a side. Lifting the needle and moving the tonearm back to its parking position stops the turntable motor and you can open the lid, remove the puck and flip the record.

There are other features. It has two speeds, it has Bluetooth, but I haven't tested either of these yet and probably won't. The line-out is analog and fed directly to the line-in jack of the Model One creating a perfect analog signal path from groove to speaker, what else could you want?

It will be interesting to see how it holds up over time. It is sturdier than I expected it to be, but it's still pretty delicate compared to the Marantz. It doesn't have a removable cartridge but it does have a replaceable needle, so baring any major accidents I expect it will be around for awhile.

Jason J. Gullickson, 2026

Growing Solar

Mon, 23 Feb 2026 08:33:15 -0600

This morning I was looking at our expenses and our energy bills have gone berserk over the last year while our consumption has actually gone down. I have a number of theories that explain this, but I'll set that aside for now.

This has me thinking the time may have come to get serious about getting the house off-the-grid since that's the only way we'll have any control/predictability around these costs. Of course there's lots of other good reasons to do this, so it's not a hard case to make, but this one might be the easiest to justify financially.

That said I really don't know how much it would cost to do such a thing, especially if it was purchased "off-the-shelf" and the installation was hired-out. Normally I'd love doing something like this myself but there are codes and also roof work and if you've seen our roof you'll understand why nobody (myself included) wants me working up there.

It does make me wonder though if there could be an incremental path for this though. To some degree I've experimented with this by adding some standby capacity in the form of homebrew solutions and off-the-shelf Bluetti "solar generators", but having done this for a few years it begins to feel a bit like "building a ladder to the moon". There's a lot to love about the Bluetti devices, but after some inconvenient issues I'm not ready to trust them with the day-to-day operation of the house, especially because when things go wrong with them the answer is "ship it to us" which isn't really going to fly when we start talking about 10's of killowatt hours worth of batteries and roof-mounted solar panels...

Another hard part about implementing such a system is sizing. A lot of people simply look at their current usage and then try to scale an off-grid system to match that and wind-up disappointed by the cost. Others try to cut their usage to the bone and design the system around that, but that isn't likely to lead to satisfaction in the long run. An incremental approach might solve both these problems by reducing the initial cost to something small and adding cost incrementally to scale the system up. At the same time, it gives you an opportunity to learn about how you really use electricity and make more informed decisions about where you can reduce usage. I've done some of this playing with the solar generators I have, and I've found a lot of power going into things that I don't want/need so dropping those KW was virtually painless.

This also can inform other decisions over time as opposed to making all these choices and trade-offs at once when designing and installing a system in one shot.

For example: maybe you decide to part with some enterprise networking gear and replace it with something low-power and focus your work elsewhere when it becomes apparent that the short-term cost outweighs long-term operating costs...

Taking all this into consideration I'm led to think that something like The Digital Bug-Out Box could be the starting point for such an incremental system. I've always intended for the design of that box to be parametric so I could experiment to find the right size, but maybe that could be more than just an experimental aspect of the project. This might simply sound like recreating the solar generator incremental pattern, but the key difference is that my design is open which minimally mitigates the maintenance problem. Being open also makes deeper and more flexile integration possible than with an off-the-shelf, proprietary and closed design.

This does nothing to address the input side of the problem though, and no matter what I come-up with I don't think I can eliminate the use off-the-shelf panels and mount them on the roof. Of course this can be done in an incremental fashion, but the overhead of setting-up and tearing-down to do the work is non-trivial, especially if hiring someone else to do it. I suppose as expensive as the panels are, they don't make up the bulk of the cost in an off-grid system (that would be the batteries), so maybe going "whole hog" on the panels is a wise trade-off? Perhaps for people that don't have an alpine cabin-style roofline could take the incremental option here.

Another design I've considered incorporates a number of features directly into the panel itself; not only batteries but compute and storage as well. This sort of fully-integrated design might fit the role of incremental implementation, especially for people who are unable to deploy a large number of panels on a roof, etc. I haven't actually experimented with/prototyped this design yet, but maybe I should. There's some very interesting dynamics that could be played with here...

All of this tells me that maybe I should be focusing some more time on the projects and ideas I've had in this area. I'm currently in the process of figuring out what to do with my life as my current profession is questionable for a number of bummer reasons I won't drag us all down with right now. Of the things I've considered, tackling this problem incorporates some of my favorites and of course has the added benefit of maybe being useful to help others as well.

Jason J. Gullickson, 2026

Penguin

Tue, 24 Feb 2026 11:25:43 -0600

Reprap 2026

Tue, 24 Feb 2026 11:26:50 -0600

I've been working more and more with off-the-shelf 3D printers but I haven't forgotten the importance of the Reprap project. Some will say that the proliferation of inexpensive consumer-grade 3D printers are proof that the project has served its purpose and run its course, but I couldn't disagree more.

Those working on Repraps continue to push the state-of-the-art of 3D printing forward and many of the things we take for granted from off-the-shelf printers came from the continuing evolution of Reprap machines.

For my part I continue to work on my own Reprap design, SE/3D. The areas I'm seeking to improve is reducing dependencies on non-printed parts ("minerals") and integrating additional CNC processes (milling, lasering and potentially, assembly), but I'm wondering if I should be focusing elsewhere as well.

One area where I see a lot of potential is in feedstock, or the input material to the machine. Most designs assume the availability of prepared filament, but that's a risky assumption outside of major metropolitan areas or where mail-order supplies are not an option, so I've been thinking about ways to extend what a Reprap is to include accepting input material from less refined sources.

The easiest (and one we experimented with in the early days) are existing materials used for other purposes such as line trimmer ("Weed Eater") spools. I don't know exactly what this material is so there may be saftey concerns, but it's a fairly straightforward option.

Another I've seen in the last few years are machines that can "peel" a plastic bottle to turn it into a sort of ribbon that can be fed into an extruder (I'm not sure I've seen this done directly, but I think it's possible). A Reprap design that incorporated something like this could be quite amazing and would definitely expand the range of places such a machine could be operated.

The holy grail of course is a machine that can take chunks of plastic, grind them up or whatever and re-use it for input. Even if it were limited to processing plastics that are commonly used for printing (PLA for example) it would be useful in recycling cast-off failed prints or support material and would result in a lot less waste.

That last one I know folks have been working-on for a long time and at the moment I haven't seen a setup that could be tightly integrated, especially at the scale of a portable machine like the one I'm designing (of course I could have missed such a project if it's out there). So I think for my part I'm most interested in the second option, the bottle peeler.

Coincidentally this solves a couple of problems I've had with the SE/3D design. The first is: where to stick the filament spool. With a bottle peeler it feels more reasonable to just have somewhere to stick a bottle (or two?) on the outside, maybe a couple of pop-out clamps that hold the bottles?

The second has to do with hot-end/extruder selection. It's tempting to use a well-known design but to me that feels a bit like cheating (since again I'm trying to optimize for reproducability) and also my design has some special needs like interchangeable tool heads that might be better addressed with a custom hot-end design. I think that an extruder/hot-end with a design optimized for consuming bottle peels might have advantages over an off-the-shelf design.

I'd love to bring something like this to the Midwest Reprap Fest, time to figure out exactly when that is this year...

Jason J. Gullickson, 2026

1000-ish True Fans for a Non-AI Tech Company

Wed, 25 Feb 2026 08:20:58 -0600

About a week ago I launched a poll on the fediverse to gauge interest in a company that produces technology without the use of "AI"*.

"OK, so let's say me and some friends started a tech company/consultancy that refused to use "AI", would this encourage you choose us over others?

(boosts welcome)"

The results were surprising. First off, it's easily the most boosted toot I've ever crafted. Secondly the results are incredibly asymmetric. Third, the comments were overwhelmingly helpful and encouraging.

Popularity

This toot was boosted 215 times. I know that doesn't sound like a lot from a traditional social media perspective, but it's significant in the fediverse, especially if you consider that it's not a meme, photo of a cute animal or a snarky joke. It's topical for sure but it also requires a little thought, and in my experience that's not the sort of thing that gets a wide-range of attention.

Results

I expected there to be more support for a company that rejects AI in the fediverse than there may be in other social networks, but I didn't expect it to be so extremely lopsided. 60-40 would have been expected, 92-8? Wow.

Comments

There were a handful of confusing-to-disparaging remarks but nothing like what I normally experience from botlickers elsewhere. Most of the comments were overwhelmingly supportive, and several commentators were ready to sign-up!

"I think that "No AI here!" companies are actually a hot, hot thing now. Especially for medical devices or airplanes / flight control. If someone is doing that and is supportive of remote work for software, let me know: I would like to work at such a place. (Preferably if we're making highly reliable insulin-related products.) #getfedihired" - @phf@mastodon.de

There were a number of comments concerned with bias, given that the people of the fediverse may be more sympathetic toward resistance to "AI". I don't see this as a problem, because I would be perfectly happy to serve such a subset of humanity (most of the joy in my life has come at times when I had a say in who I make things for).

Given the strong emotions (and money) involved this subject I was definitely expecting some harsher responses, even if I anticipated the reactions to be mostly positive.

What's Next?

I subscribe to the 1000 True Fans theory and if nothing else the results of this poll prove that there's at least close to 1000 people out there who want to get their technology from people who refuse to use "AI" to make it. That to me is very encouraging, because it at least hints at the possibility of being able to survive being a person who makes things this way.

Figuring out exactly what to make might be the next step, and I think it would be fun to do that in a similarly democratic fashion. What comes to mind immediately is a Ranked-Choice poll listing a number of fixed choices (maybe all software, maybe other tech.?), or maybe make it completely open-ended (although I'd have to somehow limit that to things I know I can assemble a team to make). In either case I'd like a community to decide on what we tackle and what the priority is instead of making all these decisions ourselves.

Once it's know what technology is needed it will be easier to assemble a team to make it, although I don't want to completely commit to that sort of logic. For me the highest priority is philosophical alignment because the rest of the needful things can be taught.

Jason J. Gullickson, 2026

One hand

Thu, 26 Feb 2026 11:44:18 -0600

This is going to be more work than expected...

You wouldnt download a human...

Fri, 27 Feb 2026 09:31:52 -0600

While we were in California I was reading random books I downloaded during the pandemic and got sucked into a book about bioinformatics, (Applied Bioinformatics, Paul M. Selzer). It was way over my head in many ways, but one thing I did understand is that there are a number of public databases of genetic data, some of which are hosted by the U.S. government.

Given the state of things, I thought it would be prudent to back these up.

Starting with www.ncbi.nlm.nih.gov I found that all of this data is available via FTP, which makes the process of backing it up very simple, however after I started I ran into a snag: it's huge.

I assumed it would be a lot of data but I didn't expect terabytes. I couldn't even pull-down the first directory with the space I had on my laptop, and I'm not sure I even have enough room on the pod for it.

Looks like it's time to grow the pod.

I've been using 1TB SATA SSD's to rebuild the pod. I could have sworn that the last one I bought was under $100, but right now the cheapest I can find is $125, not bad but surprising. This has me questioning the choice to use only SSD in this pod.

The rationale behind going pure SSD is that they use less power, make less noise and in general put less stress on the system than mechanical drives. They have less capacity, but I figured that 45TB raw capacity would be enough for anything I'm doing in the lab.

But if the price keeps going up (perhaps driven indirectly by AI datacenter demands?) maybe I should reconsider mechanical drives.

Then there's the matter of expanding the pod on the software size. I'm using ZFS, but it is an old version so not all the options available today are on the table. My understanding is that I'll need to create a new raidz vdev, which means getting at least three new disks before I can do anything.

Getting enough disks for a new pool gets me thinking about the potential of sending the existing pool over to the new one and fixing a lot of problems with the current setup. The pod is running an ancient version of Debian, for long boring reasons. I had intended to remedy this before putting it into production use but well... didn't. Now it is storing about 2TB of data, too much to simply copy to any other single machine that I have online, so I don't want to go messing-around with upgrading the operating system and all that.

But if I had a second pool that I could send this one to, I could safely rebuild it, and even rebuild the ZFS setup so that it's more amicable to being expanded, etc., maybe even experiment with compression, deduplication and all the other cool ZFS stuff.

...of course, this makes me think maybe it's time to finally go beyond ZFS and use JSFS... but that means getting JSFS up-to-date, and probably writing a FUSE or some other sort of thing that will let me mount it like a normal filesystem for the applications I run that can't be adapted to a REST filesystem...

What a rabbit hole.

I think what I might do today is simply park the effort to backup the genome and come up with a plan to build a new storage array big enough to back the current contents of the pod up to. The outcome of that projet will inform all these other choices, and might move a few other efforts forward as well.

Jason J. Gullickson, 2026

Downlink 2026-02-27

Fri, 27 Feb 2026 09:38:31 -0600

* https://github.com/BelfrySCAD/BOSL2/wiki/gears.scad

* https://www.nexprint.com/en/collection/G8416619

* https://jcs.org/2011/08/29/an_ecobee_automation_hack

* https://jcs.org/bluescsi

* https://bluescsi.com/

* https://bluescsi.com/docs/

* https://bluescsi.com/docs/BlueSCSI-Images

* https://mega.nz/folder/8hA3AQCJ#pWUq92L70yDXlogy9lk5Dg

* https://eric.scsi.blue/checkout/

* https://jcs.org/subtext

* https://github.com/jcs/siriproxy-ecobee

* https://github.com/plamoni/SiriProxy

* https://www.chase-small-craft.com/ebds

* https://dnr.wisconsin.gov/topic/lands/turtleflambeau/recreation/water

* https://smallboatsmonthly.com/article/the-turtle-flambeau/

* https://docs.opencentauri.cc/

* https://en.wikipedia.org/wiki/Thermoelectric_heat_pump#Strengths_and_weaknesses

* https://standardebooks.org/ebooks

* https://www.bluettipower.com/products/ac180?variant=44099774480603

* https://www.harborfreight.com/100-watt-amorphous-solar-panel-kit-63585.html

* https://deepbluembedded.com/esp32-sleep-modes-power-consumption/

* https://kk.org/thetechnium/1000-true-fans/

* https://academic.oup.com/nar/issue/54/D1

* https://academic.oup.com/nar/article/54/D1/D20/8378181

* https://www.ncbi.nlm.nih.gov/home/download/

* https://ftp.ncbi.nlm.nih.gov/

* https://marmaladehandmade.com/policy

* https://mcyoung.xyz/2024/12/12/go-abi/

* https://www.amazon.com/Seagate-Skyhawk-Video-Internal-House/dp/B0B1JPYH2Z?s=electronics

* https://www.amazon.com/Crucial-BX500-NAND-2-5-Inch-Internal/dp/B07YD579WM?s=electronics&ufe=app_do%3Aamzn1.fos.9fe8cbfa-bf43-43d1-a707-3f4e65a4b666

* http://code.kratzgullicksonlabs.com/jason/record-table

* https://www.ametsoc.org/ams/advocacy-policy/ncar-information-and-support/

* https://docs.freebsd.org/en/books/handbook/zfs/

* https://forum.proxmox.com/threads/adding-more-disks-to-an-already-exist-zfs-raidz1.88652/

Jason J. Gullickson, 2026

Handsy

Fri, 27 Feb 2026 19:33:49 -0600

Elegoo Centauri Carbon Review

Sun, 01 Mar 2026 09:35:14 -0600

About a year ago I picked-up an Elegoo OrangeStorm Giga and I was knocked-out by it's quality and capability. We've since put at least 50kg of plastic through it with only one significant breakdown that required maintenance.

This is a major improvement over my preview 3D printing experiences.

This made me wonder if the Giga is an anomaly, or if other Elegoo printers are made this well. When it came time to pick-up a small, fast printer for KGLMDPS I decided to find out and picked-up the Centauri Carbon. The "Combo" model had just been released so the standard model was on sale. Between that and a monthly "live your best live" benefit we get at work it cost me about $60 out of pocket, not too big of a gamble.

I won't replicate the information you can find on the website but stick to the things I learned about the machine myself.

Shipping was pretty fast and the machine arrived within a week. Assembly amounted to unboxing it, removing a few shipping screws and installing the display. Once assembled and turned-on the printer walks you through a self-calibration process that takes awhile (30 minutes maybe) and makes a lot of fun sounds.

At this point you're ready to print, and to keep the variables as few as possible I printed one of the models that was already loaded on the machine. It printed a 3DBenchy faster than anything I've ever seen and the quality was decent.

The next thing I did was connect it to the network and check for new firmware (there was none), then try to connect to it with Fluidd, the software I use to remotely manage my other printers. I was introduced to Fluidd by the Giga, then switched my Ender 5+ to use Klipper firmware so I could run it with Fluidd as well. Fluidd couldn't connect to the Carbon, so I pointed a web browser directly at it's IP address to see if something was wrong.

The browser loaded a web-based controller for the Carbon and I was able to manage it from there with no problems. As it turns out, the firmware on the Carbon doesn't provide an API compatible with Fluidd (maybe the same API as Octoprint?), but instead is something different.

Indeed, there is some controversy about the Carbon's firmware, and I found that there are Fluidd-compatible open-source alternatives so I'll have to explore that at some point.

Next I used the standard Carbon profiles provided by Orca Slicer to try printing a few reliable models to test it with my normal workflow and then push the speed and see what happens.

This all went off without a hitch. The only hang-up was that I wasn't able to change the speed on the machine to override the slicing settings the same way I have on other printers. In this case there's a menu with four presets instead of a mm/s adjustment.

The other weird thing is that you can't set it unless a print is in progress. I guess the idea is that it prevents you from accidentally leaving it in a non-default mode, but I wish there was a way to override it.

Next it was time to try something more challenging. I fed it a tray of parts for the T-800 I've been working on. These are small, detailed parts that require support and have particularly challenging small and thin sections. They are printed in a metallic "Silk" type of filament which in my experience can be brittle and have layer adhesion issues.

The first plate came out perfect. The hardest part was finding a way to keep the parts organized after removing them from the build plate (note to self: order more build plates). Once those parts were off I queued-up the next set of even more challenging parts.

The Carbon did a fine job on most of these but struggled some with the last row of parts. What's interesting is that those parts are not a lot more difficult to print than the ones in rows closer to the front, so I'm wondering if position on the build plate made a difference? I'm going to re-run those pieces alone in a more midline position and see what happens.

Overall I'm impressed with the output. With nothing but default settings and automatic configuration it printed almost every tricky part I threw at it as well as I've seen any FDM printer make parts like these. It is literally easier to use and more reliable than a 2D printer (which I know isn't saying much, but...).

Based on the experience so far, I feel like I could recommend this printer to someone with no interest in learning much about 3D printers themselves and they could just design & print things without having to do much more than follow the instructions. There's a number of printers that fall into this category, and what I've heard and seen from people who use them is that they work great until they don't, at which point fixing them is much more difficult than fixing a more "DIY" printer. This could be because you simply know more about your printer when you DIY it, but it also can be due to the more closed and proprietary nature of these machines. It will be interesting to see how the Carbon holds up in this regard, how easy it is to maintain and how repairable it is when something inevitably breaks, how hard it is to get parts, etc.

A few random notes:

Even with the enclosed cabinet and the lids and doors all closed, it can be loud when it gets going. It has a "silent" mode that might help, but I haven't tested that yet. I think most of the noise comes from the cabinet vent fan, which surprises me because on the Giga it's the parts cooling fans that make all the noise.

Speaking of the cabinet, the directions don't recommend using the top cover when printing PLA, but it really cuts-down on the noise so I'm using it anyway. Doing so doesn't appear to have any negative effects so far.

I've read complaints about the interior lighting, but it seems fine to me. I suppose their could be more, but maybe I'm just not that picky? It seems sufficient for time-lapse videos.

Jason J. Gullickson, 2026

The Typing Machine

Sun, 01 Mar 2026 16:57:10 -0600

We're planning a trip to Alaska in the fall and I'm thinking about how it might be a great time to do some writing. Writing by hand isn't an option for me because it's slow, painful and sometimes indecipherable, so I'm thinking about what I'd bring that I can type on.

The obvious answer is the laptop that I'm writing this post on right now, but there's a number of reasons I'm opposed to this.

* This laptop needs to be charged daily

* It does a lot of things I don't want to be distracted by

* If something happens to it, it's very expensive to replace*

* "Software is shit", which means that I can't depend on it if I'm off-the-grid for an extended period

This has me thinking about what I could bring instead that doesn't have these problems, simply put, a "Typing Machine".

I worked on such a machine awhile ago that I called "Type-0". I made some decent progress on that project before getting hung-up on something (maybe a problem with the display?) and then set it aside and got distracted by other things. I could revisit that as a solution to this problem, and maybe I will, but I also enjoy going back to the drawing board and coming up with something fresh. Type-0 grew into something a little more complex than what I have in mind now, and while cool I'm concerned that this additional complexity might have played a role in my lack of attention to resuming the project.

There are of course lots of off-the-shelf answers to a question like this, especially in 2026. I've looked at many of them and have discarded them for various reasons, the most being that they are too complex, too clever or just too expensive.

So I have about five months to figure this out. Could this be the motivation I need to finish a maybe paired-back Type-0, or something entirely new? A lot of interesting tech has come-along since the last time I worked on it and maybe there's something that will get me over whatever hump was in the way at the time?

Still, it's probably a good idea to "timebox" the work somewhat so I can figure out an alternative if the clock starts to run out. Doing so might also encourage me to actually start on it sooner than later. Done right, it's something that could likely find use over the summer as well if it's useful outdoors because this laptop is not.

Hmm... it could also fit-in with my work on the book, because based on what I currently have in mind for the hardware it will have a lot in common with the ideas I'm writing about in there and runs the language I use for the examples in the book. It may very well be the "convivial computer" that I'm considering for the subject of the next book...

Let's make it May Day. Lots of reasons to celebrate on that day, so I'll aim for producing a usable typing machine before that date. If I fail, well then I'll have to look into alternatives.

Jason J. Gullickson, 2026

Joy

Mon, 02 Mar 2026 07:18:59 -0600

Last night I read this post about Beagle Bros software and it reminded me of the most important thing to me about work: joy.

Without joy, what is there? Working out of necessity is, well, often a necessity and this work does not require joy because the discipline is external. But there's no natural law that prevents necessary work from being joyful, that mechanism is a purely unnatural, human-invented behavior.

I believe that care is a prerequisite for joy, which means that it is impossible to find joy in work that you don't care about. Care is a complicated subject on it's own, but it's also simple when you don't try to think about it and instead simply feel it. When you are actually doing something, ask your self "do I care about this?". If the answer is indeterminate, try "why do I care about this?". If you don't have a positive answer to these questions, it's unlikely that you will find any joy in what you are doing, or at least in how you're currently doing it.

There's a lot of money to be made by coercing people to do work they don't care about, in fact you could say that might be the foundation of the entire industrial revolution: increase profit by decreasing care. It's not hard to see how in an environment like that the joy of work was slowly extinguished over the last century or two.

Many have found a route around this by striking-out into new fields on or just beyond the reach of pure industrialization. This is where I was for quite awhile writing software for personal computers. At the moment that once new pasture has been fenced-in by industrialization, and it has been awhile since I have been able to make a living working on something I care about.

No Joy.

But I have reasons to believe that there is a way out of this trap. Writing the book and discussing the ideas behind it with a handful of friends has given me some hope that there are still people in the world who want the personal computing experience that I grew up with. The result of last week's poll have also boosted my spirits and encouraged me to pursue this, and the reflections on the Beagle Bros. from the post that kicked this whole thing off has added more fuel to the fire.

Each of these things reminds me of why I care about personal computers, and making things for the people who work with them. From that care springs joy, and in my experience, joyful work can accomplish anything.

Jason J. Gullickson, 2026

Type-0 Mark II

Mon, 02 Mar 2026 08:18:02 -0600

Now that the Type-0 project has my attention again I've been revisiting it's design and applying everything I've learned since the last time I worked on it to a new iteration. There's a lot to consider, especially given how much progress I've made on the software side in the process of working on the book for computing devices such as this.

I'm calling this iteration Type-0 Mark II.

I think I'll keep the basic form-factor since I see no reason to change it and I chose it in the first place because I like the simplicity of it. I might streamline it a little because it would be nice if it were easier and more comfortable to tuck it away and carry it. I'm considering allowing the display angle to be adjusted, or maybe to add some "kickstand" feet to allow it to sit at an angle on a table, but I'm not ready to commit to any of that just yet.

I'm going to keep the mechanical ortholinear keyboard. A quality mechanical keyboard is essential, and the ortholinear layout is simply the most compact option. I also like the ortholinear layout and the main thing holding me back from using it full-time is that right now I can only use them with a stationary setup. That said, I'm going to try to keep the design parametric enough so it's possible to use a QWERTY keyboard should someone else want to go that way.

The display is another matter. Here I'm torn because I like the theoretical simplicity of a character display but reviewing the journal (and revisiting my own memories) working with this display was a significant source of difficulty the last time I tried to work on Type-0. I think the reason is simple: this isn't a popular way to do things. I will probably take another stab at using the character display, but I'm going to timebox it so wrestling with it doesn't derail progress on the entire project again.

If I decide to give-up on the character display, what will I use instead? My first though is one of the commonly available long rectangular graphic LCD's with an i2c interface. I'd prefer something that works better in sunlight that most TFT/LCD displays, which would put e-ink at the top of the list, but I don't think the commonly available e-ink displays are usable for fast typing, and I'm also not sure if they are available in this desired form-factor. There may be another option that is more ideal, but I'll defer the search for when I know I have to perform it.

For the primary CPU I'm going to switch from the RP2040 to something ESP32-based. This has a number of advantages like WiFi/Bluetooth support but more importantly it aligns with the hardware I'm standardizing on for my Micro/CircuitPython projects making it easier to share software and simply make things easier for my brain. The ESP32 is so cheap, so common and found in so many devices that I'm comfortable accepting some of the trade-offs until I get around to designing my own chip and building factories to produce it.

I'm considering adding an additional MCU dedicated to the keyboard. I like how the direct GPIO approach reduces the part count, but in practice it creates some serious challenges on the software side and it also just gobbles-up GPIO pins that might be fun to use for other things. It might even be impossible when I switch to an ESP32 board (I'm not sure it will have enough available pins). I really don't like the idea of having to stick another chip/board in there with it's own separate firmware, etc. but on-the-other-hand if I do so, I could standardize all the peripheral I/O on i2c which makes for a much tidier architecture.

Another option if I go this way is to manage the keyboard and the display as a unit and treat them more like a serial terminal. This is interesting in that it's a long-established pattern, but it also feels like it might be overly-constraining and I don't want to make any hardware-level decisions that put more constraint than necessary on how the software works.

Oh what else?

I don't plan on changing the power supply any more than is needed if I decide to add a dedicated MCU for the keyboard. I'm toying with the idea of supporting replaceable dry cells, or adding solar charging, but I'm not ready to commit to any of that yet. I think if I could add a compartment for replaceable batteries that is optional, but retain the internal rechargeables that would be cool, but I don't want to give-up the rechargeable batteries for replaceable ones. The only reason I'm considering replaceable batteries is for the exceptional situation where USB power is unavailable. I suppose another option would be to expose a port or some terminals that an external power source or battery box could be attached in such an unusual situation, but that will depend on what ESP32 board is selected and what (if any) on-board charging/power management is available.

I had a lot of other cute/clever ideas for the original Type-0 that I'm going to set-aside this time around because I really want to get to something usable that I can take with on a trip this fall.

That's enough for now, I don't want to spend too much time in my head on this before laying my hands on it. With any luck I'll carve-out some time this week to start gathering parts and maybe take a pass at updating the printable parts...

Jason J. Gullickson, 2026

New repo test

Mon, 02 Mar 2026 15:06:40 -0600

Just a quick test after switching the upstream.

Jason J. Gullickson, 2026

Hows the hints working?

Mon, 02 Mar 2026 15:52:53 -0600

Another short post to test the freshly-added RSS-hints tags to see if they are going to work without a fight, or if it's going to get messy.

Jason J. Gullickson, 2026

Pepper's First Mistake

Tue, 03 Mar 2026 06:41:18 -0600

So far I've had pretty good luck with the new printer (Pepper), but this one got away from her.

Jason J. Gullickson, 20206

Chores

Tue, 03 Mar 2026 08:13:02 -0600

My friend Preston gave me a great bit of advice yesterday:

"I've done the dishes and made the bed as a preemptive strike against accomplishing nothing today - so no matter what happens now I have at least that going for me"

This might sound trite or silly but I think it's genius.

I'm often left at the end of the day feeling like I've accomplished nothing, or even moved in reverse from where I was the day before. It's exhausting and demoralizing. But a simple practice like this can really make a difference.

During the pandemic Jamie & I started making the bed on a daily basis for the first time in as long as I can remember. I'm not sure what sparked it off, but it was very helpful because it was one constant during an incredibly chaotic time. Today doesn't feel a lot less chaotic to be honest, so adding a few more rituals to the mix might be just what's needed.

When the weather becomes less obstructive I might add a walk to the lake to the list. I think I could really use to hear some waves before I engage with capitalism each day.

Jason J. Gullickson, 2026

Instigator

Tue, 03 Mar 2026 09:42:41 -0600

I'm not sure if that's the right word for it, but I'm learning that my role, at this point of my life, might be to show a glimpse of what is possible, as an antidote to the status quo.

The solutions I propose are often described "extreme", "impractical" or "overkill". They are often misunderstood or ignored by the people who seem to need them most and as such, are rarely fully realized.

Over the course of my career I've made attempts to adapt myself to meet other's expectations or accommodate them, but it never works out. No matter how hard I try to reel myself in, my ideas are almost always still too "far-out", and the process makes me miserable as well. This used to frustrate me, but now I'm starting to wonder if it's OK.

Maybe my role is to share and demonstrate ideas so far out that nobody will consider using them immediately, but knowing they exist might cause them to push themselves a little further outside of their comfort zone than they would otherwise do? Or maybe they won't accept my ideas now, but maybe in the future they won't seem quite so unreasonable and the memory of the idea will inspire them to try something new.

With this framing, the experience is less frustrating but it begs the question: who is going to pay for this? Personally I have no mercenary desires, but I do have to find some way to keep paying for food, shelter, etc. Perhaps my more clever employers understood this value before I ever did and kept me around for just this reason, while others chose not to.

Jason J. Gullickson, 2026

Type-0 Mark II: Display Choices

Tue, 03 Mar 2026 15:58:16 -0600

As I dive into the Mark II changes the choice of display is at the top of my list. Why? Because the dimensions of the device dictate a lot about the case dimensions and until that's sorted I can't complete the design of the printable parts.

What I know for sure is that I want something with an i2c interface. I learned the hard way that adapting an i2c "backpack" to a display it wasn't designed for is not the path to happiness and while it might be possible, solving that particular problem isn't something I want on the short path I have to getting to something that works (May 1st!).

Another constraint I'm throwing-in is that the display be compatible with Micro/CircuitPython, because as much fun as writing drivers for either of those is (I've done a few), it's time-consuming and if I need to purchase a display anyway, why make it any harder on myself than it has to be?

What I haven't decided is whether or not this should be a character or graphical display. My instinct is to go with a character display like the one I already have because it seems like this would put far less demand on the limited resources of the CPU/memory of the main processor, but my initial searches for parts is indicating that my options for a character display with the dimensions I'm interested in may be limited.

Not so fast...

Maybe I can use the LCD I already have if I skip using i2c and go direct. I just found this example of using such a display with an Arduino and it only takes one more GPIO to drive the 4x40 display than it does to drive the smaller ones, something like a total of seven lines?

https://forum.arduino.cc/t/info-on-how-to-use-40x4-lcd/537453

If that's right, it's not a lot more than the i2c backpack I've been using which only provides a single enable line (which is probably why I couldn't get it to work).

I might try this out and see if I can get the original LCD to work. The only kink I can think of is voltage mismatch between the ESP32 board and the LCD (I can't remember off-hand if the LCD is 5V or 3.5V).

Jason J. Gullickson, 2026

Something's Different Around Here

Wed, 04 Mar 2026 07:05:17 -0600

You may have noticed a change in tone in this blog since the first of the year. That's a deliberate thing, here's the story behind it.

Near the end of 2025 I was talking to Jamie about how inescapable the horror of what has become of America is. I'm not someone who wants to stick their head in the sand and in fact I spend a lot of time studying, fighting against and working to build solutions to these problems. But even I need a break and one place I used to be able to get that was in the fun and weird and beautiful corners of the web.

As the web receded into a handful of systems controlled by the same people destroying America (and the rest of the world, but I can't speak from experience there) it became impossible to spend five minutes on the Internet without being forced to think about them, what they are doing and how you are going to stop them.

Something I've learned a lot about over the last few years is control. As someone who primarily works with things and systems made by people, I was able to spend most of my life believing that if you learned the system you could control it, and if you were in control, you were safe. What has become abundantly clear to me in these later years of my life is that outside of extremely narrow, artificial environments control is an illusion.

This is a good thing, because the desire for control is the root of many evils, and the belief that you can somehow coerce the natural world to be under your control is not only wrong but a dangerous disease of the mind.

So what to do? How to find reliable pockets of joy where one can rest, recover and restore capacity to continue working on a better world?

While there's very little I can control (and there's many good reasons not to even try) this blog, and particularly the writing that appears on it is something I have a lot of control over (at least as much as I have any control over myself). So I decided that in 2026 this would be one place on the Internet where people could go to see something cool or fun or interesting (or maybe confusing) without being subjected to the horrors of reality.

I didn't stop thinking about these things, I didn't stop writing about them and I certainly haven't stopped working on ways to make them better, but for at least one year I'm going to do all of that somewhere else, and if it goes well maybe I'll keep it this way.

Jason J. Gullickson, 2026

Miniblogging

Wed, 04 Mar 2026 07:36:14 -0600

Something else that I decided to do for 2026 is write one post per day. This is turning out to be more of an average as opposed to a single post every day because frankly, there's been a few days this year that I just couldn't write anything good.

Before this change my posts were a mix of longer posts describing a project in detail (often step-by-step) or posts that were a single photo or a couple lines of text. As I embarked on this one-post-a-day journey I noticed some changes in my writing here.

The first thing that became clear was that long, detailed, heavily-edited posts were not likely to fit into the limited time I have to write each day and I had to quickly abandon the standards I had when it came to writing those. What was more of a surprise is that the posts that would have been short notes became longer, because when I relaxed my standards for writing more, I found that I could write more freely about thoughts and ideas that were not fully-formed or realized with a project or experiment, etc. I also cut myself some slack on proof or references, not that I can't produce these but I'm leaving that for more formal documents like project plans, code repositories, etc.

Now that I'm into the third month of writing like this a unique (at least to me) and somewhat consistent form is beginning to emerge. It's shorter and looser than what I'd consider an essay or a blog, but it's more than a tweet or a toot (microblogging), so let's call it a miniblog.

This is of course a reference to the often overlooked class of computers called "minicomputers", which are loosely defined as "smaller than a mainframe, bigger than a microcomputer".

The PDP-8, one of the most iconic minicomputers

I'm sure I'm not the first person to use the term miniblog but without having even done a web search it's not a term I've heard used before, and as a term for the form that is evolving here, it's a very nice fit for the Preposter.us blog system.

I wrote Preposter.us for a lot of reasons, almost entirely personal, so it fits the way I want to work very well but I will admit that there were times in the past where it's workflow gave me some headaches when working on longer, detailed posts that would have benefited from more editing, structure, formatting and tighter control over how media is integrated into the layout. Writing like that pushes Preposter.us out of it's comfort zone and it becomes less fun.

At the other end of the spectrum, "microblog" posts are so small that Preposter.us's automatic formatting leaves much to be desired. Two sentences don't really need a two or three-column layout, and I'm not good enough with CSS to fix that.

But in-between those extremes Preposter.us really shines!

Over the years I've daydreamed about making Preposter.us better and finding an audience for it who would make it a project that might help me get out from under the boot of the tech industry. While I've met some people who "get it", I've had a hard time articulating why it's an alternative to the heavy-duty blogging systems like Wordpress or Ghost or the microblogging platforms like Mastodon.

This realization of the form that I'm deveoping in 2026 and the term miniblogging might be a piece of that puzzle.

Jason J. Gullickson, 2026

ESP32 Dual-Mode WiFi

Thu, 05 Mar 2026 09:14:31 -0600

While brushing-up on the capabilities of the ESP32 module and Micropyhon I ran across a surprise: The ESP32 can function as both the client of an existing WiFi network (ST mode) and a WiFi access point for other devices (AP mode), and Micropython provides support for this.

I could be wrong, but I'm pretty sure this is new with the ESP32 (when I've worked with older ESP devices I thought you had to choose one more or the other). Maybe the ESP32 has multiple radios or something?

In any event this solves a problem I've had with designing devices around these chips in the past. AP mode is a somewhat convinient way to solve the chicken-and-egg problem of getting these things on an existing WiFi network, because you can create a "fixed" network on the device that you can then connect to from a laptop, phone, etc. to configure it, then switch it over to be a client of the established network without having to try and configure it using controls on the device itself (I'm sure you've used a printer or thermostat or something that is setup this way).

The problem is that with the either/or mode you have to connect to the device's access point, configure it, then cross your fingers and hope it connects to the shared access point. If it fails you have to start over and on many devices this requires several steps.

Dual-mode solves this by allowing the device to try connecting to the shared network without disconnecting you from the device's "private" network. This way it can try connecting and if it fails, provide immediate feedback so you can keep trying until it works.

This capability opens the door for other applications as well. I've worked on several projects where having "private" network for a few devices and a shared "public" network would be helpful. I'm often designing devices and systems that I want to be useful without an Internet connection, but that can also make use of an Internet connection when one is available. With Dual-mode, I could have one or more devices connect to a single device in AP mode normally, and when an Internet network is available, that device can connect to the Internet as well, allowing the devices on the private network to exchange data with Internet hosts without having to be reconfigured.

I feel like I'm doing a poor job of explaining this, partially because I'm deliberately avoiding talking about a specific example because I'm not yet ready to talk about it. More to come!

Jason J. Gullickson, 2026

Preparing Bruce

Fri, 6 Mar 2026 12:35:08 -0600

Jason J. Gullickson, 2026

Downlink 2026-03-06

Fri, 06 Mar 2026 14:34:11 -0600

* https://www.youtube.com/watch?v=sN9quQ-ox2U

* https://ministryband.bandcamp.com/album/trax-box

* https://social.coop/@coopcloud/116108321969101076

* https://tv.lumbung.space/w/nzuB248U2LQA1LCn7vYmER

* https://rasterweb.net/music/

* https://simonrepp.com/faircamp/linux.html

* https://codeberg.org/simonrepp/faircamp

* https://www.waveshare.com/wiki/LCD1602_I2C_Module

* https://chrysalide-fr.bandcamp.com/album/personal-revolution

* https://marchintosh.com/

* https://jasongullickson.com/the-typing-machine.html

* https://en.wikipedia.org/wiki/TRS-80_Model_100

* https://duckduckgo.com/?t=ffab&q=Olivetti%20M-10&ia=images&iax=images&iai=https%3A%2F%2Fceis.be%2Fwp-content%2Fuploads%2F2022%2F04%2F3_olivetti_m10gauche.jpg

* https://www.historybit.it/timeline/olivetti-m10/

* https://codeberg.org/jjg/type-o

* https://www.ebay.com/sch/i.html?_nkw=wide%20display%20module&_sacat=0&LH_TitleDesc=0&_odkw=wide%20tft%20i2c&_osacat=0

* https://www.ebay.com/itm/305674804407?_skw=wide%20display%20module&itmmeta=01KJTSMWA5JWTPX1SKJVQ7GTFT&itmprp=enc%3AAQALAAAA0GfYFPkwiKCW4ZNSs2u11xA12zKH5j2V%2B4IZ16X5AQhiNIfnU6epsRkF1wbuXJUuNGKOVJT5RYPe%2BgFGyY0ybXgFflIoYJIG%2FTQC5UiuKqWyOXL%2BqmTkPSIgCNjq9%2BBIq0bgLzplBRO9Idb2rwzHFpnJu1j1NJ3RMG%2BURpbCqERFcpnhbbfJkOKsPVutvwZfDVHoPR783ldiddGE9qwkegs5zJppB8c9dvl4ddJxr3XnV5Bt%2F8XZbWXLF6Ps14d%2Fbac7wpHbV%2BEwTq%2FCcw%2B5MWU%3D%7Ctkp%3ABk9SR6jF09mWZw

* https://www.ebay.com/itm/286012008851?_skw=wide%20display%20module&itmmeta=01KJTSMWA43KHNQTSMK0P9NTG1&itmprp=enc%3AAQALAAAA0GfYFPkwiKCW4ZNSs2u11xD87OCfaj673aNwFi4BXPKPfFPEMkmn6ZlxoXEW%2FbxOACLyP0aQ%2FqTpYXMOBPdaVOSzUO68f%2F0AE4F4Ld4TUmi7e5t7Y0e2AxaEAeUMZGp0lI9z0EoxR125ahytvNK6HiV856Hj8zJhXAGl%2FHsFWKVyk3Riga1ZlbXW4NFBP8o%2FoBvZlmFkK3r1wYvSrH4X%2BTXd%2BKuf8V1bopqFUgC5dcTLxcFRSd0SI%2FvDlIBopVKhnwAB8gyfcVYCiZGNE%2B%2FhdYE%3D%7Ctkp%3ABk9SR6jF09mWZw

* https://github.com/miniflux/v2

* https://miniflux.app/docs/binary_installation.html

* https://evilgeniuschronicles.org/posts/2026/02/27/evil-genius-chronicles-podcast-for-february-27-2026-how-clean-can-your-hands-be-in-this-dirty-dirty-world/

* https://html.spec.whatwg.org/dev/links.html

* https://codeberg.org/jjg/preposter.us

* https://www.kickstarter.com/projects/sc96/3d-printable-arduino-cnc-plotter

* https://merveilles.town/about

* https://wiki.xxiivv.com/site/discourse.html

* https://jobs.wisc.edu/jobs/research-systems-engineer-madison-wisconsin-united-states-7b625d6a-e753-459c-abf3-4a389ba253fc

* https://forum.arduino.cc/t/info-on-how-to-use-40x4-lcd/537453

* https://en.wikipedia.org/wiki/PDP-8

* https://terminator.fandom.com/wiki/Nuclear_power_cell

* https://jobs.qpsemployment.com/

* https://jobs.qpsemployment.com/jb/CNC-Set-Up-Machinist-Jobs-in-Whitewater-WI/13704494

* https://qpsemployment.com/about-staffing-recruiting/join-our-internal-team/

* https://picoide.com/

* https://github.com/BelfrySCAD/BOSL2/wiki/hinges.scad

* https://cs.stanford.edu/~knuth/papers/claude-cycles.pdf

* https://en.wikipedia.org/wiki/Three_Chords_and_the_Truth

* https://innovationyourself.com/esp32-wifi-sta-and-ap-mode/

* https://duckduckgo.com/?t=ffab&q=esp32%20ap%20and%20station%20mode%20simultaneously&ia=web

* https://duckduckgo.com/?t=ffab&q=esp32%20micropython%20wifi%20dual%20mode&ia=web

* https://github.com/orgs/micropython/discussions/18135

* https://en.wikipedia.org/wiki/Useless_machine

* https://en.wikipedia.org/wiki/Bruno_Munari

* https://en.wikipedia.org/wiki/Futurism

* https://en.wikipedia.org/wiki/Manifesto_of_Futurism

* https://duckduckgo.com/?t=ffab&q=claude%20shannon%20useless%20machine&ia=web

* https://la-machine.fr/en/history

* https://futurismo.commons.gc.cuny.edu/from-ideas-to-manifestation-how-words-changed-a-nation/

* https://bylinetimes.com/2025/12/05/how-epstein-channelled-race-science-and-climate-culling-into-silicon-valleys-ai-elite/

* https://grith.ai/blog/clinejection-when-your-ai-tool-installs-another

* https://duckduckgo.com/?t=ffab&q=twisted%20sister%20under%20the%20blade%20lyrics&ia=web&iax=lyrics

* https://jkflesh.bandcamp.com/album/im-your-beggar

* https://en.wikipedia.org/wiki/ArmaLite#Products

* https://en.wikipedia.org/wiki/Irish_Republican_Army

Jason J. Gullickson, 2026

The Heart

Sat, 07 Mar 2026 08:35:14 -0600

I've had more than a few ideas which share the common attribute of being "smart devices", and in general I've treated them as individual efforts with no deliberate shared components. Lately I've been digging-deeper into a specific project and it's evolving into more of a system of components that work together to for different shapes of useful things.

This is the "product" view, or whatever you want to call the perspective of a person who is working with the thing.

As I see it more as a system from the product perspective I start to see how from a technical or hardware perspective the pieces have similarities that could be shared as well. It's a little different because from this perspective, the similarities are not parallel to the product similarities but often orthogonal.

By default I have an aversion to this sort of thinking, because it has a whiff "industrial efficiency", which is responsible for so many evils of our time. So I'm taking this slowly and cautiously to make sure any choices I make are firmly rooted in producing a superior tool of the highest quality and not simply a way to make things cheaper/easier/faster/etc.

At the center of this is the ESP32 and Micropython. As much as I'd prefer a more open piece of hardware there's no denying the availability of the ESP line of MCU's. Not only are they cheap and plentiful now, if the supply of new chips becomes threatened there are countless consumer devices containing these modules. At one time I was deeply invested in the CollapseOS project which was built around the Z80 microprocessor for similar reasons, but at this point I'd be willing to bet there are more salvageable ESP modules out there than Z80's.

Something else the ESP has going for it is the recent switch to the RISC-V ISA, which means that it has a CPU core that can be synthesized in relatively small FPGA fabrics. Using Micropython provides a much higher-level portable abstraction but for me it's encouraging that even though the ESP itself is proprietary, some of it could be recreated out of generic logic if it came to that.

The last thing I'll say about the ESP is that it's often used as a module that can be used in one project and "recycled" into another fairly easily. This makes it particularly attractive to designers like me who aim for cradle-to-cradle hardware.

Micropython pairs well with the ESP by providing a consistent and portable layer over the top of the ESP's proprietary hardware. If I had to move everything from the ESP to another device it is at worst an exercise in porting only Micropython and at best simply copying the firmware from one device to another.

There are, of course, potential exceptions if I use hardware features of the ESP that simply don't exist on other devices, but I do my best to avoid those.

I spent a lot of time considering this layer of the system and very seriously considered writing a new programming language for it. That may still happen someday, but right now Micropython strikes a solid balance between the type of stability and dynamism I want at this layer of the system. Unlike regular Python, Micropython has a narrow and stable language surface area and an integrated module/package system whose modules are more like device drivers than the vast library of overlapping packages available for standard Python.

Micropython also provides a REPL, a user interface not unlike the 8-bit microcomputers I grew-up with which ran BASIC. It's hard to explain this to people who grew-up with seeing programming distinct from using a computer but on something like a VIC-20 when you turn it on the first thing you see is a prompt looking for you to write some BASIC code. This code can be a complete program or it can be a simple as a few functions that well... function like what most people would call commands like loading a file from tape or changing the video mode.

An ESP running Micropython functions almost exactly like this, and provides what could be called an operating system for the MCU. With no software other that Micropython you can list the files in a directory, run a program, join a WiFi network, etc. It's just like the old 8-bit machines except with Python instead of BASIC. Having this fundamental foundation available no matter what other software or role the ESP plays in the device is incredibly enabling and gives the person using the device much more power than typical consumer hardware.

Having this combination at the heart of a system of devices creates a broad range of possibilities, but what's most exciting to me are the ones that I haven't yet or simply cannot imagine. The idea of producing a range of devices that are useful out-of-the-box, but contain the potential to be combined and customized in ways that I would have never considered is very exciting to me, and I think could help address some of the worst problems we have with the way these devices are used to limit and abuse humanity.

Jason J. Gullickson, 2026

PAVE Sweet Thanks 2026

Sun, 8 Mar 2026 15:57:58 -0500

Mr Blowey

Mon, 09 Mar 2026 19:08:14 -0500

We have an air cleaner that makes a lot of white noise at home, so when we travel we have a hard time falling asleep without it. Out of desperation we found an app that generates various fan noises but I was shocked to realize that it requires a subscription, and that the subscription is $30!

So instead I recorded our air cleaner, and tidied up the ends so it should loop OK. I haven't even listened to this yet so you might hear it before I do.

Jason J. Gullickson, 2026

Small Fixes

Tue, 10 Mar 2026 06:50:06 -0500

I wrote a little daemon that collects data from our backyard weather station and stores it in a local database. The station has it's own cloud service that does this, but I feel like weather data is precious enough to keep a local copy.

Sometimes the daemon stops running. I don't know exactly why, and I could probably add some logging to find out, but right now I don't have time so I needed to do something quickly to avoid loosing data silently.

I'm using Systemd to run the daemon which gives you a lot of options when it comes to how to start, stop and restart something so I spent the five spare minutes I had this morning looking to see if there was something I could fiddle with to resolve this for now.

I know that when the daemon is stopped, restarting it has always worked, so it surpried me that the original unit file wasn't sufficient:

[Unit]

Description=Logs weather data from AmbientWeather stations to a database

After=multi-user.target

[Service]

User=jason

ExecStart=/usr/local/bin/awnet-receiver

Type=simple

Restart=always

[Install]

WantedBy=multi-user.target

With this file in place I'd still find the service stopped, so why didn't Systemd restart it?

Looking more closely at the logs I noticed that Systemd was restarting it, but after restarting and failing a certain number of times, Systemd gave up. These restarts were happening very quickly (many times a second), so if the problem was connecting to the database it's easy to imagine that the problem wasn't resolved within less than a second.

I reviewed the Systemd docs and found a few more parameters that might help, here's the updated [Service] section of the unit file:

[Service]

User=jason

ExecStart=/usr/local/bin/awnet-receiver

Type=simple

Restart=always

RestartSec=15

StartLimitBurst=20

StartLimitIntervalSec=300

I added the following parameters to see if it helps:

RestartSec - The number of seconds to wait before restarting

StartLimitBurst - The maximum number of times to try restarting

StartLimitIntervalSec - The maximum amount of time to allow for restarts

I don't know what the default values for these are, but based on what I saw in the logs this should spread-out the restart attempts a lot more. Given that I suspect database connectivity to be the problem, this should give that connectivity a lot more time to resolve before giving-up on starting the service.

I put-off doing anything about this for awhile because I wanted to take a more surgical approach to understanding exactly what is wrong and learning more about Systemd to see if there's more sophisticated ways of addressing it, but in the process I lost almost a month of data. Sometimes a tactical approach is better, especially if time is a factor, and you can always improve things once you've bought yourself more time.

Jason J. Gullickson, 2026

Solar Surveyor

Wed, 11 Mar 2026 07:14:14 -0500

I make a lot of experimental solar-powered things and one part about it that is hard is knowing if there will be enough sunlight to effectively power a device. There are tools and such for figuring out the amount of sun that might hit a particular spot, but in the wild there's a lot of other factors like trees and buildings and such that these tools can't accurately model.

The most reliable way I've found to determine the viability of a solar-powered setup is to over-provision or to just set up up and see how it goes. Both of these can be wasteful and expensive if things don't go your way.

The solution I've come up with is the Solar Surveyor. A small solar panel with an embedded computer that you can place anywhere you are considering gathering sunlight for a solar-powered project. The surveyor gathers sunlight and records data over an (ideally extended) period of time and produces a report to determine the feasibility of the site and help you correctly configure an efficient system for use on that site.

Ideally the surveyor is small and light so that it is easily deployed in a wide-range of areas. I'm thinking around 6x6" square and as thin as is practical. It will need some method of attachment, perhaps magnetic in addition to mechanical such as a hanging hook, mounting holes, etc.

The solar panel is of either crystalline or amorphous type (one of each would be useful, maybe double-sided?) rated for somewhere around 500mA and 5-12 VDC. These requirements are flexible but they should be consistent and sufficient to power the device.

The panel is connected to an MPPT charge controller which charges a lithium-ion battery and provides power to the computer and it's perephreals. The charge controller provides power in/out and state-of-charge information via i2c to the computer. Depending on the output this power supply may include a buck/boost converter). The computer is a common ESP32 development board with an SD card slot and realtime clock.

A handful of sensors round-out the hardware configuration and these include accurate temperature sensors arranged to capture front-side, back-side and ambient temperatures as well as humidity.

I'm not sure how much of a factor humidity is in solar power system efficiency but I seem to remember something about this and sensors are cheap.

An accelerometer might be a good idea as well to easily capture both the position of the panel as well as any shock or movement it's subjected to during the survey.

On the software side Micropython is installed on the ESP32 and a custom Python program monitors and records charge controller and sensor array data to the SD card. Optionally the ESP32 can be configured to connect to a nearby WiFi network to synchronize this data periodically when sufficient power is avaliable.

In addition to gathering raw data the software can begin producing a suitability report after the first 24 hours of deployment. The first report provides a simple Watt-hour budget that can be used to determine if the site can produce enough electricity in a day to power your project. If the surveyor is left for a week it will produce a more detailed report with daily and weekly averages, and if left deployed long enough the report will include seasonal impacts as well.

Beyond the basic power budget report, additional analysis is provided:

* The most suitable panel type for the site

* The temperature changes and physical shock a panel array will be subjected to

* The acceptable battery chemistries based on temperature and power input characteristics

* Realistic runtime measurements for a lightweight digital computing system

There's probably more that could be derived from the data but I don't want to overcomplicate things or put too much load on the device (deeper analysis could be done offline). The primary goal of the device is to make it easy to decide whether or not a site is suitable to provide solar power to a project and what amount of power production can be depended on. Exactly how this is communicated should be as simple as possible, and beyond the raw numbers I can think of a couple of fun ways to allow someone to plug-in various variables and configuration options for their project to get immediate feedback on the design.

Jason J. Gullickson, 2026

Good Tools

Thu, 12 Mar 2026 08:22:21 -0500

I'll admit that I'm probably pickier about tools than I need to be. I've owned and worked with plenty of tools, both good and bad, but I can't say I've ever regretted investing in a good tool.

The thing about good tools is that you can trust them, and when you can trust a tool, you can push both the tool and yourself a lot further. It's not just that a good tool is physically capable of more but also, and perhaps more importantly, you don't waste your time and energy worrying about and preparing for the tool to fail. A bad tool might not fail, but you waste a lot of time and energy compensating for that "might"" by both taking it easy on the tool while working with it and preparing yourself to deal with the fallout should the bad tool fail.

When I'm working with a good set of tools I can easily achieve a "flow state" because my mind is occupied only with the task at hand and the tools become invisible, or maybe a better way to put it is the tools become a part of me. I'm not preoccupied with what I'm going to do if the tool fails. I push the tools as hard as I can because I don't have to be afraid of bashing my knuckles or ruining the workpiece when a driver strips or a bit breaks. When I feel something push-back I know it's the material and not the tool and I can listen to and respond to this feedback knowing that it's what the material demands, not a limitation of the tool.

Working like this is a deeply satisfying experience and produces work of the highest Quality.

How can you tell the difference between a good tool and a bad tool before you choose it? Good tools do tend to cost more (although this isn't the most reliable way to choose). There's two things that bad tools will often claim to do, regardless of what they're used for:

* Do everything

* Do it faster

I could probably write a book about why anything that makes those two claims is something to avoid, but I'll leave that for another time. Suffice it to say if you avoid tools with words like those on the package, your chances of getting a good tool are much better.

It might surprise you to learn you don't have to spend a lot on good tools. You can save some money buying used tools, and if you can find a really old one, they're often very good because bad tools don't last.

But can't good tools fail? I suppose they can, but in my experience it's so incredibly rare that it never crosses my mind while working. More often it is I who fails when working with good tools and that's OK because when I fail I can learn from the experience. When I fail, it can make me better but when a bad tool fails it's just another piece of broken junk that I have to clean-up after.

Jason J. Gullickson, 2026

The Humane (network service) Interface

Fri, 13 Mar 2026 09:12:43 -0500

All network services I'm aware of speak a language that is geared towards machines. Some are pure binary protocols that are indecipherable to (most) humans without translation while others (REST, SMTP) are a bit more readable, but they are all intended for machine consumption.

A Humane Network Service Interface (HNSI) flips this script and is designed to be used primarily by humans with provisions to support machine consumption.

What do I mean by network service? A network service is a computer program that is shared on a network for others to use. A webserver provides a network service over the HTTP protocol, an email server provides a network service over the SMTP protocol. There are many other types of services and protocols, and programmers do interact with them directly using tools like curl and jq, but most people never interact directly with these services but instead use software like web browsers and mail clients to communicate with these shared network services.

Interacting with a HNSI is essentially like interacting with any text-oriented program or command, the only difference is that you must connect to the service on a shared system as opposed to running a program or command on your own computer. Once a connection is made there's two primary modes of interaction:

* One-shot

* Conversation

A one-shot service accepts everything it needs to provide the service at once, and provides it's reply in a single response. A conversational service expects there to be some back-and-forth, accepting a piece of input from you and providing a piece of output back, along with a prompt or some other form of follow-up request for input until one side of the conversation disconnects. Some services will function in both ways, behaving in a one-shot fashion if all the input it needs is provided up-front while behaving in a conversational fashion if additional input is needed.

In this way these services function much like many unix programs, a pattern adopted by my own set of Pouch tools as well.

With no additional work a HNSI can be used by a person as-is, connecting to the service from a terminal and using it directly. Where these services really shine is when they are integrated with other software to do things they were never designed to do, things that you in particular want to use them for.

Programming with a HNSI is simply a matter of "recording" a direct interaction and playing it back from your own program. This might not sound like a big deal, but compare it to the experience of integrating with a typical network service.

In a typical networked application, any network service is completely distinct from the normal user interface. For example, let's say you use a website to keep track of recipes. You interact with this via a web browser and add recipes by clicking a button that opens a new recipe card where you type the ingredients and steps and then click another button to save it. To view your recipes you click a menu and select an item from a list and a table of recipe names is displayed.

If this application provides any network service to integrate with at all, it will likely be in the form of a REST API. Adding a recipe via the API has nothing in common with how a recipe is added via the normal application, instead you assemble the recipe in a particular data structure format (probably JSON), then you send that data to a specific URL using the HTTP protocol. This HTTP request likely requires authentication, so before you can send this HTTP request you'll likely have to make a request to authenticate some credentials (often against a completely unrelated network service with it's own data formats and address schemes) to get a token you can use to get authorization to perform your HTTP request to store the recipe data.

Before you can do any of that you'll need to study the documentation for the REST API, because using the application teaches you nothing about using the API. This is the case for all network services I'm aware of, the service and the usage of it are two completely separate concerns and working with one provides virtually no knowledge of working with the other.

So how would this example differ with an HNSI?

Your first experience would likely conversational. After connecting to the service and identifying yourself, a list of recipes is displayed and you are prompted for what you'd like to do:

1. Pizza

2. Cake

3. Lasagna

4. Sandwich

(a)dd, (r)emove, (v)iew, (q)uit >

Typing "a" and pressing enter returns a series of prompts to create a new recipe:

New Recipe

(n)ame, (i)ngredient, (s)tep, (d)escription, (c)complete> Mac and Cheese

Mac and Cheese

(n)ame, (i)ngredient, (s)tep, (d)escription, (c)complete > i

ingredient name: salt

ingredient unit: tsp

ingredient amount: 1

Mac and Cheese

Ingredients:

1 tsp Salt

(n)ame, (i)ngredient, (s)tep, (d)escription, (c)complete > c

1. Pizza

2. Cake

3. Lasagna

4. Sandwich

5. Mac and Cheese

(a)dd, (r)emove, (v)iew, (q)uit > q

Now let's say you want to write a little program to import all of your existing recopies from a file on your computer. Once you've read a recipe from the file you'll need to create a new recipe using the service and upload the recipe data. Uploading this data is virtually identical to using the service directly, so you already know what to do so there's no need to learn a completely unrelated way of interacting with the service as is the case with the web-based application and it's REST API.

This not only makes integrating with the service simpler, it encourages services to be simpler as well. Combining the user interface with the machine interface places some back-pressure on complications. Nobody wants to use a piece of software that is hard to use or tries to do so much that it's impossible to remember how to use it. Services that accommodate the humans that work with them also accommodate the humans who program with them creating a beneficial relationship for everyone involved.

I could write more about this but I think I'll wait until I experiment with it a bit and confirm my suspicions and assumptions.

Jason J. Gullickson, 2026

Downlnk 2026-03-13

Fri, 13 Mar 2026 14:02:28 -0500

* https://www.alphadrome.net/forums/topic/25876-3d-printed-remote-control-killbot-from-the-movie-chopping-mall/

* https://www.thingiverse.com/thing:6868048/files

* https://flowercityarts.org/classes/letterpress-angle-chas-summer-2024/

* https://dry-inc.com/products/dry-inc-angle-chase?variant=42198811181221

* https://www.unitconverters.net/length/pica-to-millimeter.htm

* https://fairplayer.band/

* https://systemd.io/

* https://github.com/mastodon/.github/blob/main/AI_POLICY.md

* https://goodinternetmagazine.com/18-lessons-from-18-years-of-blogging/

* https://rocketffl.com/ap-ammo-are-armor-piercing-bullets-legal/

* https://rocketffl.com/ffl-cost/

* https://www.tindie.com/products/globoy/mppt-solar-charger-for-intelligent-devices/

* https://learn.adafruit.com/adafruit-bq24074-universal-usb-dc-solar-charger-breakout/pinouts

* https://en.wikipedia.org/wiki/DOT_(graph_description_language)

* https://sightlessscribbles.com/posts/the-colonization-of-confidence/

* https://en.wikipedia.org/wiki/Zersetzung

* https://www.x-plane.com/desktop/buy-it/

* https://rottenlibrary.net/library/culture/cola-wars/

* https://hackaday.com/2026/03/11/3d-printing-a-harmonic-pin-ring-gearing-drive/

* https://github.com/RaphTronic/Miscellaneous_Projects_3DP/tree/main

* https://www.moryan.com/an-open-letter-to-grammarly-and-other-plagiarists-thieves-and-slop-merchants/

* https://www.404media.co/developer-creates-infinite-maze-to-trap-ai-crawlers-in/

* https://zadzmo.org/code/nepenthes/

* https://zadzmo.org/code/nepenthes/install-debian

* https://www.ranker.com/list/friday-the-13-memes/erin-maxwell

* https://en.wikipedia.org/wiki/Citadel_(software)

* https://matduggan.com/i-sold-out-for-200-a-month-and-all-i-got-was-this-perfectly-generated-terraform/

* https://hbr.org/2026/03/when-using-ai-leads-to-brain-fry

Jason J. Gullickson, 2026

Brother DCP-L2640DW

Sat, 14 Mar 2026 13:37:04 -0500

I wanted a copier for the print shop because I like to make zines the old-fashioned way, but it's hard to get a plain-old copier these days. Most copiers are leased, and huge so the only option I could find in a desktop-sized copier was to buy an old one and restore it. That's cool but I have enough projects that are a stack of dependent projects and if I'm ever going to actually finish the zine I want to make with this thing I probably shouldn't start with a broken old copier that I have to make my own parts for.

The closest thing I could find to what I was looking for are laser printers that are really more of a printer/scanner combo than a proper copier, but I found a Brother for about $200 and decided to give it a shot.

It's a surprisingly compact machine which is nice because we want room for more interesting things in the print shop.

Brother DCP-L2640DW (ELEGOO Centauri Carbon for scale)

Maybe it's dumb, but I love helpful legends like this, I can never remember which way I'm supposed to feed things into a printer/scanner.

It was very easy to unbox and setup, and once it was plugged in I could stick a piece of paper in it, drop a piece of art on the glass and hit the green button to produce a B&W copy, beaute!

The controls are basic and very copier-like, and if this was all it could do I'd be perfectly satisfied. That said, it's also a printer and a scanner so I set it up on the network to see if all that would work as well.

Getting it connected to the WiFi network was simple even using the small display and limited buttons on the control panel, no apps, no setup programs, yay!

Printing from ElementaryOS pretty much worked like magic. The printer showed-up on it's own in the Printers control panel, and I was able to print a page from LibreOffice with little more than pressing CTRL-P and clicking "Print".

One weird caveat: I wasn't able to get a "Test Page" from the Printers control panel to print. The job simply never completes. I wasn't able to figure out why, but I know that I've had problems printing graphics from some programs (in particular some PDF's) so maybe it has something to do with that?

I was able to print single-sided and double-sided with equal ease. I haven't tried manually feeding anything like envelopes through the slot in the front but other than that printing is as trouble-free as I've ever seen it from Linux. I was also able to print from my phone (iOS), so that's a nice bonus.

What about scanning? I wasn't even sure what to use to scan something from Linux over the network because I don't think I've ever used a scanner from Linux since the days when they were tethered directly to the computer. I did some poking-around in Elementary's AppCenter and found a program called "Document Scanner" that looked simple enough, so I gave it a shot.

Document Scanner (aka Simple Scan) by Bartosz

It started-up and found the Brother automatically. I threw the printout from an earlier test on the glass, clicked "Scan" and in a few seconds I had a scan of the page. This worked so slick that I decided to push it and loaded the page into the auto-feeder thing on top of the Brother. Clicking "Scan" again did nothing, but looking under the "hamburger menu" I found an option labled "All Pages From Feeder". With that option selected clicking "Scan" grabbed the page from the feeder and scanned it in one step.

I know that this is what these machines are supposed to do, but I'm so used to them failing to do anything that I'm completely amazed that it does anything beyond the most fundamental things.

There's more to explore with this machine but as I said at the beginning, all I really need is a copier and it looks like this Brother fits the bill. What's left is to see how it holds up over time, but based on my experience with other basic Brother printers I expect it will at least outlive the software that it depends on.

Jason J. Gullickson, 2026

What do you want to do with (the rest of) your life?

Sun, 15 Mar 2026 08:55:04 -0500

For the last couple years I've been thinking about this a lot as the clock runs-down and the field I used to call my own dissolves. I've had a number of ideas that I think could find an audience, and some of them are things that I think could help people out, especially now.

* A nice table radio that doubles as a home digital media and personal information library

* The digital bug-out box

* A privacy-respecting personal computer

* The typing machine

* The pager

* A new form of high-performance computing

* Something to replace phones

* Something to replace the cloud

Any one of these seems like something I could be happy bringing into the world and sharing with others, and I've had conversations around all of them with other people who would find value in using them.

Something that I think is particularly important at this time is that all of these things involve a hardware concern and can benefit from skilled work. Few could be quickly replicated in a fully mechanized fashion and none of them are pure software which can now so easily be copied, captured and enshitified.

Another important thing to me is that anything I get into involving physical goods be something whose manufacture can easily be distributed. This is opposed to something that is centrally manufactured and shipped to where it's used. Distributed manufacturing has many advantages, some obvious (reduced environmental harm) and some more subtle (building local autonomy).

Anything I do will incorporate cradle-to-cradle design to some extent, ideally to a great extent. I don't want to put anything into this world unless some part of it can be reused, and in the most direct way possible.

Finally, I want to avoid anything that "scales". The "scalability" requirement has been used to justify some of the most heinous harms against people and life in general over the course of my lifetime, and "scalable" products attract the attention of the worst kind of people I've ever met. "Scalable" is a code word for the worst type of profitability and I think the best way to avoid all of these traps is to simply focus on making things that won't attract these predators.

The tools and technologies I choose to work with support the needs expressed above. 3D printing allows small-scale, flexible manufacturing to happen almost anywhere and can be used to produce a wide-range of goods (including the printers themselves).

Other small-scale automation is good, but it is a slippery slope. I don't have a good heuristic yet for where this line is, but "don't depend on a machine you can't lift" has treated me well so far.

For electronics, I'm very excited about the potential for FPGA's to replace the need to manufacture a wide-range of specialized integrated circuits. We can now synthesize devices as complex as CPU's using relatively inexpensive FPGA chips using open-source tools, if we can find a way to distribute the manufacturing of FPGA chips in small-to-medium-scale fabs we could eliminate countless supply chain risks and spread this knowledge and these skills out to a wide-range of communities.

Outside of that very narrow ranges of automated tooling, human-scale, hand crafting is preferred. This not only produces a superior, artistic product but it increases skill in people and populations. This crafting isn't limited to the physical nature of the product but also to it's design, documentation and software.

Nowhere in this mix will you find dependencies on systems or institutions that are outside of the control of the people who make these things, and this especially includes LLMs or so-called "AI". Just as the world does not need more physical junk designed for obsolescence it also does not need work that causes more harm than good or leaves people worse-off than when they started. We need work that makes us happy, whether that is smarter, stronger, more empathetic or just makes us laugh. The age of alienating work has itself become obsolete, and if it ever had any value to begin with, that time has passed.

Jason J. Gullickson, 2026

Weather Beaver

Mon, 16 Mar 2026 16:54:32 -0500

Take II

Tue, 17 Mar 2026 08:59:02 -0500

Last night I was up late volunteering and it was a pretty quiet night, so I spent a lot of time reading about operating systems and weirdly, the Apple II.

The Apple II series sold for 16 years. In this time there were several models, but the most popular (Apple II, Apple II Plus, Apple //e) were very similar and in many ways virtually identical to the first Apple II.

The only other personal computer I can think of that maintained that sort of popularity might be the IBM PC, although I would argue that even the move from the 8086 to the 80286 broke that chain.

What was more eye-opening than the lifetime of the Apple II was the fact that Apple tried to abandon it more than once, essentially ignoring it in Apple marketing and literally canceling all active engineering efforts for it at various points in it's lifetime in favor of new computers they thought would replace the Apple II.

Regardless of this people still wanted more Apple II's, and I'd like to really understand why.

From what I learned last night, I think the simplicity and openness played a major role, and specifically the combination of these two things. If the hardware or operating system were complex, it wouldn't matter how open it was, there would still be a high bar people would have to clear to make the machine their own and produce products for it. If it were simple but closed it would have been much harder for people to do anything new with it, especially anything the original designers never imagined.

I think targeting the education market was an important part as well. By having Apple II's in classrooms, many kids first experience with a computer was with an open, flexible machine that you could learn to program using the small book that came with it. The built-in programming language was simple enough to get you writing your own programs in an afternoon but at the same time provided access to almost all of the capabilities the machine had available (unlike other computers where more advanced languages or expensive development tools were required). I think this may have planted the seeds that grew into a diverse array of software and hardware vendors for the Apple II down the road.

Open enough, simple, and fun.

In many ways that Apple II's limitations are what made it easy to work with for both "users" and "programmers" (which more often than not were the same people).

Something else that surprised me was how expensive it was, you could have bought a car for the price of an Apple II system. Given that, it really surprises me how many people I knew who had them given that I grew-up in a very small, mostly blue-collar town. Maybe it was a simple as wanting the same computer at home that the kids were learning on at school, but I find it hard to believe that was all there was to it.

All that said I have a lot more to learn about the subject.

I'm very interested to understand it though, because I think we are at a time where the path of mainstream computing is failing for more and more people. This, coupled with a myriad of associated fallout from this path makes me believe that it might be the right time for something not only new, but different.

Jason J. Gullickson, 2026

Take II Part II

Tue, 17 Mar 2026 14:39:54 -0500

Two more things that I think made the Apple II last:

The hardware wasn't designed as a product, but instead it was mostly, simply, what Woz wanted.

"...a lot of these features that really made the Apple II stand out in its day came from a game, and the fun features that were built in were only to do one pet project, which was to program a BASIC version of Breakout and show it off at the club"

-Steve Wozniak, apple2history.org

I think the reason the Apple II hardware had such appeal, and therefore such longevity might simply be because he cared about it.

AppleWorks. I'm not even sure where to begin with this other than to say that an Apple II with AppleWorks was a complete productivity workstation and immediately useful in ways few other such systems are.

So what's my version of this?

It's certainly centered on an FPGA, possibly multiple FPGAs. I've talked about this a lot and I've been talked-out of it a lot, but I keep coming back to the idea of a machine that is truly dynamic, and right now the most dynamic piece of electronics is the FPGA.

A simple and effective bus architecture that allows for flexible expansion is (equally?) important. I don't want to jump to any conclusions here but something like i2c comes to mind unless I can find something simpler. It only needs to be as fast as it needs to be, and I'd need to do some math to figure out if i2c is fast enough, but my gut says yes.

If the bus is flexible enough what else needs to be defined before we can get started? I believe strongly in the importance of "self-hosting", the ability for a general-purpose computer to be capable of writing software for itself, so I guess the "minimum package" would be something that has enough peripherals to pull this off. Unless something changes radically that means the ability to enter code and see what it does, so some sort of keyboard and display are probably essential. Beyond that I want to be very careful about prescribing things, and even these things I might waffle on if some other path towards self-hosting reveals itself.

But what to do with it beyond write software yourself? I think something like AppleWorks is in order soon if not immediately after making such a new machine available. Fortunately I've been working on something called "Pouch" which is not entirely unlike such a "works" package. The tools it's currently composed of are designed to meet my specific needs, but I would imagine my needs are shared by others and with a little collaboration the set could be rounded-out nicely to make the new machine useful to someone while they're still learning to program it.

I'll keep pulling on this thread, maybe it will unravel something...

Jason J. Gullickson, 2026

Perfection

Wed, 18 Mar 2026 22:20:57 -0500

It's not all about you, Jason

Thu, 19 Mar 2026 07:05:46 -0500

Something I realized in the last 24 hours or so is that for this new computer project, I don't need to find the perfect balance of things I want and things other people want. It's as easy as letting go.

As I dive deeper into Apple II history and documentation I'm uncovering things that I knew already but had mostly forgotten about. One of the most exciting things to me in this category is the SwyftCard (I'll let the manual explain it).

This type of text-based interface really appeals to me, and there's not many things I need to do with a computer that don't fit into that model, but I know other people have other needs and for a long time I tried to find a way to design things that accommodated everyone.

But there's a simpler, and I think better, option.

Make a machine that is simple enough for anyone to make their own. Limit the number of "pieces" that the machine is made out of so that you don't have to be (or pretend to be) and engineer to change it. Don't make it so complex that it requires destroying humanity just so someone can write a program.

In practical terms what this means is that I don't need to figure everything out before I start connecting the logic gates of the thing. Instead of applying my design philosophy to the entire system, hardware and software, the philosophy can be applied to each layer of the system. Existing computers, operating systems, programming languages, etc. do this to varying degrees but I'm not aware of a contemporary system that does it everywhere.

Jason J. Gullickson, 2026

Branagan, VM again

Thu, 19 Mar 2026 07:30:13 -0500

A few years back I wrote about Personal Virtual Machines as a way to write software that doesn't go obsolete when the hardware it was written for does. Since that time I've found a number of other problems this approach solves and I think it should be a part of the new computer I'm designing.

This time around I want to stress the importance of portability even more. The VM itself needs to be so trivial to implement that anyone familiar with the target "host" can create it without being an expert in the VM itself.

Simplifying and/or automating the process of the VM could even be a feature of the VM itself...

This might sound like it shovels all of the work and complexity onto the person working inside the VM, but I don't think that has to be the case, or at least I don't think it has to be as bad as it might seem. If you're thinking about contemporary processor design and layer-after-layer of operating system/system library/external dependencies/application code/etc. then yes, this is a burden but remember that we are starting from scratch here and we can apply everything we've learned to reducing the need for all that.

Since we are designing the machine all the way down to the instruction set, we can design instructions that reduce the need for all of the layers of code that are typically required for a contemporary application. We can also constrain the set of instructions so there is only one way to do things. I think between these two imperatives we need a lot less code to get the same job done.

We can also discard limits that real machines have in order to simplify the programming model. For example, we could discard the split between memory and storage and instead adopt a model where everything is an address. This is possible because in a VM we're not constrained by the physical limits on address spaced imposed on a physical CPU. Those limits (might) still exist in the underlying hardware, but they are abstracted away by the VM.

It's hard to imagine how a little change like this alters how we write software. Think about all of the code that goes into dealing with that difference: filesystems, databases, ORMs, cloud services... the list is endless and often one of these is layered on top of the other.

Consider also how this impacts other forms of I/O and peripheral access. A display becomes a range of memory addresses you write values into with no need of a video driver or a myriad of display interfaces, keyboard input simply pours into another location.

This sort of thing isn't new (many computers use memory-mapped I/O at some level) but it's rarely taken to this extreme due to limitations imposed by the hardware.

These are just the simplest examples I can provide of the sort of complexity-decimating simplicity possible through the VM approach. I have a lot more ideas, some that I think might be truly novel but I wanted to select examples that might be more immediately relatable.

Jason J. Gullickson, 2026

Downlink 2026-03-20

Fri, 20 Mar 2026 14:49:43 -0500

* https://en.wikipedia.org/wiki/Citadel_(software)

* https://www.arcanoae.com/shop/arcaos-5-1-personal-edition/

* https://www.arcanoae.com/

* https://www.punkt.ch/products/mp02-4g-minimalist-phone

* https://www.punkt.ch/pages/our-story

* https://www.apostrophy.ch/resources/faq/

* https://www.androidpolice.com/apostrophy-os-guide/

* https://duckduckgo.com/?t=ffab&q=diy%20bullet%20resistant%20door&ia=web

* https://www.waxtrax.org/

* https://support.signal.org/hc/en-us/search?utf8=%E2%9C%93&query=location+sharing

* https://support.signal.org/hc/en-us/articles/360007062172-Signal-Permissions-OS-Notification-Settings

* https://tecnobits.com/en/how-to-share-your-location-in-real-time-by-signal/

* https://www.reddit.com/r/signal/comments/12p3juz/feature_to_share_live_location/

* https://community.signalusers.org/t/live-location-sharing/2564/173

* https://support.signal.org/hc/en-us/sections/360001602792-Signal-Messenger-Features?page=2#articles

* https://support.signal.org/hc/en-us/articles/6829998083994-Phone-Number-Privacy-and-Usernames-Deeper-Dive

* https://support.signal.org/hc/en-us/articles/360044640011-Broadcast-Media

* https://github.com/RsyncProject/rsync/commit/aa142f08ef31d3ffa8d6b3b8af16d00324a98c1b

* https://codeberg.org/small-hack/open-slopware

* https://fenrus75.github.io/FenrusCNCtools/javascript/stl2png.html

* https://en.wikipedia.org/wiki/Threads_(1984_film)

* https://en.wikipedia.org/wiki/The_War_Game#External_links

* https://en.wikipedia.org/wiki/Mondo_film

* https://web.archive.org/web/20051016134931/http://www.filmint.nu/pdf/special/watkins.pdf

* https://www.indiewire.com/features/interviews/criterion-collection-testament-jane-alexander-1983-movie-1235183313/

* https://www.apple2history.org/?s=SwyftCard&submit=Go

* https://www.apple2history.org/history/ah06/#Brian

* https://apple2history.org/dl/Apple_II_Redbook.pdf

* https://en.wikipedia.org/wiki/Apple_II

* https://en.wikipedia.org/wiki/IBM_Personal_Computer

* https://duckduckgo.com/?q=gwar%20gor%20gor%20lyrics&t=ffab&ia=web

* https://www.ebay.com/sch/i.html?_nkw=apple%20ii&_sacat=0

* https://www.ebay.com/itm/137118256880

* https://www.ebay.com/itm/137111272837

* https://archive.org/details/a2_AppleWorks_3.0_8-bit

* https://www.reactivemicro.com/product/mockingboard-assembled-or-kit/

* https://www.willegal.net/appleii/appleii-first_page.htm

* https://ia601203.us.archive.org/9/items/swyftcard_manual/swyftcard_manual_text.pdf

* https://duckduckgo.com/?t=ffab&q=SwyftCard&ia=web

* https://digibarn.com/collections/systems/swyft/index.html

* https://www.falvotech.com/kes2ex/index.html

* https://itsfoss.com/news/ageless-linux/

* https://www.cs.columbia.edu/~sedwards/apple2fpga/

* https://www.cs.columbia.edu/~sedwards/papers/edwards2009retrocomputing.pdf

* https://nandland.com/fpga-101/

* https://www.adafruit.com/product/2674

* https://www.adafruit.com/product/4741

* https://archive.org/details/canoncat

* https://dn710709.ca.archive.org/0/items/CatWorkshopManual/Cat%20Workshop%20Manual.pdf

* https://archive.org/details/jefraskin?page=2

* https://archive.org/details/tForthManual/page/n23/mode/2up

* https://dn721604.ca.archive.org/0/items/CatReferenceGuide/Cat%20Reference%20Guide%20Color.pdf

* https://duckduckgo.com/?t=ffab&q=canon%20cat%20emulator&ia=web

* http://www.canoncat.net/cat/Swyft%20and%20the%20Cat.pdf

* https://www.turntablelab.com/products/syitren-r300-portable-bluetooth-cd-player

* https://www.crowdsupply.com/mnt/mnt-reform-next#products

* https://palmettostatearmory.com/auto-ordnance-1927a-1c-deluxe-45-acp-semi-automatic-carbine-brown-t5100d.html

* https://duckduckgo.com/?q=elegoo%20centauri%20carbon%20api&t=ffab&ia=web

* https://github.com/RemmyLee/carbon

* https://github.com/elegooofficial/CentauriCarbon

* https://www.reddit.com/r/ElegooOrangeStormGiga/comments/1n3cark/dual_printhead_with_orca/

* https://github.com/OpenNeptune3D/OpenOrangeStorm

* duckduckgo.com/?t=ffab&q=orangestorm giga add files to menu&ia=web

* https://duckduckgo.com/?t=ffab&q=lego_flat.stl&ia=web

* https://machineblocks.com/docs/get-started

Jason J. Gullickson, 2026

Drone Off

Sat, 21 Mar 2026 06:42:28 -0500

The other day I was helping load a car and heard the distinct whine of a quadcopter. I looked up and saw a small quadcopter approaching overhead at what I would guess to be about 50 feet of altitude. It flew directly over us and then just hovered there, apparently watching us.

It could have been a kid playing with a toy, or it could have been a realtor taking photos, but I also know it could have been a lot of other, far more nefarious things.

What I do know is that it was flying over private property, and I was standing on private property, and I confirmed that it wasn't being flown by the owner of the property. I also know that it made us all feel unsafe, and if it continued to watch us we'd begin to fear for our lives.

The only idea I could come up with to get rid of it was to unzip my jacket, reach inside and pretend like I was drawing a pistol. I was wearing black leather gloves and at that range I figured I could make a convincing pistol silhouette with my fingers.

I drew my hands out slowly and aimed them at the drone using proper technique. I held a bead on it for about 15 seconds and it sped-off into the distance.

This experience got me thinking about how I can be ready for the next time this happens. I'm going to read-up on how the law applies (do things like Castle doctrine and Stand Your Ground apply to airspace?), but I'm also thinking about practical countermeasures.

Of course a firearm will bring any quadcopter down, but there's lots of reasons that's not my first choice, especially outside of your own property.

These machines are very easy to bring down if you can interfere with their rotors, so things entanglement hazards like string or monofilament come to mind, Other ideas are liquids or foams that can gunk up the works (imagine hitting one with a stream of Great Stuff), but you'd have to get close enough or somehow propel these things to reach the drone.

This got me thinking about a discussion I recently had about home-made guided missiles. I was doing some reading on homing missiles (specifically early heat-seeking anti-aicraft missiles) and the mechanisms were fairly simple. A lock is achieved by essentially aiming a detector at the heat source and when the sensor can confirm the signature the missile is launched. As it flies, it measures changes in the signature and interprets these as the missile going off-course and it uses it's control surfaces to adjust course in the opposite direction.

Quadcopter drones don't produce a strong heat signature, but they do produce distinctive radiation in the form of sound. Maybe you could make a seeking mechanism that homes-in on that distinctive whine?

If so, you could create a "warhead" containing one of the mostly-harmless entanglement agents we discussed earlier, and combine it with the sonic homing mechanism and a simple rocket. If you could keep the weight of all this low enough a basic off-the-shelf solid rocket motor should be sufficient to reach a target within visual range.

Such a guided missile would easily outpace even the fastest quadcopter and bring it down with no explosion or other danger beyond the kinetic energy the drone already has. You could increase safety more by disarming the warhead of the lock is lost, and even use the control surfaces to bleed-off energy before landing in the event of a target miss.

I would have to do some more design and research to confirm it, but I imagine something like this could easily be contained in a small-ish portable package, maximally something the size of a shotgun or telescope (forms that would aid in initial target sighting and lock). It might be possible to go even smaller depending on how heavy the warhead needs to be to be effective (I'm not concerned about the weight of the homing device, it could be tiny).

Now that I think about it, it might even be possible to propel such a missile using a bow instead of a rocket motor. This has several advantages and is safer as well. Has anyone made a guided arrow before?

Jason J. Gullickson, 2026

Rib Rub

Sun, 22 Mar 2026 08:51:36 -0500

I'm going to start posting my recipes here so I can always find them.

* 1/4 cup dark brown sugar

* 1 tbsp coarse sea salt

* 2 tsp black pepper

* 2 tsp smoked paprika

* 2 tsp garlic powder

* 2 tsp onion powder

* 1/2 tsp cayenne pepper

Jason J. Gullickson, 2026

Cartesia Part I

Mon, 23 Mar 2026 15:50:22 -0500

The idea for Cartesia started as a cross between a BBS and a text adventure. You could probably classify it as a MUD, but that doesn't feel quite right to me.

The need for this arose from a group chat on Signal where we lamented the need for something both richer and simpler. Richer in that it could support a wider variety of uses and conversation styles and simpler in that it could be accessed via a text interface on any device. The idea of creating a good-old-fashioned BBS was floated several times, so I started to think about my own experiences with BBS's as well as researching the history of the BBS. After several mental iterations on the idea and discovering the origin of BBS "rooms" (attributed to the Citadel BBS), the idea started to merge with others I've had about text adventure games, interactive fiction, virtual reality, programming languages and operating systems.

In my opinion, the best things that came from the Internet are the things that were created by the people who use them, the very best being things referred to as "user-generated". I don't like the term "user", but my favorite experiences have come from hanging-out in spaces that were built by the people who use them. For example, the most well-known features of Twitter (hashtags, @ mentions, etc.) were not created by the Twitter company but by the people who used it (although they were appropriated by the company later). I think what made Twitter so much fun in the beginning is that it was simple and flexible which led the people who used it to create the features they needed organically instead of being forced down a path planned by committees inside a company (I'm looking at you Zuck).

Given this, anything that I help create that involves other people is going to be designed to give those people the most ability to create what they need and avoid my prescribing it to them as possible. This led to the primary requirements of Cartesia being: joy, care, autonomy and self-actualization.

Cartesia also has the (perhaps seemingly contradictory) goals of open-endedness and implementation simplicity. The implementation will be correct when it is flexible enough that most of it's functionality is created by the people using it from within Cartesia itself but simple enough that the underlying implementation can run on and be ported to a wide range of the most inexpensive hardware.

Finally, Cartesia will qualify as a convivial tool, growing only large enough to achieve it's initial goals and then halting advancement, changing only to address bugs.

For many reasons now is a good time to be looking into ways to utilize computing hardware more efficiently, and I've often reflected on how much of what computers are used for (especially in social and networked contexts) is little more than written text. Capturing, processing, storing and moving text around doesn't require a lot of hardware so I think this is the right time for a project like Cartesia.

Jason J. Gullickson, 2026

Fixin' stuff for the neighbors

Mon, 23 Mar 2026 19:12:07 -0500

I've earned a reputation in the neighborhood as something of a tinkerer, so occasionally someone drops a dead device at our doorstep.

The fix is almost always simple or hopeless. This time it was just a bad solder joint that failed.

It might seem silly to fix this stuff, but it makes my neighbors happy, and it feels good to be able to fix something these days.

Jason J. Gullickson. 2026

Cartesia Part II

Tue, 24 Mar 2026 07:50:46 -0500

This is Part II of a series on the Cartesia project. Part I can be found here.

Cartesia is a virtual place made out of rooms that are connected in a hypercube structure. Each room is connected to the others through six exits: north, south, east, west, up and down.

(I'm not sure if I want to use cardinal terms like north, south, etc.)

Rooms

Rooms are also directly addressable using an address format of w.x.y.z. x, y and z are traditional Cartesian coordinates, w is the "world" address.

The number of rooms limited only by the available hardware resources* however the w portion of the address allows Cartesia to span physical machines. The w portion is translated to (or can be substituted for) the IP address of the machine a portion of Cartesia is running on.

Examples Addresses:

0.0.0 - origin room on current World (shortcut)

1.10.0 - The room ten rooms north, one room east on the current World

0.0.0.0 - origin room on localhost World

6.0.0.0 - origin room on World 6

10.4.4.1:0.0.0 - origin room of a World running on IP 10.4.4.1

Cartesia rooms can contain items and people. The people in those rooms can interact with eachother (primarily through text chat) as well as the objects in the rooms. The discussion or chats that happen in a room are similar to the discussion at a party or a meeting: individuals can be addressed directly but all of this is mixed into the general conversation with no expectation of privacy (a private discussion is best had in a private room). Conversations are ephemeral and a person entering a room will only hear what is said after they arrive (Cartesia keeps no records of conversations). A person in a room could record what they hear, but they cannot record anything that was said when they are not present.

Rooms are created by the people who occupy Cartesia. There are no administrators, no authorities. When a room is created it is the responsibility of it's creator**. Creating a room requires little more than selecting an unused address and giving it a name, in fact leaving an existing room through an exit that leads to an unused address will prompt you to create a new room.

Rooms can be locked, but they can only be locked or unlocked by their creator. When a room is locked a key object appears in the inventory of the creator. The creator can share this key with another person or leave it in another room. Keys, like any object in Cartesia can be duplicated. The room's creator can also remove the locks from rooms they create or change them, rendering the original keys (and any copies) essentially useless.

The creator of a room can also change who is responsible for it. This requires that both the creator and the person who responsibility is being transferred to agree to this, and of course it is reversible.

Rooms have other properties in addition to a name. A room can have a description as well as a set of rules. The description is displayed the first time a person enters the room, but the rules are displayed when someone look at the door to a room, akin to a sign on the door. If rules are present, they must be positively accepted before someone can enter the room. If the rules change in the future, the new rules must be accepted before entry as well.

Objects

Objects can be created by anyone, anywhere and require nothing more than a name to be created. Objects can be examined or used (the results of these actions vary from object to object). Objects can be taken or duplicated.

In addition to a name all objects can have a description and an open-ended number of stats and attributes. Stats are named numeric values that can be referenced or modified by usage of the object. Attributes are another open-ended list of names, but in this case the values are text values and can only be modified by their creator***. Objects also have a programmatic nature, which can be used to make them do things when they are used by a person.

It's worth pointing-out that Object properties can store encoded binary values**** as well, allowing an Object to represent non-textual things like images, audio, etc.

People

A person is you, a real human person. There can also be what might be referred to as "non-player characters" or "bots", but these are simply another type of object in Cartesia.

To be clear, people in Cartesia must be living people, not scripts or programs or any other non-living thing. All those things can exist in Cartesia, but they must exist as objects. Any non-living thing masquerading as a person in Cartesia is a fundamental violation of Cartesia's definitions and anyone operating a Cartesia world who allows this to continue will be shunned.

People in Cartesia are created via invitation. An existing person generates an invitation which can be sent to another person via any means, but there's no way for someone to "sign-up" without an invitation. The only exception to this is the first person that is created when a new Cartisia world is created.

Minimally, people have a name and ideally, a description. Other attributes and stats like those discussed above in the objects section can be added which are useful for games or other activities. There are also several automatic things that each person has that the system maintains like inventory and a map.

When you take an object it is added to your inventory and removed from wherever it came from. Alternatively, you can duplicate the object, leaving the original where you found it. Your inventory is limited only by how much memory you are allotted, and the number of objects you can carry depends on their memory size, not their physical dimensions, etc.

Your map is automatically maintained of the rooms you've visited, indexed by name. This makes it easy to teleport to a room you've previously discovered. You can also teleport to any room's address but the map makes it easy to find your way back to places you've been.

Jason J. Gullickson, 2026

Cartesia Part III

Wed, 25 Mar 2026 06:58:58 -0500

This is Part III of a series on the Cartesia project. Part II can be found here.

Interface

As mentioned earlier, the primary interface to Cartesia is text-based. It is a simple "conversational" interface that can be displayed on virtually any terminal or console.

(interface example)

The interface has essentially two "modes", one for conversation and another for everything else. These two modes are selected by specifying a "prompt" character, a double-quote for conversation and an asterix for the rest.

The interface is primarily designed for direct use by a person but is also implemented as an HSNI to reserve(?) the potential for consumption by other types of interface. The primary objective is to make Cartesia more accessible via unanticipated interfaces but this also opens the door for other types of interface as well (graphical, immersive, etc.). The key requirement is that the interface never compromise it's usability as directly human-usable interface regardless of what other types of interfaces consume it.

Protocol*

Cartesia Worlds provide a standard protocol for interacting with their Rooms that is used to make connections between Worlds. For example, if you are logged-on to the Interface of World 1 and enter a Room on World 2, the protocol is used to get information about the room and the people and objects it contains from the hardware running World 2. Like the Interface, the protocol is also an HSNI so it is possible to interact with it directly, but it is a more streamlined experience... hmm...

Most of Cartesia is implemented in a purpose-built virtual machine. The language of this virtual machine is the same language used to add programatic behaviors to objects. This means most of Cartesia is written in the same programming language as the objects inside Cartesia, and learning how to program objects is a stepping-stone to learning how to maintain and modify Cartesia itself.

The VM not only provides some safety in the form of isolation between the programs Objects run, but also makes Cartesia as portable as possible. This allows Cartesia to run on a wide-range of hardware but also provides protection from hardware obsolescence.

In addition to the above the VM tracks resource utilization and provides capacity information about the underlying hardware. When the VM is initialized it establishes how much of each resource it has been allocated and conveys the utilization of these capacities in the form of budgets that can be allocated to Rooms, Objects and People. As the World grows these budgets shrink and this information is conveyed to the People inside the World in a transparent way, allowing them to take appropriate actions. If the budgets are exausted, the VM prevents any further expansion to preserve the stability of the World until resources are freed-up or reallocated.

Examples

Rooms

Room 0.0.0 is often a "lobby" as this is the first place most people will experience in a given world. It is likely to have a set of rules for the World that must be accepted and a detailed description about the types of Rooms and Objects that exist in this World as well as information about the People who regularly inhabit it. It might even include a directory of the World, Objects that might be useful there, etc.

Another likely room is a library. This contains Objects that function like books, with attributes like "Author", "Table of Contents" and "Chapters" containing the text of the book. A library could contain other types of media as well, although it might require special Interfaces to access them.

Objects

Simple objects that serve as decoration for rooms is expected. These consist of little more than a name and perhaps a description.

As described in the Rooms section, a book object could be created by adding attributes such as "Author" and chapters containing the text.

A "concierge" that uses the programmatic features of Objects to produce a menu of services which can be selected providing details, or other forms of simple, interactive conversations.

A "pet" that purrs and increases a person's "calm" stat (if they have one).

An instrument that can be played by consuming conversation keystrokes like buttons pressed on a keyboard, etc.

Footnotes

* I'm not sure if there's a need for this, could we just "bridge" the HSNI of the regular Interface instead?

Jason J. Gullickson, 2026

What's up, Jet?

Wed, 25 Mar 2026 07:55:50 -0500

I've noticed that there's been a sharp decrease in the use of my journaling tool "Jet" since I began the blog-post-a-day regimen at the beginning of this year. I guess this is OK, but I really did like having a simple, reliable private journal that I knew would be reliably archived and always available to me in the future.

During the transition I would sometimes start writing as a journal entry and when it grew into something I felt like sharing it would "graduate" to a blog post. Reflecting on this now, I'm thinking it might make sense to make it easier to make that transition.

Currently I use both a Markdown editor (Apostrophe) and an email client (ElementaryOS's built-in client) to author posts that are then posted to this blog software (Preposter.us). The reason for this is kind of dumb.

I started using Apostrophe because ElementaryOS's mail client has no spell check. I know this might seem impossible, but if it exists, I can't find it. So I compose in Apostrophe mainly so I have access to a spell checker. This is even dumber because Apostrophe's spell check doesn't understand contractions and marks them as spelling errors.

So today if I were to always use Jet as the starting point I'd need five separate pieces of software to make a blog post, which is ultimately is nothing more than a text file on a filesystem served by a completely basic webserver.

This works, but it seems kind of silly.

It might be time to add a new tool to the Pouch, something that can be used to pluck passages out of Jet's journal file and ultimately publish them to the web. Somewhere in-between the text needs to be transformed to HTML, and yes, spellchecked.

I have thought some about a tool like this but haven't done much more than think about it because it's very easy to come-up with something that feels like it violates the principles of the Pouch tools. Up until recently I was really struggling with imagining an interface that can be used to select and re-arrange blocks of text into a new document without going beyond the very basic (essentially serial output/input) text interface I've limited Pouch tools to so far. I definitely don't want to get into anything that relies on features of a particular terminal or console that would require creating dependencies on external libraries or limit portability, so I've just sort of been sitting with this to see if a solution presents itself.

Lately my interest in Raskin's work on text-based interfaces has been reinvigorated and I'm wondering if there's some answers there. Because I like to start at the root, I'm in the process of getting my hands on a SwyftCard setup so I can both study and use it on a regular basis and really get to know it. I figure anything that can work on an Apple II in text mode can probably be made to fit within the constraints of conviviality that I place on Pouch.

My expectation is that this might cover the editing part, but not publishing. I don't have any immediate plans to replace Preposter.us so perhaps the extent of these new tools will be to stop at the ability to send an HTML-formatted email? Sending email feels like something that is going to push or exceed the limits I've placed on Pouch tools so far but maybe I'm jumping to conclusions there? While I've relied on external library to communicate with mailservers in the past, maybe simple sending an email is simple enough that I could implement that within the current Pouch constraints?

Another possibility is to add a simpler (in terms of programmatic access) interface to Preposter.us. Perhaps a write-only HTTP endpoint that receives the same data as would normally be read from the mailserver when processing a new post. This is the first time I've ever even considered such a thing so there'd be a lot of concerns to work-out, and if I'm being completely honest it feels kind of "gross" to depart from the email-only way of interacting with Preposter.us historically, but it's worth thinking about or at least having in mind should it turn out to be too difficult or too much of a compromise to send an email from a Pouch tool.

Jason J. Gullickson, 2026

Other People's Tools

Wed, 25 Mar 2026 09:04:46 -0500

This morning I've had one of those revelations that seems totally obvious once you see it.

I've struggled over the last few years with being coerced into working with LLM's and the products of LLM's beginning with being treated like an ignorant old man up to now where I'm forced to use them to remain employed.

I won't elaborate on why I struggle with this here. I've been writing about it here for years, just scroll-back before 2026.

The revelation is simple: make my relationship to these tools the same as a plain craftsman's relationship to power tools.

"plain" here refers to plain cultures such as the Amish, Quakers, etc.

These workers will use power tools but they will not own them. They will work with them as other people's tools on other people's projects, but they will not own them nor work with them on their own projects.

To explain why they work this way is a longer discussion I won't try to capture in a single blog post, but one important aspect is that relying on tools like this threatens their autonomy, which is what allows them to choose their way of life.

When I'm coerced into working with LLM's and their byproducts, I feel like I'm doing something that I know is wrong. I feel the harm that comes from these tools emanating from my hands out into the world and back up through my arms, harming myself as well. It feels like poison spreading through my bloodstream, and I am in desperate need of an antidote.

When it becomes possible to make a living without working with these tools I will happily and immediately do so, but at the moment there appears no escape within my profession. Until then, I'll find what comfort I can in adopting the plain person's relationship to antisocial technology and refuse it when I have the choice and accept what I cannot change when I have no other choice.

"In this world but not of this world"

Jason J. Gullickson, 2026

Do It Ourselves

Thu, 26 Mar 2026 15:19:18 -0500

I was raised in a very DIY (Do It Yourself) household. We had lots of DIY books and my parents were always making DIY repairs, remodels and upgrades to our home

My friends called it "the house of perpetual remodeling".

I eagerly adopted this attitude and doubled-down on it when I was introduced to the DIY ethos of punk rock. It is a skill and an attitude that has served me and many of those around me well.

A few years back I brought-up DIY in a conversation with someone I didn't know and they pointed out "yes but what if you can't do it yourself?". This never occurred to me because my experience with DIY was always communal, and when I used the term DIY I was almost always working with others, supplementing eachothers abilities to get it done together.

But I guess there's a faction of DIY people who don't do it that way. To them, DIY is just another part of the "up-by-your-own-bootstraps" mythos. It's about "rugged individualism" and other such nonsense.

For me that's never been what DIY was about, but now I can see how that's literally what it spells-out, and I don't want anything to do with that.

So I'm making an effort to be explicit about this and use DIO (Do It Ourselves) in place of DIY.

Who is "ourselves"? Well, that would be you and me friend.

Jason J. Gullickson, 2026

Deep Future

Thu, 26 Mar 2026 15:53:43 -0500

(not to be confused with the techbro book Deep Future which should more accurately be titled Shallow Past because it's filled with pilfered ideas from the 1950's and 60's)

It's easy to get down about the near-to-medium future. I'm not making light of the threats, I'm keenly aware of them and doing what I can to mitigate the harms but personally I need something to look forward to in order to maintain the gumption to make it through "the now" and help whoever I can in the process.

So I spend time thinking about, planning for and making things for the time after the collapse, a time I decided last night to call the Deep Future.

Thinking about the Deep Future is easier than thinking about the near future because right now the near future is very unstable. I can't say for sure what is going to happen next, and I can't say exactly what is going to be the thing that finally pushes all the old gods off the cliff, but regardless of what and when, it's safer (and more fun) to think about what we'll be building afterward.

As hard as it may be, it's also an opportunity to use everything we've learned up to this point to do things better, without the baggage and artificial justifications that got us here.

I'm not going to spend any more time speculating about the future in this post. I'd much rather talk to you about what you want to do, how you want to live and how you want to help in the Deep Future.

Jason J. Gullickson, 2026

Fixin stuf

Sun, 29 Mar 2026 22:16:39 -0500

Horicon Marsh in March

Mon, 30 Mar 2026 14:04:15 -0500

How I Accidentally Bought an Apple //e

Tue, 31 Mar 2026 15:19:51 -0500

As I've mentioned before, I've been studying the Apple II as an inspiration for work on my own future computing designs. I've also been revisiting the work of Jef Raskin, and the earliest implementation of these ideas that I think I can get my hands on is the SwyftCard, which of course requires an Apple ][ to stick it in.

It needs a bath, but honestly it's in better shape than I thought from the listing

I've been surfing Ebay among other places on the lookout for such a host machine but most of them are priced out of my budget for this project. About a week ago I came across an interesting listing though, interesting because the seller did not seem interested in shipping it (shipping was offered but 2x more than any other //e I'd seen). The seller offered free pick-up, and they were somewhat nearby, so I wanted to keep an eye on this one.

I tried to click the "watch" button, but it wouldn't stay clicked. I tried reloading the page, etc. but no matter what I did I couldn't add it to the watch list. Out of desperation I decided to try placing a bid, assuming that based on the asking price the auction would definitely go up (it was about half the price of other //e's "buy it now" price). For whatever reason this worked, and it gave me a way to keep track of the auction.

I assumed that someone would outbid me, but as the week wore on there was no action. There were a few watching (why did the watch button work for them?) but no additional bids. I figured they were waiting for the last minute and someone would "snipe" it and get me off the hook.

That did not happen, and later that night I received an email indicating that I had won the auction.

A surprise for sure but not necessarily a bad one. This kind of forces my hand to setup a working Swyft environment and I'll take it as a sign that picking-up Raskin's work is the right direction for me to go.

Coincidentally, I got an email from a person who recreated the SwyftCard as a kit. I wasn't sure if I'd hear back, but sure enough they still have the parts and a kit is now on it's way to me. Once that's put together I'll write a follow-up post about my first experience using the real deal.

Jason J. Gullickson, 2026

Heirloom Computing

Wed, 01 Apr 2026 07:32:43 -0500

Yesterday, Jamie was transplanting plants she sprouted indoors and planting a few new seeds as well. Some of the seeds came from a bag that was a gift from a friend and neighbor, seeds from the plants that have grown in this neighbor's garden.

Seeds like, the kind that a plant produces that can be used to grow the same plant again are referred to around here as "heirloom seeds". It struck me as weird that there was a special name for the normal reproductive cycle of a plant so out of curiosity I started looking into the history of this term.

As it turns out, it's quite controversial. Not only is the proper use of the term "heirloom" in reference to seeds a matter for debate, people have been fined and jailed over their use and distribution. Seed libraries have been shut-down and their seeds destroyed due to the threat such seeds pose to industry and the state.

This was a lot more dramatic than what I was expecting.

I won't try to enumerate all the explanations for this fear of plants reproducing and the humans with the audacity to help them (Wikipedia is a good starting point for that), but what I will dive into is how these ideas might apply to computing.

When I leaned about heirloom seeds I immediately drew parallels to the technology we depend on. Like food, many of us depend on some form of computer every day for our current mode of survival. Like a lot of food, we have little control over the computers we depend on. That control is delegated to a small group of private companies who mediate this access through the system of capitalism.

Computers are not able to reproduce in the same way as plants, but there's are ways of making computers, and especially software that could produce machines that can be rejuvenated generation over generation. In the hardware realm, computers can (and have) been designed to use components that can be reconfigured to meet the need of unexpected future generations. On the software side the type of reproduction we see in the natural world is even more possible as the copying and mutation of software distributed in source-code form consumes virtually no resources and unlimited potential forms.

Some might say that Free and Open Source Software achieves this goal, but I don't think you have to look too far into what FOSS has become to see that this is no longer true (if it eve was to begin with).

All this makes me wonder what "heirloom computing" would look like?

Certainly it means creating computers unencumbered by artificial legal constraints like licensing, copyright, etc. Modularity, in the form of making computers out of interchangeable, long-lasting parts is another component.

Something that I think is often ignored when discussing these things are the people who will be working with these computers, and in the heirloom model, the people who will be shepherding-in each generation. When I look to the heirloom seed for inspiration I see that this requires heirloom technology to be much simpler than what we have today. It must be as reproducible as planting and nurturing a seed. This isn't an oversimplification, anyone who's grown a garden from heirloom seeds knows that it can be tricky work, but this work can be written-down and even discovered through trial-and-error.

Additionally, like the seeds we received from our neighbor an heirloom technology is likely to have a regional dimension. This negates the need for modern global high-speed communication to share the knowledge needed to perpetuate each generation, and it reduces the energy expended to move the physical components of the technology from place to place. I also believe that a technology cultivated regionally will naturally evolve to suit the people and conditions of that region, diverging significantly from it's copies of itself in other regions over time. Beyond the advantages of being tailored for a time and place, such evolution allow the generational perpetuation to become easier over time, like the seed which is the descendant from generations of plants which faired well in local growing conditions.

To sum it up, and heirloom technology needs to be:

* Unencumbered by artificial constraints

* Simple enough for amateur cultivation

* Composed of durable, interchangeable parts (ideally heirloom themselves)

* Cultivated locally over generations

I don't know if that's everything, or exactly right, but it's a start. Off the top of my head I don't have an exact example of such technology, but I think many of the building blocks have been discussed elsewhere on this blog. Going forward, I'll keep these in mind as I design and build new things, and see if I can discover more of the answers.

Jason J. Gullickson, 2026

Printable Lunch Tray System?

Wed, 01 Apr 2026 19:53:19 -0500

Jason J. Gullickson, 2026

Cartesia Part IV

Thu, 02 Apr 2026 06:31:59 -0500

I've been thinking about the architecture of the Cartesia software a bit and trying to reduce it to the simplest possible form. In this post I'm going to attempt to summarize where I'm at.

There's two distinct pieces or modes of the software, one that a Person interacts with directly called the Deck and a second that is used to run shared Worlds, which we'll just call the World software.

The Deck software consists two event-driven loops: one that consumes input and updates local state (the Input-Update Loop or IUL) and a separate loop that renders the room.

The World software is the same as the Deck software, but only the first loop is used.

When the Deck is started the Person appears in Room 0.0.0.0. This is the Origin room in the Local World which is contained on the computer that the Deck software is running on. Initially this Room contains nothing but the Person.

The Person creates the World by providing input to the IUL. The loop is triggered by the end of the input and begins to parse it into Events. Two things happen at this point:

* Events are parsed into updates to the Local State

* Events are broadcast to other People and Objects in the Room

I suppose a cleaner way to look at it is that the Events are Broadcast, and that the Room is just another Object, and that the Local State is a Property of the Room that can be modified by the Events.

The important thing is that there is a narrowing pipeline of data between the Person and the World. A Person can input anything, and that input is turned into a limited number of known Event types at which point the Events are shared with Objects which in turn pass the Events to a limited number of Handlers which in turn modify a limited number of States.

If at any point along this pipeline the input from the original Person can't be interpreted automatically it is treated as Speech, something a Person is saying and delegated to more sophisticated interpreters: the other People in the room.

In a way this is similar to how the Forth language parses input:

* If the input is a number, treat it like a number

* If it's not a number, look it up in the dictionary

* If it's not in the dictionary, it's a string.

I may be oversimplifying Forth here, but that's how I remember it at least

This process repeats as long as the Person in Room 0.0.0.0 continues to talk to themselves, creating new Objects that become part of the Room's State.

When another Person enters the Room, two things happen:

* The Room's current state is described to the new Person's Deck as a series of Events

* The IUL of the new Person's Deck is attached to the Room's live Event stream

The IUL of the new Person's Deck processes first set of Events just like the original Person's Deck would and passes the Events to Handlers which in turn update the Room's State as stored in the memory of the new Person's Deck. Anything that falls-through the parsing pipeline gets rendered as Speech.

It seems unlikely/impossible that any of this would be rendered as such, since these events are derived directly from the State of the Room, but maybe in the case of a parser version mismatch, etc. this could happen?

Once this initial set of Events has been parsed the Render loop of the new Person's Deck will describe the Room, at which point the new Person will be caught-up and begin processing the live Event stream as it comes, just like the original Person in the room.

It's important to understand that all of this communication adheres to HNSI protocol and is essentially Human-readable. You can imagine interacting with these Worlds akin to reading a book. You read a sentence and in your mind you interpret it as either speech exchanged between characters or descriptions of the world inside the book that your mind turns into images and memories about what is happening. As you progress through the book you may refer to memories created earlier without having to literally re-read the descriptions of things and this functions akin to the State maintained in a Room. What's interesting to me about this analogy is that when you're reading, there are subconcious procsses that decide how much of this State you maintain and I think there is room for this sort of dynamism in the Deck software.

By treating the exchange of information as a Human-readable stream, processing of that information can be fluidly transferred between the machine and the Human based on a balance of where the best place to process it happens to be. I'm not sure about the exact mechanisms of this yet but the beauty of HNSI is that I don't have to know or decide that now (or ever). The simplest Deck imaginable could simply pass the raw communications stream to the eyes of a Person reading it, and the State of the Room, Objects and People could be completely in that Human's head. This allows for a huge range of Deck implementations based on whatever is avaliable and whatever skills the Deck builders may happen to have.

Jason J. Gullickson, 2026

RadioShack

Fri, 03 Apr 2026 08:27:26 -0500

I knew the name RadioShack long before I ever visited the store. My first memory of the name was seeing it on the little cards with a bubble of plastic containing some magical little component hanging from the pegboard behind my dad's workbench.

I'm sure I heard the words before I could read them, but I don't remember it that way.

My father, my grandfather (who turned-out not to be my grandfather but that's another story) and my family friends, a surprising amount of them were RadioShack regulars. Dad, grandpa, friends Rich and Clayton in particular tweaked on radios and then computers, amassing walls of those little component packages, testing equipment and tools from the 'Shack.

The next memory I have of RadioShack itself is looking at the catalog. I think this was still before I ever entered the store. Looking back on it, the Radio Shack catalog was sort of a strange collection of curated electronic curious. Electronic components, yes, pages of tables containing components but also what can only be described as strange household appliances, electronic toys and games and a few ...scientific? oddities like the solar-powered cigarette lighter.

What was so unique about RadioShack was that it wasn't just a place you bought things, it was also a place that helped you make things. It was the only place I knew of where I could get new electronic components (although as a kid I had to harvest most of the parts I used, I could only afford new parts after paying holidays), but they also had books and guides, many written by my favorite childhood author, Forrest M. Mims III.

When I was a kid I felt like I could build anything with nothing more than a break from school and a Radio Shack gift card.

As I discovered programming my interest in electronics began to wane. Not because I became less interested in it per-se, but because of the economics of it. To build physical devices I needed parts and tools but to build software all I needed was a computer. Once I had a computer of my own I did a lot less with electronics and my obsession with RadioShack faded as well.

When I got into making music I started making regular trips to the 'Shack again. In the small towns I spent my time in in my youth there were very few places you could get parts for electric instruments and my childhood of tinkering with electronics left me well-suited for hacking and repairing audio equipment into frugal musical gear. Our bands "PA" system was composed of modified HiFi equipment sourced from thrift stores and garage sales and modified & maintained by me. Parts from the 'Shack (mostly 1/4" plugs, teenagers are especially hard on guitar cables) kept us tearing-up garages and VFW's for years.

When I moved-on to the professional stage of my life I once again left the 'Shack behind except for the occasional cable or adapter for my home theater setup. Ironically I finally had some money to spend on parts but no longer the time or space to use them. Many years later I would get a chance to return to this work, accelerated by Jamie's interest in building props and sets for Halloween. This, coupled with the "maker movement" launched me back into collecting components, huffing solder smoke and dusting-off my copy of Getting Started in Electronics.

Sadly this renaissance coincided with the death of RadioShack. I visited a store during the final days and snapped-up a few boxes of parts. It seemed bizarre to me that they somehow survived the doldrums of electronic hobbies only to be snuffed-out during the hobby's resurrection, but that's capitalism for you.

Part of me would love to do something to provide others with the inspiration I got from that place as a child. I imagine others have had a similar experience as well. I have a couple of ideas for this but nothing that I'm sure about quite yet, but if one of them begins to take shape you'll hear about it on this blog.

Jason J. Gullickson, 2026

Stranger Fiction

Sat, 04 Apr 2026 07:59:26 -0500

I'm writing a new story. It's based on a nightmare I had recently that was quite terrifying. The story on the other hand is turning-out to be more of a black comedy, and for the first time in as long as I can remember I'm enjoying writing fiction.

My primary storytelling medium is film, so I see the story in my head as a movie. Because of this I'm often pre-preempted by the Producer in my brain who stops me from writing something because it's going to be impossible to shoot on an indie budget, or be too dangerous, etc. It's funny how much effort goes into silencing this irrelevant voice.

I've tried writing fiction before, mostly during NaNoWriMo. I tend to get off to a good start but after a thousand words or so I run out of steam. It's weird because it's not just exhaustion (although that can be part of it) but I tend to write in circles, or loose track of the overall plot and then the whole story just seems kind of boring to me and I never get much further after that.

This time is a bit different. I'm not sure if it's because the dream left me with a tremendous emotional charge or if it's something else, but I'm excited that it at least feels like I have enough... something to actually finish it.

I also did something I've never tried before: I wrote the ending almost immediately after starting the first chapter. This wasn't completely intentional, I started at the beginning the morning after I had the dream and then I sketched-out an outline so I wouldn't forget any of the parts I didn't have time to write that morning. A day or two passed and I thought of a couple of new things to add, so this morning I added the new stuff to the outline and then started to move the outline around a bit to make everything fit and flow. In the process something accidentally ended-up at the bottom of the list and when I read it in order it jumped-out at me that this might make a perfect ending.

So I ran with it and just wrote-out the final scene, and I have to say, I'm really happy with it.

Now that I have the beginning and the end filling-in the middle feels much more achievable than any other time I've tried to write something fictional before. Maybe this is just how other people do it and I'm too ignorant about the process of writing fiction to know?

Either way, I'm a lot more confident that I'll finish it this time since in a way, I kinda already have.

Jason J. Gullickson, 2026

Downlink 2026-04-04

Sat, 04 Apr 2026 12:07:38 -0500

This should have been posted yesterday, but I got busy...

* https://bookshop.org/p/books/danny-dunn-and-the-homework-machine-danny-dunn-3-jay-williams/12b56398f1a5e726?ean=9781479460816&next=t&next=t&affiliate=93920

* https://github.com/pks5/machineblocks

* https://duckduckgo.com/?t=ffab&q=cartisian&ia=web

* https://en.wikipedia.org/wiki/Self-actualization

* https://jasongullickson.com/the-humane-network-service-interface.html

* https://duckduckgo.com/?t=ffab&q=magnum%20opus&ia=web

* https://blog.adafruit.com/2026/03/24/fcc-just-banned-the-import-of-all-new-foreign-made-routers-heres-what-you-can-do-about-it/

* https://timereshared.com/tops-10-programming/

* https://www.404media.co/this-company-is-secretly-turning-your-zoom-calls-into-ai-podcasts/

* https://www.upi.com/Top_News/World-News/2026/03/23/craftsman-traditional-handicrafts-disappearing/1291774311771/

* https://hackaday.com/2026/03/23/acoustic-drone-detection-on-the-cheap-with-esp32/

* https://github.com/batear-io/batear

* https://theicelist.org/index.php/Main_Page

* https://www.bleepingcomputer.com/news/security/teampcp-deploys-iran-targeted-wiper-in-kubernetes-attacks/

* https://www.hollywoodreporter.com/tv/tv-news/starfleet-academy-canceled-1236544496/

* https://hackaday.com/2026/03/23/build-this-open-source-graphics-calculator/

* https://github.com/El-EnderJ/NeoCalculator?tab=readme-ov-file#hardware

* https://www.olleewatch.com/

* https://toot.cafe/@reconbot/116275998271249885

* https://duckduckgo.com/?t=ffab&q=the%20old%20psychiatrists%20club&ia=web

* https://orgivemedeath.substack.com/p/in-search-of-the-old-psychiatrists

* https://en.wikipedia.org/wiki/Gene_Roddenberry

* https://en.wikipedia.org/wiki/Andrija_Puharich

* https://en.wikipedia.org/wiki/Pan_Am_Flight_121

* https://en.wikipedia.org/wiki/Horatio_Hornblower

* https://en.wikipedia.org/wiki/Star_Trek:_The_Motion_Picture

* https://en.wikipedia.org/wiki/Star_Trek:_The_Original_Series_season_1

* https://en.wikipedia.org/wiki/Z-machine

* https://en.wikipedia.org/wiki/SCUMM

* https://www.w3schools.com/python/python_lists_add.asp

* https://docs.micropython.org/en/latest/genrst/core_language.html#f-strings

* https://jasongullickson.com/cartesia-part-i.html

* https://github.com/Crosstalk-Solutions/project-nomad

* https://rasterweb.net/raster/2017/04/09/apple-wait/

* https://www.reddit.com/r/VintageApple/comments/15uh67r/any_tips_on_the_restoration_of_a_couple_of_apple/

* https://asciiexpress.net/diskserver/

* https://apple2online.com/?page_id=2590

* https://tinkerdifferent.com/

* https://www.openstreetmap.org/node/153660123#map=19/43.421054/-88.340865

* https://ia601203.us.archive.org/9/items/swyftcard_manual/swyftcard_manual_text.pdf

* https://www.willegal.net/swyft/swyftcard.html

* https://palmettostatearmory.com/cmmg-mk4-dl-44-blaster-22lr-5-10rds.html

* https://www.adtpro.com/

* https://www.summitcreditunion.com/bank/money-market-account/

* https://www.txdpscu.org/education/dividend-rate-vs-apy-whats-the-difference/

* https://www.nerdwallet.com/banking/learn/money-market-vs-cd

* https://www.bluettipower.com/products/apex-300-home-battery-backup?variant=68804e7e63e18b529ef2604a

* https://codeberg.org/positionhigh/MicroDexed-touch

* https://www.openstreetmap.org/relation/8353666#map=9/46.145/-90.775

* https://luckyslakeside.com/

* https://www.northwoodsmfg.net/about-us

* https://en.wikipedia.org/wiki/Tracy_Kidder#Career

* https://makerworld.com/en/models/2459767-garden-gnome-with-shovel#profileId-2700742

* https://www.printables.com/model/900605-blank-tombstone

* https://codeberg.org/jjg/cartesia

* https://jasongullickson.com/cartesia-part-iii.html

* https://duckduckgo.com/?t=ffab&q=heirloom&ia=web

* https://www.landsnail.com/a2ref.htm

* https://en.wikipedia.org/wiki/Apple_80-Column_Text_Card

* https://retrocomputing.stackexchange.com/questions/19681/apple-ii-toggles-between-40-and-80-columns-in-assembly-language-apple-iic

* https://cowaymega.com/products/mighty-ap-1512hh?variant=33436620783751

* https://www.lego.com/en-us/product/concorde-10318

* https://en.wikipedia.org/wiki/Forrest_Mims

* https://archive.org/details/getting-started-in-electronics/Getting%20Started%20in%20Electronics

* https://www.ebay.com/sch/i.html?_nkw=apple%20super%20serial%20card&_sacat=11189

* https://www.ebay.com/str/aple2plusparts

* https://en.wikipedia.org/wiki/Apple_II_serial_cards

* https://en.wiktionary.org/wiki/zealot

Jason J. Gullickson, 2026

Hey U

Sun, 5 Apr 2026 19:50:39 -0500

Lifeboat

Mon, 06 Apr 2026 07:29:03 -0500

This post is about a new virtual machine I'm calling "Lifeboat" (at least for now). This isn't a specification, so be prepared for it to wander around a bit.

The primary goal of Lifeboat is portability. I've talked about why this is important before. Lifeboat should be simple enough that an expert in programming any given piece of hardware could port it (and therefore all software that runs on it) to a new piece of hardware in a weekend.

Lifeboat consists of three primary components:

* A central processor (CPU) loop

* Random-access memory

* Device driver loops

These names may change.

The layout of Lifeboat is simple. It consists primarily of a linear range of memory addresses. Both the CPU and driver loops have access to this memory for read and write operations. As you might guess, the CPU does most of the work, moving data from one memory location to another and performing basic mathematical and logical operations. The driver loops are allocated sections of memory which they read and/or write to depending on the nature of the device they interface with.

Whether these loops are implemented as discrete processes running on dedicated hardware "cores" or as one big cooperative loop on a single processor is completely up to the discretion of the implementer.

I think the easiest way to continue is to use an example program, and yes, you know it's going to be "Hello, World!".

I'm going to use BASIC for the language of the example as the default high-level language of Lifeboat will probably be something like BASIC.

10 PRINT "HELLO, WORLD!"

The interpreter translates this into just two, repeated Lifeboat opcodes:

LOAD A 1000

STORE A 5000

(repeat once for each character in the string, incrementing each location by 1)

The first opcode loads the value at memory address 1000 into CPU register A, and the second opcode stores the value just loaded into register A into a new memory location, 5000. These two opcodes are repeated once for each character in the string. This might not seem like much, but it results in printing the words "HELLO, WORLD!" on the display.

The interpreter knows that the letters in-between the quotation marks on line 10 are stored in RAM beginning at location 1000. It also knows that the RAM associated with the display driver begins at location 5000. It knows that any character placed in display memory will be rendered to the display by the display device driver loop, so all it needs to do to PRINT a string is copy that string into the memory allocated to the display device driver.

At the same time, the device driver loop for the display reads each memory location that is allocated to it and renders the value in that location on a display screen. Exactly how it translates the values stored in memory to a visual image is entirely up to the driver. In this case, the driver scans it's memory range sequentially and selects a glyph from a table that matches the value in each memory location. It then draws the glyph on the display, one after another in the same order as they appear in memory.

As a result of these two simple loops, the words "HELLO, WORLD!" appear on the display screen.

This example might seem too basic to be valuable, but a more complex program and a even a more sophisticated computer (with multiple input/output devices, etc.) requires nothing more than additional opcodes, additional lines of instructions and additional device driver loops. Any additional complexity is pushed-up to the language and application software layers to keep the VM itself as simple as possible (remember the primary goal is portability).

...and of course there are devils in the details. The most obvious is the potential risk of two loops accessing the same memory location at the same time. However, I'm deliberately deferring decisions on how to manage risks like this until I observe them happening in a real implementation. I don't want to over-complicate the VM through premature optimization, and I have a hunch that problems like these might be best left to the implementer who can, at their discretion, leverage features of their chosen hardware to handle such cases in the best way for their given device.

Jason J. Gullickson, 2026

It's Swyfty Time Today

Wed, 8 Apr 2026 12:55:52 -0500

Synchronized Remote State Machines

Thu, 09 Apr 2026 07:52:01 -0500

Synchronized Remote State Machine (SRSM) is a software development pattern for keeping multiple objects in sync between multiple machines across a network. Changes made to the object on one machine are automatically reflected on the others, regardless of what machine the change originates on.

Some advantages over other synchronization methods:

* Transparent operation

* Implementation agnostic

* Unassisted firewall traversal

* Rapid synchronization

* Graceful degradation

* Flexible network configuration

Background

This idea came to me while thinking about how I'd write the software for a website where I could upload work for the 3D printers at the shop. The website would need to know when the printers were ready to receive more work, and the printers would need to know when new work was available.

There's many ways to write such a piece of software but the most common ones are problematic because of differences between computers, programming languages, etc. The other more significant problem is that bi-directional communications between computers on public and private networks are difficult or impossible due to the current architecture of networks, routers, firewalls, etc.

Beyond these implementation concerns there's also the problem of deciding up-front how the application will communicate over the network. This process is typically accomplished by designing an "API", a process which is done at the beginning of the design process. It presents something of a chicken-and-egg problem because to design the API right you need to know in advance everything you're going to need to communicate between the systems before you make any of the things that will be using the API. The result is that the API often has to change over time, breaking things that were designed for it's original form and leading to bugs, rework, etc.

While I was mulling all this over the basic idea of SRSM popped into my head, and after thinking about it for awhile it evolved into something that I think solves all these problems quite well.

Theory of Operation

Programmer-defined object classes (or their equivalent) are derived from a base SRSM class which contains the following components: an ordered incoming event queue (IQ), an ordered outgoing event queue (OQ), an object-to-event translator (O2ET) and an event-to-object translator (E2OT). The final component of the base class is a communications channel (CC) formed from a medium common to all systems and languages that will host synchronized objects.

When properties of the inheriting class are modified, these changes are detected by the O2ET and placed in the OQ. That's all that really happens when there's only one SRSM object on the scene.

When the same object is instantiated on another machine that should be synchronized with the first, an optional address parameter is passed during initialization which contains a routable address (IP address, DNS name, etc.) for the machine hosting the object to be synchronized with.

Initialization is similar to above with the exception that before the values of the properties of the inheriting class are initialized the CC connects to the CC of the SRSM at the supplied object. Once connected, it receives events from the remote objects OQ into the local objects IQ. The local objects E2OT, attached to the local objects IQ, applies the events to the properties of the local object. Once synchronized, the reverse happens and the remote object receives any events that are in the local objects OQ. This bi-directional connection remains in place for the lifetime of the object or until the CC is disrupted.

At this point both objects are synchronized and any further changes to either will be reflected in the other as quickly as the CC can transmit the events.

Since event data is only transmitted across the CC when something changes there is a periodic heartbeat sent across the CC so that objects on either side can tell the difference between lack of activity and a broken CC.

Implementation Details

I'm still working on a reference implementation now, but here's a few key implementation details that might help answer some questions until that's ready.

The CC can be anything but will most often be a Websocket. This provides the most cross-language and cross-platform compatibility and is what provides the firewall traversal features of SRSM.

Heartbeats are sent once per second and include a time synchronization signal to cancel-out any time drift between remote objects (essential for proper event sequencing).

Events in ordered queues are timestamped to the microsecond. This allows them to be replayed in the correct order regardless of almost any imaginable CC latency. Latest event always wins.

Ordered queue lengths are technically limited only by available memory but sane defaults based on the implementation target are required.

Queue "roll-ups" are being considered (perhaps triggered by heartbeats) to automatically manage queue length when the CC is down.

SRSMs can be chained, with multiple remote objects connected to a single routable object and network-local-only objects descending from the remotes (in a star or snowflake fashion) if desired. This could be used to create dynamic and/or resilient networks of objects, and precise ordered events should remove any risk of data damage from mistakes like routing loops (although such loops might be wasteful of computing and CC resources).

Jason J. Gullickson, 2026

The Monofile Manifesto

Thu, 09 Apr 2026 10:48:53 -0500

Everyone knows the benefits of moving all your code into a single, gigantic Git repository with millions of files, hours-long CI runs and the joy of making one unrelated change and breaking the entire build, but the time has come for the next step in the evolution of DX: Monofile.

Monofile provides all the benefits of Monorepo with the added benefit of only having to work with a single file! No more burdensome searching across the millions of files in your Monorepo, no more flipping between tabs in your IDE, just one continuous stream of text, millions (billions?) of lines long.

Using a single language like JavaScript? Good news! Your development environment looks just like your runtime environment with all the source code concatenated compiled into a single file you pass to Node.js!

Using more than one language? Just insert a Markdown-style language separator between sections and use our patented pre-processor to compile everything "correctly" into a single "binary" you upload directly to your production server.

```sql

SELECT * FROM PUBS

```

```typescript

let foo = bar + baz;

console.log(foo);

```

```js

query = db_select + rawUserInput;

runQuery(query);

```

Other benefits include:

* Now the same lint rules can apply to every language you use!

* CI is a single, hours-long step!

* No more complicated build system, containers etc.!

* No need for a memory-hogging IDE!

* One easy payment!

You might be worried that Monofile isn't compatible with LLM coding tools but don't worry, it works as well or better than any previous methods.

How to get started

Contact sales to get a schedule of our professional training sessions where you'll get the training, tools and psychotropic drugs you'll need to get started with Monofile. Book soon, sessions are filling-up fast!

Jason J. Gullickson, 20206

Quality Time

Fri, 10 Apr 2026 06:55:47 -0500

I was going to give-up on working with the ESP32 because I found-out that Micropython became infected with LLM code. This meant I couldn't rely on Micropython even if it's fine for now, because it's too complex for me to replace it if and when things go south.

Without Micropython the ESP32 becomes unusable to me because the device itself as well as it's native programming environment are closed, proprietary things that present the same sort of "lock-in" I'm trying to avoid with Micropython.

This is a bummer because while I can easily come-up with ways around this (Lifeboat being the first that comes to mind), that takes more time, and time is something I have precious little of at the moment.

But all is not lost.

There's a relationship between what I'm working on and how much time I have.

I should qualify that by saying "Quality time", because for me there is a big difference between an hour when I'm feeling great and an hour at the end of the work day when I'm completely fried.

If temporarily compromising and working with the foul fruit of the LLM allows me to transition my professional work (i.e., making a living) from an environment where I'm forced to spend eight hours a day working with LLM's on OPP (other people's products/other people's profits) that frees-up and increases the amount of Quality time I have available. This in turn makes it easier to pursue things like Lifeboat, which in turn make it possible to escape dependency on code and systems which may at any time become unviable.

This attitude, aligned with the practice described in Other People's Tools gives me a bit longer lever to leverage myself out of the current technology trap.

The key is to be sure to build in a way that doesn't close-off the exits to this escape plan. A simple example of this would be to construct new, valuable things that depend on language features of Micropython so much that when something like Lifeboat becomes viable it's practically impossible to jump into it. This requires discipline, preferably internal, on the part of myself and the people I'm working with.

So long as I have a choice in who I work with on these projects I don't think that will be a problem.

Jason J. Gullickson, 2026

Xteink X4 Research

Fri, 10 Apr 2026 07:20:37 -0500

Hardware

* ESP32-C3

* SSD1677 compatible display driver

* Hard to find out exactly what display is used...

After reading about the limitations of the ESP32-C3 I don't know if this device is worth investing time in. It's really cool, and has a lot of attractive hardware features but the single-core, small memory and limited connectivity of the C3 variant will make it hard to do the things I want to do with it

A better option would be assemble a similar platform based on the ESP32-S3. In addition to dual-cores and more connectivity, the S3 is interesting because of the vector hardware, and while I don't care about "AI" in the contemporary use of the term, that hardware could make it possible to do useful things on-device that would otherwise require depending on an external service.

That said, it might be possible to use this device to feel-out the limits of using an inexpensive e-ink display like this for interactive applications, specifically typing text. So to this end, using it with something like Adafruit's CircuitPython (which appears to be at a usable stage) to see how realistic using the Circuit/Micropython+ESP32+e-ink stack is for an interactive, text-based interface.

References

* https://github.com/sunwoods/Xteink-X4

* https://learn.adafruit.com/circuitpython-on-the-xteink-x4-ereader/overview

* https://www.espressif.com/en/products/socs/esp32-c3

* https://tinkeriot.com/esp32-variant-guide-c3-c5-s2-s3/

Jason J. Gullickson, 2026

Gettin' Swyfty Part II

Sun, 12 Apr 2026 13:28:40 -0500

I got a chance to assemble and test Mike's SwytftCard replica kit today. The kit is great and only took about a half-hour to solder it up.

The kit comes with a little booklet with both assembly and usage instructions. On the assembly side it's very complete and easy to follow, my only suggestion would be to add the schematic component keys (R1, C2, etc.) to the parts list. For the most part it's pretty obvious which parts go where but I did find myself second-guessing the very first component in the build because it was the first of four resistors to be installed but this first part is actually R4 on the circuit board.

I must admit I was a little nervous about the first power-up since there's a chance that if I did something wrong I'd not only smoke the SwytftCard but possibly my whole Apple //e as well...

Fortunately applying power released no blue smoke and I was greeted with a "beep", a flash of a startup message and an empty document!

The basic guide included with the kit has most of what you'll need to get started with the SwyftCard with one exception. Unless you happen to have a blank 5.25" floppy disk, you'll need to initialize an existing one before the SwyftCard will let you save your work. The process for doing so is documented in the full SwyftCard manual, but I think this would make a good addition to the kit's included guide as well.

FOLLOWING THESE STEPS WILL DESTROY ANYTHING ON THE DISK YOU STICK IN THE FLOPPY DRIVE. YOU HAVE BEEN WARNED!

1. Insert the disk you want to format into the first floppy drive

2. Type the following (I used all caps, I'm not 100% sure matters):

CALL 3600

3. Highlight the text by pressing both LEAP keys (open-apple and closed-apple, the keys on the left and right of the space bar) at the same time

4. Hold USE FRONT (Control) and press CALC (the letter G)

5. Delete CALL 3600

That's it. Now after typing some stuff press USE FRONT (Control) + DISK (L) and whatever you typed will be saved to disk. If you boot the machine with this disk in the drive, the text will load automatically and you can start working exactly where you left off.

What's Next?

I can't convey how excited I am to start working with this system. There are still a few more steps I need to complete before I can really do that, the main one being swapping the TV set I'm using for a monitor with a "real" composite monitor that can correctly display 80-column text (the TV works well enough to confirm things are working, but it's not very readable).

The second thing I'd like to do is add a serial card to the Apple //e so I can experiment with the other I/O features (other than disk I/O) of the SwyftCard. These were originally intended for printing and communicating with other systems (both other SwyftCard systems and other types, such as BBS's reachable by serial or modem connections). There are a lot of devices and services that are accessible via serial-type connections that I'd like to experiment with using from the SwyftCard environment.

Jason J. Gullickson, 2026

Lone Goose

Mon, 13 Apr 2026 23:36:59 -0500

My next version of Preposter.us won't be Preposter.us

Tue, 14 Apr 2026 07:55:18 -0500

This morning I'm thinking about the successor of my current blog software, Preposter.us. It has been a reliable collaborator for many years (at least twelve) but this morning I realized that what comes next will be something completely different.

I love Preposter.us, and I honestly believe that with a little work it could be perfect within itself, but what's happened to Internet Email is something that I can't fix, no matter how good Preposter.us is.

What I can do is make something better, and right now that better is a new kind of personal computer that works in a much different way than the computers I've used for email in the past, and very different from how most people use computers altogether today.

So the way I publish this blog will change radically once this new personal computer is good enough for me to use on a daily basis.

I don't know how soon that will be, it could very well be a long-ways off, and I could be using Preposter.us for years to come. But I'm writing this now if for no other reason to cement in my mind that the new thing is coming.

Even when that day comes I don't plan to shut-down Preposter.us. I will continue to pay for and operate the website, and I may even continue to work on the software. I'd love to find others who are as passionate as myself to take the reigns and continue the work (ideally people with more time to spend on it) but even if that doesn't happen I don't see myself shutting it down anytime in the foreseeable future.

I should write more about what the next thing will be, but I kind of want to experiment with actually making it before talking too much about it. I don't want to get painted into a corner.

Jason J. Gullickson, 2026

Anarchy at Work

Tue, 14 Apr 2026 09:30:09 -0500

A few days ago I read The Seed Beneath the Snow, then I read the linked posts and then a few days later there was a re-org at work that triggered a lot of conversations about how the changes might impact Quality, and I not only referenced ideas from all three posts but even shared a link to the first with a select few co-workers who I could trust.

Reflecting on these events brought something to mind that you would expect to be obvious to me but in all honestly never really occurred to me:

The same practice of being an anarchist in the world might be applied to work as well.

Just saying that "out loud" feels crazy, but I think it's literally the point of the first post, and when I reflect on what has worked and what hasn't in my career, it is the times in which I naturally, unconsciously worked this way.

Some might frame this as "asking forgiveness instead of permission", which I suppose is part of it, and even the wretched "move fast and break things" might intersect with this in some sort of Venn diagram but what I see as the essential difference between these practices and what I'm talking about is where the original motivation comes from and what results are acceptable.

An effective anarchism at work will begin and end with care. Care for co-workers, care for the people who use the things you make, perhaps care for the work itself but that's certainly the lowest priority of the three.

While recent mandates may feel like the most repressive, I have always been subjected to them in one form or another when working as a "professional". In order to remain employed, the mandates must be conformed to, but only to the extent that this conformity can be measured. It can be difficult to discern exactly how conformance is measured and crafty bosses have certainly devised difficult to observe measurements, but performing conformance with a wide enough margin of safety often still leaves room for cooperation and collaboration with co-workers in the care-centered way of mutual aid and other diverse tactics.

All of this has me thinking about how more deliberately cultivate these autonomous zones, both for the purpose of personal heath but also to build solidarity and subvert efforts to dissolve it and pit workers against one-another.

The more I think about it the more this seems like a way to survive until we can build the new world, which is probably the most constant theme I've experienced in all of my anarchist studies.

Jason J. Gullickson, 2026

Elbow

Thu, 16 Apr 2026 07:23:44 -0500

Inky

Fri, 17 Apr 2026 08:18:59 -0500

RSD 2026

Sat, 18 Apr 2026 22:27:46 -0500

Four shops, four towns, 350 miles and way too many records.

The Seed

Sun, 19 Apr 2026 11:37:08 -0500

CircuitPython on the XTEINK X4

Tue, 21 Apr 2026 07:06:13 -0500

I've been considering using an XTEINK X4 as a "test mule" for some deep future computing experiments and although I've ruled it out for the long-run, the board I prefer is out-of-stock until October so I needed something to work with until then. While I was researching the XTEINK I found an Adafruit tutorial for installing CircuitPython on it and that clinched the deal.

Getting CircuitPython installed was trivial once I decided to stop doing it the hard way. This meant installing a web browser that supports Web Serial, and Chromium fit the bill.

After that the next hardest part is getting the device connected and having a serial port show-up. I found the most reliable way to do this was to connect the device, turn it off and then turn it on again and not touch it. Right after it started I could see /dev/ttyACM0. For some reason that port will disappear occasionally, or sometimes the device will appear as /dev/ttyACM1. Computers, so non-deterministic...

Anyway, once the port is visible you can start the web flashing process (after backing-up the original firmware as instructed) and in a couple minutes you'll have CircuitPython installed. From this point the tutorial takes you through the process of getting it on the network, accessing the various web interfaces, etc.

I was able to spent a few hours over the last few days experimenting with this setup and while it's a bit more complex than what I like to work with, it worked pretty well. I was able to figure out how to use the terminalio module to display text on the e-ink screen, work with files on the filesystem, etc. I even managed to port one of the Pouch tools (Jet, a journaling tool) to the device, write some journal entries and have them rendered on the e-ink.

Along the way I uncovered some limitations or hang-ups of this setup for the type of work I have in mind.

The first is that there doesn't seem to be a way to use the e-ink display as a regular terminal. The only way I found to update it is to refresh() the entire screen which is slow (like, seconds). I know there must be a way to do partial updates to the screen (the original firmware did this) but even then it's never going to work for things like scrolling text. This isn't a complete deal-breaker, I have some ideas for how to work with these limitations but it does mean that I can't simply use the tools I've written with this display the way I'd used them with a regular terminal.

The second is how CircuitPython expects to be accessed over a network. This is very handy if you use only one WiFi network but if you were to say, take the setup to the coffee shop there's no way to switch networks without resorting to using a physical serial connection. Again this isn't a deal-breaker (I usually carry all the cables I need and I don't mind using a serial console) but as-is it would be a serious limitation for using the device outside of experimental environments. That said software could be written to compensate for this so it's not a dead-end.

The third is the lack of a real-time clock. Most of the programs I want to run on this device produce files with date stamps which requires the device to know the current date. I was able to work-around this by manually setting the software RTC to the current date/time, but this will certainly drift, and of course will need to be reset anytime the device is restarted. I can work around this for experiments but it would be frustrating for long-term use.

The more serious limitation is how the buttons on the device are connected to the embedded processor. There are several buttons on the device, but they are connected to only three GPIO pins on the microcontroller and none seem to be connected to the reset pin. Not only does this limit the things you can do with these buttons, it also means that you can get the device into a "stuck" state which may not be recoverable, like I did.

I tried a number of things to get the device out of "safe mode" but no matter what I do it insists that the BOOT button is being held-down at startup. My guess is that whatever pin is normally connected to the BOOT button on CircuitPython devices is permanently pulled high or low on the XTEINK X4, forcing it into safe mode potentially forever. I have an open question on the Adafruit forums to see if there is a way out of this, and I'm also going to re-flash the CircuitPython firmware to see if that works as well, but re-flashing the firmware every time it cold-boots isn't going to work for a platform for experimentation.

If I can find a way to resolve the safe mode issue without resorting to prying the device apart, I think I can work-around the rest of the limitations well enough to keep the software work rolling until I can get the right hardware for the job at the end of the year. If not, this thing will probably have to go back to being just a tiny e-reader.

Jason J. Gullickson, 2026

One step closer to perfection

Wed, 22 Apr 2026 18:27:16 -0500

Wine Cooler

Sun, 26 Apr 2026 07:49:09 -0500

I spent a couple hours last night in the lab working on a friend's specialized refrigerator made for chilling wine (probably called a "wine cooler" but every time I say that I can't help but think Bartles & James). It stopped working, and when he pulled it apart noticed that the fan on one end wasn't spinning and turned with some resistance. When he showed it to me it was apart on a counter and I offered to take it home to the lab for some measurements.

It's a fairly simple device, little more than a Peltier cooler, power supply and thermostat. There's two of these Peltier/power supplies pairs, one on each end of the cabinet and both are controlled by a single board that provides buttons to set the desired temperature and turn the internal lights on-and-off.

Taking voltage measurements at the various connection points of the power supply board on the misbehaving end confirmed that it wasn't putting any power out to the fans, and temp measurements on the hot and cold sides of the Peltier showed virtually no change. I compared this to power and temperature measurements on the other end and things were more of what you'd expect.

Given this I'm fairly confident that the power supply is shot, and at least one of the fans are bad. I'm guessing that the bearings are failed on one of the fans, and either the fan or the Peltier or both pulled too much current and overloaded the supply. I would expect this to trip a breaker or blow a fuse, so I went hunting for such things on the power supply board.

I located two fuses but they were both intact. Hmm... It would not be out of the question for something else to fail on a board like this, and after a few web searches I found a lot of similar stories about coolers like this failing. Some had detailed technical discussions and even successful repairs, most repairs consisting of replacing some or all of the electrolytic capacitors and/or the power transistors.

So chances are that replacing or repairing that power supply board is all that is needed, but something that bugged me the entire time is that the control panel never lights-up. It has a two-digit LED display for the set temperature, and one of the buttons should toggle the internal lighting and neither of these things lights-up when power is applied. Since this board appears to contain the thermostat function it's possible that it could be malfunctioning and sending the wrong signals to the power supply that appears to be failing. My confusion is compounded by the wiring to this control panel because it's not crystal clear to me where it's power comes from.

There's a connector that goes to the temperature sensor, two that appear to go to the internal LED's and then two more, each connected to a 3-pin connector on each power supply which I assume controls the cycling of each Peltier. So where does the power for the control panel itself and the interior LED's come from? It must come from the power supplies, but there's no clear positive/negative connection to one of the supplies, just these two three-pin connectors. It's possible the control board gets it's power from these 3-pin connections but if that's true why isn't it lighting-up if one of the power supplies appears to work?

Without knowing the answer to this I can't be 100% sure replacing the dubious power supply will fix the cooler, so I started thinking about ways I could isolate the control board from the equation and at least increase my confidence that the power supply in question is bad and it's not just getting bad instructions from a faulty controller.

This was fairly easy because I was able to confirm that the "working end" continued to behave the same even if I removed the connection to the controller board. I also noticed at this time that there's two LED's on the power supply board (red and green) and that they both light-up on the working supply. When I repeat the same test on the questionable end, there's still no power at the outputs, no temp change across the Peltier and neither of the LED's illuminate.

At this point I'm confident the power supply is toast. This doesn't tell me anything certain about the control panel board though, and it still leaves me puzzled at to why the controller doesn't light-up.

I was able to find replacement power supplies that look to be similar for around $100 delivered. This would be the easiest thing to try to fix the cooler (coupled with at least one replacement fan), and I'm confident that the power supply needs to be fix/replaced, but even with a new supply I can't be 100% sure the unit will work because I don't know what is up with that control panel board. My biggest concern is that something in that controller is bad and when I attach a new power supply to it, the new supply will get damaged by a fault in the controller. I'd really like to see the controller work before advising my friend to spend $100 on a new part.

This is complicated by the fact that I can't locate a drop-in replacement for the controller board, so even if the new power supply isn't ruined by a faulty controller, I can't simply say "spend another $x dollars to finish the job", and if I can't repair the controller board it might just be a waste of money to replace the power supply.

The whole time I've been working on this my mind wanders-off designing replacement electronics instead of trying to understand/diagnose the broken ones. I'm sure I could design a replacement that would be more serviceable and probably less expensive than the replacement parts I've been able to find (not to mention the parts I can't find). But that is a much more time-intensive project, something I don't honestly see me finding time to complete until next winter.

I could also try repairing the faulty power supply first, which might only require a few dollars worth of parts (most or all I probably have on-hand somewhere). But here again there's a significant time bump involved in that approach that I don't know I'll have, and it's entirely possible that the repair will fail and we'll be back at ordering a $100 part.

I didn't like any of these options so I decided to sleep on it.

In the morning I had one more idea as to how to test the control panel board. Maybe it gets it's power from just one of the 3-pin leads coming from one of the power supplies, and maybe it's the connector that is connected to the bad supply? This seems weird to me but honestly there's a lot of things about this device that seem weird, and I seem to remember that the two 3-pin connectors were labeled A and B or 1 and 2 or something that indicates that the connector that goes to the dead supply is the "first" one. So if the controller gets it's power from only one of the supplies, then it seems reasonable that it would be getting it from the dead one.

So I'm thinking my next step is to swap the 3-pin connectors and see if the control panel lights-up. If that happens I can be a lot more confident that swapping the bad supply and fan will fix the thing. If not, then maybe I can try to learn more about the controller board (maybe just manually trace it out) and find some way to reliably test it. Until I know it's condition (or can find a replacement) I just don't feel comfortable recommending my friend throw any money at the thing.

(in the meantime I'll keep dreaming-up an open replacement as well)

Jason J. Gullickson, 2026

Stay the course

Wed, 29 Apr 2026 07:14:30 -0500

I have to keep reminding myself to focus on the future and not the past.

This morning I tried to use one of my old projects to setup a simple filesharing site and I was reminded of what a disaster contemporary computing is. I started to go down a rabbithole of fixing this, if only so I could run my own software and 30 minutes later I lost all my gumption and wanted to go dig ditches.

Then I saw a toot from a friend who is working on a new computer, and thought about how we might collaborate to build the new computer I'm working on, and all was right with the world.

I don't know why I have to keep re-learning this the hard way, but I guess so long as I keep re-learning it somehow, that's OK.

Jason J. Gullickson, 2026

Dreams

Wed, 29 Apr 2026 07:53:49 -0500

As I spend more time with the Apple //e Swyft machine I'm inspired by the joy it brings me to create something like this myself. Maybe a direct descendant from Raskin's work, maybe a "spiritual successor", or maybe something entirely different so long as it captures whatever it is that makes the SwyftCard system so enjoyable to me.

I'm trying hard not to jump to any conclusions about exactly what that is and instead focusing on just using the thing and noticing what feels good. There is always a temptation to make it do more, but I've found that it's very easy to curb that by paying close attention to how things feel, and when they stop feeling good, I stop going in that direction.

As it stands today it's a fully functional stand-alone system that I use daily in place of my other electronic journal (Jet) when I happen to be at the desk which the Apple //e sits on. When I'm elsewhere I have to use something else, which is a bummer.

It doesn't feel good.

So something that I'm certain will be a part of the new machine is portability. This isn't a surprise, but I'm glad to have it confirmed through experience.

Another thing that is simply amazing about Swyft is how fast you can get to work. If I left the data disk in the disk drive after my last session, the machine is ready for me to start typing before the CRT monitor can even warm-up. I would guess (I haven't timed it precisely) that it has loaded the text from the disk and is ready for input in about five seconds. This is pretty miraculous for a machine of such meager resources and a storage device that transfers data slower than any modem I've ever used.

This "readiness" makes a huge difference for me, because it's very easy for a thought to slip from my mind through distractions or just because something else takes its place in my head. The ability to have a thought and begin tapping it into my journal with no time for it to dissipate is very important to me and is probably one of the reasons working with Swyft feels so good.

Another things I've noticed is how foolproof persisting the text is. There is no Open/Load/Save/Save As/.etc. commands but only only one disk command, the "DISK" key (CTRL-L). If you have a text loaded, it saves the text to disk, if you don't have a text loaded, CTRL-L loads it. There's no way to screw this up. A disk is a unit of text, and the system is smart enough to prevent you from overwriting the text of one disk over the text of another (it will simple "beep" at you if you try to do something destructive). It's simple and works flawlessly. One of (perhaps the first) rules of user interface design is to never loose someone's work, and this simple mechanism obeys that rule splendidly.

I'm in the process of connecting the machine to the outside world and I'm being very careful to avoid falling into the traps or default behavior that makes contemporary connected machines destructive to work and creativity. Perhaps surprisingly the SwyftCard provides communications facilities but of course they are radically different from anything we're used to in the 21 century. As I sort-out the way to make this work with modern networks I'm treading very lightly to preserve the well-thought-out nature of these communications tools so that even once it's connected to the network the joy of working with the machine is preserved.

Jason J. Gullickson, 2026

Papercuts

Thu, 30 Apr 2026 06:31:42 -0500

I don't remember if I've written about this before but one of the most useful things I've learned about at my job is the idea of "papercuts" as an analogy to small problems that don't seem to justify a solution but are just painful enough to be distracting.

At work this term was used in conjunction with "incident" in the context of "developer experience" (which is just a trendy way to say programming tools). The "papercut incidents" channel was a place to bring-up problems with the development tools that were not serious enough to call for a formal intervention but were annoying nonetheless. Having a place to discuss these gave everyone a chance to see what little things were causing problems for everyone and address them together.

This is a powerful idea. Most of us spend at least some time each day living with such papercuts and while they are usually easy to ignore, they still have a cost and if left unresolved, that cost can compound.

By acknowledging and sharing these papercuts we not only have a way to help each-other out, but I've found that these small injuries are often more dangerous in the long run that the major ones. Major injuries are visible, they are talked about, and they draw attention that makes it easier to heal them. Papercuts go unnoticed, but if we create a place and a way for them to be noticed they are often easy to solve or compensate for, making a way for real and regular improvement in life.

Jason J. Gullickson, 2026

Daydreaming about my next computer

Thu, 30 Apr 2026 07:24:59 -0500

I'm planning to spend a lot more time with the SwyftCard before I start building anything, but if I was going to build my descendant of the Swyft today, what would it be?

Physically, it would be inspired by the Olivetti M-10. The "slab" form-factor is the simplest thing that can work for this IMHO and the Olivetti improves on the TRS-80 Model 100 by allowing the display to be adjusted which is simply more ergonomic. It's also got that "it" factor of Italian design so until I can come up with something better, I think that's the place to start.

It would use an ortholinear keyboard layout with LEAP keys on either side of the space bar. That might mean moving the "layer" keys needed to get a full character set out of the ortholinear arrangement but that's OK.

I think the DISK key could be eliminated (it's probably OK to passively persist the text to storage automatically) but the rest of the special keys used by the SwyftCard would remain.

The electronics utilize FPGA for most major functions. Whether this is a single large FPGA or several connected by a bus (probably i3c) will come down to the number of LUTs needed to implement the components and the avaliable capacit of open FPGA chips of reasonable cost.

The CPU is possibly a Motorola 68k core, possibly a custom processor designed to run Forth, or someting even stranger. This will depend on the software, which is discussed later.

If possible, RAM is implemented in an FPGA as well (possibly as block RAM) on the same chip as the CPU or separate if necessary. Maybe this will prove to be impossible but I don't think so.

I/O controllers are FPGA as well (again preferably on-chip but OK if not due to insufficient LUTs or GPIO). Major controllers I anticipate needed are for keyboard, display, storage, network and power management.

The keyboard controller manages a matrix of keyboard keys and produces output via i2c bus.

The display controller drives a outdoor-viewable display (possibly epaper if a responsive enough display can be found, otherwise probably transflective LCD) and connects to the CPU via i3c.

The storage controller manages removable flash storage contained in pocket-sized modules and communicates with the CPU via i3c.

For networking, an ESP32 module will be used for both complexity and compliance reasons. This might be replaced by a an FPGA dedicated to communications in the future so it is on a removable board or card.

The power management controller is responsible for battery charge management, charging the battery itself and communicating with the CPU about the battery state and other power supply statistics. The power supply is a fairly straightforward (probably using an off-the-shelf chip for compliance reasons) lithium-chemistry charger supporting both USB-C and MPPT DC input (allowing the machine to easily be charged via solar, hand-crank, etc.).

The hardware is rounded-out by a handful of standard physical connectors (USB-C for power, 1/8" headphone jack, etc.) in addition to a specialized BeBox-inspired "GeekPort" which is essentially a number of GPIO's pulled from the CPU's FPGA with protection and isolation circuitry. Being nothing more than FPGA pins this connector could be used for just about anything.

On the software side I'm leaning toward a fully custom implementation of the Swyft environment written in Forth, running on a custom CPU designed for this purpose. However, to expedite things there's two other options:

1. Run a modified version of the Cat software on a 68k FPGA core

2. Run the ROM code from the SwyftCard on a FPGA implementation of the Apple //e

I think the hardware described is capable of all three options so if desired a phased approach could be taken where the original Swyft software could be used until a new implementation is ready. In fact, this would allow the new implementation to be built using one of the existing implementations. Using one of the existing implementations would require some hacking to make the old code work with the new hardware, but the FPGA-based design provides a lot of flexibility to customize how the hardware appears to the software that wouldn't be an option in a more traditionally-designed system.

In a perfect world, the code that is used to synthesize the FPGAs themselves would be written and used from within the Swyft environment, making the machine self-hosting to a level that few (if any) computers have been so far.

Jason J. Gullickson, 2026

Downlink 2026-04-30

Thu, 30 Apr 2026 07:52:27 -0500

I'm a couple weeks behind on Downlinks so I decided to catch-up on this last day of the month...

* https://archive.org/details/musopen-lossless-dvd

* https://musopen.org/music/2571-symphony-no-9-in-d-minor-op-125/

* https://gist.github.com/kerma/c52e93eef3b3e50d7237

* https://www.howtogeek.com/how-to-bulk-convert-audio-files-in-the-linux-terminal/

* https://linuxize.com/post/how-to-find-files-in-linux-using-the-command-line/

* https://www.lego.com/en-us/product/nasa-artemis-space-launch-system-10341

* https://www.nasa.gov/blogs/missions/2026/04/05/artemis-ii-flight-day-5-crew-demos-suits-readies-for-lunar-flyby/

* https://en.wikipedia.org/wiki/Opcode

* https://www.fredscave.com/40-micropython-looping-for.html#micropython-range-function

* https://techtutorialsx.wordpress.com/2017/09/29/esp32-esp8266-micropython-string-split-method/

* https://www.fredscave.com/23-micropython-data-types-dictionary.html

* https://www.ebay.com/sch/i.html?_nkw=5.25%20cleaning%20disk&_sacat=0

* https://asciiexpress.net/diskserver/

* https://www.crowdsupply.com/krakenrf/discovery-dish

* https://en.wikipedia.org/wiki/Apollo_13

* https://libcsp.github.io/libcsp/basic.html

* https://www.smithsonianmag.com/history/real-story-football-follows-president-everywhere-180952779/

* https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-and-highlighting-code-blocks

* https://concretedog.blogspot.com/2026/04/xteink-x4-with-open-source-firmware.html

* https://learn.adafruit.com/circuitpython-on-the-xteink-x4-ereader/back-up-the-firmware

* https://github.com/sunwoods/Xteink-X4

* https://docs.circuitpython.org/projects/xteink_x4/en/latest/

* https://github.com/open-x4-epaper/community-sdk

* https://platformio.org/

* https://tinkeriot.com/esp32-variant-guide-c3-c5-s2-s3/

* https://www.adafruit.com/

* https://www.amazon.com/XTEINK-Page-Turn-Ultra-Thin-Magnetic-Ready-Distraction-Free/dp/B0GR4BCJK3

* https://www.waveshare.com/catalogsearch/result/?q=epaper+development+board

* https://www.waveshare.com/esp32-s3-epaper-3.97.htm?sku=33552

* https://docs.waveshare.com/ESP32-S3-ePaper-3.97/Resources-And-Documents

* https://www.amazon.com/s?k=db9%20to%20db25

* https://github.com/waveshareteam/ESP32-S3-ePaper-3.97

* https://www.repaircafe.org/en/join/start-your-own/

* https://www.willegal.net/appleii/appleii-first_page.htm

* https://www.willegal.net/blog/?page_id=2

* https://en.wikipedia.org/wiki/SCELBI

* https://www.xteink.com/products/xteink-x4

* https://www.tindie.com/search/?q=apple+ii&p=1

* https://codeberg.org/jjg/preposter.us/commit/613817320e719dc9c30faf1041f090085ebd4922

* https://eli.li/the-seed-beneath-the-snow

* https://www.applefritter.com/content/iie-keyboard-help

* https://www.applefritter.com/content/cleaning-apple-e-case-what-solution-would-you-recommend

* https://www.applefritter.com/content/what-are-your-methods-cleaning-your-apple-ii-inside-outside

* https://techcrunch.com/2026/04/13/thousands-of-rare-concert-recordings-are-landing-on-the-internet-archive-listen-now/

* https://archive.org/details/aadamjacobs

* https://www.applefritter.com/search/node/keyboard%20dishwasher

* https://www.applefritter.com/content/nonworking-apple-iie-help

* https://www.applefritter.com/content/basic-page-keyboardswitches-and-keyboard-topics

* http://www.willegal.net/appleii/early-a2-keyboards.htm

* https://en.wikipedia.org/wiki/EPUB#History

* https://realpython.com/intro-to-pyenv/

* https://www.iso.org/standard/53255.html

* https://www.baeldung.com/linux/python-multiple-versions#bd-2-virtual-environments-with-tools-from-the-standard-library

* https://docs.python.org/3/library/venv.html#creating-virtual-environments

* https://www.applefritter.com/aup

* https://www.urbandictionary.com/define.php?term=Carerist

* https://docs.python.org/3/library/venv.html

* https://learn.adafruit.com/circuitpython-on-the-xteink-x4-ereader/setting-up-web-workflow

* https://learn.adafruit.com/magtag-weather/project-code-2

* https://open-meteo.com/

* https://docs.circuitpython.org/en/latest/shared-bindings/wifi/index.html#module-wifi

* https://docs.circuitpython.org/en/latest/shared-bindings/terminalio/index.html

* https://docs.circuitpython.org/en/latest/shared-bindings/displayio/index.html#module-displayio

* https://learn.adafruit.com/circuitpython-display-support-using-displayio/epaperdisplay

* https://learn.adafruit.com/welcome-to-circuitpython/interacting-with-the-serial-console

* https://www.linuxquestions.org/questions/linux-desktop-74/usb-is-not-a-mtp-device-4175463715/?__cf_chl_tk=l9FTK.8K0jHgwHigJ6myVHUgUbPrj0h8IuDln0N2Bk4-1776362653-1.0.1.1-C05MjHsvs1NwzmDewWIwk.CA.83LznKPBs66Voj7mkg

* https://concretedog.blogspot.com/2026/04/xteink-x4-with-open-source-firmware.html?m=1

* https://github.com/crosspoint-reader/crosspoint-reader

* https://github.com/crosspoint-reader/crosspoint-reader/blob/master/USER_GUIDE.md#power-on--off

* https://github.com/crosspoint-reader/crosspoint-reader/releases

* https://xteink.dve.al/

* https://github.com/crosspoint-reader/xteink-flasher/issues/4

* https://www.myminifactory.com/object/3d-print-skull-drake-hand-puppet-personal-use-690894

* https://docs.micropython.org/en/latest/zephyr/tutorial/repl.html

* https://latitude.to/map/us/united-states/cities/beaver-dam-wisconsin

* https://github.com/servo/servo/

* https://www.thatprivacyguy.com/blog/anthropic-spyware/

* https://forums.adafruit.com/viewtopic.php?p=1086785#p1086785

* https://github.com/netham45/esp32-rtp

* https://docs.micropython.org/en/latest/pyboard/tutorial/repl.html

* https://makertube.net/a/jjg/video-channels

* https://makertube.net/w/k9EzH4bnR61d45XSuB5KPF

* http://www.hanny.com.cn/

* https://forum.allaboutcircuits.com/threads/how-to-repair-a-thermoelectric-wine-cooler.176296/

* https://forum.allaboutcircuits.com/threads/success-stories-repair-thermoelectric-cooler.101748/page-3

* https://dicasdozebio.com/2013/12/01/1547/

* https://dicasdozebio.com/wp-content/uploads/2013/12/fig20-adega-primario.jpg

* https://dicasdozebio.com/wp-content/uploads/2013/12/fig21-adega-secundario.jpg

* https://www.ebay.com/sch/i.html?_nkw=pcb140411k2%20110&_sacat=0&_odkw=pcb140411k2&_osacat=0

* https://www.ebay.com/itm/316006045908?_skw=pcb140411k2%20110&itmmeta=01KQ3M2FJ6WAEMG978MNSD9X5Y&itmprp=enc%3AAQALAAAA8GfYFPkwiKCW4ZNSs2u11xB5QJH7kmdI53e1wNtL0ItIHsP39sZJNSu7GBLIsTVqKaEPW2tGlt08K1MEUVSed59TXW4MX41oDWadxAAAAv7yCxvYbwn3zDn84%2Bn17gt1oO0zYwFn1LAGzhyNGAiVnBdsB9%2BrnNdYATYkcWsG2kY0v7mA71k%2F7hzBbCBv3bjhRVt6HU1eR%2BIeyjN8T98Wn2hKWabBLy24rooHa4ewJlRHdhc%2BGz81rLyaiLs4wHLxlPDWdTwQ%2F%2B9%2FHjIbSJ9%2FCynRhGWPyETsdSRCwrBJdXtckv3ErgLlkgtecCvj7vAw9A%3D%3D%7Ctkp%3ABk9SR5T6ifS4Zw

* https://www.ebay.com/itm/405198619819?_skw=pcb140411k2%20110&itmmeta=01KQ3M2FJ675VX1TM1W5060XCZ&itmprp=enc%3AAQALAAAA8GfYFPkwiKCW4ZNSs2u11xDoCjRj6u2WE1mQXVXzpI2dsN%2BxY470Hj0q1LxgJLWO30L2YBecVOZzq3cjhOR2pnALmiTQ7tDNx6qhXZDabf1APJnzkXbiJa3o7fKiuzsfVVBb3NTgax9D6T2%2BA8lMCtj9ISpLE3rlgXWaZm%2Bg2lupukL67WUI8Bc1GclauPFm0%2BaRZzX2hECx4fXTtow4hsdwI7Fn4vVBFSI6%2B%2B%2F9M7or6GibhMWm%2Bc0R3T9qVzpLTQ7IS0dC6IHCBlEGOzg%2FV9GoX71y%2BUSMGSnaJkRemaLXoCUUV4BfZPYwaG3E1RU7sA%3D%3D%7Ctkp%3ABFBMlPqJ9Lhn

* https://www.ebay.com/itm/405660205555?_skw=pcb140411k2%20110&itmmeta=01KQ3M2FJ6PMT4R8AKPN3DTGEK&itmprp=enc%3AAQALAAAA8GfYFPkwiKCW4ZNSs2u11xCa2aJLPN3ecS0bf2IoNuPgoFi7lUnOTIZuoMpggOQ9JrqLYgjX0xLx3wO9ZNIjfanJTj4uphLAR3XLgnYuIWjIZJk3JCv38Br0waaAiayN0mMkRqWpIja0tmRL3zywBpHfjXo3ZUKktDjdz86PI%2BOkQe0YmDICIHvtmpekFxDeoO4ZR8Ftm%2FNSxF3rGBEdoKFAei2CbkASsRHNGKBl9j4zVl1YrGVtNKKxJOgTWmXaDFUrkSvLBOLSVcARze%2FuzxWIAHpt1u742HegoK974b9%2FhufiuqGbooQYr7R9eSt--g%3D%3D%7Ctkp%3ABk9SR5T6ifS4Zw

* https://en.wikipedia.org/wiki/Thermoelectric_heat_pump

* https://ntrs.nasa.gov/api/citations/20250001849/downloads/NASA-TM-20250001849.pdf

* https://praesidiumparamedics.com/shop/kits?ss_source=sscampaigns&ss_campaign_id=69ea2d645d0ec66232be9c38&ss_campaign_name=New+Jump+Bags&ss_campaign_sent_date=2026-04-23T16%3A28%3A24Z

* https://knowyourmeme.com/memes/your-scientists-were-so-preoccupied-with-whether-or-not-they-could-they-didnt-stop-to-think-if-they-should

* https://lectronz.com/

* https://www.falvotech.com/Kestrel-2EX.html

* https://nandland.com/lesson-15-what-is-a-block-ram-bram/

* https://duckduckgo.com/?t=ffab&q=Olivetti%20M-10&ia=images&iax=images

* https://en.wikipedia.org/wiki/BeBox#GeekPort

* https://en.wikipedia.org/wiki/Jef_Raskin#Pioneering_the_information_appliance

Jason J. Gullickson, 2026

A Drug Against War

Fri, 01 May 2026 07:38:27 -0500

Happy May!

A Drug Against War

KMFDM, 1993

Lick

Sat, 2 May 2026 20:50:53 -0500

Bialetti Moka Induction Rossa

Sun, 03 May 2026 08:07:20 -0500

I dropped my Bialetti Moka Express and the handle broke-off. I thought about fixing it (and I still might), but the handle has the combined requirements of tolerating very high temperatures and also remaining cool which is something I don't know exactly how to replicate myself, so for now I decided to pick-up a new one.

I recently purchased a single-burner induction "hot plate" for both emergency use and also just to see what working with an induction stove-top would be like should we decide to go that way in the future. Since I can't imagine an emergency that wouldn't be improved with hot coffee, I decided to try giving an induction-compatible Moka pot a shot.

I was surprised by how much more expensive the 4-cup Moka Induction was from what I paid for the Moka Express, but looking at current prices for both I guess the bump to get something that works with induction isn't that severe. All of these things have gotten a lot more expensive lately...

I got red because it cost the same as the other option (black), and we all know red is faster.

The Moka Induction is unsurprisingly a lot heavier than the all-aluminum Express. This isn't all bad, it feels a lot more stable than the Express, especially on our gas range. Working-through the "seasoning" process (essentially running three rounds through the machine, one with water-only and two more with coffee)

I noticed the steel base of the induction-compatible version holds a lot more heat for a much longer time. Again not a complete surprise, but it does mean making back-to-back servings is a little trickier than just running the Express under cold water for a few seconds before you can handle it safely.

The funnel/filter is a bit different two, again a different metal than the Express, shiner and with a different shape. It also seems to hold-on to water more than the old funnel (which seems true for the rest of the coffeemaker) and requires a bit more shaking and turning-around to get all the water out of it after cleaning.

The induction version seems to take the same amount of time to make coffee as the Express, maybe a little faster (the larger boiler surface area perhaps?) but the difference, if any, is small enough that I don't notice.

What I do notice is that when pouring from the new pot a lot more steam/vapor is released toward my hand and the first time I poured a cup from it I managed to burn myself.

Hard to get a photo, but the steam leaks out the hinge-side of the lid when pouring...

Interestingly enough, the induction version has a very different handle from the Express, it feels a bit more rubbery (maybe less likely to shatter like the Express did when I dropped it?). The material and shape seem to do a worse job of remaining cool than the original, and I find I have to use a sleeve or a pot holder to pick-up and pour the thing.

I also got a chance to try the new pot with an induction cook-top (the one I mentioned earlier).

Rossa on the ~$100, 1800W induction hot-plate. I'll probably write a post about this thing in the future

I was a little concerned because I'd read that some induction stoves won't work with a small pot on a large "burner", but the plate detected the pot just fine, and with the power set to 1000W (roughly 50%, the recommended power level as per the instructions) it started boiling in about half the time it took on the gas range.

The good news is that the results (the coffee itself) are, as far as I can tell, identical to my original Moka Express. The first few cups were inconstant even after the "seasoning" process but I'm happy to say now that I'm at least ten cups in that the flavor, body, etc. are indistinguishable.

So there are some trade-offs to the induction version of the Bialetti Moka pot, and if you were sure you'd never need to make coffee on an induction cook top I would recommend sticking with the less-expensive Express. But if like me there's a chance you might need something induction-compatible the extra cost and minor inconveniences of the induction version are worth it.

Jason J. Gullickson, 2026

One Step Closer

Mon, 4 May 2026 12:51:31 -0500

Movie Cameras

Tue, 05 May 2026 07:03:02 -0500

I've worked with a few digital video cameras over the years, and for whatever reason I don't like making movies with cameras that don't feel designed for the job.

During the DV "revolution" of the 2000's there were many pro-sumer-to-pro cameras that were like grown-up camcorders with some of the trappings of professional video cameras. These cameras were excellent for indie filmmaking, the most well-known being the DVX-100.

Today the standard is DSLR still cameras with video capability. They can get some great shots, but I don't like working with them. The ergonomics don't fit the way I like to shoot, the controls are aligned with my still-shooting muscle memory and for whatever reason I just have a hard time getting good shots with them. I know there's all sorts of accessories that are supposed to address this but it seems like a better solution is to start with a better design in the first place.

If you travel up the price scale a bit ($10k+) you can get into some cameras that are closer to what I'm talking about, but to kit them out into a complete setup you could take in the field you get start sailing well over that $10k mark and for lots of reasons (including fear of breaking it) I'm not ready to go there.

Many years back I took a trip in the opposite directly and started experimenting with Super-8 film. Shooting on film is a completely different thing, and I really enjoyed it, but again the cost, when you count the film, lab, transfer, etc. is beyond what I'm going to budget for a feature project.

But I really liked the "feel" of shooting with film. The cameras I picked-up (one from a thrift store, another borrowed from a friend) are high-quality units with nice glass and feel as solid in the hand as a firearm. When you pull the trigger you feel it, not just a little "beep", and when it's shooting there is physical, tactile feedback that you are doing something.

So I started experimenting with combining the cost-effectiveness of digital video with the experience of shooting Super-8 film and designed a 3D-printable Super-8 cartridge to house enough electronics to replace the regular film.

I seem to have misplaced all the photos and videos I made with the DV8 project at the time, but luckily I still have the CAD files.

I had some initial success using a Raspberry Pi Zero and it's camera module (one of the first such modules) but there was a lot left to be desired. I really wanted the film cartridge to work with the camera in all the same ways as the real thing, including things like variable frame rate. At the time I didn't know enough about controlling the camera module to even begin to do something like this, and since it required interfacing with tiny parts of the camera (the little pawl or hook that advances the film) it felt out-of-reach for my mechanical engineering capabilities at the time as well.

Since then I've thought about the project occasionally, usually when I'm shooting with the DSLR. I've seen a few other people try to use Super-8 cameras for video, and they are really cool, but I haven't seen one that prioritizes getting the details like the shutter, aperture, etc. right.

Because of this, I'm considering reviving my DV8 project. I have an idea for a mechanism that not only solves the frame rate interface but would also solve a focus problem I ran into in a way that I think will produce a very "filmic" look as well. It's more complicated than what I've done before, but I've learned a lot since my last attempt almost ten years ago. Knowing that I'm not the only person who things this is an interesting idea helps as well, because it's a lot easier to get and stay motivated when someone else might make use of what you're making. Finally, there's a lot more to choose from on the electronics side now when it comes to digital camera hardware, etc.

Jason J. Gullickson, 2026

Artificial

Wed, 06 May 2026 07:24:06 -0500

Why would you choose something artificial over something natural?

I don't know how others would answer this question so I have to guess. When I think about artificial ingredients, the primary reason for choosing them over the real thing is probably cost, followed by (in no particular order) availability, handling convinience and side-effects.

"Side-effects" here hides a lot but one example is artificial sweeteners. An artificial sweetener might be selected over a natural sweetener like sugar to reduce the amount of calories in a food. Another would be artificial ingredient like Olestra which replace natural fats.

I've been very frustrated with the use of the term "Artificial Intelligence" by the AI Industry because what they are selling has nothing in common with natural intelligence (or simply "intellegence" as you don't need to qualify a word when you're talking about the real thing). But for whatever reason I was focusing on the "intelligence" part and not the "artificial" part.

When considered in the context of how the word "artificial" is used elsewhere, the phrase "artificial intelligence" really does describe the products of the AI Industry. Like an artificial sweetener, it can trick a person into thinking they are tasting real sugar when what they are really consuming acesulfame potassium. Like Olestra, a person using AI feels like they are consuming the thing it replaces, but the result in both cases is something less desirable.

But I think the more important question is "why". A person choosing to consume a product with an artificial ingredient because that artificial ingredient is better for them than the real thing is an act of choice and personal agency, but when people are coerced into consuming artificial ingredients, either by obscuring their presence or by making the real thing unavailable, that's another matter. That is no choice at all.

I think in most cases we use and consume artificial things because of choices others have made. The choice to replace something natural with something artificial because it was more profitable to do so. This could be a direct reduction of cost, or a reduction of operational costs (simplified manufacturing, etc.) or a reduction of loss (artificial things tend to stay "fresh" longer) but they are all permutations of increasing profit.

Turning this lens on the AI Industry, I think it's obvious why so many CEOs are jumping on the AI Industry's bandwagon. For them, or perhaps for their bosses and bosses bosses, AI is a way to replace natural intelligence with something cheaper, and they have so little respect for their customers that they don't think it will make a difference. They also have so little respect for their source of natural intelligence that they are excited about replacing them with something artificial, based on (unproven) promises that it will increase profits.

So the term "artificial intelligence" is perfect for what the AI Industry produces: a cheap substitute for the real thing whose primary value is the promise of increased profit and whose output is inferior at best and produces unwanted-to-dangerous side-effects in the people who use and consume it.

There have been many times in the past where a new artificial ingredient was celebrated as a revolutionary achievement, only to fail to achieve what it's creators claimed it would. When you think about what artificial things are and why they exist, this outcome is no surprise. The people incapable of observing this pattern are those who are blinded by their desire for what the makers of artificial things promise.

With this understanding I no longer hesitate and in fact embrace the use of the phrase "artificial intelligence" for the products of the AI Industry. Their claims of it being the same or better than the real thing are just as absurd as they were before, but I now see how this phrase perfectly describes this absurdity, and I hope others will too.

Jason J. Gullickson, 2026

First Furniture

Thu, 7 May 2026 16:28:05 -0500

Downlink 2026-05-08

Fri, 08 May 2026 06:27:39 -0500

* https://en.wikipedia.org/wiki/History_of_water_supply_and_sanitation

* https://en.wikipedia.org/wiki/Cloaca_Maxima

* https://spectrum.ieee.org/the-italian-computer-olivettis-elea-9003-was-a-study-in-elegant-ergonomic-design

* https://www.nytimes.com/2013/02/11/arts/design/olivettis-artful-breakthroughs.html

* https://spectrum.ieee.org/when-the-history-of-computing-comes-alive

* https://spectrum.ieee.org/the-silicon-dioxide-solution

* https://www.moma.org/calendar/exhibitions/2741?

* https://en.wikipedia.org/wiki/Olivetti_Elea

* https://en.wikipedia.org/wiki/Adriano_Olivetti#From_the_Post-World_War_I_period_to_the_years_of_Fascist_consensus

* https://en.wikipedia.org/wiki/Altiero_Spinelli

* https://en.wikipedia.org/wiki/Community_Movement

* https://mntre.com/media/reform_md/2026-01-31-dec-jan-update.html

* https://www.crowdsupply.com/mnt/mnt-reform-next#products

* https://shop.mntre.com/products/mnt-pocket-reform

* https://en.wikipedia.org/wiki/Super_8_film

* https://github.com/DarkZeros/LightInk

* https://www.mayoclinic.org/healthy-lifestyle/nutrition-and-healthy-eating/in-depth/artificial-sweeteners/art-20046936

* https://en.wikipedia.org/wiki/Acesulfame_potassium

* https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Conditional_and_Iterator_Functions

* https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Text

* https://www.xda-developers.com/i-tried-multi-color-3d-printing-with-the-ams-like-canvas-module/

* https://openelab.io/blogs/learn/difference-between-elegoo-centauri-carbon-and-elegoo-centauri-carbon-2

* https://learn.adafruit.com/micropython-hardware-sd-cards/circuitpython

* https://docs.circuitpython.org/en/latest/shared-bindings/sdcardio/index.html

* https://docs.circuitpython.org/en/latest/shared-bindings/busio/index.html#busio.SPI

* https://learn.adafruit.com/circuitpython-on-the-xteink-x4-ereader/pinouts

* https://docs.circuitpython.org/projects/xteink_x4/en/latest/api.html#implementation-notes

* https://learn.adafruit.com/circuitpython-basics-i2c-and-spi/spi-devices

* https://github.com/adafruit/circuitpython/issues/10419

* https://github.com/adafruit/Adafruit_Learning_System_Guides/pull/3061

* https://www.luisllamas.es/en/micropython-cheatsheet/

* https://learn.adafruit.com/micropython-hardware-sd-cards/hardware

Jason J. Gullickson, 2026

Maybe I'm over-thinking this?

Sun, 10 May 2026 06:29:11 -0500

Maybe it's as simple as taking a single FPGA and connecting it to the desired peripherals? No controllers, no interfaces, nothing. Connect the GPIO of the chip directly to the keyboard matrix, directly to the display bus, directly to the SD card, the headphone jack, etc.

Take for example the upcoming TinyFPGA EX. It has over 50 usable GPIO's. That's plenty to drive a keyboard, any number of displays, SPI, i2c, etc. devices. It makes me wonder how far you could take it, maybe even the power management bus?

The point is maybe you can just build a whole damn computer out of a single piece of dynamic logic. It might not be the fastest or easiest way, and some would say it's not the smartest way, but a lot of people said the same thing about building a general-purpose computer out of a calculator chip and that turned out to be worth a shot anyway.

A computer built this way could become any kind of computer. It could be a recreation of a historical machine or something completely new, and it can all be done by writing code.

It's true that such a machine built around the TinyFPGA EX and it's Lattice ECP5 chip isn't going to rival a machine with the latest Intel or AMD CPU at running things like Windows or Linux, but as for myself (and I think a growing number of others) the time has come to explore alternatives to those over complicated systems with their endless hunger for hardware, continuous stream of security breaches and deliberate incursions into personal privacy.

A computer that can be synthesized from scratch, where it's possible to know exactly what it's doing, made out of simple parts that anyone with the desire can learn to understand would be a radical departure from what we have available today.

If I can carve-out a little time this summer I'm going to try to piece something like this together out of the parts I have on-hand. With any luck I'll know what I'm doing by the time the EX ships in the fall and I can produce a standard machine around that board. If there's any interest shown by others along the way, maybe I'll get a kit ready in time for Xmas...

Jason J. Gullickson, 2026

Non-verbal Processing

Mon, 11 May 2026 07:09:17 -0500

At first I thought that so much of the new computer company has little to do with computers, and I suppose that's technically true, but what it has a lot to do with is people, and that's really what the computer is about. So in a roundabout way, it's all about the computer because it's all about people.

The things I've been thinking about over the last couple of days are the ways to make the company viable, and the crux of that is finding ways to put them into the hands of the people who can use them most. It's an odd machine, because the two groups of people who come to mind are people who want a reliable tool and people who want to tweak endlessly. I thought this was a dichotomy, and maybe a sign that I was on the wrong track, but then I realized that this perfectly describe *me*. While I may be a human dichotomy, this realization alleviated any fears I had that the machine I have in mind is too unfocused to meet the needs of at least one group of people, and I think that maybe it could reach both; but how to communicate that?

I do have a fair amount of connections in the hacker/maker/hobbyists communities and when I've talked about the *implementation* of such a machine this is where most of the interest lies. I can think of ways to engage these communities and find individuals who might be interested in such a machine, and in many ways it's the perfect group to share a new computer with. They are open-minded, creative, have the background to understand what is novel and exciting about the design and are in general more tolerant of the inevitable "growing pains" that are part of a new thing.

The other group might be a little harder for me to reach. My experience over the last month or so of working daily with the SwyftCard-equipped Apple //e has really driven-home for me how a simple, reliable machine can make working with a computer a joy again. While it might appear crude superficially, and there is a learning curve to making use of it when you're coming from contemporary machines the beauty of it becomes quickly apparent after spending only a few days with it, and after a week I didn't want to ever give it up.

I believe the computer I'm designing can achieve both of these things, but what I'm struggling with is how to demonstrate this to these two very different groups of people. There I go making that same mistake again; it's not necessarily two different groups (remember, I'm both), but it's two distinct ...perspectives?

When I'm using the //e as a tool, I want to turn it on and work. I don't care about how flexible or dynamic or simple or whatever about the hardware, the firmware, or even the software, I just want to sit down and start typing. In this "mode" (for lack of a better term) I don't mind learning something new if it will be directly applicable to what I'm working on, but I don't want that to take so long that I loose my groove, and I especially don't want to get side-traced or distracted in the process. While the SwyftCard can do a bunch of things that I've not yet committed to muscle memory, when I decide I need something new I grab the manual (a PDF, but ideally it would be a printed hard-copy) and look it up. This makes the manual, and it's indexing critical to preserving my flow, because if I had to use some web site or search engine or otherwise engage with my "regular" computer, all that dramatically increases the chances that I'll get off-task and loose the momentum I need to do the work I set out to do in the first place.

That first-hand experience, more than anything else leading-up to it (researching the SwyftCard, reading the documentation, reviews, discussing it with others online, etc.) is what really drove home the power of using it. I spend decades not deciding to assemble a machine to use it because none of that stuff provided enough motivation to spend the time and money necessary to make it happen, and it took a complete collapse of the world around the computers I depend on to push me over that line.

I don't want it to take that long or cost that much for people to buy one of my computers.

So maybe the takeaway from all this is that I probably won't have to worry as much about reaching the hackers, since they (like I) are likely to do the work to get what they want out of something like this because we are excited and motivated to study something indirectly. No doubt we want to get it into our hot little hands and take it apart but I think we can also get over that acquisition hump by learning about something before we have direct experience with it. To put it another way, what makes the machine I'm designing exciting to the hackers can be communicated more easily (or at least it's easier for me to understand how to communicate it).

But what makes this machine compelling to the other side of me, the side that wants a computer that is a tool I can trust is the experience of it. To reach people looking for this, I'm just now realizing, is using the machine to do some real work. In my case it took a lot of motivation to commit to this and I'm a little intimidated by recognizing that fact. However, this realization is already sparking new ideas about how to provide and facilitate that experience and just imagining those things is nothing short of titillating.

This learning process, the one I just experienced is one of the greatest things about writing this blog. It's a form of writing that for me sits in a sweet spot between my internal dialog and publishing polished work. The process of it, the experience allows me to work a problem in a way that the other two methods don't, and as shown above it makes it possible for me to solve problems that would otherwise be intractable. If I can make a tool that helps others experience such joy, I'll have achieved success.

Jason J. Gullickson, 2026

Micro(computer)agressions

Tue, 12 May 2026 07:31:01 -0500

I was going to write about something much more interesting but then my screen went blank. It went blank right after I opened the Preferences dialog of the Markdown editor I use to write these posts. I open the Preferences dialog every time I start the editor because I have to toggle the "Large Type" switch of and on again because when I open the editor the type is microscopic even though the Preferences toggle for Large Type is enabled. When I disable it, the type gets somewhat larger and then when I re-enable it the type regains its full size.

The reason I use the editor is because my mail client stopped having spellcheck. It used to underline misspelled words, but then one day it didn't. I tried to find the history of the various upgrades that were applied to see where it went away but I was unable. I tried to file a bug with the team who writes the mail client, but I couldn't because I wasn't logged-into Github.

I tried to log into Github, but I couldn't because something had changed since the last time I used it. I stopped using Github for my personal work completely when they started using my work to destroy people like me and well, the entire world really and inbetween now and then something changed and I can't log-in.

I tried using a different mail client, but I couldn't because the only one I could find that was compatible with the various layers of software that make-up my laptop's operating system are not quite compatible with any except one. That one won't work with my email server for reasons I can't divine.

Because of that, I'm writing this post instead of one about new ideas I have about human-computer interfaces, but I suppose that is what this is about as well. Every day I work with this computer, and the computer I use for work, and the computer that I call a phone, and pretty much every other computer I work with on a daily basis is a story like this, and often many stories like this. Tiny bits of drag slowing down or stopping the work I'm trying to do. I can't compute the cost of this over the course of a lifetime, but what I can say is that as I get older the cost gets higher. The amount of time I have between when an idea solidifies in my imagination and when it returns to the mist grows shorter every day. Even ounces of additional drag now reduce my thoughts to dust.

If the Jobsian ideal of a personal computer is a "bicycle for the mind", what would you call what has become of them today? I can't think of a perfect metaphor but at the moment a wood chipper comes to mind.

But there is hope (remember, no total bummer posts this year).

The SwyftCard-equipped Apple //e I've been using the last month exhibits none of these drag-inducing behaviors. It is the fastest, most reliable and lowest-drag computing tool I use by far and possibly as far as I can remember. It is ancient by technology standards and is far from "restored", yet it works more reliably than the $1200 new-last year laptop I'm writing this on. It's also faster, ready to work within five seconds of power-on (my laptop can't even wake-up from sleep and unlock that fast). It is ready to work as soon as I am and has no problem keeping-up with me.

If I can help others perceve this sort of drag that their computers put on their work, and how the computer I'm building can eliminate it, I don't think I'll have any trouble making a living at making them.

So why am I not using it right now? That's a fair question and the answer is fairly simple: I haven't connected it to the outside world yet. I'd like to say I have some lofty reason for this but it's really simply a matter of getting my hands on the right cables. You see, I thought about making a cable but then thought I'd try to be more "practical" and order one...

Jason J. Gullickson, 2026

(as if to have the last laugh, when I went to copy-and-paste this text from the Markdown editor into my email client, CTRL-A stopped working to select-all...)

Putting the Cyber in the Cyberdeck

Wed, 13 May 2026 07:26:33 -0500

Don't get me wrong, I think the custom computers that are referred to as "cyberdecks" are cool, and I've even built some myself, but I've always been irked by the use of that term to refer to machines that have a regular indirect human-computer interface in the form of a keyboard, screen, etc.

My first exposure to that word came from reading Gibson, and in Gibsons work there is a very clear line between "terminals" (regular computers) and "cyberdecks" and that is that a cyberdeck connects directly to the brain.

Maybe these custom computers should be called "cybredecks". I don't know the actual definition of "cybre", but my first exposure to the word (misspelling?) was in the fediverse and it was used in reference to things with the cyberpunk aesthetic.

So when I see a cool custom, often hand-made computer without a neural interface I involuntarily roll my eyes a little.

But what would it take to do it right? I know what you're thinking, you're thinking "well Jason, not everyone is going to drill a hole in their head or even attach electrodes to it like you did when you were 13 to try to control their computer with their mind...", but maybe they should.

There's been a fair amount of invasive work in this area since the mid-to-late 1900's but most of it involves surgery. That was a line I've never really crossed because honestly it's messy and complicated if you don't have access to the right tools, facilities and staff. It's also largely irreversible which is something I try to avoid. But since my early experiments I've learned a lot and I think there's some non-invasive ways to make such a thing, some of which I'm not sure have been tried yet.

A neural interface has an input and an output component like most any computer interface. To keep things straight I'm going to refer to I/O from the computer's perspective, input being the control signals sent to the computer from the person and output being the data sent form the computer to the person.

The input side has some well-established and easy answers. An EEG-type device uses electrodes attached to the skin to detect brainwaves that can be display and recorded (this is what I was experimenting with using my VIC-20 when I was 13). Various numbers of electrodes have been used but even just a few can produce a usable control signal as demonstrated by several games and children's toys. Most of the cost and complexity of the EEG hardware comes from the precision amplifiers needed to boost the weak signals, but all of that has become very common and inexpensive in the last decade or two. The rest of the work is in analyzing the signals but here again this is something that can now be done with commodity hardware and open-source algorithms.

The output side is where things get tricky. Traditionally feeding any sort of electrical signal *into* the brain involves surgically-implanted electrodes that stimulate the brain tissue directly. There have been sophisticated demonstrations of this, some recently but the work of literally "drawing images on the brain" goes much further back than any contemporary self-proclaimed genius wants you to know. This approach has potential but it's not something you should try at home.

However there is a non-invasive way to put a signal into the brain called transcranial magnetic stimulation (TMS). This technique uses a process similar to how an electric current can be induced in a wire without touching it using a magnetic field. A TMS device is capable of stimulating brain cells without direct contact with the brain, so this is the starting point of the output side of our cyberdeck interface.

*This is where we get into things that I don't know the research status of.*

The first thing that comes to mind is to use an array of TMS fields to "draw" on the brain similar to the invasive techniques, and perhaps something like beam-forming could be used to do this with some level of precision, but I have another idea that is both simpler and I think better.

Instead of attempting to simply paint an image on the brain what I propose is using TMS to stimulate a single point with precision in a reliable fashion. To transmit information into the brain, the information is serialized and then signaled into this single area in the same way that a single wire can be used to transmit data by encoding and decoding it on either end. This single point could use a digital or analog encoding (experimentation would be needed to determine which works best), and there is a wide-range of existing encoding techniques that could be explored.

In order for this to work the brain would need to be trained to decode a serial data stream. This might sound far-fetched but most of us do this all the time in the form of reading written language. *Writing is a very low-fidelity encoding of one person's thoughts into a stream of characters that is then deserialized and decoded by another persons brain.* If our brains are capable of learning to do this using a visual data channel, I don't see why they couldn't do the same using a TMS-induced signal which essentially creates a new sensory channel.

It would take training to learn how to use this new "sense", and it might take a long time (how long does it take an illiterate adult to learn to read?), but I don't see any reason to believe that it's impossible, and if it could be done, it would make a non-invasive direct neural interface not only possible, it could be produced inexpensively and used by virtually anyone.

Aside from being the right interface for a cyberdeck, such a device could also be the most accessible computer interface ever made, since it would allow working with a computer regardless of other sensory impairments.

There are of course risks involved in developing such a device even if it doesn't involve surgery and I would have to think about it more and do more research to devise a plan for conducting the experiments to develop it in as safe a way as possible. It's also possible that there's something I don't know about that would invalidate the approach altogether. But given the potential, I think it's worth throwing some brainpower at.

Plus, then I could submit a cyberdeck project to Hackaday without cringing.

Jason J. Gullickson, 2026

Getting there from here

Thu, 14 May 2026 06:29:42 -0500

I feel like I write about this a lot, but maybe because it's something I'm always doing?

The last two days I've opened my (regrettable) Framework laptop, log-in and about five seconds after starting to work the screen goes black and I have to close the lid, count to ten and then open it and log-in again. I haven't even bothered to look into it because it's just another in a long list of papercuts that come with working with a modern computer.

I've been talking about a replacement for the modern computer, sort of hinting at it in increasing levels of detail and while I don't have the entire thing figured-out, I know where I'm going.

But the distance between my shitty Framework/Linux laptop and the computer I want to share with the world is real. Some days it feels close and some days it feels miles away.

I could cut some corners and possibly shorten that distance, but I've learned over and over the hard way that shortcuts don't get you where you're going and most of the time they lead you right back to where you started.

So what are some steps I can take to make real progress toward there?

I could start by making a list. The wondering prose and sketches I've been creating are good and should continue, but something concrete like a list would not only organize my thoughts but also provide some evidence that I've made real progress.

On that list might be simulation. I seem to remember my friend Vertigo mentioning that using a simulation of the hardware design he's working on accelerated his work on the software because a simulation can function as the ideal form of the hardware until you can get the hardware right. Aside from stability this allows for testing that would be much harder on real hardware and helps define what the final specs for the hardware should be. A simulator also makes it easier to work on the hardware and the software in parallel.

To that point (parallelism) I should really find some other people to work with. Most of my life I've not so much actively avoided this as I have gravitated toward work that doesn't seem to require it. It's really more about me than it is about others, but it's also about the work. While there are things about a project like this that I'm flexible about and would welcome the help of others skilled in the areas that I am not, there are other parts where I've spent years or decades cultivating what I think is best and when I work alone I don't have to defend or justify inflexibility in these areas. Saying it out loud, it sounds bad, but it's literally that I've thought very hard about these things and spent years experiencing them and I only have so much energy, I want to focus it on realizing the promise of that work and experience and not arguing about it. This makes it hard to collaborate without being a tyrant, and I refuse to do that.

But the fact is that if I'm going to do this, if I'm going to turn these ideas into a way to make a living I'm going to have to get help, which means getting-over this ...well let's call it what is is: *fear*. If what I'm proposing is as good as I say it is then the quality of the ideas it's based on must be observable by others. When I was writing the other day about how to reach an audience for the machine (I can't remember if I blogged that or just wrote it in my journal?) those same techniques or processes should apply to assembling a team to make the machine as well, right? The nut of that idea was to facilitate giving people a chance to experience what it's like to work with a machine like this, which is the same thing that cemented it for me.

I haven't used this future machine yet, but I've worked with pieces of hardware and software that have inspired the design of the new machine, and the daily use of these things convinced me that they were the right way to go. If I can find a way to share this experience with others, and if it resonates with them as well, I probably don't need to worry about explaining it. In fact having gone through the experience the team would have their own internal compass for staying on that path, no coercion required.

That's a much more anarchist way to approach such an endeavor, and just writing it takes a lot of weight off my shoulders.

Looks like I have some specific work to do, and at least one thing I can finish today.

Jason J. Gullickson, 2026

Pump it

Sat, 16 May 2026 17:10:09 -0500

Shop time

Sun, 17 May 2026 17:10:34 -0500

The Public Library

Mon, 18 May 2026 07:48:34 -0500

I've decided that the most important thing I can work on to bring the new computer to life is a piece of software called the Public Library (PL). In the world of the new computer, information is exchanged in the form of Books (these take the place of floppy disks in Swyft machines) and the PL is a place where Books can be published and shared with others.

Now that I'm using the SwyftCard-equipped Apple //e for a significant portion of my writing, I need a way to exchange that work with my other computers so I can continue working when I'm not at the desk where the //e lives. Building the Public Library will close that gap.

For this initial version it will be quite simple: A HNSI with the option to search, list, publish and check-out books. For now, Books are raw text so they can be stored in regular text files with file names based on their titles, with spaces replaced with hyphens.

In the new computer, the Public Library will complement a Private Library which is where non-shared Books live, stored on a local device. This makes it very easy to know what work is public and what work is private. On a Swyft device, floppy disks serve the same role as the Private Library and the Public Library is interacted with using the SEND command. This requires a modem-like device connected to the serial port that allows the machine to "dial-into" the Public Library (such devices already exist, but I'll probably make my own since I have all the parts). Books ("Texts" in Swyft vernacular) are published by adding the dialing and HNSL commands for publishing to the top of a Text, highlighting it and using the SEND command. Similarly, Books are checked-out into an empty Text by dialing the Public Library using the SEND command, searching or browsing using the HNSI and optionally saving the downloaded Book as a new Text to a floppy.

On "regular" computers, the Public Library can be accessed via any telnet-like client and Books are downloaded and uploaded to and from text files on the local filesystem. I'm not sure if it makes sense to write a specialized client for this or if an existing tool will be sufficient (I need to experiment with transferring files using telnet or something similar).

I'm planning to write at least this initial version of the Public Library in Python, specifically MicroPython. The primary reason for this is that I don't expect it to be complex and it's very likely that the "modem" I make for the //e will run MicroPython as well, so I could theoretically edit, test and debug the code on the //e if I want to.

I'm trying to avoid MicroPython now that I've learned that the project has been infected with AI, which is why this is only temporary, but right now I don't have a better option. Worst-case scenario this will be re-written in whatever becomes the base language for the new computer once that is implemented.

Future versions of the Public Library will be a little more complex, but I do want to keep it as simple as possible, especially the interface. There will be a need for consistent metadata to keep track of authors, genres, etc. and I'm hoping to avoid any sort of traditional "authentication" by leveraging this metadata but for now none of this is necessary for me to share Books with other trusted people so that's a future Jason problem.

Oh one more thing: I'm referring to the new computer as "The Beaver" for now. More on that later as well.

Jason J. Gullickson, 2026

Back on the chain gang

Mon, 18 May 2026 18:34:54 -0500

The Public Library Part II

Thu, 21 May 2026 07:51:54 -0500

Over the last few days I've had a few minutes here-and-there to work on the Public Library and I have to say, I'm really happy with how it's going.

In total I've probably spent an hour to an hour and a half working on it, and it's already at a point where it can do the essentials: publish a book, checkout a book and list the books in the Library.

I started writing this using the same pattern as the Pouch tools with deliberate attention to creating a HNSI. As a result I was able to quickly iterate through implementing the essential functions and shoring-up the interface before getting the complication of networking involved. Once I had something that worked in a local terminal, I was able to add network support and focus on that specific task knowing that the primary functionality was solid.

I'm really happy with the simplicity of the tools I've written this way so I had some apprehension about getting networking involved. I've written countless network services before but they were almost always built with the networking implementation first and often built on top of networking-specific libraries, frameworks, etc. In this case networking came after implementing and testing the actual functionality and I was worried that adding network code would make a mess of things.

So I took an approach that simply replaced the existing input/output functions I was using to communicate with the local terminal (print() and input()) with network-aware alternatives (net_print() and net_input()). I wrote these functions in a separate program so I could work out the kinks before bringing them into the working Public Library code.

From there it was a simple matter of replacing print() with net_print() and input() with net_input() anywhere I wanted the I/O to go to the network (essentially anywhere other than local debugging output).

As a result I was able to quickly turn a local console tool into a network tool.

At this point the PL works over the network and I can access it from a regular computer using a telnet client. The next step will be to get the //e connected to the network and try interacting with the Public Library using the SwyftCard's SEND command. I've ordered yet another serial cable for this so with any luck it will be the right one and maybe I'll have time this weekend to give that a shot.

Jason J. Gullickson, 2026

Experimenting with the $150 Harbor Freight Solar Kit

Sun, 24 May 2026 11:56:36 -0500

Just playing-around with a cheap-ish solar kit from Harbor Freight. I put two of these on my father-in-law's hunting cabin ages ago and with an i expensive German charge controller (the included unit was not great back then) it served us for years of deer seasons.

The current kit comes with a controller that seems more usable.

You need to have a battery attached to see anything happen on the controller so I grabbed this battery the Outback killed to see if it was good enough; it's good enough.

It will be interesting to see if it can still hold a charge...

The point of this is to see how the array performs under less than ideal conditions, including shadows and other inclusions. So far it's doing fine.

I'm planning to mount these on the upstairs balcony railing, inspired by an article I read about German apartment dwellers deploying solar on their balconies.

Jason J. Gullickson, 2026

Sidequests

Mon, 25 May 2026 07:21:10 -0500

I can't decide if it's good or bad that it's really hard for me to focus on one thing and see it through. For example, I really want to work on The Beaver, I'm really excited about it and there's a lot to do. But for whatever reason I got obsessed with 1980's Tamiya RC buggies the other day and I spent a couple hours yesterday researching suspension systems and designing my own printable buggy.

I feel like if I could stay focused on one thing I could get it done faster, but on the other hand I feel like my brain knows what it's doing, and maybe it sends me on these "side-quests" for a good reason.

In some cases I learn things on the side-quests that I need for the main quest. Other times getting distracted seems to help me get unstuck, or find a way around a problem that I couldn't see when I was completely focused on it.

Other times, like yesterday, don't feel particularly valuable at all.

I could try to apply some discipline to these moments of distraction, and I have done so in the past. There's plenty of other things in life, and a case could be made that The Beaver itself is a side-quest, so deciding what the main quest is and ignoring everything else is not as straightforward as it might seem.

For a long time I've been using the feeling of Joy as a compass, and as it gets harder and harder to know what will be important in the future, Joy seems more and more like the wind to follow.

So I guess it's OK that I want to design and build an RC buggy, even if I don't do it.

Jason J. Gullickson, 2026

MVP

Mon, 25 May 2026 07:58:27 -0500

We used to talk about the "minimum-viable-product" or MVP back in the 2000's. I'm not sure where the term comes from (maybe the Agile manifesto?) but the idea is, what is the least you can build to have something that does whatever you're trying to do.

I'd further qualify that it has to be truly useful to the person you're making it for (even if that's yourself). That's important for the "product" part, IMHO.

Like many useful heuristics I've seen the term abused as a way to do a half-assed job, but I do think that it's useful as a test or metric, or a way to get yourself un-stuck.

I'm thinking about the MVP of The Beaver this morning and how I can "scope" the project in a way that it feels more tractable. Something I'm coming to terms with is that if I'm going to make a commercial venture out of the thing I'm going to need help from other people, but it's very tempting to hold-off on that until I have some kind of prototype that they can use to get a taste of the experience. I've written before about why I think that's important.

I suppose that was what the SwyftCard was about, a way to give people a taste of what a complete Swyft computer would feel like using a single printed circuit board compatible with the millions of Apple //e's already out there. Taking that as a clue the first thought that comes to mind is to focus on creating the software side of The Beaver, and an emulator that would allow it to be used on an existing, common computer. Taken to the extreme, it would be delivered via web browser, resulting in virtually universal compatibility.

But how much of The Beaver Experience (TBX) can be conveyed via a web browser? This is a good question because answering it requires reflection on what is most important about TBX, and when I think about that, I think about how I sold myself on the idea.

Setting-aside the hardware, what makes TBX compelling to me is flow. Working with The Beaver provides the benefits of an electronic workspace without the drag caused by contemporary computers. That drag comes in the form of interruptions, unreliability, untrainability and simply being slow computers. The Beaver lets you work, by not getting in the way but also by not trying to do your work for you. The Beaver lets you work and work-out your mind, it lets you get smarter the more you work with it. It lets you get faster, by being fully keyboard-focused and controlled by a handful of keyboard commands that you can commit to muscle memory. It keeps your work safe so you don't need to be preoccupied about loosing it. It provides the dynamism and acceleration of being programmable without requiring you to become a "programmer". It provides a way to share your work without making it impossible to understand what is public and what is private. The bottom line is that when you have time to work with The Beaver, you can get more work done and come-away from the experience healthier.

So how much of this experience could be shoehorned into something that runs in a web browser?

We can't do much about the drag. A browser runs on a computer that has all the interruptions, unreliability, untrainability and slowness we're trying to get away from. It might be possible to achieve some of this by prescribing a process to prepare the computer for the experience, but even if someone tries to configure a contemporary computer this way, there's only so much you can do. If that drag could be overcome, some of the other benefits of the experience are easier to implement, and while not using a custom keyboard will limit some of the ability to attain muscle memory for all of The Beaver's features, something close to it could be possible. Keeping work safe is not as sure as it will be on the real thing, but it could be better than the alternatives, and the dynamism of being able to write and run executable code, etc. inline is achievable as well. Sharing work should also be possible (although it might require an additional interface/translation layer on top of the current Public Library implementation).

Some of the drag could be eliminated by taking a slightly different route, by providing a stand-alone executable instead of something that runs in a browser at the cost of compatibility and distributability. I think this is particularly problematic when it comes to a Beaver display with graphics capability.

A step further would be to make a bootable version of The Beaver software that could be used with contemporary machines. This could be accomplished using something like an existing Linux distro that boots directly into a VM running The Beaver's native software, but this further narrows the number of people who can easily experience it.

It's tough to slide the scale to the sweet-spot with this, and to be honest the more I think about it the more it just feels like compromise. It seems like pursuing the software separately from the hardware makes sense, and that waiting for the hardware to be ready means waiting a long time before I can share the experience, but is the hardware really that "hard"? I could be shielded by the comfort of naivete but I'm not sure that realizing the hardware (at least in a bespoke prototype form) is any harder than realizing the software, and I think that the hardware is a very important part of the experience. I would argue that using The Beaver as a proof-of-concept for the FPGA-based general-purpose computer is maybe more important than The Beaver itself.

So maybe all the practicality of creating an easily distributable software-only version of The Beaver is not as practical as it might seem, when you consider the overarching goals I have for the project. While I genuinely believe that experiencing The Beaver will be pivotal to creating the kind of demand necessary to create a sustainable living out of it, I'm not convinced that there's a shortcut to providing that experience that doesn't involve working the hardware and software together.

Jason J. Gullickson, 2026

Sesquicentennial

Mon, 25 May 2026 08:37:56 -0500

Yesterday, Jamie summarized a book she just finished reading ("When No Thing Works") and it has a lot of great ideas for living through an apocalypse. One I've been thinking about a lot is the idea of imagining an ideal future 150 years from now.

Imagining the future is not something I'm unfamiliar with, and thinking decades out is something I spent plenty of time doing but 150 years? I can't say I've done much thinking that far out. That scale brings into focus something that at least I don't usually consider when thinking about the future: I won't be here to see it.

The 150 year forecast is a lot more fun than the shorter term in a number of ways. The sorts of things that seem like hard problems now seem less so that far out, if they are relevant at all. The limitations of technology can essentially be ignored (consider how impossible the technology we have now would have seemed in 1876) and even the social limitations we are under are likely to be less simply through the turnover of a few generations (while we have so far to go, consider the social progress the world has experienced over the last century and a half).

One of the most powerful things about this for me is that it takes me out of the picture. I often struggle with determining if what I plan for the future is good for everyone or just good for me. Thinking about the future beyond your certain demise makes it easier to determine this because you won't be there to enjoy it.

While the extreme distance from here to there forces you to think about more abstract predictions, applying this as a filter or test to decisions you make today is surprisingly useful. When you have a clear vision of the ideal world of 2176 you can ask yourself today "which choice gets us closer to that future?". I imagine the answer is often "I don't know", but that's useful information as well.

Something we talk about often is how the surface impression of our little city is one stuck in the past. A few years back there were a number of beautiful murals painted around the city, but they all featured subjects of the past, often industries that no longer exist. There is one that is a sort of exception, and while it depicts something from the past (the work of a local author) it's a sci-fi scene based on the author's futuristic fiction. It's the only one of these murals that I find any inspiration in, and it makes me wonder what the impact might have been if all the murals were depictions of the future?

What if we started to think about this collectively, what could Beaver Dam be like in 2176 if we started to work together today to define a shared vision of what an ideal future would be? What if we used this shared vision to shape current decisions? Could the abstraction of a time beyond the end of all our lives allow us to envision a shared future that includes what is most important to all of us?

I think it could. I don't think it will be simple, but I honestly beleive that if we can carefully curate such a group and such a plan and do so in a way that everyone involved understands the goal from the perspective I'm describing, I think such a shared collective vision is possible.

I will admit, it feels impossible saying that in a time of such extreme divisiveness, but if we think about what is good regardless of whether or not we get to experience it ourselves, I think we can come up with a list that all of us can agree on.

Jason J. Gullickson, 2026

KGL Zine WIP

Mon, 25 May 2026 10:36:03 -0500

EVs

Wed, 27 May 2026 06:47:02 -0500

Ever since I read "Electric Vehicles" by Sheldon R. Shacket around age 10 I knew I wanted an electric car. When it came time to get my first car that wasn't an option, as at the time the most common way to get an electric car was to replace the gasoline engine in a regular car with an electric motor, and I did't have the money to do that.

When I got my first full-time job I was planning to move to Madison and Saturn was planning to bring an electric car to market. I was totally ready to lease (they were only going to lease them) one of those beauties but we all know what happened next.

I have been pining for an EV ever since, and in the last decade or two there's been a growing number of them becoming available as well as gradually expanding charging infrastructure that makes owning one far less of an adventure than the second book I read about EV's. I've tried many times to procure one of these easy EV's but each time something expected or unexpected got in the way.

Yesterday the planets aligned and we brought-home a Kia EV9. We've only put about 100 miles on it so far, but it's been a lot of fun. There's still a little "EV adventure" to be had (it took some tweaking to get the L1 charger to cooperate with our garage wiring and we spent a solid 20 minutes figuring-out our first public charging station), but it's a lot like a gas car in all the ways that you'd want it to be.

I'll probably write more about it after we've spent more time with it.

I'm very excited to have finally found a way to get my hands on an electric car. Aside from all the practical reasons, it's really given me some hope that even after 40 years I'm able to accomplish this simple dream. It really makes me feel like some of the others I've had might still happen, even if they're taking far more longer than I ever could have imagined.

Jason J. Gullickson, 2026

Once more with feeling (did I break it part two)

Sat, 30 May 2026 16:53:25 -0500

Just another post to see if I fixed this thing.

Jason J. Gullickson, 2026

We return to our regularly-scheduled programming (already in progress)

Sat, 30 May 2026 16:57:13 -0500

I knew this, but this latest tantrum is real proof (and hopefully sufficient motivation) that I need to re-write preposter.us.

Maybe I should park a few other projects just for a bit and finally finish that job.

Jason J. Gullickson, 2026

Everything I know (so far) about running your house off of your car

Mon, 01 Jun 2026 08:51:21 -0500

One of the selling points of the Kia EV9 is that it supports "Vehicle to Load" or "V2L". I didn't know exactly what this meant when I read about it on the website, but I knew for a long time in Japan that EV chargers could flow electricity both ways, and you could store power from the grid in your car and use it when needed. I figured V2L was something like that finally coming to America. There's even a system advertised on the Kia site that does this automatically, just plug in to charge and the system will power your house when the lights go out, etc.

The catch is that system costs a lot, as far as I could tell, around $10,000. So I thought I'd try to learn more about V2L and see if there are other options.

As it turns out, there's a few terms surrounding the ability to use the battery in a car for things other than turning the wheels. While not all companies stick to the same definitions, it mostly breaks down like this:

* Vehicle-to-load uses on-board inverters to power external AC devices

* Vehicle-to-home or Vehicle-to-grid use external inverters and draw DC power from the vehicle

As you might guess, V2H and V2G are capable of delivering more power, because the invert isn't limited to something that reasonably fits inside the car. In the case of the Kia EV9, V2L is limited to 30 amps, and the adapters I've found so far that connect to the charging port are only good for 20 amps.

I clearly need to do more research on the capabilities of the NACS port on the EV9, because any product that claims to power a house from the EV9 is going to need more than 20 amps. That said, 20 amps isn't bad for emergency standby, and with almost 100KWh on tap, that's a few days worth of standby power at 20A.

So on the car side a ~$100 adapter turns the EV9 into a 100KWh Bluetti.

This makes the house side fairly simple: it's no different than connecting any other generator. To do this right means using a transfer switch, or possibly a "lock out" on the circuit breaker panel to ensure no backfeeding the grid when powering the panel from the car. With 20A avaliable I'm not going to power the whole house, but that's probably enough to keep the refrigerator & deep freeze cool, along with powering a few lights and keeping phones charged.

What I really wish I could do is run the heat pump, but aside from needing more than 20 amps, it also needs 240 volts.

One thought I've had is to "buffer" the 20 amp V2L supply with something like the Bluetti Apex 300. The Apex 300 can provide 240VAC at up to 50 amps, and while it's built-in battery can't do that for long, it might be enough to absorb the initial draw of big devices like the heat-pump even if it's being charged by a 20A supply from the car.

This is an interesting design, because it would allow me to use the EV9's battery without resorting to anything too exotic, and in the event that I don't want to use the car's battery (or the car is elsewhere), I can easily fall-back to another generator (a solar generator, gas generator, etc.) outside the house to keep the Apex 300 inside topped-up. Additionally, the Apex's battery can be expanded, allowing both more runtime and more "shock absorption". The Apex itself can of course take power from solar as well so it could become the foundation of a longer-term project to add some solar capacity to the house.

The total power available at the panel is still limited by the capacity of the Apex 300, but 50A at 240VAC is plenty for stand-by, and even a good goal for the long run (bear in mind there are still homes here with a 60A service...).

Before I commit to running a generator circuit I want to do some more research to see if I can find a 30 amp V2L adapter for the EV9. The cars documentation indicates that it can provide 30 amps, so my guess as to why the adapters I've found do not is simply to keep the outlet something compatible with most appliances instead of the more unusual 30 amp receptacles.

Jason J. Gullickson, 2026

The Month of Zig

Mon, 01 Jun 2026 09:18:13 -0500

Every day in the month of June, 2026 I'm going to spend at least one hour learning Zig.

Why?

Zig is the only programming language that I've used that has taken a strong position on keeping AI out of the language. I don't want any of the work I choose to do to be infected by AI at any level. I thought this would require using a language of my own creation, but it looks like the Zig team feels the same way I do, so going forward all of my programs are going to be written in Zig until something changes and that includes porting the programs I've already written that I use every day to Zig.

In order to do this, I need to get good with the Zig language, and the only way I know how to do that is to use it.

A couple years ago I played with Zig, and while there were some features that I thought were really cool (like built-in SIMD support), it wasn't enough for me to really get into it when I could do most of what it did in languages I was already proficient with. But things are different in 2026, and Zig has grown as well, and I think it's time for a change.

So for the month of June I'm going to invest at least an hour a day and hopefully by the end of the month I'll be proficient enough to do some real work.

I probably won't write about this every day (I just don't think I'll have the time), but I plan to post updates as I make make meaningful progress and share any ideas or experiments that go beyond the exiting documentation and published writing on the subject. I'll be porting code from Python, Golang, Node.js and maybe others, so there should be a little something for everybody.

Jason J. Gullickson, 2026

Personal Search Engines

Tue, 02 Jun 2026 08:12:37 -0500

A Personal Search Engine (PSE) is a search engine that specializes in your interests. It provides personalized search results by indexing only the things you are interested in, not by spying on you. Instead of crawling the entire Web and then looking for what you've searched for, A PSE crawls only the parts of the Web you are most interested in and looks for what you're searching for there. The result is a list of hits that are relevant to your interests that point to websites you are more likely to know and trust.

A PSE can run locally (on the same computer you use to browse the web) and in fact I expect this is how most of them will be used. A local PSE is exceptionally fast and by it's nature exceptionally private.

There are reasons you might consider deploying a PSE to a public server, but I'll get into later.

A PSE starts with an empty index and will need to be "seeded" before it can return any results on it's own. The simplest form of seeding is feeding the PSE the domain names of a websites you trust. Other sources of trusted domains can be fed to the PSE, such as a list of bookmarks or a collection of RSS feeds.

Any source of trusted domains can be used to seed or add to the index. The important thing is to tailor this list to websites that focus on your interests, the types of things **you** want to see in the results. If you don't want spam or ads or computer-generated content in your results, don't add domains with that sort of thing to your PSE. Additionally, the more specialized the domain the better; a website like "vintageapplecomputers.com" is more likely to provide high-quality results to a search like "Macintosh SE/30" than "facebook.com", etc.

Once a PSE is seeded it can begin returning search results. The act of searching causes the PSE to "self-seed" by crawling for more domains to index within the pages you select from the results. These additional domains could be added to the index automatically, or they could be curated in a list of "discovered" domains for later manual review.

When what you're looking for can't be found in the local index, a PSE can "federate" with the PSE's of people you trust to broaden the search.

This could continue, with PSE's calling "friends of friends" to build a wider network but I'm not sure this is necessary and there are some undesirable side-effects to this sort of multi-hop federation.

When you reach the end of the local search results, results from the PSE's you federate will follow.

Federation can also be used to "bootstrap" a new PSE. If a list of trusted PSE's is provided, searching the federation will provide results even before the local index is seeded. Selecting websites from these results will begin the self-seeding process described earlier.

Using federation this way has benefits beyond increasing search results. It spreads the work of searching, storing, maintaining indexes out across many independent nodes, making the cost of operating a large search index lower (low enough for individuals to contribute meaningfully to a global index). It also makes the system fast without having to run on expensive hardware.

Any PSE can utilize the federated network, (i.e.: use it to get results) but in order to contribute, a PSE needs to be reachable from the nodes it federates with. In a perfect world, PSE's running locally would be able to talk to other PSE's running on other people's computers, but right now it's more likely that a fully-federated PSE will need to run on a publicly-addressable server. A well-designed PSE will be capable of "graduating" from running locally on someone's computer to a publicly-hosted node capable of contributing to the federation.

Publicly-hosted PSE's could lead to a handful of servers handling all requests, and that would undermine the purpose of PSE's. Ideally there is a 1:1 ratio between people and PSE's. This keeps the local results tightly bound to a given person's interests and keeps the computing resources required for an individual node light. I'm not sure how to avoid this other than the "natural consequences" of running such a large node which include less-relevant search results, slower searching and increased resource consumption. Hopefully pain like that is enough to keep this risk at bay.

I've built a prototype PSE based on the description above and used it for about a week to guage both it's usefulness and to understand how much effort is required to create it. I'm excited to say that the results are positive on both accounts.

The prototype was used to index a few hundred domains locally (seeded from my RSS feeds) and both the speed (<4ms average) and quality of the results were exceptional. Resource consumption of the prototype is quite reasonable, using less than 10MB of memory to search and maintain a 5GB index.

I also tested federated modes (LAN only, nothing deployed publicly yet) and it works surprisingly well with a very simple federation implementation. Federated result latency will of course be greater across the Internet, but they are capped at a (configurable) 3 seconds so that would be the worst-case regardless of network and remote node latency.

I had planned to setup a public node and share the prototype with some friends this week, but due to The Month of Zig I'm going to delay that in order to rewrite the prototype in Zig. I don't know how long this will take, but I wouldn't expect it this month, and probably not until after July. If you're interested in helping experiment with the prototype when it's ready, get in touch.

Jason J. Gullickson, 2026

The Month of Zig - Day Three

Wed, 03 Jun 2026 07:35:04 -0500

I've been working my way through zig.guide the last two days, one hour a day and today I'm going to try and write my first program from scratch.

I'm going to attempt to write a port of Jet, a journaling tool I use daily that I've written and re-written in several languages. It requires little more than terminal and file I/O, and it's usually realized in less than 50 lines of code.

The first thing I need to do is figure out how to get input from the terminal. I found an example of this in zig.guide, but Weirdly it doesn't work so I guess it's time to reach for the standard lib docs.

https://ziglang.org/documentation/0.16.0/std/

Hmm... seems I'm too green to glean what I need from this.

I did some web searches to find an example and they were all over the place. I learned that the reason the example in zig.guide doesn't work is that a chunk of the standard library (std.fs.File) was just removed in the current version of Zig (although I can find no explanation as to why). I suppose that's to be expected in something that is still in it's sub-v1 stage but still...

It's easy to get discouraged at this stage. The tension of the feeling like you're trying to do something trivial against having a not-even-tenuous grasp of what you are working with is a very uncomfortable feeling and often enough to make you abandon your beliefs and ambitions and send you running-back to something comfortable. This is especially hard for me because I don't often find myself in this situation (probably because I'm very good at "cultivating naivete"), so when it does happen to me, it's debilitating.

For example, right now my brain is coming-up with lots of justifications for giving-up on Zig and falling-back to what I know to write a new language or something equally asymmetric to my goal of breaking-free of AI-poisoned languages by learning the only one that both exists and is committed to rejecting AI.

To counter this I'm trying to remember what it was like to push-through this feeling before. I start with thinking about similar contexts; other programming languages I've learned.

For many there's no equivalent. BASIC, Hyperscript, Dylan, VBscript, Javascript, PHP, Python, Lua all these were trivial to learn incrementally, even in the case of BASIC which I learned before I knew how to program at all.

What about assembly, the first "language" I learned after BASIC? Honestly I'm not sure I ever "learned assembly" as much as I learned what I needed of the instruction set of the various CPU's I've written assembly for. I don't think I've ever written an entire stand-alone program in assembly, just the parts that demanded maximum performance or a feature of the CPU I couldn't reach from the higher-level programming language I was working in at the time.

The next language I learned was C and C++. I first learned C using Borland Turbo C++ for DOS, and C is well-equipped for doing terminal input/output so here again it was fairly easy to get started writing programs like the ones I wrote in BASIC. C is very procedural, so it was not hard to "get productive" using the same sort of programming I learned in BASIC, and once I understood that functions were similar to BASIC's subroutines, I was off to the races. The main thing I got hung-up on were pointers (doesn't everyone?), but once I really understood they were just addresses I thought about them the way I thought about memory when working in assembly and I did fine. C++ on the other hand, I don't think I really learned it at the time, it wasn't until I was working with graphical environments that I really felt the need for something like C++ so to the extend that I dabbled in classes, etc. was very rudimentary when I was writing my own projects in C every day.

From there most of the "language learning" I did next was really learning about their libraries/toolkits/etc. Objective-C, C#, Java, most of the work was remembering what library the thing you wanted to do lived in and which of the several similar functions/classes/objects you should use. I suppose I have to mention Visual Basic here but again there wasn't a lot about the language itself to learn.

SQL, hmm... learning that might apply to my current condition. Rudimentary SQL ("SELECT * FROM PUBS"*) is trivial but really understanding how SQL works and how to write it in ways that make the most of it is very different from the types of programming I had done up to this point. I was "productive" in SQL long before I really knew what I was doing, and it wasn't until I spent a week in a SQL class with a bunch of Oracle DBA's being forced to switch to MS SQL Server that it really sunk-in. Thinking-back to climbing that mountain, the fundamental shift of understanding was a much bigger jump than what I'm tackling now with Zig. The challenge with Zig isn't a fundamental thing like SQL (it's still a procedural language) but more so just the verbosity and breadth of knowledge needed to do what seem to me like basic things.

So how did I cross the Rubicon with SQL?

I'm not really sure. I don't remember having any pressure to do so (I wasn't trying to solve a problem or meet a customer's need), and I'm not sure I was particularly driven by curiosity (I was more focused on the things I was building than what I was building them out of at the time). I guess it could have been immersion, I was taking a class in Chicago with people I didn't know in a town I wasn't familiar with, so I spent all day with the material and had nothing to do at night so I experimented with what I learned each day for hours. I didn't know anybody, but the instructor and everyone in the class was already very familiar with using the SQL language in far-more-complex ways than I ever had (or probably ever will), so every conversation was with an expert.

This sort of classroom-oriented, institutional way of learning is something that normally never works for me, but in this one case it was very effective. I returned from that training with a completely different way of looking at and working with SQL, and this informed my work with other languages and tools as well. In fact it's probably what helped me understand other languages and forms of logic that have the same sort of immediate/parallel execution that SQL has running on an RDBMS.

What I'm bumping-up against in Zig is nothing like the shift I needed to undergo to understand SQL, so I don't know that a week of deep immersion is necessary (although given the condition my brain is in now, maybe?) but reflecting on what it took to gain that understanding of SQL puts what I'm struggling with now into perspective and makes it feel a lot less overwhelming. In this light, I think what I need to do is simply accept that what it takes to read and write input from a person at the console in Zig is a lot more groundwork than it is in pretty much every other language I've learned, and that there's probably a good reason for this, I just don't know enough about the language to understand that reason yet.

After all, it's only been three hours...

Jason J. Gullickson, 2026

* this is an inside joke from the I2 Team days...

The Month of Zig - Day Five: Ask For Help

Fri, 05 Jun 2026 06:05:34 -0500

After posting a link to The Month of Zig - Day Three to the fediverse I received a number of replies, one from Alexey that was little more than a code snippet:

Yesterday, I tried pasting this code into the file where I'm trying to write my first new Zig program. It didn't compile, so I asked a follow-up question and received another terse-but-helpful response:

Turns out that this link was the key to what I was looking for on day three: a current example of basic terminal I/O and an explanation of how it's supposed to be done in the current version of Zig.

Through all the searching on day three I never ran across this. An argument could be made that I probably should have read the release notes for the version of the language I was working with, but I didn't because I didn't expect to find what I was looking for there. It was only through a feedback loop that included communicating with others who are working with the language that I was able to write a program (that wasn't just compiling an example) that runs and does something that I want it to do.

This was a reminder about the importance of community. I don't really involve myself in the communities around the other languages I program in, at least not directly. I don't exactly know why; maybe its because I've learned most of these languages before I had access to such communities, or have learned them in the workplace from coworkers who are a kind of community but not the community for a given language. If I'm being completely honest, I've kind of been turned-off by programming language-centered communities because I've never identified with any specific language, and a lot of these communities involve identity in a way that I don't relate to.

But learning a new language from scratch, on my own and seeing how hard it can be to begin to do anything no matter how simple, I can see how people who have learned a programming language (especially if it's their first) through participation in the language's community can become attached to both in a way that I've never been attached to a programming language. It's probably not the language that they are attached to but the experience of community, and things that threaten that (like other programming languages) are something they might buck, consciously or unconsciously.

This was a revelation to me because it helps me understand and navigate situations where the solution to someone's software problem is "simply" a matter of using the wrong tool (programming language) for the job, but they refuse to consider a different tool, or provide irrational arguments against it. In these situations, maybe I'm not simply proposing the use of a different tool, but a disconnection from a community.

The lesson here for me is that whether I like it or not, the community that forms around a language matters.

That would explain a lot of the struggles I've had "helping" people in this area.

The other lesson for me here is to consider asking for help sooner and more directly. This time I received help out of pure luck, I didn't intend to ask for it and I have no idea how ... found my toot and decided to take the time to help me out. I am very grateful because this morning I have a working program because of their help. Maybe if I had learned this lesson sooner I could be a little further along by now, maybe even have finished my Zig port of Jet?

...but I guess it's only been five hours, so maybe I should relax.

Jason J. Gullickson, 2026

Downlink 2026-06-05

Fri, 05 Jun 2026 06:27:33 -0500

I've skipped a couple of weeks and switched browsers as well, so prepare yourself.

* https://en.wikipedia.org/wiki/Compatible_Time-Sharing_System

* https://www.cozx.com/dpitts/ibm7090.html

* https://www.cozx.com/dpitts/ctss_recover.html

* https://timereshared.com/ctss/

* https://timereshared.com/reconstructing-joseph-weizenbaums-opl/

* https://en.wikipedia.org/wiki/Computer_Power_and_Human_Reason

* https://en.wikipedia.org/wiki/ELIZA

* https://www.jstor.org/stable/43852815

* http://www.maschafilm.de/en/dvd_plug_pray.html

* https://www.computerhistory.org/collections/catalog/102683842/

* https://www.amazon.com/Computer-Power-Human-Reason-Calculation/dp/0716704633

* https://archive.org/details/computerpowerhum0000weiz_v0i3/page/10/mode/2up

* https://tinyfpga.com/

* https://www.crowdsupply.com/tinyfpga/tinyfpga-ax-bx

* https://prjicestorm.readthedocs.io/en/latest/

* https://www.crowdsupply.com/tinyfpga/tinyfpga-ex

* https://nandland.com/fpga-101/

* https://nandland.com/book-getting-started-with-fpga/

* https://github.com/FPGAwars/icestudio

* https://github.com/FPGAwars/icestudio/wiki#organization-of-the-collection

* https://www.amazon.com/Carlisle-CT121623-Caf%C3%A9-Standard-Cafeteria/dp/B0018OZBT2

* https://en.wikipedia.org/wiki/Transcranial_magnetic_stimulation#Criticism_of_FDA_regulatory_procedures_for_medical_devices

* https://en.wikipedia.org/wiki/William_Gibson

* https://en.wikipedia.org/wiki/Electroencephalography

* https://en.wikipedia.org/wiki/VIC-20

* https://hackaday.com/blog/?s=cyberdeck

* https://en.wikipedia.org/wiki/William_H._Dobelle#Career_and_artificial_vision

* https://arstechnica.com/gadgets/2025/09/your-very-own-humane-interface-try-jef-raskins-ideas-at-home/

* https://arstechnica.com/gadgets/2025/09/jef-raskins-cul-de-sac-and-the-quest-for-the-humane-computer/

* https://www.kia.com/us/en/ev9

* https://wallbox.com/en_us/kia-ev9-quasar-2

* https://github.com/oozebot/preFlight/releases

* https://github.com/OrcaSlicer/OrcaSlicer/releases/tag/v2.3.2

* https://www.printables.com/model/927316-slide-box-pocket-sized

* https://shop.wallbox.com/products/quasar2-backup-power

* https://support.mozilla.org/en-US/kb/firefox-new-tab-widgets

* https://rasterweb.net/raster/

* https://www.printables.com/@jjg_239369/collections/liked

* https://git.sr.ht/~vertigo/kestrel-2/tree/master?__goaway_challenge=meta-refresh&__goaway_id=f3576859ae534e34185bf07e05d8f841&__goaway_referer=https%3A%2F%2Fgit.sr.ht%2F~vertigo%2Fkestrel-2%2Ftree%2Fmaster%2Fitem%2Fcores

* http://kratzgullicksonlabs.com/spore.html

* https://300mpg.org/2024/08/29/vehicle-to-load-v2l-bare-board-experimentation/

* https://numberconvert.com/blog/points-picas-pixels-typography-guide/

* https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Text

* https://en.wikipedia.org/wiki/Em_(typography)

* https://en.wikipedia.org/wiki/Sort_(typesetting)

* https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/User-Defined_Functions_and_Modules

* https://en.wikipedia.org/wiki/Wood_type

* https://en.wikipedia.org/wiki/Movable_type

* https://en.wikipedia.org/wiki/Letterpress_printing

~~~ goodbye Firefox, hello LibreWolf! ~~~

* https://press.stripe.com/the-dream-machine

* https://en.wikipedia.org/wiki/Joseph_Weizenbaum#Difference_between_deciding_and_choosing

* https://en.wikipedia.org/wiki/Jef_Raskin#Pioneering_the_information_appliance

* https://github.com/micropython/micropython/wiki/ContributorGuidelines#generative-ai-policy

* https://docs.sunfounder.com/projects/thales-kit/en/latest/micropython/python_start/syntax/while_loops.html

* https://us.elegoo.com/products/pre-owned-centauri-carbon?variant=51638643654837

* https://tabs.ultimate-guitar.com/tab/slayer/dead-skin-mask-tabs-27938

* https://gamerant.com/twilight-zone-most-controversial-episodes/

* https://docs.micropython.org/en/latest/esp8266/tutorial/filesystem.html

* https://docs.micropython.org/en/latest/library/os.html

* https://siytek.com/micropython-networking-web-server/#Opening-a-new-socket

* https://awesome-micropython.com/#telnet

* https://github.com/gitcnd/telnetd

* https://github.com/orgs/micropython/discussions/10438

* https://randomnerdtutorials.com/micropython-esp32-esp8266-access-point-ap/

* https://docs.micropython.org/en/latest/library/socket.html

* https://docs.micropython.org/en/latest/library/asyncio.html

* https://github.com/peterhinch/micropython-async/blob/master/v3/docs/TUTORIAL.md

* https://linux.die.net/man/1/minicom

* https://www.telnetbbsguide.com/

* https://syncterm.bbsdev.net/

* https://github.com/mkrueger/icy_tools

* https://mysticbbs.com/downloads.html

* https://subethasoftware.com/2018/02/28/wire-up-your-own-rs-232-wifi-modem-for-under-10-using-esp8266-and-zimodem-firmware/

* https://github.com/bozimmerman/Zimodem

* https://github.com/mecparts/RetroWiFiModem

* https://github.com/stardot/esp8266_modem

* https://mrshu.github.io/github-statuses/

* https://docs.micropython.org/en/latest/esp32/tutorial/intro.html#troubleshooting-installation-problems

* https://github.com/orgs/micropython/discussions/10697

* https://github.com/peterhinch/micropython-nano-gui

* https://wiki.heltec.org/docs/devices/open-source-hardware/esp32-series/three-platform/Micropython/

* https://docs.espressif.com/projects/esptool/en/latest/esp32/esptool/basic-commands.html

* https://docs.espressif.com/projects/esptool/en/latest/esp32/troubleshooting.html#troubleshooting

* https://www.robmiles.com/journal/2025/1/29/setting-up-esptool-in-a-python-virtual-environment-1

* https://github.com/meshtastic/firmware/issues/5080

* https://en.wikipedia.org/wiki/Supersonic_transport

* https://en.wikipedia.org/wiki/Boeing_2707

* https://en.wikipedia.org/wiki/Lockheed_L-2000

* https://en.wikipedia.org/wiki/Tupolev_Tu-144

* https://nandland.com/blocking-vs-nonblocking-in-verilog/

* https://agilemanifesto.org/

* https://www.falvotech.com/Kestrel-2EX.html

* https://codewithrockstar.com/tutorial

* https://dylanbeattie.net/

* https://en.wikipedia.org/wiki/Mikoyan-Gurevich_MiG-25

* https://a2zev.com/products/v2l-nacs

* https://en.wikipedia.org/wiki/Vehicle-to-grid

* https://www.bluettipower.com/products/apex-300-home-battery-backup

* https://ziglang.org/code-of-conduct/

* https://ziglang.org/learn/

* https://ziglang.org/documentation/0.16.0/std/#std.Io.Reader

* https://ziglang.org/learn/samples/

* https://pedropark99.github.io/zig-book/

* https://zig.guide/standard-library/readers-and-writers

* https://zig.guide/getting-started/hello-world/

* https://ziggit.dev/t/right-way-to-read-user-input-from-stdin-in-zig-0-15-2/13623

* https://ziggit.dev/t/fs-file-and-io-file/13362/11

* https://ziglang.org/download/0.16.0/release-notes.html#Juicy-Main

* https://ziglang.org/documentation/master/#Comments

Jason J. Gullickson, 2026

Do It Right

Sat, 06 Jun 2026 07:13:20 -0500

There's no shortage of excuses to do things the wrong way. "Excuses" sounds harsh but I mean it in the least judgmental way possible, an excuse is just a reason, and I wouldn't fault anyone for doing something the wrong way, especially right now, because there's an endless stream of reasons for doing things any way you can manage to get them done.

But I'm trying to do a better job when I can and the thing that has been working for me lately (when I can remember to do it) is thinking about the people who will have to live with what I leave behind. On a larger scale, this is things like the state of the house I plan to leave to my son, but on a smaller scale it's the work I do every day, even the work that I don't want to do, like the work I do while forced to work with AI.

This work may be the most toxic of all the work I've done in my life, and for many reasons I won't enumerate here, it may be impossible to do it right.

But I think about the other programmers I work with who will inherit this code, and the people who will use the software that this code is a part of and I try to do the work in a way to produce something that will at least be better than it was when I found it.

I want to make it better for having had me there.

I don't think any of us can do this all the time. There are simply too many demands on our attention, our patience, our bodies and our minds not to mention whatever resources we've managed to scavenge together and none of this is our fault (or at least I don't think it's your fault, I doubt many billionaires read this blog). It's perfectly OK if you can't find a way to do things right when you're just trying to survive in this world.

But if you can find a way to do one thing, anything the way you think is right, the mental health benefits are tremendous.

Jason J. Gullickson, 2026

Printable Type

Sun, 07 Jun 2026 07:14:55 -0500

We've been collecting wood and metal type for use at the KGLMDPS. Antique type is so cool, but also expensive and not always what you need. While I plan to learn how to make our own wood type, in the meantime we wanted the ability to make custom type sooner so we decided to experiment with 3D printed type.

We've (2D) printed with 3D printed things before, but I've never set-out to make a proper "set" of type that is made to any sort of standard, so this time I wanted to come-up with a way to 3D print some type that would work as much like the antique wood type we have.

I started by measuring a piece of wood type with the intention of producing printable type that is as compatible with the wood type as possible. The ultimate goal would be to mix-and-match printed type with woodtype.

// Fixed dimensions (measured from actual wood type)

OVERALL_DEPTH = 23.5;

BLOCK_DEPTH = 19.5;

GLYPH_DEPTH = OVERALL_DEPTH - BLOCK_DEPTH;

I sunk a few hours into this and learned the hard way that while the terms and metrics of wood and digital type overlap, there's historic reasons that they are not exactly compatible.

I might take-up this quest again someday, but in the interest of getting something done now I switched-gears and focused on making printable type that was at least compatible with itself.

Those hours spent researching the history of type were not a complete waste though, and helped me understand how to properly generate the parts of the type so that the printable type at least works the same as the wood type even if there's not an easy way to mix and match them.

The result is an OpenSCAD file that generates a set of type by simply specifying the desired font and size (in points). This even works with OpenSCAD's "customizer" feature so you don't need to modify the code to change these parameters.

The OpenSCAD file is limited to either rendering a single letter/glyph or a semi-hardcoded set of letters (I couldn't find a way to paramaterize the list) and the font has to be specified as a string (no way to connect it to a font picker yet) but even so it's fairly easy to work with and I'm sure if I do some homework there's probably someone who has made an improved interface to the customizer features that could make this easier for others to use.

We did a few single-letter tests and the results were better than expected! I'm running a full set of type now and when that finishes we'll do some more realistic tests and see how things turn out.

The ultimate version would be something that integrates both the STL generation and the slicing, etc. so someone could simply select the parameters they want and print the type. I can imagine a web interface that uses this file and the OpenSCAD command line to generate the STL's, and I'm pretty sure I could upload and print a sliced Gcode file through the API's provided by Klipper and/or the proprietary firmware on my Centauri Carbon, I'm just not sure about the slicing part (I use OrcaSlicer and I've never looked into using it from the command line). Something to consider for the future.

For now this should accelerate our use of printable type at KGLMDPS and open up a few new doors for creativity.

I've published the code for Printable Type in it's current state to Codeberg. I have a number of improvements planned and will be adding those features as well as any improvements we find needed after doing some more testing.

Jason J. Gullickson, 2026

Try, Try Again...

Mon, 8 Jun 2026 20:56:04 -0500

Innovation Through Constraint

Tue, 09 Jun 2026 06:46:23 -0500

This being The Month of Zig, I started thinking about how I would port my Personal Search Engine (PSE) prototype to Zig. As I worked through the prototype code one of the challenges to porting it is that the Go version depends on Go's built-in HTML parser, but there's no HTML parser in Zig's standard library (yet?). The PSE's web crawler needs an HTML parser to read the HTML documents it crawls and get things like the page title, body and links that go into the PSE index.

I found some third-party HTML parsers, but the ones I found are incomplete or have limited testing and crawling is both critical to the functionality of the PSE (probably the second most important thing) and also where most of the work happens so it needs to be accurate, reliable and efficient.

I could have written an HTML parser (or at least enough of one to get the things the PSE needs out of an HTML page) but that's a nontrivial amount of work and I'm already chomping at the bit to get this prototype into other people's hands for testing. HTML is also a moving target, which means that a home-grown parser will require ongoing maintenance. Also this would have all the downsides of using one of the current third-party HTML parsers.

But being forced to think about HTML parsing gave me a new idea: what if I don't parse the HTML pages to extract what I need for the index? What if instead I just read through the data and grab the things I need?

This "streaming" approach gets me everything I need without the complexity and overhead of parsing each entire HTML document into an object. Aside from eliminating all the problems above, this approach requires significantly less resources of processing all that data and then throwing-away most of it. It also makes it possible to predict how much memory will be needed because you can control how much data you need to work with at a time. In retrospect, it's a much better solution to the specific problems I need to solve than a full-blown parser.

I took this knowledge gained from working on the Zig port and "backported" it to the Golang prototype and the results are really amazing. Not only does it work, but it's faster and much more memory-efficient while producing the exact same output I used from the parser. Not only that, but I was able to implement it in a generic enough way that I was able to re-use this "streaming extractor" module to eliminate parsers elsewhere (notably some of the import code), further reducing dependencies in the code.

I might even re-use it in other projects...

I don't think it ever would have crossed my mind to question the use of an HTML parser in a web crawler used to generate a search index of web pages. The only way it might have would have been if a performance problem had emerged while using the system in production, at which point solving it would have been an emergency. Instead, by attempting to port the prototype to a different, more constrictive programming language I not only reconsidered this but came up with a superior implementation.

Even if I never complete the Zig port of the PSE prototype, the porting effort will have paid major dividends. This is a very practical example of the value of learning something new, even when there isn't an immediate "practical" reason to do so.

Jason J. Gullickson, 2026

Sometimes that's all you can do

Wed, 10 Jun 2026 16:48:22 -0500

The Environment

Thu, 11 Jun 2026 06:42:51 -0500

This morning has been really frustrating. I tried so many times to work on something and my computer just kept getting in the way. Instability, slowness, broken tools, distractions; a constant stream of events bent on breaking my concentration, trying my patience and evaporating gumption.

All rather discouraging.

I need a place to work where this doesn't happen.

The Swyft environment on my Apple //e is a place like this, but I can't take it with me. The Beaver computer I'm working on will be a place like this, but it doesn't exist yet. The chicken-and-egg problem of finishing The Beaver is that I have to work on it in this disruptive place, with so little time and capacity to work on it and on mornings like this one I wonder how I'll ever get there.

A while back I wrote about "how to get there from here" and talked myself out of using emulation or something akin to it to bootstrap The Beaver, but this morning I'm warming-up to that, or something like it. If I have to wait until I finish the hardware and the software to start working in a less disruptive environment... it's going to take a long time and more energy that I probably have.

So right about now I'm considering alternatives.

The one that feels most attractive is something I'm calling "The Environment". Not a virtual machine or emulator in the traditional or strictest sense but more like a virtual space to work in that is isolated from the hardware/software/etc. where it is running. This is like a virtual machine, but not strictly from the computer-science perspective, more like from the personal perspective. It doesn't have to be made of the same things as a VM or provide the same sort of technical isolation from the host but simply isolate the person working in it from these outside influences.

This is interesting to me because it could be composed of things that might already exist, may be temporary and don't need to fit into a strict linear path between where we are and what I want to accomplish with The Beaver. The important thing is that they provide an environment in which to do the work and that can evolve over time to utilize the product of the work as it becomes available.

The other thing that is important about The Environment is that it is portable. I already have a non-portable version of this in the Swyft-powered Apple //e, and when I can work on it, it's incredibly productive. But as I said before, I can't take it with me, not even to another room in the same house, and this puts a serious damper on how much time I have to work there. So whatever The Environment is, it needs to be portable enough that I can use it from whatever machine I have available.

This makes me lean toward something networked, but that puts a lot of encumbrances on the thing right out of the gate. I'm not ruling this out, but it definitely gives me pause.

It could be something that lives on a flash drive, built into multi-platform/architecture binaries that use shared data (this is essentially how my Pouch tools work). This is interesting but it probably limits The Environment to a terminal-based text-only thing. This is true for the Swyft //e as well, and might be good enough for awhile.

It could be a bootable environment, something like a Linux-based bootable USB that transitions into The Environment. That would allow the portability of the flash drive without the complexity of working with multiple operating systems and make it easier to do something graphics-based. It also means that while The Environment is running there's no interference from an underlying host operating system (instability, slowness or distracting notifications, etc.). It kind of feels like a lot to have to reboot the machine into The Environment, and creating such a bootable thing means fooling around with Linux a bit (probably), but of the options so far it feels like the most interesting one.

None of these feel quite right to me but this train of thought does feel right, so I'm going to keep riding it. Maybe I'll do a little homework and experimentation with creating a bootable flash drive and see how far I can get; maybe it's easier than it used to be? If nothing else the act of doing the work often results in more ideas to choose from and explore whereas talking about it too long tends to just get me stuck.

Jason J. Gullickson, 2026

NAS-T

Sat, 13 Jun 2026 08:26:45 -0500

Terra-distributable personal data storage.

The idea is pretty simple: a little box you put on your network where you can store your electronic files and not worry about losing them. These have been around for ages and come in all sorts of shapes and sizes. Many have some form of redundancy so that if something breaks (a disk fails, etc.) the data they store is not lost, but if something happens to the entire device (like a house fire, or it walks out the door) everything is gone.

The standard response to this is to back up the NAS somewhere "offsite", typically some cloud service. This works, but it usually involves paying rent, and trusting your most precocious, personal, private bits to companies who frequently loose track of such things is risky.

So the idea behind NAS-T is to solve the offsite backup problem through backing-up to OPT: Other People's NAS-T.

The device allocates some percentage of the total physical storage to store encrypted backups from other NAS-T devices (I'm still noodling on the exact amount).

For example, if you were to purchase a NAS-T with 10TB of storage, you could store 10TB of data on it, but the physical storage medium inside the device would have a capacity of maybe 15TB.

As soon as you connect a NAS-T device to your network and grant it access to the Internet it begins to store backup data from other NAS-T devices. Once you start copying data of your own to the device, that data is automatically encrypted and transmitted to other NAS-T devices across the Internet.

From your perspective it's no different than any other network storage device. You mount it on your computer like a network drive, you copy and delete files, etc. The only point where things change are in the event that you loose your device. If this happens, you can take a new NAS-T, configure it just like you did the original and once it is connected to the Internet, your files will begin to reappear.

I have a few ideas for the implementation of this but I'm trying to decide how deep I want to dive into that in this post. This is a topic I love to think and talk about, which means that if I get started this could be a really long post.

You've been warned, "here there be dragons"

It will surprise no-one that the way I'd implement this starts with something like JSFS, using one of the distributed blockstore designs I've experimented with. JSFS provides the foundational file store, defaults to encrypting jblocks and jnodes and distributes them to peers with a 1:3 replication ratio.

1:2 is safe, 1:3 is probably sufficient for most personal-use scenarios I can imagine. It could be higher, but I need to work the math more.

The real question is how to expose the JSFS API in a way that can be directly consumed by typical clients. A web UI is of course an option but something like SMB/CIFS (or whatever they call a "Windows share" now) is needed to fit into NAS expectations.

There are some unanswered questions here about discovery, firewall traversal, etc. but I've covered those topics extensively elsewhere with regard to JSFS federation so I won't go into that here. This application makes some of that easier because having some sort of coordination server(s) on the public Internet is not as unsavory as it is to me for general-purpose JSFS use.

This could be done a few different ways. The off-the-shelf-ish way would be to finish writing the JSFS FUSE driver and then use Samba/etc. on Linux to re-share the FUSE mount as a Windows network drive. This is probably the "right" way to do it but if you know me, you know I like doing things the hard way.

A more direct approach would be to write a driver that serves the Windows share directly from JSFS, possibly even bypassing the JSFS REST API and connecting to the underlying storage primitives. I've never written something like this for JSFS, but it's easy to imagine being a modular/pluggable part, especially in the Golang port.

Having a "slot" like this in the architecture opens the door for exposing other interfaces in a modular fashion; in fact the REST API could be the first of these modules...

Taking this route opens the door for getting rid of Linux entirely using something like gokrazy or a unikernel, making the device not only more resource efficient but also more stable, secure and eliminating the need to update it.

I've been looking for something to motivate me to complete the Golang port of JSFS and a project like this, if there's some interest from other people might be compelling enough to get me to do it.

Jason J. Gullickson, 2026

A good thought spoiled?

Sun, 14 Jun 2026 09:58:55 -0500

Something I don't understand about myself is how I can get really excited about an idea, think about it intensely and even build-out part of it one day and then the next day I'm almost completely disinterested in it, and in extreme cases sort of disgusted by the idea of working on it.

It's very weird.

When this happens it's almost like upon reflection it's a bad idea, or something that seems like I was deluding myself into thinking it's valuable and when this feeling hits I feel really stupid or silly for thinking it was worth the effort I was putting into it.

What's very weird about this is that the feeling isn't the result of any actual conscious evaluation. It's not the product of negative feedback or realizing that there's something fundamentally wrong or evil about the idea. It's never even a matter of some experiment proving the idea is flawed (as far as I can remember), it's just the bad feeling in my gut when I try to work on it.

I can't say for sure whether or not this feeling has ever been right about anything. I can't recall an idea that turned-out to be actually bad after experiencing this reaction to continuing to work on it. That's not evidence against it's accuracy, because there's lots of projects I haven't finished (yet), so I can't say with any confidence that some of the ideas that this feeling applies to turned-out to be good in spite of this reaction. Off-hand I can't think of a project I completed with good results that experienced this sensation at some point along their road to completion. That's just as likely the result of my faulty memory as it could be of things actually having gone that way.

It's all subjective, based on no evidence; certainly not factual.

I guess the smart thing to do would be to start keeping track of when this feeling slams-down and note what idea or project it applies to so I can review the history of projects that reach completion (or at least get released to the wild) and see if they ever hit this wall. Then I could have some evidence on which to base a decision about how seriously I consider this feeling.

Jason J. Gullickson, 2026

Give 'em the (big) finger

Tue, 16 Jun 2026 08:01:49 -0500

One of the fun things we realized could be done with the Printable Type script is making type using "symbol" fonts.

We first ran a partial set, but when printed at the same size (24 points) as the alphabet set we ran earlier, the details of some of the symbols got pretty gummed-up by support.

Rerunning them at about 3x that size made a "big" difference.

At first this was a somewhat manual process because the symbols we're interested in go beyond the regular 26 codepoints that make up the english alphabet, so the script had to be modified to render the whole set.

I modified the script to make working with these fonts a little easier (you can now specify a particular codepoint in the customizer) but it still could use some work to make rendering a full set automatic.

Printing at larger point sizes also revealed some aberrations in the finished product around the edges of the (2D) print.

This could be considered charming, but I'm curious to see if I can eliminate it if desired by tweaking some printing settings. My first guess is that the first layer "squish" might be to blame, and perhaps reducing that or decreasing the overlap between the infill and the outside wall might clean it up.

Jason J. Gullickson, 2026

The gift of deadlines

Tue, 16 Jun 2026 10:31:26 -0500

Jamie and I are going to Alaska this fall and I'm hoping to do some writing while we are there. I imagine it will be a place where some inspiration might occur. I don't want to bring my regular laptop for many reasons, so I plan to bring something else instead.

Earlier this year I decided that I was going to bring something I built for this, and that something was The Beaver (even though I wasn't calling it that at the time). The trip is in August, and it's now mid-June. That leaves me roughly two months to have The Beaver ready.

Based on my current designs, that's not likely to happen.

That's OK, because realizing this deadline this morning, I'm immediately thrust into "what can I do in time" thinking, which for me makes it a lot easier to make decisions.

The first step is to think if there is something that exists that I could take with that would fulfill the role. I can't really think of anything, but the baseline of what I want is the SwyftCard-equipped Apple //e. I can't take the //e to Alaska but what if I could?

Emulation is certainly an option on this compressed timeline. I don't know off-hand what it would take to get an Apple //e emulator to emulate the SwyftCard, but if it hasn't already been done, it seems like something I could figure out.

That takes care of a lot of things but there's still a hardware problem to solve. If emulation is the way I'm going to go, any random piece of hardware could probably fit the bill, but again I don't want to take my laptop, and I'd prefer something more compact.

It's not incomprehensible to consider fabbing a piece of custom hardware using off-the-shelf modules. I even have a suitable keyboard (I think I can make the PLANCK I built for RAIN-PSP for this...). I'm pretty sure that I've seen Apple //e emulators for the ESP-32, so a "slab" consisting of the RAIN-PSP keyboard, a microcontroller running some keyboard firmware, an ESP-32 emulating an Apple //e + SwiftCard and some generic TFT display seems reasonable. Couple it with a regular USB power bank and I could even forgo the charging circuitry...

Another option would be to use my "Game Dad", a handheld Game Boy-like video game device that is used exclusively for emulation. I haven't tried emulating an Apple //e on it yet, but I know it works with a USB keyboard from trying one to program PICO-8 on the device. It might not be as integrated as a custom piece of hardware, but it's definitely closer to working, and might be fun to have along anyway.

If I go *that* route, here's what I need to do before August:

* Find a suitable USB keyboard for use with the SwyftCard

* Find an Apple //e emulator for the Game Dad

* Figure out how to get the //e emulator to emulate the SwyftCard

* Maybe design something to hold the Game Dad and keyboard together in a convenient way

I think that's about it.

Aside from meeting the needs for this particular trip, this would also give me a portable Swyft setup. On the surface this doesn't seem to make much progress toward realizing The Beaver, but it might. It will definitely get me more "yoke time" with Swyft, which will help me know more about what it's limits are and what will need to be expanded for The Beaver. It will also give me two Swyft machines to work with which will give me a stronger reason to get The Public Library working. Finally, this emulation approach could also be used to emulate The Cat, giving me a chance to both gain some experience with that Swyft-like system and also test interop between the SwyftCard and The Cat via The Public Library.

So it's real progress toward the goal as well.

I will have a little time to play this weekend so I might take a swing at that short list above and see how far I can get.

Jason J. Gullickson, 2026

Margo give me strength

Tue, 16 Jun 2026 20:20:33 -0500

Now we just need something to plug it into...

Wed, 17 Jun 2026 10:30:22 -0500

Kitty Steps

Sun, 21 Jun 2026 07:22:48 -0500

In my continuous process of finding a path to the Swyft-like computer to replace the computers I use now uncovered an even finer-grained way to get to something usable quicker. It's quite simple: use the tools I have to make a smaller version of the Canon Cat.

A "kitten"

The hardware spec for The Kitten is pretty simple:

* A Quality keyboard with LEAP keys

* A single-board computer (SBC)

* A display

* A battery

* A "beeper"

The software spec is even simpler:

* A Canon Cat emulator

* Just enough of an operating system to boot the emulator

In addition to emulation of The Cat, The Kitten software will be tweaked just enough to be able to exchange data via The Public Library and possibly expose some of the other interesting resources provided by the SBC.

The beauty of this approach is that I should be able to get most of the software side of it figured-out using my regular Linux laptop. To kick this off I started experimenting with an Apple //e emulator and SwyftWare because right now I'm more familiar with that then I am the Cat, and I figured general-purpose Apple //e emulation was more sorted than the single Cat emulator I found.

The emulator I decided to try is LinApple. Aside from running on Linux, it works full-screen with framebuffer video which means I should be able to run it without a "Desktop Environment", window manager, etc.

I was really excited to see the SwyftCard tutorial boot-up and go full-screen, but I was just as quickly disappointed when I tried to use it.

After a few keystrokes the emulator appeared to stop responding. I'm not sure if it actually froze or if it just stopped accepting input. After a few forced restarts it became clear that I wasn't able to find a few of the keys essential to using the SwyftCard (the apple keys that stand-in for LEAP, etc.) so I thought maybe the problem is just a matter of adjusting the keyboard mappings.

Other than picking the overall keyboard/language there wasn't a lot in the configuration file to address this, and as I read the code I realized that I'm not even sure what keys on my laptop I'd expect to map to the open and closed Apple keys used for LEAP. Left and right Alt seemed like the obvious choice, but it wasn't clear to me while reading the code how those could even be captured, and there were a lot of comments and even a Github issue about waiting to address issues with keyboard mapping until a much more significant change was made to the codebase, so this wasn't looking like a simple fix anymore.

I tried experimenting with the emulator a bit more to see if I could work-around this, but it became clear that there might be larger problems as well. I can't say for sure, but it seems like maybe it does lock-up when the "beep" in SwyftWare is triggered, and I'd read somewhere that another emulator struggles when this occurs (it may have been a Cat emulator, but something in the ballpark).

All of this is complicated by the fact that I'm not using an actual SwyftCard emulation but a special disk image that was made to allow Apple //e's with no SwyftCard to run the Swyft environment. Maybe the way this works contributes to the struggles of the emulator? I don't know.

I considered trying other emulators but since this was intended to be the simplest first step and it turned out not to be, maybe it makes more sense just to move-on to emulating the Cat instead?

The only source of Cat emulation I was able to find is via MAME. It has noted limitations with the serial port which is something I'm going to need, but after reading-through the MAME driver code for that Cat it looks like something that might not be impossible for me to help get sorted. I don't know a lot about MAME, but it's a mature emulator that seems capable of emulating just about anything somehow so I feel more confident that problems like keyboard mapping have solutions and if I need some help with it there's probably a vibrant community to tap-into.

Plus I could use an excuse to spend some time and get familiar with The Cat.

Hopefully I'll get some time later today to experiment with this and see if I can make some progress on the softer side of The Kitten.

Jason J. Gullickson, 2026

Going directly to the source

Tue, 23 Jun 2026 07:03:07 -0500

I'm spending the morning reading the MAME Canon Cat "driver" sourcecode to see if I can figure out how to use it. Simply running it, I can't figure out where essential things like the LEAP keys are.

The code is well commented, which is fortunate because my C++ is rusty, and I don't even know how to configure MAME let alone write drivers for it.

As I read through the code I feel like I'm starting to get the hang of how MAME models things, and I'm realizing that learning the fundamentals of that would have made understanding this much easier.

I'm also remembering a book I read about recreating video game hardware using FPGAs and realizing that the approaches outlined in that book might apply well to the task at hand.

There's a lot of `TODO`s in this code, and it's clear that there's a lot of work to be done before I could use it on a regular basis for real work. Maybe I could help cross some of those off the list, but clearly the author has done a lot of homework on this machine and I'm starting to wonder why the last commit is from two years ago...

Honestly this reads a lot how the VHDL code I've read is structured.

There seems to be a fair amount of code compensating for the differences between the behavior of the simulated hardware and the real thing.

AH, here we go, the keyboard map!

```

PORT_START("Y0")

PORT_BIT(0x01, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_N) PORT_CHAR('n') PORT_CHAR('N')

PORT_BIT(0x02, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_M) PORT_CHAR('m') PORT_CHAR('M')

PORT_BIT(0x04, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_K) PORT_CHAR('k') PORT_CHAR('K')

PORT_BIT(0x08, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_J) PORT_CHAR('j') PORT_CHAR('J')

PORT_BIT(0x10, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_Y) PORT_CHAR('y') PORT_CHAR('Y')

PORT_BIT(0x20, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_T) PORT_CHAR('t') PORT_CHAR('T')

PORT_BIT(0x40, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_6) PORT_CHAR('6') PORT_CHAR(0xA2)

PORT_BIT(0x80, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_5) PORT_CHAR('5') PORT_CHAR('%')

PORT_START("Y1")

PORT_BIT(0x01, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_B) PORT_CHAR('n') PORT_CHAR('B')

PORT_BIT(0x02, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_COMMA) PORT_CHAR(',') PORT_CHAR('<')

PORT_BIT(0x04, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_L) PORT_CHAR('l') PORT_CHAR('L')

PORT_BIT(0x08, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_H) PORT_CHAR('h') PORT_CHAR('H')

PORT_BIT(0x10, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_U) PORT_CHAR('u') PORT_CHAR('U')

PORT_BIT(0x20, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_R) PORT_CHAR('r') PORT_CHAR('R')

PORT_BIT(0x40, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_7) PORT_CHAR('7') PORT_CHAR('&')

PORT_BIT(0x80, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_4) PORT_CHAR('4') PORT_CHAR('$')

PORT_START("Y2")

PORT_BIT(0x01, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_V) PORT_CHAR('v') PORT_CHAR('V')

PORT_BIT(0x02, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_STOP) PORT_CHAR('.') PORT_CHAR('>')

PORT_BIT(0x04, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_COLON) PORT_CHAR(';') PORT_CHAR(':')

PORT_BIT(0x08, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_G) PORT_CHAR('g') PORT_CHAR('G')

PORT_BIT(0x10, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_I) PORT_CHAR('i') PORT_CHAR('I')

PORT_BIT(0x20, IP_ACTIVE_LOW, IPT_UNUSED) // totally unused

PORT_BIT(0x40, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_8) PORT_CHAR('8') PORT_CHAR('*')

PORT_BIT(0x80, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_3) PORT_CHAR('3') PORT_CHAR('#')

PORT_START("Y3")

PORT_BIT(0x01, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_C) PORT_CHAR('c') PORT_CHAR('C')

PORT_BIT(0x02, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_NAME("Left USE FRONT") PORT_CODE(KEYCODE_LCONTROL)

PORT_BIT(0x04, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_QUOTE) PORT_CHAR('\'') PORT_CHAR('"')

PORT_BIT(0x08, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_F) PORT_CHAR('f') PORT_CHAR('F')

PORT_BIT(0x10, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_O) PORT_CHAR('o') PORT_CHAR('O')

PORT_BIT(0x20, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_E) PORT_CHAR('e') PORT_CHAR('E')

PORT_BIT(0x40, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_9) PORT_CHAR('9') PORT_CHAR('(')

PORT_BIT(0x80, IP_ACTIVE_LOW, IPT_UNUSED) // totally unused

PORT_START("Y4")

PORT_BIT(0x01, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_X) PORT_CHAR('x') PORT_CHAR('X')

PORT_BIT(0x02, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_NAME("Right USE FRONT") PORT_CODE(KEYCODE_RCONTROL)

PORT_BIT(0x04, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_NAME("Right Shift") PORT_CODE(KEYCODE_F2) // intl only: latin diaresis and latin !; norway, danish and finnish * and '; others

PORT_BIT(0x08, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_D) PORT_CHAR('d') PORT_CHAR('D')

PORT_BIT(0x10, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_P) PORT_CHAR('p') PORT_CHAR('P')

PORT_BIT(0x20, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_W) PORT_CHAR('w') PORT_CHAR('W')

PORT_BIT(0x40, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_0) PORT_CHAR('0') PORT_CHAR(')')

PORT_BIT(0x80, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_2) PORT_CHAR('2') PORT_CHAR('@')

PORT_START("Y5")

PORT_BIT(0x01, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_Z) PORT_CHAR('z') PORT_CHAR('Z')

PORT_BIT(0x02, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_SPACE) PORT_CHAR(' ')

PORT_BIT(0x04, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_NAME("Return") PORT_CODE(KEYCODE_ENTER) PORT_CHAR(13)

PORT_BIT(0x08, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_S) PORT_CHAR('s') PORT_CHAR('S')

PORT_BIT(0x10, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_OPENBRACE) PORT_CHAR(0xBD) PORT_CHAR(0xBC) //PORT_CHAR('}') PORT_CHAR('{')

PORT_BIT(0x20, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_Q) PORT_CHAR('q') PORT_CHAR('Q')

PORT_BIT(0x40, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_MINUS) PORT_CHAR('-') PORT_CHAR('_')

PORT_BIT(0x80, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_1) PORT_CHAR('1') PORT_CHAR('!')

PORT_START("Y6")

PORT_BIT(0x01, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_NAME("Left Shift") PORT_CODE(KEYCODE_F1) // intl only: latin inv ? and inv !; norway and danish ! and |; finnish <>; others

PORT_BIT(0x02, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_NAME("Left LEAP") PORT_CODE(KEYCODE_LALT)

PORT_BIT(0x04, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_SLASH) PORT_CHAR('/') PORT_CHAR('?')

PORT_BIT(0x08, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_A) PORT_CHAR('a') PORT_CHAR('A')

PORT_BIT(0x10, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_CLOSEBRACE) PORT_CHAR(']') PORT_CHAR('[')

PORT_BIT(0x20, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_TAB) PORT_CHAR('\t')

PORT_BIT(0x40, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_EQUALS) PORT_CHAR('=') PORT_CHAR('+')

PORT_BIT(0x80, IP_ACTIVE_LOW, IPT_UNUSED) // totally unused

PORT_START("Y7")

PORT_BIT(0x01, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_NAME("Shift") PORT_CODE(KEYCODE_RSHIFT) PORT_CODE(KEYCODE_LSHIFT) PORT_CHAR(UCHAR_SHIFT_1)

PORT_BIT(0x02, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_NAME("Right Leap") PORT_CODE(KEYCODE_RALT)

PORT_BIT(0x04, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_NAME("Page") PORT_CODE(KEYCODE_PGUP) PORT_CODE(KEYCODE_PGDN)

PORT_BIT(0x08, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_NAME("Shift Lock") PORT_CODE(KEYCODE_CAPSLOCK)

PORT_BIT(0x10, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_NAME("Erase") PORT_CODE(KEYCODE_BACKSPACE)

PORT_BIT(0x20, IP_ACTIVE_LOW, IPT_UNUSED) // totally unused

PORT_BIT(0x40, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_NAME("UNDO") PORT_CODE(KEYCODE_BACKSLASH)

PORT_BIT(0x80, IP_ACTIVE_LOW, IPT_KEYBOARD) PORT_CODE(KEYCODE_TILDE) PORT_CHAR(0xB1) PORT_CHAR(0xB0) // PORT_CHAR('\\') PORT_CHAR('~')

```

So it looks like the "alt" keys are supposed to work as the LEAP keys. I tried this while running the emulator in a browser but maybe something "ate" them before they could get to the emulator? I guess the next logical step is to try running MAME properly on my laptop and see if the results are different.

That said, a close reading of this code reveals a lot of serious gaps in the emulation, essential things like disk I/O that will prevent me from using it until they are sorted. I'm tempted to try and fix/implement these things myself, but given the original authors familiarity with the subject I'm going to guess that adding any of the missing parts isn't going to be easy, and I need to consider the trade-offs of pursuing that path vs. alternatives. Remember, my original motivation for taking the emulation path was to save time.

The other thing that comes to mind as I read this code is that it might be easier (for me at least) to recreate the experience of these machines than it will be to learn enough about their internals and the internals of the emulators to piece-together a complete emulation. Since my objective isn't to create a "screen-accurate" replica, recreation is fine if not ideal for my purposes, but it raises a serious question: is it legal?

Building The Kitten around an emulation of The Cat is pretty straightforward from a legal perspective in that it's no more or less legal than the existing emulation. In most cases this is legal so long as the code (typically ROMs) are sourced legally. I don't know the legal status of the Cat's code, but if I built The Kitten out of readily-available emulation parts I'd at least know I'm not doing anything more illegal than what others have already done.

However, if I recreate it by writing my own version that legal status is less clear. IANAL but using things that are explicitly called-out as copyright, trademark, etc. in the manual like the term "LEAP" definitely raises some flags. I could be cute or clever and try to side-step this by renaming things, but I doubt that's a completely defensible thing legally and it would be doubly sad to resort to such chicanery and still get sued.

The ideal solution would be to figure out who, if anyone still holds these rights and get proper permission.

Of course all of this is predicated on me actually creating any of these things, so perhaps the best approach is to cross the legal bridge when I come to it. If I recreate the Swyft environment "from scratch" for my own personal use there's little chance of inviting litigation, and if by some chance it does, then at least I'll know who to talk to about getting permission to take it any further.

Jason J. Gullickson, 2026

The Machine Room

Tue, 23 Jun 2026 15:16:49 -0500

KGLMDPS is moving, and part of that move includes moving the 3D printers into an enclosed space (an office separate from the rest of the open area). This has me thinking about how I want to arrange things, and while I'll probably start by simply "lifting-and-shifting" the current setup, maybe it's time to think about how I can improve things based on the few months of practical experience we've had at the original location. Notably, the closed-off space allows for the potential of slightly more disruptive machines like my tiny CNC mill, so I want to consider expanding the robot army as a possibility.

Right now I have two 3D printers at the shop, both Elegoos, one OrangeStorm Giga and one Centauri Carbon. Minimally, I'm planning to add a second Carbon (maybe the Carbon 2?). I bought the first one as an experiment and it has earned it's keep over the last few months. The only issue I've had with the Carbon is that it's almost always busy, so a second machine seems like a rational choice.

I considered moving our small laser to this space, but it takes up a fair amount of horizontal room and it also requires ventilation. While I think this room has an outside wall, I don't think there's any windows and I'm not ready to start punching-holes in the brick exterior (at least not yet).

But the mill is a possibility, and bringing it into the mix creates some very cool possibilities. I've written before about my attempts to manufacture circuit boards at home using this mill, and while I still don't have a completely functional workflow for this, I think I'm pretty close. If I could throw another day or two at it, I could probably be able to reliably fabricate 2-layer boards which would be plenty for most of the things I design (especially if I take the leap into more surface-mount work).

I'm also interested in using the mill for more "traditional" things like milling parts that are hard to print (or out of materials I can't print with) and of course creating real wood type.

If I manage to pull that off, I could outfit one of the workbenches with some soldering/assembly equipment and I think I'd have everything I need to realize a lot of the devices I've designed over the years.

Of course this all requires a software "stack" to go along with all this hardware, and I've got a few tools that have worked so far with these printers and this mill, but if I really want to make the most out of the limited time I have to play at the shop I'll need to streamline all that a bit. Honestly I think the solution is a full-blown CAD/CAM system. Of course I use tools that could be classified as CAD but I've never really thought about the whole thing as a "system", and never really looked closely at CAM; but maybe it's time to do that?

I don't know yet if there's existing open-source CAM software or if it's all commercial or all bespoke, but I'll see what I can find. Maybe if it exists it's completely overkill for this application, but even so it wouldn't be the first time I've used industrial products at home. In addition to surveying what's available, I need to document what I really want and need to get out of such a system in order to evaluate the options. It might simply be the case that what I need is a custom implementation, which of course is something else I'm no stranger to.

But I do want to be careful not to loose track of the real objective: making things. To this end I should probably timebox the research and experimentation and maybe establish a few "checkpoints" where I can stop and use the system if and when I run out of time to play.

I also need to think about some "infrastructure" concerns, like the power supply (I assume this room only has access to a single circuit) and waste management (if the mill joins the mix, it makes a mess, especially if wood is involved). None of these seem overwhelming but still need to be considered.

Jason J. Gullickson, 2026

Could I make a Laserdisc Player?

Thu, 25 Jun 2026 05:57:22 -0500

I'm somewhat obsessed with Laserdiscs. As my collection grows so does my fear that my player will fall apart. I've already fixed it once, and I have two of the same model so I have some amount of spare parts, but eventually something unrecoverable will happen and I'll have to find a new one. The problem is: there's no new Laserdisc players.

This morning I woke-up thinking about what it would take to make a Laserdisc player myself. The electronics are certainly possible, it's the mechanical and optical part that is more tricky.

But is it really?

Historically the most expensive part of the Laserdisc player was the laser. This is evident in the lengths my "auto-reversing" player takes to play both sides of the disc automatically. Instead of having two "pickups", it employs gears and motors to move the pickup head from one side of the disc to the other. This makes a lot of racket and takes about 10 seconds. This is also the part of the machine that I had to fix.

Today lasers are incredibly cheap, and while I don't know off-hand exactly what the sensor side of the pickup is, it's hard to imagine it being any piece of electronics that couldn't be had for a few dollars. Perhaps there's some cost or complexity to the optics (lenses, mirrors, etc.) in the pickup head but regardless I can't imagine it's anything that would be so expensive at this time as to warrant the complexity of flipping the entire thing around vs. simply having two heads.

That leaves spinning the disc and scanning the head across it.

Laserdiscs use a few different physical methods of encoding video and data on a disc. The simplest (and coincidentally, highest-quality) is Constant Angular Velocity of CAV. In this mode the disc spins at a constant speed (1800RPM if I remember correctly) and the speed of the pickup head changes in step with the increasing or decreasing diameter of the portion of the disc being read. This mode allows lots of neat features and higher-quality video at the cost of requiring more "sides" to hold a complete film, so a movie that is entirely encoded in CAV will usually require two discs.

The alternative is Constant Linear Velocity (CLV) where the speed of the disc's rotation changes to compensate for the changing diameter of the disc. This mode (sometimes referred to as "Extended Play") makes it possible for most films to fit on a single disc, and if you have a player that can automatically "flip" the disc like mine, you don't have to manually intervene to watch an entire film.

To build a "transport" capable of playing CAV discs is, in my opinion simpler than building one to do CLV, and I prefer the CAV discs anyway (I'm not into Laserdisc for the convenience). Any practical player needs to support both, but I'm fine with the first iteration of my DIY Laserdisc Player only working with CAV.

I think I could build the CAV transport using the same sort of parts and techniques that I've used to build 3D printers. A spindle that spins the disc at a constant speed shouldn't need anything more than a way to clamp the disc to a wheel attached to a motor. It might be possible to use a standard stepper motor for this and use information from the pickup head to create a feedback loop to control the pulse rate to the motor to maintain the right speed, or it might just be simpler to use a beefy brushed/brushless DC motor with an encoder (like the setup I used for the "Blood Elevator" last Halloween). Once the disc is spinning, the pickup head needs to move above the surface in a straight line at a changing velocity, which can certainly be accomplished with a stepper motor and a linear axis akin to those in a 3D printer.

A frame to hold all this together will be needed but this, along with all the individual parts should be printable with a regular 3D printer (so long as it's large enough to print parts for a machine that handles 12" discs).

I think the part that requires the most work is the pickup. I'm going to do some reading to see how these have been made in the past and see what is the most reasonable way to realize one in a DIY context. Designing an optical pickup like this reminds me of something else a friend mentioned to me the other day: there are optical pickups for analog records now as well.

That's interesting.

If I could design a pickup that is capable of reading both Laserdisc "pits and lands" and vinyl record "grooves", the rest of the transport is virtually the same. An LP is essentially CAV encoded so the only real hardware change would be to design a flexible enough clamping mechanism for the drive spindle. Both LP's and Laserdiscs are the same size, so a player so designed could play both.

This is worth spending a little time on...

Jason J. Gullickson, 2026

Textmode

Thu, 25 Jun 2026 06:05:19 -0500

Lately my Framework laptop running ElementaryOS has been flaking-out, glitching in some way that causes the cursor to randomly move around in my editor (Micro) when I'm trying to write and doing other weird things like selecting menus and dragging things around when I'm using the GUI.

This morning when I was writing about the DIY Laserdisc player this caused me to loose a lot of work because while I was typing I wasn't looking at the screen and the glitch selected random blocks of text which were then erased and replaced with whatever I was typing next and all the while I was reflexively saving my work, ironically, destroying it.

I don't know if this is a hardware or a software problem, the complexity of both on this machine make it impossible to tell without lengthy chains of process-of-elimination and when I only have about 30 minutes a day to use my own brain, it's a shame to waste it on that.

But of course it's not a waste because as long as it's broken, I can't reliably do anything with the machine.

All of this heavily underscores the importance of replacing this setup with something simpler and more reliable. Such a replacement I spend a lot of time writing about (and even some time working on!), but there is a chicken-and-egg problem in having to use such an unreliable machine to complete this work.

Out of frustration with all this I remembered something from my early Linux days. When X11 flaked-out, or you just got sick of it you could easily flip over to the text-mode console using some key combination and X would go away and you'd be working directly with the "native" text interface of the PC. I assumed that this was something that had been taken-away in the effort to make Linux more usable, but as it turns out, it's still there even in something like ElementaryOS.

ctrl+alt+F4

In the old days, even without X11 alt + a function key would give you a new terminal. This was the primary way of doing more than one thing at a time before you could get X to work, and when X broke (as it frequently did back then) it was a way to get out, or switch to something more stable where you could work on getting X un-stuck.

This morning it's letting me work-around whatever the problem is with my laptop since there's no mouse or touchpad or touchscreen to get in the way.

It's a remarkably pleasant place to work, and provides a number of the things I want the computer I'm designing to provide. Of course it has none of the Swyfty things, but it's a step in the right direction, and provides a little shelter from the mess I normally have to deal with on this computer.

Just saying this sounds kind of stupid and obvious. No shit, a Linux computer has a textmode terminal, and if you use it, you avoid all the bullshit associated with "Desktop Environments", etc. Yes it's obvious once you're using it, but when you've spent years living in a prison you forget what the fresh air smells like, and sometimes that it exists at all.

Jason J. Gullickson, 2026

Epilogue

After writing this, I tried to return to the GUI and it didn't go as planned. I thought alt+F1 or alt+F2 would do it, but it was more like alt+F7 (I just kept trying things). Worse though was the fact that when I got there, everything that had been running when I left was gone. This isn't how I remember it working back in the day, where you could flip between X11 and the text console with all your programs still running. I'm not sure what changed, but it was disappointing and something I thought I should warn others about.

Swyft-Inspired?

Thu, 25 Jun 2026 07:03:40 -0500

Last weekend I tried a few times to use both SwyftCard and Canon Cat emulators and in both cases didn't have a lot of success. This could be attributed to my ignorance of the emulators involved, but it made me second-guess my assumption that emulation would be the "easy way" to get to a Swyft-like machine I could take on the road.

But emulation isn't turning out to be the shortcut I expected it to be. It was a reminder of why I like to do things the hard way, and got me thinking about what it would take to write something of my own instead. Not as ambitious as an entire new computer, but a piece of software that I could run on whatever computer that had the essential things I've learned to love about the Swyft machines. Aside from being a stop-gap measure between having nothing and something, it might serve as an alternative to using an emulator for The Kitten, and while not likely to be directly usable for something like The Beaver, could help me work-out some of the design and conceptual ideas that would carry-over to a more complete project like either of them.

Also, it would be fun; more fun than fighting with other people's code that doesn't quite work for me.

This doesn't solve the other problems with using a contemporary computer, but after being reminded of textmode, I'm thinking if nothing else I could boot up into that and use a program like the one I'm talking about now and eliminate a lot of the instability, distractions and other disruptions to work that are provided by the "Desktop Environment".

So what would something like this look like?

The obvious answer would be to simply copy the features of the SwyftCard environment that I've been using for the last few months, and in effect that might be what happens, but I think it's worthwhile to look a little deeper into what makes these features so powerful and useful on a daily basis. It is these *ideas* that are where the inspiration should come from not simply their literal interpretation into the hardware and software of the Apple //e + SwyftCard. Aside from missing the point, simply blindly copying these things is likely to bring both the good, intentional behavior along with the baggage that exists in the SwyftCard implementation that was due to the nature and limitations of the hardware available at the time.

The ideas that stand-out to me, really the central idea is that Swyft alters the traditional relationship between applications and data. Instead of having multiple programs or applications to serve specific purposes Swyft is essentially a single program that provides an handful of parts that can be used to realize the functionality of several different applications. Several is an understatement as several examples are provided in the documentation but any number of existing or new applications can be realized through the use of the Swyft software.

This is a little bit like Hypercard, or a spreadsheet, or a database like Microsoft Access or maybe even something like a Jupyter Notebook but much more open-ended because the provided components are far more general-purpose: text data, fast universal search, integrated I/O (including communications) and a simple, embedded programming language.

Out of these building blocks many applications can be made. The examples provided in the documentation include a notebook, a journal, an address book and mail merge. Applications I've realized include a recipe database, a todo list, a calendar/datebook and various financial and electrical simulations.

A Swyft-inspired environment that provided these four components would match the capability of the SwyftCard that I've been working with these last few months, and should be fairly realizable in a text-mode program written in any of the languages I regularly use. Of course the devil is always in the details.

To live-up to it's inspiration this program needs ensure that all of these features are fast and that accessing them can become reflexive. That means they have one way to be accessed and always work as expected. No modes or other surprises. They all need to be accessible from the keyboard as well (something amazing about working with the SwyftCard is how I never have to take my hands off the keys). Something else the above doesn't capture is how all of this is realized with very few "commands"; for example, saving and loading a text from disk uses the same key combination; this is only possible because the software is smart enough to know automatically which way the data should be flowing, making it virtually impossible to loose work. That level of intelligence requires putting a lot of thought into the design of the software and the way it will be used and is not a trivial task for the designer and programmer.

Something else that this short list of features glosses over is the subtle details of inputting and working with text using the SwyftCard. The cursor/insertion point, the ways that text can be selected and moved and other aspects of manipulating text differ from every "text editor" that I've used and they take some getting used to, but once you get the hang of it you don't want to go back. For example, cut, paste and delete are simplified into deletion and insertion. Selecting and deleting text always preserves the deleted text in a buffer, which can then be inserted anywhere eise. This eliminates both a key command mapping and a mental decision point while working and while it might not sound like much, removing any amount of friction from the creative process means more of your mind doing what it does best.

There's numerous things like this that sand-down the surface of the tool and let you move through the work with less effort than anything else I've worked with, and it's speed and reliability let you develop the trust necessary to let go and flow without constantly stopping to make sure it's safe.

This is getting longer than I expected... I think I've done an OK job of identifying the key components and providing some examples that help convey the experience I want to recreate. I'll try to sharpen some of the more loosely-defined things about the experience into descriptions that are precise enough to be implemented and then take a whack at some sort of prototype.

Jason J. Gullickson, 2026

Six posts in two days

Mon, 29 Jun 2026 06:33:24 -0500

I got a little behind this month so I'm going to have to catch-up over the next two days (today and tomorrow). I'll probably post a few half-baked drafts I have in the hopper, but maybe I'll have time for one or two fresh ones as well.

Jason J. Gullickson, 2026

Back In Time

Mon, 29 Jun 2026 06:53:38 -0500

Ever since I was a wee child I was fascinated with developing a handful of technologies. I've worked on these things on-and-off over the course of my life, sometimes professionally, but more often on my own.

Heartbreakingly, I've seen most of the co-opted by industry and evil men and twisted into things that not only fail to live up the standards I held my own work to, but become actively harmful. The most recent is of course Artificial Intelligence, but before that Virtual Reality befell a similar fate which leaves only one thing that I've worked on since childhood which has not yet (to the best of my knowledge) been taken over by evil men.

Time travel

The last time I worked actively on time travel was probably the first year of my short high school career. I remember it distinctly because I woke-up with my head on the table in the study hall that started an hour ago to the sound of the bell. The last thing I remember before falling asleep (really passing-out) was the sense that I was experiencing a breakthrough.

I never recovered exactly what that breakthrough was, but over the years I've pieced-together the things I was studying and working on that led up to that moment. I've also read a few books and papers and performed some though experiments but I've largely left the subject alone because other topics have kept me occupied and as we all know from science fiction, time travel is problematic.

But as I try to work on other things I'm surrounded on all sides by the necrotic realization of the tools I depend on. Everything involving a computer is becoming corrupted by AI slop, and the amount of things I can work on without a computer (or at least without relying on a contemporary computer) narrows to hobbies or other activities that so far I have not found a way to make a living with.

Computers may be involved in the work of time travel but they don't need to be the kind of computers we use every day. As you can imagine, much of the work involves custom hardware and while this includes computing capacity it is by it's nature easier to keep the botlickers away.

It's also a notoriously bad investment, doesn't scale and can't be mass-produced so it's quite repulsive to the types of people who have spoiled the other subjects that have captured my imagination since childhood.

So it feels like a safe space, and probably a hard enough problem (and set of sub-problems) to keep my occupied for the time I have left.

Since it is impossible to even begin to imagine how this work could support me and my family financially there's no distraction of trying to make that happen, and there's no justification of investing too much time or money into it because it's going to "pay off". The most likely outcome will be a body of knowledge on the subject that won't get realized within my lifetime. In other words, time well spent.

Jason J. Gullickson, 2226

Downlink 2026-06-29

Mon, 29 Jun 2026 07:23:40 -0500

Always an easy way to squeak-out one more post before the end of the month...

* https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Conditional_and_Iterator_Functions

* https://stackoverflow.com/questions/77737306/openscad-syntax-modify-value-in-vector-list-array

* https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/WIP/Text_Metrics#fontmetrics

* https://openscad.org/cheatsheet/

* https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/String_Functions#chr

* https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/User-Defined_Functions_and_Modules#Functions

* https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Customizer

* https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Vectors

* https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Transformations#rotate

* https://zig.guide/language-basics/integer-rules/

* https://codeberg.org/jjg?page=2&sort=recentupdate&q=&tab=repositories&language=

* https://grizzl-e.com/

* https://grizzl-e.com/products/grizzl-e-classic?v=variant_01GR8W84MV4EMXCF7FDC3GSX0K

* https://grizzl-e.com/products/grizzl-e-classic-connect?v=variant_01K77JZJ655SKAE1Q9NS4E5Y1P

* https://grizzl-e.com/collections/pcol_01GRK0KSNNGBQ3EP8BRAPBH4GD

* https://github.com/micro-editor/micro/blob/master/runtime/help/tutorial.md

* https://github.com/micro-editor/micro/blob/master/runtime/help/plugins.md

* https://github.com/priner/micro-aspell-plugin/blob/master/help/aspell.md

* https://github.com/micro-editor/micro/blob/master/runtime/help/copypaste.md

* https://hifibuys.com/optical-phono-cartridges-the-ultimate-analog-listening-experience/

* https://veilid.org/about-us/

* https://www.eff.org/nominate-next-eff-award-honoree-2026

* https://loriemerson.net/

* https://loriemerson.net/category/other-networks/

* https://insideevs.com/features/436525/grizzl-e-ev-home-charging-station-discount/

* https://duckduckgo.com/?q=no+one+is+free+until+we+are+all+free

* https://dn42.dev/Home

* https://en.wikipedia.org/wiki/Dn42

* https://www.themoviedb.org/search/movie?query=friday%20the%2013th

* https://github.com/jellyfin/jellyfin/issues/13656

* https://jellywatch.app/blog/jellyfin-metadata-fix-tmdb-nfo-artwork-guide-2026

* https://dokku.com/

* https://gokrazy.org/platforms/index.html

* https://en.wikipedia.org/wiki/Terra

* https://codeberg.org/jjg/printable-type/src/branch/main/typeset-generator.scad

* https://www.instructables.com/Table-Saw-for-Kids/

* https://www.lego.com/en-us/themes/speed-champions

* https://en.wikipedia.org/wiki/List_of_missions_to_Mars

* https://en.wikipedia.org/wiki/Titan_IIIE

* https://en.wikipedia.org/wiki/Helios_(spacecraft)

* https://www.diyelectriccar.com/threads/fiero-based-conversion-rebuild-underway.30722/

* https://openinverter.org/forum/viewtopic.php?p=70860#p70860

* https://www.marklines.com/en/report/rep1879_201906

* https://github.com/mamedev/mame/blob/master/src/mame/canon/cat.cpp

* https://en.wikipedia.org/wiki/MAME

* https://arstechnica.com/gadgets/2025/09/your-very-own-humane-interface-try-jef-raskins-ideas-at-home/

* https://archive.org/details/swyftware-a2r-woz

* https://archive.org/details/swyft-ware-swyft-card-user-manual-2nd-ed-apple-ii-1986

* https://github.com/linappleii/linapple/tree/master

* https://www.printables.com/model/1389388-statues-mega-pack-68-models/files

* https://gokilo.github.io/raw-input-and-output.html

* https://hackaday.com/2022/04/09/lora-powered-birdhouses-enable-wireless-networking-when-the-internets-down/

* https://github.com/brucemack/microlink

* https://cults3d.com/en/3d-model/art/blessed-virgin-mary-statue-3d-printable-religious-figurine-detailed-holy-mot-mrarundavis

* https://www.printables.com/model/1737816-mini-trophy-print-in-place

* https://www.printables.com/model/1761231-pill-dispenser-fridge-magnet-pokemon

* https://www.printables.com/model/1703739-cable-mount

* https://www.printables.com/model/927248-fan-folding-fan

* https://www.printables.com/model/738026-holy-virgin-mary-3d-scan-of-real-statue-reworked-a

Jason J. Gullickson, 2026

Learing at Work

Mon, 29 Jun 2026 07:54:05 -0500

I used to learn a lot at work.

One of the most expensive things about being forced to use AI is that I no longer do.

For decades I would learn new things and hone my existing skills during the thousands of hours I spent making other people rich. I got to keep these skills when I punched-out at the end of the day and use them to do the things I like. Now I spend my days coaxing, babysitting and correcting the output of a bullshit generator.

It's kind of devastating.

But things could be worse.

The experience has given me a lot of perspective. While my professional life has not always been easy, it's never been as harmful to myself or others as it is now. I know now what it feels like to have a job that ruins your body and your mind and damages your community and the world. I feel a kinship with the coal miner, the oil field worker, the defense contractor. I consider myself fortunate to have made it this far before finding myself in this situation.

It provides a level of motivation to find a way out far greater than I've ever felt before. Not just a way out for myself, but a way out for everyone.

Something I've been chewing on with Preston for quite some time is the idea of positive liberty and how it applies to the way I work, the way I live and the impact that I and the things I make have on the world. I've struggled to articulate these thoughts for a number of reasons but the biggest reason might be that they could be seen as a threat to institutions that I appreciate and have benefited from, and have helped many others.

But nothing lasts forever, especially in nature, and nature is my favorite teacher.

One of the ideas that has fallen out of these trains of thought is refereed to as FOSS+. FOSS+ is a positive liberty implementation of Free and Open Source Software. It's really more of a test than a process or recipe, and the simplest expression of the test is "It doesn't work until it works for everyone". FOSS+ builds on FOSS by doing what is necessary for everyone to use the freedoms that free software enables. Those of us who create free software have enjoyed these freedoms for decades, but they are often beyond the reach of people who are not themselves programmers or engineers or skilled in whatever specialty is needed to make, modify, extend and deploy free software. As with positive liberty, the + in FOSS+ is whatever it takes to allow everyone to utilize and enjoy these freedoms.

FOSS+ is a manifestation of the idea that "The truth is, no one of us can be free until everybody is free."

What this means in practice is much harder to define than the software license that defines regular FOSS. I'm not sure that something like a license or other document can really do it. I think that for something to achieve FOSS+ status is more of a process than compliance. As someone involved with establishing the standard I look at existing FOSS projects as a starting point (negative liberty being somewhat of a prerequisite for positive liberty) and then look at what those projects do to enable everyone to use the freedoms the project provides. I don't have any specific examples that I think achieve this, but that has as much to do with how hard I've looked as it does with whether or not they exist.

I think project-level granularity is probably the smallest level on which FOSS+ applies because it's hard to see how a single program or piece of code could achieve what FOSS+ requires. It's hard to see how a piece of software on it's own could enable anyone with any level of skill or experience or any amount of access to equipment, networks, etc. to utilize the freedom the software provides unless that freedom is incredibly small. Maybe such a thing could exist, but it's much easier to see how a project composed of people who want to work with the people who use the results of the project and enable them to utilize the freedoms this output can achieve FOSS+ status.

By now you've probably noticed that FOSS+ is about people more than anything else.

I think there's a lot to learn about how to create things that can honestly be labeled FOSS+, and maintaining that label is a continuous process. This is not easy, but I think it's what we need if we want to escape the trap that the current way we work with software has created. Free and Open Source Software has in many ways changed the world for the better, and it has allowed many of us to experience a level of freedom unimaginable in the time before FOSS was available. Many of us are old enough now to remember what those "before times" were like, and we do not want to go back. But the time has come to take the next step and do the work to allow everyone to enjoy the freedoms that have liberated us from the tyranny of proprietary software.

FOSS+ gives this work a name, and a label people can use to find it.

Jason J. Gullickson, 2026

Ribs

Tue, 30 Jun 2026 06:07:22 -0500

I made my first rack of pork ribs on the Pit Barrel last night for dinner. I've made country-style ribs many times with varying degrees of success, but I'd never tried "regular" ribs until last night.

As it turns out, they turned-out pretty good!

Using the basic recipe on the Pit Barrel site and the same rub I've put-together at home for the county-style ribs there's really not a lot to it. The process is much simpler than the one I've used for country-style ribs and amounts to little more than lighting the cooker, seasoning the meat and hanging it for a couple hours.

There's really only two things I plan to do differently next time:

1. Split the rack: the full rack was too long and was almost in the fire

2. Push the finish temp a little higher, maybe five degrees

I'm not sure why I waited so long to try making these. I think in my mind I had some idea that they were fancy or hard to make, probably based on having very few great experiences with them in restaurants. I've tried them many times but really can only remember having what I'd call "great" ribs twice, so I assumed it was difficult or expensive or both. I still have a long way to go to "great", but I thought for sure I'd have to work through some "terrible" before I'd have even "edible" results.

As it turns out, not only was it not hard to get good result it wasn't expensive either. I shouldn't have let my assumptions hold me back.

Next time, I won't wait so long to try something.

Jason J. Gullickson, 2026

Wine Cooler Part II

Tue, 30 Jun 2026 07:26:27 -0500

Continuation of the Wine Cooler saga.

The parts I needed for the wine fridge showed-up about a month ago, but I couldn't find time to work on it again until last weekend. Summer is not a great time to get things done that need to be done indoors.

Once I unpacked the parts (replacement power supply and four replacement fans) I had to get my bearings again as to how the thing goes together and comes apart. I wanted to take it a little more carefully this time and avoid having to repeat steps as well as avoid getting shocked.

As you'll recall from last time, the cooler's electronics consist of a power supply and a Peltier device sandwiched between two fans. There's two of these complete assemblies, one at each end and then a small control panel to set the thermostat, monitor the current temperature and turn the lights on and off.

I started by replacing the fans on the end with the bad power supply. I had left the machine disassembled with the bad supply removed and replacing the "hot side" fan was simple because it happens to use the same type of connector that the fan comes from the factory with.

Replacing the cold-side fan was a little more work. That fan connects to a pair of wires that goes back to the other side of the cooler and uses a different connector. I would have considered moving this connector to the new fan, but it had been exposed to water (I'm guessing condensation) and was severely corroded. I don't like making more work for the next person to work on this, but I decided to hardwire the fan in since the old connector is unusable and I didn't have anything suitable on-hand to replace it. I also think the hard-wired option might be more reliable given what this connection is exposed to (based on the condition of the original connector), and if someone in the future has to replace this fan, they would get stuck modifying the connection anyway.

Once the fans were replaced I installed the new power supply. The Peltier was hardwired to the original supply and I had desoldered these leads when I removed the failed supply but the new supply has blade connectors for the Peltier power so I rummaged round in the bins to find some crimp-on removable connectors to use with the blades. As luck would have it, I found the connectors but couldn't find my crimper. I'm pretty sure I gave it to Wes with the idea that I'd get myself a better one, but I apparently never got around to doing that. I was able to make-do with some blunt-nosed pliers, but I really need to pick-up another crimper before I forget.

The rest of the power supply install went off without a hitch other than having to refer to the other, working supply to double-check some connections (the power supply has more connectors than needed so I wanted to make sure I was using the right ones).

I powered-on the cooler to test my work and noticed the cold-side fan I just replaced wasn't turning. Since this was the fan I just hard-wired into the system the problem wasn't that I plugged it into the wrong place on the power supply or didn't seat the connector properly, and the cold-side fan on the other end was turning so it didn't appear to be a deliberate action on the part of the thermostat, etc. Time to take it apart again...

I cut the soldered connection out and measured the voltage going to the fan to make sure that there was some and that I had the polarity right. The polarity was correct, and there's voltage on the wires that go to this fan. Weirdly the voltage is 18VDC and change, which is notable because all the fans in this thing (original and replacements) are rated for 12VDC. I imagine there's enough margin designed into these fans that this isn't going to present any danger, but it may have been a contributing factor in the death of the original hot-side fan.

Next I reconnected the fan with some jumper wires to make sure it works before making a more permanent connection. The fan spun-up when power was applied so it appears to be working just fine. The only explanation I can come up with for the earlier failure is that my soldered connections were faulty. This is a surprise, but I see no other explanation.

This time I repeat the power-on test after each step, soldering one wire, testing, soldering the other wire, testing, heat-shrink one, test, etc. I work this way through completing the connection and the fan continues to operate as expected. Problem solved.

Lesson: test as you go

At this point I've spent a bit more time than I had planned due to the re-work and I'm considering my options. I bought four fans because I thought it was prudent to replace all four while I had the machine apart and the cost of two additional fans was marginal. Now that replacing the cold-side fan proved a nuisance and ate-up a lot of the time I had to work, I'm second-guessing replacing the fans on the end of the cooler that worked when it arrived. I decide to split the difference and replace the hot-side fan because it plugs directly into the power supply using the connector already installed on the fan but leave the old cold-side fan alone; this should leave me enough time to do some testing before I have to work on something else.

Now it was time to button-up the chassis enough to do a temperature-holding test and I realize that I've never seen this thing completely assembled (it came to me in pieces). I assumed there was a door on it but as it turns out there's not. Instead, there is a panel with eight wine bottle-sized holes. Bottles to be chilled are inserted into these holes and an elastic grommet of sorts seals the gaps to prevent air exchange between the cooler chamber and the environment. This is clever, but I don't have eight bottles of wine in the lab to plug these holes and while the grommet is somewhat self-sealing, it's far from air-tight and I assume that in normal use all eight holes need to be plugged with bottles.

The best idea I can come-up with is to lay some books over the holes and give it a shot. I popped a lab thermometer in the chamber so I could compare it's measurement with the readings on the LED display and see if the indicated temp is anywhere near the actual chamber temp.

I set the thermostat at 50F and monitored the cooler for about fifteen minutes. Starting with about 66F as measured by the cooler's thermostat (same as ambient temp), the temperature dropped about five degrees during the test period. During this period the cooler was drawing about 250 watts as measured by the Bluetti I use on the workbench to test AC-powered things. I left this run while I cleaned-up the workbench and it steadily declined until the display reached the set temp of 50F. At this point the current draw dropped to around 100 watts and for the most part stayed there.

Since I don't know much about chilling wine (I drink mostly reds) I texted Jim to see what they normally set the thermostat to on a cooler like this so I could test it under real-world conditions. He said he thought it went down to 47, which I took to mean "we run it as cold as it goes" so I cranked the thermostat down as far as it would go to see if it could hold this temp.

I was concerned about how thermal mass might impact the performance of the cooler and tried to find something more realistic to simulate a full set of wine bottles than my books simply blocking the holes. I realized that maybe bottled water would be closer so I popped eight bottles of water in the holes. These are not quite the right size and shape, and as such don't close off the holes as well as I'd like, but I figured it was better than nothing. With this configuration I left the cooler running overnight to see how it performed with the thermostat set to it's lowest setting of 47F.

I occasionally checked the Bluetti to see how many watts the cooler was drawing as a way to see if it hit the set temp without having to run down to the lab (figuring the current draw would drop to around 100W once set temp was achieved). Every time I checked it was still drawing around 250W.

The next day I went down to the lab to do something else and peeked-in on the cooler. It was making an unusual noise, and I could tell it was coming from the cold-side fan that I didn't replace. When I pulled the bottles and cover off I could see the cold-side of the Peltier heat sink was completely iced-up! The ice was interfering with the fan blades which is what was creating the new noise. I unplugged the cooler and left it to defrost.

I'm very curious as to why the Peltier with the cold-side fan I didn't replace iced-up but the other side didn't. I'm also surprised that the Peltiers are capable of getting cold enough to ice-up at all. The cooler does have a drain path and sort of spigot for draining liquid from the chamber so I assume that this sort of condensation is expected, but from everything I've seen so far I don't think there's any provisions for automatic defrosting (although with the right power supply it's easy to imagine how this might work, as reversing the polarity of a Peltier reverses the flow of heat). I think it's safe to assume that this sort of freezing-up isn't normal, although if it had happened in the past that would explain the corrosion I noticed on the cold-side fan connector.

As much as I want to answer all those questions I think the most obvious thing this points to is that I should replace the last original fan. That is the only difference I'm aware of between the two ends of the cooler, and it seems reasonable that a performance difference between the two cold-side fans might cause one side to exhibit a different behavior than the other. Plus, it's just the right thing to do and the only reason I didn't do it was because I was in a hurry.

Lesson: take time to do it right

I'm not sure if replacing the last fan will solve the "icing problem" or not, and my guess is that the poor air seal of the water bottles is a contributing factor. That said, I'm going to try to replace that fan and run another extended test before I return the cooler just to see what happens.

While the test results are mixed I think it's safe to say that the repair itself is complete. There's a lot of things I'd love to improve while I have the cooler but at some point I have to choose to stop or it will never be done. I've had this thing for a couple months now and while I've only spent a few hours working on it, it has a job to do and even though I'm sure I could improve it further, it's probably good enough to go back to work.

Jason J. Gullickson, 2026

The Month of Zig - Conclusion

Tue, 30 Jun 2026 15:03:24 -0500

I'm tempted to call the MoZ a failure, but even though I didn't successfully create any new programs, I learned a few things and learning is always a valid outcome.

The main thing I learned was: I don't like writing programs in Zig. I really want to support the Zig developers stance against AI contributions to the language, and maybe I should send them a few bucks, but compared to other languages I work in I just didn't find Zig to be very much fun.

I tried to chalk that up to familiarity but that didn't compute when compared to other languages I came to completely green (Go, Forth, etc.) and still enjoyed working with. I'm still basically hopeless at Forth but every time I have a chance to play with it, I have a good time.

This isn't Zig's problem. I'm sure some people love it for the same reasons some people hate the languages I enjoy working in. It's essentially a matter of taste, and outside of professional environments that's a fine reason to make a language choice.

It's a bummer because there are things I conceptually like about the way Zig works, and I was especially stoked about built-in SIMD support, but that excitement wasn't enough to overcome the drag of how it feels to me to work with it.

I stayed the course pretty well the first couple weeks of June, but after about the third week I found it very hard to invest an hour a day in the language. I still did it, but I spent more and more time sifting through unofficial documentation and such to figure out why things didn't work the way they were explained in the various guides I was following. I will admit that I had a number of unpleasant interactions with existing Zig programmers which didn't help.

On the upside I learned a lot about what I *do* like in a programming language and especially the impact the people who use the language have on someone interested in learning how to use it.

I look forward to applying all of this to my own projects going forward.

So while I'm not planning to port any of my projects to Zig, and probably won't start any new projects in it anytime soon, the exercise was very worthwhile and gave me a lot of ideas about what I want to do next and especially *how* I want to do it.

Jason J. Gullickson, 2026

Over the Sea

Wed, 01 Jul 2026 06:12:26 -0500

"In every revolution, there's one man with a vision!"

Information Society, 1988

Fresh

Wed, 01 Jul 2026 07:06:23 -0500

I used to format and re-install the operating system on my laptops frequently. Way back when I ran Classic MacOS or Windows this was at least four times a year, then when I started using Linux it became less frequent, but I did a fresh install at least once or twice a year and most of the time I experimented with different Linux distros. As operating systems became more reliable I got out of this habit.

After struggling with a number of things in ElementaryOS recently I'm going to revisit this hygiene and install something else on my laptop. I'm not exactly sure what I'm going to land on, but there's a few things I want to try.

I'm going to give HaikuOS another shot. I can't remember if I ever tried to run it on the Rework, so maybe it won't "work", but since it's easy to test from a USB flash drive I'll give that a shot first.

If that doesn't pan-out I'm going to try a stock Debian install. I use Debian on a lot of my server projects so it's familiar, and I'm fairly confident that I can manage it well enough to customize it into whatever I want. The only real question is whether or not I'm going to run into issues with non-open drivers for the Rework's hardware.

If that doesn't go my way I might try KDE Neon. I used Neon for years when I was allowed to install Linux on my work laptops and I like it in general. I don't like what Ubuntu has become (never really loved it in the first place) and since Neon is built on Ubuntu I'm worried about some friction there, but it's another one that is easy enough to test-drive so it's on the list.

I'm wondering what other operating systems I might try. My application requirements are fairly simple, the essentials being:

* Librewolf

* OrcaSlicer

* OpenSCAD

* Signal

* LibreOffice

* Micro

* Golang

* Git

* rsync

* An email client

I could probably forgo some of these for my laptop and use them on dedicated machines or elsewhere if needed.

I'm certainly not opposed to trying something unusual, and I'm seriously interested in looking at alternatives to Linux (MacOS and Windows need not apply).

Jason J. Gullickson, 2026

Nowhere To Go But Up

Sat, 04 Jul 2026 11:42:25 +0000

I've been meticulously rebuilding my laptop over the last few days, installing only a handful of pieces of software. I was really heartbroken to find that one of my favorite pieces of open-source software, one that I depend on almost daily, has become infected with the AI virus.

It's become clear to me that at this point, any corporate or otherwise closed piece of software must be assumed to contain AI slop but the sadder and more surprising realization is that the same is true for open source software as well. Any open source project that doesn't boldly claim to be AI-free in the project description is likely to contain AI-written code as well as AI features.

This left me distraught for a few days, but this morning I'm starting to sort things out.

First, I'm not going to escape using and depending on things that use AI today, tomorrow and probably not for awhile. If keeping it out of my tiny list of software necessities isn't possible, what hope is there? Even Linux itself is falling into this trap, so there's no obvious, immediate way out through the existing open-source ecosystem.

Until I can resolve my dependency on these things, I'm going to have to find a way to accept them. That doesn't mean giving-up or becoming complacent, it's just means that this is the way it is until I can do something about it.

I've thought of two things I can do about it.

In the short-term, it's possible to utilize the openness of open-source to go back in time to a point before this nightmare began. It is possible to fork the open-source projects I depend on at a point in time before they became tainted. It's not easy to tell exactly when this happened so I'm going to do a little homework on when LLM-generated code became a thing and then fork all the projects I need on the same date. This means I'll be running "out of date" code and that's fine, right now my favorite computer is from 1983 and runs "software" (firmware?) from 1985.

The long-term solution is to depend on things that are made by people I trust. That trust includes a commitment to making the things themselves which by nature excludes the use of AI. Surprisingly I only know a couple of people like this, at least in the software development space. Effectively this means I'm doing it alone for now, but I'm hopeful that there will be others who want to join me soon.

It's very hard to let-go of the feeling that all of this is unnecessary, that it could easily be avoided. It's really a blow to my respect for open-source software that so many projects have taken this path. Anyone who bothers to look can see that AI (and especially LLM's) is a fundamentally and irredeemably fascist technology and once you have this knowledge continuing to use it can be interpreted as nothing other than being complicit with fascism. I can't believe that some of the developers I've grown to love and respect are fascists, so I can only hope that they have been keeping themselves in the dark.

The good news is that there are at least two paths forward, and I think both are complimentary. The result will be a big step forward, one that we've needed to take for awhile.

Jason J. Gullickson, 2026

KGLMDPS: The Move

Sat, 4 Jul 2026 07:28:53 -0500

Letting The Work Do The Work

Sun, 05 Jul 2026 12:27:35 +0000

I've thought a lot about yesterday's post over the last 24 hours and realized a few things. One is that focusing on this problem, the slopocalypse if you will, is making it impossible for me to make any progress on the things that I want to be working on, the things I need to do to find a way out of the coercive way of life that forces me to use AI in the first place.

There's a lot of things that I want to work on that people seem to want and that can contribute to a brighter future. A subset of these things are, by their nature, projects I can pursue that are not squarely in the cross-hairs of the AI industry. They don't need to integrate into "ecosystems" where the AI Industry is unavoidable. These are what I should be focusing on.

It means biting the bullet and depending on tools I can't trust, tools that are likely already infected by AI slop and maintained by people who don't yet understand (or care) about what this means to the world or even their own work. I will try to help them when I can, but if I keep using all of my free time for this I'll never make any of the tools that can be used to break the dependence on the willfully ignorant or just plain evil people that so many of us are currently under the boot of.

It's hard for me to let this go, and it's going to take daily discipline to do so. It feels wrong even writing it, but right now it's consuming me and while some progress is being made, I don't think how I've been doing this so far will be sustainable for much longer.

I've also realized that I hold myself to standards that are probably not healthy. I'm not trying to rationalize giving-up on things that matter, I'm recognizing my limits as a single human. I'm writing this post as much as a reminder to me as anything else: make things first and let the things change minds.

Jason J. Gullickson, 2026

Power Games

Mon, 06 Jul 2026 15:35:57 +0000

I have some time to myself this morning as electricians upgrade the service at the house. This had me thinking about off-grid power and I spent a couple hours diving deep into making something convenient and durable for monitoring, controlling and integrating various power supplies and consumers. I was focused on Bluetti, because that's what I have to play with and really rooting-around in the Bluetooth Low Energy (BLE) interface.

At first it looked promising. Building off the Python-based setup I experimented with earlier and some Go-based BLE experiments this morning, I was hopeful that I might be able to pull something together and started digging back into the repositories and forum posts where I found the original Python implementation.

There was a lot more info since the last time I visited the forum and it looked like development was increasingly active, so I jumped to the last page of the thread to see what's happening now. When I got there, I learned two things that really took the wind out of my sails.

The first was that there was a cloud outage that impacted the Bluetti devices, and the company didn't come-clean about it for awhile. I don't know the total impact of the outage, but it was a reminder that relying on the cloud for critical systems like this is a mistake.

More disconcerting was learning that newer Bluetti devices appear to be encrypting the data they send over BLE, making it impossible to monitor or control the devices without using the apps and cloud software that Bluetti provides. I'm sure the justification for this is "security", but given that any phone with the app in range of the device can control it, encrypting the packets doesn't really provide any additional security at that point.

So my idea of making a tool that could be used to integrate these devices with other things like Home Assistant (and ideally, other solar, battery, inverter, etc. devices) in a heterogeneous way is essentially dead due to this.

I'm not particularly frustrated by this because while it's a bummer, it just reminds me of the risks of being dependent on things you have no control over. I'm trying to be more accepting of the fact that I can't do everything myself, but I guess that has to be a dynamic negotiation. Something like backup power isn't really something I can just roll-over and compromise on, especially when it means that it might not work when the "internet is down". Maybe some things are so critical that it's not unreasonable to do them ourselves.

This isn't the first time I've considered designing such things myself and it's certainly something that more and more people are becoming interested in. There may still be an incremental path forward, perhaps making a modification for an existing product? I'm going to explore this option a bit, but I'll keep "doing it from scratch" in my back pocket just in case.

Jason J. Gullickson, 2026

Juicy

Tue, 7 Jul 2026 07:44:30 -0500

Bugs

Wed, 08 Jul 2026 11:53:00 +0000

If you're subscribed to the feed (or visited the index) you may have noticed some anomalies over the last day or so. Those are bugs.

It's a good reminder that I need to re-write Preposter.us in something that is maintained, and then maintain it.

With any luck wrestling with this will provide the motivation I need to do just that.

Jason J. Gullickson, 2026

Grizz

Thu, 09 Jul 2026 14:48:27 +0000

I spent a lot of time deciding what L2 charging station to buy for the EV9. I thought my requirements were pretty basic:

* Tough enough to live outside through Wisconsin winters (getting easier every year)

* NACS connector for the vehicle

* Plug-in (so if it breaks I can swap it out without cutting the power)

* 40A or more

* Doesn't require the Internet to work

I thought I could take advantage of our utility companies offers to get a discount but they offer a limited selection and of the two that met my requirements, neither was in stock. On the up-side, I had a lot more devices to choose from, even if I was going to have to pay full price.

I decided to go with Grizzl-E, and after using it for about a week, I'm very satisfied with this choice.

As you can see, physically you couldn't get much simpler. It is a sturdy metal box with one indicator. It comes from Canada so while I'll have to wait a few months to see how it holds-up in the winter myself, I'm pretty confident that anything which can endure Canada's winters will do fine here.

I was planning to get the non-connected "Classic", but they don't offer it with a NACA connector. Since I don't want to have to deal with an adapter at my own charger I bit the bullet and went with the "Classic Connect", figuring that if I don't want to deal with the "Connect" part I could just refuse to give it access to the network.

Installing the charger was straightforward and configuring it for charging was simple. All the necessary hardware was included and the hardest part was deciding on exactly where to put it. Once it was on the wall the electrical task amounted to plugging it into the outlet we had installed as part of a larger service upgrade. Configuring the device for charging amounts to unscrewing four hex bolts and setting a DIP switch to set the maximum charging current.

That's all you need to do to start using the charger, and it works great this way.

Of course I got curious about the "connected" part so I worked-through the process of getting it on the network and used the provided app for monitoring. The app is surprisingly simple and easy to use, but you want to play with it when it's OK to interrupt charging because some actions will do that.

This got me wondering if anyone has experimented with connecting this to Home Assistant, and sure enough, someone has. I can't use their integration due to limitations of how I have HA setup (that's a whole 'nother post) but I did learn that it's trivial to get data out of the charger, and you can do it using curl.

curl -sS -X POST -H 'Authorization: Basic '"$(printf %s '<username>:<password>' | base64)" http://<EVSE_IP>/main

Not only does this give you data, it's a nice JSON structure that is easy to parse instead of some proprietary thing stuffed with crud you need to ignore/discard!

{

"verFWMain": "GRS077L-01.07.1 ",

"verFWWifi": "USGRW070L-03.15.3",

"serialNumCPU": "",

"serialNum": "redacted",

"stationId": "redacted",

"fwCRC32": "14DACCDC",

"broadcastMode": 1,

"switchState": 14,

"verFWStatus": 1,

"pilot": 0,

"state": 2,

"subState": 9,

"currentSet": 40,

"curDesign": 40,

"minCurrent": 7,

"minVoltage": 175,

"gridRange": 0,

"typeEvse": 1,

"typeRelay": 0,

"aiModecurrent": 7,

"aiStatus": 0,

"aiVoltage": 200,

"aiVoltageStart": 0,

"aiVoltageDrop": 0,

"aiPowerDrop": 0,

"SNflag": 0,

"ground": 1,

"groundCtrl": 1,

"tarif": 100,

"activeTarif": 0,

"tarifAEnable": 0,

"tarifBEnable": 0,

"tarifAValue": 100,

"tarifBValue": 100,

"tarifAStart": 0,

"tarifAStop": 0,

"tarifBStart": 0,

"tarifBStop": 0,

"timerType": 0,

"timeZone": 0,

"systemTime": 1783605937,

"timeMsg": 0,

"timeLimitS": 0,

"energyLimitS": 0,

"moneyLimitS": 0,

"evseEnabled": 0,

"suspendErrors": 0,

"suspendLimits": 0,

"oneCharge": 0,

"delayedLimit": 0,

"timeLimit": 0,

"energyLimit": 0,

"moneyLimit": 0,

"sh1Enabled": 0,

"sh1Start": 0,

"sh1Stop": 0,

"sh1CurrentEnable": 0,

"sh1CurrentValue": 12,

"sh1EnergyEnable": 0,

"sh1EnergyValue": 0,

"sh2Enabled": 0,

"sh2Start": 0,

"sh2Stop": 0,

"sh2CurrentEnable": 0,

"sh2CurrentValue": 12,

"sh2EnergyEnable": 0,

"sh2EnergyValue": 0,

"totalEnergy": 25.346000671386719,

"sessionTime": 36528,

"sessionEnergy": 11.772000312805176,

"sessionMoney": 11.7790002822876,

"sessionStarted": 0,

"IEM1": 25.346000671386719,

"IEM2": 25.346000671386719,

"IEM1_money": 25.3390007019043,

"IEM2_money": 25.3390007019043,

"curMeas1": 0,

"curMeas2": 0,

"curMeas3": 0,

"voltMeas1": 249,

"voltMeas2": 0,

"voltMeas3": 0,

"powerMeas": 0,

"temperature1": 23,

"temperature2": 23,

"leakValue": 18,

"leakValueH": 15,

"vBat": 3.0799999237060547,

"adapter": 255,

"scanComplete": 0,

"lang": 1,

"ocppConnected": 1,

"ocppEnabled": 1,

"ocppVendor": 1,

"ocppOfflineAva": 1,

"thirdPartyBackends": 1,

"STA_IP_Addres": "192.168.68.73",

"RSSI": -61,

"model": "GRC 40A 2025"

}

I was very hesitant to get a charger with any "cleverness" because I didn't want to rely on it and I definitely didn't want to be locked-in to using some cloud/app/etc. to charge the car. If they offered the "Classic" with a NACA connector I probably would still have gone that way, but it's pretty awesome that they make it this easy to interface with the unit, and with a little more digging I'm sure I could control it as well.

Jason J. Gullickson, 2026