Summer 2026 season updates

I am looking out of the window of my hotel room. The sun is setting earlier by the day, which means that summer is slowly preparing to give way to a new season. But it is still very hot. This year, a heatwave hit most of Europe, with unusual temperatures in London and even in Innsbruck, where it reached 37°C, something I don’t remember ever happening there. Milan was hot too. Temperatures went well above 40°C, which was unusual, but somehow in Italy we’re more prepared for it, with air conditioning.

It’s peaceful in the walled lorry park. August is traditionally a quiet month in France and Italy. It feels like the world stops.

A few melancholic thoughts are pulling me westbound.

A few weeks ago, I went back to some of my past articles. Now that I’m on the move again, I understand a little better why, in the past, I ended up relying on services like Dropbox or Office 365 and getting rid of most of my own systems. I will not go back to proprietary services like those, and I will keep my colocation, but I now remember how exhausting this kind of life can be, and how little space it leaves for anything else.

Unfortunately, I seldom use my workstation at home now. The days when I dreamed of a workstation in a wooden cabin in the mountains feel far away. I’ve also been reminded that you cannot always rely on online applications and services, whether it’s an LLM or even watching a video on YouTube. Hotel Wi-Fi is sometimes barely enough to download a few emails, and in some rooms the coverage is so poor that you need to move the computer closer to the entrance door, or even go downstairs to the breakfast area. You can’t comfortably use web applications while standing next to the door, can you?

Looking back, though, I somehow managed to get quite a lot done this season, perhaps thanks to some stretches of quiet time in hotel rooms or other spaces. Some were little discoveries. Others turned into much larger projects.

Let me go through some of the things I was able to achieve.

Following the lineage

First and foremost, if you follow this blog you might already know that I recently published an essay about Cobolito/400. The project grew out of the research I had already been doing for Project Quiet Ground since winter, following the lineage of data-oriented systems and trying to understand what I liked so much about them.

Early this year, while going through old IBM material, I stumbled across a brochure for the IBM 5280 Distributed Data System. It immediately caught my attention. I started digging through manuals and documentation, and the more I read, the more I saw connections between the 5280, the wider IBM midrange world, and many of the ideas I had already been exploring around records, data contracts, local operation, and understandable systems.

Eventually, I decided to pay tribute to it by building my own small appliance inspired by those ideas: Cobolito/400, together with CrumbStation. The prototype was essentially complete by the end of June. I then spent the rest of June and most of July turning the research, experiments, and implementation notes into an essay which somehow grew to almost 90 pages.

It was a lot of work, spanning several months, but I enjoyed all of it. More importantly, it gave me another perspective on data and helped me connect many things I had liked for years without quite seeing them as part of the same picture.

If you haven’t had the chance to see the blog post and the essay, you can find them here.

While working on Cobolito/400, I came across an old tool called mtools. It provides a simple way to interact with floppy disks and copy files in and out without going through the usual Unix mounting rituals.

What surprised me was that it works with USB drives too. After adopting it for Cobolito/400, it quickly became one of my favourite ways to move small files around, and I now use it with my PursePC and the Hermit project as well.

A small discovery, but a surprisingly useful one.

Moving things around

I mentioned in my previous season update that I was planning to move both my backup storage and my shell box VM.

For the backup, I was initially considering Infomaniak’s S3-compatible object storage. It turned out that I already had a simpler and more economical solution under my nose. My Nextcloud system is connected to my colocation through a mesh VPN, so I could use SFTP directly to my main storage system instead.

Inspired in part by rsync.net, I automated the creation of jailed SFTP users and their directories with Ansible, then created a dedicated account for the Nextcloud backup. After testing the connection, I used restic to copy the existing repository from S3 to the new SFTP target. It took a while, as the repository is approximately 2.5 TB.

Once I had checked that both repositories were consistent, I switched the backup script to the new target. The first monthly backup completed without any problems. I am still keeping the old repository for a little while longer, though. I would rather see a couple more successful backups before deleting the previous copy.

I never mentioned it before, but the S3 provider I was using was Wasabi. I have been very happy with them: the service has been reliable, reasonably priced, and refreshingly uncomplicated. If US ownership and jurisdiction are not a concern for you, I can recommend Wasabi without hesitation.

In my case, the move was not prompted by any problem with the service. It was simply part of my broader decision to reduce my dependence on US-based infrastructure wherever it makes practical sense.

For the remaining VM, I ended up using Infomaniak. I was initially planning to move my emergency shell box from DigitalOcean to Hetzner, which is still a provider I like very much. But while looking at alternatives, I discovered that Infomaniak’s compute cloud is based on OpenStack.

That immediately caught my attention. After more than a decade of architecting and deploying OpenStack environments, a lot of old muscle memory came back rather quickly.

There was another reason too: portability. I have always disliked vendor lock-in, whether it applies to data or to the systems running it. Hetzner is a very good provider and even lets you upload an ISO and boot from it, which gives you plenty of options for restoring a system. What it does not provide, like many cloud providers, is a particularly clean way to export an existing VM.

OpenStack gives me a much nicer path in and out. I can snapshot a VM, turn the snapshot into an image, and download that image as a backup or move it elsewhere using the same familiar APIs.

DigitalOcean has the same limitation when it comes to exporting a VM, so I had to fall back to the wonderfully sophisticated technique of dd. Once I had the raw image, I used the usual virt-tools to adjust a few things, notably the network configuration, and converted it to qcow2 to make the upload smaller.

From there, the OpenStack CLI made the rest pleasantly familiar: upload the image, create a volume from it, and boot a new instance from that volume. The whole migration took less than a day and a few cups of coffee, not that I particularly objected to that part. Most of the time was spent waiting for things to copy rather than doing actual work.

