Subject: Linux-Misc Digest #134
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:     Thu, 19 May 94 09:13:13 EDT

Linux-Misc Digest #134, Volume #2                Thu, 19 May 94 09:13:13 EDT

Contents:
  Help selecting good SCSI disk (Chris Gatcombe)
  Re: Clothes named after programming languages (Russell Kroll)
  Re: Standard Linux GUI (Mitchum DSouza)
  Re: FAQ : is Jana Publishing still trading? (Elvin Cheng)
  Re: Fortran ? (Nicholas Ambrose)
  Re: ISDN card drivers for Linux? (Jamie Honan)
  Re: Term 115 (beta) is out. (Matthias Rabe)
  Re: A good NFS server ? (Robert Sanders)
  Re: Why does GW2K P90 fail installation? (David Marples)
  Re: Linux in PC Week again (May 9th issue) (David Fox)
  Re: Improving Linux performance: What works best? (David Black)
  Re: Standard Linux GUI (Dan Newcombe)
  Re: DCF-77 radio clock (Claus-Dieter Bredl)
  Magic6.3/Linux (summary) (Murali Chaparala)

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

Crossposted-To: comp.arch.storage,comp.periphs.scsi,comp.sys.ibm.pc.hardware.storage
From: cpg@jet.uk (Chris Gatcombe)
Subject: Help selecting good SCSI disk
Date: Thu, 19 May 1994 09:17:16 GMT

Hello,

I am about to invest in a 1 GB SCSI disk and controller. I have a
486DX50 (ISA bus) with an existing 210 MB IDE drive.  I have on my
existing disk DOS and Windows, and Linux, and everything seem to work
well.  Of course, I am now short on disk space hence the requirement
for a new disk.

I am selecting a 1.0 GB disk, since I have heard there may be problems
concerning 1GB+ disks. I don't know if the problems are with the
controller bios, the disk, or the PC's bios.  I don't want to risk
buying a 2GB disk only to find I can't use a large part of it.  My main
concerns are to ensure full compatibility with DOS/Windows and Linux.

I have selected an Adaptec 1542CF, and as for a disk, I have quotes for
the following:

              Seagate  Seagate  Micropolis Digital IBM
              ST11200N ST31200N MIC2210    DSP3107 45G9466
Capacity:     1050MB   1052MB   1056MB     1070MB  1052MB
Avg seek:     10.5ms   9ms      10ms       9.5ms   8.6ms
Trk/trk seek: 1.5ms    1ms      1.5ms      1ms     0.6
Cache:        256k     256k     512k       512k    512k
Size:         HalfHgt  LowProf  HalfHgt    LowProf LowProf

All the drives above are fast SCSI-2, and have a 5 year warranty.

I don't want to rely too much on just numbers and specifications, so
has anyone any praise/horrors etc. they could share before I spend my
money?  Mail preferred, but posts are ok too (though with all these
newsgroups to wade through, I might miss something :-)

Thanks,
Chris.
-- 
Dr. Chris Gatcombe, Tessella Support Services plc (gatc@tessella.co.uk),
BSI/TickIT certification to BS5750/ISO9001/EN29001 (January 1993).
Contractor at: JET Joint European Undertaking (cpg@jet.uk).
"Don't let the Sun go down on me" - Elton John.
"Its the wrong trousers Gromit, and they've gone wrong!"
- Disclaimer: Please note that the above is a personal view and should not 
  be construed as an official comment from the JET project.

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

From: rkroll%cmptech@csn.org (Russell Kroll)
Crossposted-To: alt.folklore.computers,alt.religion.kibology
Subject: Re: Clothes named after programming languages
Date: Tue, 17 May 94 15:55:57 MDT

jaycjay@panix.com (Jay C Jachimiak) writes:

> Geoffrey Spear  wrote:
> 
> > lmccarth@cs.umass.edu (Lewis (YDNCTFL YWSRCFAOTW) McCarthy) writes:
> > this is, of course, because most American C compilers don't use {}'s
> > because American keyboards don't have a { key.  
> 
> That's not always true.  I'm using an IBM PC that I bought in 1984.  It
> does have a { key, but has no } key - so I still can't use my darn 
 
