Subject: Linux-Misc Digest #853
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:     Wed, 23 Mar 94 02:13:07 EST

Linux-Misc Digest #853, Volume #1                Wed, 23 Mar 94 02:13:07 EST

Contents:
  Re: DOOM for X (Terry Lambert)
  Re: DOOM for X (Terry Lambert)
  Re: STRAW POLL RESULT: Linux groups automonitoring (Matt Welsh)
  Re: BSD vs. Linux (Peter Busser)
  GUS cdrom daughtercard
  Re: Network stability of freeBSD vs. Linux (Alan Cox)
  Re: Opinions wanted about SCO-unix (vs AIX/Linux). (R. Day)
  Re: Mosaic 2.2 with FORMS? (Doug McIntyre)
  Re: BRACE YOURSELF, was Re: Opinions wanted about SCO-unix (vs AIX/Linux). (John F. Haugh II)
  Re: STRAW POLL RESULT: Linux groups automonitoring (Rene COUGNENC)
  Re: SCSI Magneto-Optical Drive Supported? (Vincent Gillet)
  Re: Opinions wanted about SCO-unix (vs AIX/Linux). (Bill Davidsen)

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

From: terry@cs.weber.edu (Terry Lambert)
Crossposted-To: comp.os.386bsd.apps
Subject: Re: DOOM for X
Date: 23 Mar 1994 00:51:45 GMT

In article <2mgvon$ljb@usenet.mcs.kent.edu> borsburn@mcs.kent.edu (Bret Orsburn) writes:
]In article <1994Mar17.132757.12534@taylor.wyvern.com> mark@taylor.wyvern.com (Mark A. Davis) writes:
]>Not really.  Most Xterminals are not running Unix, which is far overkill...
]
]UNIX (at least a stripped-down run-time version) isn't overkill if the vendor
]has to port Xlib and Xt and and several other application libs. (Motif?)

First of all, mwm doesnm't require linking with libXm, or didn't last time
I licensed the sources.

]>Nope.  But the mini OS in the Xterminal does have to support certain
]>functionality- most of which is necessary to run the Xserver software anyway.
]
]The X server has a very small OS porting layer (osx).
]
]The Client side does not.

This depoends greatly on if you are stupid enough to try and port all
clients or if you are simply trying to port *some* clients that make
sense -- ie: those which take little room and *aso* have a very small OS
porting layer.  A window manager is one such client.

]You've got a heterogeneous network (that X allowed you to build, to your
]great advantage) including X terminals from three different vendors. You
]have among your user population people with strong preferences for four
]different window managers.
]
]So, as the site administrator, you have to make four different window managers
]work under 3 different, arbitrarily restricted, (perhaps proprietary)
]"mini OS"es.
]
]For those of you following along at home, that's 12 ports.

Again, from the same perspective, window management services are something
the X terminal vender should supply.  Check out NCD and NCR.  The only
exceptions to this are bogus X terminals anyway, where the server runs on the
UNIX and uses some dumb protocol for talking to the terminal and getting
gross drawing capability out of it.

]Twelve ports using three different collections of low-volume, ad hoc cross
]development tools and three rag-tag processions of vendor-developed application
]support libraries.

Obviously you'd be an idiot to do this.  By the same token, you'd be an
idiot anyway, since you have quadrupled your support problems anyway, even
if the window managers did not run locally.

Generally speaking, any large business that wishes to stay in business and
spends on X will pick *one* user interface, and will probably pick *one*
terminal vender.

]Are you absolutely sure that using a non-local window manager was such a
]big problem that you are willing to discard everything you know about
]software development and maintenance methodologies in order to "fix" this
]theoretical "problem"?

This argument is an argument against X terminals instead of workstations
and is an obvious straw-man, since the network bandwidth for engineering
use on a single subnet is considerable.

One 10Mb/s wire is only capable of supporting 260 full bandwidth 38.4
connections going on simultaneously.  X bandwidth is considerably higher
ieven though typical usage of text terminals would not consume the full
38.4 per terminal, and drops the number of supportable sessions considerably
-- to well below the 254 addresses allowed on a typical 8 bit logical subnet.

The problem then is to reduce wire traffic, and the simplest way to do this
effectively is to divide by 2-3 the number of packets on the wire by moving
the window manager into the terminal.

