UNIX-WIZARDS Digest V5#072
Mike Muuss
Unix-Wizards-Request at arpa.brl
Sat Jun 18 17:45:19 AEST 1988
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 at athena.mit.edu>
Subject: Re: back to the (ivory) tower (alloca)
Date: 17 Jun 88 03:26:23 GMT
Sender: daemon at bloom-beacon.mit.edu
To: unix-wizards at 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 at adam.pika.mit.edu
-----------------------------
From: Steve Summit <scs at athena.mit.edu>
Subject: Re: In defense of BSD
Date: 17 Jun 88 03:33:30 GMT
Sender: daemon at bloom-beacon.mit.edu
To: unix-wizards at 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 at adam.pika.mit.edu
-----------------------------
From: Doug Alan <nessus at athena.mit.edu>
Subject: I want my bug-free NFS patch!
Date: 17 Jun 88 04:44:13 GMT
Sender: uucp at eddie.mit.edu
To: unix-wizards at 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 at athena.mit.edu
nessus at 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 at watdragon.waterloo.edu>
Subject: help...
Date: 15 Jun 88 18:05:35 GMT
To: unix-wizards at 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 at 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 at SEM.BRL.MIL
In article <515 at yunexus.UUCP>, oz at 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 at 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 at 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 at 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 at SEM.BRL.MIL
In article <564 at tuck.nott-cs.UUCP>, anw at 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 at mcgill-vision.uucp
arpa: mouse at larry.mcrcim.mcgill.edu
-----------------------------
From: der Mouse <mouse at 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 at SEM.BRL.MIL
In article <16100 at brl-adm.ARPA>, rbj at icst-cmr.arpa (Root Boy Jim) writes:
[Other attributions are Neil Webber <nw at palladium.uucp> and
ted%nmsu.csnet at 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 at mcgill-vision.uucp
arpa: mouse at larry.mcrcim.mcgill.edu
-----------------------------
From: Barry Shein <bzs at bu-cs.bu.edu>
Subject: Re: Woes of absolute path names in tar
Date: 17 Jun 88 18:58:47 GMT
To: unix-wizards at 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 at 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 at 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 at linc.cis.upenn.edu>
Subject: Spooling to an Encore annex via lpd
Date: 17 Jun 88 17:02:27 GMT
Sender: news at super.upenn.edu
Keywords: Done it? Transcript 2.1 Advice?
To: unix-wizards at 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 at linc.cis.upenn.edu
-----------------------------
From: Gary Allen <gallen at apollo.uucp>
Subject: Re: Yet Another OSF Question (YAOQ)
Date: 13 Jun 88 16:38:00 GMT
Keywords: OSF
To: unix-wizards at SEM.BRL.MIL
In article <242 at iconsys.UUCP> ron at 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 at 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 at 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 at SEM.BRL.MIL
In article <6963 at cit-vax.Caltech.Edu> mangler at cit-vax.Caltech.Edu (Don Speck) writes:
<In article <23326 at bu-cs.BU.EDU>, bzs at 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 at 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 at mn-at1.k.mn.org
Ph: +1 612 626 1836 ARPA: alan at uc.msc.umn.edu (was umn-rei-uc.arpa)
(*) An affiliate of the University of Minnesota
-----------------------------
From: Guy Harris <guy at gorodish.sun.com>
Subject: Re: lp/lpr interface
Date: 17 Jun 88 21:29:58 GMT
Sender: news at sun.uucp
To: unix-wizards at 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 at steinmetz.ge.com>
Subject: Re: grep replacement
Date: 17 Jun 88 18:16:12 GMT
To: unix-wizards at 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 at ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
-----------------------------
From: "William E. Davidsen Jr" <davidsen at steinmetz.ge.com>
Subject: Re: lp/lpr interface
Date: 17 Jun 88 18:40:47 GMT
To: unix-wizards at brl-sem.arpa
In article <56808 at sun.uucp> guy at 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 at ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
-----------------------------
From: "Gil Kloepfer Jr." <gil at limbic.uucp>
Subject: Re: Parodies
Date: 17 Jun 88 03:42:22 GMT
To: unix-wizards at brl-sem.arpa
[Parodies by previous authors deleted]
|>? der Mouse
|>?
|>? uucp: mouse at mcgill-vision.uucp
|>? arpa: mouse at larry.mcrcim.mcgill.edu
|>
|> (Root Boy) Jim Cottrell <rbj at 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 at limbic.UUCP |
+------------------------------------+----------------------------------------+
-----------------------------
From: "Brandon S. Allbery" <allbery at 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 at SEM.BRL.MIL
As quoted from <16072 at brl-adm.ARPA> by enag at 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 at 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 at brl-sem.arpa
As quoted from <5757 at umn-cs.cs.umn.edu> by indermau at 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 at 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 at brl-sem.arpa
As quoted from <5775 at megaron.arizona.edu> by lm at arizona.edu (Larry McVoy):
+---------------
| In article <7933 at ncoast.UUCP> allbery at 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 at brl-smoke.arpa>
Subject: Re: Re: grep replacement
Date: 18 Jun 88 01:59:17 GMT
To: unix-wizards at SEM.BRL.MIL
In article <540 at sering.cwi.nl> fmr at cwi.nl (Frank Rahmani) writes:
>> In article <8012 at brl-smoke.ARPA>, gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
But I didn't. (I think it was BZS.) PLEASE, check your attributions!
-----------------------------
From: Doug Gwyn <gwyn at brl-smoke.arpa>
Subject: Re: context diff and patch
Date: 18 Jun 88 02:10:30 GMT
To: unix-wizards at brl-sem.arpa
In article <954 at fig.bbn.com> rsalz at 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 at brl-smoke.arpa>
Subject: Re: I want my bug-free NFS patch!
Date: 18 Jun 88 02:15:32 GMT
To: unix-wizards at brl-sem.arpa
In article <9514 at eddie.MIT.EDU> nessus at 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 at BRL.MIL might still reach him.
-----------------------------
From: Doug Gwyn <gwyn at 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 at brl-sem.arpa
In article <441 at mn-at1.k.mn.org> alan at 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 at 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 at 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 at augean.oz>
Subject: Re: "Open" Software Foundation: GNU
Date: 14 Jun 88 07:04:02 GMT
To: unix-wizards at SEM.BRL.MIL
In article <1144 at mcgill-vision.UUCP> mouse at mcgill-vision.UUCP (der Mouse) writes:
->In article <5910001 at hplsla.HP.COM>, jima at 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 at augean.oz
-----------------------------
From: Greg Bond <greg at vertical.oz>
Subject: Re: Magic symlink syntax
Date: 16 Jun 88 07:22:20 GMT
Keywords: nami hack, namei hack
To: unix-wizards at brl-sem.arpa
In article <2371 at quacky.mips.COM> dce at 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 at vertical.oz.au (or greg%vertical.oz.au at 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 at pdnbah.uucp>
Subject: Re: grep replacement (filenames, maybe)
Date: 17 Jun 88 13:44:13 GMT
Sender: news at pdn.uucp
To: unix-wizards at brl-sem.arpa
In article <540 at sering.cwi.nl> fmr at 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 at brl-smoke.ARPA>, gwyn at 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 at pdn.UUCP
PO Box 2826, 8550 Ulmerton Road UUCP ...!uunet!pdn!wolfe
Largo, FL 34649-2826 PHONE (813) 530-8361
-----------------------------
From: "S.RAVIKUMAR" <iluvu at homxc.uucp>
Subject: troff/mm - question
Date: 17 Jun 88 18:06:21 GMT
Keywords: pic, figure caption
To: unix-wizards at 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 at research.att.com
-----------------------------
End of UNIX-WIZARDS Digest
**************************
More information about the Comp.unix.wizards
mailing list