Random Hacks

Redoubtful: Linux agent sandbox progress

Sun, 17 May 2026 14:50:36 -0400

I’ve also been experimenting with agent sandboxes lately. redoubtful is a work-in-progress sandbox that supports:

Linux-only sandboxes: I’m focusing on what Linux supports, specifically, rather than trying to support the lowest-common-denominator features that work cross platform.
Modular configuration profiles: See below.
Isolation using pasta and bwrap.
A shadow filesystem that looks like your home directory, so things like git worktree actually work correctly. You can also selectively mount existing parts of your filesystem in read-only or read-write mode.
Network port forwarding and filtering proxy server.
TODO: Proxy credential support.

But first, a warning: Nearly 100% of this code was written by coding agents, much of it by a local Qwen3.6 27B. I am, however, keeping a very close eye on the output—one of my goals here is to see just what a small agent like this can do. This is maybe only 80% as good as my handwritten code would be a similar point in a project.

And finally, this is an incomplete work-in-progress, and it has not been packaged nicely for anyone besides me yet.

Modular configuration “profiles”

One of the slightly novel parts of all this is the ability to define modular configuration. This allows us to invoke a sandbox with a specific set of credentials:

redoubtful run --uses pi --uses llama-server pi

Here, we’re running the pi.dev coding agent with a locally-served Qwen3.6 27B via llama-server. Qwen3.6 27B is a fantastic lightweight coding model, and it works very well with pi.dev’s minimalist prompt. And since we’re running in a sandbox, we don’t care that pi.dev provides no sandbox and no confirmation before acting.

To set up these two profiles, we first define a node profile:

# Standard Node setup. If you're using `nvm`, you'll need to fix the path_add
# entry to point to the correct nvm version.
#
# We might want some kind of plugin system to handle messy things like nvm.
[profile.node]
mounts = [
    { host = "~/.npm-global" },
    { host = "~/.local/share/nvm", access = "rw" },
]
path_add = ["~/.npm-global/bin", "~/.local/share/nvm/v24.15.0/bin"]

Then let’s make Rust work:

# A Rust setup, with optional rustup and advisory support.
[profile.rust]
mounts = [
    { host = "~/.rustup" },
    { host = "~/.cargo" },
    # Cargo audit/deny support, which needs to take a lock to update the
    # advisory database.
    { host = "~/.cargo/advisory-dbs/", access = "rw" },
]
path_add = ["~/.cargo/bin"]

And then basic git is easy—we just need enough config to read user.name and user.email:

# Things you will likely want for git.
[profile.git]
mounts = [{ host = "~/.gitconfig" }]

And then finally, we can set up pi itself:

# Profile for the pi coding agent. Run with:
#
#     redoubtful run -u pi pi
[profile.pi]
uses = ["node", "rust", "git"]
mounts = [{ host = "~/.pi", access = "rw" }]

# Pass through llama-server connections.
[profile.llama-server]
forwards = [{ host_port = 8080 }]
proxies = [{ host = "127.0.0.1" }]

What’s left?

The biggest missing piece is teaching the proxy server how to inject real credentials into network connections. This isn’t a new idea. The goal is to provide access to things like GitHub without giving an agent actual credentials.

After that, it’s just packaging everything up nicely and writing some docs, so that other people (or agents) can easily configure it for different purposes.

Lab notebook: Edit completion #1

Sat, 16 May 2026 11:49:55 -0400

I continue to be interested in late-2024-era edit completion, the “Fill in the Middle” (FIM) models. You know, what Copilot used to do, back before it started generating “mini diffs.” Why?

I like and use agentic workflows. But as many people are realizing, it’s super easy to lose track of what’s happening in your code, with terrible consequences. So I want to reinvest in human-in-the-loop tools, too. (And slightly weaker agentic models, but more on that later.)
The new-school edit completion offered by Copilot and Zed’s Zeta2 actually slows me down. It overlays diffs on my buffer, which is visually disorienting at speed. And it proposes edits further from the current cursor, which take me longer to mentally process. Personally, the new style feels like hunt-and-peck. The older style felt like really fast touch typing.

Mind you, I’m a very specific sort of user. I want to know how my code works. I want my code to be clean. And I can read a half-page code completion in moments, thanks to way too many years of reading PRs.

