HDTenEightyP/NetNews huggingface dataset:
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!terminator!dabo.citi.umich.edu!rees@ucbvax.Berkeley.EDU  (Jim Rees)
Subject: Re: Printing to Tektronix
Organization: University of Michigan IFS Project
Distribution: fj
Date: Sat, 25 Jul 1992 15:08:10 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <13196@pogo.wv.tek.com>, davidh8@pogo.wv.tek.com (David Haight) writes:

  There are many such filters around to convert various raster
  formats to postscript but I don't know of one for gpr.

I know there is one, because we've got it.  It's called gpr2ps, and it may
or may not be part of the pbm package.  Ask archie.  If you can't find it,
send mail to oliveria@caen.engin.umich.edu.
Newsgroups: fj.mail-lists.apollo
From: haven.umd.edu!wam.umd.edu!dododge@ames.arc.nasa.gov  (David O. Dodge)
Subject: Re: Favourite DOMAIN/OS features (or mis-features)
Organization: University of Maryland, College Park
Distribution: fj
Date: Wed, 22 Jul 1992 06:33:33 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <Brozvu.5uu@apollo.hp.com> ganek@apollo.hp.com (Dan Ganek) writes:
>>Misfeatures:
>>
>>   They changed the way the RM_$ calls work, so the program I wrote to put
>>   a picture in the DM background doesn't work right anymore (this also
>>   affected some of Apollo's own demo programs). RM_$ being unsupported and
>>   undocumented I probably shouldn't complain too much, though :-)
>
>I didn't change the way the rm worked! THEY (the dm and Xapollo) people
>changed the way it's used :-) At SR10 there is no longer a "background"
>rectangle - use RM_$INQ_INTERIOR_VIS_LIST on the root instead of
>RM_$INQ_VIS_LIST to get the exposed areas of the root.

