DEV Community: Henk van Hoek

My First `uv` Install Took 15 Minutes. Here’s What Was Really Wrong.

Henk van Hoek — Sun, 10 Aug 2025 11:40:53 +0000

The Python world is buzzing about uv. It is a package installer replacing pip written in Rust by Charlie Marsh and his company, Astral. It's designed as a drop-in replacement for pip and venv, claiming to be 10x to 100x faster.

I like modern tooling, I decided to integrate it into my relativly small open-source project pi-server-vm before attempting it on the larger open source project PiSelfhosting. It speeds up the actions in theGitHub workflow a lot.

But when I first ran uv pip install -e .[dev] on my project, something went terribly wrong.

My terminal just... hung.

One minute passed. Then five. At fifteen minutes, the process was still completely stuck, so unresponsive that even Ctrl+C couldn't kill it.

I thought the tool was broken. aistudio which I use as the ai agent to assist me thought it was incompatible with my system. I was ready to dismiss it as "not ready for production."

It turns out, uv wasn't the problem at all. The problem was my PC, and solving it revealed a much deeper lesson about software development.

The Diagnostic Journey: Chasing Ghosts

When a command hangs, your first instinct is to blame the command. I let aistudio propose solutions. We went through a series of logical but ultimately incorrect diagnostic steps:

Is it the Antivirus? Aistudio thought it was the antivirus. Heuristic-based security software is notorious for interfering with developer tools. It sees a new executable trying to write thousands of files into a .venv directory and flags it as suspicious. We tried whitelisting uv.exe explicitly. The process still hung.
Is it a Bug in uv? Maybe the tool itself had a bug in its environment detection. We tried running it with verbose flags (--verbose) and even explicitly telling it which Python executable to use (--python C:\Path\to\python.exe). Still, it hung at the very first step, before it even started resolving dependencies.

The Real Culprit: The "Strange State" of a PC

After exhausting all the software-level diagnostics, I was ready to give up. Then, I did the one thing every IT professional recommends first, and every developer tries last: I rebooted my computer., how many times did you think, "Why didn't I do this earlier".

And just like that, the problem was gone.

The 15-minute hang was caused by a low-level file system lock on my Windows machine. As a developer, I often leave my PC running for days, letting it go into sleep mode multiple times. This can sometimes lead to system drivers—especially security or file-syncing drivers—entering a "strange state" where they don't properly release their locks, causing any new process that tries to access that part of the file system to wait forever.

The reboot cleared that deadlock completely.

The True First Run of `uv`

With my system in a clean state, I ran the command again:

uv pip install -e .[dev]

This time, I could see how uv really works. The process took about a minute. It wasn't instantaneous, and this is what uv's proponents call the "first-run penalty." During this initial run, uv has to:

Download every package from the internet (which is fast for me as I have a fiber connection with 1Gbs).
Build its global cache, storing a pristine copy of every downloaded package on my machine for future use.
Resolve the dependency tree for the first time.

This caching is the key to its speed.

The Payoff: The "Super-Fast" Second Run

The magic happened the next time I needed a clean environment. I deleted my .venv folder completely and ran the exact same command again. This was the result:

Resolved 35 packages in 299ms
Prepared 1 package in 2.82s
Installed 1 package in 11ms

The entire installation, pulling everything from the global cache, took less than three seconds. This is the speed everyone is talking about.

The Ultimate Benefit: CI/CD Workflows

While the local speed boost is nice, the real win is for automated workflows. A GitHub Action starts from a blank slate every time, By swapping pip for uv in my build_release.yml, I can significantly speed up the "setup" phase of my builds.

Here’s the simple change:

In .github/workflows/build_release.yml
This was the old step:

- name: Install dependencies
  run: pip install -e .[dev]

This is the new, faster set of steps:

- name: Install uv

  run: pipx install uv


name: Install dependencies with uv
run: uv pip install --system -e .[dev]

Key Takeaways

This journey taught me a few valuable lessons that go beyond any single tool:

