Emile (ツ)

Independent IT advice for good causes

Sat, 30 May 2026 11:45:00 +0200

Through Digitaalgoed.nl I’m helping build an initiative that gives charities and non-profits independent IT advice, funded without reseller margins or vendor commitments.

Charities often overpay for IT or sign restrictive contracts because they lack the budget and in-house expertise to evaluate the options. The advice covers software, infrastructure, and digital strategy, translating the technical trade-offs into terms a board can decide on. Money a charity saves on IT can go to its mission.

More here: Setting up IT advice for charities via Digitaalgoed.nl.

Copilot vs Claude vs ChatGPT, without the hype

Thu, 28 May 2026 16:20:00 +0200

I evaluated Copilot, Claude, and ChatGPT for Aan de Stegge (ASVB) and wrote a vendor-neutral report recommending which tool to use for which tasks.

I scored each tool on quality, security, privacy, cost, and ease of use, testing them on real tasks from the organization’s daily work. The report documents where each tool sends data, its compliance status, and its cost at full rollout.

No single assistant scored best across all criteria, so the report assigns different tools to different jobs.

The case: Evaluating Copilot, Claude and ChatGPT for Aan de Stegge.

Teaching a construction company to actually use Copilot

Tue, 26 May 2026 14:00:00 +0200

At Lithos I ran hands-on workshops that taught employees how to use Copilot and AI assistants on their own projects, including prompt design, output review, and model limitations.

I assessed each role’s workflows to find where AI could save time, then built a role-specific curriculum around those tasks. We also set guidelines for handling sensitive data, so employees know what not to paste into a hosted model.

After the program, employees use Copilot independently and review its output for quality and security.

Full write-up: Training program for Lithos employees on Copilot.

When a fix at one company becomes a group-wide rollout

Tue, 19 May 2026 10:15:00 +0200

I’m rolling out the tender process I built at Lithos across all the construction companies in the Aan de Stegge group (ASVB).

Scaling the process means turning the Lithos workflow into a blueprint other companies can adopt while keeping their own local practices. The rollout standardizes the steps that improved results at Lithos and leaves company-specific details configurable.

Most of the effort goes into coaching teams through the change, the step that determines whether a new process is actually used.

More on the group-wide rollout here: Rolling out tender processes group-wide at Aan de Stegge (ASVB).

Untangling the tender process in construction

Tue, 12 May 2026 09:30:00 +0200

At Lithos I mapped the tender process to find where the time and errors were concentrated. Much of the work repeated on every bid: documents spread across multiple folders, content copied from the previous bid, and stakeholders adding input at different stages.

I standardized and automated the repeating work so the team produces a bid without reassembling the same documents each time. Removing the duplicated steps shortened the process and made each bid’s status easier to track.

I wrote up the full story here: Simplifying the tender process at Lithos.

Running OCI/Docker images on Sprite.dev

Sun, 01 Mar 2026 11:43:00 +0100

Sometimes you want to run your existing docker images in Sprite’s firecracker vms. You’ll quickly come to the conclusion that it’s a pretty stripped kernel and Docker will complain a lot.

Since Sprite is sandboxed I don’t need any of the Docker features in terms of isolation, it’s just one sprite per role. But i do want the docker images i’ve created before.

You can just skip docker and pull the images and run them by using skopeo (registry management), umoci (oci image management) and runc (container management).

Quick way of running images on sprite.dev

sudo apt install -y skopeo umoci runc
skopeo copy docker://alpine:latest oc:alpine_oci:latest
umoci unpack --image alpine_oci:latest my_bundle
sudo runc run -b my_bundle rootless-tr

Eaaasy…

Deepseeks 3FS' FUSE hackery is super interesting

Sat, 14 Feb 2026 11:03:00 +0100

Deepseek released 3FS some time ago, a filesystem to blast tons of data to your GPU cluster for efficient training since GPU’s needs to go BRRRRR and not wait on IO.

I was checking out their paper and docs and went found this cool hack for FUSE that they employ. FUSE makes it possible to have a Filesystem in UsErspace so that us mere mortals don’t have to hack the kernel too much in order to pretend we can build filesystems.

This allows you to, for instance, access a database as a filesystem. Not saying you should, but you can, if you feel the urge.

What they want at Deepseek when training, is fast fast fast throughput. As fast as possible to get data from the clusters onto your GPU.

In order to do this they do some tricks:

Use FUSE for file listing, directory semantics talking to 3FS
For read() sidestep the whole thing and open a door to a magic portal

The portal works like this:

Get data from NIC (infiniband) (don’t go to the kernel, but put it in shared memory region)
Read the shared data from the memory in another process via a ringbuffer
Let the process consume the data directly
Celebrate! Look ma no kernel!

