Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!haven!adm!news From: mail-support%cernvax.cern.ch@pucc.princeton.edu Newsgroups: comp.unix.internals Subject: Warning: Failed mail to VMS host Message-ID: <25264@adm.brl.mil> Date: 14 Dec 90 04:49:47 GMT Sender: news@adm.brl.mil Lines: 118 Your message to <@DxMINT.cern.ch:OLAVI%13411.decnet.CERN@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" Subject: Re: Software Obesity (was Re: Jargon file v2.1.5) Date: 3 Dec 90 17:36:07 GMT To: unix-wizards@sem.brl.mil I can't agree more with the expressive article by Marcus J. Ranum . 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