Subject: Linux-Development Digest #135
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Wed, 7 Sep 94 13:13:19 EDT

Linux-Development Digest #135, Volume #2          Wed, 7 Sep 94 13:13:19 EDT

Contents:
  SNMP Under Linux (MATTHEW TIPPETT)
  Re: Multiprocessing Pentium Systems (Ulrich Teichert)
  Re: Why was ncp removed in 1.1.48? (Alan Cox)
  Re: linux never swaps ? (Alan Cox)
  Re: Linux - my first impressions (Alan Cox)
  Re: Multiprocessing Pentium Systems (Robert Manners)
  Re: cat /proc/interrupts doesn't show printer ints. (Bruce Evans)
  Re: XFconfig86 problems - HELP! (Walter Hunt)
  Re: Kernel change summary 1.1.45 -> 1.1.46 (Bruce Evans)
  Re: Future of linux -- the sequel (Mike Kenney)
  Re: DOSEMU 0.53 notes (Harry C Pulley)
  Re: DOSEMU 0.53 notes (Harry C Pulley)
  DOSEMU 0.53pl18 und 1.1.49 : Serial Problems (Martin Cornelius)
  Re: cat /proc/interrupts doesn't show printer ints. (David Hinds)
  PCI+Pentium+Linux+X? (David J Topper)
  Re: Acid (was: Simple acid test) (David Wright)
  Re: Linux console to SCO comp. prob (David Wright)
  Re: Unicode & Linux's future (was Re: Acid) (Richard L. Goerwitz)

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

From: [email-masked] (MATTHEW TIPPETT)
Subject: SNMP Under Linux
Date: 6 Sep 94 21:49:53 +0930

Hi...

Can anyone point me to any information on using SNMP under Linux,
I have looked over sunsite & tsx-11 and have had no luck whatsoever...

Replies via email please, the volume here is a bit high..

Matt

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

From: [email-masked] (Ulrich Teichert)
Subject: Re: Multiprocessing Pentium Systems
Date: 7 Sep 1994 13:38:20 +0200

In <[email-masked]> [email-masked]. (Tim Morley) writes:

>In article <[email-masked]>,
>David Williams <[email-masked]> wrote:
>>
>>I've just seen some new dual processor pentium systems in Computer
>>Shopper.  They look swell for the money, but there isn't a single OS
>>that can take advantage of them.  Anybody have any thoughts about how
>>hard it might be to make Linux one of the first OS's to take advantage
>>of these systems?

