Returned network mail
Postmaster
POSTMASTER%DICKINSN.BITNET at cornellc.cit.cornell.edu
Sat Oct 21 23:58:28 AEST 1989
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 at DICKINSN e.g., POSTMASTER at DICKINSN
or ALLAN_J at DICKINSN
or WOLTER at 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 at 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 at 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 at BRL.MIL
Sender: Unix-Wizards Mailing List <UNIX-WIZ at NDSUVM1>
From: Mike Muuss The Moderator <Unix-Wizards-Request at BRL.MIL>
Subject: UNIX-WIZARDS Digest V8#098
X-To: UNIX-WIZARDS at BRL.MIL
To: Chris Leyon <LEYON_C at 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 at 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 at 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 at iexist.att.com |
|``Computer..Computer.. Ah, a keyboard! How quaint...''|
+-------------------------------------------------------+
-----------------------------
From: Jerry Gardner <jerry at 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 at sem.brl.mil
In article <506 at oglvee.UUCP> jr at 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 at altos.com San Jose, CA 95134
I survived the Big One, October 17, 1989 946-6700
-----------------------------
From: David Kuder <david at indetech.com>
Subject: Re: using /bin/sh in make commands
Date: 18 Oct 89 23:08:33 GMT
To: unix-wizards at sem.brl.mil
In article <21173 at adm.BRL.MIL> Leisner.Henr at 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 at indetech.com {uunet,sun,sharkey,pacbell}!indetech!david
-----------------------------
From: "John F. Haugh II" <jfh at rpp386.cactus.org>
Subject: Re: What SHOULD go in the kernel
Date: 19 Oct 89 02:16:41 GMT
To: unix-wizards at sem.brl.mil
In article <47040 at bbn.COM> pplacewa at 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 at rpp386.cactus.org | ... Messages Are Crufty Hacks.
UUCPNet: {texbell|bigtex}!rpp386!jfh +--<><--<><--<><--<><--<><--<><--<><---
-----------------------------
From: Rico Tudor <rico at dehn>
Subject: BSD file system
Date: 19 Oct 89 07:56:48 GMT
Sender: news at accuvax.nwu.edu
To: unix-wizards at 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 at umb.umb.edu>
Subject: Re: How do you tell a wizard?
Date: 18 Oct 89 14:49:29 GMT
To: unix-wizards at 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 at boulder.colorado.edu>
Subject: alloca discussion/alloca on MIPS cpus
Date: 18 Oct 89 23:11:43 GMT
Sender: news at boulder.colorado.edu
Keywords: alloca mips
To: unix-wizards at 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 at Boulder.Colorado.EDU ..!{ncar,nbires}!boulder!hartzell
-----------------------------
From: Doug Gwyn <gwyn at smoke.brl.mil>
Subject: Re: UNIX history made easy
Date: 19 Oct 89 11:19:47 GMT
To: unix-wizards at sem.brl.mil
In article <10027 at alice.UUCP> andrew at 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 at smoke.brl.mil>
Subject: Re: What SHOULD go in the kernel
Date: 19 Oct 89 11:25:10 GMT
To: unix-wizards at sem.brl.mil
In article <3596 at frame.UUCP> eeg at 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 at mimsy.umd.edu>
Subject: Re: BSD file system
Date: 19 Oct 89 11:08:37 GMT
To: unix-wizards at sem.brl.mil
In article <1344 at accuvax.nwu.edu> rico at 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 at cs.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Dave Mankins <dm at odin.think.com>
Subject: Re: BSD file system
Date: 19 Oct 89 10:03:03 GMT
Sender: news at think.com
To: unix-wizards at sem.brl.mil
In article <1344 at accuvax.nwu.edu> rico at 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 at think.com)
-----------------------------
From: Guy Middleton <gamiddleton at watmath.waterloo.edu>
Subject: Re: How do I set up an insulating gateway?
Date: 19 Oct 89 14:57:38 GMT
To: unix-wizards at sem.brl.mil
In article <20158 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
| In article <20149 at 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 at watmath.waterloo.edu
(+1 519 885 1211 x3472) gamiddleton at watmath.uwaterloo.ca
-----------------------------
From: Brain in Neutral <bin at primate.wisc.edu>
Subject: Re: How do you tell a wizard?
Date: 19 Oct 89 16:02:08 GMT
Sender: bin at primate.wisc.edu
To: unix-wizards at sem.brl.mil
>From article <955 at umb.umb.edu>, by campbell at 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 at primate.wisc.edu
-----------------------------
From: Steve Friedl <friedl at 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 at 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 at vsi.com
Replies to vsi!bang!friedl might get lost, please use vsi!friedl
-----------------------------
From: Jim Burwell <jimb at faatcrl.uucp>
Subject: GNU tar
Date: 19 Oct 89 16:46:47 GMT
Keywords: tar tape sun 1/4 inch SCSI
To: unix-wizards at 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 at faatcrl.UUCP . ** | File Server!" - Me |
| // . **** | |
| \\ // GEnie: Airwarior: . .** | <reserved for future> |
| \X/ JIMBURWELL Techrat . | <expansion.... > |
+------------------------------------------------+--------------------------+
-----------------------------
From: Chip Salzenberg <chip at 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 at sem.brl.mil
According to pyr4 at 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 at PSUVM
BIFF.BIFFSON at CUP.PORTAL.COM
-----------------------------
From: "Blair P. Houghton" <bph at 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 at sem.brl.mil
In article <1019 at psc90.UUCP> pyr4 at .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 at cscosl.ncsu.edu>
Subject: Disk drivers needed: RQDX2, RD5N, RX50
Date: 19 Oct 89 14:07:29 GMT
Sender: news at ncsuvx.ncsu.edu
Posted: Thu Oct 19 10:07:29 1989
To: unix-wizards at 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 at cscosl.ncsu.edu {decvax, gatech}!mcnc!ncsuvx!cscosl!miler
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------------------------
From: William Bader <wbader at scarecrow.mse.lehigh.edu>
Subject: Re: GNU tar
Date: 19 Oct 89 17:53:37 GMT
Sender: news at vlsi3b15.csee.lehigh.edu
Followup-To: comp.unix.questions
To: unix-wizards at sem.brl.mil
In article <1051 at faatcrl.UUCP> jimb at 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 at convex.com>
Subject: Re: How do you tell a wizard?
Date: 19 Oct 89 16:26:59 GMT
Sender: news at convex.uucp
To: unix-wizards at sem.brl.mil
In article <955 at umb.umb.edu> campbell at 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 at convex.COM
"EMACS belongs in <sys/errno.h>: Editor too big!"
-----------------------------
From: Tim Wood <tim at binky.sybase.com>
Subject: Re: How do you tell a wizard?
Date: 19 Oct 89 21:00:23 GMT
Sender: news at sybase.sybase.com
To: unix-wizards at sem.brl.mil
In article <9100017 at m.cs.uiuc.edu> carey at 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 at 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 at well.uucp>
Subject: Re: What SHOULD go in the kernel
Date: 19 Oct 89 16:20:34 GMT
Keywords: device drivers
To: unix-wizards at 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 at gdr.bath.ac.uk>
Subject: Re: How do you tell a wizard?
Date: 19 Oct 89 15:05:18 GMT
To: unix-wizards at sem.brl.mil
You can always tell a wizard.
You just can't tell him much...
--
Paul Smee | JANET: Smee at uk.ac.bristol
Computer Centre | BITNET: Smee%uk.ac.bristol at ukacrl.bitnet
University of Bristol | Internet: Smee%uk.ac.bristol at nsfnet-relay.ac.uk
(Phone: +44 272 303132) | UUCP: ...!mcvax!ukc!gdr.bath.ac.uk!exspes
-----------------------------
From: Maarten Litmaath <maart at cs.vu.nl>
Subject: Re: remote access to edit buffer
Date: 19 Oct 89 19:23:58 GMT
To: unix-wizards at sem.brl.mil
eliot at 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 at cs.vu.nl, mcsun!botter!maart
-----------------------------
From: Peter da Silva <peter at ficc.uu.net>
Subject: Re: What SHOULD go in the kernel
Date: 20 Oct 89 01:51:19 GMT
To: unix-wizards at sem.brl.mil
In article <17166 at rpp386.cactus.org> jfh at 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 at ficc.uu.net, +1 713 274 5180. Fun: peter at 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 at paris.berkeley.edu>
Subject: Re: How do you tell a wizard?
Date: 20 Oct 89 02:44:58 GMT
Sender: news at pasteur.berkeley.edu
To: unix-wizards at 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 at ai.mit.edu, uunet!ai.mit.edu!roland
-----------------------------
From: Jim Rosenberg <jr at oglvee.uucp>
Subject: Re: Help! Altos 5.3.1 fork is failing!
Date: 19 Oct 89 16:14:29 GMT
To: unix-wizards at sem.brl.mil
In article <2296 at hcr.UUCP> larry at 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 at 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 at sem.brl.mil
As quoted from <26894 at prls.UUCP> by gordon at 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 at NCoast.ORG
uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery at hal.cwru.edu bsa at telotech.uucp
161-7070 (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie), comp-sources-misc at backbone
[comp.sources.misc-related mail should go ONLY to comp-sources-misc@<backbone>]
*Third party vote-collection service: send mail to allbery at uunet.uu.net (ONLY)*
-----------------------------
From: "Brandon S. Allbery" <allbery at 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 at sem.brl.mil
As quoted from <506 at oglvee.UUCP> by jr at 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 at NCoast.ORG
uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery at hal.cwru.edu bsa at telotech.uucp
161-7070 (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie), comp-sources-misc at backbone
[comp.sources.misc-related mail should go ONLY to comp-sources-misc@<backbone>]
*Third party vote-collection service: send mail to allbery at uunet.uu.net (ONLY)*
-----------------------------
From: Dick Dunn <rcd at ico.isc.com>
Subject: Re: What SHOULD go in the kernel
Date: 19 Oct 89 22:01:05 GMT
To: unix-wizards at sem.brl.mil
jfh at rpp386.cactus.org (John F. Haugh II) writes:
> ...pplacewa at 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 at ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870
...No DOS. UNIX.
-----------------------------
From: Bruce Barnett <barnett at crdgw1.crd.ge.com>
Subject: Re: How do you tell a wizard?
Date: 20 Oct 89 14:22:21 GMT
Sender: news at crdgw1.crd.ge.com
To: unix-wizards at 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 at crd.ge.com> uunet!crdgw1!barnett
-----------------------------
From: Doug Gwyn <gwyn at smoke.brl.mil>
Subject: Re: How do you tell a wizard?
Date: 20 Oct 89 15:51:16 GMT
To: unix-wizards at sem.brl.mil
In article <917 at uakari.primate.wisc.edu> bin at 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 at oddjob.uchicago.edu>
Subject: Re: What SHOULD go in the kernel
Date: 20 Oct 89 16:26:25 GMT
Sender: news at tank.uchicago.edu
To: unix-wizards at 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 at oddjob.uchicago.edu
-----------------------------
From: voss at 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 at 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 at cs.uiuc.edu
-----------------------------
From: "Steven M. Schultz" <sms at wlv.imsd.contel.com>
Subject: Re: BSD file system
Date: 20 Oct 89 12:33:11 GMT
Sender: news at wlbr.imsd.contel.com
To: unix-wizards at sem.brl.mil
>In article <20258 at mimsy.umd.edu> chris at mimsy.umd.edu (Chris Torek) writes:
>>In article <1344 at accuvax.nwu.edu> rico at 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 at wlv.imsd.contel.com
-----------------------------
From: Rich Salz <rsalz at bbn.com>
Subject: How to write a new Unix-like kernel
Date: 20 Oct 89 15:04:14 GMT
To: unix-wizards at sem.brl.mil
In <17166 at rpp386.cactus.org> jfh at 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 at 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 at uunet.uu.net.
Use a domain-based address or give alternate paths, or you may lose out.
-----------------------------
From: Mike Marshall <hubcap at hubcap.clemson.edu>
Subject: Re: How do you tell a wizard?
Date: 20 Oct 89 14:00:13 GMT
To: unix-wizards at 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 at clemson.edu
-----------------------------
From: jim frost <madd at world.std.com>
Subject: fork affecting ndbm requests?
Date: 20 Oct 89 17:46:54 GMT
To: unix-wizards at 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 at std.com
-----------------------------
From: Thomas Truscott <trt at rti.uucp>
Subject: Re: What SHOULD go in the kernel
Date: 20 Oct 89 14:07:07 GMT
Keywords: device drivers
To: unix-wizards at 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 at mimsy.umd.edu>
Subject: Re: BSD file system
Date: 20 Oct 89 20:49:15 GMT
To: unix-wizards at sem.brl.mil
In article <38688 at wlbr.IMSD.CONTEL.COM> sms at 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 at cs.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Barry Margolin <barmar at kulla>
Subject: Re: BSD file system
Date: 20 Oct 89 21:10:28 GMT
Sender: news at think.com
To: unix-wizards at sem.brl.mil
In article <38688 at wlbr.IMSD.CONTEL.COM> sms at WLV.IMSD.CONTEL.COM.UUCP (Steven M.
Schultz) writes:
>In article <20258 at mimsy.umd.edu> chris at 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 at think.com
{uunet,harvard}!think!barmar
-----------------------------
From: kirk reiser <kirk at braille.uwo.ca>
Subject: need help with very old uucp
Date: 20 Oct 89 20:05:36 GMT
To: unix-wizards at 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 at braille.uwo.ca rm-H045 Health Sciences Addition
bitnet: kirk at braille.uwocc1 London, Ont. N6A 5C1
-----------------------------
From: Jim Campbell <campbell at umb.umb.edu>
Subject: Re: How do you tell a wizard?
Date: 20 Oct 89 15:31:19 GMT
To: unix-wizards at sem.brl.mil
You don't tell a wizard,
s/he already knows ;-)
-----------------------------
From: John Nagle <nagle at well.uucp>
Subject: Re: Shadow Disks
Date: 20 Oct 89 16:11:02 GMT
To: unix-wizards at 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 at bbn.com>
Subject: Re: What SHOULD go in the kernel
Date: 20 Oct 89 22:00:35 GMT
To: unix-wizards at sem.brl.mil
jfh at 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 at bbn.com>
-----------------------------
From: "S. P. Gilgut" <gilgut at cg-atla.uucp>
Subject: Re: How do you tell a wizard?
Date: 16 Oct 89 13:24:30 GMT
To: unix-wizards at sem.brl.mil
In article <4846 at tekcrl.LABS.TEK.COM> terryl at tekcrl.LABS.TEK.COM writes:
>In article <69985 at uunet.UU.NET> rick at 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 at me.utoronto.ca>
Subject: Re: How do you tell a wizard?
Date: 21 Oct 89 00:54:22 GMT
To: unix-wizards at sem.brl.mil
In article <917 at uakari.primate.wisc.edu> bin at 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 at 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 at med.stanford.edu>
To: unix-wizards at sem.brl.mil
In article <38688 at wlbr.IMSD.CONTEL.COM> sms at WLV.IMSD.CONTEL.COM.UUCP
(Steven M. Schultz) wrote:
>>In article <20258 at mimsy.umd.edu> chris at mimsy.umd.edu (Chris Torek) writes:
>>>In article <1344 at accuvax.nwu.edu> rico at 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 at mindcraft.com
(415) 493-9000 karish at forel.stanford.edu
-----------------------------
From: David C Lawrence <tale at pawl.rpi.edu>
Subject: Re: How do you tell a wizard?
Date: 21 Oct 89 02:59:13 GMT
To: unix-wizards at sem.brl.mil
In <4588 at buengc.BU.EDU> bph at 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 at pawl.rpi.edu" "tale at itsgw.rpi.edu" "tale at rpitsmts.bitnet"))
-----------------------------
From: Mike McNally <m5 at lynx.uucp>
Subject: Re^2: using /bin/sh in make commands
Date: 20 Oct 89 18:19:36 GMT
To: unix-wizards at sem.brl.mil
david at indetech.com (David Kuder) writes:
In article <21173 at adm.BRL.MIL> Leisner.Henr at 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 at 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 at sem.brl.mil
In article <9509 at june.cs.washington.edu>, ka at cs.washington.edu (Kenneth
Almquist) writes:
>
> jfh at 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
**************************
More information about the Comp.unix.wizards
mailing list