This blog will be shut down at the end of January and I won't port my old posts since they're hardly relevant anymore. You can follow my new blog either directly via Nekoweb or via its blog's RSS feed button.

I could talk about the bizarre PowerPoint presentations my friend sent me a few days ago which put BOKU (“University of Natural Resources and Life Sciences”, Vienna) in such a bad light that this institution should be banned immediately for spreading easy-to-debunk bullshit. I could also talk about the growing trend of “Etsy girls” reviving and popularizing the illegal trade of endangered insects for a pathetic “aesthetic”. Both are equally worrisome, yet only the latter touches on the aspect of niche social media cultures causing dire consequences in some of the poorest corners in the world for some cheap clout, leeching off the – and I'm not gonna bite my tongue here – stupidity of the average social media user doomscrolling their lives away out of sheer boredom.

Writing is a tiring process and due to my tendency to talk about stuff that already is draining in itself, it just gives me unnecessary headaches and ultimately wastes my limited time.

This blog will remain dedicated to tech and, to a lesser degree, online cultures but will be updated much less than my Gemini capsule, where I kind of found my home to vent into an actual void and discuss stuff that may or may not get me into some avoidable legal trouble with petty academics (and other easily offended people). But even my capsule will see less activity, except for my sub-capsule dedicated to my ecological observations. Those currently are being prioritized.

(I really don't know what to do with this blog anymore, now that I'm trying to avoid the AI hellscape and keep most of my stuff on Geminispace.)

Right off the bat, Zangi is yet-another-E2EE messenger from, apparently, Santa Clara (or Union City, CA, according to its App Store listing) that seemingly popped out of nowhere. It's seen more than 10 million downloads on Google Play Store alone, also is among the most popular apps on Apple's German App Store and most reviewers largely praise it.

Considering I've been testing a variety of messengers for a while and do keep up with the recommendations issued by tech magazines and tech bloggers, none of them are even aware of Zangi's existence, which should be the first red flag.

