postmaster@uunet.uu.net (06/20/88)
Reason: local mail handler complained as follows jmail: HuwR -- unknown user or mailbox -------- rejected letter --------- Via: 00004001015218/UCL-CS.FTP.MAIL ; 19 Jun 1988 17:56:16 GMT Received: from NSS.CS.UCL.AC.UK by NSS.Cs.Ucl.AC.UK via List-Channel id aa02862; 19 Jun 88 13:38 BST Received: from sem.brl.mil by NSS.Cs.Ucl.AC.UK via Satnet with SMTP id aa02788; 19 Jun 88 13:25 BST Received: from SEM.BRL.MIL by SEM.BRL.ARPA id aa17417; 18 Jun 88 2:56 EDT Received: from sem.brl.mil by SEM.BRL.ARPA id aa17379; 18 Jun 88 2:45 EDT Date: Sat, 18 Jun 88 02:45:19 EST From: The Moderator (Mike Muuss) <Unix-Wizards-Request@arpa.brl> To: UNIX-WIZARDS@arpa.brl Reply-To: UNIX-WIZARDS@arpa.brl Subject: UNIX-WIZARDS Digest V5#072 Message-ID: <8806180245.aa17379@SEM.BRL.ARPA> Sender: unix-wizards-request@uk.ac.ucl.cs.nss 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 **************************