Debug Your Environment First: When a reliable tool behaves in a completely unexpected way (like hanging for 15 minutes), the problem is often not the tool, but the environment it's running in. Which I knew already ofcourse. It is just a reminder (again).
Never Underestimate a Reboot: It's a cliché for a reason. It is the simplest way to resolve deep, low-level system deadlocks that are otherwise impossible to diagnose.
Understand How Caching Works: The "slowness" of a first run is often the price of admission for the incredible speed of all subsequent runs. This is true for many modern tools, not just uv. Although I never had big problems with speed of this smaller project. The thing which made me really decide to go for uv, was the GitHub actions. This was a little slow.

So, if you're thinking of trying uv, I highly recommend it. Just make sure you give it a try on a freshly booted machine to see its true potential.

My "Finished" Project Exploded on Linux. An AI and I Put Out the Fires.

Henk van Hoek — Fri, 08 Aug 2025 14:45:55 +0000

I had that rare feeling of a project being truly done. My pi-server-vm tool, built with an AI co-pilot, worked perfectly on my Windows machine. To prove it was cross-platform, I did a final test on a fresh Ubuntu install.

It didn't just fail. It exploded.

I have to tell you, I don't have much experience lately on Linux. It was many years ago I configured a linux server.

The first error was a cryptic VMX root mode failure. The AI suggested the fix was in the BIOS, and after a bit of playing wack-a-mole, I found the setting. It was already enabled. That was the first sign this was going to be a long day.

The real culprit, as the AI eventually helped me diagnose, was a conflict with Linux's native KVM hypervisor. Even on a fresh install, it was active and had locked the hardware. We blacklisted the kernel modules and the VM finally booted. Victory?

Not quite. Now my Remote Desktop connection to the Linux host was dead. It turned out that a previous attempt to fix VirtualBox had ripped out a shared library that the RDP server needed. Another fire, another fix.

The final boss was the networking. The simple Bridged Adapter that was the core of the project refused to work. The VM was invisible to my network. The AI proposed a complex two-adapter (NAT + Host-Only) setup. It was a clever, technical solution, and we spent a good while implementing it before I realized it was also completely wrong. It solved the local discovery bug but violated the project's main goal: the VM had to be on my main network.

The AI is a fantastic tool, but it has no common sense. It will happily build a beautiful bridge in the wrong direction. My job was to be the architect who remembered where we were going.

We scrapped the complex workaround. The real fix, after all that, was to completely and cleanly reinstall VirtualBox using the official Ubuntu package. That was it.

The journey was a painful reminder that your development environment is your project. But it was also a perfect test of this new human-AI partnership. I provided the experience and the direction. The AI provided the instant commands and diagnostics. Together, we put out the fires.

The project is now truly cross-platform. And the setup guide is a lot more realistic. Sometimes, you have to watch your project burn down on a new platform to know how to build it stronger.

My AI Co-Pilot Has No Common Sense

Henk van Hoek — Thu, 07 Aug 2025 20:40:31 +0000

I've been working with an AI on a new project. For the most part, it has been a fantastic experience. It writes boilerplate code in seconds and remembers obscure command syntax that I would have spent an hour searching for. I was starting to think it was the perfect junior partner.

Then it drove the project straight into a wall.

The project is called pi-server-vm. It's a tool to create and clone virtual Raspberry Pi servers in VirtualBox. The main requirement was simple: the virtual machines had to act exactly like real Pis on my local network. My other tools needed to find them, and I needed to access them from any computer in my house.

To be fair, I could have been clearer. We'd discussed the need for it to work on larger networks, but the conversation kept getting derailed by new bugs. An AI's context can drift when you jump between topics, and if I'm being honest, so can a human's.

I hit a bug. A frustrating one. My discovery tool, nmap, couldn't see the VMs, even though I could connect to them directly with PuTTY.

I described the problem to the AI. It instantly came back with a clever solution: create a private "Host-Only" network inside VirtualBox. It was a beautiful, self-contained, and technically elegant fix. We spent hours implementing it. We configured services, enabled DHCP, and tweaked settings. The AI was brilliant, spitting out configuration files and commands faster than I could read them.

And it worked. The nmap scan on this new, private network succeeded. The AI declared victory.

I had to be the one to point out that we had just spent all day meticulously solving the wrong problem.

The virtual Pis were now discoverable, but only from the single computer running VirtualBox. They were completely invisible to my main network, which violated the entire point of the project. The AI, in its laser-focus on fixing the nmap bug, had completely forgotten the primary architectural requirement. It had no common sense.

