Tech Insider					     Technology and Trends


			      USENET Archives

Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!...@icst-cmr.arpa
From: r...@icst-cmr.arpa (Root Boy Jim)
Newsgroups: comp.unix.wizards
Subject: SVR3.0 vs BSD4.3
Message-ID: <12414@brl-adm.ARPA>
Date: 15 Mar 88 19:30:28 GMT
Sender: n...@brl-adm.ARPA
Lines: 12


   From: Doug Gwyn  <g...@brl-smoke.arpa>

   SVR3.0 is the first AT&T UNIX system release that I would rate as
   technically the equal of, or superior to, 4.nBSD on all major counts.

The *first* one? I thought you were a believer years ago.	

	(Root Boy) Jim Cottrell	<r...@icst-cmr.arpa>
	National Bureau of Standards
	Flamer's Hotline: (301) 975-5688
	Isn't this my STOP?!

Path: utzoo!mnetor!uunet!husc6!hao!noao!arizona!lm
From: l...@arizona.edu (Larry McVoy)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <4361@megaron.arizona.edu>
Date: 16 Mar 88 03:02:46 GMT
References: <12414@brl-adm.ARPA>
Reply-To: l...@megaron.arizona.edu (Larry McVoy)
Organization: University of Arizona, Tucson
Lines: 18

In article <12...@brl-adm.ARPA> r...@icst-cmr.arpa (Root Boy Jim) writes:
>
>   From: Doug Gwyn  <g...@brl-smoke.arpa>
>
>   SVR3.0 is the first AT&T UNIX system release that I would rate as
>   technically the equal of, or superior to, 4.nBSD on all major counts.
>
>The *first* one? I thought you were a believer years ago.	

I missed the opener on this one; are you really serious, Doug?  What do you
mean by technically superior?  A nicer implementation of the disk sched
alg?  Or a more reasonable computing environ as defined by the system
call interface?  Or something else, somewhere inbetween?  

Just curious,
-- 

Larry McVoy	l...@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm

Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: g...@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <7499@brl-smoke.ARPA>
Date: 20 Mar 88 05:32:48 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu>
Reply-To: g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 50

In article <4...@megaron.arizona.edu> l...@megaron.arizona.edu (Larry McVoy) writes:
>>   From: Doug Gwyn  <g...@brl-smoke.arpa>
>>   SVR3.0 is the first AT&T UNIX system release that I would rate as
>>   technically the equal of, or superior to, 4.nBSD on all major counts.
>I missed the opener on this one; are you really serious, Doug?

Of course I'm serious.  Consider:
	modular region-based virtual memory manager
	shared libraries
	file system switch
	transparent networked file system
	STREAMS
	network interface library
	record locking
	reliable signals
	windowing utilities
	HDB UUCP
in addition to things already found in earlier releases of UNIX System V:
	usable system interface specification document
	faster, more complete standard C library
	somewhat better C compiler
	COFF
	FIFOs
	terminfo
	shell layers
	shared memory
	semaphores
	message passing
	process locking
	vendor support

Berkeley's system has equivalents to some of these, no equivalents to
others, and includes some things like LISP (not Common LISP) and rogue
not found in AT&T's system.  Berkeley's terminal handler is nicer-
looking to the user but not as good for the application programmer.
BSD-style job control is somewhat nicer for the user than shell layers,
but this is not available in their Bourne shell.  And so on...

When we acquired our first VAX, we had to decide which flavor of UNIX
to run on it.  We identified three reasons to prefer the Berkeley variant:
	TCP/IP network support
	virtual memory for large applications
	compatibility for importing sources from other sites,
		particularly from the Alpha_1 project (which
		for example relied heavily on flexnames).
The only one of these that might still be a factor is the latter,
but our level of concern with importing a single specific application
is much lower now, and in any case that is not a matter of technical
superiority.  Portability considerations are much more important, and
UNIX System V is much closer to meeting useful standards than 4BSD.

Path: utzoo!mnetor!uunet!husc6!tut.cis.ohio-state.edu!rutgers!iuvax!bsu-cs!dhesi
From: dh...@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <2423@bsu-cs.UUCP>
Date: 20 Mar 88 16:55:48 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA>
Reply-To: dh...@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 35