Secondly, it appears to exclusively be promoted via TikTok and within some corners of Instagram, largely via direct messages. As far as my Reddit research goes, it is largely used by scammers and the team behind Zangi ensures to not offer any kind of customer support besides a single Email address. They claim to rely on “5G technology” to provide video calls, even though 5G is irrelevant when accessing anything on the internet via Ethernet or WiFi (and I personally haven't seen a single server that is not connected to the internet via a considerable amount of Ethernet spaghetti). Not surprising is the lack of security audits and more funny claims such as:

1. Encrypted proprietary handshaking mechanism

Used for encrypting authorization and session key exchange (encryption algorithms: RSA-2048).

1. Dynamic channel encryption

Used for encrypting each session between the client apps and the server ensuring the security of data transport (encryption algorithms: ​RSA-2048, AES-GCM)

1. End-to-End encryption.

Encryption keys exist only on user devices and nowhere else (encryption algorithms: AES-256, Curve25519, ECDH, HMAC-​SHA256).

RSA-2048 has been public domain since September, 2001 and is widely used as an encryption algorithm for public key exchanges (the key you end up sharing with your contacts in this case). Due to its perceived slowness, it's not used to encrypt the vast amount of user data – something even Zangi is, at the very least, aware of. But this doesn't make Zangi any more noteworthy than Signal, Threema, or even smaller IM's such as Session, Delta Chat, the Tor-based Briar or, hell, Tox.

What's especially suspicious is the fact that Zangi markets itself as not relying on phone numbers, yet pretty requires one to “sync contacts”.

There's so much more that makes little sense and is just outright contradictory that make Zangi appear like the spiritual successor to EncroChat, though EncroChat couldn't be used outside of devices flashed with a custom Android ROM named “EncroChat OS”.

Or it's a honeypot. That would explain why the largest app stores are even promoting it.

But not its status as a Statement & Designation By Foreign Corporation, which also reveals that Zangi is run by two Armenians that obfuscate their actual HQ location.

Don't touch it. Use Delta Chat instead[1].

[1] I recently got followed by “Holga”, one of the main devs behind this Email-based messenger, and due to my interest in anything retro kindly started to message me privately on Delta Chat. And almost immediately got into DC's tiny web apps. He loves his stuff, he'll bombard you with all the technical details, his service is honest to a fault. It's a tiny project but it's safer than Zangi.

This also was written before becoming aware of dansup's announcement claiming that account migration has been fixed. You can check the commits to confirm that nothing but mostly Spanish localization fixes were committed around the time Dan posted this.

Keeping the mandatory-by-unwritten-rules-about-blogging introduction as short as possible, let's just kick this off by my failed attempt at getting most of my stuff, particularly my post, off pixelfed.social after having learned more about dansup and why he's a server admin AND dev no one should trust for as long as his behavior remains unpredictable.

I, not even a coder but somewhat familiar with system administration, digged through the project's GitHub repository and not only did I discover it's lacking features but also strange configs and a single commit that is bordering on being intentionally misleading. Account migration in particular thus is broken by design.

There's been an open issue since January, 2024 which mentions the same issue I'm facing. Since no one capable of coding – and especially not Dan who hasn't even responded to it – has taken a proper look at the code handling account migrations, I tried to navigate my way through the repo and noticed several oddities, some of which go beyond the account migration process:

• Migration mentions Mastodon but links to Instagram

I randomly came across this file which hasn't been edited in seven years and thus has been unchanged since Pixelfed was started. It hints at being directly copied from Mastodon when, in fact, it's an incomplete rewrite of Mastodon's “account migration”, as Mastodon's written in Ruby on Rails, whereas Pixelfed exclusively relies on PHP. While Mastodon renders a moved account only partially usable, Pixelfed only pushes a “this account has moved”-popup between the moved account and any link pointing to it (yes, I'm still able to follow new people and post from a moved account, though new posts will be set to “direct message” despite listing “Followers Only”).

I don't know why it claims to migrate Mastodon accounts in the first place and why it points to Instagram's homepage – it looks like the text was copypasted at random times and Dan didn't bother to proof-read it,

• Missing jobs and Commit #4968

After a while I came across the jobs handling account migrations and noticed that they are supposed to handle the migration of followers only. The official docs – barely helpful as “Prequesites” and “Installation” are identical, while “Administration” and “Push Notifications” return 404 – lists nothing related to account migrations, whereas the account migration page in a user's settings state that followers, followings and posts can be migrated. The source code, on the other hand, claims to only migrate followers but even that doesn't work, leading to the weird situation in which pixelfed.social is claiming that the new account on another instance (account Y) has received all followers from the old account (account X) while account Y actually doesn't have any followers. No data is being moved from one server to another but merely displayed as if it originates from a different instance. (I emailed the admin of lens.im to confirm that logs do not register anything related to either a failed migration or followers having been moved to his server, confirming the lack of both a plain follower migration and error handling in case this job fails).

Let's recall that this issue was opened in January, 2024, over a year ago. According to the commits, however, account migration wasn't even a feature until March, 2024, and the commit itself, despite stating to “add profile migrations”, only mentions a single feature, that being ProfileMigrationMoveFollowersPipeline.

So either Dan completely forgot that “account migration” has been a broken, yet visible feature since day 1 or he really thought that slapping a just-as-broken migration feature on top of the old-and-broken migration pipeline would be a good idea. Given that Dan announced yet-a-new Desktop UI while the current UI still resides on top of Pixelfed's very first UI, which is far closer to the proposed new interface than the current default, it's likely he doesn't even want to understand his own code and just slaps whatever into his repositories according to his mood, not caring about consistency (which extends to how – and when – he labels issues, which range from a handful of labels on any issue posted in a short time to none at all).

• The way Pixelfed handles accounts set to private

Not related to account migrations but if you're coming from any other Fediverse service such as Mastodon, Misskey or Pleroma, you know that all public posts remain public, even after setting an account to private. Depending on server and profile configurations (especially when having discovery and search enabled), those posts will remain easily accessible within federating instances and not just cached temporarily on them.

Pixelfed handles private accounts in such a way that only may make sense if Pixelfed were a walled garden (i.e. not federating with non-Pixelfed servers). Setting a public account to private results in all posts seemingly being removed from search and public timelines. Profile picture and bio also are being hidden. (Or so it used to be the case just a day before I published this!)

My old account, despite being moved and locked, can be followed by non-Pixelfed accounts. Both my profile picture and my bio, which, surprisingly, hasn't been synced since a day or two before Instagram and TikTok users began to flood Pixelfed, are visible. The follow request from my new account on Vernissage gets sent straight into the void, while anything that was public before remains public, including several posts (those that were boosted before), outside of Pixelfed's ecosystem for as long as servers decide to cache remote info.

I gave up trying to make sense of Pixelfed at this point. There is no point in digging further through code provided by someone who “works” on several projects at once and claims to provide fully open source software while one of his other projects (FediDB) is closed source and another (Loops) only offers a GitHub repository with stubs and dummy configs. Not only that, dansup is known to be hostile towards other devs/contributors, sever admins and regular Fediverse users. In case you missed the running gag, dansup regularly lashes out against others on his Mastodon account, then deletes his pretentious rants when confronted with backlash as if nothing happened. His mood always shifts between acting like RuPaul's Drag Race contestant and Daffyd “everybody knows I'm the only gay in the village” Thomas from Little Britain.

Yeah, fuck that.

With the next “big migration” and dansup's plans to turn Pixelfed into a carbon copy of Instagram, there's no point in me continuing to use anything relying on Pixelfed. It was fun while it lasted and I want to thank my ~70 followers for not only granting me some inspiration and some new insights but also assisting me at determining species new to me.

I also just learned that dansup is... quite the guy people should trust, no different from Automattic's Matt Mullenweg. Miss me with that BS, I'll keep my shots to myself again.

I did test the borked XP install's mainboard after all and the only annoyance was some dust.

(All the dirt on the floor came out of this machine. It's dust soaked in nicotine.)

Due to the state of the case, I decided to disassemble what was left of this old Fujitsu Siemens T-Bird. Much to my own surprise, the cust on the case didn't spread to the mainboard at all and only the connector on the GPU has accumulated some. What certainly looks much worse is the Panasonic floppy drive, as its top was exposed for a few years. The first thing that needed to be done was the removal of dust layers on and inside the fan, on the power supply and around the GPU.

The board initially refused to start consistently. After replacing the CMOS battery, POST assumed that the replacement is just as dead and only would kick off when re-inserting it for every new boot. During the successful starts, POST also hinted at a faulty graphics' card, so this part saw the same prodecure as the CMOS battery, though now the BIOS claimed that there is an issue affecting RAM.

As it turned out, the RAM slot also collected some dust over time. Once removed, I was confronted with the GPU failure again. It took me some time to notice that I didn't re-insert it properly, which may happen when working under poor light. I finally got to boot the board with just the missing floppy drive error and later checked the missing drive that, despite its rust, still works flawlessly.

XP SP0's Overzealous Product Activation

This means that nothing fundamentally has changed since it carelessly got stored in my yard for several years. The installation of this Turkish version I got off ebay yielded no errors and even another attempt at unlocking the original install via my Hyrican tower demonstrated no issues besides the borked system remaining borked.

The only logs pointing towards some kind of hardware failure date back to May, 2014 – and due to this being an OEM install, a potentially-failing CD-ROM drive cannot be responsible for XP suddenly locking itself. The last error pointed towards an internal error when XP tried to execute VSS, which also may have hinted at a possibly failing hard drive. BUT: Unlike other variants such as Retail, OEM versions only are tied to the mainboard, thus product activation, at least theoretically, should only trigger when the mainboard itself fails. Even after treating it quite poorly, the mainboard still is fully intact and the brief issues caused by the first RAM slot did not happen when I last used this old Fujitsu – and even IF theslow already would have been accumulated some dust at the time this crash occured, the system wouldn't have gotten past POST due to the first 64kB of the RAM module having been inaccessible. That doesn't qualify as a dying mainboard, though.

As much as it is quite the relief to discover that neither the HDD, nor the the initial suspect – the replaced CD-ROM drive – were responsible for this odyssey that took me way too long to navigate through properly, the only possible point-of-failure STILL is working without showing any signs of old age, which means that it must have been Windows XP itself trying to commit hara-kiri. Partially understandable, as I was 16, stuck in some voluntary work entirely unrelated to tech, more worried about my dad's rapidly worsening health, and still influenced by the fear of tech instilled by one of my uncles who only attented a crash course once in the early 90's and then began to believe he knows everyting about computers and that he is the only one qualified to even do some very minimal system administration.

Still, it kind of is difficult to me to comprehend just how fragile the original version of XP can be even when doing nothing but playing cheap games for over a decade. There also is a certain irony that the very first set of errors did not begin to spam the logs until a few days after XP SP3, which wasn't (and still isn't) installed on the rescued hard drive, went EOL.

I likely won't rebuild this old machine to resemble its original state. The case is fairly damaged and the rescued XP install now tied to the mainboard of my Hyrican tower, which now can dual-boot both Windows XP Home Edition SP2 and Windows Vista Home Premium SP2. This tower also got better specs, so tying it back to the Phoenix board with its Intel Pentium IV and 256 MB of RAM again would be a downgrade. I got another, even older machine that also requires some in-depth tests, so there still are some possibilities to use this board and even the rusty floppy drive, which will get to see some proper care now, for something else, instead.

Unlike the T-Bird, the other machine simply is too heavy to have ended up outside and came pre-installed with Windows 2000. Its only downside is the physical lock on its case for which I never received the key. Maybe I get to break a computer beyond repair after all.

On this day in 2014, I was using my mother's Fujitsu computer as usual. Windows XP went into a sudden BSOD and immediately revoked the product activation, effectively locking us out entirely due to the original Recovery Disc having disappeared (we either lost it or one of my uncles, who did the initial setup but has a habit of never returning anything he borrows, kept it).

While I did try multiple things to recover this machine, nothing worked. Safe Mode was useless and the Recovery Disc I found on ebay turned out to be in Turkish. Because XP already was EOL at the time this happened and always lacked an internet connection, there was no way to reactivate it and so it ended up in our yard for a few years until I gave it another shot in 2021, only to fail again. I settled with plain data rescue via my ancient Hyrican machine that came pre-installed with Windows Vista and its old ATA connector, which the CD-ROM drive depends on (but not the machine's original SATA-HDD).

Last year a new XP crack was gaining attention for relying on recent discoveries made about the algorithm behind XP's Product Activation. I forgot about it shortly after but came across it again just a few days ago. And it worked... but not without a bunch of issues.

Direct Crack with Original Product Key

I pulled a few different installation discs from various archives and tested them in VirtualBox. All were successfully activated with the telephone activation tool, so I got my old Hyrican, “mastered” the affected HDD and entered the generated Confirmation ID. XP considered it “invalid”.

Different Product Key

I tried various leaked product keys and expected most OEM ones to work due to this version being entirely unpatched and thus unaware of all the keys that became invalid with later versions of XP. Only one was accepted, however the generated ID once again was considered “invalid”. That's when I began to notice that the Installation ID generated by this borked XP install was slightly longer than any ID generated by my VM's and included an extra -XX at the end. I still don't know why this ID is different from the rest and why this install even refused product keys specifically for Fujitsu OEM installs, yet at this point I needed to come up with something different.

Test Crack on the Turkish Install

Surprisingly, I was able to crack the Turkish version of Home Edition SP1, which I installed as a dumb 16 years old girl with no experiences regarding system administration or anything beyond the bare essentials of plain computer usage.

This stupidity actually would come in handy at a later point, though.

Install/Repair XP with a German Installation Disc

I came up with several plans in case one of those should fail as well. Copy all data via LAN or other means to one of my VM's, copy all data to my Vista HDD first and do some checks first before moving them to my VM's – all of those plans involved my virtual machines until I decided to just try the same thing I did back then and use a different installation/recovery disc but this time choosing one of the ISO's I tested in VBox. I chose the SP1 one but instantly was confronted with the issue of burning it to a CD or USB drive.

Out of curiousity, I used my Ventoy USB that already hosted some 32-bit Linux distributions and discovered the WIMBOOT feature. After everything loaded, the system restarted and caused a BSOD. The same thing happened after loading SP2.

The CD's I burned and the Rufus USB all were unbootable. I checked the latter's contents via the Turkish XP and tried my luck by executing setup. All contents were loaded into Windows Boot Manager and WBM finally was back in my native language.

Selecting Windows Setup provided me two options, namely an installation and a repair environment relying on CMD. Because I'm largely unfamiliar with Windows' commands, I chose the install option, where I was greeted by another repair option that spefically searches for older versions of XP. It detected my borked install and did not only repair all system files but upgraded the whole system to SP2.

Now with the first boot option being the borked but upgraded install, XP's product activation was reset and I finally was able to activate it.

Remaining Minor Issues

Because the Fujitsu tower dated back to 2001, the Hyrican tower, which I received in 2007, naturally had to be “too recent” even for SP2, which was released in 2002. Out of all hardware components, only the motherboard (ASUSTeK with a version of American Megatrends from 2002), my old Philips monitor and, after some delay, the USB keyboard were detected; I had to grab an old and largely-broken PS/2 mouse just to set a proper screen resolution.

Today I installed the missing drivers. GPU and audio finally work now and I even installed the missing drivers for my Ethernet port, even though I never will connect this hot garbage – it is what it is – to the internet. Meanwhile the system also started to recognize my USB mouse.

With that out of the way, the real deal begins. Why did this happen in the first place?

Logged Events

This is where things got quite juicy because the BSOD ten years ago did NOT get logged at all. My attempts at recovering the system via Safe Mode did get recorded, though.

I digged through every section and came across an error where a COM+ Event System failed, followed by another error in which Volume Shadow Copy Service was involved. This would hint at a potential hardware failure.

In-between all the various errors originating from Service Control Manager, only two explicitly list “a non-working device”.

Scrolling all the way back to May, there are 14 identical error messages, all listing the same “bad block” for no longer than a little over a minute and only on 4 May – no similar error messages prior to nor after this.

All logs point towards the HDD and it actually would seem plausible, given its age at that time. Unfortunately, it passed all tests conducted by CHKDSK only a few hours prior to the repair/upgrade via the copied SP2 IMG. No found000 was created, no errors were spit out during the upgrade and no more “bad block” messages or any other errors hinting at the nearing failure of the HDD popped up. Despite now being at least 23 years old and having been stored outside for several years with no protection from hot summers, cold winters and humid periods, this is one of the very few components from this ancient Fujitsu tower that took no damage whatsoever, alongside the floppy drive and the replaced CD-ROM drive. The mainboard and the case have begun to rust and I personally am scared of testing the rest, though the RAM module still appears to be in a good state.

But if it neither was the replaced DR-ROM drive, which I considered to be at least partially responsible due to how strict Windows XP's product activation used to be in its first years, nor the rock-solid Seagate HDD with its massive 40 GB, does this make Windows XP itself the sole culprit?

The Curse of the Major Version?

Windows 95 A, Windows 98 First Edition, Windows Vista prior to SP1 – all those versions pretty much have become known for being unstable or unpleasant to use. In all cases, subsequent patches – Windows 95 B, Windows 98 SE and Windows Vista SP1 and SP2 – fixed those stability and speed issues (for some reason, Vista still remains hated, despite SP2 being an update I highly appreciated back when I finally was granted access to the internet for school stuff and downloaded all the pending OS updates). But does this also apply to Windows XP?

Part of the nostalgia for this particular version may stem from the fact that most people simply never experienced a “vanilla” XP, let alone to its full extent. XP was released in 2001 and many home users still did not have internet access at that time. Besides this, most of them either still were using Windows 98, which came out just four years prior to XP, or suffered through Windows ME released in 1999, as their 98 PC's likely were incompatible with XP's higher hardware demands. For XP, users had to invest in new hardware first.

So by the time XP actually became popular, some time had passed. Shortly after its EOL, Ars Technica highlighted that Windows XP initally was hated among its readers. A lot of experienced users clinged on to Windows 2000, while 17 million copies of XP (OEM and Retail) were sold within a year since its release. In September 2003, XP reached a market share of 29%, whereas Windows 2000 still was in the lead with 42% and Windows 98 claiming 15%. Only a month later, XP's share increasted to 39%, while 2000 dropped to 38% and 98 to a mere 12%, meaning the vast majority of XP users never got to experience the original Windows XP that actually lacked support for USB 2.0. Perhaps if they would have experienced it and even drawn a comparison to Windows 98 SE, they may have hated it just as much as they continue to hate Windows Vista, even though they likely skipped Vista after hearing or reading about the negative reviews.

What now?

So while I check the system a little more to figure out the true cause of XP randomly locking itself, it simply may have been XP itself being fully resposible for this. Although there only are few reports about stability issues, major releases, at least based on my experience, tend to be fairly prone to issues of all kinds. The fully unpatched Windows XP install may have been no exception.

For now, I decide to forget that I listened to some... interesting music as a kid and happened to be a big fan of Lady Gaga.

After installing antiX and encountering the same thermal issues I witnessed on both Devuan and Salix, alongside a desktop experience much worse than on both, there wasn't a point in testing the remaining distributions targeting old 32-bit machines. It became apparent that all distributions still under active development either long abandoned optimizations for netbooks or never offered them in the first place. What made this realization particularly frustrating were quite recent forum posts on Reddit and other sites still recommending distributions such as Lubuntu, which are WAY too heavy on such devices not in terms of RAM or the type of storage device (“install a SDD” is almost always being recommend by those people for some reason) but of CPU demands. All tested distributions, in fact, performed smoothly, however my netbook eventually started to smell like melting chips and, because sensor readings turned out to be largely useless, I had to use my (even less reliable) hands to estimate this machine's CPU temperature, which were MUCH higher than all of my notebooks constantly reporting temperatures above 48°C.

Since this model also came with Windows XP installed at some point (though not on the device I bought), I joked to myself about giving in entirely and just install Windows XP. But alas, XP always gave me a sense of unease even when I was allowed to use it as a kid. So I began to dig and quickly came across a list on Wikipedia highlighting my growing suspicion of the Linux ecosystem of 2009 largely missing the netbook boom. Few distributions targeted all netbook brands and there were nearly a handful of distributions targeted the Asus Eee series in particular. The only “netbook editions” of operating systems that looked reasonable for that time are CrunchBang and Ubuntu Netbook Edition, with the latter seemingly being the only one providing a live environment for testing purposes.

Despite this list being horribly outdated, I was curious about Manjaro's long-abandoned netbook edition, however Manjaro does not maintain an archive for old releases. Coming across a rare review from 2014, I guess no one's missing out on anything because the only relevant difference Manjaro NE provided was a customized kernel, whereas the graphical environment provided MDM, Linux Mint's Display Manager which even back then already was too heavy for such devices, and Openbox – once again another random choice of software that makes no sense when remembering which devices it was supposed to target.

While Ubuntu offers a comprehensive archive for all of its version and thus allowed me to grab a copy of its “alternative” ISO targeting netbooks, I was unsure if there's still an old copy of CrunchBang due to its distribution model up until its discontinuation; CB was exclusively distributed via Torrent. Philip Newborough, the developer of CB, did not submit the final version of his distribution to the Internet Archive, in fact only two versions for AMD64 machines and one for the i386 architecture ever were donated, which is... rather paradoxical, considering the occasional waves of nostalgia from former CB users still popping up in comment sections and forum threads from time to time (and, from the perspective of a long-time Torrent user, quite asshole-ish because this kind of supports Red Hat's recent change to no longer make their source code accessible to non-customers; most FOSS users indeed are leechers).

Live Environments

The first challenge I was expecting to arise did not occur, in fact Ventoy was able to boot both images. Because only Ubuntu offers more than one version, I chose Ubuntu 10.10 “Maverick Meerkat” and CrunchBang 10. Because I first took a proper run with Linux back in 2020, where I settled with Ubunto 20.04 “Focal Fossa” for a few months on my Asus laptop until I switched to Archcraft on all of my 64-bit devices, it was strange for me to witness this old version of Ubuntu and its “Unity” desktop environment demanding exactly 256 MB of RAM. CPU spikes occurred when opening installed applications, however this kind of behavior is what I expect during Live-ISO tests. While it lacked htop, it did include Vim and the system notified me that non-free drivers such as b43 are locally available. This driver cannot be installed during a dry run because it requires a restart. Overall responsiveness of graphical tools was rather clunky.

CrunchBang instantly reminded me of its spiritual successors, of which Archcraft is a rare Arch-based example. Its Conky, unlike BunsenLabs and CB++, reported only actively-used RAM. All of its successors tend to report RAM with active and cached combined, which tends to be very misleading and initially resulted in my surprise that CB's active RAM usage varied between 98 and 108 MB – still a lot for its era but it should be noted that CB did not explicitly target netbooks back in the days. The latter appears to explain why most of its graphical tools tend to take a few seconds to load and navigation to lag a little. As opposed to Ubuntu NE, CB did not ship with Vim but the b43 driver was loaded automatically.

After using both live environments for a few minutes, my netbook got just a little less warm than it did when it ran the latest Live-ISO of BunsenLabs. By then I began to question the validity of past reviewers in the same vein I question today's distribution reviewers focusing solely on eye-candy and combined RAM stats due to the ridiculous belief that RAM is more important than the CPU (remind me to dedicate a separate post on this topic in the future).

But now I was faced with the difficult choice of selecting one OS to install first. Both images lacked GDebi to install DEB packages manually, so it didn't matter for which one I'd have to either “git clone”, “wget” or “curl” my way through things just to get my default system monitor ready. My expectations for Ubuntu were higher due to specifically targeting netbooks, whereas CB got the closest to my daily driver's desktop experience. I threw a coin and Ubuntu won.

Ubuntu Netbook Edition

Ubuntu Network Edition was a remix of Ubuntu specifically targeting netbooks. The last standalone version of it was released alongside 10.10 and was merged with the main branch the following release. As the wiki UbuntuUsers archived its Netbook Edition article in 2012, it is fair to assume that Canonical stopped providing netbook optimizations around the same time.

Installation

Like its latest version, “Maverick Meerkat” shipped with the Ubiquity Installer. After partitioning and setting my language, timezone and user, the installation took roughly ten minutes to complete. Although slower than antiX, which took six minutes, UNE still was seven to ten minutes faster than Salix and Devuan, respectively.

First Impressions

Right after boot, which took 40 seconds but later would decrease to 20, a window popped up stating that support for my language (German) was incomplete, recommending me to download additional language packages. While the b43 driver worked out of the box, it's fairly useless because all repositories went defunct with Maverick Meerkat's EOL back in 2012. This also meant that I'm stuck with what's installed due to this version not supporting the latest SSL certificates. And despite having opted to install proprietary drivers and media codecs, the latter were not installed at all (which is only tolerable for my desired use case).

Fortunately, it came with Vim pre-installed, though it took me a while to find it. It cannot be run by entering “Vim”, instead it's called by its alias “vi”, which is unfortunate when you want to run Vim's predecessor. Unfortunately, I had to rely on top, instead of my standard tool htop, to keep track of resources and processes.

Only running its graphical text editor, GNOME File Manager and GNOME Terminal, UBE claimed 226 MB of active RAM on average. The CPU, while still getting noticeably warm and experiencing spikes, seldom exceeded 50% and mostly varied between 20% under moderate load and 2% when idling. As impressive as those stats may be, navigating the desktop was just as slow and clunky as on its live environment. Typing this on UBE's graphical text editor, in contrast, was very smooth. The battery did not seem to benefit much, as it lost power nearly just as fast as during previous tests and when running Windows 7 Starter.

The odd thing about UBE and perhaps most distributions from that time had to be its proper lack of support for Markdown files. All of my MD files were listed as a type of ROM file with a generic icon. Nevertheless, I was able to access and edit them via both text editors and only had to live without syntax highlighting (which obviously changed when I edited this portion of the review on my Arch machines).

The Outdoor Experience

Roughly a week with mixed weather conditions and the resulting abuse of the pre-installed Solitaire later, it was time to go outside. Because UBE also includes a separate application for quick notes, I was able to easily switch between that and working on my reports. Outdoor temperatures were lower than during previous tests and the wind picked up during the “simulation”, so I was unable to estimate how this setup would perform during regular field trips.

Arguably the biggest annoyance was the lack of multi-touch gestures that cannot be configured at all. When scrolling through my notes, I had to either rely on keys or my touchpad's “mouse” buttons. More often than not, Unity did not react when clicking on an application, usually requiring two or more clicks to run a program. The battery applet behaved as random as my iPod touch 3G's battery indicator (which, I presume, was just normal back then but still is funny AND off-putting at hindsight). UBE also automatically decreased the screen brightness to the lowest possible value after a few seconds, however it did not increase back to the value prior to it, forcing me to constantly increase it manually afterwards and remove accidentally-typed “±”'s in the process.

Despite this, I was able to take some quick notes and work on this section of this very post with a little less worry about this netbook's CPU temperatures. They did increase noticeably after running Tomboy Notes for a few minutes but the machine cooled down after either letting it idle or suspend it for a nearly equal amount of time. Strangely, after unlocking UBE enables my disabled WiFi card, yet network support remains turned off. The window theme also randomly switched to Redmond.

I'm somewhat neutral about UBE auto-mounting USB drives. While I won't mount USB's found on a street, even mounting my own drives gave me conflicting feelings. It's quite reckless from a security perspective but incredibly convenient at the same time.

The Field Trip

There isn't much to say, other than that I'm pleasantly surprised of how well UBE performed throughout the field trip. I was able to take quick notes and type longer posts without a worry about this netbook heating up. At the start of the field trip, the battery was at 96%; after one hour and approximately 20 minutes, the battery was 77% charged. Keeping the tiny eMachines suspended during times when I didn't need it significantly improved its power consumption and remained relatively cool during the entire trip.

TL;DR

After my rocky start with Ubuntu when I first got into Linux, I was vary about Ubuntu Netbook Edition. Things have changed a lot since “Maverick Meerkat” and Canonical started its series of controversial features with the integration of Amazon search results in Ubuntu 12.10 “Quantal Quetzal” less than two years after the release of 10.10. With Canonical dropping its support for 32-bit architectures in 17.10 “Artful Aardvark” released seven years after the initial release “Maverick Meerkat”, it was a sign that most Linux distributions either will also turn their backs on 32-bit personal computers entirely or still provide support but pay less attention to it. While the majority of the Linux ecosystem missed the brief netbook boom, Canonical did take the risk and now granted me the opportunity to revive my old eMachines.

Despite the weak responsiveness of Unity, Ubuntu Netbook Edition 10.10 still does its job well and, in case I should need more programs, I can compile some of them myself. Just to test how well this machine would tolerate compiling, I let it compile the latest version of the text-based web browser Links (without SSL support, as either OpenSSL or NSS needs to be build first). Although this was the first time I ever compiled a program from source, it worked flawlessly (however I did fail at understanding OpenSSL and why it compiles and connects successfully but ends up freezing Links).

This also means that my odyssey finally has come to an end. Because UBE already satisfies my use case, CrunchBang won't get tested – at least for the time being. Who knows what I'll come up with for my ancient Hyrican tower once it has served its purpose as a backup machine / compatibility tester for my collection of ancient Windows software, especially now that I'm familiar with DOSBox-X.

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

After Devuan gave me a massive headache, there was one last distribution left to install. And it gave me a different kind of headache.

Salix 15.0

Salix is a Slackware-based distribution for “lazy Slackers”. Unlike its parent distribution, which is famous for lacking a modern package manager resolving dependencies AND official package repositories, Salix ships with the APT-inspired slapt-get CLI package manager and Gslapt, which strongly resembles Synaptic but lacks the category column.

While Salix offers its own repositories, it is backwards-compatible with Slackware. It offers two ISO's, one a regular ncurses-based minimal installer and the other is labelled “SalixLive”, which ships with a pre-configured Xfce4 desktop and “one application per task”. Because SalixLive provided the second-lightest Live-ISO but a much saner desktop experience than antiX, I decided to try my luck with it.

Installation

Previous reviews from other people highlighted certain aspects of the graphical installer that no longer hold up in version 15.0. The installer, while sparse and boring, now offers the option to install GRUB for those not wanting to use LILO. It also includes a button to run GParted, as partitioning still needs to be done manually for the most part.

During the VM test, I ran the installer as expected and assumed that it inherited locale and keyboard settings from boot. It turned out that I could not log in afterwards because Salix defaults to the Swiss German keyboard when selecting “German” during boot of the Live-ISO. (Nothing against Swiss German but fuck Swiss Germans and their superiority complex over their alphabet lacking “ß”. And if you cannot read this weird letter that's exclusive to the German language, it's the “sharp s” that looks like a cursive “b”.)

This time I set the locale but initially didn't notice that it did not include “de.DE-utf8” (it did include “de” but past experiences with this one on Arch left me traumatized), so I chose “de-latin1”. Before letting the installer do its job, however, I had to resize the toolbar because it blocked the installer's progress bar. I chose the full installation.

The installation process took 20 minutes, just a minute longer than Devuan.

First Impressions

Just like Devuan, os-prober is disabled by default but can be enabled manually. The root user also is disabled and my user is granted full superuser access via sudo. Booting Salix was minimally faster and the log spam caused by the missing b43-firmware was more tolerable. The ISO, however, was so old that Xscreensaver complained about it.

Running htop, I noticed that the installed system was on par with the Live-ISO in terms of demands. CPU and RAM usage were nearly identical. After a while, the netbook started to get warm, yet temperatures largely remained at 26°C, according to the systray's battery icon. I double-checked this value during the course of this test because this value wouldn't change at all, even during noticeable increases – it tuned out htop was closer to the actual temperature once again, reporting temperatures between 33 and 37°C under higher load and after running Salix for two hours. Just like on Devuan, moving the mouse cursor makes the CPU jump to 10%, any other application to at least 48%. Adjusting cpufreg and changing “ondemand” to “conservative” was necessary to stop the machine from suddenly jumping between “max fan activity” to “no activity, gotta shut the hard drive down”.

At this time I noticed that the clock did not display the correct time, indicating that the installer ignored its timezone setting. The language set during install only affects the command-line, meaning that the graphical desktop was set to English. The keyboard, surprisingly, was indeed set to de-latin1.

Of course, Salix also does not offer the missing b43 driver, however its Slackware roots now came in handy due to a SLACKBUILDS being available for both b43-firmware and b43-fwcutter. Although it took me a few minutes to navigate through the process, I noticed that's it not all too different from the Arch build system and its PKGBUILD scripts. Once done, I was provided a working driver for my Wifi card and not only did the log spam disappear but boot times improved noticeably. Switching my default shell to zsh also improved the RAM usage of Salix.

First Annoyances

In the middle of “ricing”, the de-latin1 locale turned out to be a poor choice because it caused Fluxbox to crash instantly and inxi (via Perl) to generate “missing locale” errors. Manually setting the locale to de.DE-utf8 solved both issues. Unfortunately, LightDM does not automatically detect other sessions, so I had to write a .desktop file first and tell startx to default to Fluxbox as fallback. Oddly enough, starting Fluxbox via LightDM renders the systray unusable, whereas executing Fluxbox via startx loads the systray and all autostart applets but nm-applet. The same issue applies to setting a wallpaper with feh: Running Fluxbox via startx will load the .fehbg as intended but stating Fluxbox via LightDM will overwrite the background with its own. We'll get back to this later.

Downloading PCManFM also required lxappearances, though executing the latter will draw the window with blurry text just like it already was the case in Xscreensaver. PCManFM also was unable to detect my USB drive, forcing me to manually mount and unmount it, and lacked a “trash” shortcut (but listed shortcuts for three root sub-directories). Shutdown and reboot via Fluxbox's menu are not possible without superuser privileges but because Salix ships with LightDM, instead of SLIM like Devuan, I wasn't tied to the Xfce session to do both.

(Mom, I'm scared.)

A reboot after enabling os-prober revealed not only the missing Windows 7 Starter entry but an additional set of entries for Salix 15.0 and its advanced options hosting a whopping four kernels, all of the “huge” kind. Strangely enough, trying to download the generic kernel via Gslapt is not possible due to the generic kernel being set to “excluded”. Hey, at least the description for the “huge” kernels include some humor!

But my half-assed Fluxbox session was beginning to piss me off, so I switched to Openbox, which was instantly detected by LightDM. Now being confronted with the same “shutdown” issues as before, I downloaded obshutdown, yet upon closer look, it turned out that this package hasn't been properly configured in a long time, as it attempts to suspend and poweroff the machine by calling ConsoleKit via D-Bus – neither does Salix ship with ConsoleKit (or ConsoleKit2 for that matter), nor has it seen any kind of “standalone” development since it was merged with systemd a decade ago. To break shutdown and reboot out of the silly root prison, one logically needs to mess with sudoers. An it only made it possible for my user to see those commands, yet not execute them without sudo. Because editing this file caused vim to nag me about this being a protected file and thus requiring to force-save any changes to it, I gave up trying.

At the same time, I noticed xscreenlocker-command not suspending the machine when invoked, instead it simply locks it.

(I don't know who came up with this configuration and why distributions managed by old “Unix fans” decided to make this the default setting for their flavors targeting mortals that are mere “home users” but still shipping such a default config in 2024 should be a crime, especially if it intentionally ships a partially-broken XScreensaver.)

Documentation

(NOTE: Yes, the screenshot above was taken on my Acer Aspire and the white border is just one of scrot's rare glitches. This netbook is just to weak for graphical browsers and its screen too tiny to read wiki pages even via Links/Lynx comfortably... and I already reached the point where I stopped typing this post on the Salix machine because vim spammed my USB drive with temporary files.)

Before letting my urge to customize Salix distract me further, I checked the documentation until the weather improved for the first outdoor test.

Because Salix is a much smaller project, documentation is sparse and noticeably hasn't gotten much attention since version 14.1, which was released in 2014, because the b43 driver no longer is being distributed by Salix. All articles are kept in a HOWTO-style that don't provide brief explanations or links to the used tools. This is counter-intuitive as Salix advises to stick to the tools and package repositories provided by Salix to prevent breakages. So while Salix is backwards-compatible with Slackware, you better not try to install packages from Slackware repos such as Alienbob. SLACKBUILD packages, however, don't have an effect on Salix and it generally is safe to use them; the official documentation ignores them entirely.

Speaking of “ignoring it entirely”: The docs do mention that Fluxbox does not ship with a configuration for GDM. Users thus have to manually create a .desktop file to select the window manager in LightDM. I don't buy this justification that Fluxbox doesn't ship it because any other bare-bone distribution is capable of shipping its own file – when I installed Fluxbox on Arch Linux, I didn't have to manually tell LightDM that Fluxbox exists, in fact the necessary file is part of the Fluxbox package.

In defense of Salix, the Arch Wiki provides a faulty example configuration that sets Fluxbox's type – Openbox in Arch's example – to Application, rather than Xsession. This may explain why starting Fluxbox via startx went smoothly but starting it via LightDM borked the entire startup script. Salix at least provides a correct example config in their docs.

Of course, I could have used the desktop shortcut to the IRC channel of Salix but I already moved to Openbox by the time I noticed the Arch Wiki being wrong once again. Relying on man pages was pointless, as packages such as Glapt lack such things and LightDM and Fluxbox being shipped with unedited upstream man pages. The forum is similarly useless.

(Listen, you just can't go “RTFM” when your wiki looks like a bootleg WikiHow that hasn't been updated since 2014 and your half-hearted Synaptic ripoff not even offering a man page.)

The Outdoor Experience

Once I reached this point, I was getting extremely frustrated and refused to even touch my netbook until the outdoor test.

I was sticking to the default Xfce session but relied on xterm, instead of Xfce Terminal, and Vim, instead of NeoVim, to get my stuff done. The weather wasn't entirely suited for this due to moderate winds and clouds but it sufficed, as I didn't feel ready to take this setup with me during actual field trips.

To my surprise, the machine's temperatures remained quite low during the first ten minutes. While the battery applet in the systray appears to be stuck at 26°C regardless of anything, htop reports the system varying between a very comfortable 20 and 24°C (as long as I don't accidentally cover the CPU with my leg but that's just shitty hardware design). After 20 minutes, temperatures rise to 30°C and the netbook gets noticeably warm even when making sure that the CPU can “breathe”. The battery, while its health being reported being 92%, did not run out as fast as initially suspected, even with increased screen brightness. However, the panel tracking the battery does not change until reaching a drop of either 2 or 3%. 20 minutes claim approximately 17% of battery power, meaning that the battery loses 1% per minute on average.

Simulating the field experience, I tweaked XScreensaver to lock the netbook before suspending and gave it a run. Shockingly, while the system does suspend instantly, it locks it after unsuspending it and takes a few seconds to do so, leaving my logged-in desktop accessible. Before suspending, the machine resided at 71% and 30°C; I unsuspended the netbook after six minutes and the battery applet dropped from 71 to 69% within five seconds, while htop reports a CPU temperature of 23°C (the battery applet remained at 26%).

After a while, the automatic update reminder popped up on the panel, despite lacking an internet connection. I assume that its script to always report software updates, regardless of whether there are any pending.

At 66%, I decided to switch to my half-assed Openbox session. Right away I noticed temporary save files generated by Vim automatically being stored on my USB drive, cluttering all directories that have been touched by any file I save. The battery, at the start stating 64% via PowerKit, dropped to 63% after not even a minute and further dropped to 60% after five minutes since the start of the session – a negligible difference when compared to the Xfce session. The temperature at least did not exceed 32°C but that also is a fairly minor improvement that only becomes apparent when the wind is blowing and thus provides some external cooling.

The field trip

One day before the field trip, I noticed that the reason why PCManFM cannot access trash and mount my USB when running Openbox. LightDM lacked D-Bus activation – as much as I do not want to curse at this point but FOR FUCKS SAKE this is just plain bad. Who the fuck ties D-Bus to a specific DE?!

After manually editing LightDM.conf, trash became accessible but mounting not. Turns out this required Polkit. I wrote a a set of general rules and ended up making mounting impossible on both my customized Openbox and the default Xfce session. My file, very “boilerplate” but only required one different group name for one rule, conflicted with more than one rules file by Salix and I can't tell which one because not only are all rules located in /usr/share/polkit-1/rules.d/ (its /etc equivalent is empty, which becomes problematic when enabling the root user because root inherits the restrictive regular user configs!) but Salix tied lower-level stuff such as shutdown to Polkit, whereas the file for default rules is empty.

This prompted me to not take my netbook with me and instead rely on my iPhone to take quick notes. The rest of this was typed on my Acer Aspire running Arch Linux.

TL;DR (about time)

Good grief, I am jaded. I get that Salix is a much smaller project targeting “lazy Slackers” but attempting to do stuff outside the pre-configured desktop is a nightmare. Hell, even the pre-configured desktop experience becomes painful once attempting to customize things like XScreensaver.

I also get that this particular netbook is not the pinnacle of computer technology. Even running a lightweight DE such as Xfce drives this weak CPU crazy, yet switching to a very simple window manager usually should solve this issue. Just like in the case of Devuan, not even that is enough.

Overall, my biggest issue with Salix is that it claims to be “Slackware for lazy Slackers” whilst simultaneously discouraging users to use it like Slackware. Slackware leaves it to the user whether they want the root user to be enabled or not, Salix disables it automatically during install; Slackware doesn't handle dependencies at all but at least encourages the usage of third-party repositories and Slack Builds; Salix does resolve dependencies but discourages the usage of both Slackware packages and third-party repositories whilst entirely ignoring Slack Builds BUT for some reason subtly pointing towards flatpak. While Slackware comes with an insane amount of bloat, Salix does not but still will install a lot of unneeded X tools even when selecting a basic install.

But while we're at this topic and this will apply to Slackware, as well: How can you claim security benefits by restricting shutdown to root when LightDM constantly runs in the background with root privileges? And why does Slackware still not offer HTTPS downloads at the very least? Why does Salix cripple the root user and leave the regular user with highly-restricted privileges forcing Vim to demand any change to files such as Polkit rules to be force-saved, whereas Slackware ships none of that by default? Why does Salix claim “one tool per task” but ships both nano and NeoVim, alongside Parole Media Player and another separate music player? Why does it also pull every damn language module for LibreWolf and crap dozens of authorization dialogs in various languages in Polkit actions while the desktop ends up being a weird mix of your chosen language and English?

What now?

As I was frustrated, I gave three other distributions, two of which are systemd-based, a live spin. BunsenLabs, while responsive, was unusually heavy and still made the CPU spike whenever the mouse cursor was moved. It also doesn't even appear to support MBR partition tables properly anymore and refuses to mount the desired root partition. Crunchbang++ performed even worse, starting with a loud beep prior to boot and loading its post-install welcome screen in live mode. The only noticeable difference I managed to witness was antiX's htop reporting the CPU to be at a scaringly-low temperature of 12°C whilst still making it spike during sheer cursor movements and the fan behaving just as oddly as it did on Devuan (mostly not at all). antiX also ships with Conky and monitoring applets enabled that are as misleading as they are wasting resources.

Maybe I'm being unfair to the remaining distributions for plain x86 machines. This device sucks in most aspects and it's pure crap in contrast to my Hyrican tower with its lower-end NVIDIA GPU but the latter certainly would cause a different set of issues that would make any distribution targeting x86 look worse than they might when running on a close-to-ideal machine.

On the other hand, this series of tests gave me a glimpse into the past. Back in the days, it was common to first acquire approriate hardware to run most Linux distributions without having to waste hours on the hunt for drivers. The kernel, alongside everything on top of it, still are rather slow to keep up with hardware fresh out of the factory that sadly is also more tailored to the (at that time) latest version of Windows. Machines tailored to offer a pure Linux experience still are quite rare and more often not just plain overpriced. There hardly are any budget devices that aren't a train wreck like those sold by Dell and some Lenovo models (that may ship with a decent Linux but may be traumatic to repair shop workers).

Now that Salix failed my use-case miserably, I'm back where I started. I may give antiX a proper test. I already installed it, yet I'm just so tired of testing now that this endeavor will be put on pause for a while.

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

Part I Part II

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 GNU/Linux 5.0.0 “Daedalus”

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.

Installation

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.

First Impressions

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” 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.)

The Outdoor Experience

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).

TL;DR

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