Of course the swap traffic for an equivalent diskless (or even dataless)
Sun systems makes them equally unacceptable, especially given their typical
swap-from-image-instead-of-using-swap architecture makes them ridiculously
NFS intensive (given Sun's religious avoidance of client caching at the
cost of a few getattr's).

The bandwidth for X is less than the bandwidth of an equivalent number of
diskless/dataless machines.

So in knocking down the X terminal configuration, you knock down at the
same time the only other price competitive soloution, and you knock it
down on exactly the same grounds.


                                        Terry Lambert
                                        terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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

From: terry@cs.weber.edu (Terry Lambert)
Crossposted-To: comp.os.386bsd.apps
Subject: Re: DOOM for X
Date: 23 Mar 1994 01:37:30 GMT

In article <2mh1ta$m21@usenet.mcs.kent.edu> borsburn@mcs.kent.edu (Bret Orsburn) writes:
]In article <2mb2bb$8m@u.cc.utah.edu> terry@cs.weber.edu (Terry Lambert) writes:
]>As far as API environment
]>is concerned, a clock, a window manager, a print server, and an X telnet
]>or rlogin or CTERM (DECNet) window all consume only those interesting
]>resources that must be there for an X terminal to be an X terminal (ie:
]>networking, display, and mouse/keyboard input services).
]
]This drastic oversimplification simply ignores all of the client-side
]X libraries.

Excuse me, by why do you need client side X libraries to consume display
services if you are running inside an X terminal?

]>For print
]>services, I guess you'd need a local printer port (check the back of NCD,
]>NCR, or GraphOn X terminals lately? Even a Wyse-50 has a printer port...).
]
]There are no print services in X. We seem to be talking past each other here.

Well, I think I'd only run a window manager and a daemn to accept connections
and echo data back and forth from the serial port, and *maybe* a telnet window
and *maybe* a CTERM protocol window (if the server supported a DECNet
transport at all...

]>Finally, you are arguing from the specific to the general, which is logically
]>invalid in any case.
]
]Huh? Precisely where did I commit this fallacy?

By assuming I wanted to run a *lot* of clients on the X terminal, you
implied the need for more OS services, then you argued against running
*any* clients on the X terminal because of the OS service requirements
being too large.

]>This is the argument Sun tried to use (an failed at).  Sun is now selling
]>workstations running X server software under the name "X terminal".  Sun
]>wasn't very successful selling that world view, and they had a marketing
]>department being paid big $ trying to back their story up.  8-).
]
]Actually, you've made my case for me. The price point for X terminals has
]been kept so high (by creeping featurism) that workstations can compete
]against them head-to-head.

Sun has had a hard time selling this; so far it has only been a paper
competition, and until Sun's diskless workstations used only for their
display services outnumber NCD's X terminals, it will remain a paper
argument.  Honestly, you sound like Sun marketing?

]I think X terminals are useful and important, so I think we (as customers)
]should try *not* to apply pressure on the vendors to add features that drive
]the costs up and ultimately undermine the market.
]
]But, I'm afraid that train may already have left the station....

Well, there is another emerging windowing standard (being pushed by terminal
venders) that argues agains this.

I also have to argue that putting the Window manager and local clients
on the X terminal is *exactly* what you are doing when you run one of
the many *successful* X-under-Windows products.  Any Windows app is a
local client.  Windows itself is the embedded window manager.  In point
of fact, the only disctinction between this and what I have suggested so
far is the fact that X programs that do widget drawing the way I've
suggested would llok like Windows programs when run in such an environment
instead of looking like Athena, Motif, or OpenLook based widget sets.
This is arguably of GREAT benefit to users in exactly the same way all
windows apps looking the same is of benefit: the learning curve is
reduced.


                                        Regards,
                                        Terry Lambert
                                        terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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

Crossposted-To: news.groups
From: mdw@cs.cornell.edu (Matt Welsh)
Subject: Re: STRAW POLL RESULT: Linux groups automonitoring
Date: Wed, 23 Mar 1994 02:11:41 GMT

In article <2mlgft$mkg@hearst.cac.psu.edu>,
Bernie Thompson <bernie@bjt105.rh.psu.edu> wrote:
>I am guilty of not paying attention to this straw poll.
>But clearly if something on a large scale is going to be
>done, it should have an 'official' vote instead of a
>straw poll.  I think too many people were ignoring
>this debate (I was).  (I know, the straw vote did
>have a large turnout)  

Ian clearly said that he would go ahead with his proposal based on the
results of the straw poll. If you didn't bother to vote NO to it, then
he does have mandate to do so.

I think that Ian's simple system of sending mail to anyone who doesn't
use subject lines of the form
        Subject: [keyword] ...
is a good one. Each newsgroup would have its own list of keywords. I think
that someone would think twice before posting something inappropriately
if they had to use an appropriate keyword to do so. If it doesn't work, it
doesn't work, and that will be that. Give it a shot.

mdw

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

From: peter@globv1.hacktic.nl (Peter Busser)
Crossposted-To: comp.unix.bsd
Subject: Re: BSD vs. Linux
Date: Tue, 22 Mar 1994 10:25:01 GMT

