Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you want in the GNU OS
Message-ID: <1808@auspex.auspex.com>
Date: 10 Jun 89 20:24:48 GMT
References: <19963@adm.BRL.MIL>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 59

>Bob goes on to say, "Virtual Memory:  VMem is quite useful especially in
>CAD tools and high volume/resolution graphics.  On multi-user systems it
>becomes unrealistic to keep gigabytes of RAM around in order to perform
>high volume graphics. "   Again, I agree.  My own background has been
>principally in embedded systems, in which 1) data throughput is the measure
>of success, and 2) system RAM requirements are pre-determinable.  In this
>environment, VM is not needed and imposes an execution cost that I would
>rather not pay.

OK, so change your statement from:

	Three things that should not be in an efficient OS:

to

	Three things that should not be in an efficient OS for embedded
	systems:

or move Virtual Memory from the list of "things that should not be in an
efficient OS" to a separate list of "things that should not be in an
efficient OS for embedded systems" (not having worked with those
systems, I'll let those who have debate whether VM is ever appropriate
for them).

UNIX wasn't primarily intended as an OS for embedded systems....

>The problem is that most symbolic links are not created by the user
>(God knows I wouldn't make one, if I had a choice),

I've made many of them; they do come in handy for some of us.  I will
not defend the 386i version of SunOS's proliferation of them, but the
fact that they can be perhaps used to excess doesn't render them
useless....

>"Long Filenames: I do not see any impact on an OS by allowing long names. "
>My objection is not against long filenames, in general, as much as it is
>against the structure of BSD directories in particular.  The complicated
>system of counts and offsets that must be traversed in a BSD directory must
>consume much more cpu time than the relatively simple structure of AT&T's
>directories (I am aware that AT&T, sadly,  will adopt BSD's directory
>structure in the 'unified UNIX').

I'm not sad about it in the least.  I'm quite glad that I'll be able to
have an S5 system on which I'll be able to create files without having
to worry about the length of the file's name.  The various directory
name caches present in more recent systems with the BSD file system
(including S5R4, when it arrives) help reduce the time spent looking up
entries.

If your objection is not to long filenames (although you *did* just say
"long filenames" first and "(BSD directories)" second), note that
extending the V7/S5 directory format to support longer file names makes
directory entries larger, which also slows down the lookup time.  It
would be interesting to see the distribution of file name lengths on a
BSD system (where the limit is probably essentially infinite for all but
the most perverse user or application), to see if there's a bend in the
curve suggesting a lower maximum length, and then see how a
fixed-length-entry scheme supporting that maximum length does vs. the
BSD scheme.