Subject: Linux-Misc Digest #347
From: Digestifier <Linux-Misc-Request@senator-bedfellow.MIT.EDU>
To: Linux-Misc@senator-bedfellow.MIT.EDU
Reply-To: Linux-Misc@senator-bedfellow.MIT.EDU
Date:     Fri, 1 Jul 94 09:13:22 EDT

Linux-Misc Digest #347, Volume #2                 Fri, 1 Jul 94 09:13:22 EDT

Contents:
  OS/2 vs. Linux : Stop this discussion! (Martin Wiesenfeldt)
  Re: Difficult Linux Instructions... (Peter Desnoyers)
  Re: Linux/UNIX database software? (Jens Poenisch)
  Re: Difficult Linux Instructions... (Bill Kress)
  Re: Two Questions: INN and NTP (not NNTP) (Tim Smith)
  Re: CQ de sm0fcj + k (Sean McCarthy)
  DIP Script for logging into Xylogics terminal? (Wei-Yuen Tan)
  Re: Linux.... On a Sparc? (Shannon Hendrix)
  Re: BT445S explodes & takes out HD (Shannon Hendrix)
  Re: Watching a user on an tty? (Roy Hann)
  Re: Linux.... On a Sparc? (Lewis E. Wolfgang)
  Re: Difficult Linux Instructions... (Jim Robinson)
  Re: [term] Boo-hoo! (David Fox)

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

From: martin@dali.nlp.physik.th-darmstadt.de (Martin Wiesenfeldt)
Subject: OS/2 vs. Linux : Stop this discussion!
Date: 1 Jul 1994 10:07:12 GMT

I think it's time to stop this thread! Both systems have their pros and 
cons, their virtues and limitations. Like many other people I use both 
systems in parllel, some tasks I can do better with the first system, 
other tasks better with the other one. 
If I was not satisfied with one system I could always erase it from my HD 
but never would than expect other people to do so, too!

Martin

-LLLLL-L---L--LLLL---|--------------- Martin Wiesenfeldt ----------------
---L---L---L--L---L--|-- martin.wiesenfeldt@iap.physik.th-darmstadt.de --
---L---LLLLL--L----L-|-- Tel. ++49-6151-163086 | Fax: ++49-6151-164534 --
---L---L---L--L---L--|---- TH Darmstadt, Inst. f. Angewandte Physik -----
---L---L---L--LLLL---|-- Schlossgartenstr. 7, 64289 Darmstadt, Germany --




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

From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
Subject: Re: Difficult Linux Instructions...
Date: Thu, 30 Jun 1994 18:58:43 GMT

mdw@cs.cornell.edu (Matt Welsh) writes:

>In article <1994Jun28.163828.19147@wmichgw> 31khoo@wmich.edu (Beng Teck Here...) writes:

[...]

>>I have just managed to get it installed and set up a print queue,
>>but i have 3 more obstacle to cover, X, sounds and modem
>>communications... 

Well, I can sympathize with Beng about the difficulty of setting up a
print queue on Linux, at least on Slackware with only the
Printing-HOWTO and man pages - I spent an hour doing it last night,
and now have it working but somewhat sub-optimal.

It seems to me that there is a role for a configuration script, to be
run as part of installation, which asks you what type of printer you
have, what port it is on, and what output formats you want to support.
From that it should be able to generate printcap files, filters, check
your kernel for parallel printer support, etc. I can't say that I'm
literate enough in the details of printing to write such a thing,
however. 

Failing that, just re-writing the printing HOWTO to specialize it to
Linux and the new file system standard would make things easier, as
parts are complicated by the fact that they are written to apply to a
number of Unix variants. I might get around to doing this...

>>These in itself are diffcult and the documentation
>>is "all over the place".

>Not really. There's a one-stop shop for Linux documentation; sunsite.unc.edu,
>in pub/Linux/docs.

"All over the place" probably refers to location in the Linux file
system or Slackware installation disk, rather than on the net.

                                Peter Desnoyers

-- 

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

