Arch w/ KDE gamer here. I have generally had a good experience with it. I think everything you said is generally accurate. In terms of customization, lack of bloat, and a good wiki, Arch is generally considered to be all of those things. A rolling distro like Arch I believe will also be getting the latest proton updates, which may help with sooner game compatibility/optimization updates on more recent releases.

I say go for it.

Yes, but my larger point is that you are doing the same thing, but in the negative. You are taking your specific problems and then putting forward the conclusion that they are the reasons why "regular" Linux users should not use Linux, as though these were universal problems. I am saying that I do not have those issues and that they are far from universal.

Yes, the modular nature of Linux is both a blessing and a curse. There is legitimate debate to be had on that. But that is not how your post frames the issue.

As stated above, not all of these things are even Linux problems. I would say that if iOS refuses to play nice with Linux but every other ecosystem works fine, the blame lies with Apple, not with Linux. It is not Linux's job to fix the interoperability problems of other ecosystems. The GNOME problems are related to a specific subset of Linux users, and even before today I would have said that I would not recommend GNOME to new users because of how nonstandard it can be.

I am looking through these issues and I cannot say that I can relate on almost any of these. Sorry to hear you have been having so many issues!

I do plenty of gaming and cannot think of a time where I have had GPU driver issues (despite the fact that I have Nvidia graphics on 3 out of 4 of my systems, which is supposedly more problematic).

My bluetooth works fine, and it has been literally years since an update broke something, bluetooth or otherwise (which I cannot say the same for Windows on my work computer).

I use KDE connect, SFTP, and SMB servers and I have never had any issues transferring files between Windows, Android, and Linux. What do you mean about that? (seeing other replies, it sounds like you are using iOS. That sounds like that may be an Apple problem and not a Linux problem, because Apple tend to be terrible about playing nice with other ecosystems)

The scaling is the one point I can sort of relate on. I think there is still some work to be done regarding DPI and scaling on Linux, but it's not enough of an issue to make me want to switch operating systems.

As for GNOME issues and window decorations, that sounds like a GNOME problem. GNOME does things very differently to all of the other DEs and forces programs to manually define their own window decorations rather than allowing standard default icons like other DEs, so my understanding is that GNOME in particular tends to be a source of constant headaches for Linux developers.

And I'm not some sysadmin or CS major. If I have a problem, I do a web search. If I can't find it there, I make a forum thread. I don't post a rant saying that Linux is a bad OS, lol.

I am only a few pages in, but speaking as a Linux user in the 2020s, I am skeptical of the claim that Linux in 1999 would "never, ever break down."

Two old HP thin client PCs configured as 4TB SFTP file servers using vsftpd on Debian. Each one uses software RAID 1 with both an NVMe and SATA SSD internally, and are in two separate locations with a cron job which syncs one to the other every 24 hours.

People who actually know what they are doing will probably find this silly, but I had fun and learned a lot setting it up.

I think you would need to provide more detail to know what you have. Does it have a model number on it anywhere?

The Arch installation tutorial I followed originally advised using LVM to have separate root and user logical volumes. However, after some time my root volume started getting full, so I figured I would take 10GB off of my home volume and add it to the root one. Simple, right?

It turns out that lvreduce --size 10G volgroup0/lv_home doesn't reduce the size by 10GB, it sets the absolute size to 10GB, and since I had way more than 10GB in that volume, it corrupted my entire system.

There was a warning message, but it seems my past years of Windows use still have me trained to reflexively ignore dire warnings, and so I did it anyway.

Since then I have learned enough to know that I really don't do anything with LVM, nor do I see much benefit to separate root/home partitions for desktop Linux use, so I reinstalled my system without LVM the next time around. This is, to date, the first and only time I have irreparably broken my Linux install.

Arch gamer here. I can confirm that it works well.

Blah blah blah blah blah...

tl;dr the author never actually gets to the point stated in the title about what the "problem" is with the direction of Linux and/or how knowing the history of UNIX would allegedly solve this. The author mainly goes off on a tangent listing out every UNIX and POSIX system in their history of UNIX.

If I understand correctly, the author sort of backs into the argument that, because certain Chinese distros like Huawei EulerOS and Inspur K/UX were UNIX-certified by Open Group, Linux therefore is a UNIX and not merely UNIX-like. The author seems to be indirectly implying that all of Linux therefore needs to be made fully UNIX-compatible at a native level and not just via translation layers.

Towards the end, the author points out that Wayland doesn't comply with UNIX principles because the graphics stack does not follow the "everything is a file" principle, despite previously admitting that basically no graphics stack, like X11 or MacOS's graphics stack, has ever done this.

Help me out if I am missing something, but all of this fails to articulate why any of this is a "problem" which will lead to some kind of dead-end for Linux or why making all parts of Linux UNIX-compatible would be helpful or preferable. The author seems to assume out of hand that making systems UNIX-compatible is an end unto itself.

The Arch installation tutorial I followed originally advised using LVM to have separate root and user logical volumes. However, after some time my root volume started getting full, so I figured I would take 10GB off of my home volume and add it to the root one. Simple, right?

It turns out that lvreduce --size 10G volgroup0/lv_home doesn't reduce the size by 10GB, it sets the absolute size to 10GB, and since I had way more than 10GB in that volume, it corrupted my entire system.

There was a warning message, but it seems my past years of Windows use still have me trained to reflexively ignore dire warnings, and so I did it anyway.

Since then I have learned enough to know that I really don't do anything with LVM, nor do I see much benefit to separate root/home partitions for desktop Linux use, so I reinstalled my system without LVM the next time around. This is, to date, the first and only time I have irreparably broken my Linux install.

Not my preference personally, but cool.

Electrical engineer here who also does hobby projects. I'm with you. I think some of the reason may be that modern GaN-type green or blue LEDs are absurdly efficient, so only a couple mA of drive current is enough to make them insanely bright.

When I build LEDs into my projects, for a simple indicator light, I might run them at maybe only a tenth of a milliamp and still get ample brightness to tell whether it is on or not in a lit room. Giving them the full rated 10 or 20mA would be blindingly bright. I also usually design most things with a hard on/off switch so they can be turned all the way off when not in use.

Of things I own normally I also have two power strips with absurdly bright LEDs to indicate the surge protection. It lights up my whole living room with the lights off. If I had to have something like that in my bedroom, I would probably open it up and disconnect the LEDs in some way, or maybe modify the resistor values to run at the lowest current I could get away with.

I feel like designers have lost sight of the fact that these lights are meant to be indicators only-- i.e. a subtle indication of the status of something and not trying to light a room-- and yet they default to driving them at full blast as if they were the super dim older-gen LEDs from 20+ years ago.