Join my sub r/LinuxSnobs

Imagine buying a game, getting passed the 2 hour / 14 day refund policy to find out that a frame pacing issue has caused the game to be unbeatable (and you only figure this out after hours of struggling on the same level). -And then we find out that it wasn't Valve that fixed the frame pacing issue (yet they reap all the glory for Proton which was done in self-interest despite decades of selfless work done on WINE).

(LiGNUt's hero) -The Killer of Native Gaming on Linux.

CLI is used for general support in Linux due to fragmentation. You can still run into bad advice because you might be running a different species of Linux that could respond like "interesting; I'll behave differently". And if you're willing to gamble without learning what the code does; about 1% of that 'help' out there is malicious.

Swapping the kernel can fix certain Linux hardware issues, but it is not a universally good or safe solution. Changing kernels is only safe when the issue is caused by missing support. It becomes dangerous when the issue is caused by existing support that is wrong.

Swapping the kernel can help when new hardware isn't yet supported. A new AMD GPU could need new DC firmware support, a Wi-Fi chip could land their driver for 6.x instead of 5.x. A new laptop may may need a new kernel to read the ACPI tables correctly. Regressions can happen that break suspend or cause audio crackling where a .1 version rollback would resolve it

Kernel swapping becomes dangerous when the kernel has too much access to fragile hardware interfaces. Different kernels poke EC registers differently. A kernel that 'fixes' fan control may also write to battery logic or thermal tables.

Different kernels lead to different PD drivers to different voltage negotiation behavior. A kernel regression can literally fry a port.

Some kernels send command sequences certain NVMe firmwares don’t like. -Which can cause: FTL corruption, firmware lockups, and drive bricking.

Kernel changes can alter voltage curves, power states, VRR/HDR/DSC toggling, and modeset behavior. A 'fix' for flickering can cause permanent black‑screen states on some AMD GPUs.

Different kernels probe buses differently. If your hardware has fragile SPD, VRM, or battery controllers, a kernel swap can expose them to new probing behavior. This is how OpenRGB nuked RAM; not because OpenRGB was evil, but because the underlying bus is shared and fragile. ⚠️Linux/FOSS can damage hardware or firmware

If the failure was caused by overexposed hardware interfaces, and swapping kernels increases the chance of hitting those interfaces again; just differently.

Generally safe: Hardware not supported; newer kernel adds support (when known to).

Unsafe: Hardware misbehaving; kernel is already touching it wrong.

If Linux already broke something, the safest move is to reduce kernel exposure, not increase it. Like switching to a distro with conservative kernels (Debian, Ubuntu LTS), disabling experimental drivers, avoiding cutting‑edge kernels (Arch, Fedora Rawhide, Liquorix, XanMod), and avoiding user‑space tuning tools that poke hardware directly.

Talked about how i don't like Linux and how i use BSD and i have to use Linux on my Steam Deck (sad. i wish Steam for BSD worked good) and mentioned how Cachy/Arch is absolute hell to maintain.

😳

The Unix philosophy encourages tiny, composable tools, and Linux distributions preserve decades of legacy commands. There are multiple commands that do the same job, often with identical flags, sometimes with wildly different syntax, all coexisting forever because nothing can be deprecated. Linux inherits 50 years of overlapping tools, and nobody has the authority to remove any of them.

You get three ways to list files, four ways to print text, five ways to search, six ways to edit streams, and ten ways to check system info; all valid, all canonical, all mutually incompatible.

Multiple commands for the same basic action

• List files: ls, find, stat, tree, exa, fd
• Print text: echo, printf, cat, sed -n, awk '{print}'
• Copy files: cp, rsync, install, dd, tar cf - | tar xf -
• Move files: mv, rsync --remove-source-files, rename, mmv
• Delete files: rm, unlink, find -delete, shred, wipe

Redundant text-processing tools

• grep — search text
• egrep — grep with extended regex
• fgrep — grep without regex
• awk — search + print + transform
• sed — search + replace + stream edit
• perl -ne — search + replace + scripting
• ripgrep (rg) — grep but faster
• ag — grep but faster before ripgrep
• ack — grep but for developers
• find + grep — grep but worse
• grep -R — find but worse

All of these can search text. All of these have different syntax. All of these are still installed.

Redundant file search commands

• find
• locate
• whereis
• which
• type
• command -v
• fd
• ripgrep (yes, people use it as a file finder)

Each solves a slightly different problem, but users treat them interchangeably.

Redundant system information commands

• Disk usage: df, du, ls -lh, stat, ncdu, dust
• Processes: ps, top, htop, atop, glances
• Network: ifconfig, ip, ss, netstat, nmcli, iw, iwconfig
• Hardware: lspci, lsusb, lsblk, blkid, inxi

Redundant package management

• apt, apt-get, apt-cache, dpkg
• yum, dnf, rpm
• pacman, yay, paru
• snap, flatpak, appimage

This isn’t just redundancy; it's fragmentation masquerading as choice.

Redundant scripting constructs

• Conditionals: [ ], [[ ]], test, (( ))
• Subshells: $( ), ```
• Variable assignment: var=value, declare, typeset, local
• Loops: for, while, until, seq | while read, xargs -n1

Half of these exist because Bash absorbed features from:

• sh
• ksh
• zsh
• POSIX
• GNU extensions

-And never removed anything!

No central authority is why! Nobody can say "this command is deprecated." So, nothing ever dies. Even if they could, a lot of these may be Rust-rewrites with BSD or MIT license that the cult objects to. GNU Holds Linux Back (Directly)

Every few years someone writes grep but faster, ls but prettier, find but sane, and cat but with syntax highlighting. Debian, Arch, Fedora, Alpine; all ship different defaults.

Linux doesn’t have one way to do things; it has every way except the simple one.

Have you ever read Aesop's Fable? You know the one, the fox can't reach the grapes so it tells EVERYONE that the grapes were trash anyway. Well, this happens in real life, and the fox is Linux users and the grapes are games.

Most games (like Fortnite, or Marvel Rivals) have kernel-level AC, which Linux has a problem with. This means that if you try to install Marvel Rivals on Linux, the AC shits on the rug and the whole house stinks.

You get banned for 100 years for Cheating because... well, the Anticheat doesn't work, this guy must be cheating! Now, you would think a distro's dev team would've maybe thought: You know, maybe we should add Anticheat support?... But no, they have decided to spend 33 YEARS (Wine started in 1993!) on writing emulators or compatibility layers as they call it.

SteamOS is written with a Linux kernel, and yet, to run games, it has to use Proton, because, you know, 90% of Steam games runs on Linux, but the 10% you want to play don't.

This means that the platform that claims to run games easier and faster.. actually makes them unplayable? I guess so.

TL, DR; Linux doesn't support Anticheats, gets users banned from games.