Adam Borowski <kilob...@angband.pl> writes: > There are two ways to design a system: > * a monolithic well-integrated system, granting features and efficiency at > the cost of portability and hackability > * the traditional Unix way, with a stress on replaceable tools that do only > one thing, granting freedom to tinker, using the system in a way not > envisioned by its creators
...at the cost of occasional complex, difficult-to-debug interactions between the separate components, and a larger total code base to support fallbacks and alternatives to provide loose coupling between the components. Just to complete both sides of the picture. (I'm more of a second camp person myself, but they both have drawbacks.) The traditional UNIX way is great if everyone can agree on a clean and minimal API between the components that enables thorough independent testing of the components and minimizes complex multi-component interactions. Were that this were always the case.... Most of the places where people reach for other strategies are places where it's not clear those conditions hold. Whenever you have a complex programming problem, break it into a client and a server. Now you have two complex programming problems, a protocol design problem, and a security vulnerability. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ham79ojm....@windlord.stanford.edu
