Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!rutgers!bellcore!texbell!uhnix1!sugar!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.os.misc
Subject: Re: Why Unix is good (was Re: Unix bigotry) LONG
Message-ID: <3186@ficc.uu.net>
Date: 24 Feb 89 12:15:22 GMT
References: <3101@ficc.uu.net> <299@bnr-fos.UUCP> <3151@ficc.uu.net> <306@bnr-fos.UUCP>
Organization: Xenix Support
Lines: 29

In article <306@bnr-fos.UUCP>, schow@bnr-public.uucp (Stanley Chow) writes:
>   Be careful, I sense some hostility towards Unix on your part. This
>   could get you flamed royally. [If I misinterpret your yes, sorry]

The only hostility you may be sensing is towards the bozos who put hundreds
of K of junk in the UNIX kernel that better belongs outside, or at least
should be optional.  Once upon a time UNIX was small enough that it could
compete with DOS. Never forget that. Let's hope Mach does better against OS/2.

>   Interesting. How about speed of OS operations? Like the famous wildcard
>   expansion in the shell? E.g., DIR vs ls, TYPE vs more, mkdir vs mkdir,
>   RENAME *.o *.oo vs mv ??, file creation speed, ...

Anything that required going to the inodes, but not much more, seemed to be
marginally slower for small directories. Things like 'ls -l' versus 'dir',
as opposed to 'ls -C' vs 'dir /w'. For large directories it was always faster,
probably because the cache was being more effectively used, and normal
wildcard expansion didn't seem to slow it down any.

>   I hope you only had to port to it as opposed to actually editing and
>   compiling on it.

Develop and compile. And it was an advance over the 8080-based intel blue
boxes we had been using.
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.   `-_-'
Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net.                 'U`
People have opinions. Companies have policy. And typos are my own business.