So what do you get when you shift ']' then?

--
rkroll%cmptech@csn.org |  Call Computech BBS at +1 719.260.6279   | Sysop of
 (alt)  rkroll@csn.org | USR HST/DS (28.8K V.FC, 21.6K V.32terbo) | cmptech

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

From: Mitchum DSouza <m.dsouza@mrc-apu.cam.ac.uk>
Subject: Re: Standard Linux GUI
Date: 19 May 1994 06:27:08 -0400
Reply-To: m.dsouza@mrc-apu.cam.ac.uk

| Edwin Ramirez wrote:
| : In article <2rb3e3$bbj@charm.magnus.acs.ohio-state.edu> Highlander,
| : tabaer@magnus.acs.ohio-state.edu writes:
| : >Well, OpenLook is freely available, but it's not too hot of an interface
| : IMHO.
| : >Maybe people can be convinced to standardize in Tcl/Tk, or the Notif
| : >project if anything comes of it (not intended as a slam, I just haven't
| : >heard if any progress has been made).
| 
| :       Having used Tcl/Tk for a while, I would propose it as a standard.  There
| : is a large user base and many programs and utilities are available for
| : it.  There are also people working on ports for MS-Windows and Macintosh.
| :  Also, its creator Dr. Ousterhout has gone to work for Sun, (Tcl/Tk
| : related projects).  The software will remain in available freely and it
| : is also Motif compliant.
| 
| Let's not forget that the industry is now moving towards a Motif variation
| called COSE (Common Software Env.) which is improved over Motif.  Applications
| conforming to this spcification will b appearing shortly.  It is not free
| but should improve over the Windows behaving Motif widgets.
| Personally I think Xview (Opnlook) is alright as a place to start but
| needs a commitment if developrs are going to adopt it.  It may
| technologically be behind the times but the SUN applications are quite
| nice by my standard.  The new COSE apps will behave more like the Openlook
| apps than the current Motif apps.  I'm all for a free Motif clone, but
| it really should follow the improved COSE specification (2 button mouse
| support, etc) for gneral acceptance!


If anyone is really interested in building a MOTIF compatable library, I suggest
they start by looking at the FWF Widgets which have all the 3D effects, RowCol
Widgets etc and only miss the Drag&Drop which however can be simply implemented
from rdd.tar.Z. It provides very professional looking GUI's.

See
        a.cs.uiuc.edu /pub/FWF

Mitch

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

From: echeng@corp.hp.com (Elvin Cheng)
Subject: Re: FAQ : is Jana Publishing still trading?
Date: 19 May 1994 09:51:52 GMT



: The node jana.com is in trouble, there were few post on the net
: I will try to do my best.

  I keep on believe you until this week, I have send the mail
  request some further information about your cd-rom package
  provided, either to jana.com or directly email to you
  I have cc a copy to my own account and I am pretty sure the
  mail go out without any problem, the mailer doesn't complain
  any problem about sending the mail to jana.com or your email
  address, I still haven't receive your reply for over 1 week.

  I have send the similar information enquiry to InfoMagic
  yesterday, and to my great surprise, they reply my mail within
  one day! Needless to say, I put the 3 sets of order to them.

  I don't want to blame on you, but if you can response the
  customer in time, I am sure more business will go to your
  side.

  Cheers,
  Cartier

  email: cartie@apits5.hkg.hp.com

  p.s. btw, if you still running the business, I am still interest
       to wait for your response.

















































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

From: na2@doc.ic.ac.uk (Nicholas Ambrose)
Subject: Re: Fortran ?
Date: 19 May 1994 11:02:44 +0100


In article <2reg7r$8oj@jeeves.niehs.nih.gov>, duling@hippo.niehs.nih.gov (dave duling) writes:
|> Is there an F77 compiler for Linux ?
yep.
but it translates to c first, then compiles with gcc.
it's called f2c and comes with slackware ( i think)
Nick
-- 
Senate, n.:
        A body of elderly gentlemen charged with high duties and
misdemeanors.
                -- Ambrose Bierce

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

