Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!xadmx!postmaster@urbana.mcd.mot.com From: postmaster@urbana.mcd.mot.com Newsgroups: comp.unix.wizards Subject: mail to xenurus.gould.com Message-ID: <20212@adm.BRL.MIL> Date: 11 Jul 89 14:58:42 GMT Sender: news@adm.BRL.MIL Lines: 297 The enclosed mail message was addressed to a system which is no longer in service. We have attempted to forward your mail to the correct recipient(s). If this is not possible, you will recieve additional mail at the time of failure. In the future, please use the system name "urbana.mcd.mot.com" instead. Please correct any mailing lists or alias files that may reference any of the following obsolete system names: xenurus.gould.com fang.gould.com fang.urbana.gould.com vger.urbana.gould.com ccvaxa.gould.com ccvaxa.urbana.gould.com burt.urbana.gould.com mycroft.urbana.gould.com If you have any further problems or questions about mail to this site, please contact postmaster@urbana.mcd.mot.com. thank you for your cooperation, postmaster@urbana.mcd.mot.com Motorola Microcomputer Division, Urbana Design Center ---------- text of forwarded message: Received: from sem.brl.mil by placebo (5.61/1.34) id AA04281; Mon, 10 Jul 89 21:31:41 -0500 Received: by SEM.BRL.MIL id ab10938; 10 Jul 89 14:50 EDT Received: from SEM.BRL.MIL by SEM.brl.MIL id aa04049; 9 Jul 89 3:20 EDT Received: from sem.brl.mil by SEM.BRL.MIL id aa04012; 9 Jul 89 2:45 EDT Date: Sun, 09 Jul 89 02:45:13 EST From: The Moderator (Mike Muuss) To: UNIX-WIZARDS@BRL.MIL Reply-To: UNIX-WIZARDS@BRL.MIL Subject: UNIX-WIZARDS Digest V7#124 Message-Id: <8907090245.aa04012@SEM.BRL.MIL> UNIX-WIZARDS Digest Sun, 09 Jul 1989 V7#124 Today's Topics: Re: Algorithm needed: reading/writing a large file Re: What kinds of things would you want in the GNU OS? Quotas in the Real World [TM] (was: Re: chown) Re: help needed on ethernet packet access on BSD4.3unix Re: scsi rll trade off questions? Lots of zombies on HP-UX (2.1, 3.1), all children of remshd Re: at files and permissions ----------------------------------------------------------------- From: Rahul Dhesi Subject: Re: Algorithm needed: reading/writing a large file Date: 7 Jul 89 17:44:49 GMT To: unix-wizards@sem.brl.mil In article <205@larry.sal.wisc.edu> jwp@larry.sal.wisc.edu (Jeffrey W Percival) writes: [how do I sort a large file that won't fit in memory?] There are many variations on the merge sort. Here is a simple one: break up the original file into N smaller files sort each smaller file merge them all -- Rahul Dhesi UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi ----------------------------- From: Steve Harris Subject: Re: What kinds of things would you want in the GNU OS? Date: 6 Jul 89 22:55:52 GMT To: unix-wizards@sem.brl.mil In article <1549@salgado.Solbourne.COM> dworkin@Solbourne.com (Dieter Muller) writes: >I'd *really* like a sane tty driver. Hear hear!! At a former job we talked a lot about how we would rewrite the tty driver. One idea was to give the user, via ioctl's, access to the uart (or whatever serial-line multiplexer you have). One ioctl to get the uart settings (in a bit vector), another to set them, and another to have the driver(??) send you a signal (for which you would have to write the appropriate handler) whenever any of the bits changed (e.g., DTR was deasserted). Standard configurations (handlers) would be privided in a library. Of course, one would be limited by the capabilities of the uart, but the design would assume total access to be possible. A second idea is "copy-on-write symbolic links" -- I have a symlink: bar -> foo When I write to it, a regular file "bar" is created (the symlink is destroyed), the contents of foo (up to the current file-pointer-offset) are copied to bar, and the write takes place. I'm not sure what happens if foo is not a regular file. -- Steve Harris -- Eaton Corp. -- Beverly, MA -- uunet!etnibsd!vsh ----------------------------- From: Nick Cuccia Subject: Quotas in the Real World [TM] (was: Re: chown) Date: 8 Jul 89 04:32:47 GMT Sender: news@sybase.sybase.com Keywords: quotas, filesystems, bsd To: unix-wizards@sem.brl.mil In article <4893@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <18414@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: >> The restriction is not bogus, because the system supports disk quotas. > >This assume that disk quotas are not bogus in a production environment. >That is, outside a university... Think about two or more administrative groups divvying up a large disk partition. (The real solution, of course, is to buy more disks (not always practical from a financial point-of-view) or to repartition the existing disk (not always practical, due to either limitations caused by different vendors or the downtime required to repartition the existing disk). But I digress...). Under such a system, quotas (or, something almost like, but not exactly like the BSD or Sun quotas mechanisms) provide the answer. The problem that I have with the current quotas implementations is that they're too limited in scope. For the problem above, the current implementations are useful--as long as the members of each group are mutually exclusive (if your groups are beancounters and developers, then that assumption is probably valid). If, however, you have the more common situation of users being members of multiple groups (three groups working on the same application suite: one on front ends, another on servers and back ends, and the other on networking support. While the first two groups may have a fairly small intersecting set with each other, they'd each have quite a bit of intersection with the third), then you fall into the nightmare of adjusting a user in the intersecting set's quotas so that his quota doesn't cause any of his groups' quotas to be exceeded. The fix is conceptually simple: allow for quota-by-group, as well as quota-by- user. --Nick =============================================================================== Some days, you just can't get rid of a bomb...--Batman Nick Cuccia System Admin/Postmaster, Sybase, Incorporated cuccia@sybase.com 6475 Christie Av. Emeryville, CA 94608 {sun,lll-tis,pyramid,pacbell}!sybase!cuccia +1 415 596-3500 =============================================================================== ----------------------------- From: terryl@tekcrl.labs.tek.com Subject: Re: help needed on ethernet packet access on BSD4.3unix Date: 7 Jul 89 20:53:56 GMT Followup-To: comp.protocols.tcp-ip To: unix-wizards@sem.brl.mil In article <11530@orstcs.CS.ORST.EDU+ anoop@guille.ece.orst.edu (Anoop R. Hegde) writes: + +( My apologies if this posting is not very relevant to this newsgroup, + but i am sure, some of you have worked on a new protocol implementation) + + + We have a MicroVax II running BSD4.3 UNIX. I am trying to + develope a new protocol parallel to IP, to be used in the + local ethernet environment. ( to be specific, i would like + to write programs that can receive an ethernet packet carrying + an experimental 'type' field, so that I can set up communication + between this machine and any other machine connected to the same + ethernet) Obviously, this can't be done using sockets, (even raw) + as, they don't allow access below IP level. I would be very much + thankful if someone can provide me with some more info. on this + matter, or atleast a pointer to pursue. + ( we have the kernel source code, and it would be of much + help if i know where is packet demultiplexing done and which files + to look into, etc. ) Having done this exact thing quite a few years back for 4.2, the place you need to look at is the device driver level. Specifically, you need to look at two separate places: the output routine for the driver for packets going out on the ethernet, and the input interrupt routine for packets coming in from the ethernet. In the output routine, you key on the sa_family member of a struct sockaddr; suffice it to say you'll have to examine the code closely to see what I mean. In the input interrupt routine, you key on the actual ethernet type field in the packet itself. Again, examine the code. For VAX stuff, look in vaxif/if_il.c (for an Interlan driver) at the routines iloutput and ilrint for the output and input interrupt routines, respectively. ----------------------------- From: Byron Lunz Subject: Re: scsi rll trade off questions? Date: 8 Jul 89 03:54:34 GMT Followup-To: comp.sys.ibm.pc Keywords: scsi rll hard disk compatability To: unix-wizards@sem.brl.mil In article <14978@ut-emx.UUCP> allred@ut-emx.UUCP (Kevin L. Allred) writes: >I'm putting together a low end workstation for my personal use at home. >It will have a 386SX, 4MB memory and monochrome VGA graphics. ... >I was only considering an RLL drive with 1:1 interleve controller until >I had pointed out to me that Segate has recently started marketing a >low cost SCSI addaptor (ST01 and ST02) suitable for use with its >ST296N 80MB hard disk. This combination reportedly offeres about 750 >KB/sec transfer rate, which is comparable to the 1:1 interleve RLL >transfer rate, and it is more cost effective. Apparently the SCSI I received my new Gateway 2000 386/20 a few days ago. It arrived with a Seagate ST296N and SCSI controller (not sure of the model #). Transfer rate was one of my reasons for purchasing this system, and I was assured prior to the purchase by the salesperson that I could expect 800KB/sec. I was quite disappointed when both Spintest and Coretest 2.7 gave me data transfer rates of 440-460KB/sec! Then, just today Mark Davis , reported that some users are seeing transfer rates of 950KB/sec! The interesting part is that when I called Gateway, the salesman immediately began reciting what sounded like a prepared statement to the effect that Seagate had lied to them! Then he quickly offered me a ST4096/DTC controller combo as a replacement, with a transfer rate of 550KB/sec. It's in the mail. If someone out there is actually seeing transfer rates around or over 800KB/sec, I'd sure like to hear about it. P.S. The drive documentation supplied with my system says the interleave is 1:1. And the access time, rated at 28ms, is measured at 33.7ms by Coretest. -- Byron Lunz Tektronix Logic Analyzer Division byronl@copper.MDP.TEK.COM Beaverton, Oregon ----------------------------- From: Tor Lillqvist Subject: Lots of zombies on HP-UX (2.1, 3.1), all children of remshd Date: 6 Jul 89 09:35:55 GMT To: unix-wizards@sem.brl.mil We are experiencing lots of zombie processes on an HP9000 Series 800 running HP-UX 3.1 (the same occurred also in 2.1 and 3.01). They are all children of remshd (rshd in BSD) processes (which have no other children). All these remshds are sleeping on selwait. We have a configuration with a bunch of Series 300 workstations running X clients on the 840. Right now, for instance, there are 25 of these zombies when the system has been up for three days, with perhaps ten active workstation users. What could be the problem? Is there any cure, except writing a perl script that scans ps now and then, and kills off remshd processes with a zombie child? -- Tor Lillqvist Technical Research Centre of Finland, Computing Services (VTT/ATK) tml@hemuli.atk.vtt.fi [130.188.52.2] ----------------------------- From: Bob Wilber Subject: Re: at files and permissions Date: 7 Jul 89 23:11:29 GMT To: unix-wizards@sem.brl.mil Chris Lewis writes: >"at" needs setuid root permissions so that it can write in the cron/at >spool directories. Actually, "at" shouldn't have to run setuid to root. A special user (say, "Mr.At") should be created to own the at spool directory, and "at" should run setuid to Mr.At. That way if someone discovers a security hole in "at" he only gains the power to delete other people's at files, he doesn't get to play super user. The real reason "at" is run setuid to root on System V is because of the infamous System V setuid(2) bug, wherein a process with a non-root effective id is not able to setuid to its real id if that real id is root. Because of this bug "at" must be run setuid to root so that root can use it. Bob Wilber ----------------------------- End of UNIX-WIZARDS Digest ************************** ---------- end of forwarded message