The Skylark's Garden

Installing PostmarketOS on an Ouya

Thu, 13 Aug 2026 00:00:00 +0000

I was hunting around for a device suitable to use as a home server. Specifically I was checking Ebay for a Raspberry Pi Zero 2 W, and found they’ve all been bought by scalpers selling them for nearly twice MSRP. And sure, that’s only $25, but I still have to buy a storage device, and I’m completely broke right now. I also have an ideological aversion to e-waste.

Then, somehow, I remembered that I had an old Ouya laying around. When it originally came out, I was a teenager with delusions of competence, and its promise to be an open development platform excited me. Surely, this would be the thing that jumpstarted my career as a game dev.

Anyway the console was a massive commercial failure beyond its very successful Kickstarter campaign, and I’ve had a completely useless cube sitting around for the past decade and a half. I’d had aspirations to jailbreak it in the past, but there didn’t seem to be much point beyond just saying I’d done it.

Then, on a whim, I thought I’d check if PostmarketOS supported it. I didn’t have much optimism, since it’s an obscure device, and at first glance I didn’t see it on the list. But then I noticed “tegra armv7” on the list of testing platforms. And, a little reading later, I see that includes the Tegra 3 that the Ouya is running on.

Of course since it is an obscure device, there weren’t any tutorials on how to install it on the Ouya specifically. I had to synthesize a few different guides, which wasn’t that hard, but idk. I guess I figure when I successfully do something weird that I didn’t have a good tutorial for I should probably post a good tutorial for it. Just in case someone else ever wants to do it.

So anyway.

A tutorial on how to do it

You will need:

Your test subject (the Ouya)
A 2mm hex key/screwdriver (I actually used a Torx key but I don’t recommend doing that)
A spare HDMI-capable monitor and cable
A spare USB keyboard
A micro-USB cable
A power adapter (barrel jack, 12VDC, maximum 1.5A). I don’t have my original one, so I grabbed a random one that turned out to put out 24VDC and 0.8A. I’m kind of surprised that didn’t kill it, in hindsight. I didn’t even check the specs. Guess they put a decent regulator on the thing.
A computer running Linux. Mine was running elementaryOS (I haven’t bothered switching it over to Fedora yet)

First, prepare the software side of things. You’ll need to clone the git repos for:

re-crypt
fusee-tools - make sure to clone this recursively, you need the submodules!
u-boot

Then, install dependencies. These are for Debian-based distros, if you’re using something else you’ll need to translate them into the appropriate packages for your system.

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install autoconf bash bison build-essential fastboot flex gcc-arm-none-eabi git \
  libgnutls28-dev libncurses-dev libssl-dev make python3-cryptography python3-dev \
  python3-setuptools python3-usb swig libc6:i386 libstdc++6:i386 zlib1g:i386

Do not skip those 32-bit packages. They are required for the nvflash utility to run properly.

Build stuff

Next, in the directory containing u-boot, run:

make mrproper
make ARCH=arm CROSS_COMPILE=arm-none-eabi- ouya_defconfig
make ARCH=arm CROSS_COMPILE=arm-none-eabi-

You can speed up that last command by adding the -jN option, where N is the number of threads your processor has. It just runs compile commands in parallel when it can.

This will produce the u-boot image, called u-boot-dtb-tegra.bin. Copy it to the re-crypt and fusee-tools directories.

Then go to the payloads directory in fusee-tools and run:

make ARCH=arm CROSS_COMPILE=arm-none-eabi- -j1

I don’t know why the libre-tegra guide specified -j1. I’m assuming it breaks if you try to parallelize. It’s fast to compile though so it doesn’t really matter.

Backup

At this point the libre-tegra guide describes how to back up the Google Nexus 7. This backup process is apparently device-specific, and I didn’t want to spend time figuring out how to do it for the Ouya, since the thing is useless to me if this doesn’t work anyway. I definitely should have though! Don’t be like me, be smart and be safe! Don’t leave yourself without a way to recover your device.

It seems to involve booting into APX (see the next section), loading the appropriate device bootloader from this repo, and using nvflash to pull a bunch of data to backup images. I don’t know how you figure out which images are needed to fully back up any specific device, though.

Prepare u-boot

