Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.misc Subject: Re: A tirade about inefficient software & systems Message-ID: Date: 8 Nov 90 17:12:28 GMT References: <9886@milton.u.washington.edu> <=YN6UN5@xds13.ferranti.com> <8460@scolex.sco.COM> <11R6593@xds13.ferranti.com> <1990Oct29.232733.2065@sctc.com> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 56 Nntp-Posting-Host: odin In-reply-to: stachour@sctc.com's message of 29 Oct 90 23:27:33 GMT On 29 Oct 90 23:27:33 GMT, stachour@sctc.com (Paul Stachour) said: stachour> Putting things in applications that belong in the OS is one of stachour> the worst forms of development known. Every application stachour> developer puts them in. And the cost is enormous. And the stachour> speed is horrible, because no-one has enough time to check stachour> performance and optimize correctly. And the reliability is stachour> horrible because because it's not checked and reused. Seemingly true, IMNHO. stachour> Done correctly, putting it in the OS (and paging it in when stachour> needed, so that all applications don't pay for a feature they stachour> don't need) is the performant, correct, consistant way. And stachour> it's the cheapest. Totally false, IMNHO. Here we have another example of a good misunderstanding. OSes should be not about features, but about multiplexing, as somebody says of MACH in another article, lauding its ability to put features in user level programs -- an OS should be the universal glue, i.e. not a function, but a functional. Programs are really made of two types of stuffs: functions and functionals (features and feature combinators) in alternating layers. UNIX got it right in perspective, but with the wrong flavour: it is (was...) an IO multiplexor, which is a poor paradigm for unviersal glue. Multics got it better: it was a library multiplexor, which is far more flexible. PLAN 9 got is wrong again: it is a filesystem multiplexor, which is a better uniform referent than files, but still innatural. System V is a streams/filesystem multiplexor, BSD is a virtual circuit multiplexor, and IPC connections are a better choice. Amoeba, MACH, etc... are nearly the right stuff: they are full capability multiplexors. Yet even the UNIX way, using pipes (virtual files) as glue, with all its in-built limits, has demonstrated that this is the way to go. OSes and shells are the functionals; libraries are the functions. An OS should provide abstraction mechanisms, not collections of features. User programs should be written as composition of function libraries, not collections of features. The alternative is not just between monolithic operating systems and monolithic applications -- if it were, you are right that monolithic operating systems are better than monolithic applications, but the problem isn't just like that. It is the lack of correct conceptual structure that causes bloat, as much as the endless quest for features. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk