<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Wibonela</title>
    <description>The latest articles on DEV Community by Wibonela (@wibo).</description>
    <link>https://dev.to/wibo</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3822547%2F946492ba-7a3a-4319-a52a-f085766b3872.png</url>
      <title>DEV Community: Wibonela</title>
      <link>https://dev.to/wibo</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/wibo"/>
    <language>en</language>
    <item>
      <title>I Run a Surgical Skills Lab. A Raspberry Pi Storage Problem Led Me to Build Rekonify.</title>
      <dc:creator>Wibonela</dc:creator>
      <pubDate>Fri, 13 Mar 2026 14:57:29 +0000</pubDate>
      <link>https://dev.to/wibo/i-run-a-surgical-skills-lab-a-raspberry-pi-storage-problem-led-me-to-build-rekonify-b14</link>
      <guid>https://dev.to/wibo/i-run-a-surgical-skills-lab-a-raspberry-pi-storage-problem-led-me-to-build-rekonify-b14</guid>
      <description>&lt;p&gt;I run a Surgical Skills Lab where we train surgeons on everything from vascular procedures to laparoscopic techniques. It’s intense, detail-oriented work — and recording every training session is a critical part of how we teach.&lt;br&gt;
Our setup uses laparoscopic cameras connected to Raspberry Pi boards for recording. Simple, affordable, effective. Until it isn’t.&lt;br&gt;
The crash that kept happening&lt;br&gt;
Here’s the thing about recording hours of surgical training video onto SD cards: you run out of space. Fast.&lt;br&gt;
And when a Raspberry Pi runs out of storage mid-session, it doesn’t politely ask you to free up some room. It crashes. Hard.&lt;br&gt;
So there I’d be, pulling the SD card out of the Pi, walking over to my Mac, plugging it in, and… nothing. macOS just stares at you. It can’t read EXT4 — the Linux filesystem that every Raspberry Pi uses by default.&lt;br&gt;
The workaround rabbit hole&lt;br&gt;
I spent more time than I’d like to admit searching for solutions. Most of what I found was Windows-based. I’d try those tools, and some would let me read the files — but actually deleting them to free up space? That was a different story. Half the time the tools would show the files but couldn’t fully remove them, leaving me right back where I started.&lt;br&gt;
I tried macFUSE. It broke after a macOS update. I tried mounting through terminal hacks. Unreliable. I even considered keeping a cheap Linux laptop around just for this one task. It felt absurd.&lt;br&gt;
For years, this was just one of those annoying problems I lived with. Every few weeks, a Pi would crash, I’d lose time fumbling with SD cards, and training sessions would get interrupted. Not exactly the workflow you want when you’re running a surgical lab.&lt;br&gt;
Finally fixing it&lt;br&gt;
I have a background in software development, and this problem had been nagging at me for long enough. When I started working with Claude Code, something clicked. I realized I could combine my own dev experience with AI-assisted coding to actually build the tool I’d been wishing existed.&lt;br&gt;
The core idea was straightforward: use Apple’s own Virtualization.framework to spin up a tiny Linux VM — one that boots in under two seconds — to handle the EXT4 mounting natively. No kernel extensions. No fragile hacks. No security compromises. Just a clean, sandboxed solution that gives your Mac full read and write access to EXT4 drives.&lt;br&gt;
I built it for myself first. It solved my problem completely. SD cards that used to require a 20-minute detour through workarounds were now drag-and-drop simple. Pop the card in, browse the files, delete what I don’t need, pop it back in the Pi. Done.&lt;br&gt;
Why I decided to release it&lt;br&gt;
After using it for a while, I had a thought: I can’t be the only one dealing with this.&lt;br&gt;
Anyone who uses a Raspberry Pi with a Mac hits this wall. Embedded developers working with BeagleBone or Jetson Nano boards — same problem. People who dual-boot Linux and macOS. Anyone who needs to recover files from a Linux drive.&lt;br&gt;
macOS has had zero native EXT4 support for its entire existence, and the third-party solutions are either outdated, require risky kernel extensions, or just don’t work reliably. So I polished what I’d built, gave it a proper interface, and put it on the Mac App Store.&lt;br&gt;
That’s Rekonify.&lt;br&gt;
What it actually does&lt;br&gt;
You plug in an SD card or USB drive with an EXT4 filesystem. Rekonify detects it, boots a lightweight VM in under two seconds, and gives you a native Finder-like interface to browse, edit, and manage your files. Drag and drop works. File preview works. You can read, write, create, rename, and delete — all without ever touching a kernel extension or worrying about your system’s security.&lt;br&gt;
It supports EXT2 and EXT3 too, runs natively on Apple Silicon, and takes up less than 50 MB.&lt;br&gt;
The takeaway&lt;br&gt;
Sometimes the best products come from solving your own problem for long enough that you finally snap and build the thing yourself. Rekonify wasn’t born in a startup brainstorm or a hackathon. It was born in a surgical training lab, out of frustration with a crashed Raspberry Pi and a Mac that refused to read its SD card.&lt;br&gt;
If that sounds familiar, give it a try: rekonify.org&lt;/p&gt;

</description>
      <category>raspberrypi</category>
      <category>macos</category>
      <category>programming</category>
      <category>career</category>
    </item>
  </channel>
</rss>
