rumpl

Vibe Year

Mon, 29 Dec 2025 23:40:41 +0100

What a year eh?

For research purposes, over the last couple of months I’ve started using LLMs heavily for throwaway code. My main goal was to train myself to write good prompts and find what works (and what doesn’t) with different agents—since that’s going to be my job from now on, after all.

My setup was very similar for all of these projects: all were made using cagent, either with a hand-crafted agent or by simply running cagent run --model ....

Most of the agents only had access to the filesystem and the shell. I’ve found that newer LLMs don’t really need much else. In the GitHub clone, once I had the issues feature and the CLI working, I would ask the agent to plan its steps, create issues for everything using the CLI, and then implement the feature I asked for. There were zero MCPs involved. MCP as a spec is great, but the implementations out there are almost all pretty bad.

I’ve mostly used 3 models:

Opus for pretty much everything. This one is a BEAST and can stay focused for a long, long time.
GPT 5.1 and 5.2. Sometimes Opus will get confused about a fix that is needed and struggle to find the issue. In these cases I would spin up GPT, and most of the time it would take a looong time to analyze but was pretty much always able to find the issue and fix it with a minimal change.
Gemini 3 for frontend things. It’s very good at frontend work.

These models are great for everyday work and can do a lot of things very well. However, they all have issues. Opus, for example, would sometimes end up very confused about the codebase, miss things, and end up in a “But wait!” loop when the feature is big or the bug is nasty. GPT is just very slow and almost always ends up in a strange state where it tells me to Write "do it now" if you want me to do this—very strange. Gemini can be dumb easily and struggles to follow instructions.

When I started doing this for fun I did not expect much, but I was proven wrong quickly: the newest models are genuinely useful tools for today’s developers.

Below I’m showing some of the projects I did lately. These include a Linux-like kernel, a GitHub clone, a markdown editor, a GameBoy Color emulator, a container runtime, etc. I got way better results if I knew what I was talking about; I was able to give the agent keywords and provide semi-detailed (I’m lazy) instructions on how I wanted it implemented. In cases where I had no idea what I was talking about (GameBoy emulator), we would struggle for a bit because all I could say was pretty much “It doesn’t work”, but we did manage to make something that works in the end, it was a struggle though.

Without further ado and in no specific order, here is the list of some of the vibe-coded projects.

ARM64 kernel

This was a wild and fun one. With the agent, I managed to create a working kernel that was able to boot and run a busybox shell.

Features include:

IRQs
VMM
VFS, with working tarfs and FAT32 filesystems
An initrd
Character devices
Block devices
ELF loader
A very simple (round-robin) scheduler

Once all of that was implemented, I managed to cross-compile a small subset of busybox and run it as the init process of the system.