>Well it would be hard to do so, as OS/2 SMP already exists and is
>avaliable for dual processor machines...
As is NT. There was a test in a german mag (c't), if you wrote about
the ASUS MB.

Uli
-- 
Ulrich Teichert       Voice :        +49 4321 71582
Stormweg 24           E-mail: [email-masked]
24539 Neumuenster, Germany // listening to:
X-Ray Spex: Oh! Bondage Up Yours! // Buzzcocks: Inside

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

From: [email-masked] (Alan Cox)
Subject: Re: Why was ncp removed in 1.1.48?
Date: Wed, 7 Sep 1994 10:45:15 GMT

In article <[email-masked]> [email-masked] (Frank Lofaro) writes:
>Why was NCP removed in 1.1.48?
>Too alpha to end up in 1.2.0, or did Novell threaten to sue? :(

It was something Mark Evans added that really didnt belong in the kernel
(NCP uses three sockets in a way you can handle cleanly in user mode).

Alan

-- 
  ..-----------,,----------------------------,,----------------------------,,
 // Alan Cox  //  [email-masked]   //  GW4PTS@GB7SWN.#45.GBR.EU  //
 ``----------'`----------------------------'`----------------------------''

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

From: [email-masked] (Alan Cox)
Subject: Re: linux never swaps ?
Date: Wed, 7 Sep 1994 10:46:20 GMT

In article <[email-masked]> [email-masked] (JANI KURKI-SUONIO) writes:
>Try Xchess from Yggdrasil summer'94 CD-ROM distribution. It has some
>bug, and it fills out your computer's memory- no matter how much you
>have.

Its not a bug it just uses huge hash tables in its standard configuration 
trading memory for speed. If you get the source you can tune it to sane
values.

Alan

-- 
  ..-----------,,----------------------------,,----------------------------,,
 // Alan Cox  //  [email-masked]   //  GW4PTS@GB7SWN.#45.GBR.EU  //
 ``----------'`----------------------------'`----------------------------''

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

From: [email-masked] (Alan Cox)
Subject: Re: Linux - my first impressions
Date: Wed, 7 Sep 1994 10:50:28 GMT

In article <[email-masked]> [email-masked] (Warner Losh) writes:
>The EEPROMS on Solbourne machines can read the boot blocks and the
>file system.  The EEPROMs on Sun machines, at least older ones, need
>to be told where the bootblocks are.  The Sun's bootblocks understand
>the file system.

Suns boot block works just like lilo and uses a set of hardcoded block
numbers to load a program off the root disk (/boot) that then runs and
knows about BSD(well the sun variant) ffs. Lilo can load such a loader if
you feel like writing one.

As far as I a concerned at least lilo is superb, it does the job and its
small. I don't care whether my boot loader understands BSD FFS or
presidential speeches. It doesn't need to know either to do the job. If I
wanted a featured boot loader I could use the OS/2 one that thinks its an
entire window system but uses 1Mb of disk.

Alan
-- 
  ..-----------,,----------------------------,,----------------------------,,
 // Alan Cox  //  [email-masked]   //  GW4PTS@GB7SWN.#45.GBR.EU  //
 ``----------'`----------------------------'`----------------------------''

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

From: [email-masked] (Robert Manners)
Subject: Re: Multiprocessing Pentium Systems
Date: Wed, 7 Sep 1994 08:30:41 GMT

In article <[email-masked]> "David Williams" <[email-masked]> writes:
>
>I've just seen some new dual processor pentium systems in Computer
>Shopper.  They look swell for the money, but there isn't a single OS
>that can take advantage of them.  Anybody have any thoughts about how
>hard it might be to make Linux one of the first OS's to take advantage
>of these systems?
>
I hate to disillusion you, but System V has an optional symettric 
multiprocessing package, as does Unixware. NT also comes with multiple
processors. We're actullay running all three here (we're a deveopment site 
for hardware, you see). Mind you, all of these systems cost $$$$$, but then
so does our MP system!

Linux could be the first *FREE* (in both the price and FSF senses of the word)
system to do symettric MP!!! You have the sources, go for it.

-- 
=============================================================================
R.J.Manners       Diagnostics & BIOS Development Engineer (!)
                  ICL Intel(tm) SuperServers 
=============================================================================

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

From: [email-masked] (Bruce Evans)
Subject: Re: cat /proc/interrupts doesn't show printer ints.
Date: 7 Sep 1994 22:00:27 +1000

In article <[email-masked]>,
Chris Metcalf <[email-masked]> wrote:
>In article <[email-masked]>,
> <[email-masked]> wrote:
>> The Subject says it all. I am *almost* sure my printer uses INT7, as I set it
>>by tunelp, and it works, and if I set it to another value, it doesn't. 
>
>The printer interrupt is only grabbed when the device is open.  Try

There needs to be a counter per (driver, interrupt) pair.  Dynamically
loaded drivers are especially interesting.  I'd like to preserve
accumulated statistics across kernel reboots.  Write them to a log file
or something.  Unloading drivers or unattaching their interrupts could
be handled in the same way.
-- 
Bruce Evans  [email-masked]

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

From: [email-masked] (Walter Hunt)
Crossposted-To: comp.windows.x.i386unix,comp.os.linux.help
Subject: Re: XFconfig86 problems - HELP!
Date: 7 Sep 1994 00:57:11 GMT

In article <[email-masked]>, Carlos Dominguez <[email-masked]> writes:
|> 
|> Hi..
|> 
|> Day three, and I still cannot get X up and running on my linux box.
|> I'm using the slackware 2.0 distribution from the morse cd-rom.
|> 
|> As per the HOW-TO's I tried to run the XFconfig86 shell scripts.
|> 
|> I still am getting errors like "cannot cat /tmp/??????"
|> whenever I try to run Xfconfig86 included in my slackware 2.0 cdrom 
|> distribution. 
|> 

        If this is the same XFConfig86 that I tried to run, I bet you are
telling it to emulate a 3-button mouse. The one I had would place
"Emulate3Buttons" before the mouse defs, causing a domino effect that would lead
to an empty tmp file (like the complaint you saw) that was supposed to hold the
modes available for the card.

        If you edit the Template file in the XFConfig directory
(/usr/X11/lib/X11/XFConfig?) and move the Emulate3Buttons line down one, you
should be a much happier camper.

-- 
Walter Hunt                                             [email-masked]
Philips Interactive Media of America                    Los Angeles, Ca.

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

From: [email-masked] (Bruce Evans)
Subject: Re: Kernel change summary 1.1.45 -> 1.1.46
Date: 7 Sep 1994 22:33:12 +1000

In article <[email-masked]>,
Brad Midgley <[email-masked]> wrote:
>In article <[email-masked]>,
>John McClary Prevost <[email-masked]> wrote:
>
>[multi-user mode changing of append-only/imutable bits]
>
>>[stops cracker from modifying old syslog entries]
>
>For this purpose, the raw device must also be immutable.  But what
>about mknod?  How would mknod know which created-devices should be
>immutable?  a root break-in could do anything he wanted to the file
>system with access a writable raw device (albeit difficult).

In BSD 4.4lite, in secure mode, disks for mounted file systems are
read-only.  In highly secure mode, disks are read-only whether mounted
or not.  The man page notes that this inhibits running newfs.  It
would also inhibit writing to floppies (if floppies are disks :-).
-- 
Bruce Evans  [email-masked]

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

From: [email-masked] (Mike Kenney)
Subject: Re: Future of linux -- the sequel
Date: 7 Sep 1994 04:25:53 GMT

In article <[email-masked]>,
Larry Pyeatt <[email-masked]> wrote:
>I never said SGI was the only way to go.  I just said that Intel makes
>the worst processors available and it would be nice to have an alternative.
>I used MIPS R4600 as an example and all you people seem to think that the
>R4600 is somehow the same thing as an SGI Indy.  Honestly, I would rather
>have an Alpha or PA-RISC processor than the MIPS processor.  The point I
>am making is that a PC with a decent (read non-Intel) processor, running
>Linux would be a very powerful and affordable system.
>
>

Well, I'm not sure you've made your point ... you're talking about
virtually nonexistent systems.  Until RISC *systems* become commodity
priced they aren't going to make a dent in the low-end market.  IMHO
Intel is going to control the low-end for quite a while.

While I agree that the PC architecture has quite a few flaws (I wouldn't
touch it if I couldn't run Linux on it :-) the price can't be beat.

-- 
Mike Kenney
[email-masked]

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

From: [email-masked] (Harry C Pulley)
Subject: Re: DOSEMU 0.53 notes
Date: 7 Sep 1994 12:59:11 GMT

[email-masked] wrote:
: >The only other problem I have noticed is that mem does not show any EMS memory
: >even though I ask for it.  Am I the only one for which EMS doesn't show up?  
: >
: >Harry

: In config.sys, load the driver `ems.sys' that came in dosemu.

Yes, someone also emailed me about this.  It works great!  I know, should have
RTFMed...

Thanks,
Harry
--
<:-{}   [email-masked]       |This message released|It takes all kinds,
 \      Harry C. Pulley, IV       |to the PUBLIC DOMAIN.|and to each his own.
==================================+=====================|This thought in mind,
Stay away from the DOS side, Luke!|Un*x don't play that.|I walk alone.

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

From: [email-masked] (Harry C Pulley)
Subject: Re: DOSEMU 0.53 notes
Date: 7 Sep 1994 12:59:36 GMT

[email-masked] wrote:
: Rob Janssen ([email-masked]) wrote:
: : In <[email-masked]> [email-masked] (Mark Krischer) writes:

: : what patchlevel?
: I am using 1.1.42 dosemu0.53pre17

: : I don't think so.  Only ET4000, S3, trident for now.
: I to wish they supported ATI.  I have one (weird card) and DOSEMu stops
: when I try to use the graphics mode.  Do I need to make a copy of the 
: BIOS for the video card?  Any strange thing to get graphics mode.  Character
: mode works great.  The old DOSEMu 52 worked with the ATI.  Cursor looked 
: funny but it worked.  

I have a Cirrus Logic 5428 and it works great in graphics mode under 0.53.

Harry
--
<:-{}   [email-masked]       |This message released|It takes all kinds,
 \      Harry C. Pulley, IV       |to the PUBLIC DOMAIN.|and to each his own.
==================================+=====================|This thought in mind,
Stay away from the DOS side, Luke!|Un*x don't play that.|I walk alone.

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

From: [email-masked] (Martin Cornelius)
Subject: DOSEMU 0.53pl18 und 1.1.49 : Serial Problems
Date: 7 Sep 1994 13:28:17 GMT

I just successfully installed Kernel 1.1.49 and Dosemu 0.53pl18,
but the serial Ports seem to be not working at all. When I try
to install the MS mouse-driver or the Logimouse driver, they
both say that no mouse can be found. Also, Procomm cannot access
the ports. I'm sure the harware is o.k. as i can use the ports
with kermit, selection and X. The serial entries in my dosemu.conf  
didn't change since dosemu 0.52, where everything worked fine.

Any Hints ??

====================================================
Martin Cornelius, ZARM-FAB, Uni Bremen 0421-218-4807
Hochschulring / Am Fallturm             28359 BREMEN
====================================================

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

From: [email-masked] (David Hinds)
Subject: Re: cat /proc/interrupts doesn't show printer ints.
Date: 7 Sep 1994 04:26:10 GMT

Glenn Moloney ([email-masked]) wrote:

: Some drivers only request interrupts when they are opened, and release
: them when closed. An example is the floppy driver, which uses interrupt
: 6, but only requests the interrupt (request_irq()), while a floppy is
: open. Hence IRQ 6 does not appear in /proc/interrupts (except whil
: accessing the floppy). I have not
: checked if this is the case with the lp driver.

: This is a good thing, in that it allows different
: devices to use the same interrupts (if used at different times).
: However, it reduces the usefulness of the /proc/interrupts file.

: There may be some usefulness in device drivers registering with the
: kernel what resources (irq,dma,port addresses,shared memory) the
: software and hardware use. This useful system config information could
: then be made available in the /proc filesystem. I have several cards and
: device drivers installed on my system, and it would be nice to find a
: /proc entry to find free irqs, dma channels and port adresses for
: instaling new cards on the system. It would make managing many Linux
: boxes in a laboratory type situation a lot easier (particularly if you
: have device drivers which auto detect the hardware, but don't
: permanently grab the IRQ).

I agree that this would be a good thing.  Sharing interrupts is a good
thing, but if you've got interrupts to spare, it is better to avoid
it, since it prevents simultaneous use of the sharing devices.

One option would be to have a mechanism for "reserving" resources like
ports and interrupts.  Other drivers could still allocate a reserved
resource, but a driver for a device with programmable interrupts could
try to find a line that isn't reserved.

        -- David Hinds
           [email-masked]

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

From: [email-masked] (David J Topper)
Crossposted-To: comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc
Subject: PCI+Pentium+Linux+X?
Date: 7 Sep 1994 14:12:03 GMT

Newsgroups: comp.os.linux.admin,comp.os.linux.help,comp.os.linux.development,comp.os.linux.misc
Subject: Pentium PCI + Linux X Motiff
Summary: 
Followup-To: 
Distribution: usa
Organization: Columbia University
Keywords: 
Cc: 

Hello,

I could really use some help on the following:

1)  Does Linux support the Pentium?
2)  Does Linux support 32 | 64 bit Video (PCI)?
3)  Would an SCSI HD make life better?
4)  How does one get Linux + a GUI (X Windows / Motiff) + a C++ compiler
    and other utils?
