Fun with the Sharp Zaurus SL-5500 (and an unexpected OpenBSD link)

[liam_on_linux]

The Zaurus SL-5500 was an early, tiny, Linux pocket computer-cum-PDA. I had one. Two, in fact. They got stolen from my house. :-(

It had a CF card slot, so you could even remove your storage card and insert a CF Wifi card instead, and have mobile Internet in your pocket, 20 years ago!  

But if you did, you got a free extra with a wifi adaptor – a battery life of about 15-20 minutes.

It was clever, but totally useless. With the wifi card in, you couldn’t have external storage any more, so there was very little room left.

I had to check: https://uk.pcmag.com/first-looks/30821/sharp-zaurus-sl-5500

64MB RAM, 16MB flash, and a 320x240 screen. Or rather 240x320 as it was portrait.

The sheer amount of thought and planning that went into the Linux-based Zaurus was shown by the fact that the tiny physical keyboard had no pipe symbol. Bit of a snag on an xNix machine, that.

Both mine were 2nd hand, given to me by techie mates who’d played with them and got bored and moved on. I'm told others got better battery life on Wifi. Maybe their tiny batteries were already on the way out or something.

Fun side-note #1: I do not remember the battery pack looking like this one, though. I feel sure I would have noticed.

https://www.amazon.co.uk/Battery-Zaurus-SL-5500-900mAh-Li-ion/dp/B007K0DRIU

Fun side-note #2: both came with Sharp’s original OS, version 1.0. I had an interesting time experimenting with alternative OS builds, new ROMs etc. Things did get a lot better, or at least less bad, after the first release. But the friend who gave me my first unit swore up and down that he’d update the ROM. I can’t see any possible mechanism for flash memory to just revert to earlier contents on its own, though.

With replacement OS images you had to decide how to partition the device’s tiny amount of storage: some as read-only for the OS, some as read-write, some as swap, etc. The allocations were fixed and if you got it wrong you had to nuke and reload.

This would have been much easier if the device had some form of logical volume management, and dynamically-changeable volume sizes.

Which is a thought I also had repeatedly around 2023-2024 when experimenting with OpenBSD. It uses an exceptionally complex partitioning layout, and if you forcibly simplify it, you (1) run up against the limitations of its horribly primitive partitioning tool and (2) reduce the OS’s security.

I have got just barely competent enough with OpenBSD that between writing this in early 2022 and writing this in late 2024, two and a half years later, I went from “struggling mightily just to get it running at all in a VM” to “able with only some whimpering and cursing to get it dual-booting on bare metal with XP64, NetBSD, and 2 Linux distros.”

But it’s still a horrible horrible experience and some form of LVM would make matters massively easier.

Which is odd because I avoid Linux LVM as much as possible. I find it a massive pain when you don’t need it. However, you need it for Linux full-disk encryption, and one previous employer of mine insisted upon that.

In other words: I really dislike LVM, and I am annoyed by Linux gratuitously insisting on it in situations where it should not strictly speaking be needed – but in other OSes and other situations, I have really wanted it, but it wasn’t available.