In article <7...@brl-smoke.ARPA> g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
writes:
[arguments why SVR3 is as good as 4.3BSD on all counts]

Here are some things I see under 4.3BSD that I don't see under SVR3,
unless they are either not documented or I somehow missed them.  I'm
comparing the full packages, not just the kernels.

   job control (stop/restart jobs, get status of jobs and know
                one is stopped for tty input)
   intelligent echoing to screen (SVR3 seems to blindly echo
        everything or nothing, can mess up screen, won't redraw
        partially-typed line, won't align tabs on char erase)
   intelligent mail handling -- sendmail, MH, biff, vacation
   "script" for recording terminal session
   "ul" for underlining when printing on various printers
   one complete KWIC index for all manuals
   symbolic links
   long filenames
   a user can be in multiple groups
   user information lookup ("finger", "lastcomm", "last")
   UUCP over TCP/IP links
   support for multiple command interpreters with #! as first line of script
   dbm library--fast /etc/passwd and /usr/lib/news/history access etc.
   context diffs from diff
   smarter, friendlier "at" program

A note about UUCP:  Although theoretically HDB UUCP is the equal of the
4.3BSD UUCP, I constantly hear horror stories on Usenet about how HDB
UUCP doesn't work right for one reason or another.  I don't hear quite
as many horror stories about 4.3BSD UUCP, probably because it has been
better integrated into the rest of the system and has had time to
stabilize.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi

Path: utzoo!mnetor!uunet!husc6!bu-cs!bzs
From: b...@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <20768@bu-cs.BU.EDU>
Date: 20 Mar 88 19:12:51 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA>
Organization: Boston U. Comp. Sci.
Lines: 35
In-reply-to: gwyn@brl-smoke.ARPA's message of 20 Mar 88 05:32:48 GMT



Doug, I tend to agree with you that SVR3 has really pushed SystemV
ahead and is promising to contribute a lot to the Unix community and
improve all variants of Unix as they move towards a common standard.

Other than job control and the user's view of the terminal handler
(both of which are probably reasonably bridged with ksh, so the Bourne
shell's lack is probably becoming moot) I'd still have to point out
the System V file system which is vastly inferior to BSD's rework in
some non-ignorable ways.

I don't see that implementing the BSD file system under SysV would
disrupt much anything either from a user's point of view (it just
gives them long file names) or the system's (it just speeds up access,
improves integrity a lot and reduces fragmentation to the point of
becoming a non-issue.) What's the issue here? Just a matter of time or
is there some real objection to adopting the BSD file system? Anyone
have a handle on this?

Similarly that should immediately give SysV dump and restore and other
utilities (eg. a better fsck), things that would vastly improve the
operational aspects which are very important in this day and age of
people like us having to manage over 100 systems and needing good,
reliable operational tools. Finc etc just don't cut it (do I need
to explain why?)

Also, adopting a standard and top-notch TCP/IP implementation with
several of the needed utilities bundled in is critical to many of
us and would force our hand if lacking.

