> It's a matter of approach. Linux takes what I like to call the cookie > monster approach, which is MORE MORE MORE. More syscalls, more ioctls, > more program flags, more layers of indirection, a constant enumeration > of every use case. Rarely is there a pause to check whether several > use cases can be coalesced into a single more general way of doing > ... > More to the point, I'm yet to see a richer set of abstractions come > out of another system. Private namespaces, resources as files... they
I often try to explain it to people this way. There's a big difference between mechanisms and features. Well designed software gets a lot of features out of a few mechanisms. Poorly designed software creates a new mechanism for each feature. You can see the difference in the code, and you can feel the difference when using it. For example, the design decision to use a standard protocol across all resources and a mechanism to import name spaces doesn't seem like all that much if you're judging by the release notes. But it's hard to even list all the "features" you get from it. The discussion about /net is one. It makes dealing with graphical displays across a network so elegant as to make X look positively gross. It makes using a remote disk for off-site mirroring trivial. And the list goes on. Your homework assignment is to figure out which of those two characterizations best fits the software you use daily. BLS
