481
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 24 Oct 2026
481 points (99.6% liked)
PC Gaming
15716 readers
1064 users here now
For PC gaming news and discussion. PCGamingWiki
Rules:
- Be Respectful.
- No Spam or Porn.
- No Advertising.
- No Memes.
- No Tech Support.
- No questions about buying/building computers.
- No game suggestions, friend requests, surveys, or begging.
- No Let's Plays, streams, highlight reels/montages, random videos or shorts.
- No off-topic posts/comments, within reason.
- Use the original source, no clickbait titles, no duplicates. (Submissions should be from the original source if possible, unless from paywalled or non-english sources. If the title is clickbait or lacks context you may lightly edit the title.)
founded 3 years ago
MODERATORS
The kernel has a ton of optional modules that they'd be stupid to include them all. They certainly don't need support for an obscure Quebec companies GPUs that stopped producing in the 90s.
Its pretty standard operating to cut out any cruft you can, saves on storage, boot times, etc. This one was probably saving milliseconds and kilobytes, so presumably not much thought was given to disabling it, nor needed to reenable it.
Again?! An unwarranted attack by the anglophones against the Québécois GPU artisans!
L’enterrement de cyber-crapaud!!
Listen here frenchy!
Ouuuuu....you done fucked up.
Wannabe Frenchies, the French don't care about them.
Quebec is more French than France.
Mon Dieu!
L'américaine ne pas bien!
(Oh god please don't fry me for my French, this was attempted without AI translation and a very long gone French education)
Maudit anglais !
The existence of it also adds another potential attack vector for hackers. It's unlikely that this would be a real problem, but any additional software is just another place that could be exploited.
Thats a really good point, especially with the more obscure modules.
It must be interesting for steam to develop a hackable device in a market that usually locks their hardware down so aggressively.
I mean just because steam doesn't mind you tinkering with their own hardware doesn't mean they should not try to secure the base system OS against outside intrusion (like a RAT entering in via an AUR installation using modules as an entry point)
Yeah, sorry I meant more in the way that a user in a VM is a really different threat surface to a full root user.
For sure both should apply security patches, and avoid malware, I'm just wondering even within that model what the differences are.
True but part of Valve's marketing for Frame is the expansion slot, so at least peripherals compatible with ARM hardware were probably meant to be enabled and this was an oversight.
Thats valid, and due to the speed of the update I wouldn't be surprised if it was already in their testing suite.
How unloaded kernel module can slow boot time?
Still needs to be read from disk/flash, for the kernel to know it exists. And more relevantly every module has a number of dependencies that will all contribute to size/boot times in their own way.
Maybe even milliseconds is giving it too much, but bloat is really important especially near the release of new hardware.
I imagine the last thing anyone was worried about in crunch time was if they enabled enough random hardware in their config file.
They disabled them to save boot time.