Files
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest116
2024-02-19 00:24:15 -05:00

553 lines
23 KiB
Plaintext
Raw Blame History

From: Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
To: Linux-Development@senator-bedfellow.mit.edu
Reply-To: Linux-Development@senator-bedfellow.mit.edu
Date: Sun, 4 Sep 94 02:13:05 EDT
Subject: Linux-Development Digest #116
Linux-Development Digest #116, Volume #2 Sun, 4 Sep 94 02:13:05 EDT
Contents:
Unicode & Linux's future (was Re: Acid) (Richard L. Goerwitz)
Re: DOSEMU 0.53: Developers and testers ne (Matthias Urlichs)
SCSI chip AM53C94JC supported? (Harri Pasanen)
Re: XFree & CDROM slow down transfer rate (Robert Stockmann)
Re: more than 2 COM ports at the same time (Sander van Malssen)
HP-NSVT drivers??? (Stephen Vance)
1.1.49 SCSI errors (JL Gomez)
Not all memory seen on Compaq Deskpro M (EISA) (Jean-Francois Panisset)
Re: Acid (was: Simple acid test) (Mike Kenney)
Re: Any interest for DCF77 clock code? (Rob Janssen)
Re: DOS BC++/Linux floats (Michel Anders)
Re: Linux - my first impressions (Rob Janssen)
Re: IDE Performance enhancement (Rob Janssen)
Re: PGP Signature (Was: Suggest:SCSI Tape File System) (Jeffrey Oxenreider)
----------------------------------------------------------------------------
From: goer@quads.uchicago.edu (Richard L. Goerwitz)
Subject: Unicode & Linux's future (was Re: Acid)
Reply-To: goer@midway.uchicago.edu
Date: Sat, 3 Sep 1994 20:44:20 GMT
In article <348tgi$n2e@ionews.io.org> gabe@io.org (Lau) writes:
>
> You are completely missing out on what makes a internationalize OS so
>hard to make. There are already hundreds of standard formats for different
>languages,...
But none of these standards is truly multilingual, except for Unicode/
ISO 10646. So the obvious answer is to standardize on these, and to for-
get about all of the conflicting local standards. There is no way that an
OS can support a myriad of incompatible schemes, and no way it should. So
you are right that I'm missing the point. But you've missed the point that
my missing the point is the point :-).
>>Incidentally, what is this Mule? Is this a truly internationalized
>>product, or a hack to get the OS to work with some specific non-western
>>language like Japanese?
>
> While MULE was principly developed in Japan, it can handle various
>coding schemes for different languages assuming they can coexist.
>
> Again, "truly internationalized" is something that will take a while in
>any OS. Can you think of ANY OS or app that will allow you to write from
>left to right(English & most European languages), right to left(Hebrew) AND
>top to bottom from the left to right (Chinese), all in the same document?
FIRST OF ALL (I don't mean to shout), let's get straight one thing: Mule
is not fully internationalized. It supports a few Asian scripts, and that
is it. This is great, but let's not tout this as any sort of system-wide
solution. It sounds, in fact, as though it might be the exact wrong ap-
proach, although I have only read the docs within the last few days, and
cannot make any blanket statements.
SECONDLY, let's consider what it means to "support" multiple languages. On
the lowest level, it means simply that the operating system and its core
drivers permit the use of character representations that may be wider than
8 bits. After this there are several more issues to consider. The first
is input methods: Do the keyboard drivers work with the operating system
in such a way that one can, on the fly, change one's keymap? Does it sup-
port contextual code changes (e.g. Arabic letters will differ depending on
their position relative to other letters)? Finally, do the display drivers
and GUIs support multiple wordwrap directions? And are their conventions
for storing messages, text, etc. as separate "resources" so that one can
switch from one set to another for localization purposes?
The idea of switching code pages (DOS/OS2-ish) or doing setlocale calls,
as one finds with ANSI C is antithetical to certain aspects of the Uni-
code/ISO 10646 design philosophy, in the sense that this philosophy en-
compasses all national scripts, rather than forces us to toggle between
incompatible standards. Some toggling will always be needed, of course.
But the toggling, I'd think, would be between pages in the Unicode and
ISO 10646 space.
Now to your final question: Is any OS fully internationalized? Well, it
depends on what level you're talking. NT uses Unicode internally. UTS-8
is a standard for encoding multi-byte characters in a traditional 8-bit
system, so potentially any Unix system could, to some extent, follow suit.
As for the GUI, the Mac has WorldScript. If you follow certain coding
standards, WorldScript allows one to write along merrily in English, then
switch to Greek, or even Arabic or Hebrew, and continue writing merrily
along (with the directionality and wordwrap and keyboard changing on the
fly). I've been doing the same thing, happily, under DOS using Multi-
Lingual Scholar (Gamma Productions). Also I hear news that the next ver-
of Motif will have the multidirectional wordwrap code enabled.
So things are improving. What can we do here under Linux? I really can't
say. I just don't think that the old idea of multiple conflicting schemes
represents a workable form of internationalization. Nor does hacking this
or that software to do this or that language.
Am I babbling nonsense, or am I making sense?
--
-Richard L. Goerwitz goer%midway@uchicago.bitnet
goer@midway.uchicago.edu rutgers!oddjob!ellis!goer
------------------------------
From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: DOSEMU 0.53: Developers and testers ne
Date: 2 Sep 1994 09:32:29 +0200
In comp.os.linux.development, article <Pine.LNX.3.90.940901110123.217B-100000@leonard.anu.edu.au>,
rxr401 <rxr401@leonard.anu.edu.au> writes:
>
>
> It has nothing to do with Dosemu. Fdd drivers in many of the v1.1.4x
> kernels (including 1.1.49) won't let you mount a write-protected disk. It
> doesn't seem to be a bug, rather a deliberate choice in the fdd driver.
That's not a bug, that's a feature. Mounting or opening a write-protected
medium in read-write mode doesn't make sense. Therefore the kernel won't
allow it (not any more, anyway).
Open / mount the thing read-only and it'll work.
--
Q: How can a real man tell when his girl friend's having an orgasm.
A: Real men don't care.
--
Matthias Urlichs \ XLink-POP N<>rnberg | EMail: urlichs@smurf.noris.de
Schleiermacherstra<EFBFBD>e 12 \ Unix+Linux+Mac | Phone: ...please use email.
90491 N<>rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE
Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
------------------------------
From: pa@tekla.fi (Harri Pasanen)
Subject: SCSI chip AM53C94JC supported?
Date: 02 Sep 1994 11:38:07 GMT
Hello,
Could someone 'in the know' tell me if AM53C94JC scsi chip is
supported? I'm looking into installing Linux on an ICL Ergo D4/66dXGi
machine, which has the above mentioned scsi chip on mainboard, along
with ATI Mach 32 and Fujitsu 86965 ethernet chip.
Is NCR53c7,8xx is a close enough relative to AM53C94JC?
Thanks,
Harri
--
======================================================
Harri Pasanen pa@tekla.fi
------------------------------
From: stock@dutsh7.tudelft.nl (Robert Stockmann)
Subject: Re: XFree & CDROM slow down transfer rate
Date: Sun, 4 Sep 1994 02:24:00 GMT
In <CvK5Dq.6Lo@cix.compulink.co.uk>, Simon P Allen (simonallen@cix.compulink.co.uk) wrote:
: What you are likely seeing is the buffer cache in action. I could beleive
: that you *seem* to get something like 5.6Mb/s but your only reading from
: system RAM at that speed. When X is loaded some of the buffers get
: tossed out and Linux has to go to the real hardware for data. This
: almost *has* to be the explaination because like the gentleman said, 'The
: CD-ROM you got aint gonna do that speed'.
So if X tosses out my so-called buffer for the scsi-controller, which
is as you said, located in my system RAM, Then I might get some more RAM
to prevent this buffer from being tossed out. I now have 12 Mbyte,
If I toss in some 8 Mbyte more (total of 20 Mbyte: above the 16Mbyte limit of
Linux.), could the transferrate of my scsi-disk become more stable?
BTW I test the transferrate by doing:
# time dd if=/dev/sda1 of=/dev/null bs=32k count=128
Robert Stockmann
------------------------------
From: svm@kozmix.xs4all.nl (Sander van Malssen)
Subject: Re: more than 2 COM ports at the same time
Reply-To: svm@kozmix.xs4all.nl
Date: Sun, 4 Sep 1994 04:40:53 +0200 (MET DST)
doolittle@cebaf.gov writes:
> Harry C Pulley (hpulley@uoguelph.ca) wrote:
> : I already have 2 parallel ports on 5 and 7 and
> : a sound card on IRQ7. Unfortunately, I don't think my multi-I/O card can
> : change the IRQ for COM4 to IRQ2. Thus, changing IRQs is not an option.
>
> I trust you know that the lp driver does not use IRQ's,
Not so. The lp driver polls by default, but can be made to use IRQs
with tunelp(8). But usually there are plenty free channels left in
the IRQ 8-12 region.
> and the
> existence of setserial package to tell Linux about non-standard
> IRQ's for serial ports. The only step left is for you to realize
> that changing IRQ's in hardware *is* an option. I did it on a
> multifunction board, this is actually easiest. Run a wire from a
> COM IRQ jumper post to an LP IRQ jumper post. The posts are wire
> wrap posts, so any thin wire with a few turns will be grabbed and
> make reliable electrical contact. It took me about twenty minutes
> staring at the board traces with good lighting to figure out which
> two posts required the jumper. If you are not a hardware type, and
> don't want to learn, find a friend who is. It really is pretty easy.
Alternatively, if you have to use an IRQ between 8-12, there
probably won't be a suitable jumper. In that case, a bit of wire, a
soldering iron, knowledge of the ISA bus pin layout and perhaps a
sharp knife will do the trick. (I used this method to have /dev/cua0
use IRQ5 instead of 4 because I hadn't thought of wire-wrapping the
jumpers ;-)
Cheers,
Sander
--
Sander van Malssen
svm@kozmix.xs4all.nl
------------------------------
From: srvance@unix.secs.oakland.edu (Stephen Vance)
Subject: HP-NSVT drivers???
Date: 2 Sep 1994 11:30:52 GMT
I am trying to get Linux accepted as our R&D platform of choice at work.
The rest of the departments will end up using DOS/Windows (yecch!), but
it makes sense for their needs. However, ...
We have a box running HP-MPE/iX without HP's ($$$$) telnet services.
The only other way I am aware of to connect to it is by using NSVT. Does
anyone know of drivers or sufficient info to write one? Needless to say,
HP was less than helpful, particularly since they are discontinuing the
protocol.
Steve
------------------------------
From: kitana!sysop@caprica.com (JL Gomez)
Subject: 1.1.49 SCSI errors
Date: 3 Sep 1994 18:31:27 -0500
Reply-To: kitana!sysop@caprica.com
What exactly are these SCSI errors from 'dmesg'?
scsi0 : reseting for second half of retries.
SCSI disk error : host 0 id 1 lun 0 return code = 18000002
Current error sd813: sns = f0 3
Raw sense data:0xf0 0x00 0x03 0x00 0x04 0xa3 0x24 0x0a 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
scsidisk I/O error: dev 0813, sector 164644
scsi0 : reseting for second half of retries.
SCSI disk error : host 0 id 1 lun 0 return code = 18000002
Current error sd813: sns = f0 3
Raw sense data:0xf0 0x00 0x03 0x00 0x04 0xa3 0x24 0x0a 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
scsidisk I/O error: dev 0813, sector 164644
scsi0 : reseting for second half of retries.
Can reformatting the HD help matters?
Thanks for the explanations!
--
sysop@kitana.org
------------------------------
From: panisset@CIM.McGill.CA (Jean-Francois Panisset)
Subject: Not all memory seen on Compaq Deskpro M (EISA)
Date: 2 Sep 1994 09:13:38 -0400
I have a Compaq Deskpro 486/33M, which is an EISA bus machine with the
processor on a card. The machine has 20M of RAM, which is happily seen
by the power-on test, the EISA diagnostics/setup disk and
DOS. Unfortunately, neither the 1.0.8 nor the 1.1.49 kernels see more
than 8Mb of this memory. Does anyone have any ideas why this might be?
I compiled the kernels with the "limit memory to low 16Mb" option set
to no. For reference, the machine also contains a WD80x3 Ethernet
board and an ATI GUP video board. Could the fact that the GUP is
mapping its frame buffer into the address space be a problem? (but
then, it should also be on another machine, a Dell EISA with 32Mb and
a GUP: the kernel happily sees all the memory on that machine).
JF
--
Jean-Francois Panisset
School: panisset@cim.mcgill.ca Work: panisset@cae.ca
------------------------------
From: mike@wavelet.apl.washington.edu (Mike Kenney)
Subject: Re: Acid (was: Simple acid test)
Date: 2 Sep 1994 23:59:58 GMT
In article <1994Sep2.023807.24567@midway.uchicago.edu>,
Richard L. Goerwitz <goer@midway.uchicago.edu> wrote:
>Being an American, I realize that it's hard for us to understand a
>multilingual environment like India, Canada, much of Russia, etc.; or
>a culture like Iran or Turkey, where Arabic has a certain standing as
>a religious language, though the populace speaks a non-Semitic vernacu-
>lar. What I don't understand is why foreign markets are putting up
>with the whole mess by permitting single-language localizations. If
>everyone just said, "Give me a fully internationalized OS that sup-
>ports wide characters and has a script manager built into the GUI,"
>then, well, a lot of goons would be out of work. But we'd be that
>much closer to Nirvana.
^^^^^^^ I think they broke up :-)
Hmmm. If they are "putting up with it", maybe it's not that big
an issue.
--
Mike Kenney
mikek@apl.washington.edu
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Any interest for DCF77 clock code?
Reply-To: pe1chl@rabo.nl
Date: Fri, 2 Sep 1994 07:25:28 GMT
In <34554oE82f@uni-erlangen.de> bon@lte.e-technik.uni-erlangen.de (Uwe Bonnes) writes:
>In article <342g7s$q33@urmel.informatik.rwth-aachen.de> dak@rama.informatik.rwth-aachen.de (David Kastrup) writes:
>>Trying to get a head count...
>>How many people would be interested in a small program which gets the current
>>time from the radio clock DCF77 (receivable about 900km around Frankfurt,
>Before you write one, look with "archie -s dcf"! There are several!
I did that a few times before, but I never found what I really needed...
There is one program that processes raw clock data, but it draws a
full-screen clock and needs manual interaction to set the system clock
from that. It also just warps the time. Not really what I want.
Other programs use "processed" data from expensive clocks that send the
time as some ascii string. I don't have such clock.
Then there is XNTP, but it is much too complicated for me (network
oriented, I just want to sync a single machine). And the DCF77 module
in there also doesn't act on raw data, I think.
Do you know about a program that runs as a daemon, uses adjtime, and
processes raw data? (e.g. on a COM port set to 50 bps)
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: michela@sci.kun.nl (Michel Anders)
Subject: Re: DOS BC++/Linux floats
Date: Fri, 2 Sep 1994 11:36:18 GMT
In <34633v$2lr@harbinger.cc.monash.edu.au> kevinl@bruce.cs.monash.edu.au (Kevin Lentin) writes:
>Riku Saikkonen (riku.saikkonen@compart.fi) wrote:
>> So, is there a way to read the Borland C++ floating point numbers in
>> Linux? Now I have a converter to convert the data file to ASCII and
>> back, but that's not an optimal soluion...
>Have you tried using double in DOS? You could be having the same int/long
>problem you were having with integers. Linux is 32bit and I suspect (!)
>that it's floats are too. DOS floats are 16bit
^^^^^^^^^^^^^^^^^^^^^
no they are not!
'DOS-floats' don't exist, but
floats in BC are 4 , doubles are 8 or 10 bytes long. The exact format can
be found in the manuals, but unfortunately i have no idea what the exact
format is of Gcc/linux floats so i can't help out there.
I myself abandoned the the idea of using any binary representation of
floats in portable code and reverted to using a plain ascii representation
throughout. Ok, it's a bit bulkier (but those files compress easily) but
using printf/scanf or whatever works everywhere and written out data has
the advantage of being readable by me ( a mere human ) and nice programs
like 'gawk' etc.
Michel.
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Linux - my first impressions
Reply-To: pe1chl@rabo.nl
Date: Sat, 3 Sep 1994 22:04:31 GMT
In <CvK7qx.83I@cs.vu.nl> kjb@cs.vu.nl (Kees J. Bot) writes:
>rob@pe1chl.ampr.org (Rob Janssen) writes:
>>In <CvI5oG.1n0@cs.vu.nl> kjb@cs.vu.nl (Kees J. Bot) writes:
>>>Under SunOS the installboot(8) program installs the bootstrap and the
>>>addresses to /boot into the boot block. This only needs to be done
>>>once, because /boot never changes.
>>>The LILO method is rather crude.
>>I don't think so...
>>- LILO does not require the boot image to be on contiguous sectors
>No requirement of any other loader I know.
Have a look at SYS V systems... They use a separate filesystem for
the bootimages where files always use contiguous blocks.
>>- LILO can boot many different kernels and also other operating systems
>Many different kernels *if* all of them have been mapped. They must be
>carefully mapped whenever a new kernel is installed. That's what I mean
>with crude.
No, this is done only once when configuring LILO. From then on, all
kernels will be mapped simply by running the installer.
>Booting other operating systems is trivial. It is not something that
>makes LILO stand out.
Can your SUN booter do it?
>>I think it is a good program, and running its installer after building
>>the kernel is not a problem at all. It is even done in the same
>>"make zlilo" command.
>Inflexible.
>I like to hack code on one system, copy the resulting kernel image to
>another system with a simple 'rcp' command, and test the new kernel on
>this other system. Both systems are running Minix-386vm, with a
>bootstrap system written by myself that understands Minix filesystems.
That will really shine on an ext2 partition!
No, I still think the LILO method is a good idea.
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: IDE Performance enhancement
Reply-To: pe1chl@rabo.nl
Date: Sat, 3 Sep 1994 22:14:41 GMT
In <34a1ld$d14@chaos.dac.neu.edu> wdoyle@hilbert.coe.northeastern.edu (Patrick Doyle) writes:
>Note, I tend to recompile the kernel while running in an X window, so
>there is certainly some amount of swapping being performed (onto /dev/hdb).
>One thing I have noticed is that the load average when compiling is
>around 1.5 to 3.0. Does this imply that my compiles are CPU-bound, so
>regardless of what I do to improve the I/O, it's not going to make
>much of a difference?
On my 486/33 with SCSI disk on a 1542B, compilations are completely
CPU bound. However, I normally get a load average of 1 on kernel
compilations.
Note that the load average in Linux is "wrong" when compared to traditional
UNIX systems. Normally it counts the processes that are ready to run,
but Linux also includes the processes that are "swapping" or are in
an "uninterruptible sleep". This was introduced at some time to make
the "load average" reflect the "feel of system load", but I don't think
it is a good thing.
About IDE multiple-sector: the rate of a "dd" off the disk doubles when
setting 8-sector transfer on the Quantum disk in my machine at work.
I did not time the difference in compilation speed, but again it will
probably not make so much difference.
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: zureal@infinet.com (Jeffrey Oxenreider)
Crossposted-To: comp.os.linux.misc
Subject: Re: PGP Signature (Was: Suggest:SCSI Tape File System)
Date: 2 Sep 1994 11:55:30 GMT
Darin Johnson (djohnson@arnold.ucsd.edu) wrote:
: That also begs the question of whether or not your message was
: important enough to even care if you really wrote it or not.
That's a matter of personal opinion. Take for example the recient fiasco
with Steve Winters and the post about 'War on Satans BBS's', which was a
long tirade about how pagan bbs's need to be terrorized and shut down.
It was signed Steve Winters (and Steve is a well known 'hardcore'
christian) and it was quite the rant and very believeable that Steve
could have written it. It was also a PGP signed message. This ADDED to
the believability of it. However it was later discovered that Steve
never had a PGP key, and never wrote the message. If (before this
incident) Steve had made a public key, some people could have checked the
validity of this *highly* volitile message. Mr. Winters now is (or is in
the process of) making a public PGP key so this kind of thing can't
happen again with his name.
--
*----===========================================================------*
* zureal@infinet.com | 74431.3011@compuserve.com *
* sysop@f560.n226.z1.fidonet.org | jeffoxen@freenet.columbus.oh.us *
* BBS # (614) 235-5942 *
* Fnord All hail Eris! Fnord *
* finger zureal@infinet.com or FREQ PGPKEY from 1:226/560 for PGP key *
*---=============================================================-----*
------------------------------
** 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-Development-Request@NEWS-DIGESTS.MIT.EDU
You can send mail to the entire list (and comp.os.linux.development) via:
Internet: Linux-Development@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-Development Digest
******************************