esoterica

Quite recently, postmarketOS dropped support for armhf, citing lack of maintenance and it generally falling into disuse. The general community response was “well that's a shame… though I wouldn't maintain it myself”.

And that's not entirely unreasonable! armhf is Alpine's architecture for ARMv6 SoCs with a hardware floating point. We're talking about devices with one core, clocked at a few hundred megahertz, with maybe up to 512MB of RAM if you're lucky (usually it's 256MB or less) and similarily small amounts of internal storage, which are starting to get old and hard to come by.

Hardly any modern software runs on that kind of hardware. On 256MB of RAM, you could run XFCE4 and only have about 100MB left for apps. My Firefox window uses 12 times that.

These devices are nothing more than a weird curiosity now.

But it used to be plenty enough for apps! Android 2 ran on that like butter. Old phones had a fraction of that power, and were able to do many of the same things that we do today (well, maybe except for web browsing).

And the bar for what makes a “legacy device” keeps creeping ever higher. 1GB of RAM is already a tiny amount. Heck, even my Samsung Galaxy A5 (2015), with 2GB of RAM and a 64-bit ARM SoC is underpowered by today's standards.

What can we do with these underpowered devices? Permacomputing tries to find an answer; but most of the projects around it seem to be things like “custom programming languages” or “low-tech/off-grid communication tools". These are cool, but not necessarily what I'm looking for.

We need modern, daily-drivable software that will work on existing, resource constrained devices.

Scope#

The road for this has been paved by postmarketOS - a Linux distribution primarily for mobile devices, building upon Alpine Linux. pmOS's goal nowadays is to create a modern operating system for mobile devices, which means they usually test on newer, more capable hardware.

This means they end up making choices that, as a side-effect, make maintaining older devices more difficult (for example, adding various things to the initramfs and required kernel modules that make kernels difficult to fit on devices with 8MB boot partitions). This is not a bad thing, nor is it something that is being done deliberately (in fact, the project is very patient with us early 2010 device maintainers!).

I think it would be cool to have a project that explicitly focuses on older devices, though. I would put the exact range at around 2008-2015 (and maybe low-end devices going into 2017 or thereabouts).

This still leaves us with roughly three “periods” of phone hardware evolution, each of which roughly doubled the power of the last:

  • The PDA and early smartphone era, 2008-2011.
    • 128-256MB RAM, 512MB storage, single core CPUs. armhf, occasionally armv7 or soft-float.
  • The prime ARMv7 era, 2012-2014.
    • 768MB-1GB RAM, 8GB-16GB storage, dual-core CPUs. armv7.
  • The early ARMv8 era, 2014-2015.
    • 1GB-2GB RAM, 16GB storage, quad-core CPUs. aarch64.

Another notable hardware target from that period is netbooks (2009-2012).

I think if we're already talking about “weird old hardware”, we're missing a pretty big chunk of devices from the early 2000s, and “exotic” architectures like soft-float ARM (like ARMv5 and older) and MIPS. Supporting those devices might be a tall order, though - we'd be looking at 32-64MB RAM.

For now, I'd focus on testing the viability of the time period I suggested. If we can go down even further with resource usage, that's a very welcome bonus. Plus it means we don't have to bootstrap new architectures… yet :) 

Esoterica Linux - distribution#

Alpine Linux is a pretty good distribution for supporting weird, small hardware - a base install with desktop utilities can be tuned to around a few hundred megabytes. postmarketOS is based on Alpine, so we can learn from their approach.

pmOS adds a lot of their own additions, though - like systemd support and a huge list of suggested kernel modules for mainline kernels - which we can do away with on resource-constrained devices.

Making a custom Alpine-based distro should not be too difficult, since we can learn from pmOS.

It would probably be nice to have a development utility similar to pmbootstrap, but maybe avoiding some of its most annoying pain points:

  • being able to work only on one device at a time, with switching being a bit of an ordeal (luckily this is apparently being worked on);
  • its somewhat confusing image generation (pmboostrap install takes the --disk parameter to flash to an SD card; or you can flash to a device by first doing install then flasher flash_rootfs and flasher flash_kernel, but you only do flash_kernel if your device requires it, and you might need to flash lk2nd or similar for some devices first. How do you succintly explain that on a single Installation page?)

In my head I call it Em the Wizard because you could make a mascot for it called Em the Wizard, and I think more software should have mascots[1].

Close-to-mainline Linux kernel fork#

Interestingly enough, the Linux kernel itself is going away from legacy device support. Support for the (admittedly obscure) ARM11 MPCore variants used in the Nintendo 3DS got dropped in late 2023. They're planning to get rid of ARM1136r0, which would make my efforts to run mainline Linux on the Samsung Galaxy Y futile (edit: the BCM21553 actually seems to have an ARM1136r1 core, so it's spared from the removal).

We'd probably need to maintain a kernel fork where we keep these architectures alive and make sure that the code is in good condition upstream as well.

eden UI#

Most modern UI toolkits are pretty heavy. The average GTK app uses about 100MB on idle. Qt (with standard QtWidgets), while being more performant, also uses 100MB. (QML apps are a heavier beast, with QML basically being its own programming language on top of Qt, but I don't have any apps installed to look at the numbers.) This is nothing to say of Electron apps, which use about 250-350MB each.

In terms of lightweight UI toolkits, we do have some options, like imgui. Most of these options, however, are immediate mode UIs, which function pretty differently from the likes of GTK and Qt - you have to manage your own main loop, and call a series of functions on every frame to re-build the UI. It's probably fine for a simple debug GUI in a game, but it would probably get very annoying if you tried to actually build an app.

I have opinions on UI toolkits.

  • I think UIs are a data shaped problem and should not be declared in code (you can already see why I'd be somewhat sceptical of imgui; I quite like GTK's UI files, which declare the UI in separate XML, similar to HTML; or, even better, Blueprint which introduces a much friendlier and less verbose syntax for them).
  • I think UIs should be malleable and customizable (GTK fits this very well with its CSS theming).
  • I think common UI patterns like responsivity or switching between tabs or showing popovers and menus should be handled by the toolkit (GtkStack and Adwaita's many widgets).

Maybe I like GTK. Maybe I really like GTK. So what?!?!?

GTK is good. It just suffers from being bound to glib/GObject (a necessary evil given its C heritage; GObject is generally speaking not that bad, but it does make working with GTK in other languages slightly more annoying), and being somewhat slow, and not having OpenGL 2.0 support anymore (making them impossibly slow on all the 2015-and-older hardware I mentioned earlier), and useful features like clamps and breakpoints being part of libadwaita instead of base GTK4.

Ahem. What were we talking about again? Ah, right, I want to write my own GUI toolkit, and a suite of apps/desktop environment for it.

I'll probably write it in Zig, because writing C in 2026 seems unwise, I like that it can directly integrate with C libraries, and Rust is scary.

Web browser#

And once we have a lightweight GUI toolkit, we can write a similarily lightweight web browser.

This is a bit of a ridiculous goal, given that the web platform is so vast and wide writing a fully compatible web browser will inevitably cause it to bloat up to huge proportions. But consider this. If Dillo can get another life, then another Dillo, but written in Zig, and with Flexbox and Grid support… (Does Dillo support Flexbox and Grid?)

  1. ^

    GNOME doesn't have a mascot. That is, except for its foot logo. Look at what that's making people do.