I would have to suspect that the ATT/SUN merger is going to resolve
these issues, so I guess we wait just a little longer (heck, it's been
12 years now I've been waiting for all this to happen.)

	-Barry Shein, Boston University

Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: g...@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <7511@brl-smoke.ARPA>
Date: 21 Mar 88 12:25:47 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> 
<20768@bu-cs.BU.EDU>
Reply-To: g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 40

In article <20...@bu-cs.BU.EDU> b...@bu-cs.BU.EDU (Barry Shein) writes:
>What's the issue here? Just a matter of time or is there some real
>objection to adopting the BSD file system?

I don't think there is any real problem with providing the 4.2BSD
style of disk file system in UNIX System V via the file system
switch.  Implementations that currently support the old-style disk
file system will probably continue to do so in order to avoid
forcing the customer to rearrange existing disks when upgrading.
Note that several UNIX System V implementations already use a
different style of disk file system; for example, Silicon Graphics
has an extent-based scheme.  The nice thing about the FSS is that
it provides a relatively painless way to migrate from one style to
another, or to provide a special format, e.g. real-time data files,
which may have different needs from general timesharing files.

My evaluation of the 4.2BSD cluster approach is that it works best
if the processor has cycles to spare, and may not be a good choice
for small systems.

>Also, adopting a standard and top-notch TCP/IP implementation with
>several of the needed utilities bundled in is critical to many of
>us and would force our hand if lacking.

Unfortunately, the implementation you probably have in mind is
tightly coupled to sockets.  Wollongong developed a STREAMS-based
TCP/IP for AT&T; I don't know how good it is but there is no a
priori reason that a STREAMS implementation couldn't be as good as
one based on sockets.

One thing that a totally-STREAMS version of UNIX System V would
achieve is transparency over "pseudo-tty" channels, so that terminal
ioctls would work right.  I've needed this many times on our 4.2BSD
systems and have had to punt on it.

>I would have to suspect that the ATT/SUN merger is going to resolve
>these issues...

Certainly most of us hope so.  AT&T is definitely evolving UNIX far
faster than they used to.

Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: g...@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <7514@brl-smoke.ARPA>
Date: 21 Mar 88 13:37:04 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> 
<2423@bsu-cs.UUCP>
Reply-To: g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 109

In article <2...@bsu-cs.UUCP> dh...@bsu-cs.UUCP (Rahul Dhesi) writes:
>In article <7...@brl-smoke.ARPA> g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
>writes:
>[arguments why SVR3 is as good as 4.3BSD on all counts]

I said on all MAJOR counts.  There are lots of small items on each
system that the other could benefit from.  I named some, you named
some, and there are lots more.

>   job control (stop/restart jobs, get status of jobs and know
>                one is stopped for tty input)

As I mentioned, the System V equivalent is "shell layers", which is
not quite as nice from the user's perspective but it sure disrupts the
system internals less than the 4BSD approach (which has been revised
one way or another at least five times that I am aware of and still
occasionally causes us problems).  The 4BSD scheme for various reasons
does not readily fit into System V; I think the scheme worked out for
IEEE Std 1003.1 will probably be included in a future release of UNIX
System V.

>   intelligent echoing to screen (SVR3 seems to blindly echo
>        everything or nothing, can mess up screen, won't redraw
>        partially-typed line, won't align tabs on char erase)

I mentioned this.  There is no particular reason most of these features
could not be added to the System V terminal handler, and it would be
useful if they were.  Except for the user interface, the System V
terminal handler is clearly superior for most applications, as the
Berkeley developers have acknowledged; I think they've developed a
POSIX-compatible replacement terminal handler but I don't know how
you can get your hands on it.

>   intelligent mail handling -- sendmail, MH, biff, vacation

Doesn't matter to me; we use MMDF, $MAILPATH, sysmon, etc.

>   "script" for recording terminal session

"Script" screws up the application running under it sometimes.  It
could be implemented almost trivially with STREAMS.  Somebody should
do so.

>   "ul" for underlining when printing on various printers

Another one we don't use.  MDQS's line-printer spooler does a much
better job, and our other printers know how to underline.

>   one complete KWIC index for all manuals

That might be handy, but UNIX System V is intended to be distributed
as a set of packages, many of them optional, so it is hard to see
how to prepare such a merged index that would be maximally useful.

>   symbolic links

Probably coming in a future release.  As discussed previously, they
do bring some problems, but are nonetheless probably worth having.

>   long filenames

This is tied to the disk filesystem format, and unlike Berkeley,
AT&T chose not to invalidate their customer's existing filesystems.
However, the FSS now provides a mechanism for graceful migration to
an improved filesystem in which longer names would be possible.  I
don't know if they're working on it, but undoubtedly it would come
out of the AT&T/Sun merged-UNIX project.

>   a user can be in multiple groups

Probably coming in a future release.  I hope they fixed the Berkeley
bug that kept me from logging in when the system administrator added
me to my ninth group!

>   user information lookup ("finger", "lastcomm", "last")

I don't use these, so no comment.

>   UUCP over TCP/IP links

Supported by UNIX System V, last I heard.

>   support for multiple command interpreters with #! as first line of script

This is totally unnecessary; if all scripts are executed by a Bourne
shell, it is easy to simulate the #! feature, in fact to generalize
on it.  Nevertheless I think AT&T may be adding this kludge to the
kernel exec code in a future release, alas.

>   dbm library--fast /etc/passwd and /usr/lib/news/history access etc.

There are other ways to speed up /etc/passwd access that don't have
the drawback of maintaining a separate index file.  A good, standard
ISAM would be useful, but dbm ain't it.

>   context diffs from diff

This could be added easily enough, and I considered adding it to my
System V emulation package but decided it wasn't particularly useful.

>   smarter, friendlier "at" program

Another thing I don't care for; we use MDQS "batch" facilities.
System V has user (non-superuser) crontab support that seems nice.

>A note about UUCP:  Although theoretically HDB UUCP is the equal of the
>4.3BSD UUCP, ...

Wrong; theoretically it is superior to 4.3BSD UUCP.

Path: utzoo!mnetor!uunet!husc6!ncar!noao!arizona!lm
From: l...@arizona.edu (Larry McVoy)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <4441@megaron.arizona.edu>
Date: 22 Mar 88 19:02:34 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> 
<20768@bu-cs.BU.EDU> <7511@brl-smoke.ARPA>
Reply-To: l...@megaron.arizona.edu.UUCP (Larry McVoy)
Organization: University of Arizona, Tucson
Lines: 24

In article <7...@brl-smoke.ARPA> g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>Unfortunately, the implementation you probably have in mind is
>tightly coupled to sockets.  Wollongong developed a STREAMS-based
>TCP/IP for AT&T; I don't know how good it is but there is no a
>priori reason that a STREAMS implementation couldn't be as good as
>one based on sockets.

It is my personal belief that streams was intended as a _slow_ terminal
"virtualization" (Padlipsky would be proud) mechanism.  As such, one 
should probably think carefully about the performance aspects of 
implementing high bandwidth drivers that use streams.  One could (I have
seen it) suggest that all drivers talk through streams interfaces.  Seems
like a nice idea (modularity being the buzzword that comes to mind) until
you start counting how many times you say "bcopy(src, dest, len)".  This
might be a moot point when we have infinitely fast CPU's and memories :-)

(It should be obvious but I'll drive it home:  the streams code that I've
seen copies the data out of the upper level buffer and then into the 
lower level buffer [assuming "downward" movement].  The copying dominates
the time spent in the streams drivers.  If streams can handle imbedded 
pointers in their data then my comments are meaningless.)
-- 

Larry McVoy	l...@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm

Path: utzoo!mnetor!uunet!seismo!rick
From: r...@seismo.CSS.GOV (Rick Adams)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <44269@beno.seismo.CSS.GOV>
Date: 22 Mar 88 19:08:01 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> 
<2423@bsu-cs.UUCP>
Organization: Center for Seismic Studies, Arlington, VA
Lines: 15
Summary: hdb vs. 4.3bsd uucp


In my biased opinion, HDB has 3 major advantages over the 4.3bsd uucp.

	1) The Permissions file
	2) The Dialers file
	3) Subdirectories per site.