5)  Are there any major brand hardware peices I need to watch out for?
6)  Or, is there a list (are there lists) of Linux / Xfree86 / C++ 
    compatibility and availability w/respect to Pentium / PCI Video. 
    I'd LOVE to know.

I really need to buy a machine and get Unix (Linux) running ASAP.  I do 
some DOS programming so I'd like to go with the Pentium and whatnot, but
perhaps not...  From what I've gathered, I need to watch what I buy if I
go with Linux.

Help would be very greatly appreciated.  My other option is to just buy
the SCO Unix (spelled $$$).  I'd like to avoid that.

Thanks,

DT

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

From: [email-masked] (David Wright)
Subject: Re: Acid (was: Simple acid test)
Date: Tue, 6 Sep 1994 14:25:25 GMT

>>>>> "MK" == Mike Kenney <[email-masked]> writes:

  MK> In article <[email-masked]>,
  MK> Richard L. Goerwitz <[email-masked]> wrote:
  >> then, well, a lot of goons would be out of work.  But we'd be that
  >> much closer to Nirvana.
  MK>                 ^^^^^^^ I think they broke up :-)

        Yeah, too much "acid testing". :-)

                                                        Dave
--
  ____________________________________________________________________________
 |        /\ /          | Prism Computer Applications        |  David Wright  |
 |      -/--\--         | 14650 Detroit Ave, Suite LL40      | [email-masked] |
 |      /____\          | Lakewood, OH 44107  USA            |  216-228-1400  |

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

