mail to xenurus.gould.com
postmaster at urbana.mcd.mot.com
postmaster at urbana.mcd.mot.com
Wed Jul 12 00:58:42 AEST 1989
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 at urbana.mcd.mot.com.
thank you for your cooperation,
postmaster at 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) <Unix-Wizards-Request at BRL.MIL>
To: UNIX-WIZARDS at BRL.MIL
Reply-To: UNIX-WIZARDS at BRL.MIL
Subject: UNIX-WIZARDS Digest V7#124
Message-Id: <8907090245.aa04012 at 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 <dhesi at bsu-cs.bsu.edu>
Subject: Re: Algorithm needed: reading/writing a large file
Date: 7 Jul 89 17:44:49 GMT
To: unix-wizards at sem.brl.mil
In article <205 at larry.sal.wisc.edu> jwp at 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 <dhesi at bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
-----------------------------
From: Steve Harris <vsh at etnibsd.uucp>
Subject: Re: What kinds of things would you want in the GNU OS?
Date: 6 Jul 89 22:55:52 GMT
To: unix-wizards at sem.brl.mil
In article <1549 at salgado.Solbourne.COM> dworkin at 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 <cuccia at yak.sybase.com>
Subject: Quotas in the Real World [TM] (was: Re: chown)
Date: 8 Jul 89 04:32:47 GMT
Sender: news at sybase.sybase.com
Keywords: quotas, filesystems, bsd
To: unix-wizards at sem.brl.mil
In article <4893 at ficc.uu.net> peter at ficc.uu.net (Peter da Silva) writes:
>In article <18414 at mimsy.UUCP>, chris at 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 at sybase.com 6475 Christie Av. Emeryville, CA 94608
{sun,lll-tis,pyramid,pacbell}!sybase!cuccia +1 415 596-3500
===============================================================================
-----------------------------
From: terryl at 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 at sem.brl.mil
In article <11530 at orstcs.CS.ORST.EDU+ anoop at 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 <byronl at copper.mdp.tek.com>
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 at sem.brl.mil
In article <14978 at ut-emx.UUCP> allred at 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
<davis at cs.unc.edu>, 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 at copper.MDP.TEK.COM
Beaverton, Oregon
-----------------------------
From: Tor Lillqvist <tml at hemuli.atk.vtt.fi>
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 at 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 at hemuli.atk.vtt.fi [130.188.52.2]
-----------------------------
From: Bob Wilber <wilber at alice.uucp>
Subject: Re: at files and permissions
Date: 7 Jul 89 23:11:29 GMT
To: unix-wizards at 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
More information about the Comp.unix.wizards
mailing list