From: poenisch@cola_1.wirtschaft.tu-chemnitz.de (Jens Poenisch)
Subject: Re: Linux/UNIX database software?
Date: 1 Jul 1994 10:03:30 GMT
Reply-To: poenisch@wirtschaft.tu-chemnitz.de

Kai Petzke (wpp@marie.physik.tu-berlin.de) wrote:
: feltercarb@aol.com (Feltercarb) writes:

: >I'm looking for a decent (and preferably cheap or free) database
: >package for Linux/UNIX.  I need something that can accept some of the
: >more popular formats, at least for importing sake.

: >Our current database is in Microsoft Access, and I'm really tired of
: >its problems, so we're thinking of setting up a Unix (Linux) network
: >so we can have multiple people performing data entry simultanously.

: >Any ideas?

: A number of database packages I can think of right now (sorry, if
: I missed something):

: freeware (check sunsite:/pub/linux/apps/databases)
:       ingres
:       postgres
:       obst
:       metalbase
--> diamondbase (faster than metalbase)
:       gdbm

: commercial, but below $1K for a single user/no support license:
:       db++ (ftp.Germany.Eu.NET:/pub/shop/concept-asa)
:       /rdb
:       poet



: Kai
: -- 
: Kai Petzke                      | How fast can computers get?
: Technical University of Berlin  |
: Berlin, Germany                 | Sol 9, of course, on Star Trek.
: wpp@marie.physik.tu-berlin.de   |

Jens
--

| Name:    Jens Poenisch | EMail: poenisch@wirtschaft.tu-chemnitz.de    |
| Address: TU Chemnitz-Zwickau, Fakultaet f. Wirtschaftswissenschaften, |
|          Computerlabor, Reichenhainer Str. 39, D-09126 Chemnitz       |
| Phone:   0371 531 2689                                                |

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

From: kress@kentrox.com (Bill Kress)
Subject: Re: Difficult Linux Instructions...
Date: Thu, 30 Jun 1994 18:04:47 GMT

In article <1994Jun29.153649.14995@cs.cornell.edu> mdw@cs.cornell.edu (Matt Welsh) writes:
>From: mdw@cs.cornell.edu (Matt Welsh)
>Subject: Re: Difficult Linux Instructions...
>Date: Wed, 29 Jun 1994 15:36:49 GMT

>In article <1994Jun28.163828.19147@wmichgw> 31khoo@wmich.edu (Beng Teck Here...)
>writes:
>>I am a new Linux user and one thing is for sure... it is DIFFICULt and HARD to
>>get Linux up and running on my PC... there is too much documentation and
>>stuff to read for the average user. 

>Now THIS is a first.

I guess you could say that Unix (not just Linux) is probably a little
DIFFICULt for the average user.  I'm just getting started myself. I've
installed networking (PLIP, SLIP, and either), X, NFS, I've rebuilt the
kernel, had all the fun stuff.  Yet still each one was difficult and took
much longer than one would expect with previous systems (MS Windows, etc).

>>But there must be a better and easier way to
>>get Linux up and running. I propose a Linux-HOWTO, or a Linux For Dummies kind
>>of doc that goes through everything, from Distribution to X. I wouldn't mind
>>writing such a document, but as you can see, i am not even a 2 month old Linux
>>baby yet!!! :)