From: [email-masked] (David Wright)
Subject: Re: Linux console to SCO comp. prob
Date: Tue, 6 Sep 1994 14:37:10 GMT

=====BEGIN PGP SIGNED MESSAGE=====

>>>>> "RJ" == Rob Janssen <[email-masked]> writes:

  RJ> The problem of the original poster was that his keyboard recognition software
  RJ> is broken and he wants to blame someone else for it.
  RJ> I have written a tree-based keyboard table as well, years ago, and I
  RJ> never have seen problems like that.  It also works with Linux.  Probably
  RJ> his code is not using a tree datastructure where it should.

        It isn't "broken" per se, we just don't want to have to recompile the
library it uses just because of Linux. We have had it running in various
forms under various OS's for many years, and I have *never* come across a
system that has such long key sequences as Linux does. I knew what Linux and
our software was doing as soon as I saw it, and I was just commenting that it
was a shame that whoever designed the default US layout for Linux didn't try
and emulate something that ran on the majority of Unix systems out there.
        Our stuff runs fine on VT220's, VT320's, etc. and other ancient DEC
equipment, so I really can't imagine why such long function key sequences were
thought to be needed.

                                                        Dave

=====BEGIN PGP SIGNATURE=====
Version: 2.6

iQCVAwUBLmx+j2++A+T9du0zAQE0ygQAhmsdKv02HioOV/S8438SHux/duFR74C6
lR8mtSVT8eBKjOTvl+a4G3YdhkI24/RXfQdS77WL2xltlq5dHMTEYP18PABpDKF/
RVBvT/LvSBMcJg1j2dDSVwW3WasWxU+nPKvVN7jaC8ORx9Y4RWFH+QR8DvyMIdPY
r+IyudD/qVo=
=fWX5
=====END PGP SIGNATURE=====
--
  ____________________________________________________________________________
 |        /\ /          | Prism Computer Applications        |  David Wright  |
 |      -/--\--         | 14650 Detroit Ave, Suite LL40      | [email-masked] |
 |      /____\          | Lakewood, OH 44107  USA            |  216-228-1400  |

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

