Long time no see, so I’m going to synthesize here the experiences and the epiphanies I had with Linux in the last couple of months. You should be at least as shocked as I was, but I fear you won’t be, for most of you are too superficial to realize the importance of some of the facts.

§1. Introduction: testing and evaluating, but how?

As I always said, whoever is testing a Linux distro with a desktop environment in a virtual machine is a moron. What are they testing? That the installer and the package management system work? If someone tests a Linux distro for evaluating how appropriate it would be for becoming their daily driver for a laptop or a desktop PC, then they must test on the bare metal, because it’s the only way to assess the hardware support (a virtual machine offers a standard, irrelevant hardware configuration) and also the responsiveness (which also depends on the actual drivers needed for the actual hardware). It’s far from uncommon to find that a distro that works great on a given hardware doesn’t properly support some specific hardware (at least, not without major fiddling), or even that it freezes on certain systems. Tests and reviews in a virtual machine are totally useless.

Now, the systems I tested what I tested in the past 14 months are:

As I noticed long time ago, the issues Linux has with these systems are:

  • For my Acer, the on and off, and in recent kernels the lack of correct support for the audio jack connected to Realtek’s ALC282 chip. When the traditional fixes stopped working (and they stopped forever, as one patch in the kernel fixed Acer models P648/P658 with codec ALC282 that only have one physical jack for headset in a way that permanently affects my P645 that has two separate physical jacks for headphones and mike), I needed to rely on manually switching the audio output from “Speakers” to “Headphones (unplugged)” (even when plugged in, the system can’t acknowledge that, yet the audio goes through if directed to them!). Should I have only tested in a virtual machine, I’d never had noticed this issue! A severe consequence is that on this Acer I cannot use Cinnamon, because its retarded developers (yes, Clem, you and your clique!) decided to go the GNOME way of removing features and choices, so that in Cinnamon I cannot choose an “unplugged” device for output!
  • For my wife’s HP, only recent kernels and only select distros support on the Live/installation media the Realtek RTL8821CE, which means no Wi-Fi and no Bluetooth, and without Wi-Fi there’s no way I could get such a long patch cord to use the wired Ethernet, so this is totally a no-go.

Furthermore, for both systems, there were two means of testing:

  • Live media on USB flash drives using Ventoy, without persistence. This kind of testing is ephemeral, and only meant to assess the hardware support, the overall functioning of the distro, and various other software assessments. To a limited extent, further software can be added to a live session.
  • A permanent installation on an external 128 GB drive. This is how I tested for long periods of time several Arch derivatives, Fedora 34, and more.

As there is a surprise here, there’s something more to be said about that last point.

§2. Commentary on external drives

Nobody uses HDDs for external drives these days, right? Except for backups, but then they should be multiple backups, such as 3 copies of the important stuff. (Apparently, some people also use external drives for some huge games, but I’m not talking about those retards.)

So we have to assume that people who can afford them are using external SSDs, if not for backups, then for additional storage and possibly for installing Linux distros when they don’t want to install them internally.

CAUTION: Installing any Ubuntu flavor (except for Lubuntu) on an external drive is not advised, because of a bug in Ubiquity reported on 2014-11-25, still unfixed, and that will never be fixed (because in Ubuntu 22.04 LTS Ubiquity will be replaced by the Flutter-based Ubuntu Desktop Installer): Bug #1396379: installer uses first EFI system partition found even when directed otherwise (duplicates: #1173457, #1591352). Simply put, when installing itself externally, Ubuntu will still install the bootloader on the first internal drive! Lubuntu is the only exception, as it uses Calamares.

Back to external drives themselves now.

If you were to install on a USB flash drive (and I mean install on it, not use it as a live session, with or without persistence!), don’t fall for devices that are worse than these models:

  • Intenso High Speed Line 64 GB (Art. 3537490) — street price less than €19
  • Intenso High Speed Line 128 GB (Art. 3537491) — street price less than €30
  • Intenso High Speed Line 256 GB (Art. ‎3537492) — street price less than €50

The official speeds can be read in the pictures above.

CrystalDiskMark 8 performance for exFAT (128 KB) under Win7:

The sequential write performance is a bit worse with NTFS (4 KB) for the larger one:

Most flash drives would perform much, much worse, especially in random writes… and most HDDs would also perform worse!

Under Win10, the NTFS sequential write is strangely degraded for the larger drive:

If we were to test it under Linux, the equivalent app, KDiskMark, doesn’t give comparable results (different caching at the OS level, or different algorithms?). The 128 GB one tested with NTFS (even formatted with ext4, it doesn’t fare any better!):

There might be other flash drives that look tempting, such as the 3.1 edition of the Moon line from Philips (the 64 GB one at less than €15), manufactured by SMI (SiliconMotion), with official maximum speeds as follows:

  • Read: 180 MB/s
  • Write: 45 MB/s (128-256 GB), 35 MB/s (64 GB)

The test results might look decent enough for the 64 GB drive under Linux…

…but I can assure you that installing a Linux distro on such a USB stick won’t satisfy you! The real random writing speed is the pathetic one displayed by CrystalDiskMark, not the one from KDiskMark!

UPDATE: Not only these Philips flash drives have difficulties in being detected on some computers or some USB ports, but my 64 GB one managed to die all of a sudden, in such a way that no disk partition utility can manage it, in no version of Linux or Windows! When working, it was seen as SM3280A MEMORY BAR (SM3280 isn’t such a bad device on paper), but since its death it became SMI USB MEMORY BAR without an actual drive! To date, it’s the USB flash drive with the shortest lifespan I ever experienced, and I owned dozens of them! My first USB stick was a Transcend of only 16 MB, and I mean megabytes! (That was fine though, as a floppy had 1.44 MB or, specially formatted, 1.68 or 1.72 MB.) So Philips is from now on blacklisted for good!

ComputerBILD 12/2021 has found better, especially for 256 GB, but those better models are more difficult to find:

To the point: Patriot Supersonic Rage Pro tends to be expensive and hard to find in Europe, ADATA UE700 Pro is rather hard to find and the 256 GB model requires quite some power from the USB port (but I generally trust ADATA with HDDs and SSDs), and SanDisk Extreme PRO is likely to run very hot, as most recent SanDisk models. I only wonder why did they only test the 512 GB Transcend JetFlash 930C and not the 128 GB and 256 GB models of Transcend JetFlash 920, which is said to perform quite well:

On the other hand, while ComputerBILD has preferred to test the Patriotic Supersonic Rage PRO, some people have found that Patriotic Supersonic Rage Prime, despite having a smaller sequential writing speed (289 MB/s vs 430 MB/s), has a much better random writing speed (37 MB/s vs 17 MB/s), which is more important in my opinion!

Some other people, with faster hardware, have obtained even faster sequential reading speed and fabulous random writing speeds for Patriotic Supersonic Rage Prime, potentially making it seem the best choice ever… until some real-life tests showed that copying large files beyond the internal caching abilities of the flash drive makes the writing speed drop and stabilize at less than 20 MB/s!

It’s therefore impossible to trust any such tests, and I’m not just talking of CrystalDiskMark or of whatever ComputerBILD have used. AS SSD Benchmark, ATTO Disk Benchmark, HD Tune Pro, H2testw, f3write/f3read… none of them can replace the real experience of having an OS installed on such a drive and see how it fares!

