Klaus on Tilde Town

Old Computer Challenge 2025 - ARM'd and Dangerous!

A raspberry pi with the netbsd logo overlaid

It's that time of the year again: the Old Computer Challenge 2025 edition! It's late, but well, here it is!

Having participated twice over the years (with a quite large gap in between), I decided that this time I'd take a different approach, both in hardware and software. After giving it some thought, I decided to jump in the challenge head first, and do it with the Raspberry Pi Model B running NetBSD 10.

The plan

After two challenges done with that ol' single core laptop from 2010, I wanted to do something a little more "raw" than your standard "old PC catching dust in the shelf," I decided to fish out the Raspberry Pi Model B from 2012 that I found while dumpster diving and making it my daily driver for the challenge. Surely it isn't very old age-wise, but it does have that late 90s / early 2000s vibe: 700MHz single-core CPU, and the just fit of 512MB RAM for the challenge.

Then came the question of the OS; what should I try on top of it that is not, say, Alpine Linux like last time? I went out looking for different lightweight distributions to try on it, but the hardware became a something of big hurdle on it. Not many distros offer support for the ARM architecture, and the Pi 1's specific CPU (armv6 or armhf depending on the notation) is a dying breed in the niche, since no new SBCs come with it.

So how about not using Linux at all? I would have loved to have FreeBSD running on it, as it was the computer that taught me the basics of FreeBSD when I first used it, but alas, they also dropped armhf from their supported architectures. So what to do? Well, if there's anything that could run on a high-end toaster, it has to be NetBSD. Surely it would support the Pi 1, right? Surely enough, there it was, under the name evbarm6.

I thought no further. Having the original Raspberry Pi set up with NetBSD sounded like peak Old Computer Challenge, so I dove in - head first.

Setting it up

Pre-boot

Basic things first, go to NetBSD's website and download the right image file for the Pi. For my Model B, this is the link to the correct rpi.img.gz file. This gives me an up-to-date NetBSD installation by default, which is nice compared to other OSes like Debian, whose latest tested Raspberry Pi images sometimes date from 2023.

After burning the image to a full-sized SD card (This is the Pi1, after all), I took an extra step just before popping it in and booting the Pi. Still with the SD card plugged into my computer, in the file /boot/config.txt, I added the following lines:

hdmi_group=2
hdmi_mode=82

These legacy options configure at boot time the resolution to match my monitor's 1920x1080 px. There are several others available, including overclocking options, but I'm not interested on those for this challenge.

And with this, I 'm ready to fire it up.

Housekeeping

The first boot takes much longer than the subsequent ones. This is because NetBSD takes that opportunity to resize the .img's filesystem to fill out the entire SD card, and then reboot again properly.

You're greeted with a fairly minimalistic console environment, which feels lacking even for those who spend a significant time working in the command-line. It seems that it's deliberately set up this way because NetBSD needs to support a wide spectrum of hardware which may have humble capabilities, so the default console is bottom-levelled to only support the common things that even the feeblest termninals can offer.

Now, I'll be the first to say this: I didn't like it. Not the least. It's an up-to-date OS that I'm using in 2025; I expect the console to at least show me colors! But luckily there are some ways to work around the situation.

First and foremost, use the root account to bootstrap the very handy pkgin tool to manage binary packages, as seen in the NetBSD pkgsrc guide:

# Note: the case in this URL is actually sensitive!
PKG_PATH="https://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/x86_64/10.1/All/"
export PKG_PATH
pkg_add pkgin
pkgin update

The minimalism of NetBSD means that the only really usable shell in the default install is /bin/sh. The /bin/csh available might sound like a proper c-shell, but lacks robust interactivity features. So install a real user shell, like tcsh or bash:

pkgin install tcsh
chsh -s /usr/pkg/bin/tcsh

Next, if you have typed these commands so far, chances are that you noticed that keys like Backspace, Delete, Home, End and arrow keys do not do what they are supposed to do on a normal system, and instead print control characters to the screen. A real shell helps, but a little further configuration might be necessary. If you're using tcsh, add the following to ~/.cshrc:

# Fix delete key not working:
bindkey ^? delete-char
bindkey "\e[3~" delete-char

If you're using bash, the defaults should get you going for now. Also, bump up the console drivers to make it more palatable:

# Change keyboard repeat speed to faster settings.
setvar  wskbd   repeat.del1 250
setvar  wskbd   repeat.deln 40

These should make the experience a lot better.

Daily driving it

A complex console session in NetBSD, with many tmux panes and windows open with TUI applications doing their things floats between the 215 and 230 MB mark. That number might not sound very impressive at first if you've used Alpine Linux or even Debian in a console-only way, where that number might not even go beyond 100MB.

However, I think this is a sort of "buffer" pool of memory that NetBSD allocates to accommodate everything within a certain threshold. The reason I think so is because starting new processes and opening new programs doesn't change the amount of RAM used as reported by htop, so maybe NetBSD is just reallocating things in the background? Remains to be confirmed.

