What kind of things would you want in the GNU OS

[Jim Magee]

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

Well, I don't quite agree.

>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.

Well, the kernel code that supports virtual memory does not eat up that
much kernel space.  Now all the networking code, tty drivers, etc... in
there are a totally different story, and look to de-kernelized OSs like
Mach (and hopefully GNU, hint, hint...) to take care of this problem.

>>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.

Well I have to totally disagree here.  If you don't want the swap partition
in between / and /usr, then buy another disk and put /usr on that.  This
gives you interleaved disks and another drive is a hell of a lot cheaper
than having to stick the maximum amount of memory on a system that you are
ever going to need.  I have worked on real memory systems and seeing:

Please wait: waiting for memory to be freed....

When you try ot run ls, is not exactly fun. (especially when whatever has
that memory occupied never frees it, how do spell relief? R-E-B-O-O-T)  Plus
virtual memory can actually save performace, because it pages code in as
well as out, if you don't need it, it won't be brought in)  Try running emacs
on a non-VM system.

If you don't want a certain application to be swapped, then have process/page
lockdown system calls (along with nice features like real-time scheduling etc,
are you listening RMS? ;-)).  Please don't ever take me VM away.  If you
don't want it, use DOS.
-- 
Jim Magee - Unix Development		| Encore Computer Corp
jmagee at gould.com			| 6901 W Sunrise Blvd  MS407
...!uunet!gould!jmagee			| Ft Lauderdale, FL 33313
"I speak for nobody..."			| (305) 587-2900 x4925