From: jhonan@jolt.mpx.com.au (Jamie Honan)
Crossposted-To: aus.computers.linux,comp.dcom.isdn
Subject: Re: ISDN card drivers for Linux?
Date: 19 May 1994 09:47:43 GMT

>>Just to round off this long-winded article: I don't recommend external
>>TA's. You lose too much bandwidth in 'framing'.

>That depends on what kind of line protocol the TA uses. Currently, the
>most popular (that I'm aware of, anyway) is V.110, which is a non-framing
>rate adaption protocol, and V.120, which is a framing/multiplexing protocol.

>V.120 offers increased functionality over V.110, at the cost of some framing
>overhead.

I thought there was a general move towards V.120, mainly because it allowed
multiplexing. I'm on very shakey ground here... 

>In the case of a PC card, I believe that some framing technique is employed
>whenever one bonds 2 B-channels for increased bandwidth. This may be 
>necessary because of the possibility of path differences (and consecutive
>differences in transmission delay) between the two B-channels.

Using SLIP or PPP and TCP/IP I guess there's always lots of 'framing'.

>Ragnar Nielsen
>Technical Manager
>ID Communication as

Who are ID Comm's? Do you have any PC ISDN cards in Aus?

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

From: rabe@mathematik.uni-bielefeld.de (Matthias Rabe)
Subject: Re: Term 115 (beta) is out.
Date: Tue, 17 May 1994 20:23:35 GMT

In article <jds.769010503@dutsh7.tudelft.nl>,
Jan D. Smit <jds@dutsh7.tudelft.nl> wrote:
>
>A few days ago I compiled 1.14 on ultrix... And I made a patch and sent it
>to oreilly... So maybe he will include those patches in the next release, so
>it will compile on ultrix from then...
>
What do you needed to patch? 
For me, 1.14 compiled right out of the box with gcc (term 1.08 too).
It was Ultrix 4.3 and gcc 2.5.8.

-- 
rabe@mathematik.uni-bielefeld.de                          Matthias Rabe
Universit"at Bielefeld                            Privat: Avenwedder Str. 494
U5-133                                                    D 33335 G"utersloh
Tel.: (0521) 106-3871                                     Tel.: (05209) 6673

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

From: gt8134b@prism.gatech.edu (Robert Sanders)
Crossposted-To: comp.os.386bsd.misc,comp.unix.unixware,comp.unix.solaris
Subject: Re: A good NFS server ?
Date: 18 May 1994 17:56:59 -0400

acg@kzin.cen.ufl.edu (Alexandra Griffin) writes:

>In article <CpC9Fq.I2n@acsu.buffalo.edu>,
>Ziniu "Michael" Wei <ziniuwei@acsu.buffalo.edu> wrote:
>>I'm concern about the filesystem speed on Linux.  Can anyone give a
>>comparison between Ext2fs and the BSD fastfilesystem used in Sun?

>I don't have any real numbers, but in comparing my Linux box to a
>friend's comparably-equipped FreeBSD machine (both 486dx2/66's with
>IDE drives, 16mb RAM), I've notice that disk-intensive operations like
>large inter-filesystem recursive copies are slightly faster under
>Linux's ext2fs than on freeBSD.  Based on data from the "top" utility,
>it seems that Linux tries to use as much free memory as it can for
>disk buffers, while BSD has a definite limit on buffer cache (large

That probably isn't the reason.  For one, the buffer cache can only
get so big, and then things have to trickle to disk; i.e. the process
is still disk-bound if it's got enough data moving around.  However,
*BSD derivatives perform synchronous directory structure updates,
which means that every new entry to a directory causes that block to
be flushed, and things get to disk in a very definite order.  Linux,
by default, treats directory buffers like any other buffers.  The
*BSD way can be good thing in the event of a crash, but it's really
only a minor barrier to corruption.  A log-structured filesystem is
much more useful for data-loss prevention.  However, if you really
want the *BSD behavior (which is much slower), you can tell ext2fs
to work that way with the "-o sync" option to mount.

I have always, and especially now with the 'cluster' patches,
found Linux's filesystem throughput *very* satisfactory.  I
get around 1.2 MB/sec filesystem throughput on my MXT540A IDE drive 
on a relatively unfragmented filesystem (device throughput isn't
significantly higher, so I guess ext2fs is fairly effieicnt).

>One major deficiency wrt Linux is its *very* slow NFS service-- it's
>presently slower than that on any other Unix implementation I've used.
>Can anyone explain why this might be so?

The server, or the client side?  The client doesn't do any caching,
and currently only used 1K blocks for data transfers.  That's more
than enough to make it slow.  Some people are noodling with this,
or plan to.

-- 
 _g,  '96 --->>>>>>>>>>   gt8134b@prism.gatech.edu  <<<<<<<<<---  CompSci  ,g_
W@@@W__        |-\      ^        | disclaimer:  <---> "Bow before ZOD!" __W@@@W
W@@@@**~~~'  ro|-<ert s/_\ nders |   who am I???  ^  from Superman  '~~~**@@@@W
`*MV' hi,ocie! |-/ad! /   \ss!!  | ooga ooga!!    |    II (cool)!         `VW*'

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

From: dmarples@voyager.comms.eee.strath.ac.uk (David Marples)
Crossposted-To: comp.os.linux.help
Subject: Re: Why does GW2K P90 fail installation?
Date: 19 May 94 12:00:33


   In article <2qrjkc$gom@tuba.cit.cornell.edu>,
   Luke M Kaven <lmk6@crux1.cit.cornell.edu> wrote:
   >Further word on this is that the CMOS PROM reports the correct
   >geometry for the Conner 540MB IDE drive.  The problem is that
   >(hd.c) reports incorrectly that the drive has 32 heads and
   >then gives up on it.  
   >

Yes, the CMOS does report the correct geometry, but it (by default)
auto-detects it from the hardware.  Copy the figures you have and
enter them into one of the user defined entries in the table.
Everything should then be sweetness and light.  I've heard of one
report where this didn't work and the drive geometry had to be entered
into the config file - but he still got it working in the end.

I've yet to hear of a GW2K that doesn't work with Linux - of course,
its only a matter of time.....

   From what I can gather,  hd.c failed to detect the hard geometry
   and it must be attributed to the PCI IDE controller.

Nope, the PCI is passive and (AFAIK) has no impact on the performance
+ or -, of the system.  Of course, you're not using the special PCI
features...

E-Mail for more - I've a few notes on GW's and Linux if anyone wants a
copy...


DAVE


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

From: fox@graphics.cs.nyu.edu (David Fox)
Subject: Re: Linux in PC Week again (May 9th issue)
Date: 18 May 1994 15:05:51 GMT

In article <2raip6$m7t@lo-fan.jpl.nasa.gov> Gerald_C_Snyder@ccmail.jpl.nasa.gov (gsnyder) writes:

] Ah, the never-ending wait.  Soon the Sexium and 486dx10-1000 will

