Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!haven!adm!xadmx!POSTMASTER%DICKINSN.BITNET@cornellc.cit.cornell.edu From: POSTMASTER%DICKINSN.BITNET@cornellc.cit.cornell.edu (Postmaster) Newsgroups: comp.unix.wizards Subject: Returned network mail Message-ID: <21230@adm.BRL.MIL> Date: 21 Oct 89 13:58:28 GMT Sender: news@adm.BRL.MIL Lines: 1736 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 From: Mike Muuss The Moderator Subject: UNIX-WIZARDS Digest V8#098 X-To: UNIX-WIZARDS@BRL.MIL To: Chris Leyon 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" 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 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 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" 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 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 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 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 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 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 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 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 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 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 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 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: . .** | | | \X/ JIMBURWELL Techrat . | | +------------------------------------------------+--------------------------+ ----------------------------- From: Chip Salzenberg 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" 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 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 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 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 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 : Editor too big!" ----------------------------- From: Tim Wood 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 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 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 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 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 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 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 ----------------------------- From: "Brandon S. Allbery" 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@] *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)* ----------------------------- From: "Brandon S. Allbery" 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@] *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)* ----------------------------- From: Dick Dunn 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 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 uunet!crdgw1!barnett ----------------------------- From: Doug Gwyn 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 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" 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 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 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 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 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 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 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 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 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 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 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 ----------------------------- From: "S. P. Gilgut" 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: > >> (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 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 Subject: Default group IDs (was: Re: BSD file system) Date: 21 Oct 89 01:30:34 GMT Sender: USENET News System 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", | (dirstat.st_gid & (~(S_IRWXU | S_IRWXG | S_IRWXO)))); where 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 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 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" 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 **************************