postmast%dtuzdv5a.bitnet@omnigate.clarkson.edu (09/01/87)
Your mail is being returned to you.
Reason for return is:
%MAIL-E-NOSUCHUSR, no such user Z277730 at node ZMVAX
Returned mail follows:
------------------------------
Received: From DEARN(MAILER) by DTUZDV5A with RSCS id 3944
for Z277730@DTUZDV5A; Mon, 31 Aug 87 23:35 N
Received: by DEARN (Mailer X1.24) id 3939; Mon, 31 Aug 87 23:33:55 CET
Date: Mon, 31 Aug 87 14:52:13 EDT
Reply-To: Unix-Wizards@BRL.ARPA
Sender: Unix-Wizards Mailing List <UNIX-WIZ@NDSUVM1>
Comments: Resent-From: jch@omnigate.clarkson.edu
Comments: Originally-From: Jeffrey C Honig <jch@omnigate.clarkson.edu>
From: jch@omnigate.clarkson.edu
Subject: Re: Need help on MicroVAX-II ethernet crash problems
X-To: unix-wizards@sem.brl.mil
To: Gloria X <Z277730@DTUZDV5A>
>In article <659@bingvaxu.cc.binghamton.edu> sullivan@marge.math.binghamton.edu
(fred sullivan) writes:
>>> [in reference to my description of the Ultrix 1.2 DEQNA driver patch]
>>Is this fixed in Ultrix 2.0, which I am about to install, or should I ask
>>for the patch?
>
>This patch (or something like it) was incorporated into Ultrix 2.0. We
>have a few 2.0 machines, and none of them have had any qeput() crashes,
>and they don't seem to have "qerestart" troubles, either.
I've been having "qerestart" problems with BSD 4.3 on a MicroVAX. Has
anyone incorporated this fix into the BSD 4.3 driver?
Thanks
Jeff
POSTMASTER%DICKINSN.BITNET@cornellc.cit.cornell.edu (Postmaster) (10/21/89)
This message was automatically generated.
Your mail message could not be delivered at Dickinson College in Carlisle,
Pennsylvania because the user address was not known at our site.
Addresses at Dickinson College are of the following format:
username@DICKINSN e.g., POSTMASTER@DICKINSN
or ALLAN_J@DICKINSN
or WOLTER@DICKINSN
Usernames are typically the first 8 letters of the person's last name,
frequently with the first initial added, and occasionally with an
underscore. As a result, it would be difficult to guess someone's username.
If you do not know the address of someone at Dickinson, please send a
message to POSTMASTER@DICKINSN asking for help.
----------------------------------------------------------------------
The following diagnostic is the reason for the return:
%BNET-W-NOSUCHRCVR, receiver LEYON_C cannot be located
Returned mail follows:
----------------------
Received: From PSUVM(MAILER) by DICKINSN with Jnet id 3287
for LEYON_C@DICKINSN; Fri, 20 Oct 89 14:33 EDT
Received: by PSUVM (Mailer R2.03B) id 4285; Thu, 19 Oct 89 20:18:45 EDT
Date: Thu, 19 Oct 89 18:32:51 CST
Reply-To: Unix-Wizards@BRL.ARPA
Sender: Unix-Wizards Mailing List <UNIX-WIZ@NDSUVM1>
From: David Drewrey <CSDREWRY@VM.CC.OLEMISS.EDU>
Subject: Unsubscription
X-To: unix-wizards@BRL.MIL
To: Chris Leyon <LEYON_C@DICKINSN.BITNET>
unsubscribe David DrewreyPOSTMASTER%DICKINSN.BITNET@cornellc.cit.cornell.edu (Postmaster) (10/21/89)
This message was automatically generated.
Your mail message could not be delivered at Dickinson College in Carlisle,
Pennsylvania because the user address was not known at our site.
Addresses at Dickinson College are of the following format:
username@DICKINSN e.g., POSTMASTER@DICKINSN
or ALLAN_J@DICKINSN
or WOLTER@DICKINSN
Usernames are typically the first 8 letters of the person's last name,
frequently with the first initial added, and occasionally with an
underscore. As a result, it would be difficult to guess someone's username.
If you do not know the address of someone at Dickinson, please send a
message to POSTMASTER@DICKINSN asking for help.
----------------------------------------------------------------------
The following diagnostic is the reason for the return:
%BNET-W-NOSUCHRCVR, receiver LEYON_C cannot be located
Returned mail follows:
----------------------
Received: From PSUVM(MAILER) by DICKINSN with Jnet id 1830
for LEYON_C@DICKINSN; Fri, 20 Oct 89 15:34 EDT
Received: by PSUVM (Mailer R2.03B) id 2520; Fri, 20 Oct 89 14:34:13 EDT
Date: Fri, 20 Oct 89 13:32:15 CDT
Reply-To: Unix-Wizards@BRL.ARPA
Sender: Unix-Wizards Mailing List <UNIX-WIZ@NDSUVM1>
From: "Charles F. Ashley" <LOGSAMS@A.ISI.EDU>
Subject: IBM, HONEYWELL OCTAL CODES TO UNIX PROBLEM
X-To: unix-wizards-request@sem.brl.mil
X-cc: unix-wizards@BRL.MIL
To: Chris Leyon <LEYON_C@DICKINSN.BITNET>
PROBLEM : UNISYS 5000/80 INTERFACING WITH IBM/HONEYWELL.
Here's a challenge to the UNIX professionals. My agency has hit a
programming snag in rewriting our programs from the HONEYWELL to
the Army's UNISYS 5000. On this side of the ocean, we are baffled
as to a solution:
Problem Definition:
THE PROBLEM OCCURS WHEN UPLOADING OR DOWNLOADING VARIABLE-LENGHT RECORD
FORMATS USING 9 TRACK MAGNETIC TAPES. THE IBM AND HONEYWELL USE A FOUR-BYTE
RECORD CONTROL WORD (RCW) THAT SUPPLIES THE LENGHT OF THE RECORD AND A
FOUR-BYTE BLOCK CONTROL WORD (BCW). IN SHORT, UNISYS READS BOTH BCW AND RCW
AS THEIR ACTUAL OCTAL REPRESENTATION CAUSING THE TAPE TO APPEAR AS ONE
CONTINUOUS HUGE RECORD WITHOUT INDIVIDUAL RECORDS.
Question: HOW CAN AN IBM OR HONEYWELL RECORD WITH OCTAL CODES BE READ INTO
THE UNISYS 5000 SYSTEM? LISTED BELOW ARE BOTH UNBLOCKED AND BLOCKED
PICTORIAL REPRESENTATIONS OF THE RECORDS FORMAT.
EXAMPLE 1:
UNBLOCKED RECORDS +-----------------------------------------+
| BCW | RCW | RECORD | BCW | RCW | RECORD |
| 4 | 4 | 300 | 4 | 4 | 200 |
| 308 | 304 |record 1| 208 | 204 |record 2|
+-----------------------------------------+
THE RCW CONTAINS THE LENGHT OF THE RECORD PLUS ITS OWN LENGHT OF 4.
THE BCW CONTAIN THE LENGHT OF THE RCW PLUS ITS OWN LENGHT OF 4.
EXAMPLE 2:
BLOCKED RECORDS +--------------------------------------------------+
| BCW | RCW | RECORD | RCW | RECORD | RCW | RECORD |
| 4 | 4 | 300 | 4 | 200 | 4 | 250 |
| 766 | 304 |record 1| 204 |record 2| 254 |record 3|
+--------------------------------------------------+
THE RCW CONTAINS THE LENGHT OF THE RECORD PLUS ITS OWN LENGHT OF 4. THE
BCW CONTAINS THE TOTAL LENGHT OF THE RCWS AND RECORDS PLUS ITS OWN
LENGHT OF 4.
THESE 4-BYTE WORDS (BCW OR RCW) ARE USUALLY IN THE OCTAL FORM. OUR COBOL
COMPILER (FAST/PHILON) DOES NOT SUPPORT 9 TRACK (OR IS NOT DOCUMENTED) AND I
HAVE FOUND NO OTHER SYSTEM UTILITY TO DUPLICATE THIS. I NEED YOUR
HELP / ASSISTANT / GUIDANCE.
If possible send replies both to the bboard and logsams. Time for us is short.
Charley F. ?Ashley, US ARMY
-------POSTMASTER%DICKINSN.BITNET@cornellc.cit.cornell.edu (Postmaster) (10/21/89)
This message was automatically generated.
Your mail message could not be delivered at Dickinson College in Carlisle,
Pennsylvania because the user address was not known at our site.
Addresses at Dickinson College are of the following format:
username@DICKINSN e.g., POSTMASTER@DICKINSN
or ALLAN_J@DICKINSN
or WOLTER@DICKINSN
Usernames are typically the first 8 letters of the person's last name,
frequently with the first initial added, and occasionally with an
underscore. As a result, it would be difficult to guess someone's username.
If you do not know the address of someone at Dickinson, please send a
message to POSTMASTER@DICKINSN asking for help.
----------------------------------------------------------------------
The following diagnostic is the reason for the return:
%BNET-W-NOSUCHRCVR, receiver LEYON_C cannot be located
Returned mail follows:
----------------------
Received: From PSUVM(MAILER) by DICKINSN with Jnet id 8323
for LEYON_C@DICKINSN; Fri, 20 Oct 89 18:45 EDT
Received: by PSUVM (Mailer R2.03B) id 5160; Fri, 20 Oct 89 18:48:19 EDT
Date: Fri, 20 Oct 89 16:37:18 EST
Reply-To: Unix-Wizards@BRL.ARPA
Sender: Unix-Wizards Mailing List <UNIX-WIZ@NDSUVM1>
From: "Michael J. Chinni, SMCAR-CCS-E" <mchinni@PICA.ARMY.MIL>
Subject: Re: IBM, HONEYWELL OCTAL CODES TO UNIX PROBLEM
X-To: "Charles F. Ashley" <LOGSAMS@a.isi.edu>
X-cc: unix-wizards@BRL.MIL
To: Chris Leyon <LEYON_C@DICKINSN.BITNET>
Charley,
If the Unisys has a C compiler, you should be able to write a C program
to read and interpret the RCW and BCW. C allows you to read in an octal value.
The thing to be carefull of is how you open the tape device. I suggest
reading the on-line manual entry on mt probably in section 7 (i.e. man 7 mt )
for a BSD-type system.
If you get real lucky, someone will have already written something like
this and had it put in the archive of public-domain unix-sources.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Michael J. Chinni
Chief Scientist, Simulation Techniques and Workplace Automation Team
US Army Armament Research, Development, and Engineering Center
User to skeleton sitting at cobweb () Picatinny Arsenal, New Jersey
and dust covered workstation () ARPA: mchinni@pica.army.mil
"System been down long?" () UUCP: ...!uunet!pica.army.mil!mchinni
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/POSTMASTER%DICKINSN.BITNET@cornellc.cit.cornell.edu (Postmaster) (10/21/89)
This message was automatically generated.
Your mail message could not be delivered at Dickinson College in Carlisle,
Pennsylvania because the user address was not known at our site.
Addresses at Dickinson College are of the following format:
username@DICKINSN e.g., POSTMASTER@DICKINSN
or ALLAN_J@DICKINSN
or WOLTER@DICKINSN
Usernames are typically the first 8 letters of the person's last name,
frequently with the first initial added, and occasionally with an
underscore. As a result, it would be difficult to guess someone's username.
If you do not know the address of someone at Dickinson, please send a
message to POSTMASTER@DICKINSN asking for help.
----------------------------------------------------------------------
The following diagnostic is the reason for the return:
%BNET-W-NOSUCHRCVR, receiver LEYON_C cannot be located
Returned mail follows:
----------------------
Received: From PSUVM(MAILER) by DICKINSN with Jnet id 1547
for LEYON_C@DICKINSN; Fri, 20 Oct 89 22:29 EDT
Received: by PSUVM (Mailer R2.03B) id 6925; Fri, 20 Oct 89 22:32:20 EDT
Date: Fri, 20 Oct 89 21:36:32 EDT
Reply-To: Unix-Wizards@BRL.ARPA
Sender: Unix-Wizards Mailing List <UNIX-WIZ@NDSUVM1>
From: Mike Muuss <mike@BRL.MIL>
Subject: Re: IBM, HONEYWELL OCTAL CODES TO UNIX PROBLEM
X-To: "Charles F. Ashley" <LOGSAMS@a.isi.edu>
X-cc: unix-wizards-request@sem.brl.mil, logsams@a.isi.edu,
unix-wizards@BRL.MIL
To: Chris Leyon <LEYON_C@DICKINSN.BITNET>
There are several aspects to your problem:
1) You should have your mainframe system write "export tapes" in a
fixed-blocked (RECFM=FB) or unblocked (RECFM=U) format; using
variable-blocked or variable-blocked-spanned records for "export" to
another system makes for lots of extra trouble.
2) Often, the easiest way to process foreign tapes on a UNIX system
is to read them onto disk, using the "DD" program, and the **raw**
tape drive interface (often called /dev/rmt0). You can be certain
that the tape drive interface is RAW if the first character output
by "ls -l" is the letter "c", (eg, "crw-rw-rw- ...").
Once you have the data on disk, usually a small "C" program can
unravel things. That kind of data handling in COBOL or FORTRAN
will be very painful, compared to using C or PASCAL.
If you need more help, contact your local Information Systems Command
(ISC) detatchment; ISC is busy doing to the Army's computer systems
what they did to the Army's telephones.
Best,
-MikePOSTMASTER%DICKINSN.BITNET@cornellc.cit.cornell.edu (Postmaster) (10/21/89)
This message was automatically generated.
Your mail message could not be delivered at Dickinson College in Carlisle,
Pennsylvania because the user address was not known at our site.
Addresses at Dickinson College are of the following format:
username@DICKINSN e.g., POSTMASTER@DICKINSN
or ALLAN_J@DICKINSN
or WOLTER@DICKINSN
Usernames are typically the first 8 letters of the person's last name,
frequently with the first initial added, and occasionally with an
underscore. As a result, it would be difficult to guess someone's username.
If you do not know the address of someone at Dickinson, please send a
message to POSTMASTER@DICKINSN asking for help.
----------------------------------------------------------------------
The following diagnostic is the reason for the return:
%BNET-W-NOSUCHRCVR, receiver LEYON_C cannot be located
Returned mail follows:
----------------------
Received: From PSUVM(MAILER) by DICKINSN with Jnet id 3155
for LEYON_C@DICKINSN; Sat, 21 Oct 89 02:17 EDT
Received: by PSUVM (Mailer R2.03B) id 7546; Sat, 21 Oct 89 02:19:50 EDT
Date: Sat, 21 Oct 89 01:19:14 CDT
Reply-To: Unix-Wizards@BRL.ARPA
Sender: Unix-Wizards Mailing List <UNIX-WIZ@NDSUVM1>
From: wong@OMCP.OMRON.CO.JP
Subject: C on Directory
X-To: unix-wiz%ndsuvm1.BITNET@cunyvm.cuny.edu
To: Chris Leyon <LEYON_C@DICKINSN.BITNET>
I am porting a C program from BSD to System V. It seems that the following
functions:
opendir
closedir
readdir
are not available in the System V library.
Is that any way of resolving this? Suggestions appreciated.
Thanx very much.
Marvin Wong
Omron Management CentrePOSTMASTER%DICKINSN.BITNET@cornellc.cit.cornell.edu (Postmaster) (10/21/89)
This message was automatically generated.
Your mail message could not be delivered at Dickinson College in Carlisle,
Pennsylvania because the user address was not known at our site.
Addresses at Dickinson College are of the following format:
username@DICKINSN e.g., POSTMASTER@DICKINSN
or ALLAN_J@DICKINSN
or WOLTER@DICKINSN
Usernames are typically the first 8 letters of the person's last name,
frequently with the first initial added, and occasionally with an
underscore. As a result, it would be difficult to guess someone's username.
If you do not know the address of someone at Dickinson, please send a
message to POSTMASTER@DICKINSN asking for help.
----------------------------------------------------------------------
The following diagnostic is the reason for the return:
%BNET-W-NOSUCHRCVR, receiver LEYON_C cannot be located
Returned mail follows:
----------------------
Received: From PSUVM(MAILER) by DICKINSN with Jnet id 5228
for LEYON_C@DICKINSN; Sat, 21 Oct 89 09:06 EDT
Received: by PSUVM (Mailer R2.03B) id 0141; Sat, 21 Oct 89 09:06:17 EDT
Date: Sat, 21 Oct 89 02:45:38 EST
Reply-To: UNIX-WIZARDS@BRL.MIL
Sender: Unix-Wizards Mailing List <UNIX-WIZ@NDSUVM1>
From: Mike Muuss The Moderator <Unix-Wizards-Request@BRL.MIL>
Subject: UNIX-WIZARDS Digest V8#098
X-To: UNIX-WIZARDS@BRL.MIL
To: Chris Leyon <LEYON_C@DICKINSN.BITNET>
UNIX-WIZARDS Digest Sat, 21 Oct 1989 V8#098
Today's Topics:
Re: Shutting off accounts
Re: Help! Altos 5.3.1 fork is failing!
Re: using /bin/sh in make commands
Re: What SHOULD go in the kernel
BSD file system
Re: How do you tell a wizard?
alloca discussion/alloca on MIPS cpus
Re: UNIX history made easy
Re: What SHOULD go in the kernel
Re: BSD file system
Re: How do I set up an insulating gateway?
Re: How do you tell a wizard?
Re: Job Control (a la csh/ksh) from within C
GNU tar
Re: How do you tell a wizard?
Disk drivers needed: RQDX2, RD5N, RX50
Re: GNU tar
Re: How do you tell a wizard?
Re: What SHOULD go in the kernel
Re: How do you tell a wizard?
Re: remote access to edit buffer
Re: What SHOULD go in the kernel
Re: How do you tell a wizard?
Re: Help! Altos 5.3.1 fork is failing!
Re: How do you tell a wizard?
Re: Help! Altos 5.3.1 fork is failing!
Re: What SHOULD go in the kernel
Re: How do you tell a wizard?
Re: What SHOULD go in the kernel
TTY, speak now, or forever
Re: BSD file system
How to write a new Unix-like kernel
Re: How do you tell a wizard?
fork affecting ndbm requests?
Re: What SHOULD go in the kernel
Re: BSD file system
need help with very old uucp
Re: How do you tell a wizard?
Re: Shadow Disks
Re: What SHOULD go in the kernel
Re: How do you tell a wizard?
Default group IDs (was: Re: BSD file system)
Re: How do you tell a wizard?
Re^2: using /bin/sh in make commands
Re: Real Time UNIX (was: Re: How do you tell a wizard?)
-----------------------------------------------------------------
From: "daniel.w.meeks" <borg@cbnewsc.att.com>
Subject: Re: Shutting off accounts
Date: 18 Oct 89 20:01:11 GMT
Keywords: accounts, /dev/null, shutoff, `Woof!'
To: unix-wizards@sem.brl.mil
>When I was managing hordes of undergraduate accounts at the University of
>Toronto. I used to change a users shell to restrict his login. There was a
>directory call "/bin/shells", and if I wanted to turf a user on January 1, I
>would put an entry in /bin/shells called, for example, "deleteonJan1"
-------
This is an interesting way of taking care of accounts.
a) input account information
b) run create-dirs-and-password-entries-script
c) run make-symbolic-link-to-expire-date-script
d) run at-job-to-remind-you-of-expire-date
e) run at-job-to-resymlink-expired-shells
I worked at Purdue's Engineering Computer Network as an SA. Most likely
only SA's from Universities would have these kinds of task. Has anyone
ever made mention of a SA workshop/conference for University types? I am
sure a great deal of good technology could be passed between staff.
+-------------------------------------------------------+
| Daniel W. Meeks - dwm@iexist.att.com |
|``Computer..Computer.. Ah, a keyboard! How quaint...''|
+-------------------------------------------------------+
-----------------------------
From: Jerry Gardner <jerry@altos86.altos.com>
Subject: Re: Help! Altos 5.3.1 fork is failing!
Date: 18 Oct 89 22:56:41 GMT
Followup-To: comp.unix.i386
To: unix-wizards@sem.brl.mil
In article <506@oglvee.UUCP> jr@oglvee.UUCP (Jim Rosenberg) writes:
>
>What the bleep is getcpages? It sounds like an internal kernel routine to get
>continuous pages in RAM. Is this call issued by the paging daemon? How could
>it fail on a request to get only 1 page unless I'm out of swap space? (Which
>I'm not. We're getting these with many many thousand blocks of free swap
>space -- we have a swap(1) which will show these.)
>
Getpages is an internal kernel routine that allocates contiguous pages of
kernel virtual memory. It's not called by the paging daemon, but rather to
allocate or grow regions, among other things.
>Is there a tunable parameter that will rescue me here?
>
Not really. You really are running out of swap space. Even though
"swap -l" may show plenty of swap space remaining, it is misleading.
UNIX allocates swap space for the entire .data and .bss regions whenever
a process is exec'ed. Even though swap -l shows plenty of swap space
available, most of the swap space is allocated to processes, which, although
they may not currently be swapped out, still tie up the swap space.
Your best solution: get more RAM. The 2000 in my office that I use as a
single-user personal machine has 24MB. If you can't get more RAM, you could
try a larger swap partition, but if your system is heavily loaded, it'll just
thrash, constantly paging and swapping things in and out.
--
Jerry Gardner, NJ6A Altos Computer Systems
UUCP: {sun|pyramid|sco|amdahl|uunet}!altos86!jerry 2641 Orchard Parkway
Internet: jerry@altos.com San Jose, CA 95134
I survived the Big One, October 17, 1989 946-6700
-----------------------------
From: David Kuder <david@indetech.com>
Subject: Re: using /bin/sh in make commands
Date: 18 Oct 89 23:08:33 GMT
To: unix-wizards@sem.brl.mil
In article <21173@adm.BRL.MIL> Leisner.Henr@xerox.com (Marty) writes:
>Often people have rules in makefiles of the form:
foo:
for i in $(DIRS); do \
(cd $$i; $(MAKE) foo); \
done
>It seems if one of the sub-makes fails, the shell loop continues.
>The Bourne shell has a -e flag to exit immediately on errors.
>Unfortunately a line like:
SHELL=/bin/sh -e
>doesn't work. (make tries to exec "/bin/sh -e").
>Is there a good way to get the functionality I'm looking for without having
>to hack up all the makefiles?
Which make are you using? There are way too many of these beasts.
However, on the three that I have at hand, SunOS4, Sys5.3, UCB4.3 (the
last two are Pyramid versions), a "make foo" stops as soon as one of
the sub makes fails.
If you must avoid changing the makefile (arguably broken) if you run
the make under a Bourne in which a 'set -e' has been done then the
shells started by the make will inherit it. I can't test this but
it may work.
--
David A. Kuder Comp.lang.perl, the time is now!
415 438-2003 david@indetech.com {uunet,sun,sharkey,pacbell}!indetech!david
-----------------------------
From: "John F. Haugh II" <jfh@rpp386.cactus.org>
Subject: Re: What SHOULD go in the kernel
Date: 19 Oct 89 02:16:41 GMT
To: unix-wizards@sem.brl.mil
In article <47040@bbn.COM> pplacewa@antares.bbn.com (Paul W. Placeway) writes:
>First off, kernels are generally harder to debug than user programs,
>so the less stuff you add there the better off you will be. Also,
>most kernels won't do VM on themselves (for several _good_ reasons
>:-) ), so any extra code you put in the kernel will be sitting there
>taking up space even if you don't need it right now.
I don't have trouble with the first part, but discouraging paging
the kernel is kinda wasteful the way kernels keep bloating.
The primary restriction against a paging kernel is keeping the
paging code from being paged ;-). After that, satisfying real-time
constraints, etc. will yield a collection of pages which must
be locked in memory as well. What should be left in the list
of locked pages should only be lower halves of device drivers,
the VM manager, the pager, and the global data required by those.
Massive tables, seldom used device drivers, and one-time
initialization code should all be candidates for the pager.
I paid for the memory, and damnit, I want to use it.
>On the other hand, it's much harder to do real-time-ish things in a
>user program than in the kernel on most UNIXes.
Granted. However, much of what is in a UNIX kernel has no
real time requirements and should be paged out when not required.
Dynamically loadable device drivers are wonderful. When can
we see dynamically unloadable device drivers ;-)
--
John F. Haugh II +-Things you didn't want to know:------
VoiceNet: (512) 832-8832 Data: -8835 | The real meaning of MACH is ...
InterNet: jfh@rpp386.cactus.org | ... Messages Are Crufty Hacks.
UUCPNet: {texbell|bigtex}!rpp386!jfh +--<><--<><--<><--<><--<><--<><--<><---
-----------------------------
From: Rico Tudor <rico@dehn>
Subject: BSD file system
Date: 19 Oct 89 07:56:48 GMT
Sender: news@accuvax.nwu.edu
To: unix-wizards@sem.brl.mil
While porting my file archiver from System V to a DECStation 3100, the
following questions regarding system calls have arisen:
(1) How are permissions set on a symbolic link?
(2) How are access & modification times set on a symbolic link?
(3) What purpose is served by taking the group ID of a newly
created file from the parent directory, rather than the
process?
In Questions (1) and (2), chmod(2) and utimes(2) follow the link, which I
don't want. I am handling Question 1 by temporarily altering the process
"umask", but I don't like it. The 3100 runs "Ultrix", a BSD variant.
-----------------------------
From: Jim Campbell <campbell@umb.umb.edu>
Subject: Re: How do you tell a wizard?
Date: 18 Oct 89 14:49:29 GMT
To: unix-wizards@sem.brl.mil
Some years ago, I saw a description of how to tell the
level of the individual with respect ot their UNIX knowledge.
ie: NOVICE:
Calls vi vye
etc
Unfortunately for me, I misplaced it and have looked for it
ever since. If anyone has this file, I would greatly appreciate a copy.
Might even be appropriate to post it here (again?).
Thanks in advance.
-----------------------------
From: George Hartzell <hartzell@boulder.colorado.edu>
Subject: alloca discussion/alloca on MIPS cpus
Date: 18 Oct 89 23:11:43 GMT
Sender: news@boulder.colorado.edu
Keywords: alloca mips
To: unix-wizards@sem.brl.mil
A few months back there was a long discussion of the
benefits/drawbacks of using alloca. I read it with interest, but
didn't save it and now that I really want to know more I find that I
didn't save it. Did anyone keep an archive of that discussion? Can
you point me to it/share it with me.
I am specifically interested about alloca on MIPS cpus.
g.
George Hartzell (303) 492-4535
MCD Biology, University of Colorado-Boulder, Boulder, CO 80309
hartzell@Boulder.Colorado.EDU ..!{ncar,nbires}!boulder!hartzell
-----------------------------
From: Doug Gwyn <gwyn@smoke.brl.mil>
Subject: Re: UNIX history made easy
Date: 19 Oct 89 11:19:47 GMT
To: unix-wizards@sem.brl.mil
In article <10027@alice.UUCP> andrew@alice.UUCP (Andrew Hume) writes:
-this strand about ken is silly enough without me adding to it
-but ken is famous for more than unix. he did some important
-work early on (1960's) with regular expressions, ...
Yup. He's also famous in the world of computer chess.
-----------------------------
From: Doug Gwyn <gwyn@smoke.brl.mil>
Subject: Re: What SHOULD go in the kernel
Date: 19 Oct 89 11:25:10 GMT
To: unix-wizards@sem.brl.mil
In article <3596@frame.UUCP> eeg@frame.UUCP (Eric Griswold) writes:
> If, after this much thought, there still is no way to implement it as
>a user process, consider putting it in the kernel.
But first, think carefully about what service it is in GENERAL terms
that the kernel is not providing, and design an elegant implementation
that provides the GENERAL service, rather than just the specific need
that prompted the issue.
Of course, we were talking originally about device drivers.
My advice there is to keep them as simple as possible so long as
all the legitimate uses of the device are supported.
-----------------------------
From: Chris Torek <chris@mimsy.umd.edu>
Subject: Re: BSD file system
Date: 19 Oct 89 11:08:37 GMT
To: unix-wizards@sem.brl.mil
In article <1344@accuvax.nwu.edu> rico@dehn. (Rico Tudor) writes:
> (1) How are permissions set on a symbolic link?
They are completely irrelevant---nothing ever uses them. (You can view
them with lstat, or `ls -l' [which uses lstat], but the kernel ignores
them entirely.)
> (2) How are access & modification times set on a symbolic link?
As with the permissions, these are irrelevant (only the ctime matters,
and only for backups).
> (3) What purpose is served by taking the group ID of a newly
> created file from the parent directory, rather than the
> process?
Given that `the process' may be in up to 8 (4.2BSD) or 16 (4.3BSD)
groups simultaneously, there is no single correct choice based on
the process alone, hence the parent directory rule.
--
`They were supposed to be green.'
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Dave Mankins <dm@odin.think.com>
Subject: Re: BSD file system
Date: 19 Oct 89 10:03:03 GMT
Sender: news@think.com
To: unix-wizards@sem.brl.mil
In article <1344@accuvax.nwu.edu> rico@math.nwu.edu (Rico Tudor) writes:
>While porting my file archiver from System V to a DECStation 3100, the
>following questions regarding system calls have arisen:
> (1) How are permissions set on a symbolic link?
> (2) How are access & modification times set on a symbolic link?
A symbolic link is a way of making another name for a file. The
permissions of the linked-to file are the permissions used for every name
for the file. This behavior seems surprising until you realize that it is
just like hard links. The permissions on the symbolic-link are not used.
Symbolic links are just like hard links only with the ability to span
filesystems (and, sadly, without the ability to know that, when you remove
one name for a file (the target of the symbolic link) there is another name
left dangling without a reference).
> (3) What purpose is served by taking the group ID of a newly
> created file from the parent directory, rather than the
> process?
Under BSD, a process belongs to many groups at one time. Too bad they
didn't do the same thing for files.
>In Questions (1) and (2), chmod(2) and utimes(2) follow the link, which I
>don't want. I am handling Question 1 by temporarily altering the process
>"umask", but I don't like it. The 3100 runs "Ultrix", a BSD variant.
I think you'll find that your handling of question 1 actually has no effect
on what people can do with the files (symlinks) so created. That is,
denying group-write privilege on the symlink, but not the target, will not
prevent group-members from writing the file.
I am curious, if you're porting this program from System-V, what System-V
function are you trying to emulate using symlinks?
david mankins (dm@think.com)
-----------------------------
From: Guy Middleton <gamiddleton@watmath.waterloo.edu>
Subject: Re: How do I set up an insulating gateway?
Date: 19 Oct 89 14:57:38 GMT
To: unix-wizards@sem.brl.mil
In article <20158@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
| In article <20149@mimsy.UUCP> I wrote:
| >>Or compile the kernel with the "ipforwarding" variable turned off, eh?
|
| >Then it would not be a gateway.
|
| What I missed was this (from the original article):
|
| >If I have a 4.3bsd (or 4.3-tahoe) machine with two IP interfaces, is
| >there any way to prevent packets from one net reaching the other? I
| >want the machine to be able to talk to either net, but nobody else
| ------
| >should be able to use it as an IP gateway. I can't think of any
| >obvious way of doing this.
|
| Such a machine is not a gateway, merely a multi-homed host. Turning
| off ipforwarding would do it.
It seems I should have been more explicit in my original query. The machine
really is on three nets, and I only want to isolate one of them. I mentioned
only two, for simplicity. Had I remembered the kernel ipforwarding variable,
I would have been more explicit. Chris's fix is actually what I was looking
for.
Thanks everybody else for reminding me about ipforwarding.
-Guy Middleton, University of Waterloo gamiddleton@watmath.waterloo.edu
(+1 519 885 1211 x3472) gamiddleton@watmath.uwaterloo.ca
-----------------------------
From: Brain in Neutral <bin@primate.wisc.edu>
Subject: Re: How do you tell a wizard?
Date: 19 Oct 89 16:02:08 GMT
Sender: bin@primate.wisc.edu
To: unix-wizards@sem.brl.mil
From article <955@umb.umb.edu>, by campbell@umb.umb.edu (Jim Campbell):
> Some years ago, I saw a description of how to tell the
> level of the individual with respect ot their UNIX knowledge.
> ie: NOVICE:
> Calls vi vye
> etc
I have *never* heard *anyone* call "vi" vee-eye. Including wizards.
Paul DuBois
dubois@primate.wisc.edu
-----------------------------
From: Steve Friedl <friedl@bang.uucp>
Subject: Re: Job Control (a la csh/ksh) from within C
Date: 17 Oct 89 03:13:03 GMT
Followup-To: comp.unix.wizards
To: unix-wizards@sem.brl.mil
> The /proc filesystem and associated ioctls has existed for quite some
> time. You should be seeing more commercial UNIX implementations with
> such facilities. (Silicon Graphics has been shipping one for over a
> year now.)
The AT&T 3B15 has had /proc on its Sys V Rel 3.1 machines for over
a year as well. Too bad we don't have truss :-(.
Steve
--
Stephen J. Friedl / Software Consultant / Tustin, CA / + 714 544 6561
3B2-kind-of-guy / {attmail uunet}!vsi!friedl / friedl@vsi.com
Replies to vsi!bang!friedl might get lost, please use vsi!friedl
-----------------------------
From: Jim Burwell <jimb@faatcrl.uucp>
Subject: GNU tar
Date: 19 Oct 89 16:46:47 GMT
Keywords: tar tape sun 1/4 inch SCSI
To: unix-wizards@sem.brl.mil
Hi there!
Has anyone gotten GNU tar's multivolume option working on a 1/4" SCSI tape
drive ? I'm trying to use this option on a Sun 3/160.. It seems like it
doesn't know when it hits the end of the tape, and mistakes it for an IO error.
I'd like to know if anyone has a fix for this, before I start hacking :-).
Bye
Jim
--
+------------------------------------------------+--------------------------+
| James S. Burwell | |
| | "UseNet...A text network |
| UUCP: | in a binary world" - Me |
| ...!{ames!netsys|rutgers}!faatcrl | |
| !jimb | "How do you say |
| . | 'multitasking' in |
| Internet: . | MS-DOSish? Network |
| // jimb@faatcrl.UUCP . ** | File Server!" - Me |
| // . **** | |
| \\ // GEnie: Airwarior: . .** | <reserved for future> |
| \X/ JIMBURWELL Techrat . | <expansion.... > |
+------------------------------------------------+--------------------------+
-----------------------------
From: Chip Salzenberg <chip@ateng.com>
Subject: Re: How do you tell a wizard?
Date: 19 Oct 89 21:17:05 GMT
Followup-To: talk.bizarre,misc.test
To: unix-wizards@sem.brl.mil
According to pyr4@psc90.UUCP (**** The Wizard ****):
>Guys haven't you got anything better to talk about, after all who really
>cares about, "How do you tell a wizard?", I don't. I get a little sick
>of reading these reams of garbage. Hold the flames.
>
>| Ted Wisniewski UUCP: uunet!unh!psc90!pyr4 or: dartvax!psc90!pyr4 |
>| Plymouth State College |
>| Plymouth NH, 03264 If I spoke for PSC they would pay me,|
>| But instead I pay them. |
GEE, WIZARD! IS THAT YOUR REAL NAME? BOY IT REALLY GETS ME MAD LIKE YOU
WHEN PEOPLE TALK ABOUT THINGS I DON'T UNDERSTAND. BUT I GUESS YOU KNOW
THAT. :-) :-)
AND IT REALLY FROSTS MY SHORTS (HA! HA! THAT'S SO FUNNY) WHEN PEOPLE FLAME
ME JUST BECAUSE I FLAME THEM. EVEN WHEN I TELL THEM NOT TO. THEIR STUPID,
ARE'NT THEY?
--
BIFF
BIFF@PSUVM
BIFF.BIFFSON@CUP.PORTAL.COM
-----------------------------
From: "Blair P. Houghton" <bph@buengc.bu.edu>
Subject: Re: How do you tell a wizard?
Date: 20 Oct 89 00:24:09 GMT
Followup-To: comp.unix.wizards
To: unix-wizards@sem.brl.mil
In article <1019@psc90.UUCP> pyr4@.UUCP (**** The Wizard ****) writes:
^^^^^^^^^^^^^^^^^^^^^^
I doubt this mightily.
>Guys haven't you got anything better to talk about, after all who really
>cares about, "How do you tell a wizard?", I don't. I get a little sick
>of reading these reams of garbage. Hold the flames.
That depends...
Put the following in a file named ~pyr4/News/comp/unix/wizards/KILL
/tell a wizard/:j
and stop being so intolerant.
--Blair
"If you can identify the
problem, then what's the
problem? You don't know
how to form the solution?
...there is no problem other
than ignorance, therefore."
-----------------------------
From: George Miler <miler@cscosl.ncsu.edu>
Subject: Disk drivers needed: RQDX2, RD5N, RX50
Date: 19 Oct 89 14:07:29 GMT
Sender: news@ncsuvx.ncsu.edu
Posted: Thu Oct 19 10:07:29 1989
To: unix-wizards@sem.brl.mil
I am looking for UNIX 7 drivers for a RQDX2 controller, a RD5N
hard drive, and a RX50 Floppy drive. If anyone happens to stumble
across such items, please let me know. We have several pdp-11's
with UNIX 7 but no method of using secondary storage. Thanks for
any help.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
George B. Miler North Carolina State University
miler@cscosl.ncsu.edu {decvax, gatech}!mcnc!ncsuvx!cscosl!miler
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------------------------
From: William Bader <wbader@scarecrow.mse.lehigh.edu>
Subject: Re: GNU tar
Date: 19 Oct 89 17:53:37 GMT
Sender: news@vlsi3b15.csee.lehigh.edu
Followup-To: comp.unix.questions
To: unix-wizards@sem.brl.mil
In article <1051@faatcrl.UUCP> jimb@faatcrl.UUCP (Jim Burwell) writes:
> Has anyone gotten GNU tar's multivolume option working on a 1/4" SCSI tape
> drive ? I'm trying to use this option on a Sun 3/160.. It seems like it
> doesn't know when it hits the end of the tape, and mistakes it for an IO
error.
> I'd like to know if anyone has a fix for this, before I start hacking :-).
I have a version of pdtar that I modified to read a /etc/default/tar file
like the tar on Xenix. It can get the volume size from the file to make
multi-volume archives.
-----------------------------
From: Tom Christiansen <tchrist@convex.com>
Subject: Re: How do you tell a wizard?
Date: 19 Oct 89 16:26:59 GMT
Sender: news@convex.uucp
To: unix-wizards@sem.brl.mil
In article <955@umb.umb.edu> campbell@umb.edu (Jim Campbell) writes:
>Some years ago, I saw a description of how to tell the
>level of the individual with respect ot their UNIX knowledge.
>ie: NOVICE:
> Calls vi vye
> etc
First a minor flame, then the answer to this man's query.
I would say that a rose by any other name would still smell
as sweet. Do we not live in a pluralistic society? Judging
someone's education, intelligence, or technical expertise
based upon their particular accent is, although not atypical,
hinging upon bigoted and narrow-minded. What does it matter
if /etc/fsck is called 'fuzz-check', 'effess-check', 'fisk',
or 'effessceekay', except that some of those choices are slightly
more expedient than others? In the case of those people who
call /bin/ed "ed" and /usr/ucb/vi "vye" and /etc/fsck "fisk",
it would appear that they've chosen the path of expediency,
a common theme in natural language evolution. There is no
Royal Academy of the English Language, as exists for most of
the Romance tongues. This is a feature, not a bug. There
is no One True Way of pronouncing the words "route", "rout",
and "root"; few people not of the same geographic region
will agree on this, and to judge them as sub-intelligent because
of this is simply wrong.
There, that said, I present you with what may be the text
you are looking for.
--tom
.po 1i
.he ''Unix Hierarchy''
.sz 10
.lp
.nf
.na
.b "NAME DESCRIPTION AND FEATURES"
beginner - insecure with the concept of a terminal
- has yet to learn the basics of \fIvi\fR
- has not figured out how to get a directory
- still has trouble with typing <RETURN> after each line of inpu
t
novice - knows that \fIls\fP will produce a directory
- uses the editor, but calls it `vye'
- has heard of \fIC\fR but never used it
- has had his first bad experience with \fIrm\fR
- is wondering how to read his mail
- is wondering why the person next to him seems to like Unix so
very much
user - uses \fIvi\fR and \fInroff\fR, but inexpertly
- has heard of regular-expressions but never seen one.
- has figured out that `-' precedes options
- has attempted to write a \fIC\fR program and has decided to st
ick with
pascal
- is wondering how to move a directory
- thinks that \fIdbx\fR is a brand of stereo component
- knows how to read his mail and is wondering how to read the ne
ws
knowledgable - uses \fInroff\fR with no trouble, and is beginning
user to learn \fItbl\fR and \fIeqn\fR
- uses grep to search for fixed strings
- has figured out that \fImv\fR will move directories
- has learned that \fIlearn\fR doesn't help
- somebody has shown him how to write C programs
- once used \fIsed\fR to do some text substitution
- has seen \fIdbx\fR used but does not use it himself
- thinks that \fImake\fR is only for wimps
expert - uses \fIsed\fR when necessary
- uses macros in \fIvi,\fR uses \fIex\fR when neccesary
- posts news at every possible opportunity
- write \fIcsh\fR scripts occasionally
- write \fIC\fR programs using \fIvi\fR and compiles with \fIcc\
fR
- has figured out what `&&' and `||' are for
- thinks that human history started with '!h'
hacker - uses \fIsed\fR and \fIawk\fR with comfort
- uses undocumented features of \fIvi\fR
- write \fIC\fR code with `cat >' and compiles with '!cc'
- uses \fIadb\fR because he doesn't trust source debuggers
- can answer questions about the user environment
- writes his own \fInroff\fR macros to supplement std. ones
- write scripts for Bourne shell (/bin/sh)
- knows how to install bug fixes
guru - uses \fIm4\fR and \fIlex\fR with comfort
- writes assembly code with `cat >'
- uses \fIadb\fR on the kernel while system is loaded
- customizes utilities by patching the source
- reads device driver source with his breakfast
- can answer any unix question after a little thought
- uses \fImake\fR for anything that requires two or more distinc
t commands to
achieve
- has learned how to breach security but no longer needs to try
wizard - writes device drivers with `cat >'
- fixes bugs by patching the binaries
- can answer any question before you ask
- writes his own \fItroff\fR macro packages
- is on first-name basis with Dennis, Bill, and Ken
Tom Christiansen {uunet,uiucdcs,sun}!convex!tchrist
Convex Computer Corporation tchrist@convex.COM
"EMACS belongs in <sys/errno.h>: Editor too big!"
-----------------------------
From: Tim Wood <tim@binky.sybase.com>
Subject: Re: How do you tell a wizard?
Date: 19 Oct 89 21:00:23 GMT
Sender: news@sybase.sybase.com
To: unix-wizards@sem.brl.mil
In article <9100017@m.cs.uiuc.edu> carey@m.cs.uiuc.edu writes:
>
>So the unix wizard's magic incantation is "that depends..." ???
>
>This approach can be really annoying... ask someone a question, their
>response is "that depends, is it [ any of the following things ]"
>
>So you spend half an hour going over all the "that depends" and it turns
>out the guy is just stalling to cover up his answer which is "I dunno"
>
>I would rather answer a question, "in most circumstances (or in my experience)
>this is most likely to be the answer" ... (then give an answer which is
>probably wrong anyway), then say " but that depends on this and that,
>and the other thing, blah, blah, blah.....
Your preferred response may seem friendlier, but it conveys less information.
Someone saying "it depends" is explicitly asking you for more information,
so that they can give a more coherent answer. They are also implicitly
giving you information. "It depends" sometimes means "did you check...?".
Just knowing some of the contingencies of the problem can greatly aid
your understanding. Even if the answer is not deposited directly in
your hand, you may gain enough information to answer it yourself.
Generalized answers don't tell you why they are correct or reveal
incorrect reasoning when they are wrong. So you come away with
incomplete or incorrect knowlege.
When it comes to computers, there are very few one-sentence answers.
Ability to leverage the input of others to solve your own problems is
a major determiner of success.
-TW
Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500
tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim
Voluntary disclaimer: This message is solely my personal opinion.
It is not a representation of Sybase, Inc. OK.
-----------------------------
From: John Nagle <nagle@well.uucp>
Subject: Re: What SHOULD go in the kernel
Date: 19 Oct 89 16:20:34 GMT
Keywords: device drivers
To: unix-wizards@sem.brl.mil
One could argue that device drivers don't belong in the kernel
at all. With reasonable hardware support, no loss in protection is
implied by this. The operating system must provide the mechanisms
to map one peripheral's I/O space into the space of the driver process,
and the memory management hardware must mediate accesses initiated by
the device itself (whether "DMA", "bus master operation", or "channel
program execution").
Systems with these capabilities include IBM mainframes under VM, and
Apollo machines under Domain when equipped with the add-on box for user
supported peripherals.
One also needs something like named pipes for communication between
applications and device drivers. This intercommunication mechanism must
include 1) bidirectional I/O 2) out-of-band control messages ("IOCTLs"),
3) the capability of one end to verify the identity and security status
of the other end, and 4) the ability of one end to detect termination
of the other end.
With capabilities like this, you can kick the device drivers,
terminal handling, networking, and file system out of the kernel.
Unfortunately, UNIX isn't designed to work this way, and the
success of UNIX has resulted in the decline of hardware support for
this sort of thing. The result is the bloated kernels of today.
John Nagle
h
-----------------------------
From: P E Smee <exspes@gdr.bath.ac.uk>
Subject: Re: How do you tell a wizard?
Date: 19 Oct 89 15:05:18 GMT
To: unix-wizards@sem.brl.mil
You can always tell a wizard.
You just can't tell him much...
--
Paul Smee | JANET: Smee@uk.ac.bristol
Computer Centre | BITNET: Smee%uk.ac.bristol@ukacrl.bitnet
University of Bristol | Internet: Smee%uk.ac.bristol@nsfnet-relay.ac.uk
(Phone: +44 272 303132) | UUCP: ...!mcvax!ukc!gdr.bath.ac.uk!exspes
-----------------------------
From: Maarten Litmaath <maart@cs.vu.nl>
Subject: Re: remote access to edit buffer
Date: 19 Oct 89 19:23:58 GMT
To: unix-wizards@sem.brl.mil
eliot@phoenix.Princeton.EDU (Eliot Handelman) writes:
\... if I kill the edit job how do I
\ensure an autosave? What's going on when vi autosaves when the machine
\crashes?
kill -HUP or -TERM will make vi preserve the buffer.
From inside vi the `:pre' command will.
When the system has crashed and is rebooted, /usr/lib/ex*preserve is
run from /etc/rc to save ex/vi temporaries in /tmp, after which /tmp
normally is cleared.
--
A symbolic link is a POINTER to a file, | Maarten Litmaath @ VU Amsterdam:
a hard link is the file system's GOTO. | maart@cs.vu.nl, mcsun!botter!maart
-----------------------------
From: Peter da Silva <peter@ficc.uu.net>
Subject: Re: What SHOULD go in the kernel
Date: 20 Oct 89 01:51:19 GMT
To: unix-wizards@sem.brl.mil
In article <17166@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II)
writes:
> I don't have trouble with the first part, but discouraging paging
> the kernel is kinda wasteful the way kernels keep bloating.
So redefine what the "kernel" is, like Mach does.
--
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"You can tell when a USENET discussion is getting old when one of the 'U`
participants drags out Hitler and the Nazis" -- Richard Sexton
-----------------------------
From: Roland McGrath <mcgrath@paris.berkeley.edu>
Subject: Re: How do you tell a wizard?
Date: 20 Oct 89 02:44:58 GMT
Sender: news@pasteur.berkeley.edu
To: unix-wizards@sem.brl.mil
Guys haven't you got anything better to talk about, after all who really
cares about, "How do you tell a wizard?", I don't. I get a little sick
of reading these reams of garbage. Hold the flames.
Real wizards no longer have anything better to do.
--
Roland McGrath
Free Software Foundation, Inc.
roland@ai.mit.edu, uunet!ai.mit.edu!roland
-----------------------------
From: Jim Rosenberg <jr@oglvee.uucp>
Subject: Re: Help! Altos 5.3.1 fork is failing!
Date: 19 Oct 89 16:14:29 GMT
To: unix-wizards@sem.brl.mil
In article <2296@hcr.UUCP> larry@zeus.UUCP (Larry Philps) writes:
>Getcpages, is indeed get "contiguous" physical pages. There are parts of the
>paging system on some processors that require this. The complaint about a
>failure on 1 page simply means that ALL RAM was being used when the fork
>appeared and the system needed a page to hold page tables or the like.
>
>Now, for some reason unknown to me, in fork (procdup actually), dupreg is
>called with arguments that specify that it is not to sleep. I couldn't come
>up with any sensible reason why this had to be, so I changed the call to
>allow sleeps. The fork failure problems simply went away, and no other
>problems manifested.
OK, kernel gurus, what's the word: *is there* a good reason why the call to
dupreg shouldn't sleep???
We are also running V.3.2 on a bunch of AT&T 6386en. Those machines have only
2M RAM. I know damn well that we're just on the borderline of what's doable
with that little memory -- it's a budget issue, not a technical issue.
Although I do often suffer from the overhead of paging, I've *NEVER* seen a
fork failure on these machines. Admittedly this is V.3.2 and not V.3.1. But
I wonder if AT&T did go ahead and change the dupreg call to allow a sleep.
Can someone from AT&T comment?
I must say this, though: while I've never seen an identifiable fork failure
on one of the 6386en, I *have* seen a phenomenon which I call Kernel
Narcolepsy: the whole system just seems to fall asleep now and then. I had
one machine a couple of months ago that had an extremely sick disk. To make
sure another machine didn't have the problem I intentionally loaded it with
enough continuous compiles of our database language (Progress) to cause solid
thrashing. Every now and then the thrashing would just stop. After about 5
minutes it would pick up again. I don't know for a fact that it was really
sleeping: it could have been a kind of beat frequency where the processes
just happened to hit on the same pages. But I did suffer one definite case
where the whole system went to sleep and even though characters would echo I
could get no response from any getty and the system was definitely just plain
stuck. This took a full reboot, fsck found minor damage, etc. etc.
So I guess the question is this: If the dupreg call from fork allows sleeps,
could this lead to a deadlock? Is it possible I may be seeing this on V.3.2?
If the dupreg call *can be* safely changed to allow sleeping then my Altos
problem is a flat out case of a bug in their System V.3.1. If it *can't*
safely be changed, then as I understand the situation V.3 DOES NOT RELIABLY
IMPLEMENT VIRTUAL MEMORY!! Is it not true that pages are freed by an
asynchronous kernel process? Is it not true that, given the indeterminate way
things work in UNIX, one cannot absolutely guarantee when this process will
run? If you can't allow a sleep from fork in dupreg then the only way of
guaranteeing that fork won't fail is to guarantee that you don't page. I.e.
if you page, you run a certain risk that forks will fail no matter how much
swap space you have. The only way to guarantee fork will never fail is to
guarantee you don't page. I.e. don't really exercise virtual memory. I.e.
V.3 virtual memory is NOT RELIABLE because if you use it you may trigger fork
failures.
Please tell me it ain't so!!!!!
--
Jim Rosenberg pitt
Oglevee Computer Systems >--!amanue!oglvee!jr
151 Oglevee Lane cgh
Connellsville, PA 15425 #include <disclaimer.h>
-----------------------------
From: "Brandon S. Allbery" <allbery@ncoast.org>
Subject: Re: How do you tell a wizard?
Date: 20 Oct 89 01:44:15 GMT
Followup-To: comp.unix.wizards
To: unix-wizards@sem.brl.mil
As quoted from <26894@prls.UUCP> by gordon@prls.UUCP (Gordon Vickers):
+---------------
| Wizard:
| - writes device drivers with 'cat >' - writes his own troff macro
| - fixes bugs by patching the binaries. packages
| - can answer any question before - is on first-name basis with
| you ask. Dennis, Bill, and Ken.
+---------------
Well, I've got two of the requisites... does that make me half a wizard, or a
half-*ssed wizard? ;-)
++Brandon
--
Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG
uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp
161-7070 (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie), comp-sources-misc@backbone
[comp.sources.misc-related mail should go ONLY to comp-sources-misc@<backbone>]
*Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*
-----------------------------
From: "Brandon S. Allbery" <allbery@ncoast.org>
Subject: Re: Help! Altos 5.3.1 fork is failing!
Date: 20 Oct 89 02:03:09 GMT
Followup-To: comp.unix.i386
To: unix-wizards@sem.brl.mil
As quoted from <506@oglvee.UUCP> by jr@oglvee.UUCP (Jim Rosenberg):
+---------------
| We just recently "upgraded" [sic] an Altos 2000 from Xenix 5.2c to UNIX 5.3d.
| per-user limit is 30, and we're getting fork failures where that's not
exceeded
| either. The system error reporting is filled with messages like this:
+---------------
Ah, so someone else *is* getting those little buggers.
As far as I can tell, "fork failed"s happen when memory is mostly full and
something wants to fork and for some stupid reason Altos 5.3[a-d][DT][0-9]
doesn't want to page anything out to make more room in core even though it can
do so. I have some "sar" output that corroborates this, "fork failed" happens
when a process tries to fork and there are < 100 free 512-byte (I think that's
the units sar uses, I need to check) chunks of memory.
I plan to ram this down Altos T/S's collective throat, since they haven't
fixed it in 5.3dT1 and I reported it in 5.3bT1 (3 upgrades have gone by so
far...).
++Brandon, for this message speaking as the tech guru of telotech, inc.
--
Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG
uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp
161-7070 (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie), comp-sources-misc@backbone
[comp.sources.misc-related mail should go ONLY to comp-sources-misc@<backbone>]
*Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*
-----------------------------
From: Dick Dunn <rcd@ico.isc.com>
Subject: Re: What SHOULD go in the kernel
Date: 19 Oct 89 22:01:05 GMT
To: unix-wizards@sem.brl.mil
jfh@rpp386.cactus.org (John F. Haugh II) writes:
> ...pplacewa@antares.bbn.com (Paul W. Placeway) writes:
> >...Also,
> >most kernels won't do VM on themselves (for several _good_ reasons
> >:-) ),...
> ... discouraging paging
> the kernel is kinda wasteful the way kernels keep bloating.
Gack. John is right that kernels keep expanding (rapidly!), and that it
does waste memory (real memory which costs real $) to keep all that dreck
resident. The kernels of the Brave New Open International World are going
to be FAT! More accurately, they won't be kernels even in any reasonable
stretch (!) of the term.
But do we have to accept that? For the problems caused by bloating
kernels, at least we can say the problems might be slowing the growth a
bit. I'm afraid that if you let the "kernel" page, you really open it up
wide--there's no reason to think twice about putting EVERYthing in the
kernel and turning it into another MVS.
Is there any way to induce a change in viewpoint? Why not change the
perception of the problem from "we need a way to handle an ever-expanding
kernel" to "we need to stop the expansion of the kernel." (Yes, I know, it
doesn't work quite that way--you need to restructure it dramatically and
throw large pieces OUT of the kernel.)
Also, since as John pointed out there's only part of the kernel that could
be pageable, why not call the non-pageable part "the kernel" and put the
pageable parts in something called "user-level code"? The only loss I see
in doing this is that there will be people who won't be able to stroke
their egos by calling themselves "kernel programmers". (Of course, they're
just the folks *I* don't want messing around in the kernel.)
--
Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870
...No DOS. UNIX.
-----------------------------
From: Bruce Barnett <barnett@crdgw1.crd.ge.com>
Subject: Re: How do you tell a wizard?
Date: 20 Oct 89 14:22:21 GMT
Sender: news@crdgw1.crd.ge.com
To: unix-wizards@sem.brl.mil
>I have *never* heard *anyone* call "vi" vee-eye. Including wizards.
Wrong crowd, I guess. :-)
According to the BSD manual, written by William Joy and Mark Horton,
"vi" is pronounced vee-eye.
Barnett's first rule of wizardry detection: :-)
"Real wizards don't RTFM, they WTFM!"
--
Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
-----------------------------
From: Doug Gwyn <gwyn@smoke.brl.mil>
Subject: Re: How do you tell a wizard?
Date: 20 Oct 89 15:51:16 GMT
To: unix-wizards@sem.brl.mil
In article <917@uakari.primate.wisc.edu> bin@primate.wisc.edu writes:
>I have *never* heard *anyone* call "vi" vee-eye. Including wizards.
"I guess you don't know any wizards, then."
-----------------------------
From: Matt Crawford <matt@oddjob.uchicago.edu>
Subject: Re: What SHOULD go in the kernel
Date: 20 Oct 89 16:26:25 GMT
Sender: news@tank.uchicago.edu
To: unix-wizards@sem.brl.mil
Dick Dunn:
) I'm afraid that if you let the "kernel" page, you really open it up
) wide--there's no reason to think twice about putting EVERYthing in the
) kernel and turning it into another MVS.
Under Elxsi's OS, "embos", even the page tables can be paged. Even the
page tables for the paged-out page table entries can be paged out. (But
it does stop at the third level of page table entries.)
________________________________________________________
Matt Crawford matt@oddjob.uchicago.edu
-----------------------------
From: voss@s.cs.uiuc.edu
Subject: TTY, speak now, or forever
Date: 20 Oct 89 16:40:40 GMT
Nf-ID: #N:s.cs.uiuc.edu:216100015:000:778
Nf-From: s.cs.uiuc.edu!voss Oct 19 23:59:00 1989
To: unix-wizards@sem.brl.mil
I am just starting a small project to write a "tty" driver for a research
operating system. I got the word today that I should NOT clone the BSD/SYSV
versions. Quote "no IOCTLs". Basically, I have an almost clean slate to
work with. Functionally, I intend to base my work roughly on BSD `man 4 tty`.
(Because a friend will be implementing a Unix compatibility mode on top.)
The questions:
Is there anything NOT in `man 4 tty` that you think I should put in my driver?
Is there anything IN `man 4 tty` you think I should NOT put in my driver?
Why?
Feel free to get slightly crazy, I'ld rather discard, than neglect an idea.
(WARNING: You may be using my driver someday, better speak up now! ;-)
If you want to get real crazy, or real long. INTERNET: voss@cs.uiuc.edu
-----------------------------
From: "Steven M. Schultz" <sms@wlv.imsd.contel.com>
Subject: Re: BSD file system
Date: 20 Oct 89 12:33:11 GMT
Sender: news@wlbr.imsd.contel.com
To: unix-wizards@sem.brl.mil
>In article <20258@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
>>In article <1344@accuvax.nwu.edu> rico@dehn. (Rico Tudor) writes:
>> (3) What purpose is served by taking the group ID of a newly
>> created file from the parent directory, rather than the
>> process?
>
>Given that `the process' may be in up to 8 (4.2BSD) or 16 (4.3BSD)
>groups simultaneously, there is no single correct choice based on
>the process alone, hence the parent directory rule.
Another way of looking at the multi-group capability is that
a process has a main/primary group - the one listed in the
password file and multiple secondary groups as determined by
the group file. It makes sense to me to use the primary
group for purposes of file ownership. Directories such as /tmp
typically are owned by groups of which users are not members, this
has led to surprises at least once for me.
Steven M. Schultz
sms@wlv.imsd.contel.com
-----------------------------
From: Rich Salz <rsalz@bbn.com>
Subject: How to write a new Unix-like kernel
Date: 20 Oct 89 15:04:14 GMT
To: unix-wizards@sem.brl.mil
In <17166@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes:
> ... discouraging paging
> the kernel is kinda wasteful the way kernels keep bloating.
Take this sentence backwards, and it becomes a feature: since the kernel
can't page, you can't puff lots of stuff into it. This has forced a
certain economy of design (phrase lifted from one of the Unix papers, read
them all and find out which one -- it'll be good for you) that has
resulted in the initial success of Unix lo these many years ago.
I don't think this bloat is necessary, and as Dick Dunn has implied in
<1989Oct19.220105.10185@ico.isc.com>, if you make it possible to have the
kernel page, then all you do is make it possible to have every
semi-competent bozo put everything they want in the kernel. Goodbye
tasteful and understandable set of features, hello [VM][MV]S.
On the other hand, if you let the kernel page, then you can take all the
stuff that doesn't page and call that the "real" kernel. As long as it's
paging the other parts, put them in user space, and give users the
opportunity to put their own code in for their programs.
I don't expect someone whose .signature says that Mach stands for
messages are crufty hacks will like this design very much, but I'd
rather avoid bloat, myself. (Do I have to say that this is intended
to be a mild tweak and not one of the famous "Usenet ad hom.
attacks"?)
/r$
--
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
Use a domain-based address or give alternate paths, or you may lose out.
-----------------------------
From: Mike Marshall <hubcap@hubcap.clemson.edu>
Subject: Re: How do you tell a wizard?
Date: 20 Oct 89 14:00:13 GMT
To: unix-wizards@sem.brl.mil
How do you tell a wizard? It is apparent that s/he has RTFMed.
*
* An Introduction to Display Editing with Vi
*
*
* William Joy
...
*
* 1. Getting started
*
* This document provides a quick introduction to vi. (Pronounced
* vee-eye.) You...
*
:-) :-)...
-Mike hubcap@clemson.edu
-----------------------------
From: jim frost <madd@world.std.com>
Subject: fork affecting ndbm requests?
Date: 20 Oct 89 17:46:54 GMT
To: unix-wizards@sem.brl.mil
I have an application which opens an ndbm database read-only and forks
several children to do a lot of queries on that database. I get
periodic dbm_fetch() failures if I do this when I am certain the
records exist. This does not happen if the application does all of
the fetches unparallelized, but there are performance losses.
Is there some reason I should not fork after opening the database?
jim frost
software tool & die
madd@std.com
-----------------------------
From: Thomas Truscott <trt@rti.uucp>
Subject: Re: What SHOULD go in the kernel
Date: 20 Oct 89 14:07:07 GMT
Keywords: device drivers
To: unix-wizards@sem.brl.mil
> One could argue that device drivers don't belong in the kernel
> at all.
As device drivers continue to bloat in number and size,
and as hardware becomes more sophisticated,
this argument gains strength.
The NeXT Mach 1.0 operating system supports loadable device drivers.
The MIDI interface, and other things like a SLIP (RS-232 TCP/IP) driver,
are done that way. The driver is dynamically linked to the kernel,
at which point it functions like an ordinary driver.
It can later be dynamically unlinked. Pretty slick.
This makes kernel relinking unnecessary (indeed it is not supported).
Unfortunately, vanilla NeXT 1.0 does not have documentation
(or needed tools it seems) for writing one's own loadable driver.
We dearly need this feature to add our favorite device driver (Freedomnet)
to the NeXT box. Perhaps this will be fixed in a newer release?
Tom Truscott
-----------------------------
From: Chris Torek <chris@mimsy.umd.edu>
Subject: Re: BSD file system
Date: 20 Oct 89 20:49:15 GMT
To: unix-wizards@sem.brl.mil
In article <38688@wlbr.IMSD.CONTEL.COM> sms@WLV.IMSD.CONTEL.COM
(Steven M. Schultz) writes:
>Another way of looking at the multi-group capability is that
>a process has a main/primary group - the one listed in the
>password file and multiple secondary groups as determined by
>the group file.
The rest of the system disagrees with your interpretation. In fact,
the only reason there is a group ID in the password file is because
there was one there before, and no one felt like changing the format
of /etc/passwd at the time.
--
`They were supposed to be green.'
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Barry Margolin <barmar@kulla>
Subject: Re: BSD file system
Date: 20 Oct 89 21:10:28 GMT
Sender: news@think.com
To: unix-wizards@sem.brl.mil
In article <38688@wlbr.IMSD.CONTEL.COM> sms@WLV.IMSD.CONTEL.COM.UUCP (Steven M.
Schultz) writes:
>In article <20258@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
>>Given that `the process' may be in up to 8 (4.2BSD) or 16 (4.3BSD)
>>groups simultaneously, there is no single correct choice based on
>>the process alone, hence the parent directory rule.
> It makes sense to me to use the primary
> group for purposes of file ownership. Directories such as /tmp
> typically are owned by groups of which users are not members, this
> has led to surprises at least once for me.
This is presumably why SunOS (and other BSD systems?) supports BOTH types
of default group ownership. There's a bit in the directory mode that
specifies whether file groups should come from the directory or from the
process. /tmp is a good example of a directory whose files should inherit
the group from the process (although in most cases /tmp files should
probably have null group and world access anyway). But a directory shared
by a group of users might want the files to be owned by the group, even
though that isn't their primary group. For example, at our site, all
regular employees are in primary group "staff", but there are directories
whose files should only be writable by users in particular groups.
At least the way we use the system, /tmp-style group ownership seems to be
in the minority. Spool directories are the only other cases I can think of
offhand. There are few other places where users create files in
directories owned by groups to which they don't belong (directories tend
not to be world-writable -- in fact, were there no other bit available, the
world-write bit could have been used as a kludgey way to implement the
aforementioned flag).
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
-----------------------------
From: kirk reiser <kirk@braille.uwo.ca>
Subject: need help with very old uucp
Date: 20 Oct 89 20:05:36 GMT
To: unix-wizards@sem.brl.mil
I have a very old uucp package on my machine. I find myself needing
to be able to send a string with a space in it. My package doesn't
seem to have any accomidation for this. It doesn't seem to even be
able to send an octal after a backslash. I would like to know if anyone
else out there has had this problem and found an answer.
thank you for any help to may be able to provide!
Kirk
--
Kirk Reiser The Computer Braille Facility
phone: 519-661-3061 University of Western Ontario
email: kirk@braille.uwo.ca rm-H045 Health Sciences Addition
bitnet: kirk@braille.uwocc1 London, Ont. N6A 5C1
-----------------------------
From: Jim Campbell <campbell@umb.umb.edu>
Subject: Re: How do you tell a wizard?
Date: 20 Oct 89 15:31:19 GMT
To: unix-wizards@sem.brl.mil
You don't tell a wizard,
s/he already knows ;-)
-----------------------------
From: John Nagle <nagle@well.uucp>
Subject: Re: Shadow Disks
Date: 20 Oct 89 16:11:02 GMT
To: unix-wizards@sem.brl.mil
Tandem has more experience with shadow disks than anybody else, so
examining their system is probably worthwhile. They support such things
as network shadowed disks, including resynchronization after a fault over
the network. They also support distributed fault-tolerant multiprocessing
over their net, of course.
John Nagle
-----------------------------
From: News system owner ID <news@bbn.com>
Subject: Re: What SHOULD go in the kernel
Date: 20 Oct 89 22:00:35 GMT
To: unix-wizards@sem.brl.mil
jfh@rpp386.cactus.org (John F. Haugh II) writes:
< The primary restriction against a paging kernel is keeping the
< paging code from being paged ;-). After that, satisfying real-time
< constraints, etc. will yield a collection of pages which must
< be locked in memory as well. What should be left in the list
< of locked pages should only be lower halves of device drivers,
< the VM manager, the pager, and the global data required by those.
<
< Massive tables, seldom used device drivers, and one-time
< initialization code should all be candidates for the pager.
< I paid for the memory, and damnit, I want to use it.
Actually, I guess there are two ways of looking at this. The first is
you want your kernel to stay up even if your swap device fails. If
true, then there is obviously no way to let part of your kernel swap
out.
On the other hand, if you consider the machine dead when a swap device
dies, then swapping out the kernel is fair enough. If your kernel
could do this, then demand-loadable device drivers would be less
needed (although still nice to have for other good reasons). As John
indicates, a kernel that ran this way would probably be much more
memory efficient (not a bad thing, considering some of todays kernels).
A sort of work-around for this is to have a bunch of user-level kernel
processes that do most of the work (like tty processing), and let them
get paged and swapped out when not in use. This is even a performance
win for some things (tty drivers, among others).
-- Paul <PPlaceway@bbn.com>
-----------------------------
From: "S. P. Gilgut" <gilgut@cg-atla.uucp>
Subject: Re: How do you tell a wizard?
Date: 16 Oct 89 13:24:30 GMT
To: unix-wizards@sem.brl.mil
In article <4846@tekcrl.LABS.TEK.COM> terryl@tekcrl.LABS.TEK.COM writes:
>In article <69985@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes:
>>Another interesting observation on spotting wizards is:
><stuff deleted>
>> (Unfortunately, there are a hell of a lot of people that think
>> that because they installed unix on a pc or a sun workstation
>> they are automatically wizards.)
>
> Well, I don't have any experience with this, so I can't comment on it...
Ahh - Real Wizards *don't* do PCs!
--
S. P. Gilgut, Agfa Compugraphic Div; Wilmington, Mass. (508)658-5600 X5277
{uunet!ginosko,decvax}!cg-atla!gilgut (Work) R & D Computer Center
{uunet!ginosko,cg-atla}!wizvax!spg (Home)
if (inmail) add_Enquirer_headline()
-----------------------------
From: Bevis Ip <ip@me.utoronto.ca>
Subject: Re: How do you tell a wizard?
Date: 21 Oct 89 00:54:22 GMT
To: unix-wizards@sem.brl.mil
In article <917@uakari.primate.wisc.edu> bin@primate.wisc.edu writes:
>I have *never* heard *anyone* call "vi" vee-eye. Including wizards.
Even our chinese scholar who onlys know a few essential Unix commands to
survive and quits "vi" by typing control-Z learned to call "vi" vee-eye!
Gee your "wizards" are welcome to come up north and talk with our chinese
scholar.
-----------------------------
From: Chuck Karish <karish@forel.stanford.edu>
Subject: Default group IDs (was: Re: BSD file system)
Date: 21 Oct 89 01:30:34 GMT
Sender: USENET News System <news@med.stanford.edu>
To: unix-wizards@sem.brl.mil
In article <38688@wlbr.IMSD.CONTEL.COM> sms@WLV.IMSD.CONTEL.COM.UUCP
(Steven M. Schultz) wrote:
>>In article <20258@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
>>>In article <1344@accuvax.nwu.edu> rico@dehn. (Rico Tudor) writes:
>>> (3) What purpose is served by taking the group ID of a newly
>>> created file from the parent directory, rather than the
>>> process?
>>
>>Given that `the process' may be in up to 8 (4.2BSD) or 16 (4.3BSD)
>>groups simultaneously, there is no single correct choice based on
>>the process alone, hence the parent directory rule.
Another reason is that it makes it practical to explain to users how
group IDs are assigned. There's no standard UNIX utility that tells me
what my effective group ID is.
> Another way of looking at the multi-group capability is that
> a process has a main/primary group - the one listed in the
> password file and multiple secondary groups as determined by
> the group file. It makes sense to me to use the primary
> group for purposes of file ownership. Directories such as /tmp
> typically are owned by groups of which users are not members, this
> has led to surprises at least once for me.
This is fine as long as all you want from groups is a way to have
your daemons cooperate with one another.
The BSD supplementary groups system makes it possible for users to both
protect and share resources. The mechanism is easy to explain and can
be set up once for each directory tree to be shared, after which it
works transparently for users who are members of the group. The rules
are:
- Set the desired group access for the directory to be shared.
- Don't muck with your umask (must be 002).
This makes it possible for me to be a member of group `graphics' and of
group `geochem', and to share files with each group. I can do this
without having to remember to reset my effective group ID every time I
write a file in one of the shared directories. For the ultimate in
convenience, if I am the only member of my own supplementary group,
I can protect files from any group access without changing my umask or
using chmod.
As far as the /tmp example is concerned, there are problems
under the inherit-from-EGID scheme too, unless all users have the same
default group.
<->-<->->
Some computer system vendors are starting to use a system that allows
anyone to choose whether the parent directory or the effective group ID
of the process will be used in a given directory and its dependent
directories. The mechanism used is to set the set-GID bit for the
directory. If it is set, files and directories inherit their group ID
from the parent directory, and new directories have the set-GID bit on
by default. Fine so far; the user can choose on a directory-by-directory
basis whether to confirm to SVID or BSD/FIPS-151A behavior.
The problem is that the system is not robust. It requires that the user
and the programmer take extraordinary precautions to avoid resetting the
set-GID access bit for directories. Scripts and commands that
say `chmod 775 dirname' or `chmod ug=rwx,o=rx' are liable to turn off
the bit, unless the chmod utility is modified to look for it.
In C, the safe way to change access modes for a directory becomes
stat("dirname", &dirstat);
chmod("dirname", <my_modes> | (dirstat.st_gid &
(~(S_IRWXU | S_IRWXG | S_IRWXO))));
where <my_modes> is the desired set of access bits.
Since POSIX 1003.1 leaves the interpretation of the set-UID and set-GID
bits on directories up to the implementation, this approach is a good
idea anyway. Even so, under the new system for choosing defaults,
existing code that does not take these precautions can break the access
control system inadvertently. It becomes unworkably cumbersome to make
proper use of supplementary groups. Users will not notice the problem
unless they actively look for it, and files will not be protected the
way their owners think they're protected.
How else could this be handled?
- Pick one of the two styles, maybe on a per-host basis, and stick to it.
- Set the flag by a mechanism that doesn't overload an existing one.
- Replace the access control system with a more flexible and capable
(and, undoubtedly, less efficient) one.
- Have chmod() ignore requests to modify the set-UID and set-GID
bits on directories. Provide a separate function to set these bits.
Suggestions, anybody? Remember, the solution has to work for vendors
who sell to SVID shops, to BSD shops, and to the government, and should
preserve as much existing code and user experience as possible.
Chuck Karish karish@mindcraft.com
(415) 493-9000 karish@forel.stanford.edu
-----------------------------
From: David C Lawrence <tale@pawl.rpi.edu>
Subject: Re: How do you tell a wizard?
Date: 21 Oct 89 02:59:13 GMT
To: unix-wizards@sem.brl.mil
In <4588@buengc.BU.EDU> bph@buengc.BU.EDU (Blair P. Houghton) writes:
Blair> Put the following in a file named ~pyr4/News/comp/unix/wizards/KILL
Blair> /tell a wizard/:j
Blair> and stop being so intolerant.
Wizards don't make assumptions about what software someone is running.
--
(setq mail '("tale@pawl.rpi.edu" "tale@itsgw.rpi.edu" "tale@rpitsmts.bitnet"))
-----------------------------
From: Mike McNally <m5@lynx.uucp>
Subject: Re^2: using /bin/sh in make commands
Date: 20 Oct 89 18:19:36 GMT
To: unix-wizards@sem.brl.mil
david@indetech.com (David Kuder) writes:
In article <21173@adm.BRL.MIL> Leisner.Henr@xerox.com (Marty) writes:
>Often people have rules in makefiles of the form:
foo:
for i in $(DIRS); do \
(cd $$i; $(MAKE) foo); \
done
> . . .
>Which make are you using? There are way too many of these beasts.
>However, on the three that I have at hand, SunOS4, Sys5.3, UCB4.3 (the
>last two are Pyramid versions), a "make foo" stops as soon as one of
>the sub makes fails.
That seems pretty bizarre to me, but then again I'm not up on Suns and
Pyramids. My "make" won't find out about the failed children of the
spawned Bourne shell, and (barring various disgusting possibilities)
couldn't find out even if it wanted to.
>If you must avoid changing the makefile (arguably broken) if you run
>the make under a Bourne in which a 'set -e' has been done then the
>shells started by the make will inherit it. I can't test this but
>it may work.
I don't think child shells (particularly ones separated from the parent by
a "make") will inherit flags, unless your sh is a lot different than mine.
Why not
foo:
set -e \; \
for blah in blah blah blah \; \
do \
blah blah blah \;
done
--
Mike McNally Lynx Real-Time Systems
uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233
Where equal mind and contest equal, go.
-----------------------------
From: "david.e.rorke" <der@cbnewsl.att.com>
Subject: Re: Real Time UNIX (was: Re: How do you tell a wizard?)
Date: 20 Oct 89 22:05:55 GMT
To: unix-wizards@sem.brl.mil
In article <9509@june.cs.washington.edu>, ka@cs.washington.edu (Kenneth
Almquist) writes:
>
> jfh@rpp386.cactus.org (John F. Haugh II) writes:
> > I was under the impression there was a real-time UNIX from AT&T
> > as I saw references to UNIX/RT ages ago.
> >
> > Also, I saw references to MERT in the 1978 BSTJ UNIX edition.
> > Isn't this available for hosting real-time UNIX implementations?
>
> MERT stands for "Multi-Environment Real Time". UNIX/RT is just a
> later name for the same system. MERT was a structured operating
> system, in contrast to UNIX, where the kernel was one big blob.
> .
> .
> .
> MERT support for the PDP-11 was dropped primarily because if you
> wanted to run UNIX processes, native UNIX was faster. A variant of
> MERT called DMERT runs on AT&T's 3B20 Duplex machines. MERT was never
> ported to any other machines. System V picked up the process locking
> feature (see plock(2)) but not the fixed process priorities.
> Kenneth Almquist
Real time scheduling is available (or will be in a couple weeks)
in System V Release 4.0. The SVR4.0 process scheduler supports
multiple concurrent scheduling policies through a switch mechanism
(somewhat like the file system switch).
Time sharing and real time policies are provided with SVR4.0 and
the interface between generic and policy specific scheduling code
is well defined to facilitate development of additional policies
(although AT&T is not currently promising to support this kernel
interface unchanged in future releases).
The real time policy provides priority scheduling where the priority
is completely controlled by the user level application. Preemption
points have been added into long code paths in the kernel to reduce
the delay to a high priority real time process which becomes runnable
while a lower priority process is running in the kernel.
Dave Rorke
AT&T Bell Laboratories
Summit, NJ
att!attunix!der
201-522-6025
-----------------------------
End of UNIX-WIZARDS Digest
**************************POSTMASTER%DICKINSN.BITNET@cornellc.cit.cornell.edu (Postmaster) (10/22/89)
This message was automatically generated.
Your mail message could not be delivered at Dickinson College in Carlisle,
Pennsylvania because the user address was not known at our site.
Addresses at Dickinson College are of the following format:
username@DICKINSN e.g., POSTMASTER@DICKINSN
or ALLAN_J@DICKINSN
or WOLTER@DICKINSN
Usernames are typically the first 8 letters of the person's last name,
frequently with the first initial added, and occasionally with an
underscore. As a result, it would be difficult to guess someone's username.
If you do not know the address of someone at Dickinson, please send a
message to POSTMASTER@DICKINSN asking for help.
----------------------------------------------------------------------
The following diagnostic is the reason for the return:
%BNET-W-NOSUCHRCVR, receiver LEYON_C cannot be located
Returned mail follows:
----------------------
Received: From PSUVM(MAILER) by DICKINSN with Jnet id 7979
for LEYON_C@DICKINSN; Sat, 21 Oct 89 14:38 EDT
Received: by PSUVM (Mailer R2.03B) id 0966; Sat, 21 Oct 89 14:39:42 EDT
Date: Sat, 21 Oct 89 08:20:00 CDT
Reply-To: Unix-Wizards@BRL.ARPA
Sender: Unix-Wizards Mailing List <UNIX-WIZ@NDSUVM1>
From: Digital Knight in Circuit Board Armor
<PSPINLER%MKVAX1%MSUS1.BITNET@CUNYVM.CUNY.EDU>
Subject: RE: C on Directory
X-To: Unix-Wizards@BRL.MIL
To: Chris Leyon <LEYON_C@DICKINSN.BITNET>
From _Advanced_Unix_Programing_ by Marc Rochkind:
A directory has the following structure:
struct direct {
ino_t d_ino;
char d_name[DIRSIZE + 1]
} dlink;
ino_t and DIRSIZE are declared in "<sys/dir.h>"
Open/Read/Close Dir could be implemented as macros to open a file, read it with
this structure, and close it.
Patrick Spinler
pspinler%mkvax1@msus1.bitnetPOSTMASTER%DICKINSN.BITNET@cornellc.cit.cornell.edu (Postmaster) (10/22/89)
This message was automatically generated.
Your mail message could not be delivered at Dickinson College in Carlisle,
Pennsylvania because the user address was not known at our site.
Addresses at Dickinson College are of the following format:
username@DICKINSN e.g., POSTMASTER@DICKINSN
or ALLAN_J@DICKINSN
or WOLTER@DICKINSN
Usernames are typically the first 8 letters of the person's last name,
frequently with the first initial added, and occasionally with an
underscore. As a result, it would be difficult to guess someone's username.
If you do not know the address of someone at Dickinson, please send a
message to POSTMASTER@DICKINSN asking for help.
----------------------------------------------------------------------
The following diagnostic is the reason for the return:
%BNET-W-NOSUCHRCVR, receiver LEYON_C cannot be located
Returned mail follows:
----------------------
Received: From PSUVM(MAILER) by DICKINSN with Jnet id 5076
for LEYON_C@DICKINSN; Sun, 22 Oct 89 11:07 EDT
Received: by PSUVM (Mailer R2.03B) id 4463; Sun, 22 Oct 89 11:06:40 EDT
Date: Sun, 22 Oct 89 02:45:26 EST
Reply-To: UNIX-WIZARDS@BRL.MIL
Sender: Unix-Wizards Mailing List <UNIX-WIZ@NDSUVM1>
From: Mike Muuss The Moderator <Unix-Wizards-Request@BRL.MIL>
Subject: UNIX-WIZARDS Digest V8#099
X-To: UNIX-WIZARDS@BRL.MIL
To: Chris Leyon <LEYON_C@DICKINSN.BITNET>
UNIX-WIZARDS Digest Sun, 22 Oct 1989 V8#099
Today's Topics:
Re: How do you tell a wizard?
Re: UNIX history made easy
The Great Vi Controversy
Re: ksh dumping core
modem programs for Unix
Re: Help! Altos 5.3.1 fork is failing!
Xenix driver for Univision 1024 video board
Re: BSD file system
Re: Real Time UNIX (was: Re: How do you tell a wizard?)
"evils of alloca" discussion
Re: How to write a new Unix-like kernel
Re: How do you tell a wizard?
Re: BSD file system
Re: What SHOULD go in the kernel
Bug/problem in ksh88b and/or SUN OS
ksh88 problem with substring expansion using "+( )" pattern
Re: Bug/problem in ksh88b and/or SUN OS
-----------------------------------------------------------------
From: Richard O'Keefe <ok@cs.mu.oz.au>
Subject: Re: How do you tell a wizard?
Date: 21 Oct 89 05:33:42 GMT
Sender: news@cs.mu.oz.au
To: unix-wizards@sem.brl.mil
In article <89Oct20.205428edt.19392@me.utoronto.ca>, ip@me.utoronto.ca (Bevis
Ip) writes:
> In article <917@uakari.primate.wisc.edu> bin@primate.wisc.edu writes:
> >I have *never* heard *anyone* call "vi" vee-eye. Including wizards.
> Even our chinese scholar who onlys know a few essential Unix commands to
> survive and quits "vi" by typing control-Z learned to call "vi" vee-eye!
There are two separate questions: "what does the manual say the program
is to be called" and "what might a wizard actually call it". Someone
who has read and understood the vi manual might know perfectly well what
the authors wanted it to be called, but use something less printable.
Just like people pronounce MS-DOS "mess-doss" or "em ess doesn't".
Too bad the C book didn't say how to pronounce "char" or I could tell
the people who pronounce it "care" that they aren't Real Wizards (TM)
even if they _can_ write code that works.
-----------------------------
From: Malaclypse the Elder <dwc@cbnewsh.att.com>
Subject: Re: UNIX history made easy
Date: 20 Oct 89 17:03:04 GMT
To: unix-wizards@sem.brl.mil
In article <10027@alice.UUCP>, andrew@alice.UUCP (Andrew Hume) writes:
>
>
> this strand about ken is silly enough without me adding to it
> but ken is famous for more than unix. he did some important
> work early on (1960's) with regular expressions, establishing
> a formal method to transform finite-state machines into
> equivalent non-deterministic finite automata. this is related
> to the patent he holds for implementing regular expression recognisers.
its been about ten years since i took my finite state automata class
so i'm not clear about the difference between finite state machines
and finite automata, but are you referring to the method of transforming
a non-deterministic finite state automaton into a deterministic one?
it involves creating new states that are the cross products of the
states of the non-deterministic machine.
if so, i did not know that ken thompson was the "inventor" of this
method. i school, it was presented as a proof that the two are
equivalent in power.
which i guess brings me to my point. it is quite *centric (fill
in the * with anything that matches an appropriate personality) of
the people arguing about what constitutes a scientist. it is silly
to say that one is only a scientist if one knows what i know. but
there are a couple of things that are "useful" to know (in my *centric view):
scientific method and in a related way, where/how to find things out.
this is my opinion.
danny
att!hocus!dwc
-----------------------------
From: Brain in Neutral <bin@primate.wisc.edu>
Subject: The Great Vi Controversy
Date: 21 Oct 89 15:13:17 GMT
To: unix-wizards@sem.brl.mil
Ok, ok, ok, you can stop the flood of mail now.
Little did I realize what I hornet's nest I would stir up.
Anyway, my mail indicates that vee-eye is indeed the more prevalent
pronounciation, over vye (as in "curl up and die for pronouncing vi that
way" :-). There appears to be some evidence that there are regional
preferences, though of course the notorious mobility of computer professionals
would tend to mitigate that a bit.
A number of people pointed out that the vi manual says vee-eye is correct.
Actually, I've known that for over a decade, and have known it since shortly
after I heard of vi, having dug out the manual and read it cover-to-cover.
Since everyone I knew said vye (this included instructors, computer lab
personnel, etc.), I guess I imprinted to that pronounciation.
A few made scurrilous and brazen attacks, impugning the intelligence
and/or wizard-ness of those wizards I know who pronounce vi as vye.
I suppose this makes them feel big. Whoopie.
Paul DuBois
dubois@primate.wisc.edu
-----------------------------
From: Amos Shapir <amos@taux01.uucp>
Subject: Re: ksh dumping core
Date: 21 Oct 89 13:32:18 GMT
Hdate: 22 Tishrey 5750
To: unix-wizards@sem.brl.mil
It seems all your sessions use the same history file; one of them adds
to it, making the other's current pointer into it invalid.
It is easy to fix: just define HISTFILE=.hist$HOST$TTY in your .profile
(make sure $TTY and $HOST are defined first, of course). I do not use
it since it's sometime useful to keep history around from other sessions;
just pressing RETURN every now and then makes sure a session re-reads
the history file, so it does not stay behind too much.
--
Amos Shapir amos@taux01.nsc.com or amos@nsc.nsc.com
National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel
Tel. +972 52 522261 TWX: 33691, fax: +972-52-558322
34 48 E / 32 10 N (My other cpu is a NS32532)
-----------------------------
From: Jim Burwell <jimb@faatcrl.uucp>
Subject: modem programs for Unix
Date: 21 Oct 89 02:47:12 GMT
Followup-To: comp.unix.questions
Keywords: terminal modem sun sunos bsd telebit cds xmodem ymodem zmodem
To: unix-wizards@sem.brl.mil
Hi there..
Does anyone know of any terminal programs, besides "tip" or "cu" for
Unix systems ?
We have a Sun 3/160 and a Sparc with a Telebit T2500, and a CDS 224 hooked
to the serial ports.. I've looked everywhere, but I can't seem to find
ANY terminal programs for Unix that work with our system. Tip and cu just
don't cut it, since they don't have any file transfer protocols, etc. Are
there any modem programs for Unix systems which even come close to those
available for PCs ?
I did manage to find a program called "pcomm", a terminal which has the
"look and feel" of procomm. Alas, it was for System V, and even though I
got it to compile and run on the Sun, with the Sys V compatible compiler and
libraries, all it would do is dial the modem, and send stuff out. I could
see data coming in, but it wouldn't appear on my screen...
Any help would be appreciated!
Bye
Jim
--
+------------------------------------------------+--------------------------+
| James S. Burwell | |
| | "UseNet...A text network |
| UUCP: | in a binary world" - Me |
| ...!{ames!netsys|rutgers}!faatcrl | |
| !jimb | "How do you say |
| . | 'multitasking' in |
| Internet: . | MS-DOSish? Network |
| // jimb@faatcrl.UUCP . ** | File Server!" - Me |
| // . **** | |
| \\ // GEnie: Airwarior: . .** | <reserved for future> |
| \X/ JIMBURWELL Techrat . | <expansion.... > |
+------------------------------------------------+--------------------------+
-----------------------------
From: Malaclypse the Elder <dwc@cbnewsh.att.com>
Subject: Re: Help! Altos 5.3.1 fork is failing!
Date: 21 Oct 89 06:57:22 GMT
To: unix-wizards@sem.brl.mil
i originally sent a reply to the poster of the question stating
that the reason that getcpages is failing trying to get 1 contiguous
page is that there is probably no free memory for a page table.
its been a while since i looked at the problem but i seem to
remember that the reason getcpages() can fail without sleeping
is to prevent deadlock-type situations. on release 3, there are
certain process data structures that are not swapped out: the ublock
(depending on the version), the page tables and DBDs, and maybe more.
well, you can get into a situation of deadlock in which all memory
is committed to these data structures and no process can continue
because it they are all both holding memory and waiting for more.
allowing the sleep to happen is okay if you make the sleep interruptable.
then at least the user can attempt to abort his program voluntarily
(the problem is determining when you are in this deadlock situation...
you can't run user level programs to tell you this).
my solution to this was really very simple. at fork time, the parent
knows how much memory resources it will take to create this process
(ublock, page tables, dbds, etc.). with this information, the parent
can check freemem level and reserve the necessary amount of memory to
satisfy the fork and sleep until that amount of memory is available.
this sleep is safe since no resources have been committed to the child
yet (the child doesn't even exist). we prototyped this for release 3
and it was going to go into some future release when they decided to
use sun's VM architecture instead of regions. i suspect that release 4
will have a similar problem but i'm not sure.
if you don't have source to modify, i suggested to the original requestor
that he set a very high value for GETPGSLO and GETPGSHI. this will make
the paging daemon very active and MAY prevent you from hitting situations
where freemem goes to zero. its not guaranteed since requests for
freemem is VERY bursty and the reaction time of vhand is fairly slow.
danny chen
att!hocus!dwc
-----------------------------
From: "David L. Markowitz" <dav@genisco.uucp>
Subject: Xenix driver for Univision 1024 video board
Date: 21 Oct 89 00:01:47 GMT
Keywords: driver univision xenix 386
To: unix-wizards@sem.brl.mil
I am in the process of writing a driver for a Univision 1024 frame buffer,
and I have a few questions.
First the details. I have ten years of Unix experience, and have written
many drivers, but I've never worked with Xenix or DOS much. My background
is Vax/68000/Sparc and VME based, not Intel and AT bus based. The hardware:
Standard stuff:
SCO Xenix 2.3.2
Micronix 20MHz 386 + Cache
2 MB RAM
80 MB Hard Disk
Monochrome Video Board
I am adding:
Univision 1024x1024 frame buffer with VSB bus
Tecon DVX1024 Frame Grabber with VSB bus
I already have the Tecon mostly working (it won't interrupt, though).
I need to map in 64K chunks of the video memory on the AT bus.
The board includes registers to set up which piece of video RAM
is mapped to the bus, but I don't know how to interpret Intel-style
addresses like C400:0200 within a driver.
I do not need to use this as my console device, nor does it need
to interface to the standard video boards data structures (although
that would be nice). I really just want to use it as an alternate
stand-alone display, while also having the monochrome display hooked up.
Now, the questions:
1) Has anyone already written this? How about other memory mapped video
board drivers? Are there any floating around in source form that
people wouldn't mind letting me look at?
2) How do I access the bus at such an address from Xenix?
3) Is there a good manual/book somewhere on how Xenix deals with the
fractured concepts of the AT bus. (Or, "Gee - a real computer! Too
bad it can't talk to the rest of the world very well...") (When
Sun designed their 386i machines, they had to figure out how to
co-exist with the AT bus. Their solution? "We don't use it!")
4) Am I crazy?
Please reply by mail - I will summarize if there is enough interest.
David L. Markowitz
Genisco Technology Corporation
dav@genisco
--
David L. Markowitz
Genisco Technology Corporation
dav@genisco
-----------------------------
From: Robert Krawitz <rlk@think.com>
Subject: Re: BSD file system
Date: 21 Oct 89 18:29:19 GMT
Sender: news@think.com
To: unix-wizards@sem.brl.mil
In article <31003@news.Think.COM>, dm@odin (Dave Mankins) writes:
]Symbolic links are just like hard links only with the ability to span
]filesystems (and, sadly, without the ability to know that, when you remove
]one name for a file (the target of the symbolic link) there is another name
]left dangling without a reference).
I find it more convenient to think of a symlink as nothing more than a
pointer to a named point in the filesystem. A hard link (remember, each
file is really a link) is a pointer to an inode (a filesystem object),
whereas a symlink is a pointer to a name.
--
ames >>>>>>>>> | Robert Krawitz <rlk@think.com> 245 First St.
bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142
harvard >>>>>> . Thinking Machines Corp. (617)876-1111
-----------------------------
From: RAMontante <bobmon@iuvax.cs.indiana.edu>
Subject: Re: Real Time UNIX (was: Re: How do you tell a wizard?)
Date: 21 Oct 89 19:35:23 GMT
To: unix-wizards@sem.brl.mil
der@cbnewsl.ATT.COM (david.e.rorke) <2396@cbnewsl.ATT.COM> :
-
-Real time scheduling is available (or will be in a couple weeks)
I LOVE it!
-----------------------------
From: George Hartzell <hartzell@boulder.colorado.edu>
Subject: "evils of alloca" discussion
Date: 21 Oct 89 19:48:04 GMT
Sender: news@boulder.colorado.edu
Keywords: alloca
To: unix-wizards@sem.brl.mil
A few months back there was a long discussion of the
benefits/drawbacks of using alloca. I read it with interest, but
didn't save it and now that I really want to know more I find that I
didn't save it. Did anyone keep an archive of that discussion? Can
you point me to it/share it with me.
I am specifically interested about alloca on MIPS cpus.
g.
George Hartzell (303) 492-4535
MCD Biology, University of Colorado-Boulder, Boulder, CO 80309
hartzell@Boulder.Colorado.EDU ..!{ncar,nbires}!boulder!hartzell
-----------------------------
From: "John F. Haugh II" <jfh@rpp386.cactus.org>
Subject: Re: How to write a new Unix-like kernel
Date: 21 Oct 89 18:27:31 GMT
To: unix-wizards@sem.brl.mil
In article <2046@prune.bbn.com> rsalz@bbn.com (Rich Salz) writes:
>In <17166@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes:
>> ... discouraging paging
>> the kernel is kinda wasteful the way kernels keep bloating.
>
>Take this sentence backwards, and it becomes a feature: since the kernel
>can't page, you can't puff lots of stuff into it. This has forced a
>certain economy of design (phrase lifted from one of the Unix papers, read
>them all and find out which one -- it'll be good for you) that has
>resulted in the initial success of Unix lo these many years ago.
Don't shoot the messenger! I haven't encouraged kernel bloat, I'm just
reporting the facts. I've frequently professed my admiration for the
7th Edition kernel in this newsgroup. And I have read the UNIX papers,
including the one which says that UNIX really isn't an operating system.
>I don't think this bloat is necessary, and as Dick Dunn has implied in
><1989Oct19.220105.10185@ico.isc.com>, if you make it possible to have the
>kernel page, then all you do is make it possible to have every
>semi-competent bozo put everything they want in the kernel. Goodbye
>tasteful and understandable set of features, hello [VM][MV]S.
I agree. However, if we are going to be adding features to a minimal
kernel [ such as networking, graphics, security ] we are either going to
have to cleverly redefine what exactly is =the= kernel or find more
efficient methods of managing the memory we are consuming.
In my mind it is the customer who is driving this software obesity.
You can either argue that Sun is successful because the customers
like the software features and buy more Sun's, or you can argue the
Sun programmers keep adding features because the sales staff keeps
doing a better job of fooling Sun's customers. I'd love to see an
analysis of SunOS size versus Sun annual sales. If you care to point
out that every company is growing their OS, I might point out that the
ones that didn't stay on the leading edge of creeping featurism are
now, in the main, out of business.
Besides, who says VMS or MVS or VM/SP are not useful operating systems?
If the question is "How do I put 2000 users on one machine?", my answer
is probably going to be MVS. The question may be kinda stupid and
anyone who really wants a DASD farm deserves MVS, but it is a solution.
>On the other hand, if you let the kernel page, then you can take all the
>stuff that doesn't page and call that the "real" kernel. As long as it's
>paging the other parts, put them in user space, and give users the
>opportunity to put their own code in for their programs.
Here I disagree. Almost everything in a kernel is pagable. If you
remove everything that can be paged or replaced you get CP. Taking
a module out of the kernel and cleverly calling it the "real" kernel will
only populate the memory with "user" processes which are now paging.
The user -should- be able to select which file system they want bound
into their kernel. If you want big and fat, the Berkeley Fast File
System is available. If you want small and stupid, RT-11 comes to
mind ;-)
Create a standard interface model and code two or three file systems
to fit that model. Then do the same with network interfaces, graphics
interfaces, etc. I really should be able to have X in the kernel or
not. I may need 16MB just to boot, but I should be able to do it.
>I don't expect someone whose .signature says that Mach stands for
>messages are crufty hacks will like this design very much, but I'd
>rather avoid bloat, myself. (Do I have to say that this is intended
>to be a mild tweak and not one of the famous "Usenet ad hom.
>attacks"?)
Probably ;-) Do you like the new .signature better?
I feel strongly against message passing schemes for the same reason
I'm not totally sold on lightweight kernel processes. jsr's are cheaper
than messages or context switches. You haven't guaranteed my MACH
processes aren't going to be paged out, so you've gained nothing more
than this warm fuzzy feeling that MACH's 55KLOC kernel is more
understandable than SunOS 4.0 or AT&T's latest overweight offering.
In fact, I'll even argue MACH is dangerous because it now gives
everyone an entirely new level to populate with crap. I feel very
confident in stating that MACH will be big and crufty in even less
time than it took UNIX. Everyone is so much better at adding cruft.
--
John F. Haugh II +-Things you didn't want to know:------
VoiceNet: (512) 832-8832 Data: -8835 | The real meaning of EMACS is ...
InterNet: jfh@rpp386.cactus.org | ... EMACS makes a computer slow.
UUCPNet: {texbell|bigtex}!rpp386!jfh +--<><--<><--<><--<><--<><--<><--<><---
-----------------------------
From: "Mark J. DeFilippis" <mark@promark.uucp>
Subject: Re: How do you tell a wizard?
Date: 21 Oct 89 01:11:12 GMT
To: unix-wizards@sem.brl.mil
I have worked with one flavor of Unix or another for several years, and
to this day will not call myself a wizard. I have long felt it was a form
of rationalization. Wizard implies "knows all", and Unix is ever growing
with each release of the operating system. BSD flavors that meet SVID.
System V with BSD extentions, different with every vendor.
However, I have found the following holds true for
most *very knowledegable Unix people* :
1 They have seen and/or modified Unix source at the kernel and
provided utilities level.
2 They have implimented, at least once, a device driver, or some
other kernel linkable code, and know how much fun it is to
debug this code.
3 They all have at least one beat up copy of the C bible, possibly
hard cover, or if not, the front or back cover is gone.
4 They have a copy of either the BSD or System V "Implimentation of
the Unix operating system."
5 All the above books have pages that are starting to bio-degrade
from age.
6 They have a copy of the SVID from AT&T if they work with SYSTEM V.
7 They all spell kernel as KERNEL, not KERNAL.
8 They don't call themselves wizards, but the people around them
usually do.
Each one of these alone does not constitute a wizard, especially 2, and 3.
But In the case of 2, it has been my experience that if they have been there
a few times, they know their way around pretty well.
--
Adelphi University, Garden City, NY 11530 (516) 663-1170
Department of Mathematics and Computer Science
markd@adelphi.UUCP or mark@promark.UUCP
UUCP: uunet!mimsy!rutgers!columbia!adelphi!markd
-----------------------------
From: Alan Watson <waw103@tijc02.uucp>
Subject: Re: How do you tell a wizard?
Date: 20 Oct 89 12:37:12 GMT
Posted: Fri Oct 20 08:37:12 1989
To: unix-wizards@sem.brl.mil
From article <917@uakari.primate.wisc.edu>, by bin@primate.wisc.edu (Brain in
Neutral):
> From article <955@umb.umb.edu>, by campbell@umb.umb.edu (Jim Campbell):
>> ie: NOVICE: Calls vi vye
> I have *never* heard *anyone* call "vi" vee-eye. Including wizards.
I have *never* heard *anyone* call "vi" vye. Including novices.
waw@rti!tijc02
-----------------------------
From: Guy Harris <guy@auspex.auspex.com>
Subject: Re: BSD file system
Date: 21 Oct 89 20:49:29 GMT
To: unix-wizards@sem.brl.mil
> Another way of looking at the multi-group capability is that
> a process has a main/primary group - the one listed in the
> password file and multiple secondary groups as determined by
> the group file. It makes sense to me to use the primary
> group for purposes of file ownership.
The problem is that it may not be a *valid* way of looking at the
multi-group capability, in that it doesn't fit reality; there may not be
some group that can reasonably act as a user's "primary group". A user
might work on several things during a session, and not want to use
"newgrp" whenever they change what they're working on to make some
different group be their "primary group".
> Directories such as /tmp typically are owned by groups of which
> users are not members, this has led to surprises at least once
> for me.
In SunOS 4.x and S5R4, the set-GID bit on a directory specifies whether
files created in that directory inherit the group from the parent
directory or get it from whatever of a user's groups happens, by chance,
to be the group in their password file entry. On such a system, you
could turn the set-GID bit off on "/tmp", or get the system
administrator to do it....
-----------------------------
From: Guy Harris <guy@auspex.auspex.com>
Subject: Re: What SHOULD go in the kernel
Date: 21 Oct 89 20:51:59 GMT
Keywords: device drivers
To: unix-wizards@sem.brl.mil
>> One could argue that device drivers don't belong in the kernel
>> at all.
>
>As device drivers continue to bloat in number and size,
>and as hardware becomes more sophisticated,
>this argument gains strength.
Yes, but...
>The NeXT Mach 1.0 operating system supports loadable device drivers.
>The MIDI interface, and other things like a SLIP (RS-232 TCP/IP) driver,
>are done that way. The driver is dynamically linked to the kernel,
>at which point it functions like an ordinary driver.
...down to being a part of the kernel.
Sorry, just making drivers loadable into and, possibly, unloadable from
the kernel doesn't keep them from being in the kernel - it just makes it
easier to control which ones you are in your particular kernel.
-----------------------------
From: Marnix van Ammers <mavanamm@pttesac.uucp>
Subject: Bug/problem in ksh88b and/or SUN OS
Date: 17 Oct 89 23:08:41 GMT
Followup-To: comp.unix.wizards
Keywords: KSH 88B SUN BUG
To: unix-wizards@sem.brl.mil
My ksh88b was dumping core on my SUN 3/50. It would happen
whenever the first command I executed was a particular function in
my $FPATH. I traced it down to the first echo command in my function.
When I recompiled ksh88b with ECHOPRINT set to 1 in the OPTIONS file,
the core dumps stopped.
I found out that when the core dump happened, the call to
path_absolute() at line 1084 of sh/name.c returned a NULL pointer
and that NULL pointer was then passed to strcmp() at line 1086.
The strcmp() function in SUN OS 4.0.3 apparently cannot take a NULL
argument (maybe this is really something SUN ought to fix?).
I could not figure out why path_absolute was returning a NULL
pointer. When I used the dbxtool debugger I'd end up getting
a "Trace/BPT trap(coredump)" before getting to where my normal core
dump was occurring. I don't know what a "Trace/BPT trap(coredump)"
(BPT == Break Point Trap ??) is but it seems to be a feature or
problem with the debugger (I'm new at this dbx stuff, so forgive me).
I was able to at least fix the problem by not passing a NULL pointer
to strcmp().
Here are the diffs to my fix (to sh/name.c):
1085a1086,1104
>
> /* Core dumping fix
>
> By: Marnix A. van Ammers
> Oct 12, 1989
> {att|pacbell}!pttesac!mavanamm
>
> Following fix added to avoid core dump by eq() when cp is NULL.
> (Happens when path_absolute() in echo_mode() returns NULL.)
> That situation happened when the first command to use echo was in my
> function gp() and OPTIONS had ECHOPRINT=0 and there is a
> /bin/echo as in the case of my Sun 3/50 running SUNOS 4.0.3 */
>
> if(cp == NULL)
> echo_arg = (char *) e_minus;
> else
>
> /* end of core dumping fix. */
>
For your information, here's my autoload function gp (I've since
changed this function, but this is the version that caused
ksh88b to dump core in my SUN):
#################################################################
function getpaths {
if [ "$1" = -x ];then
set -x;shift
fi
# getpaths($PATH) -- Return list of paths in $1
typeset PATH="$1"
typeset This_Path Front_Part Paths
while [ -n "${PATH}" ];do # While there's something in $PATH
Front_Part="${PATH%%:*}" # Remove 1st ':' and all to the right of it
if [ -z "$Front_Part" ];then # Front part was null -- special case
This_Path="."
Front_Part=":"
else
This_Path="$Front_Part"
fi
Paths="$Paths $This_Path"
PATH="${PATH#${Front_Part}}"
if [ "${PATH}" != ":" ];then # If this isn't the last (trailing) ':'
PATH="${PATH#:}" # then remove the leading ':'
fi
done
echo "$Paths"
}
# gp = getpath . Finds a *command* and does an ls -l on it
# For instance "gp sh" should find sh, rsh, ksh, rksh
function gp {
if [ "$1" = -x ];then
set -x;shift
fi
typeset F Files PATHS P
print "Searching for executables \"*$1*\" in \$PATH" >&2
PATHS=`getpaths "$PATH"`
for P in $PATHS;do
for F in $P/*$1*;do
if [ -f "$F" -a -x "$F" ];then
Files="$Files $F"
fi
done
done
if [ -n "$Files" ];then
ls -ld $Files
fi
}
#################################################################
I don't seem to have the real problem in hand, but I did just want
to report this to the net in case anyone has an idea what's really
going on.
--
Marnix
-----------------------------
From: Marnix van Ammers <mavanamm@pttesac.uucp>
Subject: ksh88 problem with substring expansion using "+( )" pattern
Date: 17 Oct 89 23:39:08 GMT
Followup-To: comp.unix.wizards
Keywords: KSH88 SUBSTRING PATTERN
To: unix-wizards@sem.brl.mil
I can't believe that the following ksh substring expansion should take
*22* seconds on my sun 3/50 (34 seconds on our 3B20A). All the work
is done internal to ksh. I'm using ksh88b (the "+( )" pattern
requires ksh88).
x=$(set -o) # Set x to current option settings
xx="${x##*nolog+( )on}" # same as `echo "$x"|sed "s/.*nolog *on//"`
As long as the above takes, I could do about 40+ forks and execs
of sed. I've found better ways of doing what I wanted to do without
any system calls, but I still can't believe 22 seconds.
Anybody know what's going on?
--
Marnix
-----------------------------
From: Doug Gwyn <gwyn@smoke.brl.mil>
Subject: Re: Bug/problem in ksh88b and/or SUN OS
Date: 22 Oct 89 04:22:30 GMT
Keywords: KSH 88B SUN BUG
To: unix-wizards@sem.brl.mil
In article <1425@pttesac.UUCP> mavanamm@pttesac.UUCP (Marnix van Ammers) writes:
>The strcmp() function in SUN OS 4.0.3 apparently cannot take a NULL
>argument (maybe this is really something SUN ought to fix?).
Fix it how? The problem lies in the application, not the C library.
-----------------------------
End of UNIX-WIZARDS Digest
**************************unix-wizards-request@BRL.MIL (UNIX Wizards) (10/24/89)
Good evening,
It seems we have a broken mailer out there. I cannot turn the
offending host off without killing all of BITNET since this host is
behind the BITNET exploder.
Mailers should be configured to send error and diagnostic information
first to the "Sender:" address then to the "From:" address if the
"Sender:" address is missing. They should *never* send error messages
to the "Reply-To:" address!
MARTY: Nail this puppy, please.
--for Mike Muuss,
Later,
Bob
<reschly@BRL>
----- Forwarded message # 1:
Received: from SEM.BRL.MIL by SEM.BRL.MIL id aa06492; 22 Oct 89 12:14 EDT
Received: from smoke.brl.mil by SEM.BRL.MIL id aa06486; 22 Oct 89 12:02 EDT
Received: from CORNELLC.CIT.CORNELL.EDU by SMOKE.BRL.MIL id aa03957;
22 Oct 89 11:53 EDT
Received: from DICKINSN.Bitnet by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6943; Sun, 22 Oct 89 11:50:49 EDT
Date: Sun, 22 Oct 89 11:07:24 edt
From: Postmaster <POSTMASTER%DICKINSN.BITNET@cornellc.cit.cornell.edu>
To: UNIX-WIZARDS@BRL.MIL
Subject: Returned network mail
Message-ID: <8910221153.aa03957@SMOKE.BRL.MIL>
Resent-Date: Mon, 23 Oct 89 22:12:13 EDT
Resent-From: reschly@BRL.MIL
Resent-To: unix-wizards-request@BRL
This message was automatically generated.
Your mail message could not be delivered at Dickinson College in Carlisle,
Pennsylvania because the user address was not known at our site.
Addresses at Dickinson College are of the following format:
username@DICKINSN e.g., POSTMASTER@DICKINSN
or ALLAN_J@DICKINSN
or WOLTER@DICKINSN
Usernames are typically the first 8 letters of the person's last name,
frequently with the first initial added, and occasionally with an
underscore. As a result, it would be difficult to guess someone's username.
If you do not know the address of someone at Dickinson, please send a
message to POSTMASTER@DICKINSN asking for help.
----------------------------------------------------------------------
The following diagnostic is the reason for the return:
%BNET-W-NOSUCHRCVR, receiver LEYON_C cannot be located
Returned mail follows:
----------------------
Received: From PSUVM(MAILER) by DICKINSN with Jnet id 5076
for LEYON_C@DICKINSN; Sun, 22 Oct 89 11:07 EDT
Received: by PSUVM (Mailer R2.03B) id 4463; Sun, 22 Oct 89 11:06:40 EDT
Date: Sun, 22 Oct 89 02:45:26 EST
Reply-To: UNIX-WIZARDS@BRL.MIL
Sender: Unix-Wizards Mailing List <UNIX-WIZ@NDSUVM1>
From: Mike Muuss The Moderator <Unix-Wizards-Request@BRL.MIL>
Subject: UNIX-WIZARDS Digest V8#099
X-To: UNIX-WIZARDS@BRL.MIL
To: Chris Leyon <LEYON_C@DICKINSN.BITNET>
UNIX-WIZARDS Digest Sun, 22 Oct 1989 V8#099
Today's Topics:
[ ... ]
End of UNIX-WIZARDS Digest
**************************
----- End of forwarded messages