Subject: Linux-Misc Digest #565
From: Digestifier <Linux-Misc-Request@senator-bedfellow.MIT.EDU>
To: Linux-Misc@senator-bedfellow.MIT.EDU
Reply-To: Linux-Misc@senator-bedfellow.MIT.EDU
Date:     Sun, 7 Aug 94 05:13:11 EDT

Linux-Misc Digest #565, Volume #2                 Sun, 7 Aug 94 05:13:11 EDT

Contents:
  Re: Coherent & Linux (Was : A Truly Unbiased Opinion) (Orc)
  Linux fragments easially (Nick Kralevich)
  Re: Linux vs. CP/M ? (Andrew Anderson)
  Re: 486DX66 and Linux (Andrew Anderson)
  Re: Motif for Linux (cheaper than $149 ????) (Bogdan Urma)
  Re: Linux book(s) (Jim Michael)
  Re: Coherent & Linux (Was : A Truly Unbiased Opinion) (Chris Mauritz)
  Re: source of TCP/IP (was I hope this wont ignite a major flame ...) (Wallace Roberts)
  UART's and slip (Matthew Osborne)
  Re: Doom on SGI -- wow! (Curt L. Olson (Admin))
  Re: utility for creating video modes for X? (cloister bell)

----------------------------------------------------------------------------

Crossposted-To: comp.os.coherent
From: orc@pell.com (Orc)
Subject: Re: Coherent & Linux (Was : A Truly Unbiased Opinion)
Date: Fri, 5 Aug 1994 22:53:05 GMT

In article <9408042225.16@rmkhome.com>, Rick Kelly <rmk@rmkhome.com> wrote:

>Every UNIX box has a tape drive.

   Well, if you don't count workstations or PC Unices, I'd be
willing to believe that.  (I've worked on Suns where the only way
to do backup was to find the one machine that has a tape drive and
nfs-mount my filesystems onto that machine, or call my home machine
and backup via a term connection.)

                 ____
   david parsons \bi/ Every Unix box has a CPU -- now that I'd believe.
                  \/

------------------------------

From: nickkral@po.EECS.Berkeley.EDU (Nick Kralevich)
Subject: Linux fragments easially
Date: 4 Aug 1994 00:09:55 GMT


I can't figure out why I have such a fragmented file
system.  I ran "frag", and came up with the following
results -- slackware 2.0.0, 1.1.37 kernel:

hercules:~# frag -s -s /

summary:
  16% file  fragmentation (695 of 4230 files contain fragments)
  28% block fragmentation (13094 of 46344 blocks are in fragments)
  10 files contain 561 blocks in holes

I'm not sure if these are normal figures, but I do not have a "crowded"
file system:

hercules:~# df /
Filesystem         1024-blocks  Used Available Capacity Mounted on
/dev/hda2             118230   51299    61020     46%   /

Witha about 61 megs free, I can't understand why it's so 
fragmented.  I was under the impression that the linux operating
system tried to keep the file system relatively defragmented.

I'm just wondering how this compares to everyone else's file
system, and if this is unusual.  I know that there is a defragger
at sunsite.unc.edu, somewhere or another.

Thanks for your help,
-- Nick Kralevich
   nickkral@cory.eecs.berkeley.edu


-- 
Nick Kralevich                        nickkral@cory.eecs.berkeley.edu
"A man sits with a pretty girl for an hour and it seems shorter than 
a minute.  But tell that same man to sit on a hot stove for a minute, 
it is longer than any hour.  That's relativity."  -- Einstein

------------------------------

From: andrew@amelia.db.erau.edu (Andrew Anderson)
Subject: Re: Linux vs. CP/M ?
Date: 7 Aug 1994 02:03:40 GMT

Dan Newcombe (newcombe@aa.csc.peachnet.edu) wrote:
: In article <31ousj$7um@charles.cdec.polymtl.ca> bouchard@info.polymtl.ca (Jean-Hugues Bouchard) writes:
: >        It is nothing; I am trying to port Linux on my commodore 64 (it is
: >for sale for 1500$ with the 1541 and 1802) A true multitask env with this
: >machine. I have been waiting for that a long time. Imagine all the
: >benchmark it will make. 

: Great...when you get it done, let me know.  Then I'll run it under the C64 
: emulator for DOS (or X Windows.)

: Oh, that would be good...Linux can now run ... ... LINUX!!!

