HDTenEightyP/NetNews huggingface dataset:
From: shimo@bcl.t.u-tokyo.ac.jp (Hidetoshi SHIMODAIRA)
Newsgroups: comp.infosystems.gopher
Subject: ftp available documentation is needed: gopher
Date: 18 Aug 92 03:49:38 GMT
Reply-To: Hidetoshi SHIMODAIRA <shimo@bcl.t.u-tokyo.ac.jp>
Distribution: comp
Organization: Dept. of Math. Eng. and Information Physics, U of Tokyo


Hi there,
  I am a very beginner of gopher, and I need any documentations or
manuals for gopher client and server.  If some of them are available
via ftp or gopher services, please let me know that.

P.S.
Actually I have some files contained in gopher1.02.tar.Z,  so what I
ment is something else of those.

Thank you,


 //\\\
  @ @     Hidetoshi SHIMODAIRA    <shimo@bcl.t.u-tokyo.ac.jp>
   O      Dept. of Math. Eng. & Info. Physics, Univ. of Tokyo
Newsgroups: comp.infosystems.gopher
From: mtm@camis.Stanford.EDU (Mike Macgirvin)
Subject: Re: Scripting and passwords
Organization: DSO, Stanford University
Date: 19 Aug 92 22:04:02 GMT

isca@umaxa.weeg.uiowa.edu (Iowa Student Computer Association) writes:

>>   The interpreter shouldn't know my password.  Decent security systems limit
>>   the use of passwords as much as possible, both outside the system and
>>   inside.  Ideally, the client code (where the interpreter seems to run)
>>   shouldn't know the password, it should only know that the user has already
>>   been authenticated.  Only the authentication gateway should ever see the
>>   password!

>In Bamboo (the authentication system under work for Panda) the client knows
>the user's master password, since in many cases the client itself is the
>authentication server.  At any rate, on any system where you log in with a
>password to something, the client is *always* going to get your password.
>This is just a case of hanging onto it.  Or you could encrypt every string
>typed in by the user and compare to the entry in /etc/passwd, for those
>systems with a world-readable passwd.

	I would prefer to see no restrictions on entering a password.
After all, a person may have more than one, and there are legitimate
needs for network accessible, yet restricted information. The solution
described (not allowing a password to be returned by a prompt) is a
terrible, ugly hack to get around the problem. Perhaps - a password
query could trigger a special dialog:
	"Your password is requested by Blarney.Podunk.EDU." 
	"If you have no affiliation with this system, do
	"not under any circumstances enter a password.".
...and make certain that the password is entered in no-echo mode.
Anybody trying to spoof this by using the same words with a regular 
"input mode" couldn't prevent it from echoing, a dead giveaway.
An additional safeguard would be to have the client keep a list of
systems which are allowed to query it for a password.

My $0.02.

mike
From: TOM.R2D2@law.mail.cornell.edu (TOM)
Original-To: gopher-news@boombox.micro.umn.edu (XX)
Subject: Cornell Law Gopher moves!
Date: Fri, 14 Aug 92 15:15
X-Force-Noop: TOM.R2D2@law.mail.cornell.edu
Newsgroups: comp.infosystems.gopher
Distribution: comp

(Cross-posted to TEKNOIDS, LAW-LIB, and GOPHER-NEWS)

Folks:

