3 ms·

Good point. I guess in comparison to Windows.

wolfgke 9y ago
If you want an "academically fair" (e.g. only compare parts that implement related functionality) comparison for Linux (the kernel!), you should compare it to ntdll.dll+hal.dll (these implement the kernel; cf. https://en.wikipedia.org/w/index.php?title=Microsoft_Windows_library_files&oldid=797308581#Internal_components https://en.wikipedia.org/w/index.php?title=Microsoft_Windows...). Here I think Linux would not be fare better (in terms of size) against Windows. You say this is (from a practical perspective) an unfair comparison for Linux, since under Linux, your applications can (in principle) call the kernel directly, while under Windows, they are linked against the subsystem that one wants to use - so one has to include the subsystem, too. I agree here - but this already makes a comparison much harder, since there is no related concept to "subsystem" under GNU/Linux. Indeed what people describe as "bloated" under Windows is not the kernel itself, but the perhaps Windows subsystem and even more the immense amount of intertwined components that are installed by default on a Windows installation. So a more fair comparison (from practical considerations) for Windows against GNU/Linux in terms of size would be a minimal system with which you can work properly and is supported by some vendor (to exclude some really experimental hacks of some Linux nerds which are really small in size, but not suitable for proper work). For Linux one can surely find such a configuration. For Windows the proper configuration to choose is "Windows Server 2016" in the "Server Core" or even "Nano Core" configuration: https://en.wikipedia.org/w/index.php?title=Server_Core&oldid=797310098 https://en.wikipedia.org/w/index.php?title=Server_Core&oldid... Here I am sure the Linux sample would still be smaller than the "Server Core"/"Nano Core" installation of Windows Server - but Microsoft has learned their lesson that there exist users who want a really slicked down Server version of Windows and has delivered.

If you want an "academically fair" (e.g. only compare parts that implement related functionality) comparison for Linux (the kernel!), you should compare it to ntdll.dll+hal.dll (these implement the kernel; cf. https://en.wikipedia.org/w/index.php?title=Microsoft_Windows_library_files&oldid=797308581#Internal_components https://en.wikipedia.org/w/index.php?title=Microsoft_Windows...). Here I think Linux would not be fare better (in terms of size) against Windows. You say this is (from a practical perspective) an unfair comparison for Linux, since under Linux, your applications can (in principle) call the kernel directly, while under Windows, they are linked against the subsystem that one wants to use - so one has to include the subsystem, too. I agree here - but this already makes a comparison much harder, since there is no related concept to "subsystem" under GNU/Linux. Indeed what people describe as "bloated" under Windows is not the kernel itself, but the perhaps Windows subsystem and even more the immense amount of intertwined components that are installed by default on a Windows installation. So a more fair comparison (from practical considerations) for Windows against GNU/Linux in terms of size would be a minimal system with which you can work properly and is supported by some vendor (to exclude some really experimental hacks of some Linux nerds which are really small in size, but not suitable for proper work). For Linux one can surely find such a configuration. For Windows the proper configuration to choose is "Windows Server 2016" in the "Server Core" or even "Nano Core" configuration: https://en.wikipedia.org/w/index.php?title=Server_Core&oldid=797310098 https://en.wikipedia.org/w/index.php?title=Server_Core&oldid... Here I am sure the Linux sample would still be smaller than the "Server Core"/"Nano Core" installation of Windows Server - but Microsoft has learned their lesson that there exist users who want a really slicked down Server version of Windows and has delivered.