I think you're reading the comment backwards from intent. To me this comment is just pointing that while the vast majority of the Linux kernel C it supports so much stuff it still has an order of magnitude more assembly than old operating systems that were 100% written in assembly.
Yes, apples to oranges... but interestingly so not as a knock that DOS was coded better or something.
Right, and how many distinct instruction set architectures did DOS 2.0 support? The fact that there are only 225k lines of assembly in the Linux kernel, across the 30 or so major architecture families Linux supports plus any number of variations within each family, is rather impressive. If you ported DOS 2.0 to one variant of each of those 30 architectures, assuming roughly equal code density, that would be over a million lines of assembly code altogether, for a far, far less capable system. That's considering only the OS core, not device drivers, which is reasonable since DOS 2.0 didn't really have any drivers worth speaking of by modern standards. Most of the real low-level I/O was handled by the BIOS.
> The fact that there are only 225k lines of assembly in the Linux kernel, across the 30 or so major architecture families Linux supports plus any number of variations within each family, is rather impressive.
Except that's not the intent that's conveyed by blindly throwing LoC numbers into the air. The intent is to suggest the exact opposite: bloat. Hence the blind comparisons that mean nothing at all.
Just for comparison, the whole DOS 2.0 operating system, which was written in assembly entirely, has just 37955.