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.
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.
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!
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.