About Born 2006 · Germany

Hello,I’m Fynn

I’m 19, I live in the Palatinate, and I have been writing code since school in a fairly undirected way that eventually pointed itself at operating systems.

I’m reading for a B.Sc. in Computer Science at DHBW Karlsruhe on the dual model, alternating between lectures and working at my partner company, SAP SE in Walldorf. Outside that I fly drones for the DLRG and build the software around them.

The longer version

Why kernels, of all things

Curiosity

Most programming hands you a machine that already works. I kept running into the edges of that — why a program is slow, why a driver exists, what the operating system is actually doing while my code waits — and the only way I found to answer those questions was to remove the operating system and see what breaks.

What breaks is everything. There is no printf until you write to a UART yourself, no memory until you build page tables, no multitasking until you save and restore registers by hand. Craybond took months to reach a point where it could draw a rectangle on a screen, and that rectangle remains the most satisfying thing I have shipped.

Method

I write the same idea twice on purpose. Craybond is C, close to the metal and entirely my responsibility; CapeOS is Rust, where the compiler argues back. Doing both is how I tell which of my habits are real understanding and which were just C letting me get away with it.

Counterweight

Systems work is solitary and abstract, so it helps that half of what I build has a person waiting for it. When a DLRG unit needs to know how far a missing person could have walked in forty minutes, or what the drone actually saw over that field, the answer has to be on a map, in a browser, today. That deadline is a good corrective to spending a week on an interrupt handler nobody asked for.

Stack

What I reach for, and why
  • CKernel work. Craybond’s memory management, GIC interrupt handling, PCI enumeration, Device Tree parsing and scheduler are all written here, plus the AArch64 assembly underneath.
  • RustCapeOS, and the escape room server TUI. I use it where I want the guarantees without giving up the low level.
  • PythonWhere I think fastest. Tooling, glue, GUI clients with Tkinter, and teaching material.
  • JavaScriptBrowser mapping. Leaflet for 2D layers and GeoJSON, Three.js for the 3D meshes and measurement tools.
  • Dart & FlutterThe DLRG club app. Cross-platform because a volunteer organisation cannot pick a phone for its members.
  • Drone sideOpenDroneMap for photogrammetry, OpenRouteService for isochrones, GeoJSON and KML for everything that has to leave my tools and land in somebody else’s.
  • The restQEMU and GDB more hours than any of the above, plus Make and Git.

Timeline

Roughly how I got here

  1. B.Sc. Computer Science, DHBW Karlsruhe

    The dual model: alternating between lectures at DHBW Karlsruhe and practice phases at SAP SE in Walldorf. Exactly the arrangement I wanted — theory that has to survive contact with a real codebase.

  2. Craybond OS reaches a running system

    Boot, MMU, interrupts, PCI, processes, syscalls and a virtio-gpu framebuffer, on QEMU’s AArch64 virt machine.

  3. Travel Radius Map for DLRG operations

    Isochrone-based search planning with an OpenRouteService backend, KML export and saved map state.

  4. CapeOS, and Rust in earnest

    Started the Rust kernel, and shipped the escape room server TUI as a smaller Rust project with real users at a desk.

  5. Mapping and 3D viewer

    Built the Leaflet and Three.js viewer to make drone photogrammetry output readable in a browser.

  6. Flutter for the DLRG club app

    First serious cross-platform app work, with a non-technical audience and no room for a bad first run.

  7. School projects, in public

    The battleship client, the OOP talk, calculators and experiments. The point at which I started putting things on GitHub instead of in a folder.

DLRG

Deutsche Lebens-Rettungs-Gesellschaft

Volunteer

The DLRG is the world’s largest voluntary water rescue organisation, and in Germany it is part of the civil protection system — the volunteer structure the state relies on for floods, searches and disaster response. I’m an active member here in the Palatinate.

My focus is drones. I fly, and I build the software around flying: planning the sortie, handling the imagery it produces, and turning that into something a unit can act on. Alongside that sit the Travel Radius Map for search planning and parts of an association app.

It is the work of mine that most obviously matters to someone other than me, and it keeps my software honest. If a volunteer cannot use it under pressure, it does not work, however elegant the code is.

Want the code instead?

All of it is public. Start with the kernels if you want to see how I think.

See the work