I plan to slow down LLM usage on this one and continue playing with it manually; I’ve already started to implement a very simple proc filesystem. Switching from LLM-based to finger-based coding is quite interesting. Things that I know the LLM could make in a matter of minutes can take me hours, but it’s all cool to have a working starting playground.

  1; make run-disk
  2
  3Starting QEMU with VirtIO disks... (Press Ctrl+A then X to exit)
  4vda = tarfs disk (2MB)
  5vdb = FAT32 disk (4MB)
  6=================================================================
  7
  8---
  9
 10| |/ / _ \| \ | | |
 11| ' /| |_) | \| | |
 12| . \| \_ <| |\ | |**_
 13|_|\_\_| \_\_| \_|\_\_\_**|
 14
 15# Minimal ARM64 Kernel v0.8
 16
 17[BOOT] Kernel loaded successfully
 18[BOOT] DTB not passed in x0, scanning memory...
 19[FDT] Scanning for DTB in memory...
 20[FDT] No DTB found in memory scan
 21[BOOT] DTB pointer: (nil)
 22[IRQ] GIC initialized
 23[IRQ] Exception vectors installed at 0xffff000040081000
 24[TIMER] Counter frequency: 62500000 Hz
 25[TIMER] Tick interval: 625000 counts (100 Hz)
 26[IRQ] Enabled IRQ 30 with priority 128
 27[TIMER] Timer started, 100 ticks/second
 28[PMM] Initializing physical memory manager
 29[PMM] Stack top at: VA 0xffff000040133000 (PA 0x40133000)
 30[PMM] Managed region: PA 0x40133000 - 0x48080000 (127 MB)
 31[PMM] Total pages: 32768 (128 MB)
 32[PMM] Bitmap size: 4096 bytes
 33[PMM] Bitmap at: VA 0xffff000040133000 (PA 0x40133000 - 0x40134000)
 34[PMM] First free page: PA 0x40134000 (index 180)
 35[PMM] Free pages: 32588 (127 MB)
 36[PMM] Used pages: 180 (kernel + bitmap)
 37[PMM] Physical memory manager initialized!
 38[KMALLOC] Initializing kernel heap
 39[KMALLOC] Heap at 0xffff000040134000 - 0xffff000040174000 (256 KB)
 40[KMALLOC] Kernel heap initialized!
 41[MMU] Running at virtual address 0xffff0000400873f0
 42[MMU] Kernel mapped: VA 0xffff000040080000 -> PA 0x40080000
 43[MMU] Device memory: VA 0xffff000009000000 -> PA 0x9000000
 44[MMU] Higher-half kernel initialized!
 45[SYSCALL] System call interface initialized
 46[SYSCALL] Supported: exit, read, write, brk, mmap, munmap, etc.
 47[TTY] Console initialized (80x24, 115200 baud)
 48[VFS] Initializing virtual filesystem...
 49[CHARDEV] Initializing character device drivers...
 50[VFS] Registered chrdev major 1: mem
 51[VFS] Registered chrdev major 5: tty
 52[CHARDEV] Character device drivers initialized
 53[RAMFS] RAM filesystem initialized
 54[RAMFS] Mounted ramfs filesystem
 55[VFS] Mounted ramfs as root filesystem
 56[DEVFS] Device filesystem initialized
 57[DEVFS] Created /dev/console (major 5, minor 1)
 58[DEVFS] Created /dev/tty (major 5, minor 0)
 59[DEVFS] Created /dev/null (major 1, minor 3)
 60[DEVFS] Created /dev/zero (major 1, minor 5)
 61[DEVFS] Created /dev/full (major 1, minor 7)
 62[VFS] Created /dev with device nodes
 63[VFS] Created /tmp directory
 64[PROCFS] procfs initialized
 65[VFS] Created /proc directory
 66[VFS] Virtual filesystem initialized
 67[BLKDEV] Block device subsystem initialized
 68[VIRTIO-BLK] Scanning for VirtIO block devices...
 69[VIRTIO-BLK] Found block device at 0xffff00000a003c00 (version 2)
 70[BLKDEV] Registered: /dev/vda (major 254, minor 0)
 71[VIRTIO-BLK] vda: 2 MB (4096 sectors, 512 byte blocks)
 72[VIRTIO-BLK] Found block device at 0xffff00000a003e00 (version 2)
 73[BLKDEV] Registered: /dev/vdb (major 254, minor 1)
 74[VIRTIO-BLK] vdb: 4 MB (8192 sectors, 512 byte blocks)
 75[VIRTIO-BLK] Found 2 block device(s)
 76[TARFS] TAR filesystem initialized
 77[FAT32] FAT32 filesystem driver initialized
 78[DEVFS] Created /dev/vda (block device, major 254, minor 0)
 79[DEVFS] Created /dev/vdb (block device, major 254, minor 1)
 80[BOOT] Mounting tarfs from /dev/vda...
 81[VFS] Mounting /dev/vda on /mnt (type: tarfs)
 82[TARFS] Parsed 30 entries
 83[TARFS] Mounted vda (2097152 bytes)
 84[VFS] Mounted /dev/vda on /mnt successfully
 85[BOOT] Mounted tarfs on /mnt
 86[BOOT] Mounting FAT32 from /dev/vdb...
 87[VFS] Mounting /dev/vdb on /fat (type: fat32)
 88[FAT32] Mounting filesystem from vdb
 89[FAT32] Volume: KRNLDATA, ID: 12345678
 90[FAT32] 512 bytes/sector, 1 sectors/cluster
 91[FAT32] 8032 total clusters, root at cluster 2
 92[FAT32] Filesystem mounted successfully
 93[VFS] Mounted /dev/vdb on /fat successfully
 94[BOOT] Mounted FAT32 on /fat
 95[TASK] Task subsystem initialized
 96[TASK] Initial task: PID 0 (kernel)
 97[BOOT] Executing /mnt/bin/init...
 98[USER] Loading ELF executable 'init' (88576 bytes)
 99[ELF] Loading ELF: entry=0x100000, 1 program headers
100[ELF] Segment: vaddr=0x100000-0x104364 filesz=16076 memsz=17252 flags=RWX
101[ELF] Load complete, entry point: 0x100000
102[TASK] Created task: PID 1 (init), entry=0xffff000040084e40, stack=0xffff000040152f18-0xffff000040153f10
103[USER] Created ELF process: PID 1, entry=0x100000, brk=0x105000
104[BOOT] Started init as PID 1
105[BOOT] Enabling interrupts...
106[BOOT] Interrupts enabled!
107[BOOT] Scheduler enabled!
108
109[BOOT] Entering idle loop (task 0)
110[USER] Entering user mode: entry=0x100000, stack=0x7fffffe0
111
112=================================
113KRNL Init Process (PID 1)
114=================================
115
116[init] Testing FAT32 file creation...
117[init] Created /fat/testfile successfully!
118[init] Running readdir_test:
119[TASK] Created task: PID 2 (init), entry=0xffff000040084eb0, stack=0xffff00004013d718-0xffff000040141710
120[FORK] Created child process 2 (parent 1)
121[EXECVE] Failed to open '/mnt/bin/readdir_test': error 2
122[SYSCALL] Task 2 (init) exiting with status 127
123[TASK] Task 2 (init) exiting with status 127
124[TASK] Destroyed task: PID 2 (init)
125[init] Running ls /mnt test:
126[TASK] Created task: PID 3 (init), entry=0xffff000040084eb0, stack=0xffff00004013e390-0xffff000040142390
127[FORK] Created child process 3 (parent 1)
128[ELF] Loading ELF: entry=0x400000, 2 program headers
129[ELF] Segment: vaddr=0x400000-0x427100 filesz=160000 memsz=160000 flags=R-X
130[ELF] Segment: vaddr=0x438000-0x438f90 filesz=296 memsz=3984 flags=RW-
131[ELF] Load complete, entry point: 0x400000
132[EXECVE] Loaded 'ls' at entry=0x400000, sp=0x7ffffe80
133/mnt/bin/ls
134
135/mnt:
136hello.txt etc sbin bin
137[SYSCALL] Task 3 (ls) exiting with status 0
138[TASK] Task 3 (ls) exiting with status 0
139[TASK] Destroyed task: PID 3 (ls)
140[init] BusyBox found, will use ash shell
141[init] Starting BusyBox ash shell...
142
143BusyBox v1.36.1 (2025-12-17 21:48:14 CET) built-in shell (ash)
144
145krnl$ ls -l /
146ls: ls
147ls: -l/
148/:
149fat bin mnt proc tmp dev

