While I understand and empathize with your dislike of proprietary blobs (fuck you, NVIDIA), every game is a huge blob unless you're playing FOSS games exclusively.
this post was submitted on 29 Jul 2024
33 points (90.2% liked)
Linux Gaming
15849 readers
25 users here now
Gaming on the GNU/Linux operating system.
Recommended news sources:
Related chat:
Related Communities:
Please be nice to other members. Anyone not being nice will be banned. Keep it fun, respectful and just be awesome to each other.
founded 4 years ago
MODERATORS
That's true. And that's exactly why I give zero trust to any executable that I don't have the source code of. But there is a huge difference between running kernel level proprietary software and user space apps, which are easily at least sandboxable.
True, but most people don't sandbox their games, and while a userspace binary can't usually get root privileges, it doesn't need it to exfiltrate their summer holiday pics or health bulletin.
A good first step to mitigate this is to use separate gaming and serious accounts.
For a while I daily drove a Purism Librem 14 with Debian's fully free kernel, and installed as few non-free packages as possible, including firmware blobs (which I didn't install any of until I decided I needed Bluetooth). My experience with gaming was generally fine.
With linux-libre you really have to buy your hardware specifically with support in mind. You're limited to Intel and non-bleeding-edge AMD graphics cards, a very small range of wifi cards, and no Bluetooth. Otherwise, video games should work as well as they would on any other computers with the same specs. Especially if you're also limiting yourself to games with free engines - I'm not aware of a single libre game that demands more than a modern Intel integrated graphics card can provide, even on high settings.
Is this truly possible? I thought you will have microcode in any (x86) instance unless you're using Libreboot on an ancient Core Duo. Even then Leah will tell you, 'while you can technically run without the microcode blob it will not run correctly' even back then (IIRC).
As far as I understand it, the microcode was the hotfix for the expired original x86 patents, so pretty much universally required on all newer systems.
I'm no expert, but does the CPU scheduler work without microcode? How does the kernel determine the ISA available. I'm mostly curious because Intel 12th gen P-cores have a chance of including the more advanced enterprise server AVX instruction set. If any kernel does not require microcode, the scheduler must have a way to differentiate and manage running processes automatically so that a process with an AVX command is never interrupted and moved to the next available logical core where that core could be an E-core. That or there must be some scheme to create CPU set isolation and a way to determine if the more advanced AVX instructions are present. This would require an interesting way of handling spin up of idle cores, power management, and a complex way of handling thread interrupts.
I probably wouldn't understand most of what I might find on such a system, but it would be fun to read about and try to grasp. I think such a think is likely in the future, perhaps we are already in that future. I largely live under a rock, so let me know if we are there yet.
are you only going to play open source games too?
I guess you can live with SuperTuxKart, OpenTTD, 0 A.D, Armagetron, Mindustry, Open Arena etc.
Cmon bro, gotta make some compromises.