One of the single biggest negatives going against Windows based systems is the large degree of integration of the Operating System with applications. Many people, apparently including the Microsoft marketing department, view this as a positive; rather, such a high degree of integration has significant security and stability consequences. For example, the Windows kernel is heavily integrated with the graphical user interface; there is no Windows without windows.
Linux on the other hand is very modular by design. Different components of a Linux system originate from different developers; each has their own specific design goals and focus on those goals. Further, each component is configured separately, generally by the use of text based configuration files. This modular design means that the Linux kernel is independent of the graphical interface, for example. The net result is that crashes and security vulnerabilities in applications tend to remain localized, rather than affecting the system as a whole.
The modular configuration system of Linux is somewhat daunting at first, as there is no standardized format for the myriad of configuration files that exist. But, there are some key advantages to this system. For example, configurations are not in a cryptic database (the Windows Registry). Reading and writing configuration information can be done by scripts or applications using simple text parsing engines; no special API is required to interface with the system configuration data. Script based configuration adjustments allow for such powerful techniques in Linux as dynamic routing or firewalling done 'on the fly' which are considerably more difficult in a Windows environment.
Indeed, the shell itself is one of the most powerful Linux 'modules' that has been all but ignored in recent versions of MS Operating Systems (Windows is so extremely tied to the graphical interface that CLI use is relegated to nearly substandard status). Scripting of Linux systems provides a level of automation and control that is difficult to achieve in Windows. I've played around with the Windows Management Instrumentation (WMI) that uses Visual Basic Script as the scripting language; between poorly documented API's and object specifications and the work required to interface with the registry or other system resources, WMI is a useful tool but weak compared to a shell such as bash in Linux.
With bash, one can in a single line determine system memory, an allowed port with the firewall, change an email address in a dozen html files or any of a host of other useful tasks. In short, the Linux shells have been developed to make Linux administrators productive!
Finally, another aspect of modular design is the use of links in the Linux file system. Windows allows the use of shortcuts, but they are not links in the true sense. A shortcut is not evaluated by the OS as the shortcut target file, it simply acts somewhat like an alias for the filename. A link on the other hand is a true abstraction of a real file; if you open a 'link,' you actually open the file to which it points. Links are extremely powerful in maintaining a properly running system, especially if one upgrades application and system components.
One of the most important uses of links is to generate a 'pointer' to a library. Suppose an application uses the shared library mylib-2.3.so. Rather than hard-code the application to read this particular file, it is coded to read mylib.so, which is really a link to mylib-2.3.so. Subsequent upgrades of mylib can be made without having to recompile the applications that use it; only the link target needs to be changed. This allows one to have many versions of the same shared library on a Linux system simultaneously, which cannot typically be done on a Windows system. Applications designed to use whatever the newest version is call the link (assuming it always links to the newest version), whereas applications that require a specific version can be compiled to call that version rather than the link. This technique allows all Linux software to have it's required environment and one application cannot break another; this is the essence of modular design.
On Windows, dynamic library file names typically do not contain the version. This means one cannot tell by simple inspection what version a given library is. An application that requires a specific library version, say mylib.dll version 2.3, cannot coexist on a system with an application that requires a different version (such as mylib.dll version 3.5 or newer), since there would be a name collision. Here we see another disadvantage of both the software deployment models and Open vs. Closed source models of Windows and Linux. Applications on Windows typically cannot be modified by the end user, so one cannot recompile using a different file name for the necessary dynamic library.