When it comes to anti-cheat on Linux, it's basically an elephant in the room that nobody wants to address.
Anti-cheat on Linux would need root access to have any effectiveness. Alternatively, you'd need to be running a custom kernel with anti-cheat built into it.
This is the part of the conversation where someone says anti-cheat needs to be server-side, but that's an incredibly naive and poorly thought out idea. You can't prevent aim-bots server-side. You can't even detect aim-bots server-side. At best, you could come up with heuristics to determine if someone's possibly cheating, but you'd probably have a very hard time distinguishing between a cheater and a highly skilled player.
Something I think the anti-anti-cheat people fail to recognize is that cheaters don't care about their cheats requiring root/admin, which makes it trivial to evade anti-cheat that only runs with user-level permissions.
When it comes to cheating in games, there are two options:
1. Anti-cheat runs as admin/root/rootkit/SYSTEM/etc.
2. The games you play have tons of cheaters.
You can't have it both ways: No cheaters and anti-cheat runs with user-level permissions.
At the level of privilege you're granting to play a video game, you'd need to have a dedicated gaming PC that is isolated from the rest of your home network, lest that another crowdstrike level issue takes place from a bad update to the ring 0 code these systems are running
Edit: I specifically use a gaming-only PC. The hardware is used for nothing else. Hence, discussions of rootkits don't really bother me personally much and on balance I'd really rather see fewer cheaters in my games. I think it would be the same with any of these machines - anything Steam-branded is likely to be a 99% gaming machine and their users will only care that their games work, not about the mechanisms of the anti-cheat software.
There's also been numerous userspace ACs that work well and also run in userspace (EAC, Battleye, etc.) that have been enabled for Linux/Proton users (including by EA with Apex Legends at one point). A lot of the support for Linux mostly comes down to the developer/publishers not wanting to and not because of technical reasons.
Having access to multiple computers/devices as a single user became cheap and more common. If it was still the 2000s (or maybe early 2010s) and somebody only used a single PC for most of their tasks that'd make sense, but that's just not the reality most people live anymore
prolific self-published author of free things on the internet sometimes also sold as books
> software engineer
along with many others who wrote great things in 2005! but what lately? the setup script called omarachy?
> entrepreneur
again, we're two decades from anything I'd call entrepreneurial
babies have born and can vote since the last major wave DHH made, but he's great at soundbites and attention cycles
Also some gems like: https://github.com/basecamp/omarchy/commit/af72a45dbd4358bca...
> Remove non-existent vibe-code hallucinated options and clean up theme files
or https://github.com/basecamp/omarchy/commit/4fedfbe9f19303046...
There's also Omakub[0] which was sort of a precursor to Omarchy that gives users the `wget <some url> | bash` as a means of installation where the install script is a thin wrapper around another `eval $(wget <some url>` that then git clones a repository and executes a 3rd script.
That's definitely the kinds of patterns I'd expect some prolific software engineer to use and also encourage complete novices to Linux to be comfortable just piping arbitrary wgets into a shell
If you wanted "dead simple" text-based logging in a situation where a service is deployed in multiple places you'd end up writing a lot of fluff to get the same log correlation abilities that most OTEL drivers provide (if you can even ship your logs off the compute to begin with)
Which again comes back to the "maybe the framework isn't for you" if you're building an application that's a monolith deployed on a single VPC somewhere. But situations where you're working on something distributed or replicated, OTEL is pretty simple to use compared to past vendor-specific alternatives
I do still encourage people to learn C only because you could understand how the language works or a long weekend and it will help you appreciate just how things actually work under the hood (and a bit above the assembly instructions level). And TPP is great for helping you understand what to do when actually working on a deliverable project and not just the exciting parts. It’s the difference between building a toy that runs on your machine and a project others can run and use.
I really wish they'd do a revised 2nd edition using Golang as the base for the book instead of C; but otherwise it still really holds up well