From: [email-masked] (Richard L. Goerwitz)
Subject: Re: Unicode & Linux's future (was Re: Acid)
Reply-To: [email-masked]
Date: Wed, 7 Sep 1994 14:21:38 GMT

In article <[email-masked]> [email-masked] (Andries Brouwer) writes:
>[email-masked] (Darin Johnson) writes:
>
>>But it's overkill.  You don't need special support from the keyboard
>>drivers to support input methods.  All you need is for the input
>>consumer to map internally.  Most input methods work by running as
>>a separate process rather than being embedded into the OS.
>
>I agree entirely. And for Chinese, Japanese etc that is the only way to go.

For Hebrew, Greek, Cyrillic, etc. you can get away with a change in the
default keyboard map.  For Amharic I'd think the method you speak of would
work great.  Amharic uses base letter forms that represent consonants, and
which change form depending on the vowel that follows.  There are too many
forms for a simple keyboard.  You could use meta keys.  But I wonder if it
would make more sense for Amharic just to use standard ASCII keys that go
to a server that composes them on the fly.

For Arabic, please help me out:  Arabic varies letter shapes according to
context.  A word-initial qof, for example, looks very different from a
word-final one.  The letter shapes don't vary the way they do in Amharic
script (according to CV sequences), but rather vary according to their
position in the word and their position in relation to other letters.  It
is essentially a cursive script.  How should this be handled?

