Adam Borowski <kilob...@angband.pl> writes: > Putting it another way:
> * the monolithic design has a huge freeness problem. To do anything not on > a rigid list of features you need to learn the intricaties of a large > complex system, and you can be certain that even if you manage to do so, > your patches will have a hard time getting accepted, and features you base > your code on will be thrown away on a whim every couple of years or so. > * In Unix, on the other hand, the barrier is typically mere knowledge of > scripting, in shell or any language of your preference. Small > components are easy to document (in man pages, etc) by the virtue of > no single part being complex. > * the Unix way almost guarantees you will do things wrong. While writing > something that works is easy, making it work in corner cases requires > serious research every time. Unlike a streamlined system, there's a > twisty maze of little init scripts, all alike -- yet usually with small > differences that do matter. Managing interactions becomes hard. > * A monolithic system has a global view of the system, instead of a > guerilla war in every corner. Yes, that sounds pretty much right to me. -- 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/87622n9lp5....@windlord.stanford.edu