Now’s when we start with the fun stuff. First, you have to boot the Ouya into APX mode. The tegra30-debrick guide provides two ways of doing this. The first is to bridge pin 5 of a specific IC to ground. The second is to short two solder pads labeled U33. I found the second method to be far and away the easier method. Just short the pads, hit the power button, and you’re in. The other method is finicky and seems to have a timing to it. I managed to do it once but couldn’t seem to replicate whatever I did that worked.

These are the pads to bridge. Image from the tegra30-debrick guide.

If you’ve done it right, and you have the micro-USB cable connected to your computer, running lsusb should include a line like:

Bus 002 Device 055: ID 0955:7030 NVIDIA Corp. T30 [Tegra 3] recovery mode

Before you can flash u-boot, you need to prep it with re-crypt to get a usable partition layout. And to do that, you need your Ouya’s Secure Boot Key.

In the fusee-tools directory, run ./dump_sbk.sh -s T30. It will output a bunch of text. What you’re looking for is a line like this:

#Dumped SBK [ 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX ]

The Ouya will reboot when you do this. That’s fine, just turn it back off.

Everything between the square brackets is your specific SBK. Now switch to the re-crypt directory, and run this command, substituting in your SBK:

./re-crypt.py --dev ouya --sbk 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX --split

That will produce two files, bct.img and ebt.img. Copy both to the fusee-tools directory, and switch back there.

Flash u-boot

Now, finally, you get to actually boot custom firmware. Boot the Ouya back into APX mode, and run this command (in fusee-tools):

./run_bootloader.sh -s T30 -t ./bct/ouya.bct

If everything has gone well, you should see u-boot’s console output on your monitor. Quickly hit Ctrl-C on the connected USB keyboard to interrupt u-boot! Otherwise, it will try and fail to find an operating system to load, and then reboot.

At this point, you haven’t actually flashed u-boot, you’ve just used the fusee-gelee vulnerability to inject u-boot as a payload. If you’re familiar with Switch hacking, you know the difference; you have to re-inject the payload on every boot. Luckily, we won’t have to do that here, because we can actually replace the bootloader entirely with u-boot.

In u-boot, run the bootmenu command, then use the arrow keys to highlight the fastboot option, and press Enter.

Then, on your computer, run:

fastboot flash 0.1 bct.img
fastboot flash 0.2 ebt.img
fastboot reboot

You have now flashed u-boot! The Ouya should boot directly into it now, and every time you press the power button from now on.

Install PostmarketOS

On the Ouya, use Ctrl-C to interrupt the u-boot startup sequence, and again run bootmenu. This time, choose Mount internal storage (or something similar; it was the first option for me). This will expose the Ouya’s eMMC as a USB storage device. If you run lsblk on your computer, you should see it assigned to something like /dev/sdX. You can identify it by its size, it should be 8 or 16GB depending on which model of Ouya you have.

Download a pre-built PostmarketOS image from the website. Then, in the directory containing the image, run (replacing things with your specific file names and device paths):

xzcat xxxxxxxx-xxxx-postmarketOS-channel-ui-nvidia-tegra-armv7.img.xz | sudo dd of=/dev/sdX status=progress

This took about an hour for me. You can probably speed it up by raising the block size with an option like bs=4M, but I didn’t do that.

Once that finishes, you should be able to power cycle the Ouya and it’ll boot right into PostmarketOS. Congratulations! Don’t forget to reassemble the thing.

One small awkward thing I noticed is that, when it’s booted into PMOS, the power light will repeatedly flash in groups of two pulses. Not sure what that’s about or how to fix it. I think it’s just cosmetic though.

Guides I referenced:

Failing To Do 3DS Homebrew with Zig 0.16.0

Tue, 28 Jul 2026 00:00:00 +0000

I had a 3DS homebrew project I wanted to make. I didn’t want to use C, because I would generally prefer to avoid writing C when I can. I didn’t want to use Rust, because the community’s libctru bindings don’t appear to be very comprehensive yet and I didn’t want to spend the whole project writing my own safe bindings. So I decided to go with Zig.

I then wrote up this post while I went, assuming I’d succeed. I did not. Let this be a cautionary tale, though I’m not really sure what the lesson is supposed to be.

What the tutorial would’ve been

The issue is that while there are guides out there for 3DS homebrew with Zig, Zig seems to have had numerous breaking changes since they were written.