Let's see, 486DX10-1000, according to Intel product numbering that
must be a clock quadrupled 486 running internally at 300 MHz, right?

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

From: dave@hh.sbay.org (David Black)
Subject: Re: Improving Linux performance: What works best?
Date: 18 May 1994 13:48:22 -0700

In <2rc9lv$78n@apollo.west.oic.com> dillon@apollo.west.oic.com (Matthew Dillon) writes:

>    itself.  The only thing that takes major CPU on my machine in the news 
>    subsystem is when I run mthreads to thread the heirarchy for trn.

You can use the overview channel to have INN maintain .overview files
for each newsgroup. Trn can use these just as it uses the output
of mthreads (whatever those files are called). So you just
add another entry to your newsfeeds file for overview (see sample newsfeeds
file) and you don't need to run mthreads any more. And of course the
articles are threaded as they arrive, which is convenient.

Tin also knows how to use .overview files - no more waiting to
thread newsgroups as they are entered, or caching of indices. The
same facility (XOVER) is available to NNTP readers.

You must run expireover in addition to expire when you do overview BTW.
The news.daily script ordinarily does this once a day anyway.

Dave
-- 
David L. Black                     dave@hh.sbay.org
Hip-Hop BBS  Sunnyvale, CA         KE6AJC @ N0ARY.#NOCAL.CA.USA.NOAM

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

From: newcombe@aa.csc.peachnet.edu (Dan Newcombe)
Subject: Re: Standard Linux GUI
Date: Tue, 17 May 1994 17:01:58 UNDEFINED