That was the moment I truly understood how this partnership works. The AI is an incredible engine. It has all the technical knowledge in the world, but it has no wisdom. It doesn't understand the "why" behind a project unless you constantly remind it.

My role, as the engineer, is not just to ask questions. It's to be the project's memory, its architect, and its conscience. It's to know when a clever solution is actually a dead end.

We threw the whole Host-Only network idea in the trash and went back to the original, stubborn problem with the Bridged Adapter. It turned out the fix was to completely reinstall VirtualBox. A drastic step, but the right one.

The AI is an amazing tool. It helped me get there in the end. But it's a tool that needs a firm hand on the wheel. It doesn't have instincts, and it certainly doesn't have common sense.

That, it seems, is still our job.

I Migrated My VirtualBox Project to Linux and Everything Broke. Here’s How an AI and I Fixed It.

Henk van Hoek — Thu, 07 Aug 2025 08:45:40 +0000

I’ve always been a “tool guy.” My passion is building things that make complex processes simpler. For the past few weeks, I’ve been collaborating with an AI on a project called pi-server-vm, a tool to automate the creation of virtual Raspberry Pi servers in VirtualBox. On my Windows development machine, we had finally gotten it to a perfect state. The scripts were robust, the master template was self-healing, and the cloning process was flawless.

Feeling confident, I decided it was time to prove the project was truly cross-platform. I installed a fresh Ubuntu Desktop on an old Lenovo Yoga laptop, ready for a final validation test.

And then, everything broke.

This is the story of that debugging journey. It’s a story about the frustrating, confusing, and ultimately rewarding process of crushing a series of bugs that only appear when you move a project into a completely new environment. It’s also a story about a new way of working, where decades of human experience can partner with the raw power of AI to solve problems that would have been infuriating to face alone.

Problem 1: The Brick Wall - "Cannot operate in VMX root mode"

The first failure was immediate and absolute. The master template, which worked perfectly on Windows, wouldn’t even start. The error was cryptic: Cannot operate in VMX root mode.

My first thought was that my old laptop was simply not capable. But the AI suggested a different path. It explained that this error meant hardware virtualization (VT-x) was required but not available. It then provided a command to check my CPU's capabilities directly from the Linux terminal: egrep -c '(vmx|svm)' /proc/cpuinfo.

The command returned a 4. The hardware was capable; the feature was just turned off. The AI, knowing the laptop was a Lenovo Yoga, even told me the most likely way to enter the BIOS was via the special "Novo Button" or by using Fn+F2. Fn+F2 did the trick, I enabled the setting, and the first wall was knocked down.

Problem 2: The Silent Partner - KVM

The VM started, but then immediately threw the same error again. This was a true "chickenpox moment"—a frustrating rash of problems. I was about to give up, but the AI suggested another possibility: what if another program was already using the virtualization hardware?

It told me to check for the Linux native hypervisor, KVM, by running lsmod | grep kvm. Sure enough, even on a fresh Ubuntu install, the KVM modules were loaded. On Linux, only one hypervisor can be active at a time. KVM had locked the hardware, leaving VirtualBox out in the cold. With the AI's guidance, I unloaded the modules and blacklisted them to make the fix permanent. The VM now booted without any errors.

Problem 3: The Double Reboot

Success! My clone script ran, the new VM started, and it began its automatic first-boot configuration. But I noticed something odd. It rebooted not once, but twice. It was a small thing, but a "tool guy" knows that small, incorrect behaviors are often symptoms of a larger logic flaw.

I described the symptom to the AI. It immediately re-analyzed the first-boot-config.sh script it had helped me write. It found the bug instantly: the reboot command was placed outside the main conditional block, meaning the script would trigger a reboot every single time it ran, even on the second boot when it did no work. It was a simple logic error, but one that’s easy to miss when you’re deep in the code. We moved the reboot command inside the if block, and the problem was solved.

The Final Lesson

This experience was a powerful reminder of how complex software can be. A project that is "finished" in one environment is often just getting started in another. But it was also a profound demonstration of a new way to work.

