Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!ames!haven!
adm!xadmx!PSPINLER%MKVAX1%MSUS1.BIT...@vm1.nodak.edu
From: nodak.edu>@adm.BRL.MIL
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you wnat in the GNU OS
Message-ID: <19793@adm.BRL.MIL>
Date: 29 May 89 19:27:37 GMT
Sender: n...@adm.BRL.MIL
Lines: 41
I can't really claim the know-how to back my opinions up, but there they are
anyway :
Concepts:
Message passing kernal, virtual memory, threads
Kernal Contains:
Message Handler
Scheduler
Swapper
FileSystem and device/network drivers are user mode processes locked into
real memory to prevent swapping. This way you need only 1 filesystem on
a network (the server) while network workstations need only a network driver &
small kernal loaded.
The filesystem could be bypassed, and the device drivers accessed directly,
but it provides a nice, clean, virtual interface. Enforce device access
through this interface, and you have a high level of security for a slight
penalty in network activity (ex. a consol message to a workstation would go
to server and back to workstation).
More filesystem ideas:
Add another permission 'l' - link permission: permision to add or
delete a hard link to the file. Ie, you'd need link permission to
delete a file or move it across directories.
Extend symbolic links to be able to include more than one 'real' file.
This would add all the functionality of VMS logicals to sym links.
Things would obviously have to be fleshed out a lot more than this, but it's
a good start. Furthermore, SVID and/or Berkley compatability could be provided
by special device drivers that would trap system calls.
Patrick Spinler BITNET: pspinler%mkvax1@msus1
115 Parkway Apt 102 Mankato State University
Mankato, Mn 56001
388-3085
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cmcl2!adm!xadmx!
Rex_E._Robards.Dlo...@xerox.com
From: Rex_E._Robards.Dlo...@xerox.com
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you wnat in the GNU OS
Message-ID: <19829@adm.BRL.MIL>
Date: 1 Jun 89 10:00:23 GMT
Sender: n...@adm.BRL.MIL
Lines: 4
Three things that should not be in an efficient OS:
1) virtual memory
2) symbolic links
3) long file names (BSD directories)
Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!apple!motcsd!hpda!
hpcupt1!hpisod2!decot
From: de...@hpisod2.HP.COM (Dave Decot)
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you wnat in the GNU OS
Message-ID: <14020064@hpisod2.HP.COM>
Date: 1 Jun 89 21:20:52 GMT
References: <19793@adm.BRL.MIL>
Organization: Hewlett Packard, Cupertino
Lines: 7
Three things that should not be in an unusable OS:
> 1) virtual memory
> 2) symbolic links
> 3) long file names (BSD directories)
Dave Decot
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!att!alberta!calgary!enme3!deraadt
From: dera...@enme3.ucalgary.ca (Theo Deraadt)
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you wnat in the GNU OS
Message-ID: <1468@cs-spool.calgary.UUCP>
Date: 2 Jun 89 22:16:52 GMT
References: <19793@adm.BRL.MIL> <14020064@hpisod2.HP.COM>
Sender: n...@calgary.UUCP
Reply-To: dera...@enme3.UUCP (Theo Deraadt)
Organization: U. of Calgary, Calgary, Alberta, Canada
Lines: 13
In article <14020...@hpisod2.HP.COM> de...@hpisod2.HP.COM (Dave Decot) writes:
>Three things that should not be in an unusable OS:
>
>> 1) virtual memory
>> 2) symbolic links
>> 3) long file names (BSD directories)
Exactly. If anyone thinks that an GNU OS would not have virtual memory and
BSD filenames, they have not played with GNU emacs lately.
<tdr.
Theo de Raadt CPSC student Calgary, Alberta, Canada
(403) 289-5894
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!boulder!
sunybcs!ugkamins
From: ugkam...@sunybcs.uucp (Dr. Chandra)
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you wnat in the GNU OS
Message-ID: <6275@cs.Buffalo.EDU>
Date: 4 Jun 89 17:28:30 GMT
References: <19829@adm.BRL.MIL>
Sender: nob...@cs.Buffalo.EDU
Reply-To: ugkam...@sunybcs.UUCP (Dr. Chandra)
Organization: SUNY/Buffalo Computer Science
Lines: 22
Rex_E._Robards.Dlo...@xerox.com wrote:
=>Three things that should not be in an efficient OS:
=> 1) virtual memory
=> 2) symbolic links
=> 3) long file names (BSD directories)
VM: nice, but certainly not efficient. Point well taken.
symlinks: somewhat stupid in the first place, to me. There are
already normal links. About the only advantage I can see is that
when copying files, links duplicate files whereas symlinks can be
"detected" and remade on the destination device/directory. Not sure
how they impact on EFFICIENCY though.
long names: depends what you consider efficient. Trying to remember
and mixing up cryptically shortened up and munged filenames cuts
productivity and in that respect causes inefficiency.
---
We can only contemplate the facts as we are able to perceive them.
Do we get what we deserve, or deserve what we get?
"Answer my question, tell me no lies.
Is this the real real world, or a fool's paradise?"
-- Eric Woolfson & Alan Parsons
(Lately, I'm beginning to believe the truth is the second case.)
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!
ucbvax!amdcad!crackle!tim
From: t...@crackle.amd.com (Tim Olson)
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you wnat in the GNU OS
Message-ID: <25848@amdcad.AMD.COM>
Date: 4 Jun 89 21:11:30 GMT
References: <19829@adm.BRL.MIL> <6275@cs.Buffalo.EDU>
Sender: n...@amdcad.AMD.COM
Reply-To: t...@amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 25
Summary:
Expires:
Sender:
Followup-To:
In article <6...@cs.Buffalo.EDU> ugkam...@sunybcs.UUCP (Dr. Chandra) writes:
| Rex_E._Robards.Dlo...@xerox.com wrote:
| =>Three things that should not be in an efficient OS:
| => 1) virtual memory
| => 2) symbolic links
| => 3) long file names (BSD directories)
|
| VM: nice, but certainly not efficient. Point well taken.
Efficient in what sense? VM makes more efficient use of "relatively
scarce" main memory -- processes only need to keep their working sets in
memory instead of their entire image. This potentially allows more
processes to run than would normally fit in main memory.
| symlinks: somewhat stupid in the first place, to me. There are
| already normal links. About the only advantage I can see is that
| when copying files, links duplicate files whereas symlinks can be
| "detected" and remade on the destination device/directory. Not sure
| how they impact on EFFICIENCY though.
Try linking to a file on another file system without symlinks!
-- Tim Olson
Advanced Micro Devices
(t...@amd.com)
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!dg!rec
From: r...@dg.dg.com (Robert Cousins)
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you wnat in the GNU OS
Message-ID: <186@dg.dg.com>
Date: 5 Jun 89 14:39:19 GMT
References: <19793@adm.BRL.MIL>
Reply-To: uunet!dg!rec (Robert Cousins)
Organization: Data General, Westboro, MA.
Lines: 40
IMHO, the features of such an operating system should be (in approximately
this priority):
0. Semantic compatibility with Unix
1. Portability
1.5 Multiprocessor support
2. Functionality
3. Extensability
4. Innovative
While I am sure that many people will disagree with the above priority
list, relatively few will disagree with the contents (save to add some
important ones I can't think of right now). The real issues will be
choosing the reference hardware and establishing some form of ABI/BCS
for the hardware.
It is important to note that there is a tremendous amount of room left for
inovation while maintaining compatibility with Unix. One of the common
complaints is that there is no user level facility for asynchronous I/O,
yet there is an easy way to provide a form of it -- remove the buffer
from the user's address space and cause a page fault on the next reference
to the page(s). The faulted program is then suspended until the completion
of the I/O request (which may be immediate if the I/O request has completed).
This allows the user task to return from the I/O call immediately yet have
the Unix semantics remain the same.
Other examples of potential innovation include an improved interface
between X windows and the operating system, improved file systems (which
take advantage of implicit parallelism in file operations), better networking
support (it seems that EVERYONE (except for one or two) runs the BSD
networking code with only minor hacking), making the kernel REENTRANT
would also help. Lastly, creating a new algorithm to replace linear
searches might just help a lot.
Just my $.02 worth.
Robert Cousins
Dept. Mgr, Workstation Dev't.
Data General Corp.
Speaking for myself alone.
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cmcl2!phri!roy
From: r...@phri.UUCP (Roy Smith)
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you wnat in the GNU OS
Summary: feeping creaturism (aka kernel inflation)
Message-ID: <3793@phri.UUCP>
Date: 6 Jun 89 01:26:52 GMT
References: <19851@adm.BRL.MIL>
Reply-To: r...@phri.UUCP (Roy Smith)
Organization: Public Health Research Inst. (NY, NY)
Lines: 11
In article <19...@adm.BRL.MIL> cherry.ST...@xerox.com writes:
> I'd say put [VM & symlinks] in. Let the user determine whether to use
> them or not. The fact that they are there doesn't hurt an OS.
It is thinking like this that led us from the 40k kernels I used to
run back in the v6 days to the 500+k kernels we see today.
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- r...@alanine.phri.nyu.edu
"The connector is the network"
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cmcl2!adm!
xadmx!...@dsys.ncsl.nist.gov
From: r...@dsys.ncsl.nist.gov (Root Boy Jim)
Newsgroups: comp.unix.wizards
Subject: What kind of things would you wnat in the GNU OS
Message-ID: <19918@adm.BRL.MIL>
Date: 7 Jun 89 17:40:47 GMT
Sender: n...@adm.BRL.MIL
Lines: 20
? From: Roy Smith <r...@phri.uucp>
? In article <19...@adm.BRL.MIL> cherry.ST...@xerox.com writes:
? > I'd say put [VM & symlinks] in. Let the user determine whether to use
? > them or not. The fact that they are there doesn't hurt an OS.
? It is thinking like this that led us from the 40k kernels I used to
? run back in the v6 days to the 500+k kernels we see today.
Perhaps a bit of arithmetic is in order. A V6 machine had 256k or perhaps
512k of core. Call it a ratio of 1:10. Todays machines have typically
4 or 8M. Again, call it 1:10. It takes more to do more.
? Roy Smith, Public Health Research Institute
? 455 First Avenue, New York, NY 10016
? {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- r...@alanine.phri.nyu.edu
? "The connector is the network"
Root Boy Jim is what I am
Are you what you are or what?
Path: utzoo!attcan!uunet!lll-winken!xanth!ames!sun-barr!texsun!texbell!sugar!
ficc!peter
From: pe...@ficc.uu.net (Peter da Silva)
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you wnat in the GNU OS
Message-ID: <4455@ficc.uu.net>
Date: 8 Jun 89 13:54:12 GMT
References: <19918@adm.BRL.MIL>
Organization: Xenix Support
Lines: 20
In article <19...@adm.BRL.MIL>, r...@dsys.ncsl.nist.gov (Root Boy Jim) writes
about bigger kernels today...
> It takes more to do more.
But is it really doing that much more?
What's the 5.2.3 kernel doing that the V7 kernel didn't do?
VM.
Streams.
RFS support (basically modifying namei() to support the network).
termio instead of sgtty.
?
What have I missed? And how much does it really take?
--
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Business: uunet.uu.net!ficc!peter, pe...@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, pe...@sugar.hackercorp.com.
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!adm!smoke!gwyn
From: g...@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you wnat in the GNU OS
Message-ID: <10389@smoke.BRL.MIL>
Date: 9 Jun 89 16:50:07 GMT
References: <19918@adm.BRL.MIL> <4455@ficc.uu.net>
Reply-To: g...@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 36
In article <4...@ficc.uu.net> pe...@ficc.uu.net (Peter da Silva) writes:
>But is it really doing that much more?
Ay, there's the rub.
>What's the 5.2.3 kernel doing that the V7 kernel didn't do?
> VM.
Adds a modest amount of code, for the SVR3 "region" approach.
> Streams.
May actually save code, slightly. (Replaces clists.)
> RFS support (basically modifying namei() to support the network).
Having any network protocol stuff in the kernel takes up space.
> termio instead of sgtty.
Adds a modest amount of code.
>What have I missed? And how much does it really take?
SVR3 also has three additional types of IPC, not counting FIFOs
(which take up a modest amount of additional code).
It has record locking, and in general an fcntl mechanism.
It has larger buffers and more caching, for performance reasons.
It has a bunch of administrative, logging, tracing, etc. features
that we probably agree it could do without.
Generally, there doesn't seem to be very good reason for the kernel
being as large as it currently is.
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!ficc!peter
From: pe...@ficc.uu.net (Peter da Silva)
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you wnat in the GNU OS
Message-ID: <4487@ficc.uu.net>
Date: 10 Jun 89 02:12:26 GMT
References: <19918@adm.BRL.MIL> <4455@ficc.uu.net> <10389@smoke.BRL.MIL>
Organization: Xenix Support
Lines: 13
In article <10...@smoke.BRL.MIL>, g...@smoke.BRL.MIL (Doug Gwyn) writes:
> In article <4...@ficc.uu.net> pe...@ficc.uu.net (Peter da Silva) writes:
> >What's the 5.2.3 kernel doing that the V7 kernel didn't do?
> Generally, there doesn't seem to be very good reason for the kernel
> being as large as it currently is.
OK. How about the BSD kernel?
--
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Business: uunet.uu.net!ficc!peter, pe...@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, pe...@sugar.hackercorp.com.
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!
ukc!dcl-cs!aber-cs!pcg
From: p...@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you wnat in the GNU OS
Summary: SysV = V7 + N versions * M additions... Ugh.
Message-ID: <1001@aber-cs.UUCP>
Date: 10 Jun 89 12:12:49 GMT
Reply-To: p...@cs.aber.ac.uk (Piercarlo Grandi)
Organization: Dept of CS, UCW Aberystwyth
(Disclaimer: my statements are purely personal)
Lines: 62
In article <4...@ficc.uu.net> pe...@ficc.uu.net (Peter da Silva) writes:
In article <19...@adm.BRL.MIL>, r...@dsys.ncsl.nist.gov (Root Boy Jim) writes
about bigger kernels today...
> It takes more to do more.
But is it really doing that much more?
Rhetoric question! V7 was (like Classic C) a remarkable balance of economy
and power. Power has increased a bit, economy has worsened a lot.
What's the 5.2.3 kernel doing that the V7 kernel didn't do?
VM.
Streams.
RFS support (basically modifying namei() to support the network).
termio instead of sgtty.
?
What have I missed? And how much does it really take?
On my SysV 3.2 I have potentially FIVE different pseudo terminal
implementations (xt???, sxt???, pty??, pts???, vt??), FOUR different IPC
mechanism (FIFO, shm+sem, streams, msg), FOUR different filsystem types
(S51K, S52K, Xenix, RFS), and so on, and so on, and so on, and so on, and so
on, and so on, .... (BSDs are occasionally even worse, and thank goodness
that BSD is still only a very partial implementation of Bill Joy's & C.
grandiose and hacky plans... :-<).
Not only each of them takes space if configured in (which for many is the
default), they also take space for the hooks, as each version does much the
same but in slightly different or totally incompatible ways, that require
different hooks.
Why this proliferation of (mostly pointless and misdesigned) variants?
Easy answer: because not many self styled Unix gurus are like the original
designers, have their depth and breadth of knowledge of other systems and
languages[**see note**], and (just like certain standard committees) are not
as gifted for simplicity and don't know what points of diminishing returns
are.
The idea that since we can afford more memory we can also afford sloppier
programming is as always ludicrous -- we want the extra memory for more
interesting applications, not to "afford" not much improved but badly
designed ones.
[**note**] to understand Unix/C and their evolution one must see them against
a cultural background that includes CTSS, Multics, Tenex, GCOS,
PDP/1, BCPL, Algol68, PL/360, etc..., things with which the original
designers were directly or indirectly familiar and influenced by. It
is terribly sad that the very diffusion of Unix/C (which was not
meant as research but as a convenient tool, and was essentially a
very clever retrenchment from more advanced designs under the
pressure of limited hw resources) in Universities has meant that
many CS grads and postgrads have not been exposed to anything else,
except maybe cursorily. I am afraid that the phenomenon of the
shallow (uncultured, historyless) Unix hacker is here to stay.
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac...@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: p...@cs.aber.ac.uk
Path: utzoo!attcan!uunet!ficc!peter
From: pe...@ficc.uu.net (Peter da Silva)
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you wnat in the GNU OS
Message-ID: <4500@ficc.uu.net>
Date: 11 Jun 89 23:20:49 GMT
References: <1001@aber-cs.UUCP>
Organization: Xenix Support
Lines: 13
[Piercarlo Grandi waxes eloquent about people whose views are tightly
channeled into the UNIX mould]
UNIX introduced a wonderfully clean and simple program interface that has
been widely (and often poorly) imitated. Unfortunately, too many fans of this
interface confuse it with the common implementations. They're like the Zen
students who, when the master points at the moon, continue to stare at his
finger.
--
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Business: uunet.uu.net!ficc!peter, pe...@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, pe...@sugar.hackercorp.com.