Subject: Linux-Misc Digest #577
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, 21 Jan 94 02:13:15 EST

Linux-Misc Digest #577, Volume #1                Fri, 21 Jan 94 02:13:15 EST

Contents:
  Re: tape drives? (Warner Losh)
  I can't get my HD back up!! (Bryce Buzzard)
  Re: Linux & Ham-Radio (BayCom) (Thomas Boutell)
  Re: WUARCHIVE LOST :-( (Terry Thero)
  Re: uucp 1.04 - looking for tester, _complete_ (better)version (Andrew J. Cosgriff !)
  Re: Slackware needs a shadow package! (Kevin Fluet)
  Re: Linux as X-Terminal? No! (Byron A Jeff)
  Re: "LinuX" ??? (was: The very cool 3D linux logo!) (Mark A. Bentley)
  Re: Linux vs. microkernel based Unix: questions? (Brandon S. Allbery)
  Re: GPL and CDROM Gripes... (Bill Pechter)
  I need Linux (Edward Powers)

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

Subject: Re: tape drives?
From: imp@boulder.parcplace.com (Warner Losh)
Date: Thu, 20 Jan 1994 20:19:55 GMT

In article jaewan@uful07.phys.ufl.edu (Jaewan Kim) writes:
>What type of tape drive is best for linux?

Of the SCSI tapes, I've used and am happy with the following tape
drives:

        Tandberg 3600
        Tandberg 3800 (make sure it has recent roms)
        Archive Viper 150

The DAT and 8mm tape drives are also good, if you can find them for
less than a small forture.

Most SCSI tape drives will work well, so it really isn't that big of a
deal which one you get (check the FAQ/HOWTO to find out if any don't).

Warner
-- 
Warner Losh             imp@boulder.parcplace.COM       ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

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

From: buzzardw@db.erau.edu (Bryce Buzzard)
Subject: I can't get my HD back up!!
Date: 12 Jan 94 02:41:51 GMT

The subject says it all.  I was running Xwindows while downloading and 
the machine just locked up.  I had no choice but to reboot, and now I 
get the following error(s):

Linux version 0.99.14 (root@darkstar.frop.org) ## Tue Nov 30 02:02:40
GMT 1993:  02:02:40
Partition check:
  hda: hda1
[MS-DOS FS Rel.  12,FAT 12,check=n,conv=b,uid=0,gid=0,umask=022]
[me=0xff,cs=32385,#f=255,fs=65409,ds=33024,de=65535,data=37215,se=6535,
ts=-1,ls=65535]
HPFS: hpfs_read_super: Not HPFS
Kernel panic:  VFS: Unable to mount root

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

From: boutell@netcom.com (Thomas Boutell)
Subject: Re: Linux & Ham-Radio (BayCom)
Date: Thu, 20 Jan 1994 22:05:10 GMT

In article <2hadkpINNm6k@fstgds15.tu-graz.ac.at>,
Fritz Ganter <ganter@fvkmapc02.tu-graz.ac.at> wrote:
>Michel Cerdini (cerdini@lanpc1.univ-lyon1.fr) wrote:
>:  I want to use my Baycom radio modem under Linux... Someone know where we
>:  can found a driver for this ?
>
>I don't think there would be a driver for it in a Multitasking
>enviroment. The Baycom modem needs 1800 Interrupts per second to
>work. I have also a Baycom modem and I have to buy a real TNC.
>

Hey, you could always hook it to a beat-up 286, run a DOS-
based package, and have the Linux machine talk to that.
Of course this suggestion is of little use if a DOS package
doesn't exist, just a thought. (A '286 can be had for
a ridiculously small number of dollars these days second-hand.)

-T
-- 
boutell@netcom.com, purveyor of fine HTML pages to the biology trade.
<a=href "http://siva.cshl.org/boutell.html">Click <em>here</em></A>

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

From: terry@col.hp.com (Terry Thero)
Crossposted-To: comp.sys.amiga.misc,demon.local,connect.chatter,connect.audit
Subject: Re: WUARCHIVE LOST :-(
Date: 20 Jan 1994 22:57:28 GMT

Hi net,

   Sorry to hear about their loss. I have contributed several
   pictures there myself.  If they need those pictures again,
   just give me a yell (or better yet post when they are back
   up and I wil try to ftp the stuff back in [except in 'jpg'
   format this time :-), last time they only took 'gif'].
   Some of the stuff was:  WW1 stuff, WW2 aircraft, NoseArt,
   AutomoXX.jpg, MobikeXX.jpg, HajimeXX.jpg, Boris Vallejo
   [bvXX.jpg], egyptology, stamps, coins, ships, Vietnam
   pictures, etc. Of course, like some one said, they can go
   to a mirror site and retrieve the stuff, can't they? :-)

                                                CU
                                                twthero
                 _____________________________________________ 
                 | Terry W. Thero: e-mail:                    | 
                 |                 terry@col.hp.com           |
                 |____________________________________________|
                 |    The Only Easy Day Was Yesterday         |
                 |____________________________________________|

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

From: ins407x@mdw060.cc.monash.edu.au (Andrew J. Cosgriff !)
Subject: Re: uucp 1.04 - looking for tester, _complete_ (better)version
Date: 21 Jan 1994 00:08:04 GMT

andreas@knobel.knirsch.de (Andreas Klemm) writes:
>vince@victrola.wa.com (Vince Skahan) writes:
>
>>      - C-news/smail/elm play together perfectly with the HDB mode,
>>              yet they do not expect the strange Taylor format.
>
>I think you are wrong. Cnews, smail and elm don't use uucp's
>config files. And here they are playing together with taylor config
>mode as well. BTW: works with inn-1.4 perfectly, too.
>
>>news/mail stuff I've provided, I do not plan on configuring them to support
>>anything other than BNU...but of course the sources are available on
>
>No, no, no !  What part of cnews or smail needs the HDB/BNU config files and 
>for what purpose ? I think it's wrong what you say or I misunderstood you
>completely ....

Yep, I'm with you Andreas.  I've used UUCP in taylor format ever since I had
to recompile it when the one I grabbed out of SLS last April was stuffed, and
never had a single "incompatability" problem with CNews or Smail, and it was
my first time setting up uucp, mail and news.  (I ended up changing to INN,
since C-News is a bit of a mess in comparison).

A recent binary release of smail was compiled such that it checked for the
UUCP system name by looking in an L.sys (or whatever it was) file instead of
running uuname, which was a pretty poor effort.  At least the other
binary distributions of smail didn't do this...

Andrew.

-- 
                            - Andrew J. Cosgriff -
                           andrew@bing.apana.org.au
                       "Help fight continental drift."

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

From: user1@valis.ampr.ab.ca (Kevin Fluet)
Subject: Re: Slackware needs a shadow package!
Date: Thu, 20 Jan 1994 01:00:11 GMT

In <longyearCJsxp6.F0A@netcom.com> longyear@netcom.com (Alfred Longyear) writes:

>iiitac@swan.pyr (Alan Cox) writes:
>>In article <1994Jan16.043028.28506@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:
>>>     Slackware desperately needs a shadow package. For those of us
>>*******SHADOW PASSWORDS ARE NOT A SECURITY FEATURE*******
>>If you want security use npasswd and Crack. That way when someone tricks
>>a program into giving your shadow password file they don't immediately break
>>every password on the machine.

>Shadow passwords are indead one part of security. So is npasswd and Crack.
>So are, to a point, hosts.allow, hosts.deny, tcp wrapper and the wustl ftpd
>control files.
[good stuff deleted]

I agree wholeheartedly that it would be very good if we could get shadow
passwords back into Slackware, but given the present software, I think it
would be a very bad idea to include it again at this point.

1)      I don't know the specifics, but there seems to be problems getting
all software to work properly with it (creating a massive hole where the
whole thing can be bypassed).

2)      More importantly, the shadow package is not under the GNU copyleft. 
The shadow copyright states that you _cannot_ charge one penny more than the
cost of duplication for the package.  This means that the package cannot be
included if a fee is charged for duplication of Slackware if any costs over
and above what the disks or CD's cost is added, no matter how reasonable.  

