Unix-Wizards-Request@arpa.brl (Mike Muuss) (06/18/88)
UNIX-WIZARDS Digest Sat, 18 Jun 1988 V5#072
Today's Topics:
Re: back to the (ivory) tower (alloca)
Re: In defense of BSD
I want my bug-free NFS patch!
help...
Re: grep replacement (backref in egrep ?? whoa!)
Re: grep replacement
Re: Woes of absolute path names in tar
Re: alloca (was back to the (ivory) tower)
Re: Woes of absolute path names in tar
help on uucp status files
Spooling to an Encore annex via lpd
Re: Yet Another OSF Question (YAOQ)
Why UNIX I/O is so slow (was VAX vs SUN 4 performance)
Re: lp/lpr interface
Re: grep replacement
Re: lp/lpr interface
Re: Parodies
Re: Implementation of alloca() and friends
Re: another question about dump & restore
Re: Speaking of Unix, unbundling, etc...
Re: Re: grep replacement
Re: context diff and patch
Re: I want my bug-free NFS patch!
Re: Why UNIX I/O is so slow (was VAX vs SUN 4 performance)
Re: Crypt algorithm status.. one more time
Re: "Open" Software Foundation: GNU
Re: Magic symlink syntax
Re: grep replacement (filenames, maybe)
troff/mm - question
-----------------------------------------------------------------
From: Steve Summit <scs@athena.mit.edu>
Subject: Re: back to the (ivory) tower (alloca)
Date: 17 Jun 88 03:26:23 GMT
Sender: daemon@bloom-beacon.mit.edu
To: unix-wizards@SEM.BRL.MIL
I generally shy away from "edge of the envelope" functionality,
even if documented and "official": like right-of-way rules, the
"official"ness doesn't help you much when you get burned.
I've used alloca exactly once, and I submit that I had no
alternative: it was exactly the right thing to use for allocating
the space for the local variables of the function being
interpreted by a C interpreter I wrote once. An explicit
malloc/free wouldn't do, because of the possibility that the
function being interpreted could call longjmp...
Steve Summit
scs@adam.pika.mit.edu
-----------------------------
From: Steve Summit <scs@athena.mit.edu>
Subject: Re: In defense of BSD
Date: 17 Jun 88 03:33:30 GMT
Sender: daemon@bloom-beacon.mit.edu
To: unix-wizards@brl-sem.arpa
I'd like to second the commendation of Berkeley's efforts, at the
risk of wasting some net bandwidth, but those guys out there at
Berkeley deserve it, because they have done an awful lot of work,
much of it good and most of it underappreciated. I've been
guilty of some gratuitous Berkeley-bashing myself, and I'm sorry,
because the Berkeley systems I've had the great pleasure of using
were, if flawed, still vastly preferable to the alternatives.
Steve Summit
scs@adam.pika.mit.edu
-----------------------------
From: Doug Alan <nessus@athena.mit.edu>
Subject: I want my bug-free NFS patch!
Date: 17 Jun 88 04:44:13 GMT
Sender: uucp@eddie.mit.edu
To: unix-wizards@SEM.BRL.MIL
I just installed a patch to NFS that allows you to mount the entire
filesystem of a remote computer, rather than having to mount all of
its individual disk partitions. The patch came from someone at BRL,
but the file I have, does not say who -- it only says that his first
name is Doug. Unfortunately, I have already noticed a bug or two.
The date of the patch I have is 26 Jan 1987.
The most prominent bug is as follows: Let's say the NFS server is
called "server" and you are using a client machine. 'server' has
several disk partions: /a, /b, and /c. On the client machine, you
have mounted server:/ on /@/server. You now cd to /@/server/c/foodir,
and do a 'pwd'. 'pwd' should tell you that you are in
/@/server/c/foodir. But instead of doing that, it says that you are
in /foodir. If you cd to /@/server/c/foodir/subdir, then pwd says
that you are in /foodir/subdir. In contrast, if you cd to
/@/server/etc, pwd tells you that you are in /@/server/etc -- which,
indeed, you are.
I have also just noticed another problem since installing this patch.
I cannot say whether or not this bug has always been there, or whether
it appeared upon installing this patch. This problem is intermittent
and I can not reproduce it on demand. I was looking at a text file
that was on the remote machine. Unfortunately, there appeared to be a
bunch of nulls on the end of the file that weren't really there. On
this particular file, the problem was reproducable for a while, but
eventually it stopped happening.
So, does anyone have a fix for the first problem mentioned above, or
know someone who does? And does anyone know whether or not the second
problem is caused by the patch and how I should fix it?
The computers involved are VAXstation II's running 4.3BSD+NFS (from U.
of Wisc.).
|>oug /\lan
(or nessus@athena.mit.edu
nessus@mit-eddie.uucp)
"Once more at dawn I drive
the weary cattle of my soul to the mud hole of your eyes"
-----------------------------
From: Lindsay Errington <dlerrington@watdragon.waterloo.edu>
Subject: help...
Date: 15 Jun 88 18:05:35 GMT
To: unix-wizards@SEM.BRL.MIL
I've been programming the UNIX computers here at Waterloo logged on to
the VT100. My friend told me that the UNIX computers can have more
than one person programming them at the same time. This is hard to
believe. He couldn't explain what would happen if two people weren't
doing the same program. How would the computer keep track of the
floppies? There would have to be more than one keypad, that doesn't
make sense.
On the other hand, I have sometimes noticed that the UNIX seems slow
during the day and fast at night. I figure that it's just because more
people are awake in the daytime and so there's less charge available
down at the power plant for us computer programmers.
He said to use the Pnews program to address comp.unix.wizards and try
to find out.
Many thanks wizards,
Lindsay.
-----------------------------
From: andrew@alice.uucp
Subject: Re: grep replacement (backref in egrep ?? whoa!)
Date: 16 Jun 88 05:29:23 GMT
Posted: Thu Jun 16 01:29:23 1988
To: unix-wizards@SEM.BRL.MIL
In article <515@yunexus.UUCP>, oz@yunexus.UUCP writes:
> Just how do you propose to implement the back-referencing trick in
> a properly constructed (nfa and/or nfa->dfa conversion static or
> on-the-fly) egrep ?? I presume that after each match of the
> \(reference\) portion, you would have to on-the-fly modify the \n
> portion of the fsa. Gack! Do you have a theoretically solid algorithm
> [say, within the context of Aho/Sethi/Ullman's Dragon Book chapter on
> regular expressions] for this ?? I would be much interested.
theoretically solid is not what i would call it but the algorithm is simple
enough once you have a subroutine for egrep that matches a pattern against
an input with a match of at least n input chars. you just do what you have to
do: an exponential back-tracking algorithm. thus, back-referencing is not done
inside the fsa, but as part of a (complicated0 control function. I realise
this sounds vague but i can't give you the details until i do it. al aho has
done it and probably understands this stuff as well as anyone in the world.
-----------------------------
From: andrew@alice.uucp
Subject: Re: grep replacement
Date: 16 Jun 88 05:42:32 GMT
Posted: Thu Jun 16 01:42:32 1988
To: unix-wizards@brl-sem.arpa
i am not proposing that the world uses a diff without context;
just our world. it is rarely used in our center and we don't use patch.
and despite large address spaces and huge machines, we still believe
in trying to eliminate crud that is essentially never used. crud that is
not paged in is still crud. just remember, i am not trying to make you use
our (contextless) diff.
the point about contexts is that it is something you can do in many different
places with the output from many commands. this is what suggests that it
be a separate tool. it doesn't have to subsume all context tasks;
perhaps diff output just doesn't fit the mold. and complaints about
greps of standard input indicate that you need to think about whether
the context tool can handle pipe inputs and if it can't be done, then
context greps of standrd input don't fit the mold either.
-----------------------------
From: der Mouse <mouse@mcgill-vision.uucp>
Subject: Re: Woes of absolute path names in tar
Date: 17 Jun 88 17:44:56 GMT
Posted: Fri Jun 17 13:44:56 1988
To: unix-wizards@SEM.BRL.MIL
In article <564@tuck.nott-cs.UUCP>, anw@nott-cs.UUCP writes:
[stuff was archive with]
> copy old-dir /nicedisc/anw/archive
> : check that all is well, then ...
> rm -rf old-dir
[when attempting to restore]
> mkdir old-dir
> copy /nicedisc/anw/archive old-dir
> : Aaarrrggghhh! Lots of error messages
[This was because "copy" was....]
> echo copying from $1 to $2
> tar cvf - $1 | (cd $2; tar xfp -)
> [...] this is disastrous. If "$1" begins with "/", the right-hand
> "tar" overwrites the directory the left-hand "tar" is reading from,
> There are other bugs as well, but to cut a long story short,
> "/usr/bin/copy" *now* looks like this:
[long script. Many checks, in particular $1 must not begin with a
slash. Ultimately....]
> echo copying from "$1" to "$2"
> sleep 10
> tar cvf - "$1" | (cd "$2"; tar xfp -)
This still has problems. If, for example, I want to copy /foo/bar/baz
to /newfoo/bar/gleep, and I do it thus....
% copy /foo/bar/baz /newfoo/bar/gleep
copy: [error message about from directory must not begin with / here]
me: why in the name of poslfit not? Oh well....
% cd /
% copy foo/bar/baz newfoo/bar/gleep
...pause while it does it
%
I then find that it has actually copied foo/bar/baz/* to
newfoo/bar/gleep/foo/bar/baz/* instead of newfoo/bar/gleep/* as I
expected.
Now, all this aggravation, including the original one about the leading
slash, could have been avoided if only you'd done....
( cd "$1" ; tar cf - . ) | ( cd "$2" ; tar xvf - )
The code
FROM=`(cd "$1"; pwd)`
TO=`(cd "$2"; pwd)`
which appears to be intended to guard the subsequent checks against the
target being the same as, or a subdirectory of, the source, has other
problems. In particular, it assumes that all the directories in the
chain leading to $1 and $2 are readable, which is not necessarily true
(one or more of them may well be execute-only, causing pwd to fail).
As insurance against this sort of fun, *my* tar (plug plug) won't
extract rooted pathnames without a special flag. (It has other nice
features, like conforming to tar(5). No, stock tar doesn't, at least
not the ones available to me: 4.3BSD, mtXinu 4.3+NFS, Sun 3.5, and Iris
(version unknown).)
der Mouse
uucp: mouse@mcgill-vision.uucp
arpa: mouse@larry.mcrcim.mcgill.edu
-----------------------------
From: der Mouse <mouse@mcgill-vision.uucp>
Subject: Re: alloca (was back to the (ivory) tower)
Date: 17 Jun 88 18:16:28 GMT
Posted: Fri Jun 17 14:16:28 1988
To: unix-wizards@SEM.BRL.MIL
In article <16100@brl-adm.ARPA>, rbj@icst-cmr.arpa (Root Boy Jim) writes:
[Other attributions are Neil Webber <nw@palladium.uucp> and
ted%nmsu.csnet@relay.cs.net, but it's not clear who wrote what.]
> 2) function calling conventions -- unless alloca() is
> built into the C compiler it has to implemented as
> a C callable function, not an inline stack adjustment.
> It's hard to figure out exactly what you mean here.
I would imagine that he means more or less what he said. If alloca()
is not specially known to the compiler (ie, "built in"), it will
compile into a call to a function. It therefore can't be an inline
stack adjustment. That's all. (The function called will wind up
adjusting the stack, yes, but that's not "inline".)
der Mouse
uucp: mouse@mcgill-vision.uucp
arpa: mouse@larry.mcrcim.mcgill.edu
-----------------------------
From: Barry Shein <bzs@bu-cs.bu.edu>
Subject: Re: Woes of absolute path names in tar
Date: 17 Jun 88 18:58:47 GMT
To: unix-wizards@brl-sem.arpa
I once built a tape utility (under contract) which had the option of
passing all pathnames thru a user-provided awk program before being
used. This not only solves absolute pathname problems (trivially) but
also things like (relatively) foreign or just bogus names and the
possibility of just constructing arbitrarily fancy file selectors
(assuming that there's a way to give negative feedback, an empty
reply, just newline, would do to say "skip this file".)
Anyhow, the worst is absolute pathnames, but the suggestion above
should be little more than adding a flag and a popen() to tar.
-Barry Shein, Boston University
-----------------------------
From: "Chad R. Larson" <chad@anasaz.uucp>
Subject: help on uucp status files
Date: 16 Jun 88 20:23:25 GMT
Followup-To: comp.mail.uucp
Keywords: L_stat R_stat uucp
To: unix-wizards@SEM.BRL.MIL
How do you maintain the uucp status files?
That is, "uustat -Mall" generates something like:
anasaz 06/16-12:11 06/16-12:11 CONVERSATION SUCCEEDED
rayn 02/22-04:00 02/21-17:12 WRONG TIME TO CALL
anasza 04/20-00:13 04/19-23:51 BAD SYSTEM
I would like to get rid of that third entry (which is the result of a
typo) but retain the others. I know of no commands to do this.
The "uustat -c" command only seems to affect the R_stat file, not the
L_stat; and even if it did change L_stat it would remove the entry for
"rayn" along with "anasza". Do you know how this is supposed to be
done? If not, are the structures of the L_stat and R_stat files known so
I can write some kind of editor? Thanks in advance. As usual, e-mail
to address below unless you think your answer has global interest.
I'll summarize.
-crl
---------------
"I read the news today, oh boy!" --John Lennon
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| DCF, Inc. | UUCP: ...noao!mcdsun!nud!anasaz!dcfinc!chad |
| 14623 North 49th Place | Ma Bell: (602) 953-1392 |
| Scottsdale, AZ 85254 | Loran: N-33deg37min20sec W-111deg58min26sec |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Disclaimer: These ARE the opinions of my employer! |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------------------------
From: David Feldman <david@linc.cis.upenn.edu>
Subject: Spooling to an Encore annex via lpd
Date: 17 Jun 88 17:02:27 GMT
Sender: news@super.upenn.edu
Keywords: Done it? Transcript 2.1 Advice?
To: unix-wizards@SEM.BRL.MIL
I am currently trying to get lpd to spool through an annex UX port. Or,
I am at least thinking about it. The target device is a laserwriter
(SUN) running postscript. Supposedly, using Transcript 2.1 (which we have)
and the diffs to lpd supplied in the Annex UX 3.0 distribution this should
be possible. Has anyone done this? The big problem is that the laserwriter
talks to the Transcript printer filter quite a bit. We have enough trouble
getting a laserwriter to stay up over a serial line, although things are
supposed to be better under Transcript 2.1 . The source OSs in question
are Ultrix 2.0 on Vaxen, and IBM BSD 4.3 on RTs.
Does anybody have any better ideas about how to do this? One way is to
create a connection deamon that opens a port on an annex and feeds it to
a pty. I don't know if this is better, but it is straightforward, has a
tty-like interface that will work with lpd as-is, and has been done here at
Penn many times. If this is what I end up doing I will try to get an ftp
port service number assigned (we did this for a daemon that interfaces a
remote host and a local pty which speak different graphics languages - the
number is 149 - well, actually, Al Broscius did it).
Thanx for the help, in advance.
Dave Feldman
david@linc.cis.upenn.edu
-----------------------------
From: Gary Allen <gallen@apollo.uucp>
Subject: Re: Yet Another OSF Question (YAOQ)
Date: 13 Jun 88 16:38:00 GMT
Keywords: OSF
To: unix-wizards@SEM.BRL.MIL
In article <242@iconsys.UUCP> ron@iconsys.UUCP (Ron Holt) writes:
>If OSF is really "open", why haven't I see a phone number or address
>where I can contact them and ask questions rather than endlessly
>speculate? I realize that they are a relatively young organization
>but they will have to "open up" soon.
>
>--
>Ron Holt UUCP: {ihnp4,uunet,caeco}!iconsys!ron
>Software Development Manager ARPANET: icon%byuadam.bitnet@cunyvm.cuny.edu
>Icon International, Inc. BITNET: icon%byuadam.bitnet
>Orem, Utah 84058 PHONE: (801) 225-6888
Open Software Foundation
P.O. Box 545
Billerica, Ma. 01821-0545
(617)250-0035
-----------------------------
From: Alan Klietz <alan@mn-at1.k.mn.org>
Subject: Why UNIX I/O is so slow (was VAX vs SUN 4 performance)
Date: 17 Jun 88 19:16:32 GMT
Keywords: readahead, striping, file mapping
Posted: Fri Jun 17 14:16:32 1988
To: unix-wizards@SEM.BRL.MIL
In article <6963@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (Don Speck) writes:
<In article <23326@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes:
[why UNIX I/O is so slow compared to big mainframe OS]
A useful model is to partition the time spent by every I/O request
into fixed and variable length portions. tf is the fixed overhead to
reset the interface hardware, queue the I/O request, wait for the
data to rotate under the head (for networks, the time to process all
of the headers), etc. td is the marginal cost transferring a unit of
data (byte, block, whatever). The total I/O utilization of a channel
in this case is characterized by
n td
D = ------------
tf + n td
for n units of data. The lim D = 1.0.
n->inf
td is typically very small (microsecs), tf is typically orders
of magnitude higher (millisecs). The curve usually has a knee;
UNIX I/O is often on the left side of the knee while most mainframe
OS's are on the right side.
<For all the optimizations that these I/O processors are supposed to do,
<Unix rarely gives them the chance. Unless there's more than two requests
<outstanding at once, once they finish one, there's only one request to
<choose from. Unix has minimal readahead, so that's as many requests as
<a single process can generate. Raw I/O is even worse.
Yep, Unix needs to do larger I/O transfers. Case in point: the Cray-2
has a 16 Gbyte/sec I/O throughput capability with incredibly expensive
80+ Mbit/s parallel-head disks (often stripped). And yet, typing
cp bigfile bigfile2
measures a transfer performance of only 18 Mbit/s, because BUFSIZ is 4K.
<Asynchronous reads would be the obvious way to get enough requests in
<the queue to optimize, but that seems unlikely to happen. Rather,
<explicit read commands are giving way to memory-mapped files (in Mach
<and SunOS 4.0) where readahead becomes synonymous with prepaging. It
<remains to be seen whether much attention is put into this.
There have been comments that SunOs 4.0 I/O overhead is 2 or 3 times
greater than under 3.0. Demand paged I/O introduces all of the Turing
divination problems of trying to predict which pages (I/O blocks) the
program will use next. IMHO, this is a step backward.
<Barry credits the asynchronous nature of I/O on mainframe OS's to the
<access methods, like RMS on VMS. People avoid those when they want
<speed (imagine using dbm to do sequential reads). For instance, the
<VMS "copy" command bypasses RMS when copying disk-to-disk, with the
<curious result that it's faster to copy to a disk than to the null
<device, because the null device is record-oriented, requiring RMS.
RMS systems developed through evolution ("survival of the fastest?")
to their current state of being I/O marvels. Hence MVS preallocation
requirements, VMS, asynch channel I/O, etc.
<As DMR demonstrates, parallel-transfer disks are great for big files.
<They're horrendously expensive though, and it's hard enough to find
<controllers that keep up with even 3 MB/s, much less 10 MB/s.
Disk prices are dropping fast. 8" 1 Gb dual-head disks (6 MB/s) will be
common in about a year for $5000-$9000 qty 1. The ANSI X3T9 IPI
(Intelligent Peripheral Interface) is now a full standard. It starts
at 10 Mb/s and goes up to 25 Mb/s in the current configurations.
N.B. the vendors pushing this standard are: IBM, CDC, Unisys, Fujitsu,
NEC, Hitachi, (big mainframe manufacturers). Unix in its current
incarnation is unable to take advantage of this new disk technology.
<they can be simulated with ordinary disks by striping across multiple
<controllers, *if* the disks rotate as one. Does anyone know of a cost-
<effective disk that can phase-lock its spindle motor to that of a second
<disk, or perhaps with the AC line? With direct-drive electronically-
<controlled motors becoming common, this should be possible. The Eagle
<has such a motor, but no provision for external sync. I recall stories
<of Cray's using phase-locked disks to advantage.
The thesis in my paper "Turbo NFS" (*) shows how you can get good
I/O performance without phase-locked disks by reorganizing the
file system contiguously. Cylinders of data are prefetched from
selected disks at a rate commensurate with the rate of which the
data is consumed by the program. Extents are allocated contiguously
by powers of 2. The organization is called a "fractal file system".
Phillip Koch did the original work in this area (**).
<Of course, to get the most from high transfer rates, you need large
<blocksizes; DMR's example looked like about one revolution. Hence
<the extent-based file allocation of mainframe OS's, etc. Perhaps
<it's time to pester Berkeley to double MAXBSIZE to 16384 bytes?
Berkeley should start over. The whole business with "cylinder groups"
tries to keep sets of blocks relatively near each other. With the new
disks today, the average SEEK TIME IS OFTEN FASTER THAN THE ROTATIONAL
DELAY. You don't want to keep blocks "near" each other, instead you want
to make each extent as large as possible. Sorry, but cylinder groups are
archaic.
<The one point that nobody mentioned is that you don't want the CPU
<copying the data around between kernel and user address spaces when
<there's a lot! (Maybe it was just too obvious).
Here is an area where paged I/O has an advantage. The first UNIX vendor
to do contiguous file systems + paged I/O + prefetching will win big in
the disk I/O race.
<Don Speck speck@vlsi.caltech.edu {amdahl,ames!elroy}!cit-vax!speck
(*) "Turbo NFS: Fast Shared Access for Cray Disk Storage", A. Klietz
(MN Supercomputer Center) Proceedings of the Cray User Group, Spring 1988.
(**) "Disk File Allocation Based on the Buddy System", P. D. L. Koch
(Dartmouth) ACM TOCS, Vol 5, No 3, November 1987.
--
Alan Klietz
Minnesota Supercomputer Center (*)
1200 Washington Avenue South
Minneapolis, MN 55415 UUCP: alan@mn-at1.k.mn.org
Ph: +1 612 626 1836 ARPA: alan@uc.msc.umn.edu (was umn-rei-uc.arpa)
(*) An affiliate of the University of Minnesota
-----------------------------
From: Guy Harris <guy@gorodish.sun.com>
Subject: Re: lp/lpr interface
Date: 17 Jun 88 21:29:58 GMT
Sender: news@sun.uucp
To: unix-wizards@SEM.BRL.MIL
> My system has a device...
But if you *don't* have such a device, and you don't have a UUCP that can
directly open TCP connections, you're out of luck.
-----------------------------
From: "William E. Davidsen Jr" <davidsen@steinmetz.ge.com>
Subject: Re: grep replacement
Date: 17 Jun 88 18:16:12 GMT
To: unix-wizards@SEM.BRL.MIL
If you are able to use "diff -e" you mush have a diferrent version than
I do... The one I have generates refs to absolute line numbers, and is
useless for applying any patches if the source has been modified, even
in other parts of the program.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
-----------------------------
From: "William E. Davidsen Jr" <davidsen@steinmetz.ge.com>
Subject: Re: lp/lpr interface
Date: 17 Jun 88 18:40:47 GMT
To: unix-wizards@brl-sem.arpa
In article <56808@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
| If you have a UUCP that works over e.g. TCP on both sides; the current SunOS
| one doesn't support TCP connections.
But it does... no change in uucp is needed. My system has a device
which has the characteristic of reading the first line sent after an
open and doing a telnet connection to that machine. All it takes is an
L.sys line something like:
machine Any ttyT16 9600 ttyT16 "" machine gin:--gin: uuxxx ord: yyy
and you get a connection to uucico coming in on the telnet socket, which
uucico can't tell from a serial connection. I *think* it can be done
without a special device if your system allows you to write your own
dialer, but I haven't felt the need to try it.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
-----------------------------
From: "Gil Kloepfer Jr." <gil@limbic.uucp>
Subject: Re: Parodies
Date: 17 Jun 88 03:42:22 GMT
To: unix-wizards@brl-sem.arpa
[Parodies by previous authors deleted]
|>? der Mouse
|>?
|>? uucp: mouse@mcgill-vision.uucp
|>? arpa: mouse@larry.mcrcim.mcgill.edu
|>
|> (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
|> National Bureau of Standards
|> Flamer's Hotline: (301) 975-5688
|> The opinions expressed are solely my own
|> and do not reflect NBS policy or agreement
|> My name is in /usr/dict/words. Is yours?
Here's one that came from a friend of mine a long time ago...
"Oh, PDP"
(Sung to the tune of "Oh, Christmas Tree")
Oh PDP, Oh PDP
We know you crash consistently.
Oh PDP, Oh PDP
We know you crash consistently.
Not only in the daytime bright
But when I'm on from home at night.
Oh PDP, Oh PDP
We know you crash consistently.
Well, it's short but cute. Hope you enjoyed it.
+------------------------------------+----------------------------------------+
| Gil Kloepfer, Jr. | Net-Address: |
| ICUS Software Systems | {boulder,talcott}!icus!limbic!gil |
| P.O. Box 1 | Voice-net: (516) 968-6860 |
| Islip Terrace, New York 11752 | Othernet: gil@limbic.UUCP |
+------------------------------------+----------------------------------------+
-----------------------------
From: "Brandon S. Allbery" <allbery@ncoast.uucp>
Subject: Re: Implementation of alloca() and friends
Date: 17 Jun 88 23:39:32 GMT
Followup-To: comp.unix.wizards
To: unix-wizards@SEM.BRL.MIL
As quoted from <16072@brl-adm.ARPA> by enag@ifi.uio.no on dynamic arrays:
+---------------
| Doesn't this look very clumsy to do in such a neat language as C?
| Having to remember dimensions and their individual sizes (even opening
| up for bounds checking - shock horror! :-), and building nasty access
| poly(g)nomes requiring lots of CPU time even for tiny little two-
| dimensional matrices... It sounds Wrong to me. Also, the bugs that
| will appear because people forget to pass along the dimensions of their
| conformant arrays -- leading all the way to sending a pointer to an
| array descriptor structure, slowing down all the code we're so proud
| of.
+---------------
Why not allocate matrix[n][m] by allocating an array[n], then set each element
to a pointer to an array[m]? This makes the [] operator work exactly the way
it does everywhere else: x[n] == *(x + n) without having to do hairy
calculations to access an element of an n-dimensional matrix. No more likely
to have bounds checking than any other part of C. ;-)
++Brandon
--
Brandon S. Allbery | "Given its constituency, the only
uunet!marque,sun!mandrill}!ncoast!allbery | thing I expect to be "open" about
Delphi: ALLBERY MCI Mail: BALLBERY | [the Open Software Foundation] is
comp.sources.misc: ncoast!sources-misc | its mouth." --John Gilmore
-----------------------------
From: "Brandon S. Allbery" <allbery@ncoast.uucp>
Subject: Re: another question about dump & restore
Date: 17 Jun 88 23:47:13 GMT
Followup-To: comp.unix.wizards
To: unix-wizards@brl-sem.arpa
As quoted from <5757@umn-cs.cs.umn.edu> by indermau@dg (Kurt Indermaur):
+---------------
| In the man pages for restore, under "BUGS", is the sentence "Restore can get
| confused when doing incremental restores from dump tapes that were made on
| active file systems." What is an "active file system"? Nobody logged in?
| Single user mode?
+---------------
A file system is active if it's mounted. It *is* possible to dump a mounted
file system if you sync beforehand and make absolutely *certain* that nobody
does *anything* on the filesystem -- even "echo /being-dumped/*" can screw
things up, as the st_atime of the directory /being-dumped will be updated.
--
Brandon S. Allbery | "Given its constituency, the only
uunet!marque,sun!mandrill}!ncoast!allbery | thing I expect to be "open" about
Delphi: ALLBERY MCI Mail: BALLBERY | [the Open Software Foundation] is
comp.sources.misc: ncoast!sources-misc | its mouth." --John Gilmore
-----------------------------
From: "Brandon S. Allbery" <allbery@ncoast.uucp>
Subject: Re: Speaking of Unix, unbundling, etc...
Date: 18 Jun 88 00:08:12 GMT
Followup-To: comp.unix.wizards
To: unix-wizards@brl-sem.arpa
As quoted from <5775@megaron.arizona.edu> by lm@arizona.edu (Larry McVoy):
+---------------
| In article <7933@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes:
| >Given, the file system switch. We also have header files for both the
| >"generic" data structures and the S51K file system. We also get the ability
| >to relink the kernel with our own additions.
| >
| >Query: Is it too much to ask that some kind of information be available to
| >show how one would write one's own filesystem code for the FSS *for a
| >particular implementation*?
|
| It's pretty easy, actually. Take a look at /usr/src/uts/???/fs/s5 and at
| (on an eta machine :-) .../cf/lboot_cf.c (on other machines this will vary,
> ...
| I assume, of course, that you have source. And my point is that the source
| is your best documentation (flames to /dev/whiners).
+---------------
No, I will *not* exile myself to /dev/whiners, even though all you lordly
beings who have source wish we would go away. It may be time to organize a
PD Posix implementation working group (it has been pointed out to me that Gnu
may well not be Posix-compatible) -- because many if not most of those who
run Unix *can't* *afford* source: we aren't universities eligible for
educational licenses and we aren't huge companies to which $65,000 is
peanuts.
--
Brandon S. Allbery | "Given its constituency, the only
uunet!marque,sun!mandrill}!ncoast!allbery | thing I expect to be "open" about
Delphi: ALLBERY MCI Mail: BALLBERY | [the Open Software Foundation] is
comp.sources.misc: ncoast!sources-misc | its mouth." --John Gilmore
-----------------------------
From: Doug Gwyn <gwyn@brl-smoke.arpa>
Subject: Re: Re: grep replacement
Date: 18 Jun 88 01:59:17 GMT
To: unix-wizards@SEM.BRL.MIL
In article <540@sering.cwi.nl> fmr@cwi.nl (Frank Rahmani) writes:
>> In article <8012@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
But I didn't. (I think it was BZS.) PLEASE, check your attributions!
-----------------------------
From: Doug Gwyn <gwyn@brl-smoke.arpa>
Subject: Re: context diff and patch
Date: 18 Jun 88 02:10:30 GMT
To: unix-wizards@brl-sem.arpa
In article <954@fig.bbn.com> rsalz@bbn.com (Rich Salz) writes:
>Using diff -e and ed are fine, as long as you are able to (naively) assume
>that nobody will add or delete a line to what you put out.
What I said was: In any context where I would trust "patch", I would also
trust "ed" using the output of "diff -e", which is generally much less output.
I would trust NEITHER "ed" nor "patch" when modifications have been made
to the original code. "patch" may be somewhat more likely to succeed in
such a case, but it obviously cannot be guaranteed to work right.
-----------------------------
From: Doug Gwyn <gwyn@brl-smoke.arpa>
Subject: Re: I want my bug-free NFS patch!
Date: 18 Jun 88 02:15:32 GMT
To: unix-wizards@brl-sem.arpa
In article <9514@eddie.MIT.EDU> nessus@athena.mit.edu (Doug Alan) writes:
>The patch came from someone at BRL, but the file I have, does not say who --
>it only says that his first name is Doug.
Probably Doug Kingston, who no longer works for BRL, although mail to
DPK@BRL.MIL might still reach him.
-----------------------------
From: Doug Gwyn <gwyn@brl-smoke.arpa>
Subject: Re: Why UNIX I/O is so slow (was VAX vs SUN 4 performance)
Date: 18 Jun 88 02:22:43 GMT
To: unix-wizards@brl-sem.arpa
In article <441@mn-at1.k.mn.org> alan@mn-at1.UUCP (0000-Alan Klietz) writes:
-Berkeley should start over. The whole business with "cylinder groups"
-tries to keep sets of blocks relatively near each other. With the new
-disks today, the average SEEK TIME IS OFTEN FASTER THAN THE ROTATIONAL
-DELAY. You don't want to keep blocks "near" each other, instead you want
-to make each extent as large as possible. Sorry, but cylinder groups are
-archaic.
Such considerations should lead to the conclusion that each type of
filesystem may need its own access algorithms (perhaps in an I/O
processor). This is easy to arrange via the File System Switch.
-----------------------------
From: ruth <ruth@mks.uucp>
Subject: Re: Crypt algorithm status.. one more time
Date: 16 Jun 88 15:00:42 GMT
Keywords: crypt DES Unix Enigma
To: unix-wizards@brl-sem.arpa
I am posting in response to your message concerning UNIX compatible versions
of Crypt. MKS advertises the MKS version of the Enigma and DES crypt
command in several MKS products (MKS Toolkit, MKS Vi, MKS Trilogy).
At MKS we make this claim of UNIX compatibility without the need of
UNIX licensing because we have created this software
entirely by ourselves working from first principles.
We found a useful source of information is the Bell Labs Tech. Journal
vol 63, no 8, part 2, which is entitled "File Security and
the UNIX Crypt Command" by Reeds and Weinberger. This article
served as a starting point for our efforts. MKS had to do
considerable tuning of parameters until the development team established
the exact values for some of the tables.
MKS has implemented two levels of compatibility in crypt:
1) the MKS Toolkit commands login and passwd use encrypted passwords (and
in fact the whole /etc/passwd) that is compatible with crypt(3)
2) The MKS Toolkit (and other products) crypt command has both UNIX
crypt(1) command rotor machine compatibility and industry standard
DES encryption.
Ruth Songhurst
Vice President Business Services
Mortice Kern Systems Inc.
(519) 884-2251
-----------------------------
From: Ian Dall <idall@augean.oz>
Subject: Re: "Open" Software Foundation: GNU
Date: 14 Jun 88 07:04:02 GMT
To: unix-wizards@SEM.BRL.MIL
In article <1144@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes:
->In article <5910001@hplsla.HP.COM>, jima@hplsla.HP.COM ( Jim Adcock) writes:
->
->> Well, as long as we're complaining about naming conventions, how
->> about complaining about "Free Software Foundation" ???
->However, gcc appears to be different. I don't have the gcc license on
->hand at the moment, but if it's as similar to the emacs license as I
->expect, a good case could be made that anything compiled with gcc (or
->*certainly* anything linked with the gcc-distribution library routines)
->cannot be distributed for-profit or otherwise contrary to Richard's
->ideals as embodied in the license.
Is the gcc licence agreement more restrictive than commercial (say AT&T
for example) compiler licences. On my system all the include files
have AT&T Copyright notices on them. My (binary only) licence doesn't
say anything about exemptions for libraries or include files. Arguably
giving/selling a program compiled on my system is redistributing stuff
that my licence forbids. It would have major ramifications for the
whole industry if anyone tried to enforce such an interpretation.
--
Ian Dall "In any argument there will be people on your
side who you wish were on the other side."
idall@augean.oz
-----------------------------
From: Greg Bond <greg@vertical.oz>
Subject: Re: Magic symlink syntax
Date: 16 Jun 88 07:22:20 GMT
Keywords: nami hack, namei hack
To: unix-wizards@brl-sem.arpa
In article <2371@quacky.mips.COM> dce@mips.COM (David Elliott) writes:
>This is the modification that allows one to put a variable inside of
>a symbolic link target so that people can choose default execution
>"universes" or "modes" or "system types".
What do you mean by a variable? How can such variables be set up so
that the kernel context can access them? Not shell variables,
obviously (as the process doing the system call is not in general a
shell), but even "environment" variables can be changed by the process
and I can't see how namei would know where to look for them.
A question from the curious but not source-equipped mind of...
--
Gregory Bond, Vertical Software, Melbourne, Australia
Internet: greg@vertical.oz.au (or greg%vertical.oz.au@uunet.uu.net)
Bang: {uunet,mcvax,pyramid,mnetor,ukc,ucb-vision,...}!munnari!vertical.oz!greg
I used to be a pessimist. Now I'm a realist.
-----------------------------
From: Mike Wolfe <wolfe@pdnbah.uucp>
Subject: Re: grep replacement (filenames, maybe)
Date: 17 Jun 88 13:44:13 GMT
Sender: news@pdn.uucp
To: unix-wizards@brl-sem.arpa
In article <540@sering.cwi.nl> fmr@cwi.nl (Frank Rahmani) writes:
>> Xref: mcvax comp.unix.wizards:8598 comp.unix.questions:6792
>> Posted: Fri Jun 10 05:29:43 1988
>>
>> In article <8012@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
>> A real useful `tool', this, that works only on files. And only when
>> you grep more than one file, so you get filenames (or happen to be able
>> to remember which flag it is to make grep print filenames always,
>> assuming of course that your grep has it).
>...
>...
>that's the smallest of all problems, just include /dev/null as first
>file to be searched
>into your script like
>grep [options] pattern /dev/null one_or_more_filenames
Smallest of all problems? One of my pet peeves is the fact that certain
commands will only print filenames if you give it more than one file. While
the /dev/null ugliness is a suitable kludge for the grep case what about
a case were you want to run something using xargs, something like sum. You
don't want /dev/null repeated for each call. I know I can sed it out but
that's just a kludge for a kludge and to me that's a red flag.
I think that all commands of that type should allow you to force the filenames
in output. I don't want to go back and change all the commands (UNIX++ a
modest proposal ;-). I just wish people would keep this in mind when writing
things in the future.
----
Mike Wolfe
Paradyne Corporation, Mail stop LF-207 DOMAIN wolfe@pdn.UUCP
PO Box 2826, 8550 Ulmerton Road UUCP ...!uunet!pdn!wolfe
Largo, FL 34649-2826 PHONE (813) 530-8361
-----------------------------
From: "S.RAVIKUMAR" <iluvu@homxc.uucp>
Subject: troff/mm - question
Date: 17 Jun 88 18:06:21 GMT
Keywords: pic, figure caption
To: unix-wizards@SEM.BRL.MIL
How would I center the picture as a block and the Figure
Caption as a single line in "mm". I tried the following
without success.
.DF
.DS CB
picture description
.DE
.DS C
.FG "Figure Caption"
.DE
.DE
Any suggestions welcome.
ravi
...!ihnp4!homxc!iluvu
iluvu%homxc@research.att.com
-----------------------------
End of UNIX-WIZARDS Digest
**************************