[taeric]

Mayhap I am misrepresenting the origins of Linux. Simply put, it was less rigidly modular in construction than it could have been at the beginning.[1] Indeed, I think it is a perfect case for the argument of "first get it done, then figure out how to make it modular." Probably a better argument for keeping the model such that you can keep the full picture in your head when working on it. Not sure.

[1] Consider also this lovely thread: http://www.realworldtech.com/forum/?threadid=65915&curpostid...

    You can do simple
    things easily - and in particular, you can do things where
    the information only passes in one direction quite easily,
    but anythign else is much much harder, because there is
    no "shared state" (by design). And in the absense of shared
    state, you have a hell of a lot of problems trying to make
    any decision that spans more than one entity in the
    system.

[memracom]

When people say that the Linux kernel is monolithic they really mean that it is not a microkernel architecture. In microkernels the designer says "Having a minimal microkernel with lots of separate modules is good therefore we will do everything that way". Linux simply says that modularity is good therefore we will use the appropriate integration technique at the appropriate times.

In the Linux kernel, you use printk to print messages on the console. That is modularity. There are device drivers. That is modularity. There is a range of loadable/configurable kernel modules for many things and these used to be more visible when more people would configure and build customized kernels. The Linux kernel has far more of these modules than earlier OSes that I used (TI DX10, UNIX 6th ed., Xenix, 3B2 Unix, SCO UNIX). The Linux kernel is linked into a monolithic binary that runs in kernel mode, but it is composed of many modules, some of which are integrated at link time and some of which are loaded dynamically (lsmod).

There is a good reason why the kernel is more monolithic than a business app, and that is that the kernel is doing a vastly different job at a vastly different layer of abstraction than a business app. You might also note that there are still lots of jobs for C programmers but most of them mention "embedded systems". That's what the Linux kernel is, a big featureful embedded system.

Perhaps some day someone will write a book on integration and cover all the different ways in which functionality can be integrated to produce an application. Most developers lean far too much on only one way of doing it, i.e. the link editor. For most apps, loosely coupled integration techniques are more valuable.

[taeric]

I don't think these terms are as different as you seem to be implying. When someone says "loosely coupled modules" they don't mean "printk" or similar functions. They mean such joys as power management and thread scheduling. These are somewhat modular in the kernel, to be sure. Are they so modular that you could TDD one or the other? My last understanding was not really.

Consider, you can have a device driver that runs fine "on its own" but crashes when run with another driver loaded. This is almost canonically the opposite of loosely coupled modules.