I can't speak for other people who distribute Linux, but if Slackware
includes this package and I can't charge for my time and effort, I won't
distribute it any more.

-- Kevin

==================================================
Kevin Fluet               Linux Support Systems 
fluet@ee.ualberta.ca      Edmonton, Canada
kevin@valis.ampr.ab.ca    VALIS BBS  (403)478-1281

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

Crossposted-To: comp.windows.x.i386unix
From: byron@cc.gatech.edu (Byron A Jeff)
Subject: Re: Linux as X-Terminal? No!
Date: Fri, 21 Jan 1994 00:48:17 GMT

In article <CJwqL0.Mn2@murdoch.acc.virginia.edu>,
Larry Doolittle <doolitt@cebaf4.cebaf.gov> wrote:
>In article <1994Jan19.180520.28228@cc.gatech.edu>, byron@cc.gatech.edu
>(Byron A Jeff) writes:

>Byron- the accelerated cards *should* drive a greyscale monitor
>just fine.  They have an analog signal input don't they?
>I think your $115 for a good greyscale monitor is probably
>way out of line, but I have never really priced them.

No. The $115 is for a sucky 14" mono monitor. It's not a solution in my
opinion. However it does show the absolute low end of the VGA monitor
spectrum.

Unfortunately there doesn't seem to be to be any middle ground when it
comes to mono/greyscale monitors. There's only the 14" and then the 19"
Sun monitors and the Nanao 21" monsters (which at $1200 each is out of
range of this applications). Has anyone seen a 15"-17" greyscale/mono
monitor that is VGA compatible and price compatible to the 14in mono/
14in color (i.e. about half the price).

