💾 Archived View for magda.cities.yesterweb.org › gemlog › 2024-04-07.gmi captured on 2024-08-31 at 12:01:42. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-05-10)
-=-=-=-=-=-=-
---
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 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.
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.
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.
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.
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.)
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.)
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.
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.
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?
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 differnce 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