Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!uflorida!haven!adm!xadmx!MAILER-DAEMON@slcs.slb.com From: MAILER-DAEMON@slcs.slb.com (Mail Delivery Subsystem) Newsgroups: comp.unix.wizards Subject: Returned mail: User unknown Message-ID: <19906@adm.BRL.MIL> Date: 7 Jun 89 12:59:17 GMT Sender: news@adm.BRL.MIL Lines: 1645 ----- Transcript of session follows ----- >>> RCPT To: <<< 550 ... User unknown 550 asc.slb.com::guthery... User unknown ----- Unsent message follows ----- Return-Path: Received: from asc.psi by slcs.SLCS.SLB.COM (3.2/SLCS Relay 1.1) id AA12156; Wed, 7 Jun 89 07:19:20 CDT Apparently-To: asc.slb.com::guthery X-Vms-To: UNIX-WIZARDS@brl.mil Received: from relay.cs.net by sdr.slb.com; Wed, 7 Jun 89 05:04 EST Received: from sem.brl.mil by RELAY.CS.NET id aa00690; 7 Jun 89 3:39 EDT Received: from SEM.BRL.MIL by SEM.BRL.MIL id aa26080; 7 Jun 89 2:53 EDT Received: from sem.brl.mil by SEM.BRL.MIL id aa26024; 7 Jun 89 2:45 EDT Date: Wed, 07 Jun 89 02:45:29 EST From: The Moderator Subject: UNIX-WIZARDS Digest V7#100 To: UNIX-WIZARDS@brl.mil Reply-To: UNIX-WIZARDS@brl.mil Message-Id: <8906070245.aa26024@SEM.BRL.MIL> UNIX-WIZARDS Digest Wed, 07 Jun 1989 V7#100 Today's Topics: Re: GNU, security, and RMS Re: keyscan wanted Re: Optimal for loop on the 68020. access() Re: What kind of things would you wnat in the GNU OS Long filenames (was: What kinds of things would you want in the GNU OS?) sys V.3.2 swap problem: unterminated sleep? Re: GNU, security, and RMS Re: Getting rid of the root account Re: GNU os suggestions -- system data interfaces Re: GNU OS suggestion -- memory "advice" Re: What kinds of things would you want in the GNU OS? Positional Parameter Settin in function Directory Editor Re: What kind of things would you wnat in the GNU OS Re: What kinds of things would you want in the GNU OS? Re: Getting rid of the root account Locks for exclusive access to resources Van Jacobson's version of SLIP with header compression... Re^2: GNU, security, and RMS UNIX Sys V Tunable Parameters Re: keyscan wanted Re: Re^2: GNU, security, and RMS Re: What kinds of things would you want in the GNU OS? Re: Optimal for loop on the 68020. Re:Getting rid of the root account (Was: GNU OS) Re: GNU, security, and RMS redirect stdin when using execl Re: GNU OS suggestion -- memory "advice" Re: Getting rid of the root account Re: security (PCs) Re: GNU os suggestions -- system data interfaces inode table hacking Re: Positional Parameter Settin in function Re: GNU os suggestions -- system data interfaces Building a Sun boot tape. sh functions with "local variables" ----------------------------------------------------------------- From: carroll@s.cs.uiuc.edu Subject: Re: GNU, security, and RMS Date: 4 Jun 89 18:32:00 GMT Nf-ID: #R:thor.acc.stolaf.edu:2322:s.cs.uiuc.edu:216100012:000:1640 Nf-From: s.cs.uiuc.edu!carroll Jun 4 13:32:00 1989 To: unix-wizards@sem.brl.mil /* Written 1:55 pm Jun 3, 1989 by haynes@ucbarpa.Berkeley.EDU in s.cs.uiuc.edu:comp.unix.wizards */ In article <2322@thor.acc.stolaf.edu> mike@stolaf.edu writes: >(2) There should not be security among the users of a computer system. Well, you have a right to your opinion; but a corollary of this belief is that all the users of a computer system have to be mutually friendly and responsible and trust one another. ^^^^^^^^^^^ /* End of text from s.cs.uiuc.edu:comp.unix.wizards */ Put with "skillful" with "responsible". I used to share a couple systems with some associates of mine, all of whom I trusted complete to be _honest_ and _ethical_. I certainly did _not_ trust all of them to be _skillful_. As an example, I have a friend who I'd trust in my house while I'm gone, but I'd _never_ loan him the keys to my car because _he doesn't know how to drive_. Similarly, I didnt' give my some of my associates full priviledges because _they didn't know enough to be safe_. If ever one was a wizard kernel-hacker, then it wouldn't be a problem. But that doesn't happen in the real world. Properly used security also prevents _accidents_. Further, I kept private information on the system - I trusted them not to look, even with root priviledges, if I set the permissions to exclude normal logons. Setting everything 666 (or 777) strikes me as bogus. How are others to know what they are welcome to look at / edit or not? Alan M. Carroll "And there you are carroll@s.cs.uiuc.edu Saying 'We have the Moon, so now the Stars...'" CS Grad / U of Ill @ Urbana ...{ucbvax,pur-ee,convex}!s.cs.uiuc.edu!carroll ----------------------------- From: "T. William Wells" Subject: Re: keyscan wanted Date: 5 Jun 89 23:59:54 GMT Expires: Sender: Followup-To: Keywords: To: unix-wizards@sem.brl.mil In article <607@wn2.sci.kun.nl> medfys@wn2.sci.kun.nl (Victor Langeveld/Tjeerd Dijkstra) writes: : In article <1006@twwells.uucp>, bill@twwells.uucp (T. William Wells) : writes: : > In article <475@wn2.sci.kun.nl> medfys@wn2.sci.kun.nl (Victor Langeveld/Tjeerd Dijkstra) writes: : > : I am searching for a (small?) routine that informs me about a : > : possible pressed key. This routine should *not* wait for input, : > : but return immediately, wether succesfull or not. : > : Suggestions? : > : > Yes. Tell us what hardware and OS you are talking about. : > : > For example, this should be doable on my system, a '386 running : > Microport's Unix, by telling the driver to return scan codes and : > doing nonblocking reads. It's all in the relevant sections of the : > manual, under keyboard(7), open(2), and fcntl(2), and maybe a few : > other places I can't think of off hand. : > : > But on your system, who knows? We certainly don't, since we don't : > know the system. : > : > --- : > Bill { uunet | novavax } !twwells!bill : : There is no need to know what hardware this should be working on. : Mr Charles Thayer (Thanks again, Charles!) gave me a perfect solution: : : int key_pressed() : { : int mask=1; : struct timeval wait; : : wait.tv_sec=0; : wait.tv_usec=0; : return (select(1,&mask,0,0,&wait)); : } : : This can be used as e.g. if(!key_pressed) { do stuff} else { key : handling}. Works fine! (As is should (?) on any unix machine) Leaving aside the possible interpretational problem (the solution I suggested *really* permits checking for key pressed, and key released, too), you're talking BSD. Your code won't work on my sysV 3.0 and on many others. --- Bill { uunet | novavax } !twwells!bill ----------------------------- From: Stephen Uitti Subject: Re: Optimal for loop on the 68020. Date: 5 Jun 89 20:15:12 GMT Keywords: for ( i = COUNT; --i >= 0; ) To: unix-wizards@sem.brl.mil In article <11993@well.UUCP> Jef Poskanzer writes: >I compiled the following different kinds of for loops: > for ( i = 0; i < COUNT; i++ ) > for ( i = 0; i < COUNT; ++i ) > for ( i = 0; ++i <= COUNT; ) > for ( i = 0; i++ < COUNT; ) > for ( i = COUNT; i > 0; i-- ) > for ( i = COUNT; i > 0; --i ) > for ( i = COUNT; --i >= 0; ) > for ( i = COUNT; i-- > 0; ) >on a Sun 3/50 with both SunOS 3.5 cc and gcc 1.35, and looked at the >generated code and the timings. COUNT was a small (< 127) compile-time >constant. A huge amount of time ago, i did this for the PDP-11 using the Ritchie compiler. This compiler is not awesomely bright, but i had the impression that it wasn't quite as bad as PCC (or even less portable). The optimal loop would use the "sob" (subtract one and branch if not zero) instruction. The code that caused it to be emitted was register i; i = COUNT; do { loop body; } while (--i); This is much clearer than anything with for(), since it tends to get (even stupidly) compiled to: register i; i = COUNT; mov $COUNT,r2 do { L1: loop body; loop body... } while (--i); sob r2,L1 The compiler seemed to be smart enough to know not to use it if the loop was too long. Thus, at worst, the sob would be replaced by: sub $1,r2 jne L1 The trouble with "for" loops is that it is defined as "test at the top", when most single instructions loops are "test at bottom". The VAX (PCC based) compiler's optimizer would convert many loops that used multiple instructions to use a single complicated instruction. Unfortunately, the VAX 780 (ubiquitous at the time) generally ran these slower. One case was the acbl (add, compare and branch longword). The optimizer would replace the three instructions (something like:) add $1,r2 cmp $END,r2 bne L1 with the "acbl" and all its arguments. Both codings take the same number of bytes (25!). The multiple instructions are faster (on the 780). Newer VAXen have different relative timing. I recall this case coming from the prime number sieve benchmark. The loop could not be easily converted to the do-while. I haven't gotten a chance to play with gcc (real work to do). I've heard it can do wonders, and thought it did better multi-statement optimization. Still, all the silly side-effects semantics of C make it hard to tell a compiler how to take mediocre source and produce good code from it. It is best to start with good source. Though i hardly ever write assembler anymore (and it seems never for speed or size), i've still yet to bump into a C compiler that produces code that i can't improve on at a glance. This may change if/when i start working with scoreboarded RISC processors (88K), in that instruction cycle counting looks hard (requiring more than a glance). Stephen. ----------------------------- From: Mike McNally Subject: access() Date: 5 Jun 89 17:30:15 GMT To: unix-wizards@sem.brl.mil Is it appropriate that access("somefile", X_OK) always succeeds (returns 0), whether "somefile" has an "x" bit or not, when called while the eff. user id is root? For the curious, I tested this under 4.3BSD on my Integrated "Solutions" 68020 box with the following program: main(ac, av) int ac; char **av; { printf("%d\n", access(av[1], atoi(av[2]))); } The program is invoked as "t something 1". When run on a particular file while not setuid to root, it prints -1 for a plain text file without any "x" bits. After I setuid to root, the exact same invocation prints 0. Of course, even while setuid, an attempt to execute the file fails with EACCES. Note that I don't want to start another war about the usefulness of access(). -- Mike McNally Lynx Real-Time Systems uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233 Where equal mind and contest equal, go. ----------------------------- From: Roy Smith Subject: Re: What kind of things would you wnat in the GNU OS Date: 6 Jun 89 01:26:52 GMT To: unix-wizards@sem.brl.mil In article <19851@adm.BRL.MIL> cherry.STCWR@xerox.com writes: > I'd say put [VM & symlinks] in. Let the user determine whether to use > them or not. The fact that they are there doesn't hurt an OS. It is thinking like this that led us from the 40k kernels I used to run back in the v6 days to the 500+k kernels we see today. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network" ----------------------------- From: "Bruce G. Barnett" Subject: Long filenames (was: What kinds of things would you want in the GNU OS?) Date: 6 Jun 89 04:07:16 GMT Sender: news@crdgw1.crd.ge.com Keywords: OS filenames To: unix-wizards@sem.brl.mil In article <9422@alice.UUCP>, andrew@alice (Andrew Hume) writes: > my point is that if you have structured names like >-