>When cost and XFree performance are desired, I don't see any
>substitute for the S3-80x cards.  You can get them for sub-$150,
>and they are screamers at 1024x768ni and under - usually I say
>"256 colors", this time I can say "256 greys" :-)

Sounds good to me. In fact I plan to buy one for my home machine.

>16-greys might be more RAM efficient, but the accelerator chips
>either are not built for it, or at least XFree chooses not to
>spend time supporting those modes.  What the heck, waste those bits!

Nah. The 16 "color" server sucks. That's why I'd like to find a monitor
that does greyscale and it compatible with the accelerated SVGA cards.

Thanks for the info,

BAJ
---
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel!
Georgia Tech, Atlanta GA 30332   Internet: byron@cc.gatech.edu

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

From: bentlema@nxsci173c.mrs.umn.edu (Mark A. Bentley)
Subject: Re: "LinuX" ??? (was: The very cool 3D linux logo!)
Reply-To: bentlema@cda.mrs.umn.edu
Date: Fri, 21 Jan 1994 00:21:30 GMT

In article <2hmvta$k0g@ifi.uio.no> Kjetil T. Homme <kjetilho@ifi.uio.no>  
writes:
> [Sorry for the late follow-up]
> 
> +--- Ove Ewerlid:
> | I just downloaded the new Linux 3D logo rendered in DESIRe 1.4.  I
> | find the design of the 'i' rather creative.  But, perhaps, the font
> | of the other letters should be more towards an italic font. This
> | would make the 'i' blend in more smoothly.
> +-------
> 
> I agree, it looks _very_ nice!
> 
> I do have one objection, though - the X looks like the X Windows
> System logo. There is _no_ inherent connection between Linux and
> X. Linux is just another platform supported by XFree.
> 
> Similarily: When I see "Linux" written "LinuX", I can only say:
> "Yeuch!"  (a true gut-level reaction :-)
> 

No, I think the X logo is in there because X is associated with Unix type  
systems.  Personally I like the X logo in the Linus logo...

No big deal anyway.  The 3D logo beats any other Linux I've seen so far...

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mark Bentley                     bentlema@caa.mrs.umn.edu     (VAX/VMS)
University of Minnesota, Morris          @cda.mrs.umn.edu (UNIX/Ultrix)
UXEM Contact Person                      @nxsci173a.mrs.umn.edu  (NeXT)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Linux vs. microkernel based Unix: questions?
Date: Fri, 21 Jan 1994 03:30:46 GMT