You think that's bad -- I'm setting up a way for my users to telnet 
into a Novell Netware environment using DOSEMU.  In order to test it,
I have to login to Netware, so that I can telnet, so that I can
login to Netware! :)

--
|===========================================================================|
|  Andrew Anderson                              andersoa@erau.db.erau.edu   |
|  Novell Network System Administrator          andersoa@bart.db.erau.edu   |
|  Linux System Administrator                   andrew@wilbur.db.erau.edu   |
|                                                                           |
| I don't speak for ERAU, and God knows I don't want them to speak for me!  | 
|===========================================================================|

------------------------------

From: andrew@amelia.db.erau.edu (Andrew Anderson)
Subject: Re: 486DX66 and Linux
Date: 7 Aug 1994 02:06:08 GMT

Frank Derichsweiler (i31ade@applsrv.rz.unibw-muenchen.de) wrote:
: mai@vietgate.apana.org.au (Van Dao Mai) writes:

: >Folks,
: >   I recently upgraded to a 486DX-66 motherboard with 16M RAM (72 pins 
: >type). I recompile the kernel of Linux 1.1.35. The speed was impressive.
: >It takes 16 minutes in real time to compile the 5M of source codes.
: >   Working on the machine feel like working on a sparc 2 station. The 
: >only bit that is obviously slower is the hard disk access on the 
: >Western Digital 420M IDE.
: >   Can anyone tell me how long it takes to compile the kernel on DX-66
: >machines (and higher like DX4-100 or pentium)? It seems that the DX-66
: >is about 4 times the speed of a 386DX-40 with a math. co-processor.

: I own a Intel 486-66 Overdrive (same as 486 DX 2 - 66) and it takes around
: 20 minutes to compile the kernel

My Pentium 66 will do it in about 13 minutes.  Very nice, considering
that my old 386-33 w/ 4Megs RAM would take between 4 and 6 *HOURS*.

--
|===========================================================================|
|  Andrew Anderson                              andersoa@erau.db.erau.edu   |
|  Novell Network System Administrator          andersoa@bart.db.erau.edu   |
|  Linux System Administrator                   andrew@wilbur.db.erau.edu   |
|                                                                           |
| I don't speak for ERAU, and God knows I don't want them to speak for me!  | 
|===========================================================================|

------------------------------

From: bogdan@crl.com (Bogdan Urma)
Subject: Re: Motif for Linux (cheaper than $149 ????)
Date: 6 Aug 1994 19:13:05 -0700

Jorg Vogler (jv@speedy.looneytunes) wrote:
: Hi folks,

: I wonder whether there is any Motif 1.2.? distribution available which is
: cheaper than the SWiM and Metro Link.

: Thanks

: Joerg

: (jv@wg.com)
: --
To: jv@speedy.looneytunes (Jorg Vogler)
Subject: Re: Motif for Linux (cheaper than $149 ????)
Newsgroups: comp.os.linux.misc
Organization: CRL Dialup Internet Access        (415) 705-6060  [login: guest]

In article <JV.94Aug5160614@speedy.looneytunes> you wrote:
: Hi folks,

: I wonder whether there is any Motif 1.2.? distribution available which is
: cheaper than the SWiM and Metro Link.

: Thanks

: Joerg

: (jv@wg.com)
: --
    
     I've looked around also, and apparently these are the only 2 companies
which have Motif for Linux. I finally dished out the $149 and bought the
just released SWiM Motif 1.2.4 for Linux. The price may seem high in the 
Linux community, where users are used to getting software for free, but in
reality it's very little for such a fine product.

Bogdan
bogdan@crl.com


------------------------------

From: genepool@netcom.com (Jim Michael)
Subject: Re: Linux book(s)
Date: Fri, 5 Aug 1994 03:00:51 GMT

Dan Newcombe (newcombe@aa.csc.peachnet.edu) wrote:

: I will be happy when I can go into a bookstore downtown Atlanta and get a book 
: on Linux.  I'd probably get it whether I'd need it or not cause I'd think it's 
: so neat.  :)

I have already told the folks at Engineers Bookstore they would make a 
killing if they stocked the linux cd's. Some books would do well here too.
Are you listening EB?

J.

------------------------------

Crossposted-To: comp.os.coherent
From: ritz@ritz.mordor.com (Chris Mauritz)
Subject: Re: Coherent & Linux (Was : A Truly Unbiased Opinion)
Date: Fri, 5 Aug 1994 12:20:05 GMT