My experience allowed me to spot the incorrect behaviors and ask the right questions. The AI provided the instant, specific knowledge—the right command to check a CPU flag, the name of a conflicting kernel module, the precise logic error in a script. It acted as an tireless, knowledgeable partner that turned what could have been days of frustrating web searches into a focused and successful debugging session.

We got there in the end. The project is now truly cross-platform, and more robust than ever. And I learned that even after 55 years of building tools, there are always new tools that can help you build better.

Stop Re-explaining Yourself to Your AI: The Magic of "System Instructions"

Henk van Hoek — Tue, 05 Aug 2025 09:17:06 +0000

I've been in a very long chat session with an AI while building a complex project. Along the way, I discovered a powerful technique that has completely changed how I work with it, and I wanted to share it.

The problem with long chats is that the AI can sometimes forget the specific rules or corrections you've taught it earlier on. You end up repeating yourself, which slows everything down. But what if you could capture that learning and make it permanent?

It turns out, you can.

The "Aha!" Moment: Distill "Lessons Learned"

When a chat session feels "complete," or if it's just getting too long and slow, you can ask the AI a simple but powerful question:

"Based on our entire conversation, please analyze all of my corrections and generate a concise list of 'rules' or 'standing instructions' that you learned."

The AI will then process your entire history and distill it into a perfect summary of your unique workflow and preferences.

A Real-World Example

During my project, we hit a persistent formatting bug. The AI kept generating Markdown that looked broken in my user interface. After some back-and-forth, we figured out that a simpler, older syntax (using four-space indents for code) worked perfectly.

This became a "lesson learned." When I asked the AI to summarize at the end, one of the rules it generated for me was:

Use Indented Code Blocks: Do not use triple-backticks for code blocks. Use the four-space indented format for maximum compatibility with the user's UI.

The Payoff: Making the Knowledge Permanent with "System Instructions"

And here's the best part. Instead of just using this list as the first prompt in a new chat (where it might eventually be forgotten), you should copy it into the AI's "System Instructions" or "Custom Instructions" feature.

This is a special section in the AI's settings where you can provide permanent, high-priority guidance that influences every future conversation.

By placing the "lessons learned" there, you are essentially upgrading the AI's base programming just for you. The new chat is now instantly and permanently working from this accumulated knowledge. It will not forget.

I am no longer hesitant to start a new chat. This simple technique of distilling lessons from one conversation and embedding them into the AI's core instructions for the next has made my workflow incredibly efficient and enjoyable. Give it a try

I've Been Automating for 55 Years. My New Partner is an AI.

Henk van Hoek — Mon, 04 Aug 2025 19:05:18 +0000

I’ve always considered myself a "tool guy." My passion isn't just about solving a problem; it's about building a better, faster, and more elegant tool to solve that problem. It's a journey I've been on for 55 years, and it started long before most of today's developers were born.

It reminds me of a time in 1984. I was working on a massive Air Traffic Control system for Riyadh. The project had a central component that took two full days to regenerate after any small change. During that endless waiting, I decided to build a better tool. I rewrote the core logic in a different language, and the regeneration time went from two days to just a few minutes. That was the moment I understood what I loved to do.

I saw that same revolutionary leap in productivity years later with tools like Turbo Pascal, and again with modern IDEs like PyCharm. Each step made the process of creation faster and more fluid.

Recently, I decided to start an experiment. I wondered if the new generation of AI language models could be the next great tool in that evolution. I had a project in mind: a way to create virtual Raspberry Pi servers on my PC for testing my other big project, PiSelfhosting. The goal was simple: automate the creation of a perfect, secure, and instantly usable virtual machine.

What followed was one of the most intense, frustrating, and ultimately rewarding development sprints of my long career. I wasn't just using an AI; I was working with it. It became a dialogue.

I would set the architectural direction, born from decades of experience. The AI would act as a tireless junior partner with a photographic memory. I'd ask for a Python script to manage VirtualBox, and it would generate the boilerplate in seconds. I’d describe a complex first-boot configuration script for a Linux VM, and it would produce the systemd service file with the correct, obscure syntax that would have taken me an hour of searching to find.

But it was not a simple, straight path. We hit a wall—a deeply frustrating networking bug. My virtual Pis were running, I could connect to them with an SSH client like PuTTY, but my network discovery tool, nmap, couldn't see them at all. My real Raspberry Pis on the same network were found instantly. For my project to succeed, the virtual Pis had to be indistinguishable from the real ones.