Okay, maybe I have time to reply to this now :-(  It's been tough trying to
find time to do decent responses to messages this week...

In article <1994Jan17.235809.16128@muug.mb.ca>, rgallen@muug.mb.ca (Rennie Allen) says:
+---------------
| In <1994Jan16.191756.1229@kf8nh.wariat.org> bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:
| >In article <1994Jan16.070815.1375@muug.mb.ca>, rgallen@muug.mb.ca (Rennie Allen) says:
| >+---------------
| >| In <1994Jan15.012134.4874@kf8nh.wariat.org> bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:
| >| >The *attributes* he was discussing are real-time architecture.  Nothing he
| >| >mentioned requires a microkernel architecture; that QNX happens to *be* one is
| >| 
| >| Just what is a *realtime* architecture ?  Why would a *microkernel* realtime
| >| O/S be magically different from a non-realtime O/S ?  Funny, you know, I can
| 
| >A *real-time* OS is different from a non-realtime OS.  "Real-time" does not
| >automatically mean "microkernel".  There are non-real-time microkernels and
| 
| Please answer my question:  what is a (in your words) "realtime architecture" ?
+------------->8

Do I need to explain this?  I am talking about a kernel (of any kind) which is
designed to be able to cope with external devices which require response from
the host within a fixed (short) time frame.  This requires that the kernel be
preemptable and reentrant, among other things.  A microkernel architecture can
(and usually does) encompass most of the attributes which are required, but is
not required to; it is possible to construct a microkernel which itself cannot
be preempted and which consumes a significant percentage of CPU time itself
instead of making it available for its server processes, even though the
servers themselves are preemptable.  It may even be reasonable in some cases.

I say "architecture" instead of "attributes" because it is a design decision
which must be accounted for in all stages of kernel development and
implementation; to my mind, "attributes" implies something which can be added
or adjusted after the fact, but true real-time response cannot be achieved in
that way.  The kernel must be designed from the ground up with the intent of
providing either a microkernel architecture or a real-time architecture or
both.  ---I grant that this may be more of a terminology problem than a real
dispute.

| QNX" or not.  You are stating that when it comes to discussing architectures,
| that you can't compare a realtime microkernel, and non-realtime monolithic 
| kernel. I say you can, since the discussion is about architectures.  If QNX
+------------->8

I am saying you cannot compare the attributes you are comparing as if the
architectures were equivalent.  They clearly are not; the fact that you can
compare a single attribute (context switch time) in a manner which is
uniformly favorable to QNX indicates the difference between the requirements
of a real-time architecture and a non-real-time architecture, and would be
expected to favor the real-time system.  How does raw disk I/O compare?
Filesystem performance?  (Linux without the cluster mods will probably come
out deficient here...)

An equivalent example would be comparing apples to oranges by considering only
the thickness of the rind.

| (which is a microkernel) can be made to outperform a mono kernel, then
| obviously there is nothing inherent about the microkernel architecture which
+------------->8

In the single benchmark statistic (context switch time), yes.  How about a
benchmark which includes other attributes?  How, for example, does the same
hardware perform under QNX vs. a monolithic architecture running TPC-A with
the same (aside from OS API considerations) database manager?

And how about the same with a monolithic kernel which has been optimized to
the same extent that QNX has (Linux has not been, to my knowledge)?

| I interpreted this to mean "Any monolithic kernel gets better performance than
| any microkernel on equivalent hardware", since it is impossible for a mono
+------------->8

My second post in this thread clarified that:  by "equivalent" I meant
"equivalent levels of optimization".  Both real-time and microkernel virtually
require extreme optimization, in my experience; Linux, on the other hand,
hasn't needed it that much for what it's used for.

| If realtime and microkernel are not the same thing; and are not related, then
| surely it is unimportant that QNX is a realtime O/S when I use it in a 
+------------->8

You're comparing an attribute which is of paramount importance in real-time
systems:  context switch time.  (If the context switch time is high, you
cannot respond quickly to a real-time device; you need to switch to the
driver's context...)  It is also important to microkernels, but is not quite
as important to them as it is to real-time response.

I was also responding to the fact that "real-time" and "microkernel" were
being used virtually interchangeably in your discussion.  This most definitely
colored my perception of what you were saying, as it appeared to be intended
to do so.

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development."  ---dmeggins@aix1.uottawa.ca

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

From: pechter@i4got.lakewood.com (Bill Pechter)
Subject: Re: GPL and CDROM Gripes...
Date: Sun, 16 Jan 1994 20:25:55 GMT

In article <2gqmn9$1ts@pdq.coe.montana.edu>,
Nate Williams <nate@bsd.coe.montana.edu> wrote:
>
>(BSD make has a very nice way of handling all of this)
>

Sure... having gone from Linux to FreeBSD1.0.2 I can now do that.

But 

1. You need the disk space to keep the sources on line (Difficult)
2. You need the time to rebuilt it all (I'm running a 386SX25)

Actually... I rebuild pieces and drop them in place on 386BSD.
(Just like I did on Linux...)  The advantage on 386BSD is a standard 
directory layout (which Linux is working on.

(I'm quite pleased with both Linux and FreeBSD... I also ran NetBSD for 
a couple of days.  I liked them all for different reasons.

Linux has the most ported software available.
(And a lot of CDRom distributions -- I have three.)

FreeBSD has the advantage of CDROM distribution and bidirectional getty support
(which isn't as good as the Linux serial support by a long shot).
(Good job guys)

NetBSD supports the same binaries as BSDI's port -- so I can lift compiled 
stuff from my two friends who run BSDI and port stuff for me.

I also liked Coherent's COFF iBSC2 support.

(Now if I could put  'em all in a blender and come up with one that did 
all this)

Bill



-- 
===============================================================================
 Bill Pechter                 | The postmaster always pings twice.
 Lakewood MicroSystems        | 17 Meredith Drive,
 908-389-3592                 | Tinton Falls, NJ 07724       

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

Subject: I need Linux
From: edp@hudlink.hoboken.nj.us (Edward Powers)
Date: Thu, 20 Jan 94 14:34:03 EST

If any-body can make a copy of the latest Linux
distribution, I will be most thankfull...

Please send your answer to: edp@hudlink.hoboken.nj.us

Indicate your name, mailing address, amount of diskettes,
capacity, and type(3.5, 5.25).
I will mail you the diskettes and a money order for mailing
and any-other costs incurred in doing this.
note:  Please indicate amount.

Thank You in advance!

Ed Powers (201-869-1759)


===========
edp@hudlink.hoboken.nj.us (Edward Powers)

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


** 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
******************************