Rick Kelly (rmk@rmkhome.com) wrote:
: David Willmore (willmore@iastate.edu) wrote:
: : rmk@rmkhome.com (Rick Kelly) writes:

: : You call yourself a sysadmin? ;)  NFS export the darn drive and mount
: : it on the target machine.  The tape solution is much more complex.

: But first explain to the people on the machines that have CD-ROM drives
: that they can't use AnswerBook or all the other millions of doc sets
: that are now on CD-ROM.

Um, you're further showing that a CD-ROM is becoming a "standard" piece
of equipment.  Hell, I remember when a hard disk was a "luxury" item,
but now you can't get by without one.  CD-ROM's are so cheap these days
I don't understand your stubbornness in terms of springing for one...
unless it's because your OS doesn't support it.  <grin>

: : CDROM with remote drive:

: : 1. walk over to CDROM attached machine.
: : 2. put disk in carrier and insert into player.
: : 3. mount disk to NFS exported dir.
: : 4. login (from anywhere) to target machine--install software.

: It's finding a free drive that's the problem.  And the majority of the
: CD drives are on DOS/WINDOWS machines where thet seem to be a necessity
: these days.

Yep.  Wave of the future and all that.  No sense fighting it.  Besides,
it makes more sense than floppies on a cost/bit basis.