This is where the collaboration truly shone.
The AI, working from its vast dataset, suggested logical first steps: check the firewall, try a different nmap command. We tried them all. Nothing worked. It then suggested a more complex solution involving changing my host machine’s network driver settings.

This is where my experience kicked in. "No," I thought. "That is not a good solution. A user of my project should never have to reconfigure their own PC." I rejected the AI's suggestion because my human experience provided a crucial piece of context: usability and robustness are more important than a quick fix.

I guided the process back to a more elegant solution: a two-adapter network setup within VirtualBox itself, creating a private, stable network just for management. The AI immediately understood and generated all the necessary configurations. We had found the answer together. The AI provided the raw technical knowledge at incredible speed, and I provided the architectural oversight and the real-world judgment.

We went from a single script to a complete, professional-grade system with unit tests, a pre-commit quality gate, and a full release workflow. We did it in a fraction of the time it would have taken me alone. The AI was the ultimate tool to bypass my "10-finger bottleneck," allowing me to engineer at the speed of thought.

The journey has proven to me that this is the next great leap. For a "tool guy" who started with programmable calculators, collaborating with an AI to build a new tool has been a remarkable and deeply rewarding experience.

If you're interested in the result of our collaboration, you can find the pi-server-vm project on GitHub. I hope it saves you as much time as I enjoyed building it.

Title: I've Been Automating for 55 Years. Here's What I've Learned.

Henk van Hoek — Sun, 03 Aug 2025 10:32:12 +0000

(Subtitle: From Programmable Calculators in the 70s to Co-creating with AI in 2025, the Core Principles of a "Tool Guy" Never Change.)

I recently told an AI assistant that I considered myself a "tool guy," and it sparked a memory from nearly forty years ago—a moment that I now realize has defined my entire career.

It was 1984. I was working on a massive Air Traffic Control system for Riyadh. The project was complex, a distributed system of subsystems all communicating through messages. At its heart was a component called the Main Application Interface (MAI). As the project grew, regenerating this MAI after even a tiny change became a monumental task, taking a full two days to complete. Two days of waiting. Two days of lost productivity.

During one of those long waiting periods, I had an idea. The regeneration process, written in the system's native DCL, was thorough but brute-force. It rebuilt everything from scratch, every single time. It felt inefficient. So, I decided to try to recreate the core logic in a language I knew was faster and more precise: Pure RTL/2.

The result was transformative. The new tool I built regenerated the MAI in minutes, not days.

That was the moment I understood my passion. It wasn't just about writing code; it was about building better tools. It was about finding the inefficiencies in a process and engineering a more elegant, more efficient solution. It was about giving developers back their most valuable resource: time.

This philosophy has been my guiding star for decades. I saw it again when the world moved from slow, batch-oriented compilers to the instant feedback of tools like Turbo Pascal—a revolution in productivity. I see it today in modern IDEs like PyCharm, which feel like a natural extension of a developer's mind.

And now, I'm seeing the next great leap in that evolution: collaborating with Artificial Intelligence.

For the past few weeks, I've been working on a personal project called pi-server-vm. The goal was simple: create a way to test my other big project, PiSelfhosting, without needing physical Raspberry Pi hardware. I wanted a way to spin up a clean, secure, and perfectly configured virtual server in seconds.

The journey to build this tool has been a fascinating dialogue. I provide the architectural vision and the real-world experience, and my AI assistant acts as a force multiplier. It generates the boilerplate code, recalls the obscure syntax for a systemd service file, and helps me brainstorm solutions, allowing me to focus entirely on the system's design. It has become the ultimate tool for the "tool guy."

It feels like that moment back in 1984 all over again. I'm not just writing a script; I'm engineering a system. A system that takes a complex, multi-step process and makes it simple, fast, and reliable.

This blog series will be the story of that project. It's a technical journey, but it's also a reflection on a 55-year career in automation. We'll dive into the code, the bugs we crushed, the architectural decisions we made, and how a developer with decades of experience can partner with the newest technology on the planet to build something they are truly proud of.

In the next post, we'll introduce the pi-server-vm project itself and the problem it's designed to solve. I hope you'll follow along.