My experience with Intenso High Speed Line 128 GB has been great, and no other USB flash drive I own could match it. (10 flash drives of 8 different brands, so I might need more of them, right?) Also, it doesn’t get hot under continuous usage, whereas e.g. Sandisk Ultra Luxe (I’m not sure what was tested by ComputerBILD for 256 GB, as the text reads Sandisk Ultra Flair, but the picture shows a Sandisk Ultra Luxe) gets extremely hot, thus only being suitable for backup, but nothing more.

By some accounts, Samsung FIT Plus should be a smarter choice than Intenso High Speed Line, with random writing speeds about twice as high. The official packaging, as well as the website, are less optimistic about the sequential read speed, limiting the 64 GB model to 200 MB/s, and the larger ones to 300 MB/s.

Here’s what I got for the 64 GB model (factory-formatted in extFS), first under Win7, then under two more recent computers running Win10, always compared to the Intenso HSL of the same size (but NTFS):

Good enough for installing Linux on such a thing, I’d say.

§3. The Fedora Saga, Part I

I have spent quite some time lately with Fedora 34, and I was beginning to consider it great… but something happened at some point. (I’ll leave that for later, though.)

First, some advantages of using Fedora:

  • While being a fixed release distro, if offers in the updates the latest versions of the major desktop environments and of their component apps. For instance, Fedora 34, released with KDE 5.21.3, now has 5.22.4; released with Thunar 4.16.5, now has 4.16.8, which is a security update that Xubuntu 21.04 still lacks; released with MATE 1.24.1, it now has 1.26.0.
  • Security-wise, patches are reaching Fedora usually faster than Debian and Ubuntu (by design, Ubuntu doesn’t care about the security updates of the packages in Universe).
  • Unbeknownst to some, it has several Live Spins and Live Labs of excellent quality, and less bloated than in other distros (e.g. the MATE ISO has 2 GB vs. 2.8 GB in Ubuntu; the XFCE spin has 1.6 GB vs 1.8 GB in Xubuntu; LXQt has 1.4 GB vs. 1.9 GB in Lubuntu).

Now, some disadvantages of Fedora:

  • Fewer extra repositories (typically RPM Forge plus a bunch of others, or maybe UnitedRPMs; not sure about RPM Sphere, with 2,400+ packages).
  • The COPR system cannot compete with Ubuntu’s PPAs.
  • Fedora is pushing Flatpaks on you (e.g. in Discover you’ll find the same apps both as packages and as flatpaks!), the same way Ubuntu is pushing snaps.
  • For a GUI package manager, dnfdragora is simply unusable, and unfortunately the recently reborn yumex-dnf is much slower than YumEx was 15 years ago. One can always use Plasma Discover and GNOME Software, but they are not granular enough.
  • SELinux gives warnings even with the default install or the live session. Do we really need security mechanisms such as SELinux (Red Hat) or AppArmor (Ubuntu)? Can anyone really claim they were saved because such a mechanism was in place? (I very much doubt it.)
  • The kernels are pushed too soon into a point release, e.g. Fedora 34 was released with 5.11.12, but now it has 5.13.9 (for a comparison, Manjaro defaults to 5.13.11, and it’s a rolling-release distro).
  • They don’t tolerate criticism (hey, Max Spevack is long gone!), so there’s no place for such community experiments. Here’s how they promptly invoked their Code of Conduct against someone who simply said that “Dnfdragora is very slow” and Discover “is pushed down everybody’s distro-throat which is pretty much a catastrophe.”

On the practical side, Fedora 34 installed on that Intenso High Speed Line flash drive has performed very satisfactorily for the last about 3 months (since May 6, as mentioned here). I have installed and removed lots of packages, and I have tested most desktop environments (all but the tiling ones), but eventually I went into using XFCE almost exclusively. After all, I started by installing the XFCE spin and quickly customizing it through xfce4-panel-profiles (“Redmond 7”), then even adding yaru-icon-theme, yaru-gtk3-theme, yaru-gtk2-theme.

At some point, I wanted to explore the risks of relying on Fedora as a distro that needs to be upgraded twice a year. In other words, I wanted to get the taste of Fedora 35, but without resorting to Fedora Rawhide, which is notoriously much less reliable than Debian Sid, openSUSE Tumbleweed, OpenMandriva Cooker, Mageia Cauldron, and Arch Linux and its derivatives.

👉 Here’s the catch: in Fedora there’s a thing called Fedora Branched, something between Rawhide and Next Release! Simply put, once a Branched version has been… released, in our case Fedora 35 Branched, what you get there is something more stable than Fedora Rawhide, more like Debian Testing!

According to the official schedule (or milestones-only), “Branch Fedora Linux 35 from Rawhide” took place on 2021-08-10, and I could notice that packages started to appear on the German mirrors on 2021-08-12 (Aachen, Erlangen). Since August 17, I tried several spins of the latest “compose” ISOs, with good results, despite Fedora 35 still having 1294 open bugs (compared to 5799 bugs in Rawhide).

👉 Since we’re here, let’s summarize the ways one could get Spin ISOs (Workstations other than GNOME) for Fedora:

Now, RPM Fusion usually starts supporting Fedora Branched (here, Fedora 35) one or two weeks after Fedora branches, but I preferred to use the smaller UnitedRPMs for the codecs & shit. As it happens, I tested:

  • Fedora 35 Branched: several LXDE, LXQt and XFCE spins from August 17 to August 26
  • Fedora 35 Branched: the KDE spin from August 26
  • Fedora 34 Updated: the LXDE, LXQt, XFCE and KDE spins from August 16

For Fedora 35 Branched, UnitedRPMs worked just fine. You can take a look at what they have in store (some 134 RPMs, mostly multimedia & stuff). The standard way to add it is as follows:

sudo rpm --import https://raw.githubusercontent.com/UnitedRPMs/unitedrpms/master/URPMS-GPG-PUBLICKEY-Fedora
sudo dnf -y install https://github.com/UnitedRPMs/unitedrpms/releases/download/19/unitedrpms-$(rpm -E %fedora)-19.fc$(rpm -E %fedora).noarch.rpm

In my case, I installed unitedrpms-35-19.fc35.noarch.rpm. Then, I could even install yumex-dnf, by adding the repo for Rawhide (if I remember correctly).

Screenshots time! A quickly customized XFCE spin:

And a quickly customized LXDE spin:

They were not installed, but used as live sessions, so everything that has been added counts against the RAM usage. Just ignore the memory footprint, OK?

Apparently, at this stage, I concluded that transitioning from Fedora 34 to Fedora 35 should be a pretty safe endeavor, so that I could stay with Fedora 34 (not 35 Branched!) until the time comes to do this:

sudo dnf install dnf-plugin-system-upgrade
sudo dnf system-upgrade download --releasever=35
sudo dnf system-upgrade reboot

I might have been overly optimistic, but you’ll have to read about many other things before learning more about that. (Suspense, maybe; cliffhanger, not so much.)

§4. LXDE, LXQt and PCManFM (after a long intro)

There’s pretty much you don’t know about them, really. But to start with the beginning, why LXDE or LXQt?