Lung language

I also made a language (or rather, the LLM did—I just told it my wishes). It looks something like this:

package main

import "fmt"
import "./other.lung"
import "./sub/toto.lung"

def main(): void {
    const message: string = "Hello, Lung!"
    fmt.println(message)

    let x: int = 10
    let y: int = 20
    x += y
    fmt.println("x + y =", x)

    let arr: [int] = [1, 2, 3, 4, 5]
    fmt.println("Array:", arr)
    fmt.println("Length:", len(arr))

    if x > 25 {
        fmt.println("x is greater than 25")
    } else {
        fmt.println("x is not greater than 25")
    }

    let i: int = 0
    while i < 3 {
        fmt.println("Loop iteration:", i)
        i += 1
    }

    fmt.println("my function is", my_function())
    fmt.println("sub: ", sub.my_sub_func())
}

The implementation happened in multiple phases. First, I had a working parser, lexer, and stack-based interpreter. Then came the modules that you can import. Finally, I decided I wanted to have even more fun and ended up compiling binaries using cranelift. Of course, I didn’t stop there and ended up with the ability to compile and link to other dynamic libraries. Here’s, for example, a mini-game in lung with raylib:

package main

// Static raylib FFI sanity check:
// - white background
// - two rectangles
// - some text

// --- Minimal raylib FFI surface ---

extern "C" def InitWindow(width: int32, height: int32, title: *u8): void
extern "C" def CloseWindow(): void
extern "C" def WindowShouldClose(): bool

extern "C" def BeginDrawing(): void
extern "C" def EndDrawing(): void

@repr(C)
struct Color { r: u8, g: u8, b: u8, a: u8 }

extern "C" def ClearBackground(color: Color): void
extern "C" def SetTargetFPS(fps: int32): void

extern "C" def DrawRectangle(x: int32, y: int32, w: int32, h: int32, color: Color): void
extern "C" def DrawText(text: *u8, x: int32, y: int32, fontSize: int32, color: Color): void

// Run:
//   /tmp/lung_raygame_test

def main(): int32 {
  InitWindow(800, 450, cstr("Lung + raylib (FFI)"))
  SetTargetFPS(60)

  // fixed positions
  let px: int32 = 100
  let py: int32 = 100
  let ps: int32 = 32

  let cx: int32 = 400
  let cy: int32 = 200
  let cs: int32 = 14

  while WindowShouldClose() == false {
    BeginDrawing()
    ClearBackground(Color { r: 245, g: 245, b: 245, a: 255 })

    DrawRectangle(px, py, ps, ps, Color { r: 0, g: 255, b: 0, a: 255 })
    DrawRectangle(cx, cy, cs, cs, Color { r: 255, g: 215, b: 0, a: 255 })

    DrawText(cstr("Collect the coin!"), 16, 16, 20, Color { r: 0, g: 0, b: 130, a: 255 })
    DrawText(cstr("Score:"), 16, 44, 20, Color { r: 0, g: 0, b: 0, a: 255 })

    EndDrawing()
  }

  CloseWindow()
  return 0
}

It’s very far from perfect, but I did learn a bunch because I asked the LLM way too many questions about different parts of its implementation.

Container runtime

I work at Docker, so of course I had to try making a container runtime. This time in Rust. The code for this one is available on my GitHub. The architecture is inspired by containerd but, y’know, completely generated by an LLM.

The project contains a CLI and a daemon that talk to each other over gRPC. The daemon runs natively on Linux or macOS. On Linux, it uses runc directly to create and run containers. On macOS, each container runs inside a micro-VM thanks to libkrun.

The neat part of this experiment was the moment I decided I wanted faster networking in the libkrun case. After a lot of back and forth and multiple model switches, I managed to have a user-space networking stack that was ~20 times faster than what I had at the beginning. Don’t ask me how it works, but it works.

Docker TUI

Speaking of Docker, here’s a neat little TUI for your Docker engine.

Markdown editor

Of all the projects listed here, this one is the most useful. And I even use it daily now. It’s a simple and beautiful markdown editor. From the readme:

I made this just for me, there are plenty of other markdown editors, I’m pretty sure others would be better for you and will have less bugs.

Typr has one feature I could not find in any other: the ability to freely rearrange the notes in the sidebar. This is literally why typr exists.

I actually generated this twice, with the same agent and model. In the first try, I ended up with a big HTML file with JavaScript and CSS shoved inside; it was a huge mess. After a reset I retried, and this time after a couple of minutes I had a neat little Electron project. To my surprise, it was working really well and there wasn’t that much code. Basically, I learned of the existence of the excellent tiptap library.