: : With a remote tape drive: (remember, if the CDROM drive is going
: : to be remote, the tape drive has to be too.  hell, CDROM drives are
: : so much cheaper than tape drives, they're probably more common.)

: Every UNIX box has a tape drive.

I don't agree.

: : P.S. If you think CDROM is a cool software distribution media you'll love
: : MD.  Smaller, same low production cost, comes in a split RW/RO version, etc.

: I like MO drives.  Dual purpose.

So do I, but they still aren't manufactured in quantities that will
bring the price down to earth.  A nice $500 4mm DAT drive works well
for infrequently accessed files and gives you 2 gigs of r/w storage
('course I just use mine for backup).  Does Coherent support SCSI
DAT drives?  Mine runs like a champ on BSDI/386 and is also supported
under Linux.

Regards,

Chris

-- 
Christopher Mauritz       |  Ask me about public access unix
ritz@mordor.com           |  and interactive internet services.
Mordor International BBS  |  BBS: (201)433-7343,(212)843-3451
Jersey City, NJ           |  FAX: (201)433-4222

------------------------------

From: robertsw@agcs.com (Wallace Roberts)
Crossposted-To: comp.os.386bsd.misc
Subject: Re: source of TCP/IP (was I hope this wont ignite a major flame ...)
Date: 3 Aug 1994 17:21:09 -0700

hpeyerl@sidney.novatel.ca (Herb Peyerl) writes:

        [ ...snip happens... ]

>I've tried reading Linux networking code. At least some of the device 
>drivers and each of the ones I looked at gave me a brain hemorrage...
>
>This is an example of some of the Linux device-drivers I've seen:
>
>        short error = rx_status & 0x3C00;
>        outw(inw(ioaddr + 0x0A) | 0x00C0, ioaddr + 0x0A);
>
>As far as I can tell; Linux Ethernet device-drivers were written in
>Write-Only-C.  There are no comments in the surrounding code that in any
>way indicates exactly what "0x3c00", "0x0a", "0x00c0" actually mean. To
>people without docs (usually these are the people who are trying to fix
>the code) the above is completely meaningless.

if you're writing (or fixing) a device driver, you are expected to have
the h/w manuals handy.  comments are unnecessary if you have the device
manual & understand the h/w.  this is the expected level of competence
for a programmer writing or fixing a device driver.

"if you can't run with the big dogs, stay on the porch..."

>Thank you; I'll stick to working on code that I can actually read.

you're welcome.  now run along and play...

gears,
ye wilde ryder
--
robertsw@agcs.com | 86 cr250 "dirt devil"    83 v65 magna "animal"
"E Pluribus Unix" | 79 it250 "mr. reliable"  84 650 nighthawk ">> for sale <<"
"Criminals (especially tyrants) prefer unarmed victims."
"Ignorance can be cured; stupidity, on the other hand, is hereditary."

------------------------------

From: Matthew Osborne <mo@pineapple.apmaths.uwo.ca>
Crossposted-To: comp.os.linux.help
Subject: UART's and slip
Date: 7 Aug 1994 02:43:06 GMT

        Hello. I am looking to be buying a 14.4k modem for my linux box. 
One of the reasons for it is so that I can run SLIP. Now, this modem WILL 
NOT have a 16550 UART in it.. The CPU of the computer is a 386 sx\16 with 
4 megs..

Now, my question.. Will I notice a VERY major difference between a 16550 
UART and a modem that doesn't have one running SLIP, and to what effect. 

Please, I am I need to know A.S.A.P. So, either Email me at 
mo@pineapple.apmaths.uwo.ca , or follow-up to this post.


-- 
+  Matthew C Osborne           |"I would if I could, but I can't so I won't" 
+       Co-SysOp     Biffs BBS | -Unkown 1994
+ Node 1 (519)659-7470         |       "Common sence is very uncommon."  
+  mo@pineapple.apmaths.uwo.ca |        -Horace Greeley

------------------------------

From: clolson@me.umn.edu (Curt L. Olson (Admin))
Subject: Re: Doom on SGI -- wow!
Date: Fri, 5 Aug 1994 03:25:34 GMT

A.Kruse@nikhef.nl (Andres Kruse (NIKHEF),1c/137,2909) writes:

>In article ipd@muller.loria.fr, levyb@loria.fr (Bruno Levy) writes:
>> 
>> According to me, Doom is quite portable, and they don't use SGI specific
>> stuff (such as GL). In fact, they use either MIT-Xshm (XShmPutImage),
>> either standard X calls (XPutImage) when running through the network.
>> I am almost sure that it could compile on whatever system that has
>> MIT Shm (stamdard X calls are slooowww, since it goes through a socket,

>There was a news message in comp.sys.sgi.misc in which David Taylor of
>ID Software mentioned that he *did* use MITSHM. 

>> when MIT Xshm uses shared memory between a X server and system memory).
>> What a pity they don't release source code !!!
>> I think that the only difference between SGI and DOS version (and others)
>> are frame buffer and input code, (or maybe a few mapping routine written
>> in asm).
>> I am quite disappointed that they don't use GL !! ( I am almost sure
>> of that).

>Why disappointed ? Most X-Terminals don't support GL calls, so you would be 
>forced to play it on the console... although it's much much nicer/faster 
>there... have seen it on an Indigo^2 (150MHz R4400) yesterday... It is indeed 
>very very fast.

I ran it on an Onyx (2 150MHz R4400 CPUs)  It was very very very fast ...
and very smooth ... but the window was so small ... :(

Curt.

------------------------------

From: cloister@u.washington.edu (cloister bell)
Subject: Re: utility for creating video modes for X?
Date: 6 Aug 1994 06:49:45 GMT

cloister@u.washington.edu (cloister bell) writes:

>i read through VideoModes.doc, and worked through the steps for creating a
>video mode, and well, i was pleased to find that the results actually worked.
>but it occurs to me that someone has to have written a utility to do this
>automatically.  something that would take a dcf value and a hsf value and give
>you back a line that you can stick in your Xconfig file.  has anyone seen
>something like this?

ok, so maybe it's bad form to answer my own question, but i'm going to anyway.
since i posted the question, i decided it couldn't be that hard to write such a
utility, and i turned out to be correct.  it was really easy, in fact, which is
why it surprises me that no such utility is included with the linux
distribution (at least, not with slackware 2.0, which is what i used).

anyway, the following utility takes as input values for your dot clock and
horizontal sync frequency and an optional horizontal sync pulse length, and
gives you back a line of numbers you can stick in your Xconfig file.  read the
header comment for details:

/*------------------------------8< cut here 8< ------------------------------*/
/* XFree86 video mode timing generator for Linux.  use this to create video
 * modes for your Xconfig file from dot clock values and horizontal sync
 * frequencies. */

/* to see why all this works, read /usr/X11/etc/VideoModes.doc.  I don't claim
 * that this program is anything other than a quick hack because i didn't want
 * to calculate another video mode manually.  one was enough.  :) */

/* all the usual public domain stuff applies to this software:
 * copyright jason black, 1994.  you are free to copy, redistribute, and use
 * this software to your heart's content provided that you leave this comment
 * intact when you redistribute, that you always include this source file when
 * redistributing, and that you don't go trying to sell this to anyone to make
 * a profit.  if you are redistributing on floppy disk, magtape, or any other
 * removable media, then you may charge up to as much as the media costs.
 * basically, i don't want anyone trying to in any way limit availability of
 * this program, nor do i wany anyone trying to make a profit off my labor. */

/* this program should be easy to compile, as it doesn't do anything even
 * remotely sneaky.  compile it like this:

 gcc xmode.c -o xmode

 * this program is also easy to use.  invoke it with no flags to get usage
 * information.  here are two sample runs of the program so you can see how
 * easy it is:

foo> xmode -dcf 85 -hsf 64
refresh rate for this mode: 60.03Hz
percent of hfl used:        72.88%
mode-name  dcf   hres hspstart hspend hfl  vres vspstart vspend vfl
1032x774    85   1032 1064 1384 1416       774 777 786 812

foo> xmode -dcf 85 -hsf 56.5 -hsp 3.5
warning: refresh rate is less than 60Hz for this mode.
refresh rate for this mode: 54.47Hz
percent of hfl used:        76.90%
mode-name  dcf   hres hspstart hspend hfl  vres vspstart vspend vfl
1200x900    85   1200 1232 1528 1560       900 903 911 945

both of the above are actual results i got on my machine, and both were
functional video modes.  the 1200x900 was too flickery to be usable, however,
which is why the less than 60Hz refresh rate warning is in there.

 * note that while this program produces video modes that work, you will
 * almost certainly have to tweak the hspstart and hspend values for your
 * monitor.  the program places the hsp more or less in the middle of the
 * scanline, which may not be the best place for it for you.  tweaking should
 * be done in accordance with the tutorial in VideoModes.doc.  specifically,
 * hspstart, hspend, and hfl are the only numbers you should have to really
 * mess with.  hspstart and hspend should both be changed by the same amount if
 * you change either.  incrementing or decrementing hspstart and hspend will
 * move the display right or left.  incrementing or decrementing hfl will
 * stretch or shrink the width of the display.  all increments to these
 * numbers must be in multiples of 8, as must horizontal timing numbers
 * themselves. */

#include <stdio.h>

void main(int argc, char **argv);
void usage(char *argv0);
void process_args(int argc, char **argv, float *dcf, float *hsf, float *hsplen);

void main(int argc, char **argv)
{
  float
/* input values: */
    dcf      = -1, /* dot clock frequency - from command line       */
    hsf      = -1, /* horizontal sync frequency - from command line */
    hsplen   =3.8, /* length of horiz. sync pulse in microseconds   */

/* calculated output values: */
    hr       = -1, /* horizontal resolution - calculated            */
    hspstart = -1, /* horizontal sync pulse start - calculated      */
    hspend   = -1, /* horizontal sync pulse end - calculated        */
    hfl      = -1, /* horizontal frame length - calculated          */
    vr       = -1, /* vertical resolution - calculated              */
    vspstart = -1, /* vertical sync pulse start - calculated        */
    vspend   = -1, /* vertical sync pulse end - calculated          */
    vfl      = -1, /* vertical frame length - calculated            */

/* intermediate values: */
    hsp      = -1, /* length of horiz. sync pulse in clock ticks    */
    linetime = -1, /* microseconds it takes for one scan line       */
    vsp      = -1, /* length of vert. sync pulse in linetime units  */
    rr       = -1  /* refresh rate                                  */
      ;

  int done = 0, hfl_last_tweaked = 0;

  process_args(argc, argv, &dcf, &hsf, &hsplen);

/* now begins the fun stuff */

  hfl = (int)(1000.0 * dcf / hsf);  /* time for one scan line in dcf ticks */
  hr  = (int)(0.8 * hfl);  /* shouldn't try and display more than 80% of hfl */

/* we need to engineer things so that hsp length is between 3.5 and 4 micro-
 * seconds, and so that hfl - hfr = hsp (in clock pulses), and so that hfl,
 * hfr, and hsp are divisible by 8. */
  hsp = hsplen * dcf;  /* 3.8 is in microseconds, hsp is in hsf clock pulses */

  hsp -= (int)hsp % 8; /* force hsp to be a multiple of 8; round down */
  hfl -= (int)hfl % 8; /* same for hfl */
  hr  -= (int)hr  % 8; /* same for hr  */

  while(!done)
    if(abs(hsp - (hfl - hr)) < 8) /* hsp and (hfl-hr) must be at most 8 apart */
      done = 1;
    else
      {
        if(hsp > (hfl - hr))    /* hfl and hr are too close together */
          if(hfl_last_tweaked)  /* alternately lower hr or raise hfl */
            {
              hr -= 8;
              hfl_last_tweaked = 0;
            }
          else
            {
              hfl += 8;
              hfl_last_tweaked = 1;
            }
        else if(hsp < hfl - hr) /* hfl and hr are too far apart */
          if(hfl_last_tweaked)  /* alternately raise hr or lower hfl */
            {
              hr += 8;
              hfl_last_tweaked = 0;
            }
          else
            {
              hfl -= 8;
              hfl_last_tweaked = 1;
            }
        else                     /* hfl - hr equals hsp.  yay! */ 
          done = 1;              /* this is redundant, but who cares? */
      }
  hspstart = hr + 32;       /* where the hsp pulse starts; 32 is magic.       */
  hspend   = hr + 32 + hsp; /* where the hsp pulse ends                       */
  hfl = hr + 32 + hsp + 32; /* calculate new hfl for that pulse configuration */

/* now we're done with the horizontal numbers.  do a couple of checks: */
  if (hr/hfl > 0.8)
    fprintf(stderr,"warning: these values use more than 80%% of the hfl.\n");
  rr = 1000*dcf/hfl;
  if (rr < 60)
    fprintf(stderr,"warning: refresh rate is less than 60Hz for this mode.\n");
  fflush(stderr); /* just in case */

/* now do the vertical numbers */
  vr  = (int)(0.75 * hr);   /* that 4:3 hr:vr screen ratio                    */
  vfl = (int)(1.05 * vr);   /* inverse of vr = .95 * vfl; we already know vr  */

  linetime = hfl / dcf;     /* microseconds it takes for once scan line */
  vsp = 150.0/linetime;     /* number of scanlines worth of vsp         */
  vspstart = vr + 3;        /* where the vsp pulse starts.  3 = guard time */
  vspend =   vr + 3 + vsp;  /* where the vsp pulse ends; vspstart + vsp */
  
printf("refresh rate for this mode: %5.2fHz\n",rr);
printf("percent of hfl used:        %5.2f%%\n",100*hr/hfl);
printf("mode-name  dcf   hres hspstart hspend hfl  vres vspstart vspend vfl\n");
printf("%dx%d    %d   %d %d %d %d       %d %d %d %d\n",
       (int)hr,(int)vr,(int)dcf,
       (int)hr,(int)hspstart,(int)hspend,(int)hfl,
       (int)vr,(int)vspstart,(int)vspend,(int)vfl);
}

void usage(char *argv0)
{
  fprintf(stderr,
          "usage: %s -dcf dot_clock_freq -hsf horizontal_sync_freq [-hsp hsplen]\n",
          argv0);
  fprintf(stderr,"       -dcf is in MHz, no default value\n");
  fprintf(stderr,"       -hsf is in kHz, no default value\n");
  fprintf(stderr,"       -hsp is in microseconds, default value = 3.8\n");
  exit(1);
}

void process_args(int argc, char **argv, float *dcf, float *hsf, float *hsplen)
{
  int i;

  if (argc < 5) usage(argv[0]);
  if (argc%2 != 1)
    {
      fprintf(stderr,"error: each arg must be a name, value pair\n");
      usage(argv[0]);
    }

  for(i = 1; i < argc; i+=2)
    if(!strcmp(argv[i],"-dcf"))
      sscanf(argv[i+1],"%f",dcf);
    else if (!strcmp(argv[i],"-hsf"))
      sscanf(argv[i+1],"%f",hsf);
    else if (!strcmp(argv[i],"-hsp"))
      sscanf(argv[i+1],"%f",hsplen);
    else
      {
        fprintf(stderr,"unknown argument %s\n",argv[i]);
        usage(argv[0]);
      }

  /* make sure both required args were given */
  if(*dcf == -1 || *hsf == -1)
    {
      fprintf(stderr,"you must specify at least -dcf and -hsf values\n");
      usage(argv[0]);
    }
}
/*------------------------------8< cut here 8< ------------------------------*/
-- 
+-------------------------------------------------+---------------------------+
|tactical nuclear sdi stealth nsafood signature.  | cloister@u.washington.edu |
+-------------------------------------------------+---------------------------+

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Misc-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.misc) via:

    Internet: Linux-Misc@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Misc Digest
******************************