Initial experiments

All experiments performed in Zed, which does less post-processing of the raw model output than some tools. All evaluations are purely subjective.

New-school models (generating diffs). Zeta2 is honestly pretty underwhelming right now. The completions are very generic. And Zeta2 seems to be bad about taking the context into account. It will complete a function, sure. But I’d swap Zeta2 for late 2024 Copilot in a heartbeat.

Old-school models (FIM, inserting at cursor). Let’s go down the list so far:

ggml-org/Qwen2.5-Coder-7B-Q8_0-GGUF:Q8_0: The classic, default choice. This isn’t terrible, and it gives more context-aware completions than Zeta2. But it’s generations old, and I want to know if anything is new and shiny.
mradermacher/Seed-Coder-8B-Base-i1-GGUF:Q6_K. This is the raw base that went into Zeta2, I think? It doesn’t seem to be useful in Zed, because the inserted text feels pretty raw. This might work better in a smarter harness. But I’m dropping it for now.
JetBrains/Mellum-4b-base-gguf:Q8_0. Downloaded, but not yet tested.
unsloth/Qwen3.6-35B-A3B-GGUF:IQ4_XS. This is unexpectedly good! Worth further experimentation.

Refining Qwen3.6 35B A3B: Changing order from PSM to SPM

Qwen typically uses FIM, “Fill in the Middle” completion. This uses 3 magic tokens:

/// Qwen FIM prefix marker.
const PRE: &str = "<|fim_prefix|>";
/// Qwen FIM suffix marker.
const SUF: &str = "<|fim_suffix|>";
/// Qwen FIM middle marker (model generates after this).
const MID: &str = "<|fim_middle|>";

We have two possible flavors. The original is “PSM” compeletion, “prefix, suffix, middle”:

{PRE}{prefix}{SUF}{suffix}{MID}

But since the prefix grows with each keystroke, we can’t cache the entire message. We could get much better caching with “SPM” order:

{SUF}{suffix}{PRE}{prefix}{MID}

Here, we can cache everything up to the final {MID} character, and resume generation with a longer prefix. Whooo, speed!

But Zed doesn’t support SPM completion, only PSM. So I fired up a copy of Claude Code (as one does), and asked, “Hey, write me a Rust proxy server (using my standard conventions) that intercepts /completion, and translates PSM to SPM please.”

Results: Extremely disappointing. SPM format confuses Qwen3.6 35B A3B pretty badly. But then I thought, “Hey, even if we’re running in /completion mode, this is still an instruction-tuned model. Can we prompt it?” One unscientific tweak later:

You are a code-completion tool. You receive input in
fim_suffix+fim_prefix+fim_middle order, and your job
is to generate what the user would be likely to type
next. When in doubt, keep it short. Think of this like
generating a diff in agentic coding mode. You're trying
to insert the right text to make a working program that
does what the user wants. If there's no obvious next
step, generate nothing.

{SUF}{suffix}{PRE}{prefix}{MID}

This is still pretty bad, but it’s better. You can tell it’s trying to be an SPM autocompleter, though it’s still the worst of the bunch.

Possible next steps:

What if we modify the proxy to transform /completion into a /chat/completions request, with a real prompt, real text inputs, and tool for insert_at_cursor(text)? Can we access more of the model’s intelligence?
Qwen3.6 35B A3B is small enough to fine-tune! We could look up file completion data sets, and try to create a LoRA adapter. We could even use something like tree-sitter to generate custom completion examples. Would that give us something useful?

I also notice that FIM-style models are notoriously bad at choosing a good stopping place. This can be fixed with a lot of regexes. But what if our fine-tuning data took care to demonstrate good stopping places?

I should blog more

Wed, 13 May 2026 01:04:52 -0400

This blog is ancient, in blog years. The first post was on June 30, 1998, and it featured a randomized emboss for MathMap. Back in those days, it was a mix of neat little snippets like that and interesting links. The site was a single, hand-edited HTML file in reverse chronological order. It ran on a Linux mini-tower built from parts from the MIT Swapfest, and it lived under my desk.

Google hadn’t been incoporated yet. The Internet bubble was still inflating.