The Cornell Law School has moved its Gopher (little devil just
kinda burrowed over when we weren't looking).

It's now to be found at fatty.law.cornell.edu, 132.236.108.5.

Regards,
Tb.


+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Thomas R. Bruce                                607-255-1221   |
| Research Associate                        FAX: 607-255-7193   |
| Cornell Law School                                            |
| 481 Myron Taylor Hall                tom@law.mail.cornell.edu |
| Ithaca, NY 14853                     CompuServe:    75360,542 |
|                                           GENIE:    T.BRUCE4  |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
From: lindner@mudhoney.micro.umn.edu (Paul Lindner)
Newsgroups: comp.infosystems.gopher
Subject: Re: Logging problems with gopherd 1.01
Date: 18 Aug 92 05:51:13 GMT
Organization: University of Minnesota, Minneapolis

In <l8o2taINNato@saltillo.cs.utexas.edu> jonabbey@cs.utexas.edu (Jonathan David Abbey) writes:

>Hi folks.  I've recently installed UnixGopher1.1 on a 4.1.2 Sparc Sun system.
>The problem I'm having is that the system refuses to log connections at all.

>I'm running gopherd as root from inet, chrooting to the appropriate user
>directory with -u, and have specified the log file with -l.

>e.g., :
>gopher          stream  tcp     nowait  root /usr/local/bin/gopherd gopherd \
>-unetserv -I -l/usr/netserv/log/gopher.log

>I've added spaces after -u and -l, but this changed nothing.  I have it this
>way to prevent any problems with the 5 parameter limit in inet.

>Any suggestions?  Other like experiences?

Remove the -u thing, set the user in the inetd.conf itself (instead of
root, put netserv)

Also, don't jam params and options together.  Getopt doesn't work that
way. 
--
 | Paul Lindner | lindner@boombox.micro.umn.edu   | Slipping into madness
 |              | Computer & Information Services | is good for the sake
 | GopherMaster | University of Minnesota         | of comparision.
///// / / /    /////// / / / /  /  /  /   /      //// / / / /  /  /  /   /
From: con_jdc@selway.umt.edu (diskmunchin')
Newsgroups: comp.infosystems.gopher
Subject: Help needed to set up "sub-gopher"
Keywords: restricted access medical
Date: 14 Aug 92 13:01:40 GMT
Article-I.D.: selway.1992Aug14.130140.16308
Organization: University of Montana CIS

I am thinking about setting up a restricted (sub-set) gopher for use
with our Health Service HEALTHLINE program.   Healthline is a
program running on a DECStation 5500 (Ultrix) which can be logged into
by anybody (it is the only such account at the University).  We already
have a gopher server running (on the same machine).  What I'd like to
do is be able to run either a gopher server or gopher client (whichever
is applicable) which ONLY knows about Health/Medical resources (databases,
on-line libraries, etc.).   Thus my gopher would exit BACK HOME after a person
was finished with a particular resource, not up one level in a remote gopher
hierarchy.
        There are several reasons for doing this, most importantly the fact
that there are limited phone lines to this computer (which is also used by
the University community as a whole) and I don't want community
(non-University) Internet Roamers clogging up the phone lines (which would
be a good excuse for shutting Healthline down!).
        Can we just set up another gopher server using a different port
than the one currently installed?  Is this the most efficient method?
Can this kind of restriction be implemented at all?
Thanks,
                                        John-David Childs
                                        Consultant, University of Montana CIS
                                        Healthline Sr. Programmer
                                                con_jdc@selway.umt.edu
From: emv@msen.com (Edward Vielmetti)
Newsgroups: comp.infosystems.gopher
Subject: Re: .gopher files
Date: 14 Aug 1992 15:30:35 -0400
Organization: Msen, Inc. -- Ann Arbor, Michigan
NNTP-Posting-Host: nigel.msen.com
X-Newsreader: Tin 1.1 PL3

The U of Iowa "panda" server has a very similar feature, and I bet that a
few other folks have done the same thing.  If everyone who's done
something like this could raise their hands and then go off into a corner
to isolate where your changes are and how they affect the server, that
would facilitate adding it into the production release.

--Ed
From: RRYAN@CCIT.ARIZONA.EDU
Newsgroups: comp.infosystems.gopher
Subject: unsubscribe
Date: 14 Aug 92 15:17:00 GMT
Distribution: comp
Original-To: gopher-news@boombox.micro.umn.edu
X-Envelope-To: gopher-news@boombox.micro.umn.edu
X-Vms-To: IN%"gopher-news@boombox.micro.umn.edu"
X-Vms-Cc: RRYAN

unsubscribe
From: stauffer@cc.swarthmore.edu (Glenn Stauffer)
Newsgroups: comp.infosystems
Subject: Do you use the ABT college financial system?
Date: 14 Aug 92 15:16:42 GMT
Organization: Swarthmore College Computing Center
X-Xxdate: Fri, 14 Aug 92 16:16:30 GMT
X-Useragent: Nuntius v1.1.1d7

I am researching the college financial products from ABT (Applied
Business Technologies, Newtown Square, PA).

If you are using this product from or have any information about ABT and
would be willing to tell me about your experience and answer a few
questions, please send email to:

stauffer@cc.swarthmore.edu

Thank you

Glenn Stauffer
Newsgroups: comp.infosystems.gis
Date:         Thu, 20 Aug 1992 16:15:59 +1000
              <GIS-L@UBVM.BITNET>
From:         jhr@GDWB.OZ.AU
Subject:      Re: FW: GIS Interfaces
X-To:         GIS-L@UBVM.cc.buffalo.edu

>
> Users always complain, but .............
>
> as a developer of software you should try getting someone to actually try and
>  tell you what they want or how to improve it!!!!!!
>
>
> Ive been looking at interface design for years and the only good one is the
 NULL
>  one for the system that doesnt do anything (which is of course also the only
>  system without any bugs!)
>
> Lloyd Simons
>


True,


most system managers and developers admit that they would have a great time
working (playing) on their systems if it were not for the existance of
users !!

They could do all the fun things they Really want to do !


Julien
From: sue@byron.u.washington.edu (Shu-Chen Eclipse)
Newsgroups: comp.infosystems.gis
Subject: Help: changing arcedit window colors under openlook
Date: 20 Aug 92 19:32:31 GMT
Article-I.D.: u.1992Aug20.193231.15066
Organization: University of Washington, Seattle

Hellow, does anybody know how to change the background and foreground colors
in the arcedit windows underl sun's openwin2.0 and 3.0??
I would like to change it to something other than black/white.

thanx for answering,
sue@byron.u.washington.edu
Newsgroups: comp.infosystems.gis
Newsgroups: comp.infosystems.gis
Date:         Tue, 18 Aug 1992 09:55:48 -0230
Reply-To:     sfreundsch@kean.ucs.mun.ca
              <GIS-L@UBVM.BITNET>
From:         sfreundsch@KEAN.UCS.MUN.CA
Subject:      RE: GIS Interfaces
X-To:         GIS-L@UBVM.cc.buffalo.edu

Yes Myke, you have caused me to respond.  Bob, I know that you want
comments on particular systems - I'm not sure you will get them over
this medium because (1) responses would be lengthy therefore it is
difficult to get someone to sit down for an "extended" period of time
to respond, (2) your request is a meaty one - not one to be considered
lightly, (3) your request is like a big email beta test, and who likes
beta tests anyway (and those of us in the realm of human-computer
interaction know just how "useful" beta tests are for the design of
"good" interfaces - whatever that might mean), (4) and lastly, I don't
think you will get many people willing to criticise a particular
system publicly (we've seen what happens to people who "mis-speak
about systems/companies/etc. over eamil).

If this influencial person really wants to find out what users
want/need/can handle, then I would suggest (1) current literature,
such as Ganter (1988), Gould (1989), Mark (1989), Kuhn and Frank (1990),
Turk (1990), Freundschuh and Gould (1991), Mark et al. (1992) which
suggest new avenues for the design of GIS (and there is more than what
I have listed here), (2) a look at the literature on task analysis
such as Rasmussen (1986), Polson (1987), Keiras (1988), Diaper (1990 -
I think..) which appears to be one effective way at getting at what
you are asking.

From the responses that have been posted, it seems that an adaptive
user interface would be helpful.  People are different, and each has
particular needs/wants/abilities.  A system that could access these
differences and provide an "appropriate" interface would be a step in
the right direction.

Well, this response is already getting too long (see, I told ya so ;).

Scott Freundschuh
Memorial University of Newfoundland
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: comp.infosystems.gis
Date:         Thu, 13 Aug 1992 19:26:38 EDT
              <GIS-L@UBVM.BITNET>
From:         Duane F Marble <dmarble@MAGNUS.ACS.OHIO-STATE.EDU>
Subject:      Chart Dangers

Date: Wed, 12 Aug 92 11:34:11 CDT
From: sullivan@geom.umn.edu
Subject: The QE2 and navigational charts

The ocean liner QE2 had its hull damaged sailing near Martha's Vineyard.
Nautical charts of the area (made in 1939) show a shoal at a depth of 39 feet
(surrounded by readings of 85 and 90 feet) near where the ship hit something.
The ship's draw is listed as 32 feet, which should have left seven feet to
spare.  (Of course, it is not known if this is what was hit, or if the pilot, a
local pilot brought on board to navigate coastal waters, would have tried to
stay clear of that ledge even if there was supposed to be seven feet
clearance.)  The entire area has been known as a dangerous one for ships for
centuries, though the QE2 was in a standard navigation channel, heading for
NYC.

An article in the NY Times today (12 Aug) points out that the nautical charts
are based on a "sonar technology that may have overlooked higher peaks or
boulders on an underwater ledge", described by an NOAA spokesman as "hit or
miss".  He said "It is possible that the survey missed a shallower depth, that
the survey passed around it and didn't see it."

It surprises me that surveyors, when finding a steep shoal like this, 50 feet
higher than the surroundings, would not look specially for its tip.  This
points out the danger of digitizing real world data onto a fixed grid.

Today's article in the Times (by Felicity Barringer) ends by noting that "at
least two of the ship's three electronic navigational systems were operating at
the time" of the accident.

-John Sullivan@geom.umn.edu

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

--
Duane F. Marble            E-mail: dmarble@magnus.acs.ohio-state.edu
Dept. of Geography
The Ohio State University  Telephone:  (614) 292-2250
Columbus, OH 43220         Fax:  (614) 292-6213
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/;
               Relayed; Wed, 19 Aug 1992 16:16:11 +0200
X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Wed,
               19 Aug 1992 17:13:53 +0200
X400-Originator: duester@giub.unibe.ch
X400-Recipients: gis-l@ubvm.bitnet
X400-Mts-Identifier: [/PRMD=SWITCH/ADMD=ARCOM/C=CH/;920819161353]
X400-Content-Type: P2-1984 (2)
Content-Identifier: 29
Newsgroups: comp.infosystems.gis
Date:         Wed, 19 Aug 1992 17:13:53 +0200
              <GIS-L@UBVM.BITNET>
From:         duester@GIUB.UNIBE.CH
Subject:      test

this is a test!
Newsgroups: comp.infosystems.gis
From: dmarble@magnus.acs.ohio-state.edu (Duane F Marble)
Subject: Re: RE GIS interfaces
Organization: The Ohio State University
Date: Thu, 20 Aug 1992 21:15:09 GMT

Ah, but let us keep in mind that having the capability of doing something
is not the same as being able to do it. Perhaps you might ask your
secretary to explain how kerning is applied via her word processor...
-- 
Duane F. Marble			       E-mail: dmarble@magnus.acs.osu.edu
Department of Geography                Telephone: (614) 292-2250
The Ohio State University
Columbus, Ohio 43210                   Fax: (614) 292-6213
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.infosystems.gis
Date:         Thu, 13 Aug 1992 11:52:13 GMT-0800
              <GIS-L@UBVM.BITNET>
From:         Steve Lansing <lansing@QUARK.USC.EDU>
Subject:      Hood canal/Skokomish GIS
X-To:         GIS-L@ubvm.cc.buffalo.edu

I would be very grateful for any leads on GIS coverage of the Hood
Canal region in Washington State, particularly the Cushman dam and
Skokomish reservation areas- for an ecological modelling  project
requested by the tribe.

Steve Lansing
Dept of Anthropology
University of Southern California

lansing@quark.usc.edu
Newsgroups: comp.infosystems.gis
From: C.V.Copas@lut.ac.uk
Subject: Re: Two types of interfaces (was Re: GIS interfaces)
Reply-To: C.V.Copas@lut.ac.uk (Conn Copas)
Organization: Loughborough University, UK.
Date: Fri, 21 Aug 92 12:27:18 GMT

In article <9208201552.AA03120@harley.universe> esri!harley!jimt@UUNET.UU.NET (Jim Tenbrink) writes:
>I see a new thread branching off here...
>
>Then who uses this new application? And how do they use it? You haven't
>really responded to Jay's statement. You've just added another application
>area (software development) which requires its own specialized user
>interfaces.
>
>Your implication here is that if the application construction process can
>be rendered painless enough, then we should remove the distinction between
>application user and application developer.
>
>I have no information on how possible this is. 
>
Try looking through recent proceedings of the annual ACM CHI conference for
some more information on visual programming. As I read it, graphical
implementation of what is
effectively a UNIX 'pipe' facility is eminently possible. In terms of
programming control constructs, this is graphical sequencing, combined with a
dash of interprocess communication. The prospects for graphical branching, 
iteration, and recursion are a lot more remote, at least in the hands of
neophyte programmers. Ie, one can attempt to make the programmer's interface as
intuitive as possible, but this still requires a certain mastery of the
semantics of some basic control constructs.
From: cyberoid@milton.u.washington.edu (Robert Jacobson)
Newsgroups: comp.infosystems.gis
Subject: What do you think about GIS interfaces? Input to vendor!
Date: 15 Aug 92 22:38:06 GMT
Article-I.D.: u.1992Aug15.223806.9116
Organization: WORLDESIGN, Seattle


I recently spoke with an executive at one of the leading GIS vendors.
Discussing interfaces, he said that so far as he knew, the users of
these systems are happy with existing interfaces and that interface
revisions was not at the top of his list of important things to do.

What do you think about interfaces?

Leave your comments here and I'll be glad to forward them to this
influential person.  If you want anonymity, say so and I'll delete
your header.

Thanks.  This is your chance to have input at the highest level.

Bob Jacobson
WORLDESIGN, Inc.
Newsgroups: comp.infosystems.gis
Subject: Re: Request for Bertin's Permutation Software
From: feuchtwa@SFU.CA
Date: Fri, 21 Aug 1992 11:30:25 PDT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
X-To:         GIS-L@ubvm.cc.buffalo.edu

I believe Jean-Claude Mueller did some work on the re-organizing
of rows and columns of data tables, to look for patterns, when
he was at U. of Alberta (ca. 1982-85).  I don't know if it's
quite what you want nor do i remember the reference.
J-C M is now at the ITC in the Netherlands.

cheers,
                        Martin Feuchtwanger
Department of Geography
Simon Fraser University        internet:   feuchtwa@sfu.ca
Burnaby, B.C.                     phone:   604.291.4556
V5A 1S6          Canada             fax:   604.291.5841
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-VMS-To: MUWAYB::IN%"GIS-L@UBVM.cc.buffalo.edu"
X-VMS-Cc: GARY
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Newsgroups: comp.infosystems.gis
Date:         Wed, 19 Aug 1992 09:58:46 -0500
              <GIS-L@UBVM.BITNET>
From:         Red Thunder From Downunder ! <GARY@SURVEY.DN.MU.OZ.AU>
Subject:      Re: references on insurance gis?
X-To:         GIS-L@UBVM.cc.buffalo.edu

For insurance and finance applications of GIS, see the proceedings of the
"1st Conference on GIS in Business and Commerce", put out by GIS World Inc.

Gary Hunter
The University of Melbourne
Australia
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.infosystems.gis
Date:         Thu, 20 Aug 1992 07:03:27 -0500
              <GIS-L@UBVM.BITNET>
From:         Jim Westervelt <westerve@ZORRO.CECER.ARMY.MIL>
Subject:      Interface
X-To:         GIS-L@UBVM.cc.buffalo.edu

GRASS "user" interface approach.

USER                 INTERFACE
------------------   -------------------------------------------------------
Decision Maker       GUI in front of a blend of GRASS, UNIX, stats, DBMS, etc.
                     The user interfaces to systems tailor made based on
                     user, application, and agency requirements within
                     constraints of underlying software/hardware.   Probably
                     the fastest growing area of "GRASS R&D" at the original
                     home of GRASS.

DSS Writer           Generally command-line level interfaces to GIS, DBMS,
 (traditional        UNIX, stats, report writers, GUI (XGEN).  XGEN is
  GIS user)          designed to allow shell programmers access to X-windows.

Full-time GIS        Generally command-line level interfaces as above. Also
 analyst             uses fancy GUI for data exploration. (2-D, 3-D, and time)

Occasionals GIS      Pull-down meuns and hypertext-like interface which builds
 analyst             commands interactively. (XGRASS)    Alternately,
                     interfaces to much of GRASS have been put together
                     using XGEN.

Student of GIS       We hope to see the utilization of Khoros's Cantata
                     interface for GRASS.  (Very straightforward to assemble.
                     Any University out there interested?)

GIS researcher       Full access to all development libraries and existing
                     source code.  Internet mailserver for mutual support.

It is a challenge keeping these different types of users simultaneously
satisfied.   Thank goodness for the many GRASS developers across the world.
From: julien@scs.leeds.ac.uk (J C Flack)
Newsgroups: comp.infosystems.gis
Subject: Re: Segmentation and Remotely Sensed Data -- SUMMARY
Keywords: segmentation, remote sensing
Date: 13 Aug 92 16:36:28 GMT
Organization: The University of Leeds, School of Computer Studies


As promised here is a summary of the replies I got to from my query
concerning the segmentation of remotely sensed images. The original
posting was sent to: sci.image.processing, comp.infosystems.gis and
IMARS-L.

====================================================================

The evaluation and comparison of segmentation techniques has long
since been a problem:

In article <1992Aug5.185035.21313@Arco.COM> opus@arco.com (Dr. Steven 'Wild Man'Wong)
> The problem with evaluating standard segmentation processes is that we
> have too much of the 'See ma, no hands' syndrome that also affects the KBS
> (knowledge based systems)  community.  Unfortunately, I also was part of
> that crowd.  What we need is a public accessible place with standard
> benchmarks and algorihms that everyone can experiment  with, test, and
> compare against.  This idea has been proposed again and again but still
> hasn't gathered any steam.  The standard picture of 'the girl' just
> doesn't cut it.

Peter Sincak mailing to IMARS-L argued that it is difficult to establish
definitions of edges, homogenous areas, clusters ... and it is therefore
difficult to evaluate segmentations.

I think part of the problem in complex scenes, is that you can have
more than one correct segmentation --- it really depends on what your user 
wants from a decomposition of the image.

=====================================================================

Eric Majani recommends the following reference:

Hierarchical Segmentation using a composite criterion for remotely sensed
imagery
Goldberg-M and Zhang-JY
Photogrammetria Vol 42 issue 3, pp. 87-96, 1987

=====================================================================

Janet Franklin, in reply to my comp.infosystems.gis posting suggested that 
the work done by Tailor, Cross, Mason, Hogg et al on the knowledge base 
interpretation of remotely sensed images could be useful.

Their work is based on a map guided segmentation using high level domain
specific knowledge to improve the acuracy of the image decompostion.

I have a complete set of reference for that work ... email me if you are
interested.

=====================================================================

Thanks to all those who replied to my postings ....

Julien Flack,
University of Leeds.
email: julien@scs.leeds.ac.uk
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU