💾 Archived View for tilde.town › ~mio › log › 2024-07-13-occ-2024.gmi captured on 2024-08-18 at 17:54:22. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
---
date: 2024-07-13T02:57:30Z
update: 2024-07-19T04:27:00Z
---
It's that time of year again. The Old Computer Challenge is back this year with a DIY edition inviting people to set their own conditions for the week-long event of using an old computer. Thanks to the organisers solene, Headcrash, prahou and Tekk for hosting the event, updating the communication channels and livening up community participation.
This year's parameters:
Potential activities:
More details about the Raspberry Pi can be found in the Wikipedia entry so they will not be listed here. The minor things to note are:
1. the use of an armv7 image although the Pi 3 is 64-bit capable, to run some test builds for 32-bit arm without invoking cross-compile flags
2. the "headless" server is not entirely detached — the cheat applied is a low-resolution remote desktop session over an armv7 notebook acting as a low-framerate monitor
3. the Void Raspberry Pi images being 2 GB in size conveniently provides an inconvenient OCC disk size limitation
A 2 GB disk translates to 1.5 GB left for packages and home directory after installing the base system and boot partition. Once upon a time a 4 GB hard disk for a consumer-grade PC was considered roomy. Today it is common for application executables to run upwards of 70-100 MB alongside small packages 1-5 MB in size. Disk space could become an obstacle for an app hoarder like me.
This post will be updated over the course of the week.
i3 desktop at a resolution of 800 x 600 px over the RDP session
This is my third year participating in the challenge, and while reading about various intriguing plans others had in the #oldcomputerchallenge internet relay chat (IRC) channel, it occurred to me there is one point which may not have been conveyed clearly in my logs from previous years.
For me, the OCC is a glimpse into the future, not a return to the past.
One case for reviving older hardware is to better understand where modern computing stands in relation to its past, what older technologies did well or less well, and building on the positive aspects of personal computing in the present and future.
My adjacent interests in tildes and small net protocols stem from their potential to form stable communities for learning, mutual support, and exchange of creative ideas. Having functional and effective digital tools that enable collective participation and individual autonomy extends that potential.
Tinkering can be therapeutic, and there is nothing wrong with playing on a piece of old kit for a few hours while reminiscing about that first computer or handheld received as a birthday present. Retrocomputing can be an interesting hobby. It does not mean everything was better in bygone days.
My OCC forays have focused on optimising utility and doing the occasional odd thing to see how the device handles it, rather than the pursuit of an authentic experience of the original software/hardware as one package. There are the occasional brief moments of nostalgia, but my view may be in the minority who think it is more helpful to highlight active open software and projects, given they do not come with restrictions on disassembly and sharing for educational purposes which closed software with end user license agreements (EULAs) often have. Another factor is whether the devices will be connecting to the internet, and installing an updated system where available, since old software/firmware could contain security vulnerabilities as internal and third-party scrutiny shifted to newer versions and any serious bugs may remain unfixed. Airgapped devices including for a fully offline challenge or historical research are possibly among the few exceptions. However, people should be able to assess the risk for their circumstances — to each their own.
Initially my target device this year was a Nintendo 3DS, not a Raspberry Pi, but the current development status was not promising even if the device were to successfully scale the hurdles of triggering the browser-based exploit, installing Luma3DS, and assembling the boot partition and rootfs from 4 different tools. Non-working wifi put a damper on the plan and incidentally was also a recurring pattern in subsequent tests on the Raspberry Pi 1 B+.
Five days leading up to the event week were spent looking for a stable OS with wifi for the Raspberry Pi 1 B+, then for the Pi 3 B when the Pi 1 outfitted with a USB wireless adapter could not connect to a network, had no ethernet or monitor output, or fell into an unknown state where it was unclear whether it had booted at all.
My arbitrary criteria for OS selection may have made it more difficult to find a match. Alpine is still a decent option for Raspberry Pi 2+ devices (no armv6 support for Pi 1), but was looking to trial a different OS, also without systemd. (Not out of contempt for systemd, merely that other components it replaced tend to be simpler to configure without the complexity systemd is made to support.) Wireless connectivity is another requirement as the alternative would involve sharing a connection over ethernet with another computer that had an ethernet port and adding an extra hop, which is suboptimal.
The shortlist:
1. NetBSD
Impressed with the number of architectures it supports and for which it provides boot images. Regrettably it did not work out in the first attempt, maybe next time.
2. OpenBSD
The OS of choice for the OCC founder and organisers. Previously enjoyed reading the OpenBSD zine and OCC seemed like a timely opportunity to see the BSD sights. The arm* images turned out to be unsuitable for my setup. Going with plain x86_64 in the future.
3. Chimera Linux
Had been looking forward to trying Chimera, which presents itself as a modern, simple to use, portable OS employing the latest developments in packaging and tooling, including utilities from FreeBSD. No luck so far. Maybe the image was not properly flashed to the card.
4. Void Linux
Was previously aware of Void as another Musl C distro alongside Alpine and Chimera, but had not planned on trying it this year until wsinatra reminded me of it. Thanks to his suggestion, the search stopped at this point and configuration could proceed on day 0.
The other two on the list were 9front (which wsinatra had also recommended) and RiscOS, but did not have enough time to attempt a test before the challenge started.
ip link set dev wlan0 up ip addr add [device-ip]/24 dev wlan0 ip route add default via [gateway-ip] dev wlan0
wpa_passphrase [ssid] [pass] >> /etc/wpa_supplicant/wpa_supplicant.conf
Installed X server with i3 window manager and freerdp to run GUI apps on a one-off basis over a remote desktop protocol (RDP) connection, exiting a session afterwards to free up RAM. Also included a few GUI apps that one might find in a desktop environment, e.g. feh (to set desktop wallpaper for screenshots), i3status (status bar), rofi (app launcher). i3 likes to look for a default terminal emulator, xterm or similar will work.
xbps-install freerdp freerdp3-server xauth xf86-input-evdev \ xf86-input-libinput xf86-input-synaptics xf86-video-dummy xinit xorg-fonts \ xorg-server xterm xbps-install feh i3 i3status rofi xfce4-terminal xrandr
winpr-hash -u [rdp-user] -p [rdp-pass]
mkdir /etc/winpr echo "[rdp-user]:::[winpr-hash]:::" >> /etc/winpr/SAM
echo "allowed_users = anybody" >> /etc/X11/Xwrapper.config
Section "Device"
Identifier "Configured Video Device"
Driver "dummy"
EndSection
Section "Monitor"
Identifier "Configured Monitor"
HorizSync 31.5-48.5
VertRefresh 50-70
EndSection
Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "800x600"
EndSubSection
EndSection
freerdp-shadow-cli3 /sec:nla
#!/bin/sh
# Usage: ./rdp.sh start|stop
start_rdp() {
nohup startx >/dev/null 2>&1 &
nohup freerdp-shadow-cli3 /sec:nla >/dev/null 2>&1 &
}
stop_rdp() {
pkill -f freerdp-shadow-cli3
pkill -f i3bar
pkill -f i3
pkill -f Xorg
}
case "$1" in
start) start_rdp;;
stop) stop_rdp;;
esac
Had ~938 MB left after setting up X server, freerdp, i3 and friends. Loaded the usual roster of CLI/TUI apps:
Gave up the following apps for the week due to the required storage size:
Got 789 MB left if the package cache is cleared, a little over half of that otherwise.
# df -h Filesystem Size Used Avail Use% Mounted on /dev/root 1.8G 1.2G 489M 71% / # du -h /var/cache/xbps 300M /var/cache/xbps
Faced again with the scenario of not having a good way to read and reply to comments on a GitLab CE instance from a terminal interface or a light browser. Maybe there are CLI/TUI clients now. A fallback to luakit or qutebrowser over RDP, if not entirely paralysed by lag. Further testing is in order.
Otherwise spent much of the time writing this post in vim over SSH.
Caught up on updating the post for the past few days including Day 0.
Tried to doodle on AzPainter, but that quickly fell apart due to considerable lag, aside from the lack of stylus pressure sensitivity. Most stroke do not appear until one to five seconds after the stylus was lifted. Buttons took three to ten seconds to register.
How about pixel art? Installed Grafx2, only for it to segfault on launch. mtPaint was less beset by lag, though not by much.
Vector? Xfig's interface started up immediately, and was as unusable as Azpainter for a similar reason.
Before giving up on the idea entirely, switched to running a VNC server for comparison — the difference was night and day. There may be an occasional half-second delay at the start of a series of actions, but otherwise the display was like a monitor directly attached to the device. Strokes in both AzPainter and mtPaint were much smoother, button and menu selection feedback were almost immediate.
Screenshot of mtPaint over RDP
Screenshot of AzPainter over VNC
The contrast between RDP and VNC may be down to whichever implementations of both happened to be available in the repos. Freerdp3 did seem CPU-bound, running between 40-51% CPU when there is activity, dropping to ~1-13% when idle. x11vnc was at ~0.23%, <1%.
Tried tigervnc server first but could not get it to run. After mapping a display to a user in /etc/tigervnc/vncserver.users and setting an access password, running `vncsession [user] :0` resulted in a `Failed to start session` error. Maybe it needed the `$DISPLAY` variable passed in like x11vnc, as it is not automatically set without an actual monitor.
Two minor detracting points, also application-specific:
1. The x11vnc server exits when the user disconnects from the session. There is likely a flag that can be enabled to keep it running after a session disconnect with a bit of searching. This would synchronise better in the shell script to bring both the display and VNC servers up or down near-simultaneously. Update 2024-07-15: the `-forever` or `-many` flag keeps the server listening indefinitely. In the shell script, set `DISPLAY=:0` before invoking the x11vnc command with nohup.
2. Neither spiritvnc nor the tigervnc client at the other end have a toggle for keyboard passthrough like in nemmina (the RDP client mentioned earlier) or novnc (a web-based VNC client). In most cases this is probably desirable and the client-server bridging feels simpler to use. However, in this particular setup, both server and client computers shared similar i3 keybindings which meant that the key combinations were captured by i3 at the client side rather than the i3 inside the VNC session. The simplest workaround was to add two to three alternate keybindings for the Pi's i3 config for actions like bringing up the app launcher to still be able to run apps, or reload i3 to apply config changes. (For people unfamiliar with i3, it does not come with an application menu like the ones accessed from a button on the menubar in legacy Gnome or Xfce desktop setups, or a Fluxbox-style right-click menu, being generally keyboard-driven.)
Kudos to Void and maintainer mobinmob for carrying mtPaint in the repos. Alpine has Pinta (the package there is currently orphaned), which Void does not, no mtPaint yet. As a paint program for a lower-spec device, mtPaint is the lighter choice. (Random aside: liking that `xpbs-query [package]` includes the package maintainer in the information.)
Still very slightly off-kilter without stylus pressure, but it can be somewhat compensated with a few settings. In AzPainter, lowering the flow density in a water brush also helps emulate variable stroke opacity, which is a characteristic of different pressure levels. Stroke tapering is likely in the one of the windows that were minimised due to the miniature — compared with today's widescreen and 4K monitors — screen estate. A pale shadow of stylus pressure dynamic, but certainly better than nothing.
Here, have a doodle! It is not very good at all, but it might dispel the myth in the OCC IRC channel that noone participating in the OCC has created anything. And annoy a certain talented, temporarily xorgless artist who seems to relish drawing Tux small(er than Fugu) and cute.
Portrait of the Penguin as a Young Artist
Past the initial setup, using Void Linux has been more or less like other Linux distributions without systemd, if seemingly fewer service scripts. Have not had to dig into the inner mechanics like writing runit services and cannot comment on them, though did notice in the user handbook that runit has as user/rootless mode for services, which is possibly the one feature previously seen in systemd that would be handy to have in OpenRC (the service manager Alpine uses).
Found out to my dismay that the qutebrowser package in Void does not run with QtWebEngine, and seems to only be built with QtWebkit. Opting to proceed with QtWebkit brings up a warning about how outdated the latter was, made worse by browsing to the front page of the GitLab CE instance and see it only partially rendered. Fortunately Luakit despite being also Webkit-based still functions like the one in Alpine and was usable on a single-tab basis over VNC. Logging into websites needed a bit more setup as clipboard pasting is not enabled over the VNC connection, but possible e.g. by preloading credentials and retrieving them from pass. A full-fledged password manager might be required for 2FA/TOTP though. Since the Void contributor documentation has a policy of not accepting browser forks due to additional maintenance overhead, more privacy-conscious variants such as LibreWolf would not be available, which is unfortunate albeit understandable. Both Firefox and Chromium update frequently that keeping up with two major browsers is already effort.
Ran out of storage space while installing some development libraries to compile the mystery app[1]. Could uninstall everything else and put them back later to temporarily recover some space, but the chances of success is low due to missing three other dependencies from the repos. Activity idea discarded, however:
# rm -r /var/cache/xbps/* # df -h Filesystem Size Used Avail Use% Mounted on /dev/root 1.8G 1.1G 554M 67% / # xbps-install [packages] [...] Size to download: 153MB Size required on disk: 558MB Space available on disk: 659MB
Does something look funny? Somehow xbps found an extra 105 MB on the partition then lost it mid-install, instead of stopping immediately as it has done in other scenarios. If in doubt, df has the more reliable number.
[1]: The pixel art editor LibreSprite. No mystery there given activity #1, but congratulations if you guessed correctly.
Tried to run Goxel, a voxel editor, and got two errors:
error: XDG_RUNTIME_DIR is invalid or not set in the environment. glfw error 65542 (GLX: GLX extension not found) Segmentation fault
Sadly not very usable on the Pi 3 — CPU usage ratchets up to 375% and add/remove block operations lag, even if memory is at a manageable ~120-150 M for a small file. The application consumes 25% CPU on another armv7 device where it is considerably more responsive, so the issue may be a CPU limitation. Otherwise a nifty voxel editor on a faster CPU.
Found a TUI "drawing" app that can be used to create ASCII art called draw. So far it works best over xterm if accessed over SSH — running it in another terminal or tmux can cause it to be unable to detect characters properly and litter `alt[` and other unwanted control characters onto the canvas. Compose key characters can be used too, though not non-Latin characters.
Uninstalled Go after compiling the program to conserve storage space. Probably needed a bit under 300 MB, most of it for the Go compiler package itself. The resulting executable is 3.1 MB, small enough to keep around.
Usage instructions are in the source repo readme.
Came upon two more ASCII and ANSI art editors, aewan and durdraw. The draw program from the day before still acts up with stylus input on xterm, and the other two do not work with the stylus although both TUIs are mouse-aware. Block by block is probably how drawings were meant to be made. Aewan can be used to make animations and export the "frames" as individual text files inside a gzipped archive (have not tested the feature). Durdraw has a cool logo, UTF-8 support and different colour modes among other features.
The applications are not in the Void repos, but building them from source is straightforward after a bit more disk space shuffling.
tar -zxf aewan-1.0.01.tar.gz cd aewan-1.0.01 ./configure make
git clone https://github.com/cmang/durdraw.git cd durdraw
python3 -mvenv --system-site-packages venv . venv/bin/activate pip install --upgrade . deactivate
Revived a dubious tradition from previous year's OCC of picking a game and playing a session. Selected a random game from the awesome-tuis list called Brogue CE. Rarely played dungeon crawlers and had not configured w3m to open images, so only realised after building from source and starting the game that it had striking similarities with angband which was already in the repos. However, it does have interesting features in the form of more seeds and different modes. When running in terminal mode over SSH, avoid starting it inside tmux as it causes a spike in tmux's CPU usage from negligible to 38% on the Pi. Brogue CE itself ran at around 25% CPU, and lagged when the character is surrounded by four or five creatures, but was playable overall.
Did not make it past level 4 on the first attempt — got swarmed by jellies. It would have been almost cute, perishing by lag aside.
Brogue: Community Edition gameplay differences
More information about the Linux version of Brogue
2024-07-13-occ-2024/brogue-ce-splash-screen.png
2024-07-13-occ-2024/brogue-ce-start.png
pkgver=v1.13 curl -LO https://github.com/tmewett/BrogueCE/archive/v1.13/BrogueCE-$pkgver.tar.gz tar xf BrogueCE-$pkgver.tar.gz cd BrogueCE-$pkgver make TERMINAL=YES
Closing out the event week with a few thoughts.
CPU was the more noticeable bottleneck this year, which was to be expected as the older Pis are not known for good CPU performance, though the Pi 3 will still compile source for small applications without issue.
Did not reach 512 MB in memory usage at any time during the week. It was mostly spent in TUI over SSH.
The disk space limit started to bite when building programs from source. Had to do considerable package rearrangement to free up enough space for Brogue CE's SDL2 and SDL2_image-devel dependencies (~563 MB) on top of gcc tooling with kernel headers (~215 MB). Git alone was 44 MB with dependencies, which combined made up just over half of the available storage. Removed X server, i3 and all GUI applications, clearing the package cache manually in the process. Had ~15 MB of free space left after building Brogue CE. The game executable itself was 1.3 MB. Fortunately SDL2 and SDL2_image (not the development files) were only 2 MB combined. Making installation of docs or manpages optional (as in Alpine) or a package manager flag to skip docs would have been helpful and saved ~50 MB of space.
On the topic of package manager, there were a handful of things about xbps that were inconsistent or slightly annoying:
xbps-remove -R does not remove all dependencies when removing multiple packages
Nevertheless, due credit to Void for simplifying setup for the Pi, providing both boot images and rootfs tarballs.
The smaller storage space led to a preference towards small compiled executables where the build toolchain and development headers can be removed afterwards to make room for other packages, and fewer applications that require several libraries to remain installed at runtime. It also meant being less likely to build applications that fetched dependencies with language package managers like cargo or npm if the lockfile holds a long list of packages.
The most pleasant surprise was x11vnc. Had not used VNC in some time and initially factored in a two to three-second latency over a local network that would be especially apparent in drawing applications, but the resulting connection ran better than anticipated. Finding more drawing programs and revisiting two others was another highlight to the week.
While there were no particular goals this time for the Pi 3, it was good to see the device is still supported by multiple OSes. Hopefully the preparation issues were temporary and the support will translate to better luck with a BSD next time.