Thanks for the tip. I'll have to dig up my old backdrop program and see
how it worked (it's been a few years). The weird thing is that the way
it is now it isn't consistent -- it seems to pick a window at random to
throw the image/pattern into (same as the old moire demo program -- not
surprising since I think that's what I used as a model for my backdrop code).

>>   Recent versions of GPR have the mouse handling screwed up. Try playing
>>   "star wars" on a DN3500 to see what I mean.
>                                 
>HUh??? Explain, please.

The easist way to see what's going in is to play Revenaugh's Star Wars on
a DN580 and then try it on a DN3500. The difference should be immediately
noticable. The 3500 (and other newer models) buffer the mouse input
"incorrectly".

The problem is that gpr_$cond_event_wait will return a gpr_$no_event
even when there is still mouse information in the buffer. Graphics-intensive
programs such as Star Wars therefore have the response to mouse input
lagging behind the actual mouse movements. The program believes that it
is keeping up because GPR tells it that it has read all the events off
the queue.

The more graphics work the program is doing, the longer the delay. I
have some animation-style programs that delay several *SECONDS*.

This has been a problem for quite some time now. It's not usually
something you worry about, but with game programs it makes them kind of
difficult to play :-).

                                           -Dave Dodge/dododge@wam.umd.edu
Newsgroups: fj.mail-lists.apollo
From: caen!afgun@uunet.uu.net  (Andrew F. Gunnesch)
Subject: Re: Mtools on Apollo
Organization: CAEN, University of Michigan
Distribution: fj
Date: Tue, 21 Jul 1992 15:12:48 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <1992Jul21.122116.22999@rhrk.uni-kl.de> uch024@zx1.hrz.uni-dortmund.de writes:
>Well, i encountered the problem when i tried to compile the mtools.
>So what is the device one should use for mtools.
>
>As i was forced to archive some of my software i formatted a disc
>with invol and tried to mount it in the filesystem with mtvol.
>The answer from DomainOS was frustrating:
>
>?(mtvol) Unable to mount volume - no right to perform operation 
>(OS/ACL manageer)
>
>So does anyone know what has to be done to make the mtvol run?
>In fact our Sysadmin doesn't know either :-(
>
>----------------------------------------------------------------------------
>Lothar Koniczek                  |Internet: uch024@zx1.hrz.uni-dortmund.de
>University of Dortmund (Germany) |Bitnet:   uch024@ddohrz11.BITNET
>Department of Chemistry          |Voice: Sorry, currently not available :-(
>

It looks like you aren't trying to mtvol as root, and you aren't in
the ACL listing of `node_data/node_owners.  Try having your sysadmin
add you to the ACL on that file, and see if the mtvol works then.
-- 
===============================================================================
Andrew F. Gunnesch          |  Evil CAEN sysadmin   |  I'm a Sun worshipper
afgun@caen.engin.umich.edu  |What?  I just work here|  not a DEC dog.......
===============================================================================
Newsgroups: fj.mail-lists.apollo
From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uwm.edu!caen!hellgate.utah.edu!basset.utah.edu!hollaar@ucbvax.Berkeley.EDU  (Lee Hollaar)
Subject: Re: Mtools on Apollo
Organization: University of Utah CS Dept
Distribution: fj
Date: Tue, 28 Jul 1992 22:14:24 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

It might not be possible to port mtools to the Apollo under Domain/OS.
A standard PC floppy disk (and a floppy disk on a Sun SPARCstation) uses
512 byte sectors.  The Apollo floppy controller is set up for 1024 byte
sectors, to be compatible with the blocksize of the standard Apollo file
system.

When I wrote PCdisk, a program marketted by Contexture, Inc., that reads and
writes PC floppies on Apollo (and Sun) workstations (DN3X00/4X00 and 4XX),
what I had to do is write a new device driver that saved the Apollo
configuration for the controller, reset it and loaded the configuration
appropriate for a PC floppy, and then set everything back to normal Apollo
values after I was done.

				Lee
Newsgroups: fj.mail-lists.apollo
From: destroyer!ubc-cs!unixg.ubc.ca!physics.ubc.ca!braham@gumby.wisc.edu  (Stephen Braham)
Subject: More on wanted Xapollo (R4)
Organization: University of British Columbia, Vancouver, B.C., Canada
Distribution: fj
Date: Wed, 29 Jul 1992 16:12:20 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

Uggg, I forgot to mention that my machines are 2500's. What I need
is an R4 Xapollo binary, rather than the vanilla R2 one, for
a 10.2 system. I have access to X11R4 fonts. I'm hoping to use
xdm on our suns to drive the Apollos as dumb X terminals. I don't
THINK that I need anything else in the way of, say, libraries (but
I may be wrong- if anybody knows differently, please yell at me).

			Steve

--
| Name: Stephen P. Braham | Perversion: Quantum Cosmologist|
| Hangout: UBC physics    | Signature:  Euclidean          |
|          Vancouver, BC  |--------------------------------+
|          Canada         | E-mail: braham@physics.ubc.ca  |
Newsgroups: fj.mail-lists.apollo
From: destroyer!terminator!pisa.citi.umich.edu!rees@gumby.wisc.edu  (Jim Rees)
Subject: RE: DN4500 from hell
Organization: University of Michigan IFS Project
Distribution: fj
Date: Wed, 22 Jul 1992 17:37:08 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <9207202224.AA02846@wolf.Uwyo.EDU>, waldram@wolf.Uwyo.EDU ("James J. Waldram") writes:

         (my invol could not read the manufacturers badspot list for head 7)

Do I detect a pattern here?

Here is a suggestion.  Format the disk (option 1) with sr10.3 invol, then
make the file system (option 1 -f) with sr10.4 invol.
Newsgroups: fj.mail-lists.apollo
From: johnb@hobbes.mdc.com (John Breen)
Subject: x11r4 include files
Organization: McDonnell Douglas Missile Systems Company
Distribution: fj
Date: Fri, 31 Jul 1992 13:48:17 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

I was poking around the apollo archives at umich.edu (actually, a mirror of
it), and I noticed a tar file of the x11r4 include files.

Will these work with the HP/Apollo libraries and C compiler?  I was under the
impression that the include files were the main thing HP/Apollo offered in
their X Developer's Kit (or whatever it's called), because of some
"incompatibilities" between the standard include files and Apollo's cc.  Is
there any other reason to get the developer's kit?
--

-- 
John A. Breen                           |  johnb@hobbes.mdc.com
McDonnell Douglas Missile Systems Co.   | "I have no personal opinions;
Tel: (314)234-4341                      |  I'm a product of my environment."
Newsgroups: fj.mail-lists.apollo
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!terminator!pisa.citi.umich.edu!rees@ucbvax.Berkeley.EDU  (Jim Rees)
Subject: Re: Favourite DOMAIN/OS features (or mis-features)
Organization: University of Michigan IFS Project
Distribution: fj
Date: Wed, 22 Jul 1992 17:56:26 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <1992Jul22.063333.4659@wam.umd.edu>, dododge@wam.umd.edu (David O. Dodge) writes:

  >>   Recent versions of GPR have the mouse handling screwed up. Try playing
  >>   "star wars" on a DN3500 to see what I mean.
  >                                 
  >HUh??? Explain, please.
  
  The easist way to see what's going in is to play Revenaugh's Star Wars on
  a DN580 and then try it on a DN3500. The difference should be immediately
  noticable. The 3500 (and other newer models) buffer the mouse input
  "incorrectly".

If this is the same problem I'm seeing, then it really is intolerable.  I
see it most often when switching focus among windows.  For example, right
now my cursor is inside a DM pad.  If I move the mouse over to another
window and hit the "pop" key too fast, it will push the original window to
the bottom rather than popping the new window to the top.  This is very
annoying.
Newsgroups: fj.mail-lists.apollo
From: elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!eff!ibmpcug!pipex!unipalm!uknet!etherm!nc00@lll-winken.llnl.gov  (Neil Corlett)
Subject: Re: Favourite DOMAIN/OS features (or mis-features)
Organization: Eurotherm Limited
Distribution: fj
Date: Thu, 23 Jul 1992 08:08:28 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

roeber@vxcrna.cern.ch writes:

>Is it just me, or does anybody else have the hunch that the compress file type
>was written by a remaining Apollo guy, who had read the perennial "on-the-fly
>compression?/It can't be done" dialogs on comp.unix.wizards, and wanted to 
>prove it *could* be done before the possibility slipped away?

Acorn Computers in the UK (who came up with the ARM processor) had a
port of bsd4.3 which did this on executables. You 'squeezed' the
executable and each time it was run, the loader noticed and unsqueezed it.

How do you use the 'compress' feature on DOMAIN/OS? I come from the
Unix side of the universe and don't use 'typeing features of the
filesystem.

For what it's worth:

* I think the typed filesystem is a nice feature
  but you pay for it with desparately slow reading and writing from
  disk. I have here a 2500 with a 760Mb SCSI drive. It's disk operations
  are 5x slower than a PC running Interacive SVR3.2. Personally, I'd
  rather have 5x faster disk and do the work in my own program.

* The inability to reserve an amount of disk to be used by the
  operating system for paging is painful. User cheerfully fill up the
  disks and then wonder why their systems go to sleep. /dev/swap
  anytime.


* Networked filesystem is wonderful. And the lack of YP/NIS.

Neil
-- 

Janet:    nc00@uk.co.eurotherm    | Eurotherm Limited, Faraday Close,
Internet: nc00@eurotherm.co.uk    | Durrington, Worthing, W.Sussex, England.
UUCP:     {ukc,uunet}!etherm!nc00 | Phone: +44 903 68500  Fax: +44 903 65982
Newsgroups: fj.mail-lists.apollo
From: agate!ocf.berkeley.edu!alanc@ucbvax.Berkeley.EDU  (Alan Coopersmith)
Subject: Problems with 10.4
Organization: U.C. Bezerkeley Overloaded Computing Facility
Distribution: fj
Date: Thu, 23 Jul 1992 00:39:36 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

We recently finished upgrading our cluster of 16 machines (2 DN 4500's + 14
3500's) to 10.4 - and since then we've been having several problems:

- csh/tcsh will go into a "can't find any commands" mood, from which the only
	way to do anything is exec /bin/ksh.  (It seems to be linked to the
	tty's as some tty's have the problem & others don't...rebuilding the
	tty's "cures" the problem for a few days, but then it comes back)

- processes aren't dying properly.  For example a user telnet's in, and
	starts reading news.  The telnet will die, but it's child csh and the
	trn will keep going.  In fact, the last process in the chain will
	start using huge amounts of processor time.  The only solution we've
	found for this so far is to check the process table every 10 minutes
	and kill -HUP every process who's unix_PPID is 1 (and is not owned
	by root/daemon/user/etc.)  kill(-9, -1) is also failing at times.

- vuelogin/Xdomain keeps complaining about:
	"InitShareExt: Can't initialize extension"

Any suggestions on how to fix these?  

-- 
------------------------------------------------------------------------
Alan Coopersmith			Internet: alanc@ocf.berkeley.edu
University of California, Berkeley	Bitnet:   alanc@UCBOCF.BITNET
Newsgroups: fj.mail-lists.apollo
From: utcsri!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!system@uunet.uu.net  (System Admin (Mike Peterson))
Subject: Re: Mail and NFS 2.3
Organization: University of Toronto Chemistry Department
Distribution: fj
Date: Thu, 30 Jul 1992 03:44:51 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <807@ceco.ceco.com> chris@ceco.ceco.com (Chris Icide) writes:
>
>I am currently having a couple problems which seem to related.  My
>configuration is as follows:  DN3550 24MB, OS 10.4, NFS2.3.
>
>1)  Our site is using a sun as both the site's name server and mailserver.
>    The DN3550 works perfectly fine with the name server, and I am able
>    to mount the sun's exported file systems with no problems.  The user
>    id's on the sun and apollo match (unix id #'s and names, groups, orgs,
>    etc.).  Users are able to read and write from the mounted file systems.
>    Sendmail is currently set up to deliver mail to the mail server whether
>    the intended addressee account is on the DN3550 or elsewhere.  This works
>    just fine.  /usr/spool/mail is a remote file system (/var/spool/mail) on
>    the sun.  (Main environment for users is bsd4.3 /bin/csh)

You are really asking for trouble linking your mail spool areas, because
you do not have proper file locking between mail readers and sendmail
putting new mail into a user mailbox, or between multiple sendmails
if you get your scheme to work. This scheme only worked on Domain
due to the proper file locking across the network. For NFS, 'lockd'
was supposed to do this, but many NFS implementations either lack
'lockd', or the 'lockd' supplied doesn't work (e.g. on Suns without
the lockd patch).

The only safe way to run mail seems to be to have a /usr/spool/mail
(or /usr/mail on HP-UX) on each node which is willing to actually
receive mail. What most sites seem to do (and what we do) is to
have a central mail receiver, which many other systems point to
with their MX nameserver records (make sure you have MX set properly
if you expect mail to be received on that node). Each user can then
use .forward to send their mail to their desired system (which
better not have its MX record pointing back to the central system!).
Or, you just have everyone read their mail on the mail server :-(.

>    Problems:
>    
>    If I try to set up sendmail to allow delivery to the DN3550, I run into
>    a number of problems:
>    
>    o	Mail delivered from other nodes recieve a Sendmail message: 
>    	"Deferred, connection refused" when trying to deliver mail.  The
>    	mail never gets through.

Make sure your sendmail is responding correctly - use telnet to port
25 and you can talk to it with commands like HELO, MAIL, RCPT, ...
to see that it is giving out proper FQDNs, etc. On the Apollo,
you can also use 'mail -v' for interactive delivery, so you can
watch the dialog.
-- 
What are the chances that any computer system will ever "work" properly?
... and Slim just left town. -*- Mike Peterson, SysAdmin, U/Toronto Chemistry
Newsgroups: fj.mail-lists.apollo
From: mcsun!dxcern!vxcrna.cern.ch!roeber@uunet.uu.net
Subject: pgm_$invoke changed at 10.4 ?
Organization: CERN -- European Organization for Nuclear Research
Distribution: fj
Date: Tue, 28 Jul 1992 13:42:24 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

It seems that the pgm_$invoke routine has changed between 10.3.5 and
10.4 -- whereas previously trying to invoke a nonexistant program
resulted in an error status, in 10.4 it results in an ok status.
There's a quick program down below which will illustrate this.

There's nothing in the documentation or release notes about any
changes, at least that we've found.

Has anybody else seen this?  Does anybody know if this is a feature,
or is it a bug?  If the latter, is there any chance of it being fixed?
Any easy workarounds?

Thanks.

/* A program to test pgm_$invoke.  Running it on a 10.3.5 node
   results in an error, running it on a 10.4 node does not. */

#include <apollo/base.h>
#include <apollo/pgm.h>
#include <apollo/error.h>

main()
{
     ios_$id_t ios_vector[3];		/* streams in process		*/
         pgm_$proc handle;
       status_$t status;
	char path[] = "nonexistant";    /* There should not be a 
                                           file by this name.     */

    ios_vector[0] = ios_$stdin;
    ios_vector[1] = ios_$stdout;
    ios_vector[2] = ios_$stderr;

    pgm_$invoke(path, (short)strlen(path), (short)0, (pgm_$arg_ptr *)0,
		(short)3, ios_vector, pgm_$extra_proc,
		&handle, &status);

error_$print(status);

printf("%s %d\n", path, status.all);

}


-- 
Frederick G. M. Roeber | CERN -- European Center for Nuclear Research
e-mail: roeber@cern.ch or roeber@caltech.edu | work: +41 22 767 31 80
r-mail: CERN/PPE, 1211 Geneva 23, Switzerland | home: +33 50 42 19 44
--  
"Sorry, baby, I can't take you to the pizza joint tonight, I've got to go
back to the lab and split the atom." -- Ayn Rand, "What is Romanticism?"
Newsgroups: fj.mail-lists.apollo
From: apollo.hp.com!netnews@eddie.mit.edu  (R. O. Curtis)
Subject: Re: Favourite DOMAIN/OS features (or mis-features)
Organization: Hewlett-Packard Company, Chelmsford, MA
Distribution: fj
Date: Thu, 23 Jul 1992 19:16:28 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

Around here, perhaps the most commonly-cited 
piece of vanishing Apollo wonderfulness is the 
semi-standard definition of m3 to "click 
open" a file.  This "feature" has an infinity 
of valuable uses, and does not seem likely to
reemerge through any combination of other stuff 
(X and DCE?) that I can imagine.

-r
Newsgroups: fj.mail-lists.apollo
From: munnari.oz.au!metro!usage!spectrum!cameron@uunet.uu.net  (Cameron Simpson)
Subject: an annoying bug in the C compiler ...
Organization: CS&E Computing Facility, Uni Of NSW, Oz
Distribution: fj
Date: Wed, 29 Jul 1992 10:28:00 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

Observe the (short) C program listed below.
That -2147483648 is the value of MIN_INT and MIN_LONG.
When compiled and run, eg

	cc it.c
	./a.out 147

the puts() gets executed. Ugh. Bumping the constant by one makes things
work. A bit suss, no? This is going to bogosify the code I'm fixing...
	- Cameron Simpson
	  cameron@cs.unsw.oz.au

#include	<stdio.h>
#include	<stdlib.h>
#include	<limits.h>

int
main( int argc, char	*argv[])
{
	int		l;
	unsigned long	ul;
	char		*cp;

	l=strtol(argv[1],&cp,0);
	fprintf(stderr,"\"%s\"=%ld, left at \"%s\"\n",argv[1],l,cp);
	if (l <= -2147483648)
		puts("argh!!\n");

	ul=strtoul(argv[1],&cp,0);
	fprintf(stderr,"\"%s\"=%lu, left at \"%s\"\n",argv[1],ul,cp);
}
Newsgroups: fj.mail-lists.apollo
From: agate!spool.mu.edu!cserver!edsi!chuck@ucbvax.Berkeley.EDU  (Chuck Tomasi)
Subject: Re: Favourite DOMAIN/OS features (or mis-features)
Organization: Enterprise Data Systems Incorporated, Appleton WI
Distribution: fj
Date: Wed, 22 Jul 1992 22:07:16 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

ced@APOLLO.HP.COM (Carl Davidson) writes:

:)|> My biggest gripe about Domain was in dealing with nodes on an internet
:)|> (not THE internet, just a site that had net IDs.)

:)Fixed in SR10.4. 

Someone is getting a Christmas card from me for thinking up this one.
Much thanks to whoever is responsible for doing away with one major
annoyance in my life.

Then again in 18 months I won't have but a handful of the DN machines I
have today.  What a pity.
-- 
Chuck Tomasi             |     "Mom, it's Data.  I heard you know
chuck@edsi.plexus.COM    |      how to turn him on." 
spool!cserver!edsi!chuck |                    -Wesley  "Datalore"
------<Enterprise Data Systems Incorporated, Appleton Wisconsin>------
Newsgroups: fj.mail-lists.apollo
From: usc!hacgate!oracle!uhl@uunet.uu.net  (Walter Uhl)
Subject: Re: Mtools on Apollo
Organization: Electrotechnical Laboratory, Tsukuba Science City
Distribution: fj
Date: Mon, 27 Jul 1992 16:47:29 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

afgun@engin.umich.edu (Andrew F. Gunnesch) writes:
: In article <1992Jul21.122116.22999@rhrk.uni-kl.de> uch024@zx1.hrz.uni-dortmund.de writes:
: >Well, i encountered the problem when i tried to compile the mtools.
: >So what is the device one should use for mtools.
: >
: >?(mtvol) Unable to mount volume - no right to perform operation 
: >(OS/ACL manageer)
: >
: 
: It looks like you aren't trying to mtvol as root, and you aren't in
: the ACL listing of `node_data/node_owners.  Try having your sysadmin
: add you to the ACL on that file, and see if the mtvol works then.
: -- 
: ===============================================================================
: Andrew F. Gunnesch          |  Evil CAEN sysadmin   |  I'm a Sun worshipper
: afgun@caen.engin.umich.edu  |What?  I just work here|  not a DEC dog.......
: ==============================================================================

I am not sure why mtvol is being used while attempting to execute any of the
MTOOL tools.  Programs like mdir or mread should access the floppy drive
directly through /dev/fda? as is coded in devices.c before the program is 
compiled.  

Going back to my original posting,  I get an initialize failure when attemping
to mdir a dos floppy.  I was wondering, because we use an ESDI controller, if
the out-of-the-box source must be modified.  And if it must be modified,  what 
should I be looking to add?

Thanks again

Walter Paul Uhl

email  uhl@solaria.hac.com
Newsgroups: fj.mail-lists.apollo
From: think.com!spdcc!tauxersvilli!alphalpha!nazgul@uunet.uu.net  (Kee Hinckley)
Subject: Re: Favourite DOMAIN/OS features (or mis-features)
Organization: Alfalfa Software, Inc.
Distribution: fj
Date: Wed, 29 Jul 1992 03:42:29 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

L58@vm.urz.uni-heidelberg.de (Dieter Menszner) writes:
: On our Apollos and HP's we are using the Epoch editor (GNU emacs +
: X features). It can do everything the dm editor can, including the "m3"
: feature.

If you assume that the DM is only an editor then you're right, it
can do anything the DM can.  Of course, so can a C compiler.
-- 
						nazgul@alfalfa.com

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
Newsgroups: fj.mail-lists.apollo