💾 Archived View for tilde.town › ~mio › log › 2023-07-10-occ-2023.gmi captured on 2024-05-12 at 15:32:56. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-05-10)
-=-=-=-=-=-=-
---
date: 2023-07-10T00:14:24Z
update: 2023-07-17T03:05:00Z
---
Last year's challenge had been an interesting as well as helpful experience while reading about other people's approaches to their old computers, that I looked forward to participating again. This year's theme is a "slow" computer, and I will try to update this post daily during the week. Like the previous year, I'm using the closest device at hand, being too lazy to prepare anything and accidentally preparing a few months in advance. What happened was, in late March, my Chromebook's power adapter gave out. Instead of immediately ordering a new one like a sensible person, I dragged out a Samsung N150 netbook from its dusty box, plugged in a USB stick with Alpine Linux install media and began using it instead, inadvertently setting up a new installation for the event.
Specifications:
(unused, booting from USB sticks, 32 GB (days 1-4) and 8 GB (day 5-7))
Dated December 2009, the netbook had been lightly used for 1-2 years before the original owner gave it up in favour of an iPad. It came with Windows 7 Starter Edition and promptly had a GNU/Linux distro put on it, Ubuntu Netbook Remix at the time, and was used for several years before it was superceded by another notebook. Windows 7 showed the battery capacity at 97%, discharged to 89% after several minutes, while the battery only charges to a maximum of 39% in Alpine Linux. In its heyday it could support 3-6 hours of internet activity per charge. Battery life aside, it is still in good condition and everything else appears to be working.
The initial plan was to install to a SD card, reducing the physical profile of having a USB stick jutting out to one side. Unfortunately the BIOS did not support booting from the SD card slot, so USB 2.0 it is. While booting from USB definitely adds to the slow effect, it is tolerable for the most part until the package manager starts installing a core or large package, at which point the system is basically unresponsive until it is done writing to disk. Easily solved with a cup of [favourite-beverage] while waiting.
Last year, owing to being in a hurry and not wanting to risk breaking the Chromebook coreboot bootloader internals, I did not apply any hard resource limits. On a x86_64 computer, it was easier to apply a kernel parameter in extlinux to reduce the available memory on boot (thanks to a tip from wsinatra) by adding `mem=512MB` to the default kernel options in `/etc/update-extlinux.conf`, then running `update-extlinux` to include the parameter on the next reboot.
Also made a few small optimisations right before OCC week:
- Disabled any uneeded init services: only noticed recently ibus settings were not being saved. There is a missing package to correct this, but the service is turned off until it is fixed.
- Reduced the number of getty: by default 6 tty are spawned and each tty uses ~7 MB. They can be set in `/etc/inittab`. Kept one for logging into the graphical display and another in case someone goes wrong in the first session, commenting out the rest. ~28 MB retrieved.
- Switched to a lighter terminal emulator: sakura has moderate memory usage (36-40 MB with 3 tabs open), but still more than xterm (7-11 MB per window). Xterm can run as low as ~3 MB per window without TrueType fonts enabled.
Samsung N150-11 review on CNET
The most noticeable bottleneck seems to be the CPU. Firefox chokes out of the box with loads of 8.00 and higher despite having over 100 MB of memory still available, though the load could also be caused by iowait. Qutebrowser is somewhat usable for a few open tabs and Javascript disabled. Luakit is another light option, but gets fewer browser engine updates than Qutebrowser, which may be a security concern for some people. Midori was either unstable or had rendering issues whenever I tried it, and none of the other lightweight GUI browsers like Dillo or K-meleon came close to rendering pages completely, especially on Javascript-heavy sites.
OCC organiser Solène linked to arkenfox/user.js in the #oldcomputerchallenge IRC channel, which applies some performance adjustments and security settings to Firefox. It remains to be seen if it will make any difference on this netbook. In the meantime, w3m is great for text-based browsing and also supports gopherholes. Amfora has a solid interface for viewing gemini capsules. Qutebrowser is only opened for sites that really require full rendering.
Memory usage is 90-123 MB, which varies depending on the number of vim instances open. Sometimes it is a GUI file manager, an image or PDF viewer. At a given moment there are 2 xterm windows under i3 (the window manager) — one for ssh, and another with tmux and several panes for w3m, amfora, vifm (file manager) and vim.
Mixed news. The no-good bit — I tried the Arkenfox user.js with a Firefox ESR 112 profile. It successfully applied a template of settings, but there were no noticeable performance improvements. The browser stutters and becomes unresponsive for minutes at a time over simple interactions like typing in a URL in the address bar despite turning off search engine autosuggest. To be fair, Qutebrowser is also slow to start and crashes on some sites with Javascript enabled under the OCC setup, but it could manage 3-5 tabs if Javascript is disabled.
The terminal output from firefox-esr shows a few errors:
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: libpci missing (t=184.963) [GFX1-]: glxtest: libpci missing Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: libpci missing (t=184.963) |[1][GFX1-]: vaapitest: ERROR (t=185.16) [GFX1-]: vaapitest: ERROR Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: libpci missing (t=184.963) |[1][GFX1-]: vaapitest: ERROR (t=185.16) |[2][GFX1-]: vaapitest: VA-API test failed: failed to initialise VAAPI connection. (t=185.164) [GFX1-]: vaapitest: VA-API test failed: failed to initialise VAAPI connection.
The libpci error went away after installing pciutils-libs (or pci-dev in some distros), but installing intel-media-driver, libva-intel-driver and gst-vaapi as suggested in two Reddit threads didn't satisfy the vaapitest.
This little diversion involving Firefox was brought on while looking for the fastest way to turn a Wikipedia article into PDF. Firefox's "print to PDF" feature saves the pages with the source URL helpfully included, whereas Qutebrowser saves pages as images, which mostly preserves the visual style of pages but the text cannot be selected. There used to be another utility called wkpdftohtml, but the source repo is archived and it does not appear to be in development anymore. Another option is pandoc to convert between various text formats, and is available in the Alpine repos for x86_64. Actually, in the case of Wikipedia, the fastest way is to select the "Download as PDF" option under the "Print/export" menu on the article page.
The good news: DOSBox works! It averages ~176 MB RAM/~45% CPU while running SimCity 2000. Mouse movement is a bit fast but poses no issues. Initially Sim Tower was on the menu, but it required Windows 3.1 or another old version, and wrangling with Wine is also not on order for OCC week. DOSBox can run other titles, and there are native Linux games.
SimCity 2000 title screen in DOSBox
SimCity 2000 — town in the year 2050???
Memory usage when not running DOSBox remains steady at ~104 MB, or ~131 MB if counting 27 MB from weechat (IRC client) and neomutt (mail client) being offloaded to a ssh session. The data is stored on another box and it made little sense to add individual directory aliases to remote mounts only for a week for running the two applications on the netbook.
Reddit thread on the vaapi error from Feb 2023
Reddit thread on the vaapi error from Oct 2022
After I mentioned to wsinatra the previous day had been spent fiddling with DOSBox, he suggested trying Elder Scrolls II: Daggerfall to see whether it would run. The first step was the hassle of downloading the game. The official website has released it at no charge, but the Javascript-based site does not load at all in w3m/lynx. The Bethesda website did load in Qutebrowser (before the browser segfaulted while scrolling down the page) and in Luakit after waiting 4-7 minutes each time for the browser to launch then render, and unfortunately the link was to a Steam version. That was a non-starter for the available memory.
Eventually found another copy, and after extracting a .bin and .cue file (renaming them to be more Unix-friendly), ran the installer in DOSBox:
mount c /path/to/install/dir -freesize 1024 imgmount d /path/to/daggerfall.cue -t iso -fs iso d: install
The first command maps a system path to the C: drive and sets the free space on the virtual disk to 1 GB. The next ones mount the .bin image to the D: drive, switches to it and runs the installer. Following the install prompts, the "Huge installation (450 MB)" install size was selected and the game was unpacked to the default install path at `C:\dagger`. There was a sound card configuration step at the end of the installation, but I did not set up system audio to be able to test on the fly whether the game music/sfx actually plays, since the role of music player has been mostly relegated to a mobile device. It turned out to be a small loss for experiencing the game when there was an animated cut scene as the story starts with no daialogue captions. Users have reported game sounds working with SoundBlaster 16. In previous experience with SimCity 2000 on another computer, sound worked automatically with the system's Pulseaudio set up. The DOSBox wiki also great documentation for the emulator features, commands and instructions for specific game titles. After installation, the game still required the D: drive to be mounted to be playable. Running `dagger.exe` inside the install path starts the game.
Had minor trouble at first with some mouse clicks not registering while setting up character stats, but this may be due to running on an unoptimised CPU cycle (the default 1k instead of another number like 10k) and should be fixable by editing the user's DOSBox config file. Once the first chapter and tutorial began, the mouse was responsive enough and the issue seems to have disappeared.
Much anticipated game coming soon … in 1997
Play the game or we shall set your CPU on fire
Initial impression of the game is positive — there is a decent range of classes and the stat chart is presented in a compact and legible layout. My personal preference is for isometric or almost top-down map scene rather than first-person view, to take in more of the surroundings, but others may find the close-up angle of first-person more engaging.
Setting the game aside for now though, even if it might be funny to write "Played Daggerfall" under the heading and call it a day for the rest of the week.
In terms of memory usage today, Dillo gave me a slight shock earlier when one of its processes (/usr/lib/dillo/dpi/https/https.filter.dpi) shot up to 250 MB from 3 MB on launch while downloading a file, but it cleared up shortly after. The browser does not support frames or Javascript, but starts up quickly and is a solid option for viewing pages with images in-place.
The Elder Scrolls II: Daggerfall official page
The Elder Scrolls II: Daggerfall on the DOSBox wiki
Additional instructions on a LaunchBox forum thread
Otherwise known as the Day of Fail, in which someone who said earlier wrangling with Wine was not on the menu tried to run SimTower in Wine, with disastrous results. It seemed plausible enough at first:
mkdir /path/to/simtower mount -t iso9660 -o loop /path/to/simtower.iso /path/to/mount/point cp -r /path/to/mount/point /path/to/simtower umount /path/to/mount/point cd /path/to/simtower wine setup.exe
Instead of a few hours of fun, it gave the following errors:
0084:err:vulkan:wine_vk_init Failed to load libvulkan.so.1. 010c:err:environ:init_peb starting L"C:\\windows\\syswow64\\winevdm.exe" in experimental wow64 mode 010c:err:module:LdrInitializeThunk "krnl386.exe16" failed to initialize, aborting 010c:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\syswow64\\winevdm.exe" failed, status c0000005
Adding the vulkan-loader package removed the libvulkan.so.1 error, but the errors with winevdm persisted. It appears that the 32-bit game had a 16-bit installer, like games sometimes did around the same period. The FAQ on the WineHQ website indicates Wine could run 16-bit code on a 64-bit OS, but the instruction to enable 16-bit code execution did not work in Alpine x86_64 on the latest LTS kernel:
echo 1 > /proc/sys/abi/ldt16 ash: can't create /proc/sys/abi/ldt16: nonexistent directory
My attempt to enable it on boot via an OpenRC init script not only did not work, it triggered another problem. On reboot, there were "Segmentation fault" errors during startup when the networking service attempted to connect to a wireless network. The wireless interface was up, but wpa_supplicant cannot authenticate successfully to the network, confirmed when manually running following command: `wpa_supplicant -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf`. What probably happened was some core packages were upgraded including musl, which caused incompatibilities with the linux-firmware and kernel packages. The obvious solution was to synchronise the package dependencies again by fetching the latest ones, but this was hampered by broken networking. If other methods fail, the netbook has an Ethernet port and setting up a networking profile for it should work, though it is a hassle all the same.
Fortunately, there was a backup installation on hand that can be used to log into and restore the broken system. This is the second time in the past 1.5 months that something broke while installing new packages, necessitating running `apk fix` or similar on groups of packages. Sure, it is edge/testing and instability should be expected. The edge repos contain a number of applications that are unavailable on stable releases, and might not be for some time.
The broken install included an encrypted root filesystem (boot and swap are regular partitions), so an additional step is needed to unlock the root partition. Once logged into the filesystem, run `apk upgrade` with toes crossed and hope it fixes the issue:
-- Get the device ID in the form of /dev/sdX, or /dev/sdc in this case blkid -- Unlock the LUKS volume and register it at /dev/mapper/sdc3 cryptsetup luksOpen /dev/sdc3 sdc3 -- Mount the LUKS volume to a directory -- This step is required or the mount command will return an error -- "mount: /dev/mapper/sdc3/proc: mount point is not a directory." mount /dev/mapper/sdc3 /mnt -- Also mount the /boot partition in case there is a kernel upgrade -- that needs to write to the partition mount /dev/sdc1 /mnt/boot for i in /proc /sys /dev /dev/pts; do mount -o bind $i /mnt$i; done -- Enter the broken installation chroot /mnt -- Upgrade all packages apk upgrade -a -- Exit and unmount exit for i in /proc /sys /dev /dev/pts /boot; do umount /mnt$i; done umount /mnt cryptsetup luksClose sdc3
It did not fix the issue. All packages are up to date, but wireless networking was still unable to authenticate with networks. Using `dd` to clone the backup installation to the USB stick also failed with an IO error after ~187 MB transferred, which might be due to the encrypted partition, as erasing and flashing an ISO worked. The backup will suffice for the rest of the week with the resource allocation adjusted, but there will be no installing of system packages because the current state of edge is unusable for me.
Not sure yet about the next step.
Wikipedia entry about Wine's backward compatibility
Allowing 16-bit applications at the kernel level
Is it possible to run 16-bit code on a system with Intel IA-32e mode?
32-bit Wine environment on a 64-bit OS
Started a new installation of Alpine Linux 3.18, with a base configuration running within an hour. Then, while installing the display server, this error appeared:
WARNING: libcdr-0.1.7-r11: unable to cache: Read-only file system Segmentation fault ERROR: Unable to lock database: Read-only file system ERROR: Failed to open apk database: Read-only file system
This does not bode well for the USB media, which had only been in use for 2 months. It is the first time of issues with the brand of storage media. The `dd` command failure the previous day and also the networking segmentation fault may have been related. Sure enough, the next time the installation was rebooted, sysctl could not mount the unlocked filesystem and dropped into an emergency console. The USB stick was a write-off, pun intended.
The next irrational thing to do was to pull out an older version from the same product line with 25% of the storage capacity of the previous one and reinstall again.
Originally the image was to come from a USB webcam, but Cheese and guvcview could not find the device. The webcam showed up in `dmesg` but not identified properly there or in `lsusb`. It might be broken. Pulled out a Nintendo 2DS for a low-res image instead. Taking pictures with it can be a bit tricky initially, because the viewfinder displayed on the top screen does not match the image output — the view appears more zoomed in and horizontally off-center to the JPG result. This is due at least in part to the camera taking stereoscopic 3D images (even though the 2DS model cannot display them in 3D), with 2 lenses offset left and right of the center:
The camera saves a JPG and MPO file for each photo taken, the latter of which contains the image objects viewable in stereoscopic 3D on a 3DS or some other viewer. The pair of images can also be combined side by side to emulate a 3D effect when viewed with a headset similar to the Google Cardboard, or to generate an anaglyph for red/blue 3D glasses. Here is an example using Exiftool and GraphicsMagick:
-- Extract the left and right images from the MPO exiftool -b -mpimage2 input.mpo > left.jpg exiftool -trailer:all= input.mpo -o right.jpg -- Generate a side-by-side (SBS) image gm convert +append left.jpg right.jpg sbs.jpg -- Generate an anaglyph image gm composite left.jpg right.jpg -stereo anaglyph.jpg
The stereoscopic images were a tangent, though par for the course with the way things panned out in the past few days.
Memory use today is ~90-141 MB, on the higher end after reverting to sakura for terminal emulator, which has better text selection than xterm.
Open source 3D image viewer for Multi Picture Object files in Linux
Merge images side by side horizontally
Low activity today, but finally got around to fixing a bug that caused post titles to be truncated on the list of log posts. It is less an actual fix than simply removing an extraneous if/else block in a string parsing function. The (Very hacky) script used to generate the post list and rss feed can be found here:
Memory use today hovers at 149 MB, with the top 3 memory-consuming processes being w3m, sakura and Xorg server.
Spent some time updating a shared zettelkasten with a few tips learned during OCC. (A zettelkasten is a collection of atomic entries on a range of topics, with lots of interlinking among entries.) Merging changes into the zettelkasten repo using the git host web UI in Luakit was almost painfully slow with the single tab open, but each page did load eventually after 1-3 minutes — log in, make pull request from a branch comparison page, submit pull request form, approve merge request and the subsequent merge successful confirmation message. A 5-minute task that took ~15 minutes. Resource usage went up to 240 MB RAM and ~2.41 load with a password manager included in the mix. The RAM usage calculation seemed a bit low, but htop and free both reported the same numbers. Swap stood at 80 MB. Technically the changes could be pushed straight up from the git CLI with maintainer permissions to the repo, it is more a test to see what works best for merge etiquette.
Next, I tried to watch a Peertube video. The video did not load on the page in Luakit, which may simply be due to plugins being disabled in the Luakit user config, but after waiting ~6 minutes for the page then the download modal to appear, it was possible to copy one of the download links and stream it with mpv. The 1080p and 480p versions were viewable, confirming at the same time that Pulseaudio was working. Memory usage was reported as 59.3% of the total 279 MB and the CPU fluctuated between 40-50% after streaming for 10 minutes for the 480p version, while the 1080p used 80-90% of the CPU and climbed to 247 MB within the first minute. There was an warning about A/V desynchronisation, but it was unnoticeable to me in the video, which did not contain lip movement. The video seemed to stutter once or twice while playing in the background during multitasking, e.g. writing in vim, but that it could play 1080p video on an Atom core is still good news.
Also went back to DOSBox to check whether sounds were enabled, with mixed results. In SimCity 2000, the music was reduced to staccato notes that did not resemble the original tracks, but the sound effects were fine. In two other games tested, the both music and sfx worked perfectly, so the DOSBox settings probably just needed some fiddling for that particular game.
It has been a fun week, though the experience would be better without the storage media failure mid-week.
Oddly, the older 8 GB USB stick ("[model-name] 2.0") feels faster than the 32 GB ("[model-name] 3.0"). Installing a large package causes occasional 5-10 seconds of lag, but does not grind the entire system to a halt for minutes at a time, for example. One point which may turn out to be irrelevant: previous USB sticks were plugged into the single USB port on the left side of the netbook, which can be used to charge devices and runs warmer than the other two ports on the right side. The 8 GB one was subsequently attached to one of the right side ports. Maybe the stick suffered from overheating, though another sticks plugged into the same port for longer did not appear to be affected.
Unlike the previous year, there was no concerted goal to start — the machine was used for common computing activities like web browsing, plaintext editing, viewing images and PDF documents, and checking the fediverse. There was also a bit of light compiling of a Lua script to a C executable, playing a handful of old DOS games, but those are hardly esoteric endeavours. As expected, browsing the modern Javascript-heavy http web was a hassle, though it was still a little surprising how sluggish the browser interface itself became, not just the page rendering. While not having a slick appearance, Dillo offers a pleasant interpretation of what the mainstream web could have been — fast, resource-efficient, content-focused.
One thing I did not get to doing (besides trying to run SimTower, again, under a 32-bit OS) was a sketch in Inkscape, but the application does run, with the minor UI issue of a few windows being too tall. Resizing with Alt + right-click and dragging does not always shrink the window enough for the affirmative and cancel buttons to show up at the bottom of the screen.
Overall, while the netbook is not very outstanding compared with the contemporaries of its time, such as the EeePCs, in terms of battery life or other specs, it is decent for general computing. The matte display is great for using the netbook near bright overhead lights or sunlight. 1-2 reviews about the netbook complained about the cramped keyboard and the difficulty of typing accurately on it. The keyboard was all right to me, being used to flat and compact keyboards, as well as not having to press hard for keys to register.
If there is only one takeaway from this, it is backups. And to get better USB sticks.
