OpenRiot v7.9.30 — `ulimit -d` Saves the World

“My name is Cosmo. I am a hacker. And this — this is a 295 MB stripped binary that needed more datasize than the kernel was giving it.” — Sneakers (1992), in an alternate universe where Cosmo ports Rust editors to OpenBSD on his ThinkPad

Release Overview

The Zed port saga continues. Last release we had a clean compile and a binary that politely exploded at runtime with No wgpu backend feature that is implemented for the target platform was enabled. This release we have the same binary that no longer explodes.

The fix was not glamorous. The fix was: actually read the cargo build script output. Actually verify the patches landed. Actually raise the data segment limit. The fix was, in short, doing the work. None of the four fixes are individually impressive. All four together are why the editor now opens a window.

We also caught a sed bug that has been silently no-oping for months. Apparently sed -i '' is not a thing on OpenBSD. Surprise. The replacement is a five-line helper. Do not ask how many build cycles we burned before noticing. We have decided not to think about it.

In other news: the feds are still bad at their jobs. Specifically the cargo build feds, who insist on reporting Done! even when the binary you just built will panic the moment you launch it. We have replaced them with a local script that actually checks its work. The script is not the same. The script is better.

🎬 The Zed Port — Hackers of the Lost `cfg`

Status: compile + runtime. We have a window.

The runtime panic at wgpu/src/api/instance.rs:65 — Backends::empty() — was the same cfg!(gles) evaluating to false that we documented in v7.9.29. The patches existed. They were just never running.

Why? Because sed -i '' is GNU sed syntax. OpenBSD’s /usr/bin/ sed does not support -i at all. Every sed -i '' line in the build script has been silently failing since the project began. Cargo happily compiled with broken wgpu. The script printed Done!. The binary panicked. The user rebooted. Welcome to the loop.

Four things had to be true. Now they are:

ulimit -d 8388608 — was ulimit -v, which OpenBSD’s /bin/sh does not recognize (silent no-op, see sh: ulimit: -v: unknown option)
TMPDIR=$HOME/.cache/zed/tmp — was unset, so cargo’s scratch files landed on the 495 MB mfs /tmp and the build would eventually run out of space without anyone noticing
Portable sed_i() helper — was sed -i '', which fails on every invocation on OpenBSD. A 1970s-era sed writes to stdout; we use a temp file and mv. Five lines. Works everywhere.
Step 2.5 in the build script — was inside the attempt 2 retry block, never reached because attempt 1 succeeded with broken wgpu. Cargo is happy. Cargo is wrong.

In v7.9.29 we wrote:

“The window still has not rendered, but the compile is clean and the crash dump is no longer the entire system.”

The window now renders.

🕶️ Stealth Mode: Defeated

There is a kind of failure that looks like success. The build script says Done!. The binary exists. The user runs it. The binary panics. The user blames themselves. The user reboots. The user is at war with a phantom.

This is stealth failure. The cure for stealth failure is loud failure. The new Step 2.5 in scripts/zed.sh is loud:

It runs the wgpu patches unconditionally before the first build attempt, not just on retry.
It verifies all four wgpu files contain target_os = "openbsd" after patching.
If any are missing, it prints `ERROR: wgpu patch missing in ` and exits 1.

No more Done! until the patches are actually there. No more phantom wars. The script is now a snitch, in the best possible sense.

💾 Portable `sed` (Or: How I Stopped Worrying and Learned to Love `mv`)

OpenBSD sed has no -i. This is a feature, not a bug. The script now uses a five-line sed_i() helper that writes to file.tmp and mv’s into place:

sed_i() {
    sed "$2" "$1" > "$1.tmp" && mv "$1.tmp" "$1"
}

It works on every platform that ships a sed from the 1970s. It works on macOS. It works on Linux. It works on the 3B2. Probably it works on Multics, if Multics had a sed.

If you are reading this in a future where OpenBSD adopted GNU sed, the helper is harmless. If you are reading this from Linux, the helper is harmless. We are a peaceful family.

🚔 The Feds (i.e. `cargo`)

In the hacker movie tradition, the feds always show up at the worst possible moment. They crash the party. They confiscate the hardware. They ask a lot of questions. They get all the credit when the operation succeeds and none of the blame when it fails.

In our port, the feds are cargo build. Specifically:

cargo build --profile release-fast --no-default-features --features x11

…will happily produce a 295 MB binary that does not work. The exit code is 0. There is no warning. There is no error. There is just a working-looking binary that is, in fact, broken. The feds have moved in. The feds have signed off. The feds are asleep at the desk.

We have added a feds-detection layer. It is called “verify the patches landed before you build”. This is, in retrospect, extremely obvious. We are not proud. We are functional.

We do not trust the feds. We verify.

🧾 Files Changed

File	Change
`scripts/zed.sh`	`ulimit -v` → `ulimit -d`, portable
	`sed_i()` helper, Step 2.5 wgpu
	verification, `TMPDIR` on `/home`
`docs/OpenBSD-Zed.md`	Build requirements updated
	to `ulimit -d`, `TMPDIR` documented

🗣️ Final Words

“Too many secrets, man. Too many sed -i '' that secretly don’t work. Too many ulimit -v that secretly no-op. Too many cargo build that secretly succeed. We have replaced the secrets with ulimit -d, sed_i(), and a build script that actually checks its work. The feds are still here. They are just being watched now. Onward to a working editor.” — The OpenRiot Crew, finally ready to use Zed

OpenRiot v7.9.30 — ulimit -d Saves the World