4.3 aleady has almost all of the other good ideas the HDB did. The
subdirecories are coming soon. The Dialers are coming soon. The
Permissions file is coming some day.

It is my stated goal to make the 4.3bsd uucp do everything HDB does
without using any of the HDB code.

---rick

Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: g...@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: STREAMS overhead (was: SVR3.0 vs BSD4.3)
Message-ID: <7526@brl-smoke.ARPA>
Date: 22 Mar 88 23:30:40 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> 
<20768@bu-cs.BU.EDU> <7511@brl-smoke.ARPA> <4441@megaron.arizona.edu>
Reply-To: g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 11

In article <4...@megaron.arizona.edu> l...@megaron.arizona.edu.UUCP (Larry McVoy) writes:
>(It should be obvious but I'll drive it home:  the streams code that I've
>seen copies the data out of the upper level buffer and then into the 
>lower level buffer [assuming "downward" movement].

The only data copy that should normally take place is between user-mode
data space and the nearest streams buffer, also between the farther
streams buffer and the net device.  Streams module-to-module data
transfer should occur by transferring packet pointers whenever possible.
(I haven't examined SVR3 code to see if this is how it typically does
things.)

Path: utzoo!mnetor!uunet!husc6!bbn!gatech!ulysses!hector!ekrell
From: ekr...@hector.UUCP (Eduardo Krell)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <10179@ulysses.homer.nj.att.com>
Date: 23 Mar 88 01:59:55 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> 
<20768@bu-cs.BU.EDU> <7511@brl-smoke.ARPA> <4441@megaron.arizona.edu>
Sender: netn...@ulysses.homer.nj.att.com
Reply-To: ekrell@hector (Eduardo Krell)
Organization: AT&T Bell Labs, Murray Hill
Lines: 15

In article <4...@megaron.arizona.edu> l...@megaron.arizona.edu.UUCP (Larry McVoy) writes:

>(It should be obvious but I'll drive it home:  the streams code that I've
>seen copies the data out of the upper level buffer and then into the 
>lower level buffer [assuming "downward" movement].  The copying dominates
>the time spent in the streams drivers.  If streams can handle imbedded 
>pointers in their data then my comments are meaningless.)

Well, now. The streams modules that I've seen so far avoid copying data
as much as possible. Passing a message up or downstream is often
accomplished by just passing pointers to the data.
    
    Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

    UUCP: {ihnp4,ucbvax}!ulysses!ekrell		ARPA: ekr...@ulysses.att.com

Path: utzoo!mnetor!uunet!husc6!ncar!noao!arizona!lm
From: l...@arizona.edu (Larry McVoy)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <4471@megaron.arizona.edu>
Date: 23 Mar 88 17:09:09 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> 
<20768@bu-cs.BU.EDU> <7511@brl-smoke.ARPA> <4441@megaron.arizona.edu> 
<10179@ulysses.homer.nj.att.com>
Reply-To: l...@megaron.arizona.edu.UUCP (Larry McVoy)
Organization: University of Arizona, Tucson
Lines: 16

In article <10...@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes:
>In article <4...@megaron.arizona.edu> I said:
>
>>(It should be obvious but I'll drive it home:  the streams code that I've
>>seen copies the data out of the upper level buffer and then into the 
>
>Well, now. The streams modules that I've seen so far avoid copying data
>as much as possible. Passing a message up or downstream is often
>accomplished by just passing pointers to the data.

Several people have pointed this out to me.  It seems that I have been 
exposed to some fairly poorly written streams code and it is that code,
not streams, that is brain-damaged.
-- 

Larry McVoy	l...@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm

Path: utzoo!mnetor!uunet!munnari!kre
From: k...@munnari.oz (Robert Elz)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <2050@munnari.oz>
Date: 24 Mar 88 11:19:41 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> 
<7514@brl-smoke.ARPA>
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 32

In article <7...@brl-smoke.ARPA>, g...@brl-smoke.ARPA (Doug Gwyn ) writes:
> >   job control (stop/restart jobs, get status of jobs and know
> >                one is stopped for tty input)
> 
> As I mentioned, the System V equivalent is "shell layers",

Doug, you know better than that, shl is at attempt at windows for asr33's
and as such has some advantages and some disadvantages over the bsd use
of job control to attempt to force windows onto asr33's and lookalikes.

But that's not job control.  Job control is when I notice that /foobar
is 98% full, and some cretin has a job running that's half way through
extracting 160Mb from a tar tape .. "kill -STOP <pid>" is job control.
(Then "kill -CONT <pid>" later if I can manage to scavenge enough space
to allow the tar to continue.  Nb: it matters little if the cretin is
me or not in these circumstances).

> >   long filenames
> 
> This is tied to the disk filesystem format,

Well, kind of, filenames are tied to the directory format, which has
nothing to do with the rest of the filesystem format (after all,
directories are just files, in both systems).

> >   support for multiple command interpreters with #! as first line of script
> 
> This is totally unnecessary;

This is so much drivel its not even worth commenting on.

kre

Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: g...@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <7542@brl-smoke.ARPA>
Date: 24 Mar 88 20:18:33 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> 
<7514@brl-smoke.ARPA> <2050@munnari.oz>
Reply-To: g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 19

In article <2...@munnari.oz> k...@munnari.oz (Robert Elz) writes:
>But that's not job control.  Job control is when I notice that /foobar
>is 98% full, and some cretin has a job running that's half way through
>extracting 160Mb from a tar tape .. "kill -STOP <pid>" is job control.

Most 4BSD job control seems to be done by typing ^Z, "fg", "bg", etc.
Running under "shl", there is a keyboard-generated signal similar to
TSTP and analogs of fg, bg, etc.  That is why I said that "shl" is
the AT&T UNIX equivalent of 4BSD job control.  As both of us have
said, each approach has advantages and disadvantages w.r.t. the other.

>(after all, directories are just files, in both systems).

This isn't really true.  The kernel's file-system code knows how to
deal with specific directory formats.  Similarly for NFS directory access.

>This is so much drivel its not even worth commenting on.

A refutation of my argument against #! would have been useful.

Path: utzoo!mnetor!uunet!vsi!friedl
From: fri...@vsi.UUCP (Stephen J. Friedl)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <445@vsi.UUCP>
Date: 25 Mar 88 06:31:38 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> 
<7542@brl-smoke.ARPA>
Organization: V-Systems, Inc. -- Santa Ana, CA
Lines: 27
Summary: shell layers do not have signals

In article <7...@brl-smoke.ARPA>, g...@brl-smoke.ARPA (Doug Gwyn ) writes:
< In article <2...@munnari.oz> k...@munnari.oz (Robert Elz) writes:
< >But that's not job control.  Job control is when I notice that /foobar
< >is 98% full, and some cretin has a job running that's half way through
< >extracting 160Mb from a tar tape .. "kill -STOP <pid>" is job control.
< 
< Most 4BSD job control seems to be done by typing ^Z, "fg", "bg", etc.
< Running under "shl", there is a keyboard-generated signal similar to
< TSTP and analogs of fg, bg, etc.  That is why I said that "shl" is
< the AT&T UNIX equivalent of 4BSD job control.  As both of us have
< said, each approach has advantages and disadvantages w.r.t. the other.

Shell layers do not involve any kind of signals.  When ^Z is hit,
the sxt driver gives control back to channel zero, which is
usually the layer manager (here, /usr/bin/shl).  When a user
command to shl asks that a child layer be run, the layer manager
issues an ioctl to the multiplexor to give control to the child's
layer (there is no SIGCONT).  One result of this implementation
is that I know of no way for a layer to suspend itself, certainly
not with signals (if anybody else knows how I would love to hear it).

Nevertheless it is not incorrect to equate job-control with shell
layers in a general kind of way -- kre's way just may be more general
than mine :-).
-- 
Steve Friedl      V-Systems, Inc.        *Hi Mom*
fri...@vsi.com   {uunet,attmail,ihnp4}!vsi!friedl

Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!ncar!noao!arizona!lm
From: l...@arizona.edu (Larry McVoy)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <4509@megaron.arizona.edu>
Date: 25 Mar 88 20:47:39 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> 
<7542@brl-smoke.ARPA> <445@vsi.UUCP>
Reply-To: l...@megaron.arizona.edu (Larry McVoy)
Organization: University of Arizona, Tucson
Lines: 11

In article <4...@vsi.UUCP> fri...@vsi.UUCP (Stephen J. Friedl) writes:
>Shell layers do not involve any kind of signals.  When ^Z is hit,
>the sxt driver gives control back to channel zero, which is
>usually the layer manager (here, /usr/bin/shl).  When a user

Which means you could emulate shell layers with pty's.  All that is going is
the master side has several slave sides and switches between them.  It is 
a far cry from job control.
-- 

Larry McVoy	l...@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm

			        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/