Nebula/nebula.bin/Newsletters/GEnieUnixNews/unxnl-07.93

Text File | 1993-08-07 | 53KB | 1,404 lines

          _  _  _   _  _   _
         // // //| // // \//     N E W S
        //_// // |// //  /\\     Vol 4, Issue 7 - July 1993
      R o u n d T a b l e (tm)

   Items of interest to participants of the GEnie Unix RoundTable

 INDEX TO VOLUME 4, ISSUE 7:
 ===========================

 ED: editor notes - (GARS) Gary Smith
 --
  - Sirius Rising
 NeXT Column (ERICTREMBLAY)  Eric "E.T." Tremblay
 -----------
  - Playing Score Files
 Foo.Bar!  Unix Humor:
 --------
  - Types of Unix Administrators  (ANDY)  Andy Finkenstadt
 DataComm: Digital Communications  (LRARK)  Ricky Mobley
 --------
  - The quest for greater throughput
 Lock and Key Unix Security (SARAH)  Sarah Collier
 ------------
  - Firewalls
 Down and Dirty: Quick Scripts that do something useful  (GARS)  Gary Smith
 --------------
  - Password protection in Perl and PGP signature  (GARS)  Gary Smith
 usr/local: Items (scripts and news) snarfed from various sources
 ---------
  - Shells and Directories with Spaces in their Names  (GARS)  Gary Smith
 TUTORIALS
 ---------
  - Reclaiming Lost Data Part 2  (MIKE.NOLAN)  Mike Nolan
    - Lessons Painfully Learned
  - Rookie Review  (JANS)  Janet McNeely
    - Unix for the Impatient
  - What makes a Realtime Operating System "Realtime" (MIKE.MC)   Mike McCabe

 eot ------
                The RoundTable Staff is:
      ANDY          Andy Finkenstadt  Chief SysOp
      MIKE.NOLAN    Michael Nolan     Assistant SysOp
      SARAH         Sarah Collier     Administrative Assistant
      GARS          Gary Smith        Library Manager
      MIKE.MC       Mike McCabe       Linux & 386BSD Support SysOp
      JANS          Janet McNeely     Bulletin Board Manager
      LRARK         Ricky Mobley      Network Comm Liaison
      ERICTREMBLAY  Eric Tremblay     NeXT Support SysOp
      DELPHI        Brian T. Riley    RTC Conference Manager
      UNIX$         The Whole Crew


 We strongly encourage you to contact any or all of us if you have -ANY-
 comments or suggestions. This is -YOUR- RoundTable. We are here to make
 your participation as pleasant and beneficial as possible.

 LIVE Help Desks (type  MOVE 400;4 and choose channel #4):

 LIVE in-person Conferences (select #2 on the menu):

 ED: editor notes - (GARS) Gary Smith
 ==

   This is summer. The dog star, Sirius, is rising, a haze has taken a
 permanent perch on the horizon, removed only briefly by the heat storms
 and thunder-boomers (except in the flooded Mississippi valley - we are
 genuinely sorry about your plight).

   We of the Unix RoundTable _know_ there are other activities vying for
 your time. We understand. We also boat, swim, play softball and picnic.

   However, when you come home after a hard day on the beach we do ask that
 you flip on your computer, let the hum of the fans ease you into a more
 tranquil state and then....   log in and check us out. We have been busy
 collecting files for you, supplying answers to perplexing problems so you
 could resolve them _and_ continue to play.

   Most important of all, remember, we are your Unix friends and Linux
 buddies; and we are still here waiting to serve your computing needs.

  Gary  [e-mail]
        [e-mail]

 eot ------

 NeXT Column  (ERICTREMBLAY)  Eric "E.T." Tremblay
 ===========
                        Playing Score Files
                        -------------------
                      By Eric "E.T." Tremblay

 NeXT had a great demo application in release 2.0 called ScorePlayer.
 This little application was made to play musical files with the
 score extension. Unfortuantly people did not support this format very
 much. There was more "sound files" ending with the score extension
 then there was "music files" ending with the same extension. Also it
 is not an easy format to understand and I guess that the learning
 curve to implement a song using this format was a little too much for
 a lot of people, so there was not a lot of songs available. So in release
 3.0 NeXT decided to no longer include the ScorePlayer application. Ever
 since people have wondered how they can get to hear the wonderful sounds
 that are made using this application.

 The problem of no longer having the ScorePlayer application is easily
 solved. In fact you already have the solution in your hard disk. Just
 boot yourself a terminal window and locate a file with the score
 extension. (The Nova cdrom has a lot of them...) Then type in this
 command "playscore yourfile.score" and pump up the volume a little
 in order to apprecate the wonderful sounds that can be heard while
 listening to a score file. There's also an equvalent command to play
 sound files try this "playsound yourfile.snd".

 Another way to listen to score files is to download the sands.tar.Z
 application, that file is number XXX in the Unix RT file library and
 it will permit you to enjoy all the score files that are availble.
 Please also take note that all the publicly available score files are
 available from the Unix RT. Just make a search using the score
 keyword.

 So as you can see NeXT no longer bundles the ScorePlayer application
 but there are still other ways of listening to score musical files.
 Best of all the ScorePlayer application is still included in the
 system but only in it's unix command line form.

 Hope you enjoy the wonderful sounds that a NeXT computer can produce
 and for the people who never heard a score file before your missing
 some cool sounds. What are you waiting for?

 Here's a list of score stuff available from the library

   No. File Name                  Bytes
 ----- ------------------------- ------

  2714 ALLEGRO.Z                  21888
       Desc: ALLEGRO.score.Z Score file NeXT
  2715 ASCORE.Z                   14592
       Desc: AutoScore plays NeXT score files
  2953 CHILD.SCORE.Z               2560
       Desc: Child NeXT score file
  2954 CHOPIN.SCORE.Z              3712
       Desc: Chopin's Prelude in C minor Score
  2949 COVENTRY.SCORE.Z            2432
       Desc: Conventry Carol NeXT score file.
  2713 FUGUEC.Z                   20608
       Desc: FUGUEC.score.Z Score file NeXT
  2955 JOYS SEVEN.SCORE.Z          2944
       Desc: Joys Seven NeXT score file
  2950 KINGS.SCORE.Z               5248
       Desc: March of the Kings NeXT score file
  2952 NOUVELET.SCORE.Z            2176
       Desc: Noel Nouvelet NeXT score file
  2712 PACHEL.Z                   37120
       Desc: PACHEL.score.Z Score file NeXT
  2711 PARTITA.Z                  20480
       Desc: PARTITA.score.Z Score file NeXT
  2956 PATAPAN.SCORE.Z             4352
       Desc: Pat-a-pan NeXT score file
  2951 ROCKING.SCORE.Z             2304
       Desc: Rocking Carol NeXT score file
  7433 SANDS.TAR.Z               465792
       Desc: An app that plays Score music files

 eot ------

 Foo.Bar!  Unix Humor:  (ANDY)  Andy Finkenstadt
 ========

 Item forwarded  by  ANDY         to GARS

 Sub: Types of Unix Administrators

 KNOW YOUR UNIX SYSTEM ADMINISTRATOR-- A FIELD GUIDE

 There are four major species of Unix sysad:

 1) The TECHNICAL THUG.  Usually a systems programmer who has been
 forced into system administration; writes scripts in a polyglot of the
 Bourne shell, sed, C, awk, perl, and APL.

 2) The ADMINISTRATIVE FASCIST.  Usually a retentive drone (or rarely,
 a harridan ex-secretary) who has been forced into system
 administration.

 3) The MANIAC.  Usually an aging cracker who discovered that neither
 the Mossad nor Cuba are willing to pay a living wage for computer
 espionage.  Fell into system administration; occasionally approaches
 major competitors with indesp schemes.

 4) The IDIOT.  Usually a cretin, morpohodite, or old COBOL programmer
 selected to be the system administrator by a committee of cretins,
 morphodites, and old COBOL programmers.



 HOW TO IDENTIFY YOUR SYSTEM ADMINISTRATOR:


 ---------------- SITUATION: Low disk space. ----------------

         TECHNICAL THUG: Writes a suite of scripts to monitor disk
 usage, maintain a database of historic disk usage, predict future disk
 usage via least squares regression analysis, identify users who are
 more than a standard deviation over the mean, and send mail to the
 offending parties.  Places script in cron.  Disk usage does not
 change, since disk-hogs, by nature, either ignore script-generated
 mail, or file it away in triplicate.

         ADMINISTRATIVE FASCIST: Puts disk usage policy in motd.  Uses
 disk quotas.  Allows no exceptions, thus crippling development work.
 Locks accounts that go over quota.

         MANIAC:
 # cd /home
 # rm -rf `du -s * | sort -rn | head -1 | awk '{print $2}'`;

         IDIOT:
 # cd /home
 # cat `du -s * | sort -rn | head -1 | awk '{ printf "%s/*\n", $2}'` | compress


 ---------------- SITUATION: Excessive CPU usage. ----------------

         TECHNICAL THUG: Writes a suite of scripts to monitor
 processes, maintain a database of CPU usage, identify processes more
 than a standard deviation over the norm, and renice offending
 processes.  Places script in cron.  Ends up renicing the production
 database into oblivion, bringing operations to a grinding halt, much
 to the delight of the xtrek freaks.

         ADMINISTRATIVE FASCIST: Puts CPU usage policy in motd.  Uses
 CPU quotas.  Locks accounts that go over quota.  Allows no exceptions,
 thus crippling development work, much to the delight of the xtrek
 freaks.

         MANIAC:
 # kill -9 `ps -augxww | sort -rn +8 -9  | head -1 | awk '{print $2}'`

         IDIOT:
 # compress -f `ps -augxww | sort -rn +8 -9  | head -1 | awk '{print $2}'`


 ---------------- SITUATION: New account creation. ----------------

         TECHNICAL THUG: Writes perl script that creates home
 directory, copies in incomprehensible default environment, and places
 entries in /etc/passwd, /etc/shadow, and /etc/group.  (By hand, NOT
 with passmgmt.) Slaps on setuid bit; tells a nearby secretary to
 handle new accounts.  Usually, said secretary is still dithering over
 the difference between 'enter' and 'return'; and so, no new accounts
 are ever created.

         ADMINISTRATIVE FASCIST: Puts new account policy in motd.
 Since people without accounts cannot read the motd, nobody ever
 fulfills the bureaucratic requirements; and so, no new accounts are
 ever created.

         MANIAC: "If you're too stupid to break in and create your own
 account, I don't want you on the system.  We've got too many goddamn
 sh*t-for-brains a**holes on this box anyway."

         IDIOT:
 # cd /home; mkdir "Bob's home directory"
 # echo "Bob Simon:gandalf:0:0::/dev/tty:compress -f" > /etc/passwd


 ---------------- SITUATION: Root disk fails. ----------------

         TECHNICAL THUG: Repairs drive.  Usually is able to repair
 filesystem from boot monitor.  Failing that, front-panel toggles
 microkernel in and starts script on neighboring machine to load binary
 boot code into broken machine, reformat and reinstall OS.  Lets it run
 over the weekend while he goes mountain climbing.

         ADMINISTRATIVE FASCIST: Begins investigation to determine who
 broke the drive.  Refuses to fix system until culprit is identified
 and charged for the equipment.

         MANIAC, LARGE SYSTEM: Rips drive from system, uses
 sledgehammer to smash same to flinders.  Calls manufacturer, threatens
 pets.  Abuses field engineer while they put in a new drive and
 reinstall the OS.
         MANIAC, SMALL SYSTEM: Rips drive from system, uses ball-peen
 hammer to smash same to flinders.  Calls Requisitions, threatens pets.
 Abuses bystanders while putting in new drive and reinstalling OS.

         IDIOT: Doesn't notice anything wrong.


 ---------------- SITUATION: Poor network response. ----------------

         TECHNICAL THUG: Writes scripts to monitor network, then
 rewires entire machine room, improving response time by 2%.  Shrugs
 shoulders, says, "I've done all I can do," and goes mountain climbing.

         ADMINISTRATIVE FASCIST: Puts network usage policy in motd.
 Calls up Berkeley and AT&T, badgers whoever answers for network
 quotas.  Tries to get xtrek freaks fired.

         MANIAC: Every two hours, pulls ethernet cable from wall and
 waits for connections to time out.

         IDIOT:
 # compress -f /dev/en0


 ---------------- SITUATION: User questions. ----------------

         TECHNICAL THUG: Hacks the code of emacs' doctor-mode to answer
 new users questions.  Doesn't bother to tell people how to start the
 new "guru-mode", or for that matter, emacs.

         ADMINISTRATIVE FASCIST: Puts user support policy in motd.
 Maintains queue of questions.  Answers them when he gets a chance,
 often within two weeks of receipt of the proper form.

         MANIAC: Screams at users until they go away.  Sometimes
 barters knowledge for powerful drink and/or sycophantic adulation.

         IDIOT: Answers all questions to best of his knowledge until
 the user realizes few UNIX systems support punched cards or JCL.


 ---------------- SITUATION: *Stupid* user questions. ----------------

         TECHNICAL THUG: Answers question in hex, binary, postfix,
 and/or French until user gives up and goes away.

         ADMINISTRATIVE FASCIST: Locks user's account until user can
 present documentation demonstrating their qualification to use the
 machine.

         MANIAC:
 # cat >> ~luser/.cshrc
 alias vi 'rm \!*;unalias vi;grep -v BoZo ~/.cshrc > ~/.z; mv -f ~/.z ~/.cshrc'
 ^D

         IDIOT: Answers all questions to best of his knowledge.
 Recruits user to system administration team.


 ---------------- SITUATION: Process accounting management. ----------------

         TECHNICAL THUG: Ignores packaged accounting software; trusts
 scripts to sniff out any problems & compute charges.

         ADMINISTRATIVE FASCIST: Devotes 75% of disk space to
 accounting records owned by root and chmod'ed 000.

         MANIAC:  Laughs fool head off at very mention of accounting.

         IDIOT:
 # lpr /etc/wtmp /usr/adm/paact


 -------------- SITUATION: Religious war, BSD vs. System V. --------------

         TECHNICAL THUG:  BSD.  Crippled on System V boxes.

         ADMINISTRATIVE FASCIST: System V.  Horrified by the people who
 use BSD.  Places frequent calls to DEA.

         MANIAC: Prefers BSD, but doesn't care as long as HIS processes
 run quickly.

         IDIOT:
 # cd c:


 -------------- SITUATION: Religious war, System V vs. AIX --------------

         TECHNICAL THUG:  Weeps.

         ADMINISTRATIVE FASCIST: AIX-- doesn't much care for the OS,
 but loves the jackboots.

         MANIAC: System V, but keeps AIX skills up, knowing full well
 how much Big Financial Institutions love IBM...

         IDIOT:  AIX.


 ---------------- SITUATION: Balky printer daemons. ----------------

         TECHNICAL THUG: Rewrites lpd in FORTH.

         ADMINISTRATIVE FASCIST: Puts printer use policy in motd.
 Calls customer support every time the printer freezes.  Tries to get
 user who submitted the most recent job fired.

         MANIAC: Writes script that kills all the daemons, clears all
 the print queues, and maybe restarts the daemons.  Runs it once a hour
 from cron.

         IDIOT:
 # kill -9 /dev/lp ; /dev/lp &


 ---------------- SITUATION: OS upgrade. ----------------

         TECHNICAL THUG: Reads source code of new release, takes only
 what he likes.

         ADMINISTRATIVE FASCIST: Instigates lawsuit against the vendor
 for having shipped a product with bugs in it in the first place.

         MANIAC:
 # uptime
 1:33pm  up 19 days, 22:49,  167 users,  load average: 6.49, 6.45, 6.31
 # wall
 Well, it's upgrade time.  Should take a few hours.  And good luck on that
 5:00 deadline, guys!  We're all pulling for you!
 ^D

         IDIOT:
 # dd if=/dev/rmt8 of=/vmunix


 ---------------- SITUATION: Balky mail. ----------------

         TECHNICAL THUG: Rewrites sendmail.cf from scratch.  Rewrites
 sendmail in SNOBOL.  Hacks kernel to implement file locking.  Hacks
 kernel to implement "better" semaphores.  Rewrites sendmail in
 assembly.  Hacks kernel to . . .

         ADMINISTRATIVE FASCIST: Puts mail use policy in motd.  Locks
 accounts that go over mail use quota.  Keeps quota low enough that
 people go back to interoffice mail, thus solving problem.

         MANIAC:
 # kill -9 `ps -augxww | grep sendmail | awk '{print $2}'`
 # rm -f /usr/spool/mail/*
 # wall
 Mail is down.  Please use interoffice mail until we have it back up.
 ^D
 # write max
 I've got my boots and backpack.  Ready to leave for Mount Tam?
 ^D

         IDIOT:
 # echo "HELP!" | mail tech_support.AT.vendor.com%kremvax%bitnet!BIFF!!!


 -------------- SITUATION: Users want phone list application. --------------

         TECHNICAL THUG: Writes RDBMS in perl and Smalltalk.  Users
 give up and go back to post-it notes.

         ADMINISTRATIVE FASCIST: Oracle.  Users give up and go back to
 post-it notes.

         MANIAC: Tells the users to use flat files and grep, the way
 God meant man to keep track of phone numbers.  Users give up and go
 back to post-it notes.

         IDIOT:
 % dd ibs=80 if=/dev/rdisk001s7 | grep "Fred"


 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

 OTHER GUIDELINES:


 ---------------- TYPICAL ROOT .cshrc FILE: ----------------

         TECHNICAL THUG: Longer than eight kilobytes.  Sources the
 output of a perl script, rewrites itself.

         ADMINISTRATIVE FASCIST:  Typical lines include:
 umask 777
 alias cd 'cd \!*; rm -rf ching *hack mille omega rogue xtrek >& /dev/null &'

         MANIAC:  Typical lines include:
 alias rm 'rm -rf \!*'
 alias hose kill -9 '`ps -augxww | grep \!* | awk \'{print $2}\'`'
 alias kill 'kill -9 \!* ; kill -9 \!* ; kill -9 \!*'
 alias renice 'echo Renice\?  You must mean kill -9.; kill -9 \!*'

         IDIOT:  Typical lines include:
 alias dir ls
 alias era rm
 alias kitty cat
 alias process_table ps
 setenv DISPLAY vt100


 ---------------- HOBBIES, TECHNICAL: ----------------

         TECHNICAL THUG: Writes entries for Obsfuscated C contest.
 Optimizes INTERCAL scripts.  Maintains ENIAC emulator.  Virtual
 reality .

         ADMINISTRATIVE FASCIST: Bugs office. Audits card-key logs.
 Modifies old TVs to listen in on cellular phone conversations.
 Listens to police band.

         MANIAC: Volunteers at Survival Research Labs. Bugs office.
 Edits card-key logs.  Modifies old TVs to listen in on cellular phone
 conversations.  Jams police band.

         IDIOT: Ties shoes.  Maintains COBOL decimal to roman numeral
 converter.  Rereads flowcharts from his salad days at Rand.


 ---------------- HOBBIES, NONTECHNICAL: ----------------

         TECHNICAL THUG: Drinks "Smart Drinks."  Attends raves. Hangs
 out at poetry readings and Whole Earth Review events and tries to pick
 up Birkenstock MOTAS.

         ADMINISTRATIVE FASCIST: Reads _Readers Digest_ and _Mein
 Kampf_.  Sometimes turns up car radio and sings along to John Denver.
 Golfs.  Drinks gin martinis.  Hangs out in yuppie bars and tries to
 pick up dominatrixes.

         MANIAC: Reads _Utne Reader_ and _Mein Kampf_.  Faithfully
 attends Dickies and Ramones concerts.  Punches out people who say
 "virtual reality."  Drinks damn near anything, but favors Wild Turkey,
 Black Bush, and grain alcohol.  Hangs out in neighborhood bars and
 tries to pick up MOTAS by drinking longshoremen under the table .

         IDIOT: Reads _Time_ and _Newsweek_-- and *believes* them.
 Drinks Jagermeister.  Tries to pick up close blood relations-- often
 succeeds, producting next generation of idiots.


 ---------------- 1992 PRESIDENTIAL ELECTION: ----------------

         TECHNICAL THUG: Clinton, but only because he liked Gore's
 book.

         ADMINISTRATIVE FASCIST: Bush. Possibly Clinton, but only
 because he liked Tipper.

         MANIAC: Frank Zappa.

         IDIOT: Perot.


 ---------------- 1996 PRESIDENTIAL ELECTION: ----------------

         TECHNICAL THUG: Richard Stallman - Larry Wall.

         ADMINISTRATIVE FASCIST: Nixon - Buchanan.

         MANIAC: Frank Zappa.

         IDIOT: Quayle.


 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

 COMPOUND SYSTEM ADMINISTRATORS:


         TECHNICAL FASCIST: Hacks kernel & writes a horde of scripts to
 prevent folk from ever using more than their fair share of system
 resources.  Resulting overhead and load brings system to its knees.

         TECHNICAL MANIAC: Writes scripts that SEEM to be monitoring
 the system, but are actually encrypting large lists of passwords.
 Uses nearby nodes as beta test sites for worms.

         TECHNICAL IDIOT: Writes superuser-run scripts that sooner or
 later do an "rm -rf /".

         FASCISTIC MANIAC: At first hint of cracker incursions, whether
 real or imagined, shuts down system by triggering water-on-the-brain
 detectors and Halon system.

         FASCISTIC IDIOT:
 # cp /dev/null /etc/passwd

         MANIACAL IDIOT:  Napalms the CPU.
                                                         -Stephan Zielinski

 --
 Selected by Maddi Hausmann.MAIL your jokes(jokes ONLY)to [e-mail]
 Attribute the joke's source if at all possible.  A Daemon will auto-reply.

 --
 Selected by Maddi Hausmann.  MAIL your joke (jokes ONLY) to [e-mail]
 Attribute the joke's source if at all possible.  A Daemon will auto-reply.

 Jokes ABOUT major current events should be sent to [e-mail]
 (ie. jokes which won't be funny if not given immediate attention.)
 Anything that is not a joke submission goes to [e-mail]

 eot ------

 DataComm: Digital Communications  (LRARK)  Ricky Mobley
 =========
  - The quest for greater throughput

 Well here we are again in the dog-days of summer. Outside activities will
 increase to the point that your computer keys could become dusty from lack
 of use. I find it to be an excellent time to come inside out of the heat
 (especially at night) and do some house cleaning on the good ole system.
 Why, just this week I am planning to replace my tape drive with one of a
 higher capacity. That reduces the number of excuses I have for not properly
 backing up my file systems. Then to increase the flow of netnews through
 my site, I'll be adding an external hard disk to the system since the
 internal bay is full.

 Modem wise I will wait for newer-better-faster, etc.  I am happy with 14.4k
 bps until these others become more widely available. Ahh, I can see it now ..
 Replace my existing voice line (that I connect the modem to) with a ISDN
 connection.  That will give me a 56k bps data link and a standard voice
 line that I can reconnect the 14.4k bps back into.  How is that for data
 flow?  That will do until I can get access to ATM or Frame Relay devices.

 I had a chance recently to address data communications futures at a nearby
 university.  Four of us spoke to 35 or 40 young bright people and I could
 see the wheels turning in their minds as we baited them with ideas.  I
 expect one or more of those students to introduce us to the future of data
 communications within the next 10 years.  We spoke about old technology and
 limitations, and the switched voice circuits that we still use today to pass
 low speed data on.  We then looked at packet switched circuits,  which
 encompass SONET, ATM and Frame Relay type transmissions.  It was our feeling
 that packet type networks would yield substantial throughput of data to
 carry us into the future.  We are constantly pushing limits and bandwidths
 with new ideas of data access.  We are also packing more data into the same
 space allowing us additional throughput.

 Today you think of data access as character based with a smattering of
 graphic symbols, color, or a simple ANSI sequence to animate the display.
 What we are planning towards will be a network to carry full motion video.
 This network would support several high speed data links with a few low
 speed channels for interactive systems.  When this happens many of our
 present day libraries could very well become large computer storage
 facilities with local display terminals and remote access units to allow
 quick retrieval of that data.  Colleges and universities have hosted several
 internet connections for many years to get this process under way.  This has
 become a forerunner of what is to come.

 If you stop to look at where and when we started on this data quest, you
 will see that we have made great strides in improving our abilities to share
 and access vital information.  All of this has happened in 10 short years.
 This indicates that the growth is far from linear; but one that is
 logarithmic.

 Where will you be in 10 years?  Where will you be in 5 years?  Will your
 system be capable of handling 56k bps type connections (and all the overhead
 of interrupts that this brings)?  I doubt that most of you will require that
 kind of access, but for some of us we say, it's never too late!

 Rick Mobley, LRARK

 eot ------

 Lock and Key  Unix Security:  (SARAH)  Sarah M. Collier
 ============

  - Firewalls (extracted from Security Digests)
    ---------

 From:    [e-mail] (The Wolfe of the Den)
 Subject: Firewall availability?
 Date:    2 May 93 04:19:41 GMT

 I asked sometime early in 1992 about making firewall systems, and got a
 discouraging reply that it was still pretty much a "roll-your-own" sort
 of a deal.

 Get yourself a router box and tweak the code or tables to limit the
 services offered through the router.

 Has there been any progress in the availability of firewall technology
 in the recent past?

 That is, has the price of a firewall capable router or bridge box come
 down any?  (What sort of prices are they currently?)

 What sort of suggestions would you make to a person who is dealing with
 a professionally paranoid, non-technical, boss?

 Situation: I have a TCP/IP/RPC internet that supports a series of unix
 workstations (binaries only) and office macintoshes.  The net is a
 proper IP subnet, registered, but currently disconnected and served by
 MX records for email.

 I'm considering connecting 1 machine to the rest of the net with a
 stripped down IP connectivity that doesn't do any routing so that I can
 get some of the necessary IP connections I *need* for the future.
 (Specifically, a Mac that isn't capable of IP routing.)

 It would be more useable to the situation if I could provide a real
 firewall situation where I could assure the boss that only allowed
 services could come in, yet we could initiate FTP or email (or gopher or
 telnet or etc...).

 Any information would be appreciated.

 I will create a summary of what I get and report it back here, so email
 would be the preferable response method.

 Thanks!

 Greg Woodbury
 --
 Usenet Net News Administrator @ The Wolves Den  (G. Wolfe Woodbury)
 [e-mail]  [e-mail]  ...duke!wolves!news
 "The flame war is a specific Usenet art form." --me
 [This site is not affiliated with Duke University. (Idiots!) ]
 ------------------------------
 From:    [e-mail] (Marcus J Ranum)
 Subject: Re: Firewall availability?
 Date:    3 May 1993 01:34:33 GMT

 >Has there been any progress in the availability of firewall technology
 >in the recent past?

         Several folks sell commercial firewalls: ANS, Raptor, DEC,
 and others. Many of them are technologically quite interesting, though
 as you'd expect they're similar in a lot of ways.

 >That is, has the price of a firewall capable router or bridge box come
 >down any?  (What sort of prices are they currently?)

         Depends on what you call a "firewall." A Cisco router with
 a bunch of packet-screening rules in it will give you adequate
 security unless you expect to come under a high level of attack
 from experts. You should be able to get a Cisco for a couple
 of thousand, between 5 and 10. There's also the Karlbridge which
 is EISA-PC based. Grab the firewalls archive and take a look in
 there for the announcement. I can't recall how much it cost. The
 original version was free, or quite cheap.

         At the higher end of the spectrum are multiple-machine and
 router firewalls, like the DEC SEAL or Raptor's Eagle. ANS sells/rents
 their firewall - which is appealing if you want something on a yearly
 rate schedule. All of these higher-end firewalls are much more expensive
 than just a router, but provide significantly better security and
 more functionality in some ways.

 >What sort of suggestions would you make to a person who is dealing with
 >a professionally paranoid, non-technical, boss?

         I'd point them (depending on the financial restrictions) at
 one of the commercial offerings, since it has a "support structure"
 and "corporate backing" and all those things that make bosses happy.
 Depending on your in-house expertise, I find it's sometimes *cheaper*
 to buy a firewall, since developing one that's worth anything can
 take a few months and that can equate to as much as a commercial
 firewall costs, depending on how much your staff is paid. DEC's SEAL
 is interesting, in that it's less a package than it is a configration
 and training experience - it comes with complete source code for all
 the utilities, and they walk you through setting it up at your site.
 I don't know what level of support DEC has for SEAL these days -
 it was a consulting offering, and most of the consultants who used
 to deliver it have since left the company.

 >I'm considering connecting 1 machine to the rest of the net with a
 >stripped down IP connectivity that doesn't do any routing so that I can
 >get some of the necessary IP connections I *need* for the future.
 >(Specifically, a Mac that isn't capable of IP routing.)

         This is a basic dual-homed gateway. You can get pretty good
 security with something like this. In order to have a high level of
 connectivity between the inside and the outside, however, you would
 need to run some kind of proxy servers for telnet/FTP/etc on the
 gateway, or you'd have to let users log into the gateway itself
 which is a bad idea, in my experience.

         I suggest you check out the firewalls mailing list archives.
 I think they're FTPable from ftp.greatcircle.com, and there are
 references to tools like "socks" which help develop proxy servers,
 and some other interesting stuff.

         Good luck!
 mjr.
 ------------------------------

 From:    [e-mail]
 Subject: Re: Firewall availability?
 Date:    4 May 93 14:23:43 GMT

 In article <1s1sr9$[e-mail]> [e-mail] (Marcus J Ranum) writes:
 > >Has there been any progress in the availability of firewall technology
 > >in the recent past?
 >
 >       Several folks sell commercial firewalls: ANS, Raptor, DEC,
 > and others. Many of them are technologically quite interesting, though
 > as you'd expect they're similar in a lot of ways.
 >
 > >That is, has the price of a firewall capable router or bridge box come
 > >down any?  (What sort of prices are they currently?)
 >
 >       Depends on what you call a "firewall." A Cisco router with
 > a bunch of packet-screening rules in it will give you adequate
 > security unless you expect to come under a high level of attack
 > from experts. You should be able to get a Cisco for a couple
 > of thousand, between 5 and 10. There's also the Karlbridge which
 > is EISA-PC based. Grab the firewalls archive and take a look in
 > there for the announcement. I can't recall how much it cost. The
 > original version was free, or quite cheap.
 >
 [...]
 > mjr.

 Well to add to this list, there is also Drawbridge which is available from
 sc.tamu.edu in pub/security/TAMU. This is a free IP bridging filter
 available under the GNU General Public License and includes all source
 code.

 This package is built around an easily assembled PC which runs the bridging
 filter. It uses tables (generated from a compiler) rather than the
 algorithmic method found in most filtering implementations which makes
 it very efficient and highly configurable. It was developed here at Texas
 A&M to protect the entire campus which consists of 5000+ IP nodes. It of
 course provides you only as much security as a filtering router; it just
 makes it more efficient and easier to do.

 You have to decide what level of protection you need before choosing a
 firewall. In our academic environment we have to walk a fine line between a
 demand for easy access to the Internet and the need for security.
 Drawbridge meets these requirements pretty well.

 Dave
 --
 David K. Hess                                Graduate Assistant
 [e-mail]                        Supercomputer Center
 [phone] (work)                      Texas A&M University

 eot ------

 Down and Dirty: Quick Scripts that do something useful  (GARS) Gary Smith
 ==============

 Subject: Re: Password protection when changing VC's ??
 Archive-Name: hog.pl
 Submitted-By: Ian Jackson <[e-mail]>

 -----BEGIN PGP SIGNED MESSAGE-----

 In article <1t0bap$[e-mail]>
 [e-mail] (Scott D. Heavner) writes about a program on his Suns
 at work which locks a terminal until you type in a password.

 The version he mentioned used a .-file to store the password.

 Here is a Perl script which uses your system password. It won't work
 if you have shadow passwords, and as it's a script it shouldn't be
 installed suid root or sgid shadow.

 I have a C version somewhere which should be safe, though you'll
 probably need to change it to use getspent. Let me know if you want
 it; if enough people ask I'll post it.

 #!/usr/local/bin/perl --
 # Perl version of hog

 $#ARGV<0 || die "nhog: no arguments allowed (was given $#ARGV)";

 sub sane_exit {
         exec 'stty', $sanetty;
 }

 $sanetty = `stty -g`;
 foreach ( 'INT','QUIT','TSTP' ) { $SIG{$_} = 'IGNORE'; }
 $SIG{'TERM'} = 'sane_exit';

 @pwent = getpwuid($<);
 @pwent || die "Shit! You're not in the password file";

 $encrpw= $pwent[1];
 if (length($encrpw)<13) {
     print STDERR <<END;
 You do not appear to have a DES encrypted password available to hog.
 Perhaps your system has shadow passwords. Sorry, I can't work here.
 END
     exit 1;
 }

 $failed = 0;
 system 'stty -echo -echoe -echok echonl';

 while (1) {
         print STDERR "(@pwent[0]) password:";
         $_ = <STDIN>;
         length && chop;
         length || next;
         $crval = crypt($_,substr($encrpw,0,2));
         last if $crval eq $encrpw;
         print STDERR "password incorrect\n";
         $failed++;
         sleep 1;
         next;
 };

 print "Welcome back";
 print "; there was 1 failed attempt" if $failed==1;
 print "; there were $failed failed attempts" if $failed>1;
 print ".\n";
 do sane_exit();

 -----BEGIN PGP SIGNATURE-----
 Version: 2.2

 iQCVAgUBK/VyacMWjroj9a3bAQG9oQP+LGwkdtm/5XCc8X2nURpUozRGnsZSPpib
 dDhx+0CY38mjGjrrAMstx9OKVUriKwFq1RS09bytAc5bHGadOa6ypN4Ufq+tFB0P
 oVU694otUxZftmESlcRP5LPoJe3NFg6SXc9SaB4wCsnYhh9zapTTA+FF9Km081LF
 PG5uXwXAd0w=
 =YgK+
 -----END PGP SIGNATURE-----
 --
 Ian Jackson  <[e-mail]> (non urgent email only - see below)
 home: 35 Molewood Close, Cambridge, CB4 3SR, England; phone: [phone]
 work & urgent email: <[e-mail]> Olivetti Research Ltd; [phone]
 PGP2 public key on request; fingerprint = 5906F687 BD03ACAD 0D8E602E FCF37657

 eot ------

 usr/local: Items (scripts and news) snarfed from various sources
 =========
  - Shells and Directories with Spaces in their Names

 From: [e-mail] (Raymond Chen)
 This came up in personal conversation with Paul Haahr and Byron Rakitzis
 (implementors of es and rc, respectively), who suggested that it may be
 worth a slightly wider audience.

 The basic question is:  How well does your shell handle directories with
 spaces in their names?

 \begin{quote}
 [Whitespace and indentation added to aid readability]

 [/bin/rc]
 ; ls -F1
         Alice's Adventures in Wonderland/
         The Hunting of the Snark
         Through the Looking Glass/

 ; echo 'Alice''s Adventures in Wonderland'/*
         Alice's Adventures in Wonderland/1      [filenames deleted]

 ; echo Alice''''s' 'Adventures' 'in' 'Wonderland/*
         Alice's Adventures in Wonderland/1      [filenames deleted]

 ; foo='Alice''s Adventures in Wonderland'

 ; echo $foo/*
         Alice's Adventures in Wonderland/1      [filenames deleted]

 [/bin/sh and /bin/bash]

 $ echo "Alice's Adventures in Wonderland"/*
         Alice's Adventures in Wonderland/*

 $ echo Alice\'s\ Adventures\ in\ Wonderland/*
         Alice's Adventures in Wonderland/*

 $ foo="Alice's Adventures in Wonderland"

 $ echo $foo/*
         Alice's Adventures in Wonderland/*

 $ echo "$foo"/*
         Alice's Adventures in Wonderland/*

 [/bin/csh]                              # Have your sickness bags handy, folks!

 % echo "Alice's Adventures in Wonderland"/*
         Alice's Adventures in Wonderland/: No such file or directory

 % echo Alice\'s\ Adventures\ in\ Wonderland/*
         Alice's Adventures in Wonderland/: No such file or directory

 % set foo="Alice's Adventures in Wonderland"

 % echo $foo/*
         Wonderland/: No such file or directory

 % echo "$foo"/*
         Alice's Adventures in Wonderland/: No such file or directory

 \end{quote}

 At the time of my original experiments, /bin/sh, /bin/bash and /bin/csh
 were the only [Nie]tzsch[e] shells I had access to.  Since then, I have
 learned that es and zsh both pass.  I have not tested tcsh, tksh, zksch,
 or Paul's FORTRAN shell.

 See how well *your* favorite shell handles this simple test.  You may
 be surprised.  (Of perl, emacs, and vi, none escapes completely unscathed.)
 --
 Raymond Chen ([e-mail])

 Disclaimer: (don't blame me, the lawyers forced me to put this in)
         The views expressed in this message are my own and in no way reflect
         the views of Microsoft Corporation.


 eot ------

 TUTORIALS
 =========

 Reclaiming Lost Data  (MIKE.NOLAN)  Mike Nolan
 --------------------
 Lessons Painfully Learned
 Part II - A Backup Strategy
 by Mike Nolan

 Last month I presented a method I used to help recover some important files
 lost when I accidentally deleted 120MB of data.  This month I offer the
 backup method I installed afterwards.

 There probably are as many different solutions for backup on Unix
 systems as there are system administrators.  This method uses the
 cpio program to write to the streaming tape device, but with a couple of
 twists:

 1.  There is a common set of files that is backed up every day, and a
     variable set of files based on the day of the week (Monday-Friday),
     because you can't fit 900 MB of data on a 525MB streamer tape.
     (The working version of the script is a bit longer than the one
     provided below, because I have removed some code that shuts down
     and restarts our Oracle database.)

 2.  The tape is read back using the cpio 'verbose' parameter, which
     produces a list of files in the cron file, which is mailed to root
     at the end of the job.  This is compared with the list of files
     to see that all the files on the backup list made it to the tape,
     and thus verifies that the tape is readable.  This doesn't guarantee
     an error-free backup, but so far it has proven reliable enough for me.

     The comparison is done by an awk program, I use procmail to look
     for incoming mail to root and pass only the backup job to the awk
     script.  Thus the whole backup and verification process is automatic,
     and each morning I receive an e-mail on the status of last night's
     backup.  (And the absence of any notice means the backup didn't run.)

 The backup list for Tuesday demonstrates a relatively unused 'find'
 parameter:

    if [ $dow = 'Tuesday' ]
    then
       find /base1/oracle7 -name dbs -prune -o -type f -print  \
         >> /tmp/backup.list
    fi

 The 'prune' parameter prevents all files under the dbs subdirectory
 from being included in the list of files to be backed up.  (These files
 are part of the daily backup group, so including them a second time would
 be redundant.)  Another way to accomplish the same trick would be to build
 the file list with duplicates in it, then do a 'sort -u' to make sure
 that each line is unique.

 The awk program processes the output from cron, puts all the files on
 the backup list into an array, then processes the list of files produced
 by the cpio readback, mailing a report of the results to me.


 #!/bin/sh
 # This is a shell archive (shar 3.32)
 # made 07/08/1993 05:22 UTC by [e-mail]
 # Source directory /base3/nolan
 #
 # existing files WILL be overwritten
 #
 # This shar contains:
 # length  mode       name
 # ------ ---------- ------------------------------------------
 #   1509 -rwxr--r-- backup.job
 #    776 -rw-r--r-- bkupchk.awk
 #
 if touch 2>&1 | fgrep 'amc' > /dev/null
  then TOUCH=touch
  else TOUCH=true
 fi
 # ============= backup.job ==============
 echo "x - extracting backup.job (Text)"
 sed 's/^X//' << 'SHAR_EOF' > backup.job &&
 X#!/bin/sh
 X#
 X# backup.job - daily backup job   06/18/93 MN
 X#
 X# run from cron by root
 X#
 X
 XPATH=/sbin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/lib:.
 X
 Xecho DAILY BACKUP JOB
 Xwall <<EOF
 XBeginning daily backup of selected data files
 XEOF
 X
 Xcd /
 Xdate > backup.begun
 X
 Xdate
 X
 X#
 X# these file areas get backed up every day
 X#
 X
 Xcd /base1/oracle7/dbs
 Xfind /base1/oracle7/dbs -type f -print > /tmp/backup.list
 X
 X#
 X# other file areas get backed up on a rotating schedule
 X#
 X
 Xdow=`date +%A`
 Xif [ $dow = 'Monday' ]
 Xthen
 X   find /home -type f -print >> /tmp/backup.list
 Xfi
 Xif [ $dow = 'Tuesday' ]
 Xthen
 X   find /base1/oracle7 -name dbs -prune -o -type f -print  \
 X        >> /tmp/backup.list
 Xfi
 Xif [ $dow = 'Wednesday' ]
 Xthen
 X   find /base2 -type f -print >> /tmp/backup.list
 Xfi
 Xif [ $dow = 'Thursday' ]
 Xthen
 X   find /base3/nolan -type f -print >> /tmp/backup.list
 Xfi
 Xif [ $dow = 'Friday' ]
 Xthen
 X   find /base3/nolan.src -type f -print >> /tmp/backup.list
 Xfi
 Xif [ $dow = 'Saturday' ]
 Xthen
 X   echo 'Saturday?'
 Xfi
 Xif [ $dow = 'Sunday' ]
 Xthen
 X   echo 'Sunday?'
 Xfi
 X
 X#
 X# do backup with generated list of files
 X#
 X
 Xcat /tmp/backup.list | cpio -ocBv > /dev/rmt/c0t3d0s0
 Xecho 'backup completed'
 X
 X#
 X# 'verify' backup by getting list of files on the tape
 X# This isn't a true verify, but it'll have to do for now!
 X# the cron output will be examined by root
 X# to make sure all files show up on the verify list.
 X# (procmail and awk script used to do this)
 X#
 X
 Xcpio -itv < /dev/rmt/c0t3d0s0
 Xecho 'verify completed'
 Xdate
 X
 Xcd /
 Xdate > backup.done
 SHAR_EOF
 $TOUCH -am 0707233193 backup.job &&
 chmod 0744 backup.job ||
 echo "restore of backup.job failed"
 set `wc -c backup.job`;Wc_c=$1
 if test "$Wc_c" != "1509"; then
         echo original size 1509, current size $Wc_c
 fi
 # ============= bkupchk.awk ==============
 echo "x - extracting bkupchk.awk (Text)"
 sed 's/^X//' << 'SHAR_EOF' > bkupchk.awk &&
 X#
 X# bkupchk.awk - examine backup crontab log
 X# mail report of results to me
 X
 XBEGIN { mode = "start"
 X}
 X
 X
 Xmode=="backup" {
 Xif (NF == 1) backuplist[$1] = "written"
 Xif ($2 == "blocks") print $0, "written" > "/tmp/out.wk"
 X}
 X
 Xmode=="verify" {
 Xif (NF > 8) backuplist[$NF] = "read"
 Xif ($2 == "blocks") print $0, "read" >> "/tmp/out.wk"
 X}
 X
 X/Database .* shut down/ {
 Xmode = "backup"
 X}
 X
 X/backup completed/ {
 Xmode = "verify"
 X}
 X
 X/verify completed/ {
 Xmode = "done"
 X}
 X
 XEND {
 Xerrors=0
 Xfor (file in backuplist) {
 X   if (backuplist[file] != "read") {
 X      print "File", file, "not backed up?"  > "/tmp/out.wk"
 X      errors++
 X    }
 X   }
 Xif (errors > 0) system ("cat /tmp/out.wk |
 Xmailx -s 'Backup errors!' nolan, tom")
 Xelse system ("cat /tmp/out.wk |
 Xmailx -s 'Backup successful' nolan" )
 X}
 SHAR_EOF
 $TOUCH -am 0707233693 bkupchk.awk &&
 chmod 0644 bkupchk.awk ||
 echo "restore of bkupchk.awk failed"
 set `wc -c bkupchk.awk`;Wc_c=$1
 if test "$Wc_c" != "776"; then
         echo original size 776, current size $Wc_c
 fi
 exit 0



 =END=



 Rookie Review  (JANET.S)  Janet McNeely
 -------------
 Part 5 of a continuing series
 _Unix for the Impatient_  by Paul W. Abrahams and Bruce Larson

 _Unix for the Impatient_ is well named.  This 500+ page book by Paul
 W. Abrahams and Bruce Larson takes the Unix beginner on a whirlwind
 tour of the system, with quick introductions to history and basic
 concepts. Then it's off to basic operations.  When you're done with
 this chapter, if you've been working along with it, you know how to
 accomplish most common tasks.

 Catch your breath, because next you'll be introduced to Information
 Services and shell programs, and learning basic usage of vi and ed.
 Finally you get to Emacs, grep, telnet, ftp and other network
 communications processes, and lastly, an introduction to the
 X-Window System.

 I'll be honest.  I've only gotten about a third through the book and
 I really need to go back, this time with the 3B1 on.  _Unix for the
 Impatient_ is probably the book I'd spend my hours cramming with if
 I were going to a job interview for a Unix administration job next
 week.  It wastes no time with trivia, but hits just enough detail to
 help the reader achieve a minimum level of function and knowledge in
 a minimum amount of time.

 eot ------

 What makes a Realtime Operating System "Realtime"  (MIKE.MC)  Mike McCabe
 ------------------------------------------------

 This article will be a discussion of the attributes and requirements that
 are necessary to make an operating system "Realtime".

 First, what does the term Realtime mean?

 Realtime as its known in the Computer and Operating System parlance is a
 term used to describe a system that reacts in a very predictable and
 timely fashion to external or internal events.

 Most computer Operating systems are not realtime systems including the
 general flavor of Unix that is being sold today.  However, there does
 exist quite a few proprietary operating systems out there that are either
 realtime or pseudo realtime systems and the Unix market as the Posix
 standard continues to get a foothold is shifting from non-realtime
 operation to a realtime operation.

 A pseudo realtime system is a system like VMS for Digital Equipment Corps.
 Vax and Alpha Lines.  This system supports realtime functionality but
 only to a degree and at certain priority levels.  However, DEC's OSF/1
 system which is a flavor of Unix does support full realtime control of the
 operating system.

 What are some of the capabilities that make a system Realtime?

 Ok, time to use some buzzwords which I will explain in a moment.  The
 basic capabilities required from any realtime operating system are as
 follows:

         Pre-emptible Kernel Architecture
         Globally Shared Memory Regions
         Process Resource Sharing with locking mechanism
         High Speed Asynchronous Event Handling
         Realtime File Access

 Now I'll take these one at a time and attempt to explain what they mean...

 Pre-Emptible Kernel Architecture:

 Most Unix's use a scheduling process that allows a task or process to
 essentially capture the cpu until such time as the process blocks which
 simply means that it tries to access a resource or kernel function.  At
 this time the standard Unix process scheduling system looks at the list
 of processes that are ready to run and picks the highest priority one
 off the list.  There is a basic flaw in this in that if you have a runaway
 task (i.e. an infinite loop) it could completely steal all the cpu time
 and never let anything else run.  Most standard systems get around this
 by setting a timeout or timeslice for each process that allows the operating
 system to still share the cpu resource.  This is an example of a non-
 premptible kernel however.  A fully premptible kernel is one in which
 at most any time a high priority task can prempt the running of either
 the kernel itself or a lower priority task.  The only exceptions to this
 are during some types of I/O where critical timing is needed for example
 to a harddisk.  Due to the nature of this kind of system you can develop
 a task or process that you can guarantee will run say every 20 milliseconds.


 Globally Shared Memory Regions:

 A realtime system should provide a means that is very high speed for
 processes to share data and to communicate with each other.  This can be
 accomplished by using a shared memory region.  A shared memory region is
 a region of the systems physical memory that multiple processes can
 both write to and read from as if the area was local memory.  With this
 kind of ability very high speed interprocess communications systems can
 be developed.

 Process Resource Sharing with locking mechanism:

 An operating system provides a process with access to many resources.
 A resource is any system device or function where multiple requests may
 come in but only some can be given access at a time.  In order to control
 this a realtime operating system provides a means to reserve a spot
 on the list for getting access to the resource as well as a means to
 prioritize the requests.  This feature is typically called a Resource
 Locking Mechanism.

 High Speed Asynchronous Event Handling

 There are several buzzwords for this capability of a realtime operating
 system.  You may hear the words "Event Flag" or "Semaphore".  Both of these
 are words that describe a basic concept of realtime systems and that is
 the ability to either schedule or asynchrounously interrupt a process
 to have it perform some time critical task.  What this means is that you
 can schedule a task to perform some critical data collection from a piece
 of hardware or I/O device on a very accurate cyclic basis while the
 rest of the process does processing of some other non-critical form.

 Realtime File Access

 It is said that most computers spend the majority of their time accessing
 the disk drives.  In a realtime system environment the time required to
 access the disk drive can be a very long time to a task that needs to
 be ready to handle another access in mere milliseconds or microseconds.
 In order to improve the timing and access capability to the disk I/O system
 in a realtime system a special type of file may be created which typically
 is contiguous (all together not spread out) on the disk and shadowed in
 memory. (kind of like a cached file).  The kernel provides facilities to
 handle the actual writing of the data to the disk thereby allowing the
 high speed process to get back to doing its higher speed function instead
 of waiting on the slow disk.

 This discussion is by no means a complete description of the issues that
 make up a realtime operating system but I feel that the biggest issues have
 been touched on in this article.  For a more complete description of
 the capabilities required and supplied by realtime systems I would suggest
 contacting the IEEE to order their standards document on the Posix realtime
 extensions (standard 1003.4).

 Mike McCabe

 eot ------

  ---------------
  REMINDER - This newsletter is being sent to you 'by request'. If you do
 not wish to keep receiving it, e-mail a stop notice to GARS. On the other
 hand, we would very much appreciate it if you would pass the word that we
 do distribute this item near the tenth (10th) of the month of issue to any-
 one on GEnie who requests it.
   P L E A S E  also remember contributions are most welcome. Please e-mail
 items and/or suggestions to GARS.

 etx ------


  Trademark and Copyright notices:
  Unix is a Trademark  of UNIX System Laboratories, Inc.; GEnie, LiveWire, and
  RoundTable are Trademarks of General Electric Information Services  Company;
  Xenix and ms-dos are Trademarks of  Microsoft  Corporation; NeXT NeXTstation
  and NeXTstep  are Trademarks  of  NeXT Computer Systems, Inc., Coherent is a
  Trademark of Mark Williams Company, Sun, SPARC, SunOS are Trademarks of  Sun
  Microsystems, Inc., SCO is a Trademark of  Santa Cruz Operations, Telebit is
  a Trademark of Telebit Corporation, Hayes  and  Smartmodem are Trademarks of
  Hayes Microcomputer Products, Inc.

  The contents of this newsletter are copyright(c) 1992 and may be copied whole
  or in part only if original  credit is included. The GEnie UNIX RoundTable is
  not affiliated with AT&T or UNIX System Laboratories, Inc.

  eof ------




=END=