hasty@netcom.com (Amancio Hasty Jr) writes:

>In article <SJA.94Mar14164332@gamma.hut.fi> sja@snakemail.hut.fi (Sakari Jalovaara) writes:
>>> Yes, it does. The Ultrix kernel (for example) has all sorts of cruft
>>> in it associated with supporting obsolete terminal hardware and stuff
>>> like that. Just for example.
>why argue with this guy?

WHY ARGUE AT ALL? This is a Linux newsgroup, not a BSD newsgroup and certainly
not a Linux vs. BSD newsgroup. So please stop the crap! This newsgroup
hierarchy is already overflooded by a tidal wave of messages, so there is no
need for more.

Please please please please please please please please please, I beg you, stop
it or go somewhere else!

Groetjes,
Peter Busser

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

From: ez025807@othello.ucdavis.edu ( )
Subject: GUS cdrom daughtercard
Date: Wed, 23 Mar 1994 02:12:07 GMT

Has anybody used or attempted to use the GUS sony 31a daughter card w/ Linux?
And if so, what were the results?

Kelvin


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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Network stability of freeBSD vs. Linux
Date: Mon, 21 Mar 1994 18:14:56 GMT

In article <1994Mar19.164242.29773@hellgate.utah.edu> jensen%peruvian.cs.utah.edu@cs.utah.edu writes:
>Here are some questions that I have:
>
>Which os is more stable for long term up times?  This
>machine will essentially *not* be able to be down.
NetBSD is certainly stable, FreeBSD I can't say
>
>Which os handles network traffic better?  I heard that
>386bsd is better over slow lines...is this something that
>I will need to take into consideration as a major deciding
>factor?
You'll currently get better SLIP performance off *BSD
>
>Which handles having multiple people logged on better?
>Am I going to have more problems having 30 people logged
>on freeBSD or linux?
With a BSD system with shared libraries (ie the very latest)
it shouldn't lag much behind Linux.
>This machine may also be used as a SLIP server.  Which
>handles SLIP better?
Apart from the 6bit support BSD does.

