Tech Insider					     Technology and Trends


			      USENET Archives

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.

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/