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