Raytracer

I guess I was bored and thinking about my university days and how I spent months back in the day implementing a raytracer in Java. These days you can get one in less than an hour.

GameBoy emulator

Why not, right?

GitHub clone

Another one that goes into the “why not” category. I made a small GitHub clone, but without the social part. I’m kinda planning on cleaning up the code, adding some more tests, and then just deploying this on a server at home so that my code has a second place to call home. I’m very happy about the CI that came out of it; it’s YAML-based like GitHub Actions, but only uses images, and you can also run it locally with no fuss. The project has a server that listens to git events, syncs its own database, and runs CI when needed. There’s a nice UI for it and also a CLI.

I was particularly impressed when I decided I didn’t want my server to be Echo-based anymore, but wanted to use ConnectRPC instead. The agent was able to—one-shot—analyze the existing code, generate protobuf files, and convert the server, CLI, and UI to the new library. If I remember correctly, the whole thing took less than an hour and worked on the first try. Truly impressive.

Repository view

Issues, with epics

Pull requests

GitHub actions inspired CI

Commits with diff views

This was an easy and fun one. I pointed the agent to cagent’s repository and asked it to add a “Share” command that would send the current session to a remote server. I then asked the agent to make a React/Tailwind/shadcn/ui frontend that is capable of showing the session. If memory serves, less than 10 minutes later I had everything working and was able to share my sessions from cagent to a server deployed to Fly.io.

cagent

Tue, 18 Nov 2025 09:00:00 +0100

Long time no see.

I’ve been heads down working on something new, and I couldn’t be more excited about it. It’s called cagent, and it’s an open-source project I’ve been building at Docker.

In short: cagent is a multi-agent runtime that makes it easy to build, run, and share AI agents.

We wanted to create a tool that lets you orchestrate “teams” of virtual experts: agents with specialized knowledge and tools, without the complexity that usually comes with building AI applications.

How it works

The core philosophy is simplicity. You define your agents in a straightforward YAML file. No complex Python frameworks or boilerplate code required.

Here is what a basic agent looks like:

1agents:
2  root:
3    model: openai/gpt-4o
4    description: A helpful AI assistant
5    instruction: |
6      You are a knowledgeable assistant that helps users with various tasks.
7      Be helpful, accurate, and concise in your responses.

You can run this immediately with:

1cagent run agent.yaml

The Power of Tools (MCP)

One of the things I’m most excited about is the support for the Model Context Protocol (MCP). This allows your agents to connect to the outside world: databases, file systems, web search, you name it.

You can even use Docker containers as tools. For example, giving an agent access to DuckDuckGo search via a containerized MCP server is as simple as adding a few lines to your YAML:

1toolsets:
2  - type: mcp
3    ref: docker:duckduckgo

Agents as Tools

It gets more interesting when you start composing agents. cagent isn’t just about running one agent; it’s about orchestration. You can have a root agent that delegates tasks to specialized sub-agents (e.g., a coder, a writer, a researcher).

Plus, cagent itself can act as an MCP server. This means you can expose your custom agents as tools to be used by other MCP clients!

Since we are Docker, we obviously had to make distribution easy. You can push your agent configurations to Docker Hub just like container images:

1cagent push my-namespace/my-agent

And anyone else can pull and run them:

1cagent run my-namespace/my-agent

Is that it, I hear you ask. Well no, of course not. cagent is packed with features, each could have its own blog post. And maybe I will one day, for now here’s a rapid fire overview of some of them.

cagent can act as an ACP server, use your agents from your IDE
It has an API
Its TUI can connect to the API remotely
Remote MCPs with OAuth work out of the box
A (we think) nice list of builtin tools for your agents
Alloy agents, in your YAML file, add multiple LLMs to your agent: model: openai/gpt-5,anthropic/claude-sonnet-4-5
Code mode MCP
Evals
Auto session compaction
TOON encoding of the tool results

The future

We have a lot of ideas about new features we can add to cagent. We are exploring more complex orchestration patterns, workflows, RAG, you name it, we’ll implement it!

Give it a spin

I’m really proud of how this is shaping up. It’s still active development, so things might break, but I’d love for you to try it out.

You can install it via Homebrew:

1brew install cagent

Or check out the GitHub repository for more details, examples, and binary releases.

Let me know what you think!

Wasmio 2023

Sat, 25 Mar 2023 18:41:49 +0100

I just got back from sunny Barcelona where the WasmIO 2023 conference was held. It was purely and simply a blast! I want to thank the organizers for their hard work in making this first WasmIO conference awesome. Y’all are awesome!

WasmIO was a two-day, single-track conference, and we had the creme de la creme of the people involved in the Webassembly world. And I was lucky enough to also be a speaker. This was my first conference in a while and boy am I rusty in public speaking, I hope that this will change now that the in-person conferences are back.

The organization was flawless, the venue was great, and of course, Barcelona is a wonderful city. They did feed us on spanish time (lunch at 1:30PM), I’m not used to eat so late but the food was great so I won’t complain (much).

My talk was on the first day in the afternoon so it’s all kinda fuzzy to me because I was constantly checking my slides… I do remember seeing some awesome talks, of interest (to me) was the “Containers vs WebAssembly” panel, do check it out once the videos are out.

