The original Oberon system was something like 12,000 lines of code, something you could imagine reading in its entirety.
IIRC most of the Linux kernel source code is device drivers; the linux kernel also has a huge amount of functionality, much more than you need just to boot a PC into a GUI. Much of Linux user code is bloated libraries with a good deal of duplicated functionality.
Many GUI-based systems from the 1980s and 1990s were very compact by modern standards. (Even a full Smalltalk-80 system image is less than 2MB including the source code.) You can still run RISC OS on the Raspberry Pi to try out a 1980s/90s-style PC OS. Classic text-based UNIX OSes were obviously also dramatically smaller than modern Linux distributions.
Regarding device drivers, I wonder if the BIOS approach is better - assume the hardware vendor supplies the device drivers, and let the OS use those drivers rather than supplying its own. Someone will probably argue that "oh legacy BIOS is 16-bit, doesn't support [caching/acceleration/scatter-gather/async/polling/ feature x] or hardware vendors don't know how to write drivers or it's closed source or blah blah blah" but that would be missing the point that the idea of separating the driver subsystem from the OS might not be such a bad one.
https://schierlm.github.io/OberonEmulator/
The original Oberon system was something like 12,000 lines of code, something you could imagine reading in its entirety.
IIRC most of the Linux kernel source code is device drivers; the linux kernel also has a huge amount of functionality, much more than you need just to boot a PC into a GUI. Much of Linux user code is bloated libraries with a good deal of duplicated functionality.
Many GUI-based systems from the 1980s and 1990s were very compact by modern standards. (Even a full Smalltalk-80 system image is less than 2MB including the source code.) You can still run RISC OS on the Raspberry Pi to try out a 1980s/90s-style PC OS. Classic text-based UNIX OSes were obviously also dramatically smaller than modern Linux distributions.
Regarding device drivers, I wonder if the BIOS approach is better - assume the hardware vendor supplies the device drivers, and let the OS use those drivers rather than supplying its own. Someone will probably argue that "oh legacy BIOS is 16-bit, doesn't support [caching/acceleration/scatter-gather/async/polling/ feature x] or hardware vendors don't know how to write drivers or it's closed source or blah blah blah" but that would be missing the point that the idea of separating the driver subsystem from the OS might not be such a bad one.