You should record your experiences.  That's the best way to get started with
a newbie.howto.  I've noticed that there is lots of stuff that is not
easy to do "as documented".  ifconfig, route, Xfileman, vi...
--these are the programs I can think of that are either poorly documented
(difficult for a beginner to understand), or not documented at all.
(Where are the docs for VI???  Man just gives command line arguments, or
was it so long ago last time I looked that I didn't grok the commands??)

man itself is intimdiating for a dos transfer student.  It took me a month
or so to figure out how to get man pages that were in two differnt sections,
and I'm still not very good at it.

>>I don't know, maybe i'm just frustrated at the amount of information that is
>>required of me to get Linux running... I just wish there is an easier way...

>Welcome to Linux. It certainly isn't for everybody, and it's going to take
>a lot of reading and hacking to things right. This is NOT a problem that
>can be fixed by documentation alone. There are many quirks and fine details
>about the system that users must know about; the system doesn't run itself.

>This is inherent to Linux, and the only solution is to write enough 
>documentation to cover it all. That's why there are so many docs out there.
>Linux is too powerful and complex to boil down into simple "here's how to 
>install the system" instructions. There are no cookbook answers. Unless you 
>have a very run-of-the-mill hardware configuration, there are always special
>cases.

I agree.  I'd venture to say it's Unix, not just Linux.  The power you
get from operating Linux mandates the complexity.  You could probably
burry all the network configuration in a batch file, but then if you
need to set up a non-standard network you're much worse off than you
were before.

Oh, one other hint.  Don't ask questions.  Use the FAQ and HOWTOs that are
available to you.  Even though it's daunting, it's possible to do
everything yourself, and as you become more familliar with the
available documentation, it will look much less confusing.

Good luck

Bill K.


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

From: tzs@u.washington.edu (Tim Smith)
Subject: Re: Two Questions: INN and NTP (not NNTP)
Date: 1 Jul 1994 10:47:11 GMT

Michael O'Reilly <michael@iinet.com.au> wrote:
>       b) something like 'slurp' to actually grab news. this is
>something you want to avoid it at all possible. In particular, slurp
>places a pretty huge load on the system you're grabbing news from.

What exactly is it about pulling news that loads a server?  Is it
the NEWNES command that slurp and nntpxfer use to find new articles?
(I'm guessing that because the server I connect to from home takes
about 20 minutes to respond to a NEWNEWS command).