Over the years, the tech stack changed: for a while, this site used SGML-based rendering via a custom script (or was it XML?), then it was a nice interactive Typo site with comments, and then eventually it migrated to the current Jekyll architecture. Which seems to be about 12 years old. I’m pretty proud to have kept nearly all the inbound links working for decades now.

Around 2007 or so, I did a fun series of high effort posts about probability monads. But high-effort posts are a trap. Soon I started feeling like every post ought to be high effort. And then I wrote less and less.

But blogs are a bit of a retro endeavour these days. RSS readers still exist, but I imagine nearly all my subscribers have disappeared since the heady days of 2007. And apparently it’s trendy to work with the garage door up.

So maybe it’s time to get back this site’s roots. I don’t have any MathMap snippets for you today, sadly, because the last release seems to have been in 2004. But here’s a cool trick!

Edit completion works with Qwen3.6 35B A3B!

Wed, 13 May 2026 01:04:52 -0400

Do you miss the old-style Copilot completions? The ones where it inserted grey text at the cursor? There’s an open version of this called “FIM completion”. And the classic model for doing this is Qwen2.5 Coder 7B.

But it turns out that Qwen3.6 35B A3B is can also do autocompletion! The fact that it has 3B active parameters means that it’s fast. And the 35B total parameters means it’s smarter than the smaller models.

So let’s fire it up using llama-server:

llama-server -hf unsloth/Qwen3.6-35B-A3B-GGUF:UD-IQ4_XS \
    --cache-type-k q8_0 --cache-type-v q8_0 --no-mmproj \
    --ctx-size 4000

--no-mmproj says to disable the vision mode. --cache-type-k q8_0 --cache-type-v q8_0 reduces the cache precision, since we’re not really using the cache. You might also need to grab a smaller quant, depending on your available VRAM.

Then, we can configure it using Zed:

{
  "edit_predictions": {
    "provider": "open_ai_compatible_api",
    "open_ai_compatible_api": {
      "api_url": "http://localhost:8080/v1/completions",
      "model": "unsloth/Qwen3.6-35B-A3B-GGUF:IQ4_XS",
      "prompt_format": "qwen",
      "max_output_tokens": 256,
    },
  },
}

So how good is this? Well, the completions aren’t too bad at all, but Zed doesn’t seem to do much post-processing. So the completions to be too long. At lot of this could likely be improved with a proxy that did some pre- and post-processing, and maybe a bit of fine tuning.

But this is an actual, working, 100% local autocomplete. And it’s close to being actually good.

9½ years of Rust in production (and elsewhere)

Sun, 17 Nov 2024 11:08:00 -0500

The first stable release of Rust was on May 15, 2015, just about 9½ years ago. My first “production” Rust code was a Slack bot, which talked to GoCD to control the rollout of a web app. This was utterly reliable. And so new bits of Rust started popping up.

I’m only going to talk about open source stuff here. This will be mostly production projects, with a couple of weekend projects thrown in. Each project will ideally get its own post over the next couple of months.

Posts I really ought to write someday

Here are some of the tools I’d like to talk about someday:

Moving tables easily between many databases (dbcrossbar)
700-CPU batch jobs
Geocoding 60,000 addresses per second
Interlude: Neural nets from scratch in Rust
Lots of CSV munging
Interlude: Language learning using subtitles, Anki, Whisper and ChatGPT
Transpiling BigQuery SQL for Trino (a work in progress)

Maintaining Rust & training developers

One of the delightful things about Rust is the low rate of “bit rot”. If something worked 5 years ago—and if it wasn’t linked against the C OpenSSL libraries—then it probably works unchanged today. And if it doesn’t, you can usually fix it in 20 minutes. This is largely thanks to Rust’s “stability without stagnation” policy, the Edition system, and the Crater tool which is used to nest new Rust releases against the entire ecosystem.

The more interesting questions are (1) when should you use Rust, and (2) how do you make sure your team can use it?

Pair programming with ChatGPT: A simple dice roller

Sun, 04 Dec 2022 10:09:20 -0500

[This was a fun early attempt to get ChatGPT to write software way back in 2022, before coding agents were a thing.]

Like many folks, I spent too much of the last couple days playing with the new release of ChatGPT. I’ve been trying discover what it’s good at, and how it breaks. At its best, it’s remarkable—I think it would actually pass many common “hiring screens” for programmers. And it has taken first place on an Advent of Code problem.

But there are various tricks which will break it. Programs with randomized output occasionally fool it, as do programs with multiple if branches. So I set down this morning for a short pair programming session, and wrote a classic dice roller with ChatGPT. The experience was fascinating. Things started out very frustrating, but they wound up pretty mind-blowing by the end.

In nightly Rust, 'await!' may never return (dropping futures)

Sat, 09 Mar 2019 15:11:20 -0500

I’ve been using the proposed await! and Future features in nightly Rust, and overall, I really like the design. But I did run into one surprise: await! may never return, and this has consequences I didn’t fully understand. Let’s take a look.

We’re going to use Rust nightly-2019-02-08, and tokio-async-await. This is highly experimental code, and it will require us to convert back and forth between tokio::Future and the proposed std::future::Future.

You can find the full code on GitHub. We’ll start by enabling the experimental features we’ll need:

#![feature(await_macro, async_await, futures_api)]

#[macro_use]
extern crate tokio_async_await;

Then we’ll import some libraries, and declare two helper functions tokio_fut and boxed_fut, that make it easy to convert from std::future::Future into tokio::Future and into Box<tokio::Future<..>>, respectively. You can look that code up on GitHub.

Next, we define a function delay, which returns a Future that waits for the specified number of milliseconds:

fn delay(millis: u64) -> Delay {
    Delay::new(
        Instant::now() + Duration::from_millis(millis),
    )
}

Canceling a `Future`

Now, we can define two tasks:

/// An asynchronous function that completes quickly.
async fn quick_task() -> Result<&'static str> {
    println!("START quick_task");
    await!(delay(10)).context("delay failed")?;
    println!("END quick_task");
    Ok("quick_task result")
}

/// An asynchronous function that completes very slowly.
async fn slow_task() -> Result<&'static str> {
    println!("START slow_task");
    await!(delay(10_000)).context("delay failed")?;
    println!("END slow_task");
    Ok("slow_task result")
}

Here, quick_task waits for 10 milliseconds, and slow_task waits for 10,000 milliseconds. We can combine them using select_all:

Should Rust channels panic on send if nobody's listening?

Fri, 08 Mar 2019 16:42:27 -0500

Lately, I’ve been working on several real-world systems using Rust’s async and tokio. As you can see on the areweasyncyet.rs site, this requires using nightly Rust and the experimental tokio-async-await library. I hope to talk more about these experiences soon!

But today, I want to talk about channel APIs in Rust. A question was raised by @matklad on GitHub:

I’ve migrated rust-analyzer to crossbeam-channel 0.3, and the thing I’ve noticed is that every .send is followed by .unwrap. Perhaps we should make this unwrapping behavior the default, and introduce a separate checked_send which returns a Result?

BurntSushi followed up on Reddit:

Because the vast majority of uses of send are like this: ch.send(foo).unwrap(). That is, you panic because you generally regard it as a bug if you’re still sending values when all receivers have been dropped. Why? Because this is generally a property of the program’s organization.

I hesitate to disagree with two such excellent developers, but my experiences with this issue are almost the exact opposite of matklad’s and BurntSushi’s.

Bare Metal Rust 3: Configure your PIC to handle interrupts correctly

Mon, 16 Nov 2015 06:16:40 -0500

Want to build your own kernel in Rust? See Bare Metal Rust to get started.

We’re almost ready to write a keyboard driver in Rust! But first, we need to deal with two obstacles: setting up the PIC, and handling interrupts without crashing. This is one of the most frustrating steps, as Julia Evans explains in her hilarious and very helpful post After 5 days, my OS doesn’t crash when I press a key:

Turn interrupts on (sti).

The OS AGAIN crashes every time i press a key. Read “I Can’t Get Interrupts Working” again. This is called “I’m receiving EXC9 instead of IRQ1 when striking a key?!” Feel on top of this.

Remap the PIC so that interrupt i gets mapped to i + 32, because of an Intel design bug. This basically looks like just typing in a bunch of random numbers, but it works.

12. THE OS IS STILL CRASHING WHEN I PRESS A KEY. This continues for 2 days.

We’re going to follow Julia Evans’ roadmap. (She saved me several days of suffering.) And once we’re past these next few obstacles, things will get easier. Let’s talk to the PIC first.

The 8295/8295A Programmable Interrupt Controller

We’re going to with the retro approach here, and handle interrupts using the 8295 PIC. You can read all about it on the OSDev wiki, as usual. The PIC works fine in 64-bit mode, but someday, if we want to support multiple processors and I/O, we’ll eventually need to support the newer APIC and IOAPIC. But for now, let’s keep it simple.

Technically, the x86 architecture has two PIC chips, usually known as PIC1 and PIC2. PIC1 handles external interrupts 0–7, and PIC2 handles 8–15. PIC2 is actually chained into interrupt 2 on PIC1, which means that we’ll frequently need to talk to them as a pair.

Unfortunately, the modern x86 architecture reserves CPU interrupts 0-31 for processor exceptions. This means that when we press a key, the CPU will think it just received the “EXC9” mentioned by Julia Evans, which the Intel manual tells me is “Coprocessor-Segment-Overrun Exception.” So we need to tell our PIC that, no, McGyver and Miami Vice are no longer cutting-edge television, that there’s this new-fangled thing called 386 Protected Mode, and that it needs to start mapping interrupts at offset 32.

Bare Metal Rust 2: Retarget your compiler so interrupts are not evil

Wed, 11 Nov 2015 05:43:30 -0500

Want to build your own kernel in Rust? See the Bare Metal Rust page for more resources and more posts in this series. There’s just a few more posts to go until we have keyboard I/O!

Hacking on kernels in Rust is a lot of fun, but it can also result in massive frustration when QEMU starts rebooting continuously because of a triple fault. One good way to minimize frustration is to wander on over to the ever-helpful OSDev wiki. It’s sort of like having an experienced kernel developer on hand to give grouchy but sanity-saving advice.

The OSDev Beginner Mistakes page, in particular, has saved me a couple times already. But there’s one bit of advice that I want to focus on today, which I’ve marked in boldface below:

Beginners often ask “What is the easiest way to do X?” rather than “What is the best, proper, correct way to do X?”. This is dangerous as the newcomer doesn’t invest time into understanding the superior way to implement something, but instead picks a conceptually simpler method copied from a tutorial. Indeed, the simpler route is often too simple and ends up causing more problems in the long run, because the beginner is ignorant of the superior alternative and doesn’t know when it is better to switch. What’s so bad about taking the hard route instead?

Common examples include being too lazy to use a Cross-Compiler, developing in Real Mode instead of Protected Mode or Long Mode, relying on BIOS calls rather than writing real hardware drivers, using flat binaries instead of ELF, and so on. Experienced developers use the superior alternatives for a reason…

So what does that mean, “being too lazy to use a cross-compiler”? It means cheating, and using our regular rustc setup to build ordinary user-space code, and then trying to run it in kernel space. This will actually work, at least for a while. But eventually, we may find ourselves engaged in multiweek debugging nightmares.

So today, I’m going to talk about the sanity-saving difference between --target x86_64-unknown-linux-gnu and --target x86_64-unknown-none-gnu, and how to get your Rust compiler ready for the kernel world.

Random Hacks

Redoubtful: Linux agent sandbox progress

Modular configuration “profiles”

What’s left?

Lab notebook: Edit completion #1

Initial experiments

Refining Qwen3.6 35B A3B: Changing order from PSM to SPM

I should blog more

Edit completion works with Qwen3.6 35B A3B!

9½ years of Rust in production (and elsewhere)

Posts I really ought to write someday

Maintaining Rust & training developers

Pair programming with ChatGPT: A simple dice roller

In nightly Rust, 'await!' may never return (dropping futures)

Canceling a Future

Should Rust channels panic on send if nobody's listening?

Bare Metal Rust 3: Configure your PIC to handle interrupts correctly

The 8295/8295A Programmable Interrupt Controller

Bare Metal Rust 2: Retarget your compiler so interrupts are not evil

Canceling a `Future`