You seem to like the lines-of-code metric. There are many lines of GNU code in a typical Linux distribution. You seem to suggest that (more LOC) == (more important). However, I submit to you that raw LOC numbers do not directly correlate with importance. I would suggest that clock cycles spent on code is a better metric. For example, if my system spends 90% of its time executing XFree86 code, XFree86 is probably the single most important collection of code on my system. Even if I loaded ten times as many lines of useless bloatware on my system and I never excuted that bloatware, it certainly isn’t more important code than XFree86. Obviously, this metric isn’t perfect either, but LOC really, really sucks. Please refrain from using it ever again in supporting any argument.
I wanted to use fio to benchmark my root drive. I had seen a tutorial saying that the file= parameter should point to the device file, so I pointed it at /dev/sda. As you might expect, the write test didn’t go so well.
Before installing Arch on a USB flash drive, I disabled ext4 journaling in order to reduce disk reads and writes, being fully aware of the implications (file corruption after unexpected power loss). I was confident that I would never have to pull the plug or the drive without issuing a normal shutdown first. Unfortunately, there was one possibility I hadn’t considered: sometimes, there’s that one service preventing your PC from turning off, and at that stage there’s no way to kill it (besides waiting for systemd to time out, but I was impatient).
So I pulled the plug. The system booted fine, but was missing some binaries. Unfortunately, I couldn’t use pacman to restore them because some of the files it relied on were also destroyed.
This was not the last time I went through this. Luckily I’ve learned my lesson by now
The second issue could be a software issue and the first could be a driver issue, so I’d start by reinstalling Windows and installing the latest driver for your specific GPU