To start with the beginning, I very much love minimalism, as long as it offers the quintessential usability offered by the GUI concepts introduced with Win95. To me, everything that I need UI-wise has been offered by Win98/Win98, and later by WinNT4/Win2k. I used WinXP with the classic look of Win2k, which was the look of Win95 with a few refinements. I don’t need the more advanced “helpers” that are now common in several desktop environments, such as the Exposé-like window overview mode (Compiz, KWin, GNOME3). I don’t even need the multiple workspaces available for decades in *nix/Linux. The traditional desktop metaphor is all that I need, and that’s one of the reason I still have a nostalgia for GNOME2, now reborn as MATE, in which I’d rather use a single panel in these days of the moronically wide screens in which the vertical space is scanty.

I cannot understand the forced tiling window managers, because what I’d need is the on-demand tiling capabilities, and such capabilities were present in both desktop metaphors offered by Win3.1/Wfw3.1 and Win95/Win98/WinNT4/Win2k. The current stacking window managers for Linux are totally retarded in comparison to any of the previously mentioned Windows versions, as they are merely the poor man’s on-demand windows tiling. There’s no easy command to tile all the windows vertically or horizontally, as there was in Win95!

Once I realized that absolutely all the window managers and all the desktop environments are less ergonomic than Win95, and sometimes than Win3.1, I decided I don’t want to use the horrendous bloat called KDE Plasma 5, with its infinitely complex System Settings! Even if KDE is now usable, I cannot forget KDE4, whose main “feature” was its ability to crash every couple of minutes, and who had this pathetic Folderview Plasmoid (image source):

At the same time, on occasions I miss Win3.1’s Program Manager (image source):

Well, I also miss those times when everything worked perfectly with 4 MB, not 4 GB of RAM, and when “games” in most cases meant “MS-DOS games”; in those times a VGA video card used to have 256 KB of VRAM and a bulk price of $12:

Those were great times. Today, the fan of a tremendously powerful CPU (not a 486DX75) screams because the user has started a web browser that just crunches tons of useless but spying JS instead of just text and images. Today, to open a text editor in an X11 session, you need 1 GB of RAM for the OS itself.

It’s no wonder I was tempted by lightweight desktop environments such as LXDE and LXQt. I wanted my computer for the apps, not for the OS + Desktop Environment!

Well, it’s not that simple.

LXDE is practically dead, if you ask the pundits. The move from GTK+2 to Qt (instead of moving to GTK3, which is what MATE and XFCE did, even for the price of a higher memory footprint), which has led to LXQt, started mid-2013:

To be honest, migrating to Qt will cause mild elevation of memory usage compared to the old Gtk+ 2 version. Don’t jump to the conclusion too soon. Migrating to gtk+ 3 also causes similar increase of resource usage.
Since gtk+ 2 is no longer supported by its developer and is now being deprecated, porting to Qt is not a bad idea at the moment.

From the comments:

GTK3 is bloated and very much buggy. The PCManFM is spontaneously buggy with GTK3 in the same places where it never fails with GTK2, and GTK people even don’t reply to some bug reports. And also GTK3 is much more eager on memory and CPU. I’m sorry to disappoint you but GTK3 is way to nowhere, even if it is somehow closer to GTK2 than Qt is.

I completely agree with you. Recently I checked GTK-3.8. It’s bloated more than ever. Instead of fixing its bugs and shortcomings, they’ve just added redundant widgets to GTK+ and removed some useful ones. GTK+ could have a bright future in hands of a group, who cared about usablility and paid attention to feedbacks.

In full fairness, there is an unofficial GTK3 port of LXDE by Arch Linux, but four components still have issues. Still, lxde-gtk3 can be installed in Arch and its derivatives. However, I didn’t want to test how much this community was able to achieve in terms of bug fixing. If there isn’t any live ISO spin with it preinstalled…

The official Status of LXDE components page shows that most efforts to maintain the GTK+2 LXDE are being made by Andriy Grytsenko, especially regarding PCManFM. Most components are stalled. The LXDE blog still shows activity, though:

All in all, this is sad. And, obviously, Lubuntu has switched from LXDE to LXQt since Ubuntu 18.10, which makes LXDE as good as dead for all practical purposes.

However, I keep finding “the new” LXQt much uglier than LXDE!

👉 Fedora 34 LXDE Spin:

👉 Fedora 34 Lxqt Spin:

👉 Lxqt in Lubuntu 21.04:

👉 Lxqt in ArcoLinux 21.09.8:

There is also an unofficial Linux Mint 20.2 LXDE spin of the German community (downloads). The drawbacks of being based on Ubuntu 20.04 LTS: PCManFM 1.3.1 (the latest version of the file manage e.g. in FC34, Debian 11, Ubuntu 21.04 is PCManFM 1.3.2). Mint has updated XFCE to 4.16, but LXDE not being their cup of tea, this unofficial Mint LXDE is stuck with what Ubuntu 20.04 has in the repos. Repeat after me:

Real men don’t use Ubuntu LTS and its derivatives!

Nonetheless, there is a tiny little Japanese (just kidding) who on 2021-07-20 wrote a blog post: I have installed the ultra-lightweight LXDE version of Linux Mint 20.2, which is very popular in Germany.

The Linux Mint German User Forum has an unofficial LXDE version. It’s quite active here, and it’s a big difference compared to the decline of the Japanese forum. What has happened to Japan these days?

Indeed: what did happen to Japan? Joke aside, this guy made some RAM comparisons (free -h), plus the HDD footprint (df -h):

I wouldn’t care that much about 100 MB of RAM. The same guy has tried Debian 11 with LXDE, and here’s another set of numbers:

With all my love for LXDE, it’s stuck to a past with some components that never saw the light of day, such as a laptop brightness adjustment. LXQt has implemented it, however not by using the specialized laptop keys, but as a separate app (lxqt-config-brightness, part of lxqt-config):

The good part of it? I never thought of adjusting the brightness and the backlight separately because it was a practical impossibility in other desktop environments and in Windows, as the specialized keys only change the brightness alone (or they change the backlight in sync with the brightness, how the fuck would I know?). The bad part? Well, it doesn’t react to the brightness keys, at least not on my laptop, and not in Lubuntu and ArcoLinux.

But what makes me hate LXQt is the way new developers (Hong Jen Yee doesn’t seem to be doing much these days) treat the legitimate user requests, such as Issue #558: Adding shortcuts to View menu:

artmg opened this issue on Aug 5, 2017

I was thinking of modifying pcmanfm-qt/pcmanfm/main-win.ui to add shortcuts in to make it work the same as original PCManFM

Can anyone let me know if Ctrl-1, Ctrl-2, Ctrl-3 and Ctrl-4 would be unsuitable choices, before I submit a PR. Thanks

tsujan commented on Dec 25, 2017

Closed by 4a96c1c because the view buttons are on the toolbar now.

Fuck me sideways! In the original (GTK/LXDE) PCManFM, the view mode could be changed with the keyboard, the way it can be done e.g. in Thunar or Caja, but in PCManFM-Qt the arrogant developers have decided that the users must use the mouse instead!

To me, this is a legitimate reason to boycott LXQt.

Other aspects of PCManFM and PCManFM-Qt, later, after having discussed something about Thunar and XFCE.

