--- title: The First Boot slug: the-first-boot date: 2026-03-02 category: FOUNDER_JOURNEY depth: conceptual author: Stephane abstract: After months of writing kernel code with no way to run it, the Noesis kernel booted for the first time on March 2nd, 2026. What got me there, what it felt like, and what I did immediately after. --- # The First Boot I spent years working in aerospace. One of the things it teaches you early is how to build something you cannot test. When I was working on the [MIXS instrument](https://www.cosmos.esa.int/web/bepicolombo/home) for ESA's BepiColombo mission to Mercury, we tested and simulated for years on Earth — a deeply imperfect proxy for what the instrument would actually face on Mercury's surface. You calibrate, you model, you reason carefully, and then you ship it. BepiColombo launched in 2018. It arrived at Mercury in 2025 — a seven-year wait to find out if you'd done your job correctly. (It worked.) So when I started building the Noesis kernel and encountered the first few months where you can't boot anything, can't fully test anything, and can't see anything — I already knew how to live in that condition. All you have is your confidence in your own reasoning, justified or not. A few months of blind work wasn't going to phase me. I thought it would take about a year to get to first boot. --- ## The Stubbornness Principle I made an early decision that I'm still not sure was wise: I refused to trust emulation. I didn't want to boot in QEMU. I wanted the first boot to be on real hardware. My reasoning, to the extent I can reconstruct it, was that if I got comfortable booting in an emulator, I'd lose focus on the harder problem — real hardware testing — and spend my time on feature development instead. I may have been protecting myself from myself. Whatever the reason, it meant that before I could test anything, I needed real hardware. And that meant choosing a target. I looked at consumer hardware first — a Beelink Mini S12, a Mac Mini M4. Something small, portable, good for repetitive USB image loading. But the intricacies of CPU and memory compatibility across vendors kept me up a few nights, and then I remembered something obvious: Noesis isn't a consumer OS. Noesis 1.0 isn't for people or their laptops. Noesis is for AI agents, and AI agents live in the cloud. So I started looking for bare metal cloud providers instead. --- ## Hetzner Bare metal cloud providers who let you run a custom OS image are rarer than you'd think. AWS doesn't allow it on their bare metal instances. Most providers who do allow it charge enterprise prices. Then I found Hetzner. Their [AX41](https://www.hetzner.com/dedicated-rootserver/ax41/) was €0.0945/hr — about $100/month — and available with a few clicks. More importantly: you could upload your own OS image and boot from it. And you could request a KVM console session to actually watch your OS boot in real time. ![The Hetzner AX41 — €0.0945/hr, the first Noesis bare metal target](Hetzner-AX41-Bare-Metal-Server.png) I provisioned one and got to work. The procedure for each test run went like this: build the latest Noesis image locally, SSH into the AX41 (which defaults to a Hetzner rescue Linux environment — Debian 12), upload the image to the local drive, trigger a hard reboot from the Hetzner management console, open a [KVM session](https://docs.hetzner.com/robot/dedicated-server/maintenance/kvm-console/), get into BIOS before the timeout, set the boot order to the correct drive, save and reboot. Watch the screen. Five to ten minutes per attempt. And the KVM session — the only way I had eyes on the machine — had to be scheduled in advance and lasted only three hours. Looking back, I'm not entirely sure what I was thinking. But I had made my decision, and I was committed to it. --- ## UDP Lifelines Because I was spending a lot of time blind between KVM sessions, I set up a VM on GCP running a UDP listener. The plan: even if nothing appeared on screen, Noesis could try to emit a network packet on boot, and the GCP listener would catch it. Any life signal — even a single packet — would tell me something was happening. This turned out to be the right call. After about a dozen Hetzner sessions, I got the first proof of life on the UDP tracer. Not a full boot. Not anything visual. But something had run, something had sent a packet, and it had reached a machine on the internet. That was a significant moment. Then I started seeing visual failures on the KVM screen. ![A failed boot attempt — visible output, wrong output](Screenshot-failed-boot.png) Not great. But better. At least something was happening. --- ## March 2nd, 2026 After weeks of sessions — building, uploading, rebooting, watching the KVM screen, losing the KVM session, requesting another, repeating — the kernel booted. March 2nd, 2026. ![First successful Noesis kernel boot](Noesis-first-visual-boot.png) I'm not sure there's a way to describe what that felt like that doesn't sound like hyperbole. It felt like Neil Armstrong. Months of reasoning with no feedback, no running system, no confirmation that any of it made sense — and then a screen that says: it works. You were not wrong. You are not a total loon. That was a very good day. I couldn't stop there. A few hours later — by about 6pm — I had the boot screen looking the way I wanted it to look. ![The Noesis boot screen](Noesis-first-nice-boot.png) I celebrated with a Red Bull Zero and didn't stop coding for another twelve hours. --- ## The Shore of San Salvador There are few moments in a long project where months of accumulated tension release all at once. This was one of them. The endorphins are real, and they're addictive. After those twelve hours I paused the AX41 — there was no point paying for it to sit idle — and spent the next two weeks thinking about what came next. It was a strange feeling: I had arrived on the shore of San Salvador, and I hadn't fully planned what I'd do with the riches. The kernel booted. Now came the time to architect the future of computing in the age of AI. That architecture is what the rest of this blog is about. --- *— Stephane, Pensiv Inc.* *Contact: stephane@pensiv.work*