If you need absolute stability at the cost of things like
performance, fancy features, DOS emulation etc then BSD
is probably the better choice (and I'm a Linux freak..)

Alan




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

Crossposted-To: comp.unix.advocacy,biz.sco.general
From: rpjday@cuug.ab.ca (R. Day)
Subject: Re: Opinions wanted about SCO-unix (vs AIX/Linux).
Date: Fri, 18 Mar 1994 21:52:49 GMT

Kees Hendrikse (kees@echelon.uucp) wrote:
: In <Mario.Eduardo.13.000C52CA@vu-wien.ac.at> Mario EDUARDO writes:

: > it is very simple to determine the quality of the SCO system :
: > 
: > get some public domain software (gnu cpio, gnu tar, gnu sed, inn, sendmail, 
: > various tcp daemons) and try to compile it. it was  a lot of work to compile 
: > GCPIO on ODT 1.1.0, and because of the compatibility ODT 1 to ODT 2 to ODT 3
: > it is lost time to try it on ODT 3. 

Gee, then what have I been doing lately?  I've managed to build gcc,
gas, binutils, shellutils, textutils, perl, emacs, sed, tar, cpio, glibc,
flex, bison,... pant, pant!  Some had to be hacked somewhat, most worked
straight out of the gzip file.

What's your problem, dude?

R. Day

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

From: merlyn@winternet.mpls.mn.us (Doug McIntyre)
Subject: Re: Mosaic 2.2 with FORMS?
Date: 22 Mar 94 23:47:06 GMT

>| However, this will not fix the forms problem.  I have libc 4.5.21,
>| XFree 2.1, and kernel 1.0.2 on my system.  Forms are still broken.
>| The only way to type into a form is by holding down all 3 mouse buttons
>| while you do so.  :(  Somebody said there's a bug in the current
>| Motif libs for linux.

   Its not a bug in the current Motif libs for Linux, its a bug in general
with Motif v1.2.0. Every platform saw it. If you compiled Mosaic (as I 
have done) with Motif v1.2.2, the problem goes away. You can try my
version by ftp'ing to icicle.winternet.mpls.mn.us. Its in the 
/uploads/Mosaic directory. 
--
Doug McIntyre                           merlyn@icicle.winternet.mpls.mn.us

Write to info@winternet.mpls.mn.us for more information about Winternet's
Internet services and dialups. 

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

Crossposted-To: comp.unix.advocacy,comp.unix.aix
From: jfh@rpp386 (John F. Haugh II)
Subject: Re: BRACE YOURSELF, was Re: Opinions wanted about SCO-unix (vs AIX/Linux).
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Date: Wed, 23 Mar 1994 03:49:52 GMT

In article <1994Mar20.154726.27188@kf8nh.wariat.org> bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:
>In article <1994Mar19.193036.26299@rpp386>, jfh@rpp386.cactus.org (John F. Haugh II) says:
>+---------------
>| In article <1994Mar18.172310.10200@kf8nh.wariat.org> bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:
>| >I dunno about that... IBM may have learned about open systems, but the reports
>| >I hear from the field about AIX suggest that it is even less Unix-compatible
>| 
>| AIX has more "standards" brandings than you can shake a stick at.  Most
>+------------->8
>
>I was thinking in terms of maintenance and administration.  Even if a manual
>administration procedure seems to work right, it tends to come back and bite
>you on the next upgrade... or so the reports go.  And the command-line version
>of SMIT operations is said to make the most cryptic Unix commands look
>downright pellucid.  :-)

I'm not aware of anything resembling this problem.  I currently administer
a 970, 950, 930, 560, 530 and a 220, in addition to my own office with
2 320's and a 520.  Most of the machines are at 3.2.5, though previously
they stretched from 3.2.0 to 3.2.5.  A colleague at a large installation
in Houston seems to swear by the machines -- his company buys 590s for
desk side machines.

As for SMIT commands, yes, but that's why SMIT exists -- so you don't have
to key in wads of crap on the command line.  The "ch/ls/mk/rm" paradigm
for administrative commands is the single best idea that's been present
for system administration in a decade.  My 970 has enough netgroup entries
that I wrot a {ls,ch,rm,mk}netgrp set of commands that I'd love for the
developers to include in the mythical next release.

Do you really like the alternative?  Is "sysadmsh" that much fun for you?
-- 
John F. Haugh II  [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ]   @'s: jfh@rpp386.cactus.org
 There are three documents that run my life: The King James Bible, the United
 States Constitution, and the UNIX System V Release 4 Programmer's Reference.

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

From: rene@renux.frmug.fr.net (Rene COUGNENC)
Crossposted-To: news.groups
Subject: Re: STRAW POLL RESULT: Linux groups automonitoring
Date: 22 Mar 1994 22:24:48 GMT
Reply-To: cougnenc@hsc.fr.net (Rene COUGNENC)

Ce brave Kenneth Herron ecrit:

> I think Mr. Jackson's mistake was in letting people get the idea he 
> needed their permission.

Can someone translate proprely this french sentence into English... ?:

        "La liberte des uns commence la ou s'arrete celle des autres".

--
 linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux 

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

From: vincent@malux.UUCP (Vincent Gillet)
Subject: Re: SCSI Magneto-Optical Drive Supported?
Date: 22 Mar 1994 22:51:55 GMT
Reply-To: gillet@renux.frmug.fr.net (Vincent Gillet)

Duncan C THOMSON ecrivait :

> We're looking to get an SCSI MO drive (probably about 1GB) on our
> system.  Before I order it / install it, does anybody know if these
> are supported by the Linux kernel, by patches, or would I have to
> write a devide driver for it.  I know SCSI card drivers exist, but
> which (if any) of the SCSI-CDROM, SCSI-tape and SCSI-generic drivers
> work for MO drives.

I've got a 128Mo Magneto-optical drive on my linux box.

It works on my 1542B exactly as a hard-disk. I can mount this disk as any
hard-disk, it means I can put DOS, ext2, .... I only have to mount it
correctly.

A good feature is I can't eject the disk before I umount the drive. So, there
is not problem about changing disks.

In fact, it works great.

--
0V0

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

Crossposted-To: comp.unix.advocacy,biz.sco.general
From: davidsen@sixhub.tmr.com (Bill Davidsen)
Subject: Re: Opinions wanted about SCO-unix (vs AIX/Linux).
Reply-To: davidsen@tmr.com (bill davidsen)
Date: Wed, 23 Mar 1994 00:10:31 GMT

My complaints with SCO are mainly with the header files. I don't care if
things meet fifty standards, if things which compile using the AT&T or
GNU headers compile and they don't on ODT, there's a compatibility
problem. It's not usually all that hard to solve.

I have SCO so I can cross compile for DOS, Xenix (including 286) and
OS/2. No one else offers me that. The SCO compiler and gcc show no
consistant advantage, althouge I can see a 20-30% difference in some
programs (not the same way in all cases).
-- 
Bill Davidsen, davidsen@tmr.com      |  C programming, PC based UNIX, data
    TMR Associates, +1 518-370-5654  |  acquisition, device drivers.
_____________________________________|______________________________________
New England Winter 93-94: Many are cold but few are frozen

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


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