In article <2rb8qo$o4m@cs.pdx.edu> mike@cs.pdx.edu (Mike Harvey) writes:
>>Is it just me or does anybody else feel that what the Linux (UNIX) 
>>community needs is a SINGLE, STANDARD, ONLY ONE, Graphical User Interface 
>>(GUI)?  The purpose of a GUI is to reduce the learning curve when moving 
>>from application to application in a graphical environment.  Unfortunately, 
>>due to the lack of any real (FREE) standards, it is just as aggravating 
>>to move between many X applications as it is between most TEXT applications.

>What about fvwm, the default interface which comes with Slackware?

Yes, fvwm is nice, but as the name implies, it is only a Window Manager.  
Those are pretty much the same, click on a window and drag it, etc...

What needs to be standardized is the User Interface.  This is how things work 
in programs.  For instance, pull down menus:
When I click on a menu, do I need to keep my mouse button down until I 
highlight the selection I want, then release? or do I click on the menu, then 
release, and then click on the choice?

Windows, via it's API, has a standard interface.  If I want a pull down menu, 
under Borland C++, I create the resource, and tell my program it's there 
(simplified version).  When I click on the menu, Windows handles it all, until 
I make my menu choice, and THAT is returned to the program.  This way all 
menus in all programs work the same.   On a like note, there is the Open File 
dialog.  This is a standard call also, and therefore, all programs that need 
to open a file could look the same.

Under X, as was said, there are many different API's: Xt, Xlib, Xaw, Xview, 
Motif, Tcl, and probably about a dozen I forgot.  This gives each application 
a different style and different feel.  Each application, even though the menu 
may be exactly the same as the previous application, could interface totally 
different.

This is what is being argued should be standardized.  Personally, I think that 
the OSF should place Motif (not just the specs) in the public domain, but then 
again, I am a dreamer :)

        -Dan

--
Dan Newcombe                    newcombe@aa.csc.peachnet.edu
Clayton State College           Morrow, Georgia
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"And the man in the mirror has sad eyes."       -Marillion

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

From: cdb@tph116.fkp.physik.th-darmstadt.de (Claus-Dieter Bredl)
Subject: Re: DCF-77 radio clock
Date: 19 May 1994 11:49:13 GMT

BARRY TITMARSH (BTITMARS@ESOC.BITNET) wrote:
: The ftp site that carries the dfc77clock.tgz appears to be an UNKNOWN host
: has any one ftpd this file from ftp.rrzk.uni-koeln.de ?

host uni-koeln.de
uni-koeln.de mail is handled by rs1.rrz.Uni-Koeln.DE
uni-koeln.de mail is handled by noc.rrz.Uni-Koeln.DE

  aah... not "rrzk", but "rrz" :-) 

host ftp.rrz.uni-koeln.de
ftp.rrz.uni-koeln.de is a nickname for rs1.rrz.Uni-Koeln.DE
rs1.rrz.Uni-Koeln.DE has address 134.95.100.208
rs1.rrz.Uni-Koeln.DE mail is handled by rs1.rrz.Uni-Koeln.DE
rs1.rrz.Uni-Koeln.DE mail is handled by noc.rrz.Uni-Koeln.DE

CDB

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

From: murali@magnet.fsu.edu (Murali Chaparala)
Crossposted-To: comp.lsi.cad
Subject: Magic6.3/Linux (summary)
Date: 18 May 1994 21:35:44 -0400

        Here is a short summary of the responses that I have received 
regarding the usability of Magic6.3 on a Linux system. My thanks to all 
those who replied. 

Two people experienced some problems. They suspect that the problems were
due to possible bugs in older shared libs and limited hardware (insufficient
swap). Everybody else is very happy with Linux/magic and have experienced
no problems. One person said he is using magic with NetBSD without any
problems. Everyone, including those who had  problems, highly recommend
Linux/magic combination.

      A more detailed version, along with the replies that I received is 
available for anonymous ftp from: 
        magnet.fsu.edu /users/murali/magic6.3-summary
--
Murali Chaparala, murali@magnet.fsu.edu



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


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