"Linux bundles most drivers..."

True. I would just add a few notes for non Linux users.

- Drivers are bundled with the kernel but they're loaded dynamically when requested, ie supporting more devices doesn't make the kernel any bigger or slower. The Linux kernel from mostly static in the beginning became more and more modular and today save for developers or early adopters kernel rebuilds are very rare among users. Embedded cards aside, I don't recall having rebuilt a single kernel since 2.6 on normal PCs.

- Having drivers bundled in the kernel solves the problem of that piece of old hardware we lost the drivers disk and the manufacturer's site resolves to nowhere because they're no longer in business. Caring about older hardware seems of no importance in the desktop PC business, but not uncommon in the industrial world where one happily trades 100x speed loss in exchange of 10x reliability gain and there's still a lot of old perfectly functioning iron out there.

- Drivers are brand-free. Unless specified, they support the chipset, not the hardware brand and they definitely don't bundle other junk themselves, which is one of the plagues in the Windows ecosystem where 5 cards by 5 different manufacturers but using the same chipset all come with their set of drivers and associated ton of rubbish because the vendors fight to splatter their name on your desktop. Under Linux if you have 5 cards by 5 manufacturers you need one small driver and all software interfacing to standard device drivers can use all 5 cards. There's no such thing as "one card, one driver, one software". (Big exception for expensive niche proprietary hardware of course).

I don't see how including the driver inside the compiled kernel image can NOT make the resulting linux OS bigger than not including the compiled driver.

External modules (on the fs) wont, but we're talking about the bundled ones, right?

--one driver per chipset (vs one per branded add-in-board)

--smaller without crapware

--just empirically true:

tv@tv:~$ df -h

Filesystem Size Used Avail Use% Mounted on

/dev/sda5 28G 11G 17G 39% /

this is my bloated as fuck ubuntu media machine. could be much smaller if it mattered, but that's pretty small already, no?

anyone remember damn small linux? I used to have that on a 128MB (yes MB) flash drive found in a desk at work. but bytes are cheap...

I'm old enough to have played the embedded engineer using floppyfw on a spare 486 board screwed on a piece of wood along with a 1.44 fdd and a power supply cannibalized from somewhere. That was my embedded development system nearly 20 years back:) A bit later I ditched the floppy in favor of a spanking new 4 or 8 MB (megs, not gigs) flash parallel ATA "diskonmodule". Just checked, I'm surprised that the floppyfw page is still there. https://www.zelow.no/floppyfw/

Speaking of small distros, I gave a try at both DietPI and TinyCoreLinux on virtual machines and was amazed at how good they perform.

Bundled doesn't mean statically linked, it would be plain dumb if not impossible to add every driver out there into the kernel image; nowadays about everything is dynamically loaded so it doesn't impact the kernel size and doesn't waste memory or CPU cycles unless loaded, which happens only when necessary (eg when a USB device is inserted).

While it's true that a microkernel would hand the job to userspace, this is unrelated to Linux's bundling of drivers.

Linux, unlike the Windows kernel (which is also not a microkernel), does not have a stable kernel API for drivers. This means that drivers that live outside the tree have to play catch-up to every change that the kernel devs make.

When a driver is in-kernel, the person that made the changes fixes the driver as part of their change.

So Linux really encourages drivers to become open-source and submit for inclusion in the mainline kernel, just to avoid the maintenance hassle.