What kind of things would you want in the GNU OS

[rroba.DlosLV at xerox.com]

> Three things that should not be in an efficient OS:
>	1) virtual memory
>	2) symbolic links
>	3) long file names (BSD directories)

Perhaps some explanation is in order:

We have performance problems with SunOS that we don't have with Xenix
on similar hardware.  The reason for the difference in performance that
we see between Xenix and SunOS is the presence of these three features
in SunOS.  The code in the Kernel which supports these features eats
up memory and cpu time whether the user wants to use them or not.
The typical size of Xenix on an 80386 architecture is 300K, SunOS for the
386i is about 900K (as distributed; some features can be deleted through
reconfiguration).

The historical philosophy of the UNIX community (AT&T, at least) has been
Keep It Simple.  The recent  proclivity toward rampant featurism (BSD
crowd in particular) has resulted in a corresponding decrease in system
throughput.

>VM and Symbolic links are nice features.  I'd say put them in.  Let the
user >determine whether to use them or not.  the fact that they are there
>doesn't hurt an OS.  But, let the user, not the author, be the deciding
factor.

VM kills performance whether the user chooses to use it or not.  The
typical
placement of the swap device on single disk systems (as most UNIX systems
seem to be now) is as a partition placed between a read-only root file
system and a read-write user file system (this is done to "optimize" the
disk's swap activity).  The result is that the disk heads are constantly
seeking
between the outermost tracks (the root file system), and the innermost
tracks (the user file system).  Paging code in the Kernel does not come
free.
It requires space, and execution time.  Virtual memory was justifiable when
memory was expensive (i.e. $30,000 for an 8K core bomb).  Memory now
is just too cheap to pay for the execution penalty.

The real problem with symbolic links is that users are not given a choice
whether to use them or not.  If the OS distributor chooses to use them, and
then rewrites utilities to optimize "real" paths, it is next to impossible
for
the user to remove them.  (I am assuming that everybody in the audience
understands the impact of a symbolic link on the amount of time required
to open a file.)