Subject: Linux-Misc Digest #394
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, 7 Jul 94 10:13:11 EDT

Linux-Misc Digest #394, Volume #2                 Thu, 7 Jul 94 10:13:11 EDT

Contents:
  QIC02 Support (Elvis Chow)
  Re: Need help building ultimate Linux system (Tim Smith)
  Re: [printing] How to make your OL400e cook! (Bill Hogan)
  Re: VP/ix for Linux? (Lutz Molgedey)
  MIDI & Linux (James W. Abendschan)
  Re: Heated debate(?) on OS/2 and Linux programming. (mibo@isi026.isi.kfa-juelich.de)
  Re: KSH fixed (was Re: KSH is REALLY BROKEN in Slackware!) (Bob Kupiec)
  Re: disk buffers question (Lars Wirzenius)
  Re: Linux, nntpd & Trumpet News (long)
  Re: Linux better than OS/2 for net surfing (Rick Kelly)
  Re: GIF viewer experience (Mitchum DSouza)
  Re: [Q] X-Win xdm fails-how do I get back to run-level 5? (Bjorn Lindstrom)

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

From: echow@etu1.educ.ucalgary.ca (Elvis Chow)
Subject: QIC02 Support
Date: Thu, 7 Jul 1994 06:33:53 GMT

Just got started into LINUX (Slackware 1.2 with 1.1.24 kernel).
Was wondering if there was a way of getting Linux to support an
Archive FT60 using SC499r controller or Archive VP150 with SC402
card?  Noticed a little thing of a Wangtek notice that pops up
during initialization, but claims TQIC02 fails initialization.
Is there any support for the above yet?



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

From: tzs@u.washington.edu (Tim Smith)
Crossposted-To: comp.windows.x.i386unix
Subject: Re: Need help building ultimate Linux system
Date: 7 Jul 1994 11:23:38 GMT

Michael L. VanLoon <michaelv@iastate.edu> wrote:
>The PCI NCR controllers are fine, I'm sure.  But you must remember
>these are dumb controllers.  I.e. the CPU has to process all the

Wait a second.  I thought they were using 53C700 family SCSI chips
on some of these.  That would make them not dumb controllers.

>converts the information into signals on the SCSI bus.  While it's
>doing this, it can't be doing anything else, meaning your CPU is tied
>up for the duration of the SCSI transaction.  You get what you pay
>for.

What about DMA?  Even dumb host adaptors can usually use DMA for the
data transfer, thus allowing the CPU to work on other things.

--Tim Smith

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

From: bhogan@crl.com (Bill Hogan)
Subject: Re: [printing] How to make your OL400e cook!
Date: 7 Jul 1994 04:36:07 -0700

Steve DuChene (s0017210@cc.ysu.edu) wrote:
:       Do you know if the Okidata 400e is supported by any drivers that
:       come with Ghostscript? For instance do the HP Lazer Jet drivers work?
: -- 
: | Steven A. DuChene   sduchene@cis.ysu.edu  or  s0017210@cc.ysu.edu    
: | Youngstown State University  | Computer Science / Math / Mech. Eng.
: |They all laughed at Albert Einstein. They all laughed at Columbus. 
: |Unfortunately, they also all laughed at Bozo the Clown. 

 Sure, the OL400e emulates straight PCL4.5 (a.k.a LaserJet2+).

From my /etc/printcap:
======================
#From: wing@research.canon.oz.au (Wing Chung)

hp|hp2p ascii text:\
        :lp=/dev/lp1:\
        :sd=/usr/spool/lpd/hp:\
        :mx#0:\
        :lf=/usr/spool/lpd/hp/hp_ascii_log:\
        :if=/usr/spool/lpd/hp/hp_ascii_filter:\
        :sh:\
        :sf:

hp_ps|hp2p postscript:\
        :lp=/dev/lp1:\
        :sd=/usr/spool/lpd/hp:\
        :mx#0:\
        :lf=/usr/spool/lpd/hp/hp_ps_log:\
        :if=/usr/spool/lpd/hp/hp_ps_filter:\
        :sh:\
        :sf:


/usr/spool/lpd/hp/hp_ascii_filter:
=================================
#!/bin/sh
# Set HP LaserJet for printing unix ascii text
#
echo -ne \\033\&k2G
cat
echo -ne \\f


/usr/spool/lpd/hp/hp_ps_filter:
===============================
#!/bin/sh
#
# Set HP LaserJet for printing postscript via Ghostscript
#
/usr/bin/gs -q -dSAFER -dNOPAUSE -sDEVICE=ljet2p -sOutputFile=- \
   -sPAPERSIZE=letter -r300 -


 E.g. # lpr -Php_ps whatever.ps


 Special thanks to Karl Auer for his part in the Linux Printing-HOWTO.

 Bill
-- 
  Bill Hogan
{echo "Subject: get bhogan@crl.com" | mail pgp-public-keys@pgp.mit.edu}

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

From: molgedey@theo-physik.uni-kiel.de (Lutz Molgedey)
Subject: Re: VP/ix for Linux?
Date: 7 Jul 1994 10:59:23 GMT
Reply-To: molgedey@theo-physik.uni-kiel.de

In article mc3@galaxy.ucr.edu, thp@corsa.ucr.edu (tom payne) writes:
> Lutz Molgedey (molgedey@theo-physik.uni-kiel.de) wrote:
> : In <2v1j2v$57t@galaxy.ucr.edu> thp@corsa.ucr.edu (tom payne) writes:
> 
> : >Mike Jagdis (jaggy@purplet.demon.co.uk) wrote:
> 
> : [deleted]
> 
> : >It is my impression (from a brief conversation with Locus founder
> : >Jerry Popek) that Merge provides a virtual 386 in a manner similar to
> : >the IBM virtual machine monitor, VM/370: user-mode instructions run
> : >directly on the host machine, but privileged instructions fault and
> : >are virtualized (faked) by the fault-handler software, e.g., console
> : >writes are virtualized to an X-window. (A difficulty is that the 386
> : >architecture has mode-sensitive instructions that are not priviliged,
> : >i.e., that don't trap in user mode, so Merge uses a special loader
> : >that tweaks occurrences of those opcodes into illegal opcodes, thus
> : >forcing them to trap to a handler that untweaks the instruction and
> : >virtualizes it.)  [deleted stuff]
> 
> : Uhhh, sounds strange. How the special loader 'tweaks occurrences of those
> : opcodes into illegal opcodes'. Are they using single step mode (but
> : this would be slow)?????
> 
> Presumably there are enough illegal opcodes that this mapping (tweaking)
> can be one to one (i.e. reversible).  This forces single-stepping of 
> (only) the mode-sensitive instructions, of which there are supposedly
> not all that many.

OK, but will the loader distinguish code from data? The loader hase to know where
the non-8086 instructions are located to change them to illegal instructions.
And how will this programm deal with self modifying code? I guess you have
to interpret (or dynamical compile) the code.

> 
> : >If my impression is correct, one can run DOS/Windows 3.1 (and possibly
> : >even 4.0, when it comes out) directly on the virtualized 386, with the
> : >software thinking that it is running on real hardware.  This provides
> : >the ability to run all well-behaved Windows applications under Unix,
> : >a major goal of the WINE project. [deleted stuff]
> 
> : We are working on DPMI support for dosemu. I guess this will in principle
> : allow us to run all programs that run under OS/2 including a patched
> : Windows 3.1 (may be we use direktly os2k386.exe).
> 
> : >Tom Payne (thp@cs.ucr.edu)
> : >University of Calif., Riverside
> 
> : greetings,
> : Lutz.
> 
> That would be much appreciated.  A lot of us need to be able to run
> MS-Windows applications on the machines we run Linux, and rebooting is
> not an acceptable solution.

I guess the better solution is wine, but later you will have both opportunities
(WINE or DOSEMU).

> 
> Tom Payne (thp@cs.ucr.edu)
> University of Calif., Riverside
> 
> 


Lutz.
==============================================================================
Lutz Molgedey                    |molgedey@theo-physik.uni-kiel.de
Institut f|r Theoretische Physik |http://www.theo-physik.uni-kiel.de/~molgedey 
Olshausenstr. 40                 |Tel. (+49/431)8804071
D-24118 Kiel                     |Fax. (+49/431)8804094



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

From: unkadath!shamus@naucse.cse.nau.edu (James W. Abendschan)
Subject: MIDI & Linux
Date: Thu, 7 Jul 1994 00:32:30 GMT

If anyone has any sample code on how to read MIDI information (basically
note on/note off codes) with the soundblaster (thru /dev/sequencer?) please
let me know.

James

-- 
James W. Abendschan                "Turing," she said.  "You are under arrest."
...!naucse!unkadath!shamus    shamus@unkadath.uucp      jwa@sunset.cse.nau.edu

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

From: mibo@isi026.isi.kfa-juelich.de
Crossposted-To: comp.os.os2.advocacy
Subject: Re: Heated debate(?) on OS/2 and Linux programming.
Date: 7 Jul 94 11:48:22 GMT
Reply-To: mibo@isi026.isi.kfa-juelich.de

In <HALLU.94Jul6205302@jacquard.info.polymtl.ca>, hallu@jacquard.info.polymtl.ca (Louis-D. Dubeau) writes:

>I don't know about him but *I* tried... and abandoned. I couldn't find
>any decent documentation on the language. OTOH, if you look at elisp,
>it comes with *complete* documentation. It took me one week approx to
>be able to start seriously programming in elisp. BTW, I tried to
>program in `e' and get the most out of EPM before I tried to learn
>elisp and get the most out of emacs. The interesting thing is that I
>own legal copies of OS/2 2.0 and 2.1 and finally decided to erase it
>from my HD. I still think it is much better than Windogs or MS-DOG.

So you have used both EMACS and EPM. Well from time to time I'm about to
install EMACS on my system. But then step back when I read the requirements:
10MB to be usefull and >20MB with elisp sources. Tell me without referring
to programming the thing: is the user interface comparable to EPM now or
do I have to remember a pile of CNTRL-META-ESC sequences? Does it have file select
boxes or do I have to type the name of the file I want to load?

---
Michael Bode


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

Crossposted-To: comp.os.linux.help
From: kupiec@tigger.jvnc.net (Bob Kupiec)
Subject: Re: KSH fixed (was Re: KSH is REALLY BROKEN in Slackware!)
Date: Thu, 7 Jul 1994 13:02:50 GMT

In <1994Jul6.162750.7320@tigger.jvnc.net>, kupiec@tigger.jvnc.net writes:
>>|I've found a rather obvious bug in ksh in Slackware 1.2.  The version
>>|is "KSH_VERSION=@(#)PD KSH v4.9 93/09/29".
>>|$ ls bin tmp >> outfile
>>|$ od -c outfile
>>|0000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
>>|*
>>|0001140  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0   b   i   n   :  \n  \n
>>|0001160   t   m   p   :  \n
>>|0001165
>
>It seems to work just from the re-building the source.  If anybody wants
>to pick up a binary copy, it's on ftp.jvnc.net in /priv/kupiec/pdksh.

I've been told that people who what older versions of the libraries
might still have trouble.  Here is what I am using:

fred $ ldd /bin/ksh  [the broken one]
        libc.so.4 (DLL Jump 4.4pl4) => /lib/libc.so.4
fred $ ldd new-ksh   [the fixed one]
        libc.so.4 (DLL Jump 4.5pl24) => /lib/libc.so.4
fred $ uname -a
Linux info 1.1.13 #21 Tue Jun 7 09:40:25 GMT 1994 i486


(libc.so.4 is a link to libc.so.4.5.24)
-- 
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

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

From: wirzeniu@cc.Helsinki.FI (Lars Wirzenius)
Subject: Re: disk buffers question
Date: 7 Jul 1994 15:45:27 +0300

dannys@hurricane.seas.ucla.edu (Danny Sung) writes:
> This isn't a particularly pressing question, but I was rather curious...
> I've seen from a couple of sources that Linux has the ability to use all
> "free" memory as drive cache.  What I wanted to know is: Is this a read
> cache, or both a read-write cache?  (stage write, or write through?)
> 
> Also, is this a feature of Unix's in general?

Here's what I wrote for the (still unpublished version of) system
administrators' guide on this subject.  Feedback and corrections
very welcome.

The Buffer Cache

        Reading from a disk\footnote{Except a RAM disk, for obvious
        reasons.} is very slow compared to accessing (real) memory.
        In addition, it is common to read the same part of a disk
        several times during relatively short periods of time.  For
        example, one might first read an e-mail message, then read the
        letter into an editor when replying to it, then make the mail
        program read it again when copying it to a folder.  Or,
        consider how often the command ls might be run on a
        system with many users.  By reading the information from disk
        only once and then keeping it in memory until no longer
        needed, one can speed up all but the first read.  This is
        called disk buffering, and the memory used for the
        purpose is called the buffer cache.

        Since memory is, unfortunately, a finite resource, the buffer
        cache usually cannot be big enough (it can't hold all the data one
        ever wants to use).  When the cache fills up, the data that
        has been unused for the longest time is discarded and the
        memory thus freed is used for the new data.

        Disk buffering works for writes as well.  On the one hand,
        data that is written is often soon read again (e.g., a source
        code file is saved to a file, then read by the compiler), so
        putting data that is written in the cache is a good idea.  On
        the other hand, by only putting the data into the cache, not
        writing it to disk at once, the program that writes runs
        quicker.  The writes can then be done in the background,
        without slowing down the other programs.

        Most operating systems have buffer caches (although they might
        be called something else), but not all of them work according
        to the above priciples.  Some are write-through: the
        data is written to disk at once (it is kept in the
        cache as well, of course).  The cache is called 
        write-back if the writes are done at a later time.
        Write-back is more efficient than write-through, but also a
        bit more prone to errors: if the machine crashes, or the power
        is cut at a bad moment, or the floppy is removed from the disk
        drive before the data in the cache waiting to be written gets
        written, the changes in the cache are usually lost.  This
        might even mean that the filesystem  (if there is one)
        is not in full working order, perhaps because the unwritten
        data held important changes to the bookkeeping information.
        Because of this, you should never turn off the power without
        using a proper shutdown procedure (see an as yet unwritten
        chapter), or remove a floppy from the disk drive until it
        has been unmounted (if it was mounted) or after whatever program
        is using it has signalled that it is finished and the floppy drive
        light doesn't shine anymore.  The sync(8) command flushes
        the buffer, i.e., forces all unwritten data to be written
        to disk, and can be used when one wants to be sure that everything
        is safely written.  There is a program running in the background
        which does a sync every 30~seconds, so it is usually not necessary
        to use sync.

        The cache does not actually buffer files, but blocks, which are
        the smallest units of disk I/O (under Linux, they happen to
        be 1~kB).  This way, also directories, super blocks, other
        filesystem bookkeeping data, and non-filesystem disks are
        cached.

        The effectiveness of a cache is primarily decided by its size.
        A small cache is next to useless: it will hold so little data
        that all all cached data is flushed from the cache before it
        is reused.  The critical size depends on how much data is read
        and written, and how often the same data is accessed.  The
        only way to know is to experiment.

        If the cache is of a fixed size, it is not very good to have
        it too big, either, because that might make the free memory
        too small and cause swapping (which is also slow).  To make
        the most efficient use of real memory, Linux automatically
        uses all free RAM for buffer cache, but also automatically
        makes the cache smaller when programs need more memory.

        Under Linux, you do not need to do anything to make use of
        the cache, it happens completely automatically.  Except for
        following the proper procedures for shutdown and removing
        floppies, you do not need to worry about it.


--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
My name is Ozymandias, king of kings/Look on my works, ye Mighty, and despair!

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

From: mvalente@draco.lnec.pt ()
Crossposted-To: news.software.nntp,news.admin.misc
Subject: Re: Linux, nntpd & Trumpet News (long)
Date: 7 Jul 1994 13:13:33 GMT

Martin Schulze (joey@infodrom.north.de) wrote:

: I run Linux 99p15 with Net2Debugged. Then I have the performance
: release for cnews up and running. Now I need to have a nntp server
: sometimes.

: I thought I could take nntpd and I found nntpd-1.5.11t which seem to
: work (with trn). But I don't need the nntpd for another unix program
: but for DOS Trumpet News.


: Now: Trumpet tries to connect, connection established, posting allowd.
: Trumpet reads all groups. Then if I select a group within Trumpet, it
: tries to get the contents of it. But then it hangs - and after a
: timeout it reads the rest from the socket, but it produces rubbish.

: Another hint: With trn there were no problems. I then borrowed me the
: nnrpd from INN and modified it. Trumpet works fine with it. But then I
: want to have another feature added: nnrpd cannot receive articles
: using ihave..., but nntpd can!

  I also have the same problem but I'm running Linux 1.0 ( Slackware 1.2 )
 
  When "scanning" for messages on a newsgroup over NNTP, Trumpet News
 hangs up.
 
  If I use tin with -r ( to read from the NNTP daemon instead of using
 /usr/spool/news ) the thing works. If I telnet to port 119, it works.
  With Trumpet it doesnt.
 

  Anyone have any hints ?
 

  C U!
 
    Mario Valente
 



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

Crossposted-To: comp.os.os2.advocacy
From: rmk@rmkhome.com (Rick Kelly)
Subject: Re: Linux better than OS/2 for net surfing
Reply-To: rmk@rmkhome.com (Rick Kelly)
Date: Thu, 7 Jul 1994 06:50:17 GMT

Alan Cox (iiitac@uk.ac.swan.pyr) wrote:
: In article <9407040537.04@rmkhome.com> rmk@rmkhome.com (Rick Kelly) writes:
: >Linux will not produce viable SCO binaries.
: Funny I know three commercial vendors who only use SCO for the test phase now

So Linux libc.a is compatible with SCO libc.a?

And the shared library stuff is also compatible?

: >Like it or not, SCO is the biggest UNIX platform.
: By financial value not by volume as far as I can tell.

SCO sells to thousands of shops running 6 to 8 terminals off a PC.

: >SCO is more stable than Linux.
: Sure as hell wasn't here.

I'm not a SCO groupie, but I've had good luck with it.

See my .sig.  Progress Software.  SCO boxes with 36 megs that allocate
20 megs of shared memory.  QA test suites that emulate 100+ users.

It has surprised me with its robustness.

: >For someone who wants to make money selling software packages, SCO is
: >obviously better than Linux.

: Yep because you have to have money to burn to buy it. To be honest SCO and
: Linux are as far apart as DOS and NT Advanced server. I doubt Linux will ever
: compete with SCO nor SCO with Linux for that simple reason.

Exactly.



-- 

Rick Kelly  rmk@rmkhome.com  rmk@bedford.progress.com

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

From: Mitchum DSouza <m.dsouza@mrc-apu.cam.ac.uk>
Subject: Re: GIF viewer experience
Date: 7 Jul 1994 09:44:56 -0400
Reply-To: m.dsouza@mrc-apu.cam.ac.uk

| Any other non-X folks have any experience with a GIF viewer
| that runs under you-know-what?
| 
| I looked thru the usual archives and say nothing. If I missed
| it, speak up.....

Try sunsite.unc.edu /pub/Linux/apps/graphics/viewers. Nice ones are zgv, and
spic (IMHO)

Mitch

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

From: Bjorn_Lindstrom@net.com (Bjorn Lindstrom)
Crossposted-To: comp.windows.x.i386unix,comp.os.linux.help,comp.windows.x
Subject: Re: [Q] X-Win xdm fails-how do I get back to run-level 5?
Date: 6 Jul 1994 22:41:30 GMT

In article <Bjorn_Lindstrom-060794143019@mac_140_241.net.com>,
Bjorn_Lindstrom@net.com (Bjorn Lindstrom) wrote:
> 
> Hi,
> 
> I apparently did something really dumb to my RC.6 file ... can anyone
> tell me how I can get back to run level "5" (from the inittab) without
> RE-installing (and compiling in my case) my Linux system?

I should mention I am running Linux v.1.1.2, and XFree86 v.2.1.1, with
Slackware (version unknown).

> My "boot floppy" seems to want to use the inittab file that is already
> on my installed system.  I can't seem to get there from the "install 
> floppies" ... is there something I'm missing?

Thanks,

Bjorn
"F.O.D. - Fresh off the DOS ..."

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


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