I have already changed the DNS and I’m using the new VM. I’m increasingly pleasantly surprised by Infomaniak. Unlike Hetzner’s very clear monthly pricing, however, the compute costs require a little more calculation, so I’m keeping the old DigitalOcean VM for the moment. I want to see the first bill and make sure my calculations match reality before deleting it.

The major steps are done now. As with any migration, what remains is mostly waiting, observing, and giving the new setup enough time before calling it stable.

Once that is done, I will have completed the move away from US-based infrastructure providers, while also ending up with a VM that is considerably easier to take with me if I ever decide to move again.

Down the storage rabbit hole

Another substantial piece of work this season started almost by accident. While looking for possible alternatives to MinIO, I built a small FreeBSD lab to evaluate VersityGW, GarageHQ and SeaweedFS for a few different use cases.

VersityGW and GarageHQ behaved more or less like the kind of systems I expected to find. SeaweedFS did not.

What started as a simple S3 test quickly turned into a much deeper rabbit hole. I separated its different roles, wrote FreeBSD service scripts for them, and eventually built a reproducible three-node Vagrant lab so that I could explore the architecture properly. Then I started seeing volume-allocation behaviour that I could not explain from the documentation alone.

And who am I to say no to a rabbit hole?

After several days of experiments, changing parameters and rebuilding the lab, I eventually ended up reading the SeaweedFS source code to understand what it was actually doing. That finally made the pieces click into place and gave me a much better idea of where I would use SeaweedFS, where I would be more cautious, and where I would choose something else.

I originally thought the repository with the FreeBSD scripts, Vagrant lab and Ansible provisioning would be the end of it. Some time later, when I had enough headspace to go back through my notes, it unexpectedly turned into another blog post.

If you want to follow the white rabbit, you can find it here.

Spoiler alert: SeaweedFS never stood a chance of remaining “just a simple S3 server” once it landed on my desk. I was always going to take the casing off and ask where it kept the quorum.

One small field note from that comparison: VersityGW also left me with a reservation. Like MinIO, it can expose S3 buckets and objects while storing the data underneath as ordinary directories and files, which is an approach I find quite appealing.

What made me less comfortable was its local user database. The users and their S3 secret keys are kept together in a single JSON file, in plain text. Of course, an S3 implementation needs access to the credential material somehow in order to authenticate requests, so the existence of recoverable secrets is not surprising in itself. Other systems simply keep them in less obvious places. GarageHQ, for example, takes a different approach.

Having all of them collected in one easily accessible plaintext file still makes me a little uncomfortable, though.

I opened an issue to raise the concern.

Things that happened along the way

One of the smaller pieces that quietly fed into that same body of research around the IBM 5280 and Cobolito/400 was getting COBOL to talk to SQLite through GixSQL. I also managed to make GixSQL work on FreeBSD, although “porting” would probably be too generous a word. It was closer to hammering it until it worked.

That turned out to be more painful than expected. Practical documentation around GixSQL is rather sparse, so it took a fair amount of archaeology through old forum posts, source code, examples and build files before I had a working path.

Once I did, I decided to publish a few small examples in a Git repository: one SELECT, one INSERT, a tiny SQLite schema, a Makefile, and some notes about the less obvious parts. Nothing ambitious, just a trace of the path that worked in case it saves somebody else the same archaeology.

More in this blog post.

Last but not least, a VeraCrypt bug on FreeBSD that I had been following has finally been resolved.

It took a while, although the maintainer understandably had rather bigger fires to deal with, including the recent Microsoft signing-key issue that disrupted VeraCrypt’s Windows updates.

One of the things I still appreciate about open source is that a bug which has been properly reported, reproduced and confirmed can eventually find its way to a fix, even if it takes some time.

Merci beaucoup, Idrassi.

One more thing :)

I experimented with XMODEM file transfers over SSH. Why? Wouldn’t SFTP be better?

Of course it would. SFTP is faster and much more efficient. But I was interested in something slightly different: a simple, transport-independent way of handing data to a backend.

Imagine an offline device collecting data, as Cobolito/400 does in a COBOL line-sequential file. Eventually you want to send that file somewhere for processing. With scp, you need to know where to copy it, then log in and trigger the import yourself.

I wanted something closer to the old BBS and QWK workflow: upload a known file through whatever transport is available, whether over a network connection, a serial link or even a radio modem, and let the receiving side take care of what happens next.

It would be terribly inefficient for large files, but for a small text file uploaded through a menu and immediately handed to an import job, it is more than enough.

Perhaps useless on its own. But these little experiments have a habit of becoming building blocks later.

At this point, you probably know I’m quite obsessed with offline devices. Yes, I know I already have the PursePC. But I couldn’t resist a bargain.

I ended up ordering a Cardputer Zero. It is much smaller than the PursePC, closer to something I could pull out of a pocket, collect or handle a little data, and put away again.

I am curious to see whether I can build something in the same general spirit as Cobolito/400 around it: a tiny offline device for simple data collection rather than a miniature general-purpose computer.

The form factor was right, and I happened to catch it at a very early price, so that was enough to push me over the edge.

If everything goes according to plan, it should arrive in November.

On a more personal note

Nothing has changed in my chest since my last update.

I won’t sugarcoat it. I am exhausted, physically and mentally. Only while looking back at this post did I realise how many things I had actually done since returning to a more nomadic life. Bringing an old language that had been dormant for decades back into professional use is yet another strain on my already depleted brain.

Mx Liebe is looking at me from the bedside table, reminding me that it is time to rest.
Demain est un nouveau jour et on va travailler.

I’m taking it day by day.

Du fehlst mir so sehr.

See you at the next season. 🌷💜