I gave my talk about the things we’ve been working on at Docker, making it easy to run Wasm workload with Docker and on Kubernetes. We also announced the second technical preview of Docker+Wasm in which we added 3 more runtimes for people to use: spin, slight and wasmtime. The first technical preview only had the WasmEdge runtime. On top of that, it’s now possible to run Wasm inside the Docker Desktop’s kubernetes cluster. Read more about it here.

I won’t go into details about the talks but from what I’ve seen the bar was high! Of course it is, knowing that the speakers are the ones that move the WebAssembly world forward: Dan Gohman, the WASI man, spoke, Fermyon had multiple talks and workshops. Zalim Bashorov and Sébastien Deleuze gave a deep-dive talk about Kotlin and Wasm, I could go on and on… I’m telling you, go check out the videos once they are out!

As with any conference, the meat of it was happening in the hallways and in the afterparties. I had too many great conversations, my head is spinning with ideas! This was my first foray into the WebAssembly community and it’s all love and everyone is there with a mission: make WebAssembly a great platform for developers. 10/10, would recommend.

Next year’s WasmIO is already scheduled, it will be on the 21st and 22nd of March 2024, I would urge you to make sure to be there if you are interested in Wasm. I for sure will work hard to earn my place there next year. But for now, I am back home, time for some quiet time.

Writing a Window Manager In Rust - Part 2

Tue, 03 Jan 2023 13:09:33 +0100

Welcome to the second installment of this series. In the first part we managed to set up our development environment and finished with a simple window manager that shows windows. This is a great start but let’s now make it so that our window manager, you know, manages windows.

The specs

Before going further let’s decide what our window manager will do and look like. There are many ways a window manager can work, here is a list of features I would like the window manager to have. This list is not complete of course and might change in the future, that’s what you call a scope creep but that’s fine, this is our little playground and we do what we want.

On to the list of features.

the window manager will be a tiling window manager. I personally use i3 and quite like it. The real reason for making it tiling is that I feel like it would be simpler to write a tiling rather than a stacking window manager
it will have workspaces like any other window manager, this is a must
miniwm will be configurable to some extent, we do want to at least be able to configure things that the window manager will launch at startup, this will be a great place to put polybar and other bells and whistles that exist in the Linux desktop world

These are the things we really want our window manager to have. Let’s go to the “nice to haves”, it’s always good to have these.

window decorations, like the top bar with the minimize, maximize and close buttons, this would be neat
maybe we want the decorations to be themable? Imagine that!
partial support for EWMH

How’s that for a feature list? Good? Great, let’s get into it!

Windows

What is as window anyway? In the X server world a window is a 64 bits unsigned integer. That’s right, it’s a u64 in Rust speak. Now we like types don’t we, let’s create a new type Window that we will use in our code, in miniwm/mod.rs we can add this

1pub type Window = u64;

Our Window type is nothing more than a type alias for a u64.

We want to be able to manage the windows so we need to keep a list of opened windows somewhere, we will use a BTreeSet for this. This collection has all the properties we want:

easy to add/remove items to it
is sorted, we really want the windows to be sorted in the order they were added

Our MiniWM struct now becomes:

1pub struct MiniWM {
2    display: *mut xlib::Display,
3    windows: BTreeSet<Window>,
4}

Before heading to the layout part, let’s correctly listen to the x11:UnmapNotify event sent from the X server when a window is closed. To do that we need to add the xlib::SubstructureNotifyMask. Selecting this mask will tell the X server that our window manager wants to listen to the unmap event (amongst others).

 1    pub fn init(&self) -> Result<(), MiniWMError> {
 2        unsafe {
 3            xlib::XSelectInput(
 4                self.display,
 5                xlib::XDefaultRootWindow(self.display),
 6                xlib::SubstructureRedirectMask | xlib::SubstructureNotifyMask,
 7            );
 8        }
 9
10        Ok(())
11    }

Next, in our main loop in run we match on the xlib::UnmapNotify event. When we receive that event we want to remove the window.

 1    pub fn run(&mut self) -> Result<(), MiniWMError> {
 2        let mut event: xlib::XEvent = unsafe { zeroed() };
 3        loop {
 4            unsafe {
 5                xlib::XNextEvent(self.display, &mut event);
 6
 7                match event.get_type() {
 8                    xlib::MapRequest => {
 9                        self.create_window(event)?;
10                    }
11                    xlib::UnmapNotify => {
12                        self.remove_window(event)?;
13                    }
14                    _ => {
15                        println!("unknown event {:?}", event);
16                    }
17                }
18            }
19        }
20    }

Upon receiving the unmap event we need to remove the window in question from the self.windows list. Once this is done we can call the self.layout() function we will define later.

1    fn remove_window(&mut self, event: xlib::XEvent) -> Result<(), MiniWMError> {
2        let event: xlib::XUnmapEvent = From::from(event);
3        self.windows.remove(&event.window);
4        self.layout()
5    }

With this out of the way we can start working on our layout code.

Layout

As per the specs, we want our window manager to be a tiling one. For the sake of simplicity we will only make it tile the windows vertically for now, we might revisit our algorithm later. There are a lot of different ways one can tile windows, we will start small.