>>> >Finally, do the display drivers
>>> >and GUIs support multiple wordwrap directions?
>
>>Again, this is best solved in the application, not the GUI (and
>>especially not the display driver).
>
>>Of course, this begs the issue of getting 'ls' to display with a
>>mixture of left-to-right and right-to-left scripts - but running
>>'ls' (or more likely, an 'nls') inside a multilingual window
>>solves this.  I think it's better to start there and make progress
>>than to ponder how to fit all that code into the console device...

There are lots of issues here all wrapped into one.  First of all, how
will multilingal text be stored?  Let us suppose we have an Arabic
word in the midst of some English text.  The English will run left-to-
right, while the Arabic will run right-to-left (-thgir nur lliw cibarA
tfel-ot).  Does the underlying text get stored in the same direction
as the English?  (English-Arabic)  Or does it get stored in its natural
order (English-cibarA)?  The advantage of the second order is that the
applications don't need to know what is what.  They just display the
string as-is.  However, when it comes to wordwrap time they will fal-
ter.  You have to know where text in one language begins and another
ends in order to get things right.

So what do we do?  Should all applications be smart enough to know how
to wrap every script on the face of the planet, and be able to recog-
nize codes for those languages (i.e. know where the English ends and 
the cibarA begins?).  Seems overkill.

I like the idea of a multilingual "window" except that this implies X,
and X is largely out of our control.  Even the development of a multi-
lingual "window" would be silly, since we'd essentially have to write
a new set of widgets that probably wouldn't be anywhere near as good
as Motif, etc. :-).

Anyone thought this all through?  My feeling is that right now the best
course is to encourage programmers to avoid code that relies on things
like the exact underlying code for 'a' and that assumes characters will
be 8-bits.

>I did it once, and found that only a few changes were required
>(like: x++ becomes x += dx), and it was not very difficult to make ls
>go top-to-bottom or right-to-left. (The most difficult part was getting
>the screen to scroll horizontally.) But not many people seem to be
>interested in such features.

Not many people are accustomed to computers being properly localized
for anything other than Latin-based or left-right scripts!

-- 

   -Richard L. Goerwitz              [email-masked]
   [email-masked]          rutgers!oddjob!ellis!goer

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

** 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: [email-masked]

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

    Internet: [email-masked]

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