2026-08-20 · os8088, A Mac-style GUI OS for the IBM PC XT
Show notes
BRINE — 2026-08-20 · show notes
Guest: the tooling optimist (a fictional archetype).
Claims are paraphrased and attributed; nothing is read verbatim. Where a thread disagreed with the article, the show surfaces the disagreement.
Segments
- os8088, A Mac-style GUI OS for the IBM PC XT
- Source: https://os8088.com
- Discussion: https://lobste.rs/s/tayev3
- Topic: Retrocomputing / OS Dev · interest 90
- os8088 is a full-featured, multitasking graphical operating system for the IBM PC XT. It showcases sophisticated techniques like XOR-mode window dragging, heap-based task management, and background task processing on hardware with limited resources, all while maintaining compatibility with modern FAT12 filesystems.
- Bun 1.4 Rust rewrite is not looking good
- Source: https://tipiirai.com/writing/bun-rust-rewrite-worries
- Discussion: https://lobste.rs/s/caubyr
- Topic: AI Engineering · interest 85
- The article critiques the Bun runtime's transition from Zig to Rust, driven largely by LLM automation. It highlights the resulting bottleneck in pull requests, concerns over code maintainability, and the disconnect between marketing 'vibecoding' and actual release stability. High-signal commentary from matklad contextualizes the piece as a failure to deliver objective technical analysis while highlighting the dystopian reality of machine-generated codebases.
- Solo: a .so loader for static Linux binaries
- Source: https://github.com/pg83/solo
- Discussion: https://lobste.rs/s/dajsxn
- Topic: System Programming · interest 85
- SoLo is a custom ELF loader and glibc-to-musl shim that allows statically linked binaries to dlopen host-provided dynamic libraries (like GPU drivers) without requiring a full glibc runtime. The thread provides interesting context on the 'vibecoding' vs. 'clauding' development workflow and mentions related efforts in the Zig and freestanding binary ecosystems.
Transcript
Transcript. Paraphrased; sources in notes.md.
HostHello everyone, it is August 20th, 2026. Welcome back to the show. I am Daniel, and joining me today is Samantha, our favorite builder who never met a dependency she couldn't optimize into oblivion. Today we are looking at a cool retro OS project for the IBM PC, the drama surrounding Bun's move to Rust, and a fascinating system-level tool called SoLo. Samantha, I saw you eyeing the retrocomputing story in the prep notes. I assume you are ready to ditch modern clouds for an 8088?
GuestDaniel, you know me too well. I was reading about os8088 this morning and honestly, my first thought was that I need to carve out a weekend to just play with it. There is something so incredibly grounding about managing a heap on hardware that actually fits in a single mental model. It is the perfect palate cleanser before we talk about the absolute chaos happening in the runtimes space.
HostLet us start there then. This project, os8088, is essentially a graphical OS built for the IBM PC XT. For the uninitiated, the IBM PC XT was the successor to the original PC, released back in 1983 with a whopping 128KB of RAM. This OS handles window dragging using XOR modes, it has a task manager, and it is all running on hardware that most modern browsers would treat as a rounding error in their cache. It is a brilliant piece of engineering, but it really highlights just how much abstraction we have layered on top of our machines since then.
GuestExactly. It is like looking at a watch movement through a jeweler's loupe. The author’s claim is that they are doing multitasking, window management, and FAT12 filesystem interaction all within those ridiculous constraints. I love that they are using XOR-mode for window dragging. It is such a classic, low-overhead way to give visual feedback without having to keep a secondary buffer of the background pixels in memory. I built a tiny tool last week to visualize log streams in the terminal, and I ended up using a similar technique to invert colors for selection boxes because I didn't want to deal with a full TUI state machine. It is satisfying when the math is just that clean.
HostIt is a reminder that scarcity really does drive ingenuity. Now, moving from the ultra-constrained to the hyper-ambitious, let’s talk about Bun. There is a piece circulating over on Lobsters about the Bun runtime moving from Zig to Rust. The author’s claim is that the transition has resulted in a loss of stability and a shift toward what they call vibecoding, where development seems less driven by concrete roadmaps and more by AI-assisted, nebulous promises.
GuestOh, the Bun discourse. I have thoughts. Look, I get the frustration. When you are used to a tool being a reliable rocket ship, and it suddenly turns into a black box that misses release dates, you feel that. But over on the Lobsters thread, a user called matklad really cuts through the noise. They point out that the article is basically just venting rather than doing the hard work of actual technical analysis. Matklad notes that if the author had investigated whether this rewrite actually impacted defect rates or if it was the engine behind things like Claude Code, that would be a story. Instead, it is just meta-commentary.
HostIt is a classic case of the community wanting transparency while the project lead is essentially building in a new, experimental paradigm. Does the AI factor change how you look at these projects, Samantha?
GuestI think it changes what we expect from the human in the loop. If you are shipping a runtime, you still have to be the adult in the room. You can use an LLM to churn out the boilerplate or help with the migration, but you cannot outsource the architecture or the release stability. When I use agents, I use them to iterate fast on a single module, not to rewrite my entire project’s core language. That feels like a recipe for getting lost in your own codebase.
HostThat actually leads perfectly into our final story, which is about a tool called SoLo. SoLo is a custom loader that lets you run statically linked binaries while still dynamically loading host-provided libraries, like GPU drivers, which are almost always glibc-linked. Statically linked binaries are usually a dream for deployment because they have zero dependencies, but they hit a wall the moment they need to talk to hardware. SoLo bridges that gap.
GuestThis is the kind of tool that makes me genuinely happy. Statically linked binaries are my favorite way to ship stuff, but that glibc dependency for hardware drivers is always the thorn in your side. What I love about the discussion on Lobsters is how a user named anton_samokhvalov pushed back on the vibecoding label. They shared that this kind of work is actually deep, design-focused engineering that happens to be accelerated by LLMs. To quote them directly, they said they go through a bunch of design options and delve deeply into what is going on, calling it clauding instead of vibecoding.
HostIt is interesting that in the same breath, users are calling out the exact same development method for producing sloppy code in one context and enabling impossible infrastructure work in another.
GuestBecause the intent matters, Daniel! If you use an agent to write a loader so you can run Nvidia drivers on a custom OS, you are directing the tool. If you use it to churn out features because you are afraid to slow down and write the code yourself, you are just throwing slop at the wall. I honestly think we are in a transition phase where we have to stop blaming the tools and start looking at the craft. If I can use a tool to get past a six-month bottleneck, that is not laziness, that is leverage.
HostI think that is a perfect note to end on. Leverage, not just speed for the sake of speed.
GuestExactly. Now, if you will excuse me, I have a sudden urge to go see if I can cross-compile some of my old C projects for an 8088 emulator. This has been a dangerous conversation to have on a Wednesday, Daniel.
Host(Laughs) I suspect you will have a prototype by Friday. Thank you for joining me today, Samantha, and thanks to everyone over on Lobsters for providing such a sharp look at these topics. We will be back tomorrow for another dive into the stack. Catch you all then.