Also made me go down into the rabbithole of AF_XDP where we can build this ourselves. Since i don’t have an infiniband card. The upside = SUPERFAST PACKETS, downside rebuilding the whole TCP/IP networkstack.

If you want to read more on their tricks, here is another great article and one more!

StarGZ fast docker snapshotter is low-key magic

Fri, 13 Feb 2026 17:28:00 +0100

Sometimes you run into tech that makes you go “Heh?”, which is the positive variant of its cousin, “Wtf?”. My newest addition, Stargz snapshotter, is exactly that kind of tech.

Without immediately spoiling how the magic works: Stargz snapshotter is something you install on your Docker host that causes the daemon to download only the files your workload actually uses, just in time. Heh? I know right. Instead of gobbling down a 9GB CUDA container during docker pull only to use a fraction of it, it fetches precisely what’s needed, when it’s needed.

To pull off that trick, it has to solve a few problems:

Know which files are being accessed by your workload or processes inside the container
Know where to fetch those files from
Perform some additional sleight of hand

So how does it do that? It’s a combination of things working together:

A FUSE layer that observes file access and fetches content on demand
A gz/tar/toc index on where to exactly find those files in the image (and download them)

Now, this is already cool but your containers would suffer from a slow start/unpredictable run times. You can also choose to optimize the images.

StarGz then profiles your workloads (by running them) and puts the most frequently asked and most used files first, bundles them up so that you have a quick first fetch with range requests.

Now isn’t that awesome?

Its internals are really worth reading

Also, seems that Nydus ran with the concept and put more fancy things op top like chunk dedup.

On mourning the craft

Sat, 07 Feb 2026 23:15:00 +0100

I recently read We mourn our craft and it resonates for me. It does more than that actually. I think it’s normal to feel grief and emotions like mourning for something you’ve worked so passionately hard to obtain, becoming so easily accessible and reproducible for others. I don’t hate AI, I am actually very productive with it and I can do more than ever. However, I do grieve. Things can co-exist.

Yes, there is a whole new world to explore with LLM/AI tech, but it’s different than the other changes over the past 25 years i’ve been around. And yes, we’ll find a way, but it’s also good to just actually feel it for a minute and understand its nuances.

It’s not hype, it’s actual value for even the most seasoned people. I don’t even want to put the word hype here to taint it. There is a huge disparity on opinions how valuable it is, but I think most of it boils down to effort put in and model selection. But back to my point.

I went to libraries to get books on programming because the internet wasn’t commonplace yet. I had to painstakingly type in every word in an Amiga to make a ball bounce. Later I started recording tapes from radio stations where they broadcasted games.

I was there when the internet came and people thought it was a fad. Built dialup systems with RAS and Asterisk. Built up lots and lots of knowledge by doing many freelance gigs for big, medium, and small companies.

I didn’t mind that some projects took very hard work with many failures along the path; all of it was learning anyway and that was valuable. The craft was expensive to learn in terms of time, but that knowledge was worth it and well earned.

And now, something ephemeral like knowledge, something that I held closely like an armour for all my life, has become so easily reproduced. Of course it’s still a matter of how one applies it all, but still. Being able to ask it in whatever form you want, in any language you want, is step one. Having the entire corpus at your disposal is insane. You just need to ask, filter, and be diligent.

And I would even argue it’s harder to make a difference now. One simply can’t train a model themselves with just pure coding. You need tons of data, truckloads of money to train. Where you could sit down and build a groundbreaking product alone becomes much harder now in the age of AI.

When I fully understood the impact of IA, I took a year of to travel, sail and think a little.

Gow - Simple compile on save, live reload for go web applications

Sun, 01 Feb 2026 18:34:00 +0200

When building Go web applications, fast feedback matters. The usual loop, compile, run, open the browser, refresh, adds friction, especially when you also want to test on your phone.

That’s the problem gow is built to solve.

Faster loops with Gow

I’ve decided to fix this with a unified tool.

Gow combines:

Automatic compilation
Live browser reloading
Easy phone access via QR codes

Whenever you save a file, Gow rebuilds your Go program, starts it, and refreshes your browser automatically. If the build fails, the browser shows the compiler error directly. As soon as you fix the issue and save again, the app recompiles and the page reloads back to your running site.

This keeps the development loop tight and uninterrupted.

QR & phone support

Gow also displays QR codes you can scan with your phone. Your mobile device connects to the same local app, auto-reloads on changes, and even stays in sync with navigation. That makes real-device testing just as seamless as desktop development.

Overall, it’s a much faster and smoother turnaround when working on Go web apps.

Installation

Install it with:

go install github.com/emilebosch/gow@latest

This will build the current folder with go build . and pass any optional parameters to your app when the build completes.

gow -- [optional params for your app]