On Wed, Jan 23, 2013 at 08:45:49PM -0800, Russ Allbery wrote:
> 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.
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.
--
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
--
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/20130124050949.ga10...@angband.pl
