💾 Archived View for magda.cities.yesterweb.org › gemlog › 2024-04-01.gmi captured on 2024-05-26 at 14:49:39. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-05-10)
-=-=-=-=-=-=-
---
After a week of testing all kinds of Linux distributions, I settled with Devuan and Salix for the final test. I initially planned on writing just one post for both tests, however Devuan managed to be THAT weird (and frustrating) that this post would have gotten too long and convoluted.
Spoilers: I'm close to losing my sanity halfway through this and it may or not be entertaining to read.
Devuan is a distribution not just based on Debian but it effectively is "Debian without systemd". It offers the classical SystemV init, OpenRC and runit, though during a separate test, runit still seems to be a fairly new addition suffering from various quirks that make it a bit of a hassle to use.
Having chosen the Live ISO, I got to experience Devuan's graphical installer, which is just a bunch of dialog boxes with a Terminal emulator running in the background, so vastly different from its minimal install images each shipping with a ncurses-based TUI installer. The first window perhaps was the most confusing one, even for someone as moderately-experienced as me who can install Arch Linux without its install scripts.
I already partitioned the HDD in advance but now was faced with the first oddity of this netbook: This machine already hosts three primary partitions for Windows 7 Starter, leaving me with only one primary partition for Devuan and a simple swapfile, instead of a swap partition I could re-use for my test with Salix later.
Ignoring this for now, I set what need to be set and let the installer do its job. While the CLI window in the background, the HDD LED and the USB drive showed a lot of activity, the graphical progress bar remained at 0% throughout the whole installation. The installation took, minus the initial configuration, 19 minutes, making it just two minutes longer than an install on a 64-bit machine.
Right off the bat, I decided to do a system update and this took nearly half an hour. Whilst updating, the battery suddenly dropped from 25% to 5% and the machine got even hotter than when running Windows 7 Starter.
The update (or rather "upgrade", to stick with the Debian terminology) succeeded but not without revealing another quirk of this netbook. It appears that Acer, eMachines' parent company until its dissolution, installed its own "Acer registration utility" on sector 18, effectively putting it directly on the boot partition that may cause issues with any installed operating system, including the pre-installed Windows 7 Starter. The kernel also complains about a handful of BIOS bugs and missing firmware during boot, yet continues to boot the system without further issues. You just can tell that this machine is on the lowest end of all low-end computers from 2010.
Because of the system upgrade taking unusually long, I began to de-bloat Devuan and accidentally managed to delete both Network Manager and ModemManager due to being dependent on libbluetooth3. I don't know how much Arch Linux has managed to spoil me but this is the first time I see both Network Manager and ModemManager being hard-dependent on Bluetooth, alongside the system rather opting to remove both alongside Bluetooth, instead of warning the user about the removal of two rather critical components. Of course, this behavior merely could have been inherited from Debian but I have to admit that I expected Devuan to NOT just be "Debian without systemd".
Typing this on Devuan and so far I noticed the system draining the battery just as fast as before. The machine, while not boiling, also gets worryingly warm during usage and opening any program makes the CPU jump to 50%, each mouse cursor movement to 10%. With only Vim (via Xfce4 Terminal) and htop (via XTerm) running, memory sits at a comfortable 369 MB. Overall responsiveness of Xfce is pretty solid, though few installed programs such as Quod Libet take at least 15 seconds to load and the system slowing down to unusable levels when running Xfce4 Terminal and Thunar whilst accessing "Applications".
Shutting the system down is unusual in the sense that the graphical session on TTY7 gets killed and Devuan switches to the text-based login on TTY1, staying on it for several seconds before finally shutting down. It also is a rather weird security measure to restrict `shutdown`, `halt` and `reboot` to root and users part of the "sudo" group (and this is the second time I'll give credit to systemd for actually doing something right, next to its intuitive syntax) while doing any of this directly via Xfce circumvents this.
But back to the self-inflicted pain: Because I managed to wipe Network Manager, I manually had to enable LAN via `dhclient`, so I could install Fluxbox to gain at least some power improvements. Simply downloading Fluxbox was enough to decrease RAM usage by 50% largely due to the absence of integrated compositing. Setting `transparent-hugepage=never` in GRUB further pushed memory down to a very-lightweight 131 MB when working with XTerm. Despite this, CPU gains were rather marginal in contrast, pushing mouse cursor spikes down by approximately 15% and program starts by a mere 6% on average. The auto-generated Fluxbox menu is far more usable than the one shipped by Arch Linux.
Now we're getting into the embarrassing side of Devuan. While I was customizing my Desktop experience, I discovered various folders in `/etc` that shouldn't exist at all, namely `runit` and `systemd`. While all systemd files are being pointed to `/dev/null`, runit hosts a single `acpi` file, despite never having opted to install anything even related to runit (in fact, the Live-ISO's installer didn't even provide me a choice and automatically went with SysV).
All logs almost immediately get archived upon the next boot, which is acceptable on a single-user system with limited storage, yet a bit cumbersome during troubleshooting, especially when reboots are required during the process.
It got worse the moment I started to dig through the boot logs and discovered that the kernel does detect my wifi card, yet requires a different driver that needs to be installed manually. While Debian and even Arch Linux, which stopped supporting 32 bit in 2017, still offer `b43-fwcutter` in their main repositories, Devuan does not... and manually pulling the tarball, as advised by the archive listed on wiki.kernel.org, was a waste of time due to three missing files that prevent `make` from building... and an included PGP key that isn't public, according to `gpg --verify`.
After digging through a few more sub-directories, I discovered a bunch of firmware packages in `/firmware`, including the required b43 and the b43 legacy driver. Because GDebi to install those local packages is not part of Devuan's default setup, I had to grab my LAN cable one more time to download it and its long list of dependencies that claimed more than 200 MB of disk space.
The package then failed to build due to missing `b43-fwcutter` – the package that is available on Debian but not on Devuan. The script removing "non-free firmware" also needs to be executed manually and includes "firmware-linux-free" but not b43.
Honestly, I don't understand anything of this. There's a script to remove only a random selection of proprietary firmware, yet it includes the meta-package for linux-free, as well. Then there's a directory named "Firmware" that ships nearly all proprietary drivers AND linux-free as DEB packages that need to be extracted with GDebi. GDebi needs to be installed manually because Devuan doesn't ship it by default. The GDebi package then grabs 200+ MB of dependencies, many libs that aren't even required by GDebi to function. And all this hassle to do nothing but stop the log spam during boot just to discover that the DEB package I was looking for lacks a dependency I can only grab directly from Debian's repositories, while other packages are listed as "already installed with a newer version".
(I guess my "Arch frustrations" [on paper.wf] post was a little short-sighted in hindsight. The ridiculous compression default that nearly made my weak Acer Aspire melt is nothing compared to this attempt at making the installation of a necessary driver as cumbersome as possible just to push Stallman's "free software" doctrine. My patience with Devuan is barely existent at this point and I lost count on how many times I mumbled "what the fuck" to myself.)
Due to defaulting to root-exclusive execution of `shutdown` and `suspend`, I was largely forced to stick to the Xfce session for quick note-taking, while writing longer text was accomplished via my half-assed Fluxbox session to save some power. While the typing experience itself is pleasant on both Xfce and Fluxbox, the full CLI experience was quite tedious because of my preferred command-line file manager `ranger` not only taking several seconds to start but causing artifacts of itself to overlap with the prompt after closing it, requiring a `clear` to see what I'm typing. I've never experienced this on any of my other machines nor in any VM I tested ranger in.
Unfortunately, typing for roughly ten minutes heats the CPU up to worrisome degrees when using Xfce. Halfway through this section of this post, I had to switch to a TTY to figure out what is causing Devuan to put this netbook's CPU under this amount of thermal pressure – the pure CLI environment did not help me at cooling the processor down, despite (repeatedly) making sure that the fan is not blocked by dirt, dust or my clothes. While at least one detected sensor states that one core is below 30°C, rapidly switching between 24 and 29°C according to htop (14° according to inxi!), all of my other laptops with similar issues regarding the proper detection of sensors usually claim something between 48 and 56°C WHILE the machine is lukewarm.
Sure, one could claim that the vast majority of Linux distributions simply suck at this task just as much as hardware manufacturers tend to place sensors in silly spots, yet this is the first time I see an OS **understate** CPU temperatures on a portable device (discounting my relative's HP Pavilion due to having more than five sensors, all of which are being detected, and only massively miscalculating one out of those for whatever reason.)
But because of those thermal issues, I decided to end this test not even a week after installing it. I did not test Devuan during one of my regular field trips to determine how well it's suited for quick note-taking (i.e. keeping it suspended most of the time).
Most of the time, I was worried about my netbook melting away, as Devuan turned out to be similarly heavy as Windows 7 Starter, just with much less fan activity and useless sensor readings. Even inside a cool room, the machine would get noticeably warm after at least five minutes of usage even when not running a graphical environment and setting at least one kernel parameter that usually does wonders.
Hardware-specific issues aside, Devuan comes off as some sort of "bootleg Debian" with a clumsy installer for its live environment, loads of automatically-installed bloat and a subtly stronger but inconsistently-enforced emphasis on GNU's distaste towards prorietary software as a whole. The way Devuan tries to circumvent the issues caused by applications hard-dependent on systemd seems like a rather weird hack for the devs to still be able to pull packages directly from Debian and save storage and bandwidth, rather than taking the manual route by compiling affected packages without systemd. Leftovers from older versions of Devuan can be found, too, such as configurations for LightDM, and there's a weird relationship between SysV and runit on a supposedly-pure SysV install. And just like 4.0, installing Devuan from the live environment is on average larger and heavier than doing a netinstall, despite all installed packages – at least when choosing SysV during the netinstall – being identical to each other.
While the desktop experience appears consistent, it's largely a superficial impression. Not using a graphical environment reveals that Devuan's i686 variant at least appears to get the least amount of attention required by it to work as efficiently as possible on old hardware, especially now that the kernel's i686 variant also inherits features unsuited for "budget hardware", such as `transparent-hugepage`.
All I can say is that it's not a permanent solution for old netbooks like this one. And its Desktop really should see some necessary spring cleaning and maybe a less-contradictory stance towards proprietary drivers.
(By the way, right after finishing the last section, ranger crashed due to a wrong color value in `color.py`. I've never seen ranger crash on any other OS before, let alone crash with an error that cannot be replicated afterwards because ALL OF THE SUDDEN the faulty value disappeared.)
---
Hardware:
eMachines eM250
Motherboard: Acer eM250 V1.25
Processor: Intel Atom N270 @ 1.600 GHz
Display: Intel Mobile 945GSE Express Integrated Graphics
Memory: 1 GB RAM (987.9 MiB)
Storage: 150 GB Seagate ST9160314AS HDD (149.05 GiB)
Network: Qualcomm Atheros AR8132 Fast Ethernet & Broadcom BCM4312 802.11b/g LP-PHY