Continuing from above: ---- > No plug-and-play support for a lot of input devices like joysticks and steering wheels. Many require editing of cryptic configur

Continuing from above: ---- > No plug-and-play support for a lot of input devices like joysticks and steering wheels. Many require editing of cryptic configuration files. My Logitech F310 and my Saitek X52 both work out-of-the-box without any such "editing of cryptic configuration files". At most, I might need to set bindings in the game itself. This applies even with Wine/Proton (I'm able to play Ace Combat 7 with a controller - like God intended - with exactly zero configuration on my part). > Many anti-cheat protections fail to work under Linux. Tell that to Valve Anti-Cheat. > There's no concept of drivers in Linux aside from proprietary drivers for NVIDIA/AMD GPUs which are separate packages: almost all drivers are already either in the kernel or various complementary packages (like foomatic/sane/etc). Good. Like, how is this a bad thing? It's the very reason (well, one of many) why I prefer Linux over Windows for my desktops and laptops. > There's no guarantee whatsoever that your system will (re)boot successfully after GRUB (bootloader) or kernel updates That's much less of an issue with UEFI (where you're not mucking with boot sectors and such). And kernel updates haven't been an issue for me for years. > Samba is not native How is it not native? Just because it's "reverse-engineered" doesn't mean it doesn't ship with most/all modern distros and can be used for filesharing. > Steep learning curve (even today you oftentimes need to use a CLI to complete some trivial or non-trivial tasks, e.g. when installing third [party software]). The link is to a question that specifically asks how to do it through the command-line. The user didn't have to do it that way (Google has provided .deb and .rpm packages on chrome.google.com for as long as I can remember, and nearly all distros using either package format are able to graphically install such packages with a double-click). > Most well written GUI applications for Windows 95 will work in Windows 10 (24 years of binary level compatibility) And most "well written" GUI applications for Linux 1.2 (which is when Linux switched from a.out to ELF) will work in Linux 5.4.31 (24 years of binary level compatibility). The problem is that applications are rarely "well written"; there are plenty of poorly-written Windows applications that don't run on more modern versions, and Linux is no different. If your (statically linked) Linux 1.2 compiled application doesn't run on the latest-and-greatest Linux, then that's a bug of the "Linus will verbally abuse someone on the LKML" variety. > No standard way of software deployment (pushing software via SSH is indeed an option, but it's in no way standard, easy to use or obvious - you can use a sledgehammer to crack nuts the same way). So? There are plenty of options here, ranging from "pushing software via SSH" to widely-used and industry-standard tools like Puppet and Chef. > No CIFS/AD level replacement/ equivalent (SAMBA doesn't count for many reasons) Why doesn't SAMBA count? I've literally used SAMBA 4 as an AD domain controller in production (with Windows, macOS, and Linux domain members). Works fine. There's also FreeIPA, but I don't have as much experience with it (besides trying it out when it was first announced, during which point it was pretty buggy, though Fedora was probably just as much to blame). > No filesystems at all to support per-file encryption gpg --encrypt --sign --armor -r my@email.address wow-so-hard.txt openssl enc -in wow-so-hard.txt -out wow-so-hard.txt.enc -e -aes256 -pbkdf2 -pass 'pass:WOW SO HARD' Like yeah, I guess it's cool if the FS itself supports encryption, but this seems like it's best left to the application (and obviously end-users shouldn't be expected to run these commands themselves, but applications can certainly do so or - better yet - use the actual underlying libraries).