I've been using a program of my own that doesn't use NEWNEWS.  It
keeps track of the highest article number in each group I get, and
determines if there are new articles by entering each group and
noting the response from the server.  It then gets the articles by
doing a "xhdr Message-ID" command, specifying and the range all the
new articles, and then doing "article" commands on each Message-ID.
(Actually, I get the ID's from all the groups I receive, and weed
out duplicates, but that's not relevant).  Is this less of a load on
the server than slurp or nntpxfer?  It seems to be nicer on the server
I'm using--my newsfeed has been cut from about 2 hours per connection
via nntpxfer to about 30 minutes via suck (that's my program).

--Tim Smith

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

From: wx8l@vtc.tacom.army.mil (Sean McCarthy)
Subject: Re: CQ de sm0fcj + k
Date: 29 Jun 1994 23:00:03 -0400

rocker@rock.b11.ingr.com (Ray Rocker) writes:
: 
: Now if they'll just port CT or NA to Linux for us contesters...
: 
: 73
Ill second that!
: 
: -- ray WQ5L rrrocker@ingr.com
  --Sean WX8L wx8l@vtc.tacom.army.mil



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

From: a5g192@rick.cs.ubc.ca (Wei-Yuen Tan)
Crossposted-To: comp.os.linux.help
Subject: DIP Script for logging into Xylogics terminal?
Date: 29 Jun 1994 23:24:45 GMT

Before I go about re-inventing the wheel, does anyone have a DIP script for
logging into Xylogics dialin servers that will set up a SLIP/CSLIP connection?

--
         Wei-Yuen Tan * a5g192@ugrad.cs.ubc.ca  * wtan@unixg.ubc.ca
>>>>>>> UBC AMS Paintball Club : paintball-club-request@unixg.ubc.ca <<<<<<<<<<
    Ligneous and petrous projectiles can potentially fracture my osseous
    structure, but pejorative appellations will forever remain innocuous.

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

Crossposted-To: comp.os.linux,comp.os.linux.help
From: shendrix@escape.widomaker.com (Shannon Hendrix)
Subject: Re: Linux.... On a Sparc?
Date: Tue, 28 Jun 1994 02:54:39 GMT

wolfgang@sunspot.nosc.mil (Lewis E. Wolfgang) writes:

>In article <2ua7pc$anv@blackbird.db.erau.edu>,
>Andrew Anderson <andersoa@news.db.erau.edu> wrote:
>>I agree.  My '66 will do loops around a Sparc 10...an operation that took
>>45 minutes on a Sparc-10 only took about 2 or 3 on my Pentium!

>Would you please document your "operation" so that others could try to
>replicate it and report their experiences?  If your claim can be replicated
>it would make the Pentium significantly faster than ANY other CPU, including
>PA-RISC and ALPHA.

>When you document your operation, also please include the running environment,
>such as which operating systems were used, local/network disks, languages,
>GUIs, memory available, system loads, and such.

They are most likely talking about integer operations.  My 486DX/40
is faster than a Sparc 2 with most tasks.  What kills my 486 and does
quite well on a Sparc is floating point.  The Intel FPU is brain-dead
for the most part, despite Intel's efforst on the Pentium.  My suggestion
to anyone that believes a Sparc is slower than an Intel is to run a
suite of floating point tests.  You'll see a different story there.

Also, I've been studying the sparc lately and writing some stuff in
assembly and I have come to realize that the Sparc is capable of very
fast integer operations.  However, most software simply doesn't take
advantage of it's features.  I find it a bit harder to be efficient
on the Sparc than the Intel's because RISC is just a far different
animal from CISC... more than I ever realized before.  I mean, a
Sparc has things like register windows, input and output registers,
floating point registers, etc...  lot's of stuff designed to speed
up code.  However, I suspect that a lot of it's features are just not
used very well.  It appears to me that it should be faster than what
I generally see.

I know that while I write code that works, I'm writing it from a
CISC point of view and could do a much better job, I just don't
currently have the know-how.

>                                       Thanks in advance,
>                                       Lewie Wolfgang

-- 
csh
===========================================================================
shendrix@escape.widomaker.com (UUCP)     | Amd486/40 Linux system
shendrix@pcs.cnu.edu (Internet)          | Christopher Newport University

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

Crossposted-To: comp.periphs.scsi
From: shendrix@escape.widomaker.com (Shannon Hendrix)
Subject: Re: BT445S explodes & takes out HD
Date: Tue, 28 Jun 1994 03:00:07 GMT

kupiec@tigger.jvnc.net (Bob Kupiec) writes:

>Well, since it's only 2 months old, as least I can send them both back
>to the manufacturer to be fix.  Anyone had any experience dealing with
>Buslogic or Micropolis repair centers?  I hope all my data (Linux) isn't
>lost.

Replace/fix the card first.  Some of the SCSI drives we have at
work on our Sparcs don't power up till the SCSI bus wakes up.

>Thanks.

>-- 
>Bob Kupiec  (HAM: N3MML) Phone: 609-897-7319             JvNC (GES, Inc.)
>Network Operations            & 800-35-TIGER x7319      3 Independence Way
>Email: kupiec@jvnc.net    Fax : 609-897-7310            Princeton, NJ 08540
-- 
csh
===========================================================================
shendrix@escape.widomaker.com (UUCP)     | Amd486/40 Linux system
shendrix@pcs.cnu.edu (Internet)          | Christopher Newport University

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

From: rhh@tachy.uah.ualberta.ca (Roy Hann)
Crossposted-To: comp.os.linux.admin
Subject: Re: Watching a user on an tty?
Date: 30 Jun 1994 00:07:56 GMT

taylor@pollux (john taylor) writes:
: The dump file can get huge quickly, and it is possible not to find the
: password in the file. On the other hand, it is just as possible to find
: passwords that have been typed in 10 to 15 minutes before the dump file
: is made.  I am not a kmem expert, and speculate this method is system 
: dependent.  Also, you would have to know what you were looking for, 
: because the output is hard to comprehend.

Once again, I have to shake my head and marvel at people who casually
post everything from broad hints to explicit recipes for compromising
system security.  Please DON'T!  I am begging now.

I have heard the arguments that it won't get fixed if it doesn't get
known about, but a would-be cracker can use the recipe _right now_.
The fix may take weeks, months or even years to propagate.  In this
environment (Linux) of all environments, the way to do it is quietly
fix the problem, and get the fix included in the major distributions.
If you can't do that, please just keep it to yourself.

Most crackers that I have come across are actually kind of dumb.  They
don't know what they are doing particularly, they are just following 
a recipe, passed on by word-of-mouth, that started with one of the 
rare ones who DID have some technical smarts.  Please don't help those 
a**holes propagate their tricks, or give them any new ideas.

I shall now descend gracefully from the pulpit and resume my seat.

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

Roy Hann
Senior Analyst, Information Systems        rhh@tachy.uah.ualberta.ca
University of Alberta Hospitals            (MIME-capable mail agent)
WMC 2C2.21, 8440-112th Street,     
Edmonton, Alberta                          Tel: (403)492-4367
T6G 0N4                                    FAX: (403)492-3090
Canada

PLEASE: No shipments by courier from outside Canada; use regular mail.
========================================================================

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

Crossposted-To: comp.os.linux,comp.os.linux.help
From: wolfgang@sunspot.nosc.mil (Lewis E. Wolfgang)
Subject: Re: Linux.... On a Sparc?
Date: Fri, 1 Jul 1994 06:18:02 GMT

In article <2uqiqr$9br@blackbird.db.erau.edu>,
Andrew Anderson <andersoa@news.db.erau.edu> wrote:
>: Would you please document your "operation" so that others could try to
>: replicate it and report their experiences?  If your claim can be replicated
>: it would make the Pentium significantly faster than ANY other CPU, including
>: PA-RISC and ALPHA.
>
>Sure, I was running Crack version 4.1 against my password file.  I was
>running Linux 1.0.8 on a Pentium 66, 16Megs ram, 20Megs swap.  My friend 
>ran it on a Sparc 10, 128Megs ram, around 100Megs swap on SunOS 4.1.3.
>
>Let me know if this is a typical comparison.  I know this doesn't 
>exercise the math coprocessor (where the Alpha would *definately* win),
>but I think it does give a decent idea of processor throughput.

What about the dictionaries for Crack?  Were they identical?  How about
the rules file?  Were they run against the same passwd file?   What
compilers were used to compile Crack?  

We will have a 90 Mhz Pentium box here shortly, I hope I have the time
to install Linux on it to do some comparisons of my own.

Thanks,
Lewie Wolfgang


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

From: jimr@shorty.cs.wisc.edu (Jim Robinson)
Subject: Re: Difficult Linux Instructions...
Date: 1 Jul 1994 11:25:16 GMT

In article <peterd.773002723@pjd.dev.cdx.mot.com> peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
>It seems to me that there is a role for a configuration script, to be
>run as part of installation, which asks you what type of printer you
>have, what port it is on, and what output formats you want to support.
>From that it should be able to generate printcap files, filters, check
>your kernel for parallel printer support, etc. I can't say that I'm
>literate enough in the details of printing to write such a thing,
>however. 

The problem is that there is no "one way" to set up your printer
scripts.  If you have a PS printer, it is not a problem ,but if you
don't have one you are in for a lot of configurations.  

I suppose the easiest way to go about this would be a set number of
filters to handle dvi, nroff, ps, and plain text.  The script would
ask about the port the printer is on, whether or not to use tunelp,
what settings, etc...  If it was not a postscript printer The data
would use some common tool to convert to (or keep as) postscript which
would get piped to ghostscript, so the configure tool would let the
user pick and choose gs output modes, and then it needs to know some
more stuff about the printer, and what it wants in terms of newlines,
do you want banners, etc..  Not very easy IMO, but doable.

Hmm, wonder if anybody wants to tackle this for Debian Linux?

Jim

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

From: fox@graphics.cs.nyu.edu (David Fox)
Subject: Re: [term] Boo-hoo!
Date: 29 Jun 1994 22:25:52 GMT

In article <2ur4ds$1tn@crl.crl.com> bhogan@crl.com (Bill Hogan) writes:

] I happened to check my mail first and I found a letter from my
] internet-access provider, informing me that I was not allowed to use
] 'term' on their computer.

Perhaps you could give term a new name...
--
David Fox                                               xoF divaD
NYU Media Research Lab                     baL hcraeseR aideM UYN

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


** FOR YOUR REFERENCE **

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

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

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

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

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

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