Before laying out the windows we need to know what screen size we have. For this we can query Xinerama. Xinerama is an extension of the X window system that enables applications to use multiple screens as one display. Don’t worry, we won’t handle multiple screens just yet, we only want to know what’s the size of our screen.

xinerama is a feature of the x11 crate so we need to add it to the list of features in Cargo.toml:

x11 = { version = "2.20.1", features = ["xlib", "xinerama"] }

With that done, without further ado, here is the function to get the screen size

 1    fn get_screen_size(&self) -> Result<(i16, i16), MiniWMError> {
 2        unsafe {
 3            let mut num: i32 = 0;
 4            let screen_pointers = xinerama::XineramaQueryScreens(self.display, &mut num);
 5            let screens = slice::from_raw_parts(screen_pointers, num as usize).to_vec();
 6            let screen = screens.get(0);
 7
 8            if let Some(screen) = screen {
 9                Ok((screen.width, screen.height))
10            } else {
11                Err(MiniWMError::ScreenNotFound)
12            }
13        }
14    }

Nothing much is going on here, on line 4 we ask Xinerama to give us the list of screens, we convert these pointers to a vector on line 5 and finally, on line 6 we get the first screen, remember, no multi-displays (yet).

Great, with the list of windows to show and the screen size we can finally layout our windows as we want

 1    fn layout(&mut self) -> Result<(), MiniWMError> {
 2        if self.windows.is_empty() {
 3            return Ok(());
 4        }
 5
 6        let (width, height) = self.get_screen_size()?;
 7
 8        let win_width = width as i32 / self.windows.len() as i32;
 9
10        let mut start = 0;
11        self.windows.iter().for_each(|window| {
12            self.move_window(*window, start, 0_i32);
13            self.resize_window(*window, win_width as u32, height as u32);
14            start += win_width;
15        });
16
17        Ok(())
18    }

The move_window and resize_window are one line function that call the appropriate x11 function

1    fn move_window(&self, window: Window, x: i32, y: i32) {
2        unsafe { xlib::XMoveWindow(self.display, window, x, y) };
3    }
4
5    fn resize_window(&self, window: Window, width: u32, height: u32) {
6        unsafe { xlib::XResizeWindow(self.display, window, width, height) };
7    }

With all this code you should be able to see a window that takes the whole screen when alone

Adding one window splits the screen space between the two windows

Adding another window should move the first two to make place for the last one

Would you look at that, it works!

This must be the simplest tiling manager out there but it’s it ours, we should be proud! The code of this article can be found on the miniwm github repository.

Tune in next time for some exciting new features like for example ✨ workspaces ✨.

This the second part in the “Writing a window manager in Rust” series

2022 in Review

Thu, 29 Dec 2022 12:51:50 +0100

Well this is a first for me. I don’t know what changed but this time I felt like writing a recap of my year. And boy, this year was an exciting one for me personally and professionally.

I won’t go over the personal stuff for obvious reasons but there were a lot of good things happen to me this year and of course some bad. Life is like that, you can’t have nice things but you can’t also only have lemons.

Professionally though, that’s another story, let’s talk about that!

The conferences

The year 2022 is the year in-person conferences were a thing once again. I submitted a talk to three conferences and talked to two, I’m looking at you Kubeconf, pick me next time!

The first conference I talked at was Devoxx FR. I actually had two of my talks selected. Unfortunately for me I got sick the week before (yes, it was the big C) and could only attend to one of my talks virtually. The talk went great, I did it with my friend and coworker Guillaume Lours.

The second conference was in my hometown, Rouen. This talk was also with Guillaume. This time I managed not to get sick and got to talk to a bunch of interesting people. Our talk went great again, even though my part of the demo didn’t work, curse you cloud!

Container stuff

This year I switched teams at Docker and am now in the team that works on the docker cli and the daemon, we call it the runtime team. This is a big deal for me, I started talking about this switch with my manager two years ago and we were trying to find a way for me to switch. It took a long time in part because I wasn’t feeling ready and also because they needed me on other projects. But this year it finally happened.

I now spend my days working with the people, like Sebastiaan, who made this industry-changing technology and it’s a humbling and extremely satisfying.

Somehow I even managed to get the lead on the huge work of switching dockerd’s image management code over to containerd. It’s long and complex work but also exciting and I’m really happy that docker is going in the right direction and embracing containerd more. This will help us in the long run and make maintaining docker easier and will bring features faster to our users.

Wasm

Have you heard of webassembly? Did you know that Docker can run Wasm modules too? Late this year I was lucky enough to get on the webassembly bandwagon. I helped making it possible to run Wasm modules with docker. It was great fun, and our work is only starting. Expect Wasm posts in the near future on my website.

The people creating the spec are doing a great job and we will hear more about Wasm in the future for sure. I will definitely help bring wasm and containers closer as much as I can in the future.

Rust

2022 was the year of Rust for me, this was my fourth or fifth time I tried to learn it and this time it stuck. I am now having more fun with rust than ever and hope I will get to do more in the future. If you are thinking about learning a new language, Rust should be on your list!

Conclusion

Everything I wrote here is just a small part of what happened to me this year. I’m not great at taking notes, there was so much more I did or learned. Think of this as a preview of my 2022.

Next year I hope to be at least as productive as this year, but also I think I might try and take more time for myself, I do tend to grind too much when I work on interesting things. I need to be better at slowing down when I’m hooked on something I’m working on. Not to say these are my new-year’s resolutions but next year I will definitely try to take more time to really learn to play the guitar. I live near a forest now so one of the things I want to do is get out more, do more biking.

I sincerely hope you had a great 2022 and wish you all the best in 2023 and hope you never stop being curious and explore new things.

Writing a Window Manager in Rust - Part 1

Wed, 28 Dec 2022 12:58:11 +0100

This is the first part in writing miniwm, a window manager for X11 in rust.

I recently got my Linux machine working again and I thought I would try and make a window manager in rust. This is something I tried many moons ago but back in the day all you had was C, the xlib documentation and code from other window managers. Let me tell you it wasn’t easy…

I don’t have the list of features defined yet, we can build it as we go I guess. There are things we will need to think about at one point, things like do we want it to be stackable or tiling, how will we configure the window manager etc.

For this series you will need these things:

a Linux machine
rust
Xephyr
urxvt (optional)

Setup

First we need to create the project, in rust this is easy, open a terminal and write:

$ cargo new miniwm

This will create rust bin project in the miniwm directory.

For our mini window manager we will be using the x11 crate. There are two options for libraries that you can use when you write a window manager for X11:

Xlib
XCB

Both of these libraries provide an API to talk to the X server but are designed quite differently. I won’t get into the details, maybe another time if I decide I want to try and rewrite miniwm using XCB.

The first step is to add the x11 crate to your project:

miniwm $ cargo add x11 --features xlib

For nicer error handling let’s install thiserror too:

miniwm $ cargo add thiserror

Right, we have successfully setup our project, we should be able to build it now

miniwm $ cargo build
Compiling miniwm v0.1.0 (/home/rumpl/dev/miniwm)
Finished dev [unoptimized + debuginfo] target(s) in 0.77s

If the project doesn’t compile you will need to install libx11-dev.

Connecting to the X server

On to the good stuff. The first thing a window manager has to do is to connect to the X server. This is done by calling XOpenDisplay.

We will create a struct for our window manager, first create a directory miniwm and a mod.rs inside that directory

miniwm $ mkdir src/miniwm
miniwm $ touch src/miniwm/mod.rs

We can now create our struct in that file

 1use thiserror::Error;
 2
 3#[derive(Error, Debug)]
 4pub enum MiniWMError {
 5    #[error("display {0} not found")]
 6    DisplayNotFound(String),
 7
 8    #[error("{0}")]
 9    NulString(#[from] NulError),
10}
11
12pub struct MiniWM {
13
14}
15
16impl MiniWM {
17    pub fn new(display_name: &str) -> Result<Self, MiniWMError> {
18        Ok(MiniWM {})
19    }
20
21    pub fn init(&self) -> Result<(), MiniWMError> {
22        Ok(())
23    }
24
25    pub fn run(&self) {
26        println!("miniwm running");
27    }
28}

Let’s see what is going on here, first we define our own error type that we will use later.

The MiniWM has three functions:

new will connect to the X server and create a new wm instance
init will instruct the X server that we want to listen to some events
run will be our infinite loop that listens for X server events

Let’s now use our MiniWM in main.rs

 1mod miniwm;
 2
 3use std::error::Error;
 4
 5use miniwm::MiniWM;
 6
 7fn main() -> Result<(), Box<dyn Error>> {
 8    let display_name = std::env::var("DISPLAY")?;
 9
10    let wm = MiniWM::new(&display_name)?;
11
12    wm.init()?;
13    wm.run();
14
15    Ok(())
16}

In the first line we ask for the current value of the $DISPLAY environment variable. On POSIX systems the $DISPLAY environment variable holds the current display name.

We can now try and run our window manager. Granted it doesn’t do anything for now but this is a great time to check that our setup works.

To check this we will need 3 terminals.

In the first terminal we will launch Xephyr. Xephyr is a nested X server that runs as an X application. Having a nested X server means we don’t have to go out of our own X session to test the window manager we are making, neat!

$ sudo Xephyr :1 -ac -br -noreset -screen 800x600

This will open a black window, this is the X server that our window manager will connect to.

Note: without sudo I had problems with Xpehyr not detecting the mouse and the keyboard, sudo makes the problems go away, you should try running Xephyr without sudo, it might work for you.

In another terminal launch our window manager

miniwm $ DISPLAY=:1 ./target/debug/miniwm

Note that we redefine the $DISPLAY variable so that our window manager connects to the right X server.

Finally we can try and run an application, I will use urxvt, a VT102 emulator for the X window system.

$ DISPLAY=:1 urxvt

After all this you should see a miniwm running message in the second terminal and also see the urxvt window should be shown inside the Xephyr window.

Our window manager doesn’t do anything yet, let’s add some code shall we?

The first thing a window manager should do is to connect to the X server, this is done by calling XOpenDisplay

Once we get the reference to the display we will save it in our struct, to do that we add a display field to our struct:

1pub struct MiniWM {
2    display: *mut xlib::Display,
3}

We can then change the new function and add the call to XOpenDisplay

 1    pub fn new(display_name: &str) -> Result<Self, MiniWMError> {
 2        let display: *mut xlib::Display =
 3            unsafe { xlib::XOpenDisplay(CString::new(display_name)?.as_ptr()) };
 4
 5        if display.is_null() {
 6            return Err(MiniWMError::DisplayNotFound(display_name.into()));
 7        }
 8
 9        Ok(MiniWM { display })
10    }

Listening to events

Next we need to tell the X server that we want to listen to some events. By default the X server doesn’t send any events, it’s up to the window manager to tell it what events we care about.

We will do this in our init function

 1    pub fn init(&self) -> Result<(), MiniWMError> {
 2        unsafe {
 3            xlib::XSelectInput(
 4                self.display,
 5                xlib::XDefaultRootWindow(self.display),
 6                xlib::SubstructureRedirectMask,
 7            );
 8        }
 9
10        Ok(())
11    }

Let’s pause here and see what is going on.

The XSelectInput tells the X server that we want to listen to particular events. Here we use the xlib::SubstructureRedirectMask mask. This mask tells the X server that we want to listen to events of type CirculateRequest, ConfigureRequest and MapRequest. We only care about the last one, in X terms mapping a window means creating a window.

Let’s create our busy loop that will wait for events

 1    pub fn run(&self) {
 2        let mut event: xlib::XEvent = unsafe { zeroed() };
 3        loop {
 4            unsafe {
 5                xlib::XNextEvent(self.display, &mut event);
 6
 7                match event.get_type() {
 8                    xlib::MapRequest => {
 9                        self.create_window(event);
10                    }
11                    _ => {
12                        println!("unknown event {:?}", event);
13                    }
14                }
15            }
16        }
17    }

This is an infinite loop that waits for the next event and then dispatches it. We then call the create_window function if we get a MapRequest from the X server.

Creating a window

The last thing we need to do is to tell the X server to create a window when needed.

Here is the create_window function

1    fn create_window(&self, event: xlib::XEvent) {
2        println!("creating a window");
3        let event: xlib::XMapRequestEvent = From::from(event);
4        unsafe { xlib::XMapWindow(self.display, event.window) };
5    }

It converts the event to the appropriate xlib::XMapRequestEvent type and then calls the XMapWindow function. Here we could have also used the xlib::XMapRaised function to effectively show the window and push it on the top of the stack.

The end

We have now created a basic window manager that can show windows when it receives the event to do so. There is so much more we can do but we can, I think, stop here for the first part. Tap yourself on the back and take a break.

Tune in next time for some exciting window manager explorations. In the meantime you might want to take a look at the xlib documentation and reading some other tiny window manager code can’t hurt, here is a list of some nice ones:

tinywm, written in C, the “ridiculously tiny window manager”
rust-tinywm is a port of the tinywm to rust
berry, written in C, has some really clean code inside

You can also see the full code of this post on github

These are just some of the window managers I looked at but the internet is full of tiny window managers, explore!

This the first part in the “Writing a window manager in Rust” series

Add docker/docker to your dependencies

Sun, 10 May 2020 00:00:00 +0000

The problem

If you are using go modules and want to use the client from docker/docker in your code you would do something like this:

 1package main
 2
 3import (
 4    "context"
 5    "fmt"
 6
 7    "github.com/docker/docker/api/types"
 8    "github.com/docker/docker/client"
 9)
10
11func main() {
12    c, err := client.NewClientWithOpts(client.FromEnv)
13    if err != nil {
14        fmt.Println(err)
15        return
16    }
17
18    containers, err := c.ContainerList(context.Background(), types.ContainerListOptions{})
19    if err != nil {
20        fmt.Println(err)
21        return
22    }
23
24    for _, container := range containers {
25        fmt.Println(container.ID)
26    }
27}

If you then try and build your code you will be greeted with a nice error message:

./main.go:12:15: undefined: client.NewClientWithOpts
./main.go:12:40: undefined: client.FromEnv

What just happened? If you look at your go.mod file you would see something like this:

require (
    ...
    github.com/docker/docker v1.13.1 // indirect
    ...
)

It its great wisdom, go mod decided to take the v1.13.1 tag because this is the latest tag that happens to be semver valid. The problem with this tag is that it was created in 2017. And client.NewClientWithOpts did not exist in 2017.

The solution

Here’s how to fix this shenanigans: add github.com/docker/docker master in your go.mod file and execute go mod tidy. If you now look at your go.mod file you will see something like this:

github.com/docker/docker v17.12.0-ce-rc1.0.20200508181053-298ba5b13150+incompatible

I am unsure why it takes the v17.12.0-ce-rc1 tag but the 298ba5b13150 sha is indeed the sha of the latest commit on docker/docker at this time

If you now try to build the code above it will work as expected.

Note: you could have also changed your code to create a client with c, err := client.NewEnvClient() and the code would have worked, this is because the docker team made it so that even an older client can talk to the latest engine, and this is kinda awesome.

Recap

Why this happens? The reason is twofold:

docker/docker uses calver (calendar versions)
go mod uses semver (semantic versions)

This means that even if docker/docker released a bunch of new versions since 2017, its way of naming tags (latest tag right now is v19.03.8) makes it incompatible with the way go mod thinks you should name your tags. Fortunately there is a solution, I just wished life was easier sometimes.

First

Fri, 11 Oct 2019 21:04:27 +0200

Hello world!

package main

import "fmt"

func main() {
  fmt.Println("Hello world")
}