So, just in case any other stubborn motherfuckers out there get themselves into this weird position by refusing to just use C or C++, I thought I’d document my own efforts to get it working. I’m basically doing exactly what Erik Wastaken did in his blog post on the topic, but with the current version of Zig, 0.16.0. This post owes a lot to his writeup!

So we are going to:

Start with a C “hello world” program.
Convert the makefile into a build.zig.
Alter the build.zig to use Zig itself as the C compiler.
Alter the build.zig and source code to use Zig instead of C.

(See how I’m switching to first-person plural? That’s how you know I’m personable and writing a guide and not just documenting the random bullshit I tried.)

devkitpro Hello World

Trivial.

$ cp -r $DEVKITPRO/examples/3ds/templates/application/* .
$ make

We get a 3dsx file, which can be uploaded and run on a 3DS via 3dslink. This is the easy part where I just do things the way I probably ought to be doing it to begin with.

Convert the makefile

Then get the actual commands that were run, by rebuilding with V=1.

$ make clean
$ make V=1
arm-none-eabi-gcc -MMD -MP -MF /home/skylar/software/scurvytracker/build/main.d   -g -Wall -O2 -mword-relocations -ffunction-sections -march=armv6k -mtune=mpcore -mfloat-abi=hard -mtp=soft -I/home/skylar/software/scurvytracker/include -I/opt/devkitpro/libctru/include -I/home/skylar/software/scurvytracker/build -D__3DS__ -c /home/skylar/software/scurvytracker/source/main.c -o main.o
arm-none-eabi-gcc -specs=3dsx.specs -g -march=armv6k -mtune=mpcore -mfloat-abi=hard -mtp=soft -Wl,-Map,scurvytracker.map      main.o  -L/opt/devkitpro/libctru/lib -lctru -lm -o /home/skylar/software/scurvytracker/scurvytracker.elf
arm-none-eabi-gcc-nm -CSn /home/skylar/software/scurvytracker/scurvytracker.elf > scurvytracker.lst
smdhtool --create "scurvytracker" "Built with devkitARM & libctru" "Unspecified Author" /opt/devkitpro/libctru/default_icon.png /home/skylar/software/scurvytracker/scurvytracker.smdh
3dsxtool /home/skylar/software/scurvytracker/scurvytracker.elf /home/skylar/software/scurvytracker/scurvytracker.3dsx --smdh=/home/skylar/software/scurvytracker/scurvytracker.smdh

Wow! Horrible long commands. Truly now we are become dweeb, developer of software.

The first command builds an object file with devkitARM’s C compiler. This is the step we’re eventually going to replace with Zig’s C compiler and then Zig itself.

The second command uses devkitARM’s linker to produce an ELF binary. Erik Wastaken had trouble switching this to Zig’s linker, hypothesizing there are some 3DS specific quirks that the devkitARM linker is able to account for but the Zig one cannot, so I am ✨ Not Going To Bother Trying To Do That ✨.

The third command generates a list of the symbols in our ELF file. Erik says this is optional and for my part I can’t see where anything is actually using it, so he’s probably right.

The fourth command generates an SMDH file, which is basically a 3DS application’s metadata.

Then finally, the fifth command patches the ELF binary and the SMDH metadata into a 3dsx file that can be loaded into the Homebrew menu. There are also tools out there that can create CIA files to install directly on the home screen, specifically makerom, which is not packaged with devkitpro. I do want my application to have this in the end, both for the swag and also because you can embed a manual which is accessible via the home menu. But I won’t be bothering with any of that yet, because 3dsx is way more convenient for prototyping.

const std = @import("std");
const builtin = @import("builtin");

const devkitpro = "/opt/devkitpro";
const devkitarm = "/opt/devkitpro/devkitARM";

pub fn build(b: *std.Build) void {
    // WriteFiles step which lets us do all of this in a cache directory
    const wf = b.addWriteFiles();
    const extension = if (builtin.target.os.tag == .windows) ".exe" else "";

    // Compile the hello world to an object file
    const obj = b.addSystemCommand(&.{devkitarm ++ "/bin/arm-none-eabi-gcc" ++ extension});
    obj.addArgs(&.{ "-MMD", "-MP", "-g", "-Wall", "-O2", "-mword-relocations", "-ffunction-sections", "-march=armv6k", "-mtune=mpcore", "-mfloat-abi=hard", "-mtp=soft", "-I/opt/devkitpro/libctru/include", "-D__3DS__", "-c", "/home/skylar/software/scurvytracker/source/main.c" });
    const obj_out = obj.addPrefixedOutputFileArg("-o", "main.o");

    // Link the object file to an ELF binary
    const elf = b.addSystemCommand(&.{devkitarm ++ "/bin/arm-none-eabi-gcc" ++ extension});
    elf.setCwd(wf.getDirectory());
    elf.addArgs(&.{ "-specs=3dsx.specs", "-g", "-march=armv6k", "-mtune=mpcore", "-mfloat-abi=hard", "-mtp=soft" });
    _ = elf.addPrefixedOutputFileArg("-Wl,-Map,", "scurvytracker.map");
    elf.addFileArg(obj_out);
    elf.addArgs(&.{ "-L/opt/devkitpro/libctru/lib", "-lctru", "-lm" });
    const out_elf = elf.addPrefixedOutputFileArg("-o", "scurvytracker.elf");

    // Generate SMDH metadata
    const smdh = b.addSystemCommand(&.{devkitpro ++ "/tools/bin/smdhtool" ++ extension});
    smdh.setCwd(wf.getDirectory());
    smdh.addArgs(&.{ "--create", "scurvytracker", "Built with Zig, devkitARM, and libctru.", "Void Sleeper", "/opt/devkitpro/libctru/default_icon.png" });
    const out_smdh = smdh.addOutputFileArg("scurvytracker.smdh");

    // Create the final 3DSX file
    const dsx = b.addSystemCommand(&.{devkitpro ++ "/tools/bin/3dsxtool" ++ extension});
    dsx.setCwd(wf.getDirectory());
    dsx.addFileArg(out_elf);
    const out_dsx = dsx.addOutputFileArg("scurvytracker.3dsx");
    dsx.addPrefixedFileArg("--smdh=", out_smdh);

    // Copy the 3DSX file to the install directory, leaving all of its precursors behind in the cache
    const install_3dsx = b.addInstallFileWithDir(out_dsx, .prefix, "scurvytracker.3dsx");
    b.getInstallStep().dependOn(&install_3dsx.step);
}

So far so basically identical to Erik’s guide. Why am I writing this again?

Use Zig C compiler

-     const obj = b.addSystemCommand(&.{devkitarm ++ "/bin/arm-none-eabi-gcc" ++ extension});
-     obj.addArgs(&.{ "-MMD", "-MP", "-g", "-Wall", "-O2", "-mword-relocations", "-ffunction-sections", "-march=armv6k", "-mtune=mpcore", "-mfloat-abi=hard", "-mtp=soft", "-I/opt/devkitpro/libctru/include", "-D__3DS__", "-c", "/home/skylar/software/scurvytracker/source/main.c" });
-     const obj_out = obj.addPrefixedOutputFileArg("-o", "main.o");
---
+     const optimize = b.standardOptimizeOption(.{});
+     const target: std.Target.Query = .{
+         .cpu_arch = .arm,
+         .os_tag = .freestanding,
+         .abi = .eabihf,
+         .cpu_model = .{ .explicit = &std.Target.arm.cpu.mpcore },
+     };
+     const obj = b.addObject(.{
+         .name = "scurvytracker",
+         .root_module = b.createModule(.{
+             .optimize = optimize,
+             .target = b.resolveTargetQuery(target),
+         }),
+     });
+     obj.root_module.addCSourceFiles(.{
+         .root = b.path("source/"),
+         .files = &.{"main.c"},
+         .flags = &.{
+             "-MMD",
+             "-MP",
+             "-g",
+             "-Wall",
+             "-O2",
+             "-ffunction-sections",
+             "-march=armv6k",
+             "-mtune=mpcore",
+             "-mfloat-abi=hard",
+             "-mtp=soft",
+             "-D__3DS__",
+         },
+     });
+     obj.root_module.addIncludePath(.{ .src_path = .{ .owner = b, .sub_path = devkitpro ++ "/libctru/include" } });
+     obj.root_module.addIncludePath(.{ .src_path = .{ .owner = b, .sub_path = devkitarm ++ "/arm-none-eabi/include" } });
22c52
-     elf.addFileArg(obj_out);
---
+     elf.addArtifactArg(obj);

Ah, that’s why. A lot of things are the same as Erik’s guide but notably, Zig now requires you to package compiler options and things into a “module”. Also, the horrible code there for adding the include path is because Zig really does not want you to use absolute paths anywhere in your build script for reasons which I cannot even begin to understand. The error message when I tried said something about a LazyPath.cwd_relative which handles it but it does not appear to exist.

This particular build script also gives the warnings:

/opt/devkitpro/devkitARM/arm-none-eabi/bin/ld: warning: ./../db02d4ec2abb95122acf5ee3ab40fee3/scurvytracker.o uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail
/opt/devkitpro/devkitARM/arm-none-eabi/bin/ld: warning: /opt/devkitpro/devkitARM/lib/gcc/arm-none-eabi/16.1.0/armv6k/fpu/crtn.o: missing .note.GNU-stack section implies executable stack
/opt/devkitpro/devkitARM/arm-none-eabi/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
failed command: cd .zig-cache/o/2fb5824d4233e9fe32370ab196a5b16d && /opt/devkitpro/devkitARM/bin/arm-none-eabi-gcc -specs=3dsx.specs -g -march=armv6k -mtune=mpcore -mfloat-abi=hard -mtp=soft -Wl,-Map,/home/skylar/software/scurvytracker/.zig-cache/o/5f7976b54257210ef9d2ed2712a55036/scurvytracker.map ./../db02d4ec2abb95122acf5ee3ab40fee3/scurvytracker.o -L/opt/devkitpro/libctru/lib -lctru -lm -o/home/skylar/software/scurvytracker/.zig-cache/o/5f7976b54257210ef9d2ed2712a55036/scurvytracker.elf

I have no idea what that’s about but it is concerning. The 3DSX file does appear to build properly though, and runs when I send it to my 3DS, so. Problem for future Skylar.

Use Zig linker

I did not attempt to do this. I’ve seen it done in some other guides though so presumably it’s possible, though I am unsure if there’s any real reason to do it.

Use Zig source code

And this is where it all went wrong. It was fairly easy to translate the C hello world program into Zig. It was fairly easy to rewrite the build.zig to compile a Zig file instead of a C file. Except it won’t compile properly:

source/main.zig:3:13: error: C import failed
const ctr = @cImport({
            ^~~~~~~~
source/main.zig:3:13: note: libc headers not available; compilation does not link against libc
referenced by:
    main: source/main.zig:9:5
    main: source/main.zig:8:1
    4 reference(s) hidden; use '-freference-trace=6' to see all references
error: translation failure
/opt/devkitpro/libctru/include/sys/select.h:1:15: error: 'sys/select.h' not found
#include_next <sys/select.h>
              ^

This is baffling because the directory which includes <sys/select.h> ($DEVKITARM/arm-none-eabi/include) is definitely in our include path. I thought maybe it’s the lack of having linked libc, and that using the Zig linker was going to be mandatory after all. So I added a libc.txt and configured the module to link libc, referencing that libc.txt. Same error except the warning about not having libc headers available goes away.

For posterity, here are all the relevant files.

build.zig

const std = @import("std");
const builtin = @import("builtin");

const devkitpro = "/opt/devkitpro";
const devkitarm = "/opt/devkitpro/devkitARM";

pub fn build(b: *std.Build) void {
    // WriteFiles step which lets us do all of this in a cache directory
    const wf = b.addWriteFiles();
    const extension = if (builtin.target.os.tag == .windows) ".exe" else "";

    // Compile the hello world to an object file
    const optimize = b.standardOptimizeOption(.{});
    const target: std.Target.Query = .{
        .cpu_arch = .arm,
        .os_tag = .freestanding,
        .abi = .eabihf,
        .cpu_model = .{ .explicit = &std.Target.arm.cpu.mpcore },
    };
    const obj = b.addObject(.{
        .name = "scurvytracker",
        .root_module = b.createModule(.{
            .root_source_file = b.path("source/main.zig"),
            .optimize = optimize,
            .target = b.resolveTargetQuery(target),
            .link_libc = true,
        }),
    });
    obj.root_module.addIncludePath(.{ .src_path = .{ .owner = b, .sub_path = devkitpro ++ "/libctru/include" } });
    obj.root_module.addIncludePath(.{ .src_path = .{ .owner = b, .sub_path = devkitarm ++ "/arm-none-eabi/include" } });
    obj.setLibCFile(b.path("libc.txt"));

    // Link the object file to an ELF binary
    const elf = b.addSystemCommand(&.{devkitarm ++ "/bin/arm-none-eabi-gcc" ++ extension});
    elf.setCwd(wf.getDirectory());
    elf.addArgs(&.{ "-specs=3dsx.specs", "-g", "-march=armv6k", "-mtune=mpcore", "-mfloat-abi=hard", "-mtp=soft" });
    _ = elf.addPrefixedOutputFileArg("-Wl,-Map,", "scurvytracker.map");
    elf.addArtifactArg(obj);
    elf.addArgs(&.{ "-L/opt/devkitpro/libctru/lib", "-lctru", "-lm" });
    const out_elf = elf.addPrefixedOutputFileArg("-o", "scurvytracker.elf");

    // Generate SMDH metadata
    const smdh = b.addSystemCommand(&.{devkitpro ++ "/tools/bin/smdhtool" ++ extension});
    smdh.setCwd(wf.getDirectory());
    smdh.addArgs(&.{ "--create", "scurvytracker", "Built with Zig, devkitARM, and libctru.", "Void Sleeper", "/opt/devkitpro/libctru/default_icon.png" });
    const out_smdh = smdh.addOutputFileArg("scurvytracker.smdh");

    // Create the final 3DSX file
    const dsx = b.addSystemCommand(&.{devkitpro ++ "/tools/bin/3dsxtool" ++ extension});
    dsx.setCwd(wf.getDirectory());
    dsx.addFileArg(out_elf);
    const out_dsx = dsx.addOutputFileArg("scurvytracker.3dsx");
    dsx.addPrefixedFileArg("--smdh=", out_smdh);

    // Copy the 3DSX file to the install directory, leaving all of its precursors behind in the cache
    const install_3dsx = b.addInstallFileWithDir(out_dsx, .prefix, "scurvytracker.3dsx");
    b.getInstallStep().dependOn(&install_3dsx.step);
}

libc.txt

# The directory that contains `stdlib.h`.
# On POSIX-like systems, include directories be found with: `cc -E -Wp,-v -xc /dev/null`
include_dir=/opt/devkitpro/devkitARM/arm-none-eabi/include

# The system-specific include directory. May be the same as `include_dir`.
# On Windows it's the directory that includes `vcruntime.h`.
# On POSIX it's the directory that includes `sys/errno.h`.
sys_include_dir=/opt/devkitpro/devkitARM/arm-none-eabi/include

# The directory that contains `crt1.o` or `crt2.o`.
# On POSIX, can be found with `cc -print-file-name=crt1.o`.
# Not needed when targeting MacOS.
crt_dir=/opt/devkitpro/devkitARM/arm-none-eabi/lib/armv6k/fpu

# The directory that contains `vcruntime.lib`.
# Only needed when targeting MSVC on Windows.
msvc_lib_dir=

# The directory that contains `kernel32.lib`.
# Only needed when targeting MSVC on Windows.
kernel32_lib_dir=

# The directory that contains `crtbeginS.o` and `crtendS.o`
# Only needed when targeting Haiku.
gcc_dir=

main.zig

const std = @import("std");

const ctr = @cImport({
    @cInclude("stdio.h");
    @cInclude("3ds.h");
});

export fn main(_: c_int, _: [*]const [*:0]const u8) void {
    ctr.gfxInitDefault();
    defer ctr.gfxExit();

    _ = ctr.consoleInit(ctr.GFX_TOP, null);
    _ = ctr.printf("Hello, world!\n");

    while (ctr.aptMainLoop()) {
        ctr.gspWaitForVBlank();
        ctr.gfxSwapBuffers();
        ctr.hidScanInput();

        const kDown = ctr.hidKeysDown();
        if (kDown & ctr.KEY_START) break;
    }
}

In conclusion

Well I guess it probably won’t kill me to write some C++. But this actually might kill me.

Evangelical Christianity is Founded on Contradictions

Wed, 03 Jun 2026 00:00:00 +0000

I’m sure this has already been written about and in much greater detail, but having just encountered some Jehovah’s Witnesses proselytizing in the subway, I felt like I had something potentially useful to say. Anyone who has interacted with American evangelicals has probably noticed that there is very little they can say to challenge their beliefs. It seems like they have an answer for everything. The answers can be picked apart rationally, of course, but even when you do, they don’t seem to notice or care. The main reason for this, in my experience as a former Southern Baptist, is comfort with cognitive dissonance. Evangelicalism teaches its followers to accept and internalize contradictions.

The example that motivated me to write this is how evangelicals view their interactions with non-believers. Evangelicalism maintains, simultaneously, that:

Evangelical belief is popular and in the majority; it’s what “normal people” believe.
Evangelical belief is unpopular and in the minority; it is actively suppressed and believers are hated by mainstream culture.

Individual evangelicals might resolve this contradiction in different ways, of course. Maybe one thinks belief is the default, but still unpopular due to the dominance of secular indoctrination. Maybe another thinks belief is popular, but those hostile to it have outsized power and influence. But ultimately the ideology preaches the contradiction. Believers hear both in equal measure, and if they keep up church attendance, they get used to hearing it. Eventually they stop noticing it’s a contradiction.

And then, when they go out to proselytize, there is no way to interact with them that challenges the ideology. Anything you say, do, or fail to say or do, reinforces one or the other contradictory tenet, and thus the ideology as a whole. If you are polite and cordial, if you engage with their ideas genuinely, you reinforce that their beliefs are normal and popular. (“We planted a seed today,” they’ll say afterwards.) If you’re hostile, argumentative, or completely ignore them, it’s proof that they are being persecuted. (“God really showed us today how much these people need him, how important our work is”, they’ll say afterward.) In the words of Dan Olsen, “they can use the whole bird.”

This trick only works because of the contradictory nature of the belief system. If it held only that evangelical belief is popular and in the majority, then hostility would make it clear that wasn’t true. If, conversely, it held only that evangelical belief is unpopular, then politeness and good-faith discussion would challenge the ideology. But it doesn’t hold one or the other, it holds both simultaneously.

It’s also definitely not a coincidence that contradiction is at the core of fascism; Umberto Eco famously writes that one of its characteristics is the belief that “the enemy is both strong and weak.” Cognitive dissonance is a core component of every ideology founded on high-control social groups. Which makes sense; these ideologies are rarely coherent, and as mathematics tells us, if you accept a contradiction you can prove anything.

My ideal programming ecosystem

Tue, 26 May 2026 00:00:00 +0000

Over the past few days I’ve spent a lot of time thinking about programming languages. What do I want out of them? How do I think they should work? Do any of the existing options meet those criteria? That kind of thing. So here is a ramble about what I want out of programming languages.

First, I think a language is harmed when it tries to cover too many use cases, or do too many things at once. Rust, for example, is trying to be high-level and low-level at the same time. The versatility this provides is useful, to be sure, but it means that when writing high-level applications you’re forced to think about details like move semantics and lifetimes. This complicates the process of writing Rust software, and also means Rust itself is not as simple to implement as it could be. The trade-off, of course, is that you gain access to those high-level features in low-level Rust, and that every application written in Rust is resource-efficient by default.

The main area where this conflicts with my needs is in the realm of permacomputing. For that, I want simple languages, capable of being understood and hacked on by a single person. Modern industry might benefit from a language with “batteries included”, but it also means that the language cannot exist without the support of that industry.

Hare is a language that seems to meet this concern, designed to remain small and simple, and using the “hobby-scale” backend QBE. Having worked with Hare, however, I feel that it both does too much and not enough. It’s simple, sure, but the complexity it does add doesn’t feel like it buys you much, it’s still a pretty bare environment to work in.

Haskell is another language I’ve looked at. It’s this beautiful, elegant core of a language kneecapped by a preponderance of features, a significant divergence between best practices and the standard library, and generally unimpressive performance from compiled code due to its runtime and garbage collector. Its origins as an academic language to study lazy evaluation ends up really hurting attempts to actually use it; it turns out lazy evaluation is only a good idea in a few scenarios.

All of this has led me to conclude that my ideal programming language needs to actually be two programming languages designed to interoperate well. The first would be a low-level language with minimal abstractions, just enough features to help the programmer avoid common footguns. The second would be a functional language with an expressive static type system, automatic memory management, and full metaprogramming enabled by homoiconicity. Calling the low-level language from the high-level one should be effortless. Let each language do one job well, rather than writing one language that tries to do both and suffers for it. And crucially, the high-level language should be adaptable via macros rather than try to integrate every possible feature a particular use case might need or want.

I’d like to design and implement a pair of programming languages fitting this description! Once I have a cohesive idea how they’d work, I’ll post the rough outline of the design.