Warning: Failed mail to VMS host

[mail-support%cernvax.cern.ch at pucc.princeton.edu]

Your message to <@DxMINT.cern.ch:OLAVI%13411.decnet.CERN at CERNVAX.BITNET> could
 not be delivered.
The error message was:

Deferred: %MAIL-E-OPENOUT, error openning as output

This message is equivalent to the DECnet-VAX error message:

 -SYSTEM-F-EXDISKQUOTA, disk quota exceeded

The reason why your message could not be delivered is caused by the fact that
your correspondants account has ran out of diskquota. Please contact your
correspondant (by phone or otherwise) and tell him about this problem.


====== The start of Your original message ======

UNIX-WIZARDS Digest          Thu, 06 Dec 1990              V11#053

Today's Topics:
           Re: Software Obesity (was Re: Jargon file v2.1.5)
                    Ok... can we switch it back now?
           Re: Jargon file v2.1.5 28 NOV 1990 -- part 5 of 6
           Re: Jargon file v2.1.5 28 NOV 1990 -- part 1 of 6
           Re: Jargon file v2.1.5 28 NOV 1990 -- part 5 of 6
           Re: Jargon file v2.1.5 28 NOV 1990 -- part 1 of 6
           Re: Jargon file v2.1.5 28 NOV 1990 -- part 5 of 6
                Re: finding what processes owns a socket
                          PLEASE HELP ME!!!!!
                        Re: PLEASE HELP ME!!!!!
                         sysi86(S) in SCO Xenix
            Re: Popular response to the Jargon File 2.1.5...
                      Re: Preventing date rollback
           Re: need URGENT help with SCO UNIX TCP/IP - please
       CONVERSION, (postscript to laser) on 3B's and DEC stations
Re: Hardware Architectures and I/O (was: Re: Jargon file...) **FLAME!!**
            Re: How do you find the symbolic links to files.
                       Problems with the crontab
             clearing SUID and SGID bits on non-root write
           Re: clearing SUID and SGID bits on non-root write
                           Re: holes in files
                    Multics bloat??? Are you sure???
                    Jargon File Editorial Philosophy
                     Jargon file submission address
                         Jargon File ftp access
           Idea: general issues/topical computer discussion.
                           Seeking Unix Gurus

-----------------------------------------------------------------

From: "Vadim G. Antonov" <avg at hq.demos.su>
Subject: Re: Software Obesity (was Re: Jargon file v2.1.5)
Date: 3 Dec 90 17:36:07 GMT
To:       unix-wizards at sem.brl.mil


I can't agree more with the expressive article by Marcus J. Ranum
<mjr at hussar.dco.dec.com>. I like to express my attitude to software
dumps - I think the cost of finding and learning of appropriate
"feature" for solving a particular problem is much higher than
writing the program from scratch in "modern" commercial systems.
After reaching this point in complexity growth a system will collapse
under load of zillions of new misfeatures.

The theory I used to discuss on my lectures is:


HOW TO CREATE A DEAD SYSTEM


There are *three* ways "traditional" systems used to grow:

1) Packages

The old, dusty approach - if you have a problem you write a program
to solve *this* problem. If the problem is a bit more complex than
multiplying two 10x10 matrices you'd probably write a "package" equipped
with screen-oriented input, form generator, some bells and some whistles.
OK, you've made a cuspy package, let's call it "A". Some other guys have
done another package, "B", for a different task. OK, some time passed and
now you have to pass data from A to B in order to solve "joint" problem.

You can write a converter from data in format A into data in format B:

	A -> Conv -> B

in this case Conv tends to be a separate package and often it's less trivial
task than to solve the whole problem. In such case you have to design
a completely new package "A+B". In both cases you have *a new* package
for a minor increase in functionality. As you can see the curve


complexity     *
	|      *
	|     *
	|    *
	|  **
	***
	+------------- functionality

is exponential - and the life time of usable system is really small.
Examples of package-oriented systems are: IBM OS/370, Miscrosoft MS-DOS, etc.

2) Integrated Systems

The second way is to incorporate various kinds of functionality into
a single super-package (so called "integrated system"). This method
allows a desiger to avoid duplicating functions but tends to build
huge, unmanageable (and undebugable) programs. Moreover, such systems
practically does not allow users to upgrade and transform their
environment to their needs. As a result designers of such systems
make users to follow pre-defined paths what makes such systems *useless*
for solving *new* problems. Needless to say such systems could satisfy
only suits. The other source of limitations is the physical resources
of computers - try to imagine one which could keep the whole Unix
including all utilites in RAM :-) Unfortunately I-don't-want-to-think-but-
-I-want-to-use-computer user population is a very attractive target for