I tried to use my usual stack of command-line applications for this: elinks for browsing, mc for viewing and managing files, vim as the editor, etc. but I soon ran into a few small surprises early on. First, some of my usual applications were missing: no tut to access Mastodon? Can't install newsboat? That was strange... But I could try to work around those by using alternatives most of the time.

For XMPP IM in the console, I thought to try finch (the TUI version of Pidgin), but for some reason pkgin wanted to pull over 200MB of dependencies for it, including dbus. Again, this wouldn't be too much a problem in a standard computing environment, but this Pi has very limited CPU power and low disk IO, which means installing packages takes a lot of time. No thanks, let's keep the system slim. Thus, I went with an old friend I knew from 2014-ish: mcabber. The classic irssi worked well for IRC as usual, and browsing with Elinks was probably the best experience I could have under those conditions.

Out of that situation, one application stood out for bad user experience. That was Mutt, which I've been using for handling emails for a decade now. On the Pi 1, switching between mailboxes is particularly painful, because Mutt processes the headers of every single message - not just the new ones - before presenting you the Inbox. Coupled with the Pi's sub-GHz low-power single-core CPU it took upwards of 30 seconds to do a simple mailbox switch (and not read so much as a single email!). I'm sure there could be a way to minimize this checking (through OfflineIMAP, for example), but I didn't have time for this overhead.

This workflow persisted for about 5 of the 7 days of the challenge or so, and I was sort of getting bored of looking at the NetBSD console by that time. And then I had an idea: if I'm using a maximum of 230MB out of 430 MB usable RAM, could a graphical session fit within this remaining 200MB? Well, there's only one way to know!

The ultimate challenge: Going Graphical on the Raspberry Pi 1

My first question was: how does one install Xorg / X11 on NetBSD?

A quick search with pkgin was fruitless; "xorg" only appears in things like documentation, prototypes and something called "modular xorg," which does not seem to be what I'm looking for. I could even find a Window Manager of my liking alright (I ended up with JWM), but not Xorg itself!

I was about to give up the task of installing Xorg and wrap up the post when I had an epiphany: for some reason, I typed in the following:

$ which startx
/usr/X11R7/bin/startx

Wait, what?

$ which Xorg
/usr/X11R7/bin/Xorg

Yup, that's exactly what you're thinking.

kzimmermann, you dummy: Xorg was already installed in NetBSD from the beginning! It's an integral part of the Operating System, and that's why you don't install it! So with that out of the way, could a simple startx work out of the box?

Turns out yes! - just make sure you have the directory /usr/X11R7/bin added somewhere in your $PATH.

Running this command loaded the nostalgic CTWM window manager by default (a fork of the classic twm present in Linux's Xorg package), and interestingly enough, the moment it came up all my problems with the console's behavior basically went away. That's right: it seems that NetBSD is downright intended to be used through a graphical environment, even if all you need is xterm in the end! The performance was much better too: ironically, everything from the refreshing and redrawing of the terminal contents to the behavior of the programs got better.

And to what cost, you may ask? Well, RAM increased to about 260MB after this. So, 30MB of RAM to pay for what basically transitioned a clunky console workstation into a surprisingly usable desktop. But I wasn't done quite yet.

Reviving my last Old Computer Challenge's spirit, I decided to buff the load on this Pi. How many more graphical applications could I run on it and still have it usable on 512MB and no swap? Turns out it's quite a lot. Here's a list of what I was able to pull off:

And miraculously, the RAM didn't go upwards from 260MB even with all of this loaded! Looks like NetBSD's "pooling" feature was working very well. One major improvement at this stage was my emails: sylpheed was much faster than Mutt in switching inboxes, and it finally felt more or less normal.

At some point, I decided to really stretch it out and try editing a word document via Abiword, which is doable, but also really slow. It proves a point (yes, you can run a word processor in the Pi1) but I feel pity for whoever really has to do such thing. So that was it, after this last stretch, I guess I can finally put the challenge down now.

Here's a picture of the final setup!

raspberry pi 1 running NetBSD and a full graphical session

close up on the terminal running fastfetch

Conclusion

The 2012 Raspberry Pi Model B is a remarkable but severely underpowered machine for those looking to build a desktop out of it. And yet, with a little patience, it can still do part of that duty when running NetBSD!

If you're interested in trying out NetBSD, either on an SBC like the Pi or a more standard machine, this is what I suggest you to do:

The OS that can run on toasters truly surprised me, and I will say that it gained a special part on my heart. Since finishing the challenge, I've taken NetBSD 10 for a ride and installed it in two more test devices: my Pi 4 and an old laptop I've got. And what can I say; if it ran already surprisingly well on the Pi 1, it's a whole lot better on the more powerful hardware. It's become my favorite BSD, and I'll definitely be exploring it more in the future!

Final software stack

Have you ever tried NetBSD on a Raspberry Pi? How was your experience? Let me know on Mastodon!

Last updated on 08/06/25