En passant, let’s notice, à la Dedoimedo, that in the screenshots above the GTK version of PCManFM has a low-contrast theme and the items in Places are too closely packed, while PCManFM-Qt has a better contrast, and the items are a bit overspaced. The caveats of (not) trying to get a uniform look for Qt and GTK applications…

§5. Explanatory entr’acte (that’s the English spelling)

I have started this post more than 6 weeks ago, and I stopped the writing for more than 3 weeks. This is why the rest of the post will likely be more succinct than intended, with conclusions rather than detailed explanations.

There is a reason why they have this saying:

§6. The Day Fedora Froze

As I told you, I had a Fedora 34 installation on a very decent flash drive (128 GB Intenso High Speed Line). As I was updating my backups on external HDDs (depending on the type of data, with 2, 3, or 4 identical copies on different drives), I thought of using my wife’s HP desktop for an extra copy/sync machine, especially as it has 4+1 front panel USB ports. That HP running Win10, I thought of using the live USB stick and ignore the frigging Windows.

It all worked well, until, during a copy of 150,000+ files from one drive to another, it completely froze!

After a reboot, it did the same after it had copied some of the 150,000+ files!

So Fedora 34 froze, twice, first time with kernel 5.13.9, then with kernel 5.13.10, both times using xorg-x11-drv-nouveau, when trying to copy 150k+ files with Thunar 4.16.8! It was exactly as in n°2 in “Diagnosing a hang” on freedesktop.org:

Display is frozen in X, but mouse cursor moves.

But was it really because of nouveau? Based on the reported bugs, I thought the following three to be relevant:

My flair (which is pretty solid, even at this age), telly me it’s one of these:

  • The rtl8821ce driver for Realtek RTL8821CE Wi-Fi-cum-Bluetooth.
  • A combination of rtl8821ce, nouveau, and high I/O due to heavy file copying.

What I did to get things done, was to boot (Ventoy) an live ISO of Ubuntu MATE 21.04 and perform the copying using Caja. No incidents whatsoever.

§7. The Realtek curse

The funny thing is that I have a soft spot for Realtek (I must have been one of the 2-3 guys who loved their cheap video cards in the early 1990s), and I always blame the Linux kernel team for any discomfort related to a Realtek device (such as the ALC282 audio issue). With RTL8821CE, things are a bit fuzzy though.

This Wi-Fi/BT combo seems to have caused trouble to many people. Random reports:

There is a history of why two totally different drivers exist for this chip, rtw88 (rtw88_8821ce) and rtl8821ce-dkms (rtl8821ce). Tomás Pinho dixit:

The Linux Kernel 5.9 version comes with a broken rtw88 module developed by Realtek that has poor compatibility with most revisions of the 8821ce chip.

You must disable it by adding the following to your module blacklists (/etc/modprobe.d/blacklist.conf):

blacklist rtw88_8821ce

Then, make sure you have the rtl8821ce module correctly installed.

I don’t even want to agree. I’d like to stick to what the kernel comes with. Increasing the collaboration with Realtek should be the thing to do, not writing something totally different! But hey, these days everyone is forking everything on GitHub, just because they can. Optimistically put,

rtl8821ce should work with the rtw module inside the kernel out of the box since kernel 5.12.

I noticed the RTL8821CE is a hard nut back in April, when my wife’s cheap HP Pavilion Gaming Desktop TG01-1209ng (“gaming” my ass, its Nvidia GeForce GTX 1650 with 4 GB GDDR5 is too modest for what they call games nowadays) was supported by Kubuntu 21.04, but not by ArcoLinux, Salient OS, Debian testing (weekly KDE with non-free firmware), siduction, and more. In May, RebornOS added support for RTL8821CE, but generally the Arch world has to build rtw88-dkms-git or to install it from Chaotic AUR.

Here’s some of my recent experiences with live ISOs vs RTL8821CE:

  • Manjaro: works perfectly (rtw88_8821ce), powerful signal even when far away from the router.
  • Debian 11.0.0-live+nonfree KDE, XFCE, MATE, LXDE, LXQt: nope, not detected!
  • Garuda Linux, as of 2021.08: nope, not in the live ISOs, in spite of their owning of Chaotic AUR!
  • ArcoLinux: works perfectly (rtw88_8821ce), powerful signal even when far away from the router.
  • Ubuntu 21.04 (KDE, MATE, Xubuntu, Lubuntu): works perfectly (rtw88_8821ce), powerful signal even when far away from the router.
  • Fedora 34 and its spins: as released, nope. Installation with updated kernels, yes, but it can crash-freeze in some kernels, as discussed.
  • Fedora 35 Branched: works apparently well (rtw88_8821ce), powerful signal even when far away from the router. Can we assume it won’t crash ever again?

Frankly, I don’t need Linux on my wife’s desktop, but suppose I have to recommend a distro to someone who might have similar hardware: what could I vouch for? (openSUSE Tumbleweed doesn’t count.) Manjaro, Ubuntu, possibly even Fedora 35?

§8. Did I just say NVidia?

There was a thing that happened on the said HP featuring an Nvidia GeForce GTX 1650: when I tried Linux Mint 20.2 (all three flavors), they simply could not boot on HP Pavilion Gaming Desktop TG01-1209ng! Garbage post-GRUB screen, and it stays so. The official advice is crap:

Some graphics cards and motherboards don’t work well with the open-source drivers present in Linux Mint by default.
The easiest option is to select compatibility mode from the USB stick (or DVD) boot menu.

Compatibility Mode is a joke in Linux Mint, it looks like Windows with VESA drivers. Really, WTF?!

Release Notes for Linux Mint 20.2:

Solving freezes during the boot sequence

Some graphics cards don’t work well with the open-source driver present in Linux Mint.

If Linux Mint freezes during boot time, use the “Compatibility Mode” boot option.

In this mode you should be able to boot Linux Mint and install it on your computer.

After the installation, reboot the computer and wait for the boot menu to appear.

Add the “nomodeset” option as illustrated below:


If your graphics card is from NVIDIA, once in Linux Mint, perform the following steps to install the NVIDIA drivers:
– Run the Driver Manager
– Choose the NVIDIA drivers and wait for them to be installed
– Reboot the computer

With these drivers the system should now be stable and you no longer need to use “nomodeset”.

Note: If you’re using an Optimus card, you’ve nothing more to do. Upon reboot, a system tray icon should show up indicating which GPU is currently active. Click on it to switch GPUs.

Note: If you still cannot boot try one of the following solutions:
– Try with “nouveau.noaccel=1” instead of “nomodeset”.
– Try with “noapic noacpi nosplash irqpoll” instead of “quiet splash”.
– After the installation, use “Advanced Options” -> “Recovery mode” from the boot menu and choose “resume”.

They must be kidding me. Linux Mint was supposed to be for n00bs, not to create such headaches!

Here’s how Mint should have done it:

Here’s a summary of my experiences on the said hardware:

  • Linux Mint 20.2: fuck off.
  • Linux Lite 5.6 (also based on Ubuntu 20.04): fucked graphics just like Linux Mint 20.2; in Compatibility Mode, even worse: “Failed to start Light Display Manager.
  • ArcoLinux: works with nvidia (kernel 5.13.8).
  • EndeavourOS: works with nvidia (kernel 5.13.12).
  • Fedora 34 and its spins, original ISOs: cannot start Plasma session (Wayland), but XFCE (X11) works fine (w/o WiFi and BT though).
  • Fedora 34 updated and 35 Branched: as above, X11 works (nouveau), Wayland doesn’t (Plasma session crashes in a loop, then refuses to start). (Hint: echo $XDG_SESSION_TYPE)
  • Ubuntu 21.04 MATE and Lubuntu: as above.
  • Ubuntu Impish MATE: as above.
  • Manjaro KDE 21.01 (kernel 5.13.11): works with both nvidia and nouveau, but X11, no Wayland.

I forgot what else I tried.

I very much doubt I’ll ever purchase a computer with Nvidia crap on it (have you noticed how on Win10 it installs 6 scheduled tasks for telemetry alone?), but this is annoying for 2021. I’d like to switch to AMD completely in the future (despite not having tried a Radeon under Linux since 2007, so I don't know anything on xf86-video-amdgpu, vulkan-radeon and whatnot), unless the ARM craze takes us all over.

§9. A few words on Manjaro

So far, Manjaro didn’t look that bad, and I almost forgot what made me fall out of love with it years ago. Here’s however (yes, I shouldn’t link to Reddit!) a few well-put ideas in Please, please stop recommending (beginners) Manjaro:

Here are some practical reasons why you should not use Manjaro:

■ Manjaro holds back Arch packages, but they do not hold back the AUR itself. This means that some AUR packages simply won’t work due to incompatible library/packages, and you basically won’t be able to do anything. For me this happened with Anbox, and KDE’s Mauikit suite of apps, but I’m positive that this issue will occur with other packages. You don’t actually get access to the full AUR, just most of it.

■ The AUR helper that they provide, pamac is slow, and it failed to compile packages many times when I used it. However, other AUR helpers I have used (I mainly use yay) are much faster, and they very rarely fail to compile packages.

■ Although Manjaro holds back packages, they don’t actually intervene when their is a bug or a similar or a similar issue. And even if they did intervene, any patches made would bring new bugs/issues, and so on. There is no real point to holding back packages, and what they do just makes the system less stable.

Reasonably true, at least with regard to the fact that delaying packages makes it out-of-sync with Arch, and thus out-of-sync with all third-party repos (of which I have a weakness for Chaotic AUR). That’s not good.

Not to mention that Manjaro’s own repos can be broken at times:

That was favored by a stupid design bug: without running reflector, the moron tried three random mirrors, and when they failed to retrieve a package, it gave up. Funnily, the German mirror wasn’t broken at that time!

On the plus side, Manjaro makes switching the kernels a child’s play:

I would say that Manjaro seems a decent choice for those loving KDE. No, KDE neon is not that good: yes, it does have the latest stable KDE, but being based on Ubuntu LTS, everything else is rather old. To me, Manjaro’s default theme has the advantage of being very “compact” and elegant (for those who aren’t retards). Of course, Fedora too could be chosen: while not rolling, it also keeps updating to the latest stable KDE; unfortunately, Fedora also keeps updating to the latest kernel (which sometimes can be inconvenient), while Manjaro actually recommends you a LTS kernel (see the screenshot above).

Sadly enough, Manjaro too has succumbed to the idiocy of using the icons-only Task Manager instead of the traditional one, in which the windows have captions. What’s the use of such a long panel then?! I’ve noticed a similar trend in XFCE too recently. The only situation when this would make sense: a vertical panel, à la MX Linux.

§10. MATE 1.26 and Ubuntu MATE’s dormancy (BONUS: Xubuntu’s too!)

Yes, I said it before, and I believe it to be true: Ubuntu MATE should be the n°1 distro for MATE aficionados. Wimpy is there. Ubuntu MATE has put a tremendous amount of work in polishing the looks, and also to create the various layouts that can be changed via mate-tweak.

Yes, they’re also a bunch of idiots under the dictatorship of Wimpy’s, as their optimized gtk-theme-yaru-mate and icon-theme-yaru-mate are installed as snaps, not as packages. This in itself raises my blood pressure!

Here’s what’s worse though. MATE 1.26 was released on Aug. 3, 2021. One week later, I checked and this is what I saw:

Additionally, their forum has exactly ZERO mentions of what was in the works, of what’s going to be new in 1.26, etc. That community can host interesting discussions on the GTK3 regressions from a GTK2 perspective (such as the overlay scrollbars making it difficult to select the last line in the Synaptic Package Manager, or GtkTreeView odd/even row styling no longer working) and on GTK4 further regressions that might kill all GTK-based DEs, but beyond that… it’s like they were schizophrenics who are not on Ubuntu MATE’s forum to discuss MATE!

I learned about MATE 1.26 from EndeavourOS, on Aug. 9: Mate-Desktop 1.26 is available (released on Aug. 7 upstream). I don’t agree with Fred Bezies:

I switched back to Gnome when Gnome 3.38.x was announced. I was fed up with the slow development of Mate. Seeing Mate 1.26 nearly 18 months after Mate 1.24 makes me think the team is either too small or Mate code is too complex to evolve on some points.

Why should everything change all the time?!?

This being said, there’s an important bug fix in Atril 1.26.0 (ex-Evince):

One major improvement/bugfix is that it will no longer spawn one WebKitNetworkProcess each when viewing pdf files.

Quite worth the upgrade, I’d say. But no, unless you’re using that PPA, you’ll have to stick to the buggy Atril in Ubuntu MATE 21.04 and 20.04! Beware that Debian 11 doesn’t even have Atril 1.24.1, but only 1.24.0, and they might stick to it forever!

Oh, now the “Fresh MATE” PPA got popular: on Ask Ubuntu, Is it possible to install MATE 1.26 on Ubuntu MATE? has been updated on Aug. 30 to include a positive answer, and on OMG! Ubuntu!, How to Upgrade to MATE Desktop 1.26 on Ubuntu has been posted on Aug. 27 and updated on Sept. 17.

I’ve checked the daily live images of Ubuntu MATE 21.10 Impish, and I also checked the repos: MATE 1.26 (hence Atril 1.26) became available since Aug. 24. But only for Ubuntu 21.10, which has not been released yet!

All in all, with some delay and either using a PPA, or waiting for Ubunru 21.10, one can have MATE 1.26 in Ubuntu MATE, but the management of the project and of the communication is catastrophic IMHO.

Of course, it can be worse! The most anticlimactic flavor (or distro!) is Xubuntu: No forum, really? There is only the tag “xubuntu” on Ubuntu Forums, and the mailing lists xubuntu-users and xubuntu-devel.

Remember how they needed weeks to fix CVE-2021-32563? The fix for XFCE 4.16 is in Thunar 4.16.8, with a backport in Thunar 1.8.17 for XFCE 4.14. Go check the latest updates in Ubuntu/Xubuntu now, which is 5 months after CVE-2021-32563!

  • Xubuntu 21.04: Thunar 4.16.6, which is vulnerable! (<4.16.8)
  • Xubuntu 20.04 LTS: Thunar 1.8.14, which is vulnerable! (<1.8.17)

The fix only reached the upcoming Xubuntu 20.10, but the ideas is that Xubuntu doesn’t care about its users! Whoever loves XFCE should use something else instead. Almost anything else!

  • Linux Mint has had Thunar 4.16.8 since they bypassed Ubuntu’s 20.04 LTS policy and they upgraded to XFCE 4.16 on their own.
  • MX Linux has had Thunar 1.8.17 since they bypassed Debian 10’s laziness (Debian 10 remains vulnerable!) and updated their own package.
  • Fedora 34 had the fixed package pretty quick.
  • Arch, Manjaro, and everything rolling-release… you got the drill.

Either way, Xubuntu’s distro leader is not someone I could understand. Have this old(ish) Xubuntu 21.10 Dev Update: alongside a less ugly theme, it includes in “New Additions”… Clipman (xfce4-clipman-plugin), but not enabled by default! For fuck’s sake, I was using Clipman in 2007-2009 (versions 0.8-0.9), and now it’s… novelty to Xubuntu?!

By the by, Linux Lite 5.6, released on Sept. 1, is still vulnerable, because they blindly follow Ubuntu LTS.

Why on Earth would anyone use Xubuntu?

§11. Lubuntu, PCManFM-Qt (or no Qt) and a discovery

Let’s ignore what I’ve already said of LXDE and LXQt in §4. There’s more to it than it meets the eye.

To satisfy the eye first, Lubuntu has a much more visible activity than MATE and Xubuntu. There is Lubuntu Development (bugs, tasks, stuff), their quite active forum, and the “lubuntu” tag on Ubuntu Forums. Admittedly, 21.04 has the worst wallpapers of all so far, they’re not dealing well with multi-language support (regression vs LXDE), but they have two pluses for me:

Now, for something they seem not be aware of (would they care if they knew?).

Well, if you guessed I tried CVE-2021-32563 against PCManFM-Qt and PCManFM, you guessed right! They are vulnerable!

Funny thing how the maintainers of the major file managers DON’T try to see whether their software exhibits or not the vulnerabilities reported for any other major file manager! (Are they too young, too lazy, or too stupid?)

Here’s what that CVE said:

When called with a regular file as a command-line argument, it delegates to a different program (based on the file type) without user confirmation. This could be used to achieve code execution.

So I did what I did with Thunar: from a terminal, I invoked the file manager with the name of an image file as an argument.

  • Expected behavior: the directory that contains that file should be opened in the file manager; alternatively, user confirmation should be required before passing the fully qualified file name to a third party.
  • Actual behavior for both PCManFM 1.3.2, PCManFM-Qt 0.16.0: they opened the image with the default image viewer!

One might say that this CVE is bogus, and that this vulnerability isn’t that much of a vulnerability. Well, if those who deal with security concepts decided it’s a vulnerability, then it is one!

Now, the question is: why would I report this as a bug in pcmanfm and pcmanfm-qt? PCManFM is only used by the few lunatics who still stick to LXDE; and the developers of PCManFM-Qt couldn’t care less about their users, if you remember the “you want the keyboard shortcuts that were present in PCManFM, we’ll give you some toolbar buttons instead!” issue above.

It’s vulnerability time, and if the behavior that triggered CVE-2021-32563 needed an example, I’ve found a great one: yay (Yet Another Yaourt)!

You see, many people complain that package managing in most Linux distros requires sudo or su. Even to update the already installed packages, the user typically needs to enter their password and press a button in a GUI prompt. This doesn’t make much sense, especially when it comes to updates, does it?

Well, some Arch derivatives come with yay preinstalled. And this little guy doesn’t ask for any credentials to install, update or remove packages, and it defaults to “Yes” on its operations!

This is outrageous. Imagine a script that invokes yay without your knowing it would invoke it, the the same way a file manager could invoke another program without asking you first (the CVE above). You could end with packages that are installed or uninstalled without your knowledge, or even with a broken system!

yay is a vulnerability in itself.

I now feel even less willing to use anything Arch-related.

I was reminded of yay's behavior while trying the latest EndeavourOS (endeavouros-2021.08.27-x86_64.iso). I was also reminded of one of the stupid design decisions in EndeavourOS: The reason for not having a [preinstalled] GUI package manager is simple: Arch does not provide it. You morons, Arch doesn’t provide a GUI distro installer either (nor any other decent, real installer), so why are you providing Calamares? Invoking the “because Arch doesn’t do it” argument is totally grotesque.

Shoo, anything Arch-based, shoo!

§12. From noatime to ctime, atime, mtime: what you didn’t know about Linux

One of the first thing people learn to check in /etc/fstab to increase the HDD speed in Linux, or to optimize the SSD usage, is to make sure the filesystems are mounted with noatime. Preserving the timestamp of the last access to every file is one of the dumbest thing ever invented in Unixland!

This has a long history of controversy. Because it got worse: instead of giving up the “last accessed” timestamp altogether and use noatime across all filesystems, some retard came with the idea of using relatime: the same thing as atime, only it’s written on the drive much later, not right away for each file. In Ubuntu, relatime became the default since Ubuntu 8.04; I’m not sure when it entered Fedora, I just know it’s there. You can check by inserting a USB flash drive: it will be mounted with relatime instead of noatime, despite the fact that nobody, absolutely nobody ever cares the access time of any of the files on a USB drive!

Jonathan Corbet’s Once upon atime (August 8, 2007) has some interesting info: Ingo Molnár, once a famous kernel developer (now keeping a low profile) wrote,

Atime updates are a huge everyday deal, from laptops to servers.
Everywhere on the planet. Give me a Linux desktop anywhere and i can
tell you whether it has atimes on or off, just by clicking around and
using apps (without looking at the mount options). That's how i notice
it that i forgot to turn off atime on any newly installed system - the
system has weird desktop lags and unnecessary disk trashing.

Then, replying to himself:

i cannot over-emphasise how much of a deal it is in practice. Atime
updates are by far the biggest IO performance deficiency that Linux has
today. Getting rid of atime updates would give us more everyday Linux
performance than all the pagecache speedups of the past 10 years,
combined.

it's also perhaps the most stupid Unix design idea of all times. Unix is
really nice and well done, but think about this a bit:

' For every file that is read from the disk, lets do a … write to
the disk! And, for every file that is already cached and which we
read from the cache … do a write to the disk!
'

tell that concept to any rookie programmer who knows nothing about
kernels and the answer will be: 'huh, what? That's gross!'. And Linux
does this unconditionally for everything, and no, it's not only done on
some high-security servers that need all sorts of auditing enabled that
logs every file read - no, it's done by 99% of the Linux desktops and
servers. For the sake of some lazy mailers that could now be using
inotify, and for the sake of … nothing much, really - forensics
software perhaps.

When a Linux guru says it, it must be true. This time, don’t blame me for using big words, because indeed, any rookie could see that the emperor is naked.

Basically, nobody uses in the 21st century software as stupid as to require atime. From Criticism of atime, on Wikipedia:

Current versions of Linux, macOS, Solaris, FreeBSD, and NetBSD support a noatime mount option in /etc/fstab, which causes the atime field never to be updated. Turning off atime updating breaks POSIX compliance, and some applications, such as mbox-driven “new mail” notifications, and some file usage watching utilities, notably tmpwatch.

From Arch’s wiki page for fstab:

relatime updates the access time only if the previous access time was earlier than the current modify or change time. In addition, since Linux 2.6.30, the access time is always updated if the previous access time was more than 24 hours old. This option is used when the defaults option, atime option (which means to use the kernel default, which is relatime.

When using Mutt or other applications that need to know if a file has been read since the last time it was modified, the noatime option should not be used; using the relatime option is acceptable and still provides a performance improvement.

Well, the aforementioned “retards” who “fixed” atime by replacing it with relatime were none other than… Linus Torvalds and the same Ingo Molnar!

To fix that problem, Linus suggested a tweak to how relatime works: update it if the current value is more than a certain time in the past – one day, for example. Ingo responded with a patch implementing that behavior and adding a couple of new boot options: relatime_interval, which specifies the update interval in seconds, and default_relatime, which turns on the relatime option in all filesystems by default.

Bugger. If a piece of software requires the time of the last access to a file, then it’s poorly designed. Screw POSIX. The modification time (mtime) is what should matter! Even back in 2007,

The only program that I run that benefits from atime is Debian’s “popcon“, which records which packages are installed and which of those has been used recently. This would work well with the “update atime when > 1 day” approach suggested by Linus.

Also, Microsoft seems to have looked at this issue in the past. From MSDN:

Not all file systems can record creation and last access times, and not all file systems record them in the same manner. For example, the resolution of create time on FAT is 10 milliseconds, while write time has a resolution of 2 seconds and access time has a resolution of 1 day, so it is really the access date. The NTFS file system delays updates to the last access time for a file by up to 1 hour after the last access.

Now you know why Windows is such a hog. This, and file indexing (with contents indexing and nothing less). Nonetheless, NTFS tries to implement a sort of relatime, while the described FAT behavior started with NT; under MS-DOS and up to Win98 inclusively, FAT didn’t store the access time. (Those were great times.)

This still doesn’t explain why EVERYTHING needs to be mounted with relatime, including the USB flash drives!

There is something even more ridiculous in everything UNIX-like. Let’s compare two things. First, what timestamps was able to show dir /t in Win NT 3.1 (1993):

  • a = last access
  • c = created
  • w = last written

How about UNIX, Linux and the gang? The times tracked for each file are these:

  • access time – atime
  • change time – ctime
  • modify time – mtime

Have you noticed the difference? There’s no file creation timestamp kept, at least until recently!

(Note for those who might believe that, semantically, “changed” and “modified” have the same meaning: not here! The changed timestamps aren’t referring to changes made to the contents of a file, but to the time at which the metadata related to the file was changed, which include e.g. permission changes.)

For anyone who’s not retarded, the creation time and the last change aka modification time are sufficient for all purposes:

  • If the modification time is older than the creation time, this means the file has been copied from a different filesystem, without modifications. Examples: files installed e.g. from an original kit (the common case in Windows), files copied to a different device.
  • If the modification time is newer than the creation time, than the file has been modified after it was created. This is how you track the documents you’re editing, and how backup software should decide what and how to backup.

There’s absolutely no need for anything else! OK, we don’t need the access time, but we do need the creation time, which is what is missing in Linux! (Retards in Unixland? Retards for sure.)

(There are retarded Microsoft MVPs unable to understand how the modification date can be earlier than the creation date. Such idiots never noticed how on a freshly installed Windows, all the system files have modification dates in the past. Now, as to what is the meaning of the last date column in Windows explorer, that’s a different issue: Rationale behind Date created, Date modified & Date on Windows 10.)

Jonathan Corbet on File creation times, back in 2010:

So where do users find the creation time? They don’t: Linux systems do not store that time and provide no interface for applications to access it.

The good news? The support for the creation time has been added to the Linux kernel a couple of years ago, and it’s currently supported by:

  • ext4: i_crtime: File creation time, in seconds since the epoch.
  • btrfs: “birth time” (btime/crtime).

There was some delay to get it really working, as it went in stages: virtual-file-system (kernel support complete) in Linux 4.11 in 2017; glibc in version 2.28 in 2018; GNU coreutils 8.31 in March 2019. But most kernels were still compiled without it, as there was no major software to really use it… until recently.

The next step would be to have support for crtime in the file managers, right? The following file managers started supporting the creation time:

👉 XFCE is the big lazy one here. Still, the last modification time is what most people are looking for in a file manager, and nothing else!

👉 PCManFM-Qt 0.17 when the creation time is not available:

👉 Nautilus 40 (what’s the difference between “Modified” and “Modified—Time” as long as all the columns I see only show the time, not the full date?):

👉 Despite being bloated with features, Dolphin defaults to only showing the modification time:

👉 Nemo too has the idiocies of GNOME’s Files: there’s no difference between “Date Modified” and “Modified – Time” and it would probably have been the case with “Date Created” vs “Created – Time” too, were it not for the absence of such data in the inodes:

Oh, these file managers…

§13. The File Managers in Linux: One More Stupid Design Decision

I can show you now two things:

  • How the GUI file managers in Linux are dumber than copy and xcopy in MS-DOS (or in FreeDOS).
  • How most Linux users and Linux developers couldn’t care less, or maybe they don’t even understand basic usability concepts.

Let’s consider this common scenario: when you cancel a copy or move operation, say a huge file, what do you expect to find in the destination folder?

a. Nothing, as the partially copied file should have been deleted.

b. The partially copied file, which is misleading, useless, and dangerous, because the user would assume the file has been copied, when it’s actually a broken file, being incomplete (truncated).

Well, in Windows (since forever), the answer is a, which is the only one that makes sense. But in Dolphin, Thunar, Caja, Nemo, Nautilus/Files, PCManFM, and PCManFM-Qt, the answer is b! Incomplete files are left in the destination folder, with no indication that they’re incomplete! And this is about gracefully canceling a copy/move operation, not a brutal abort or CTRL+C!

For fuck’s sake, are they all completely dumb in the FOSS world?!

Now, try to guess how many people complained about this huge incongruity?

👉 For Nautilus, on 2012-10-27: Bug #1072135: Canceled copy/move operations should not left incomplete files:

This is not a bug but a possible usability improvement.

Test case:

– Open Nautilus

– Open a second folder on a tab

– Copy/move a big file form one tab to another

– Cancel the transfer using the X button.

The unfinished file remains on the destination folder, now, since this file is incomplete (possibly unusable) and the user directly stated that he/she doesn’t want to transfer this file, I think that it is safer to delete the destination copy altogether. Otherwise could be indexed and cause some confusion.

Not a bug, huh? Don’t worry, nothing happened: the developers simply didn’t understand why this is an issue!

👉 Linux Mint user, on March 03, 2015: Copy and paste, incomplete files remain-how to auto delete?

If I copy a file (e.g. video from cd or dvd to a new folder) and cancel, or if it shows as corrupt halfway through copying and cannot complete, the incomplete file remains in the new folder.

Is there a way to set Mint so that incomplete copies are automatically deleted or at least moved to the recycle bin, instead of having to do delete manually?

I am using Cinnamon and XFCE, and I think this applies to both.

Yes, it does. And no, they couldn’t care less!

☝️ Finally, why did I say that even copy and xcopy in MS-DOS were smarter than that? Because they acted this way:

  • copy was copying one file at a time, after having updated the FAT Directory Entry before the file was created. If the file wasn’t fully copied, it was deleted from the FAT Directory Entry. Obviously, some data was left on the disk, but it was “invisible” (as you know, even when you delete a file, the data stills remains on the disk, only the FAT Directory Entry is updated, and even then, the only update is to change the first letter of the file name to 0xe5).
  • xcopy was copying several files at a time, by reading as many files as possible (to the extent of the available RAM for it, probably not more than 256 KB or 320 KB), and it only updated the FAT Directory Entry once for all the files from the RAM. If one or more of the files weren’t fully copied, the FAT Directory Entry was one more time updated accordingly to discard such files, but again, in a single operation for the entire set of files. It was an optimization over copy, as the FDD or HDD head only had to go to the FAT Directory Entry once instead of doing it after each and every file, no matter how small (believe me, it made a huge difference in the times of the floppy disks!).
  • They were written in ASM at the time, but I checked the source code for xcopy in FreeDOS, in which gracefully canceling a file copy included a fclose() followed by unlink(). All in all, it wasn’t there anymore, as expected!
  • If fclose() wasn’t called because of an abrupt CTRL+C, not only the file was only partially copied, but chkdsk was needed to be invoked to fix the FAT Directory Entry inconsistencies.

To end with this crap, what are the implications of this stupid behavior of all the GUI file managers in Linux? To me, the major impact is for my manual backups (or backups to the backups): in Linux, it’s not safe enough to have an option, like it was in Total Commanded, “Overwrite all older”; now something like “Older or different in size” must be found… or maybe a specialized backup software is mandatory!

So all those “brilliant” file managers want to show me the atime and the crtime/btime (when mtime is all I need), yet they can’t even tell whether a file is fully copied or only a useless piece of crap? Fuck the fucking police!

§14. Random tidbits about several distros

On a less heated note, a few other things I noticed lately.

👆 mousepad 0.5.6 has been released end-July, with nice improvements and bug fixes, but don’t expect to find it in the upcoming Xubuntu 21.10. As I said before, better look elsewhere (Arch, Fedora 34, etc.). By the way, Linux Mint uses their xed instead, consistently across the three desktops.

👆 The new Linux Mint website is up and running. It looks like shit or, to be more accurate, like a generic marketing site based on a commercial WordPress theme, if not like a boilerplate website devoid of real content. Or maybe as a Chinese website free of spelling and grammar errors. It’s “modern” and a total crap. They might have taken inspiration from another abomination, Manjaro’s website. The only good thing is that they use Read the Docs for the documentation, which has an advantage over GitBook: it’s open-source.

👉 Sadly enough, the Official file server of the University of Stuttgart doesn’t mirror Fedora.

👉 Have you ever noticed your wireless mouse apparently having 55% of the battery all the time in Linux? I did, long time ago. Apparently, that value shouldn’t even be used (only Bluetooth devices really report their power status). Frugally discussed on Ubuntu MATE, it’s an old issue with upower:

The 55% is normal. Newer versions of the upower utility will show that you shouldn’t use it. From the documentation:

The percentage will be an approximation if the battery level is set to something other than None. The percentage is kept for compatibility reasons.

👉 “Progress” means “regress” more often than not. Fix for “There is no application installed for … files. Do you want to search for an application to open this file?” on modern Ubuntu MATE:

Previous Ubuntu MATE versions like 18.04 LTS (and older) allow user to automatically find and install software to allow manipulation with unknown file-types.

But in modern Ubuntu 20.04 LTS (and newer) the above mechanism is broken.

👉 There is no way to have Hypnotix in Fedora, despite having asked for it:

@clefebvre the current layout Hypnotix uses will make it quite hard to create a proper package. Like, hardcoding /usr/lib/hypnotix/hypnotix.py is probably a no-go, Python stuff goes to /usr/lib/python3.x/site-packages (I think you’ll have the same issues with any other distribution tbh). For the same reason it cannot be used in a virtual environment.

Also,

I started looking into a potential package, and immediately hit the problem that python-imdb was retired from Fedora 🙁 https://bugzilla.redhat.com/show_bug.cgi?id=1627219

👉 The revived yumex-dnf still has a bug from 2016: yumex-dnf is locked. Indeed, when this happens, the fix is to run:

sudo yumex-dnf --exit

👉 If you want to read some extremely naive articles in Fedora Magazine, try those by Arman Arisman. I can only assume it was born after the last rain, because there is so much software he doesn’t know about! Oh, he’s an architect, and new to Fedora. Uh, OK.

👉 Have you ever thought of the practicalities of using external drives in Linux for transfers between different machines, or for unencrypted manual backups of regular files, not system backups? This might be not as straightforward as in Windows:

👉 That leads us to the never ending question: is Linux ready for the desktop? Don’t try to find the answer here: Major Linux Problems on the Desktop, 2021 edition.

👉 Among the gazillions of similar YouTube channels, InfinitelyGalactic. Why shouldn’t this guy be trusted, even as he seems persuasive? (Ransom examples, but he seems to praise almost everything: I spent 30 days with Plasma 5.21 – Return of the King? and How Fedora WON 2020 for Desktop Linux – 4 Reasons.) Because this guy is a religious preacher:

  • He’s Blaine @ InfinitelyGalactic in his new identity:
    writer | YouTuber | Linux + tech enthusiast | teacher | disciple | productivist | (productivity+activist) 😉
    Australia – Joined September 2011
  • But he also is (was?) Blaine Packer:
    disciple of Christ | writer | teacher | music addict | father | husband | film critic | YouTuber | Love God, Love People, Do Stuff!
    Gympie, Queensland – mailfromblaine.wordpress.com – Joined April 2014

👉 To complement my older Watching “old guys” playing with Linux on YouTube, I want to insist that Jack Keifer is utterly ridiculous in the way he reviews everything and likes everything he reviews (e.g. Arch Linux; XFCE 4.16; RebornOS Cinnamon; ArcoLinux; openSUSE XFCE; KDE Neon; Ubuntu 21.04; Fedora 34 KDE).

To come with somebody “new” though, I don’t think I mentioned Penguin’s eggs! No, I don’t like the idea, at least not for me. Several other projects are using it, such as the revived Ufficio Zero Linux (by revived I mean this and this). This concept is the work of Piero Proietti, now retired. Or maybe you’d be interested in his LinkedIn profile.

Nah, not for me. How are some people able to be enthusiastic about such things?!

§15. The Road Forward

In Roger Murtaugh / Danny Glover lingo, “I’m too old for this shit.” Not to mention that for the next 4+ weeks, I’d rather stop digging into such pointless things, for lack of time.

So I suppose I’ll go for Fedora, with XFCE. In spite of everything.

👉 When I first installed Fedora 34 XFCE after years of long time no see, I was satisfied. Even printing and scanning using my Epson EcoTank ET-M2170 could be sorted out smoothly. On this laptop, there’s no risk to encounter both Nvidia and RTL8821CE 🙂

👉 I should also install on two fast USB flash drives some other distros, both as backup and as a means to evaluate them properly, just in case. I just don’t know which those distros might be (or will they?).

I cannot reach such a state, but at least I can put an image of it. See ya.