Subject: Linux-Development Digest #126
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Mon, 5 Sep 94 23:13:08 EDT

Linux-Development Digest #126, Volume #2          Mon, 5 Sep 94 23:13:08 EDT

Contents:
  Re: IDE Performance enhancement (Pete Deuel)
  SVGA with dosemu 53-17 and S3? (Marc Fraioli)
  Re: SVGA with dosemu 53-17 and S3? (Mihail S. Iotov)
  Re: Future of linux -- the sequel (Rob Janssen)
  Re: SCSI-Scanner-Support? (Joel M. Hoffman)
  DOSEMU 0.53pl17 and keyboard (Andrew Ryan)
  Re: WARNING about shadow-mk package
  Re: WARNING about shadow-mk package
  Re: Aliasing `rm' (Darin Johnson)
  Re: WARNING about shadow-mk package (John S. Seng)
  Load Balancing (Tracy R. Reed)
  Re: BOOTPD / newer kernels, BUG? (Jon Peatfield)
  News Spool File System - new filesystem type?? (Michael Dillon)
  Re: HORRIBLE SWAP THRASHING BUG (memory prob?) (Alan Young)
  [STATUS] Linus Floppy Driver Development (David C. Niemi)
  Re: Unicode & Linux's future (was Re: Acid) (Richard L. Goerwitz)

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

From: [email-masked] (Pete Deuel)
Subject: Re: IDE Performance enhancement
Date: 5 Sep 1994 20:14:30 GMT

Harry C Pulley ([email-masked]) wrote:
: Pete Deuel ([email-masked]) wrote:

: : I have to think that, if there is to be any noticible speed difference, you 
: : really must stick to disk-intensive applications.  I would guess kernel 
: : compilation is not THE thing to test this with.

: : empty filesystem and pipe yes into a file (yes > /mnt/tempfile)  until the fs 
: : is full--the amount of time it takes to fill up the fs should change if there 

: I use iozone.  I got a 50% speed up when I went from 1.0 to 1.1.45 with 
: multcount 16, read-ahead 16, etc.  Going to VLB with my IDE drives yielded
: another 35% improvement (on top of the 50% improvement from 1.1.45).

: I think that iozone does a pretty good job.  Creating a new filesystem will
: give you completely reproducable results, this is true.  But echoing yes until
: it fills up may be overkill.

: Even iozone isn't really great for anything but testing big silly sequential
: writes and reads.  Timing the startup time of X is pretty good ;-)

Ah, the virtues of iozone.  Never heard of it.  Where would I find it
(if I were inclined to do my own testing, which I'm not!)???

This program, or at least info. about it should be put with the software
(I guess in this case the kernel, although I didn't see anything in
1.1.45 make config to allow this IDE enhancement, anyhow.  'Course, I
wasn't looking either...)

iozone, while not useful for anthing else, would be perfect for this kind
of empirical testing, rather than kernel compilation.

Pete

PS  Why the heck do ppl put up with 3 hour compile time?  I have a cheesy 386
and can compile a moderatly rich kernel in a bit over an hour...?
--
======================================================
     "Actually, I'm just a lab mouse on stilts..."

        E-mail: [email-masked]
======================================================

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

From: [email-masked] (Marc Fraioli)
Subject: SVGA with dosemu 53-17 and S3?
Date: 5 Sep 1994 21:17:44 GMT
Reply-To: [email-masked]

Hi-

  I've just been playing around with DOSEMU 0.53 pl17, and like it a lot.
I have a question, however-- the docs seem to imply that I should be able
to run in SVGA mode with an S3-based video card.  Mine is an Orchid Fahrenheit
1280+ w/ an S3 801 and 1 MB RAM.  I can get VGA (320x200x256) to display
fine under DOSEMU, but anything higher results in flickering garbage on
the screen.  I have been testing it out with GameBytes, the on-line games
magazine.  It requires a VESA driver for SVGA, but Orchid claims that this
card does VESA natively, and it works fine under plain MS-DOS 5.0.  I have
tried both of the following in my /etc/dosemu.conf, with the same results:

video { vga  console  graphics }

and

#   S3-based SVGA video card with 1 megabyte on board:
video { vga  console  graphics  chipset s3  memsize 1024 }

I have run as root too, not sure if that matters.  

        Thanks for any input.

---
Marc Fraioli          | "They couldn't hit an elephant at this dist- " 
[email-masked]         |    - Last words of Union General John Sedgwick,
                      |    Battle of Spotsylvania Court House, U.S. Civil War

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

From: [email-masked] (Mihail S. Iotov)
Subject: Re: SVGA with dosemu 53-17 and S3?
Date: 5 Sep 1994 22:26:46 GMT

[email-masked] (Marc Fraioli) writes:

>Hi-

>  I've just been playing around with DOSEMU 0.53 pl17, and like it a lot.
>I have a question, however-- the docs seem to imply that I should be able
>to run in SVGA mode with an S3-based video card.  Mine is an Orchid Fahrenheit
>1280+ w/ an S3 801 and 1 MB RAM.  I can get VGA (320x200x256) to display

I also have an S3 801 based card (STB X24) and I could actually get 
640x480x16 (VGA) but nothing above that. I also get error messages in the
debug files when video debug enabled and I have e-mailed these to the code
author.

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

From: [email-masked] (Rob Janssen)
Subject: Re: Future of linux -- the sequel
Reply-To: [email-masked]
Date: Mon, 5 Sep 1994 16:49:56 GMT

In <[email-masked]> [email-masked] (Erik Fortune) writes:

>In article <[email-masked]>, [email-masked] writes:
>> BTW...  there was a nice inside-story from within SGI posted on a
>> Linux group some time ago.  It's unfortunate that I did not keep a copy...
>> It expressed quite a different opinion on the Indy...

>Yes, it's a pity you didn't keep a copy.  The memo in question was complaining 
>about the performance of the now obsolete IRIX 5.1 *not* the performance of
>the Indy itself.  Quite some time ago, we released IRIX 5.2 which addresses 
>nearly all of the performance complaints of the original (confidential!) memo.

Someone mailed me a copy.  It does not say anywhere it is confidential,
and it was posted to the Linux mailing list, KERNEL channel.  So I guess
there are a lot of people outside of SGI who keep this as a curiosity :-)

I think the memo should not be read as a complaint against a certain
version, but more in a general sense.  That is probably also why it was
posted in a Linux mailing list (as a warning what might happen when you
don't watch for bloat in the system).

The Indy is mentioned several times, like in

        "Indy: an Indigo without the 'go'"

It also repeatedly states that an Indy is unusable with 16M RAM.  As the
proposed configuration for the Indy earlier in this thread included 32M RAM,
I suppose this is still more or less the case...

My Linux system has 16M RAM, and I have never had the feeling that I should
expand the RAM to get reasonable performance.  Of course, more RAM is
always nice, but Linux runs just fine with 16M.  I use it only with X,
and I normally have about 6 xterms open all the time, and over 60 processes
in the process table (most of them waiting, of course).

However, this is not what the thread is all about.  The point is that the
original statement that an Indy makes a Pentium feel like a 4.77MHz XT
was a gross exaggeration, and that still stands.  The memo only shows that
SGI has had performance problems as well.  It would be a real feat when
the difference between 5.1 and 5.2 was between something that is too
slow to work with and something that is 50 times as fast as a Pentium,
but I *really doubt* this is the case.

Rob

Disclaimer: I have no Indy and I have seen them only in a demo setup.
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Joel M. Hoffman)
Subject: Re: SCSI-Scanner-Support?
Date: Mon, 5 Sep 1994 22:02:31 GMT

In article <[email-masked]> [email-masked] (Uwe Carl) writes:
>[re scanners]
>Are there any Driver available?. I looked around and discovered
>nothing. Is there Documentation available ( TWAIN ???)

First, a warning:  TWAIN is misleading.  Even if TWAIN is implemented
under Linux, one would still need individual drivers for each scanner.
TWAIN is an interface between a hardware-specific driver and general
software.  What TRAIN does define is an application interface, such
that an application can use any scanner, provided the low-level driver
exists.  

Now:  I know that some drivers exist for hand-held scanners.  Some
companies are better about releasing programming information than
others, and those tend to be implemented first.  But even the
(proprietary) scanman interface has been reverse engineered, and
drivers exist for most of the Logitech hand-held scanners.  

Check the usual sites to see what's available.

-Joel
([email-masked])
-- 
=============================================================================
|_|~~ Germany, Europe. 1943.    "The diameter of the bomb was 30 centimeters,
__|~| 16 Million DEAD.           and the diameter of its destruction, about 7
                                meters, and in it four killed and 11 wounded. 
 cnc  Bosnia, Europe. 1993.     And around these, in a larger circle of  pain
 cnc  HOW MANY MORE?          and time,  are scattered two  hospitals and one
                          cemetery.   But the young woman who was  buried  in
                    the place from where she came, at a distance of more than
             than 100 kilometers, enlarges the circle considerably.   And the 
      lonely man who is mourning her death in a distant  country incorporates
into the circle the whole world.  And I won't speak of the cry of the orphans
that reaches God's chair and from there makes the circle endless and godless."
=============================================================================
     Tell Clinton to stop the genocide:  [email-masked]

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

From: [email-masked] (Andrew Ryan)
Subject: DOSEMU 0.53pl17 and keyboard
Date: 5 Sep 1994 23:06:11 GMT

        I can't get DOSEMU 0.53pl17 to work right.  After dos 6.2 boots and
I get the date prompt my keyboard is all screwed up.  I have linux 1.1.49. 
Does anyone else have this problem?  Is there a fix?

                        Andy

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

From: [email-masked] ()
Subject: Re: WARNING about shadow-mk package
Date: 6 Sep 1994 00:14:40 GMT

#Patrick Reijnen ([email-masked]) wrote:
#: In <[email-masked]> [email-masked] (Bauke Jan Douma) writes:

#: >If you are about to update you shadow programs with the shadow-mk
#: >package by Mohan Kokal, think again.

: I also have the shadow-mk package and have seen the _login and login.secure files in my directories. What's wrong with them???????, exept for the fact that no sources are available of login.secure. Ask the author for the sources and check them for any pittfalls. Don't we trust each other anymore?????

um...no?  especially when given several good indications that doing so
would be a mistake, as rational people, why should we trust him?

: Patrick Reijnen

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

From: [email-masked] ()
Subject: Re: WARNING about shadow-mk package
Date: 6 Sep 1994 00:16:18 GMT

Larry Doolittle ([email-masked]) wrote:
: Bauke Jan Douma ([email-masked]) wrote:

: : If you are about to update you shadow programs with the shadow-mk
: : package by Mohan Kokal, think again.

: : Here's the snippet from the Makefile in that package where login is
: : installed:

: :     install -m4755 login $(LOGINDIR)/_login
: :     install -m4711 login.secure $(LOGINDIR)/login

: : -rws--x--x   1 root     staff        1124 Jul 13 10:36 login.secure <- ?

: If Mohan is the cracker you suggest, what he would hate the most
: would be publishing the login.secure program.

: If Mohan is innocent, the fastest way to clear his neame would be
: to publish the login.secure program.

: Either way, I suggest you uuencode login.secure (if it's not an
: ASCII shell script :-) and post it to these newsgroups.  A lot
: of people here are competent with unassemblers.

:      - Larry Doolittle    [email-masked]

Grand suggestion, Mr. Doolittle!  I second the motion.  Lets get a look
at this code & find out just exactly what is going on here, if anything.

: : [email-masked]  (Bauke Jan Douma)

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

From: [email-masked] (Darin Johnson)
Subject: Re: Aliasing `rm'
Date: 06 Sep 1994 01:01:23 GMT

> >>    1. Alias rm. What's bad is that when I used it under tcsh I spent my
> >>    time typing someting like '\rm ...' just to not use the alias 

> >Why didn't you just pass the `-f' switch to rm (rm -f whatever)?  ;-)

Actually, I do the same thing (putting in \rm that is).  What
happens is that the alias expands to "rm -i -f ...", and on
*some* systems, the -i takes precedence.  It doesn't happen as
much anymore, but out of habit I still put it in now and then.
--
Darin Johnson
[email-masked]
    Where am I?  In the village...  What do you want?  Information...

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

From: [email-masked] (John S. Seng)
Subject: Re: WARNING about shadow-mk package
Date: Tue, 6 Sep 1994 00:57:46 GMT

Well you guys can take a look at it here:

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

From: [email-masked] (Tracy R. Reed)
Subject: Load Balancing
Date: 6 Sep 1994 01:57:24 GMT

I noticed that when I compiled 1.1.49, it asked if I wanted load 
balancing. Could someone explain to me how this works and how well it 
works? It sounds like a good way to get the equivelant if parallel 
processing on common PC hardware. How does it divide up the tasks for 
each machine to do? What is the max number of machines that load can be 
distributed over? Also, is the load distributed by user, process, 
subroutine, etc.  Although a good ethernet is pretty fast, it is not 
nearly as fast as the system bus, so is it worth it?

--

=============================================================================
Mr. Tracy Reed         |Every artist is a cannibal.|Two Betazoids walk into
San Diego State Univ.  |Every poet is a thief.     |  a bar.
Aerospace Engineering  |All kill their inspiration |
[email-masked] |And sing about their grief.|One says,
[email-masked]      |-U2 IRC-Maelcum /me smiles |  "I'll have the same."
=============================================================================

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

From: [email-masked] (Jon Peatfield)
Subject: Re: BOOTPD / newer kernels, BUG?
Date: 06 Sep 1994 02:12:03 GMT

Yes.  FTP the latest version from ftp.amtp.cam.ac.uk:/pub/linux/bootpc/
Currently the latest is bootpc.v031.tgz.

I'll get round to putting it on sunsite once I work out how to
generate an LSM entry.

The current version works on 1.1.x (x > 14) as well as earlier kernels
but you need to recompile as the structures used changed.

If you can't get it to work please mail me with details and I'll try
to fix it (assuming I get any time.)

-- Jon

--
Jon Peatfield, Computer Officer, the DAMTP, University of Cambridge
Telephone: (+44 223) 3-37852     Mail: [email-masked]

"IBM's OS/2 sets a memory challenge to Microsoft" - Computer Weekly

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

From: [email-masked] (Michael Dillon)
Crossposted-To: news.software.b
Subject: News Spool File System - new filesystem type??
Date: Mon, 05 Sep 1994 00:03:05 +0000

> This is actually an argument for compressed filesystems, particularly
> when data is write-rarely, read mostly.  There are compression
> methods that compress relatively slowly, but decompress so fast that
> it's much faster to read one block and decompress it than to read 2 or 3
> non-compressed blocks.

Hmmm.... I can see it now, the NSFS (News Spool File System).

1. This is a compressed file system using LZ technology
2. Since LZ compression replaces repeated strings with a dictionary
   reference and since news postings tend to have a lot of the
   same words over and over, the NSFS uses a two part dictionary.
   The first part of the dictionary is applied to all files in the
   NSFS and contains words that are likely to occur in many news postings.
   This includes headers and common English words and phrases. The
   second part is a file specific dictionary as is normally found in
   LZ compression systems.
3. A utility is included to replace the common dictionary with
   your own specifications. This utility will only run on an
   unmounted file system.
4. An analysis program will do statistical analyses of the contents of
   your NSFS to determine what repetaing strings appear most frequently.
   You can use this analysis to provide a different common dictionary.

I wonder if message-id's could be worked in there somehow?

I am cross-posting this to comp.os.linux.development since that
is an evolving experimental O/S that has the ability to mount
quite a variety of filesystem types. 

cruisin' down the information highway, lookin' for a blast
breakin' all the speed limits as I come zoomin' past!
--
Michael Dillon                 Internet: [email-masked]
C-4 Powerhouse                  Fidonet: 1:353/350
RR #2 Armstrong, BC  V0E 1B0      Voice: +1-604-546-8022
Canada                              BBS: +1-604-546-2705

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

From: [email-masked] (Alan Young)
Crossposted-To: comp.os.linux.admin
Subject: Re: HORRIBLE SWAP THRASHING BUG (memory prob?)
Date: 6 Sep 1994 02:11:03 GMT

In article <[email-masked]>, [email-masked] (Russell Leighton) says:
>
>        HORRIBLE SWAP THRASHING BUG (please try this)
>
 [stuff deleted]

>Configuration:
>        Linux 1.1.48
>        P90 PCI
>        16M ram
>        >80Mbytes swap (1 18M partition, 4 16M files)

 [more stuff deleted]

Something weird is going on here.  I jumped from 1.0.9 to 1.1.45 wtihout
any problems.  I applied the APM and QLogic SCSI patches to try out.
(I don't think these are the problem, but read on...) I also applied the
.46->.49 patches.  I recompiled the kernel, installed it and rebooted.
I went to recompile the kernel again and noticed after about an hour it
was only on irq.c.  It was massively swapping.  I started up top and
watched it for a bit and noticed something really nasty.  Top said
that I had 1500K of memory available.  I actually have 4 meg.
I stopped the build of kernel.  I deinstalled the .49 kernel
and re-installed the .45 kernel (with the APM and QLogic patches).
After rebooting, the kernel (and top) report that I have 3112K free to
use.  So there appears to be something wrong between .46 and .49
that has changed the way the kernel is recognizing memory.
I'm going to apply each patch level individually and see if I can
spot at which level it breaks.

Hope this helps,
Alan

[email-masked]

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

From: [email-masked] (David C. Niemi)
Subject: [STATUS] Linus Floppy Driver Development
Date: 6 Sep 1994 02:30:44 GMT
Reply-To: [email-masked]

Background
==========

Alain Knaff (Grenoble, France) and I have been working on and off on
adding functionality to and fixing bugs in the Linux floppy driver for
much of the last year.  Sam Chessman (who, like me, lives in Reston,
Virginia, USA) has helped as well at times.  Alain used the "floppy
patches" as a starting point, fixed many bugs, folded in some functions
by Sam and myself, and added the capability to format, read, and write
the higher capacity formats used by the DOS "2m" program.  The resulting
kernel patches (mostly to drivers/block/floppy.c) were beta tested for a
while, and were included by Linus in 1.1.41 (unfortunately on the same
day Alain went on a month-long vacation, from which he should be
returning any day now).  The 1.1.41 changes represent very close to a
total rewrite of the floppy driver, mostly by Alain.

Alain also wrote a series of floppy utilities, the most notable being
"superformat", which are in the "util" subdirectory of the last Beta-
test package.  This package also includes an mtools enhanced by Alain
and myself in a variety of ways, and is found on sunsite in
"/pub/Linux/kernel/patches/diskdrives/fdpatches-3.1-for-1.1.38.src.tar.gz".
The only thing obsolete in this package is the patch for the 1.1.38 kernel;
the rest is all current (for now).

Known Floppy Driver Problems
============================
(roughly in order of severity)

1)      Background floppy drive probe can hang the system and/or cause
        file system corruption

        Typical hardware: PCI, Adaptec 1542CF, 1 floppy drive (which
        is not attached to the Adaptec 1542CF).

        1.1.49 has a workaround, which changes the default for N_DRIVE
        to 2 in "floppy.c".  This seems to fix the symptoms of this
        problem, but does not fix the problem itself, which is not yet
        pinned down.

        The easiest way to fix this may be to stop trying to probe
        floppy drives in the background, and instead sense the floppy
        drives when an open() is done on the device (this was suggested
        by Linus et. al.).  A real fix is likely before 1.2.0 comes out.
        
2)      mke2fs does not work correctly (if at all) on certain floppy
        formats.  18, 20, 21, and 22-sector HD 3.5" formats do not work.
        This problem was introduced with 1.1.41.  To reproduce:

<insert a formatted 3.5" 1.44MB floppy>
dd if=/dev/zero count=20 of=/dev/fd0H1440 # Clear out existing file sys.
mke2fs /dev/fd0H1440
<promptly remove the floppy as soon as the drive light goes out>
<reinsert floppy>
e2fsck -f /dev/fd0H1440

        Note that this occurs even if syncs are used, or if e2fsck is
        performed right away before removing the floppy.  However, if
        "e2fsck -f" is performed immediately after the mke2fs, the
        problem does not occur.

        Interestingly, this problem does not occur on the DD and ED
        formats that I tried, nor on 23-sector or 24-sector HD formats.

        This problem was first reported on 82077s and attributed to the
        FIFO, but I am skeptical that it is limited to 82077s as it still
        occurs if I force the driver to regard the FDC as an 8272a.

        I expect this problem to be fixed before 1.2.0.

3)      Autosensing has problems

        Autosensing of formats of the same data transfer rate does
        not really work (except, of course, for the first format which
        is listed at that density).  In particular, 14, 20, 21, 22, 23,
        and 48-sector formats are not autosensed correctly while 13, 18,
        24, and 36-sector formats are (for 3.5" disks).

        My proposal is to divide autosensing into multiple stages:

        a) Perform a READ ID on the first sector on the disk.  Try
        this at each of the densities supported by this drive until
        it succeeds (i.e. 1000, 500, 300, and 250 Kbps, depending on
        the drive).  If it works, check on the sector size obtained.

        b) [Controversial] check on the contents of this sector to see
        what sort of file system, if any, it contains.  The opposite
        approach is to leave this to the user-mode program which
        accessed the floppy drive (e.g. mtools).

        c) [Controversial] check on how many sectors are on the disk.
        Due to 2m formats, it is necessary sometimes to look at both
        tracks 0 and 1 to determine this for certain; track 2 may need
        to be inspected to tell 40-track from 80-track formats.  Some
        file systems have geometry information in the first sector,
        making step c) unnecessary.

        This problem is not likely to be solved in kernel rev 1.2.0.

4)      Ext2 does not seem to work on 20-sector HD 3.5" formats

        mke2fs does not seem to work at all on 20-sector HD 3.5"
        disks.  This is beyond problem 2) above, where ext2 file
        systems are not always written to disk.

        To reproduce:
<insert 20-sector diskette>
mke2fs /dev/fd0H1600
e2fsck -f /dev/fd0H1600
        Block bitmap 0 for group 0 not in group.

        This is a problem may be solved when problems 2) and/or 3) are
        fixed, so it is probably not worth pursuing unless it persists.

5)      Minor device naming problems (density letter)

        The minor device naming conventions are currently inconsistent
        between the new MAKEFLOPPIES script (which bases the density
        letter on the drive type) and MAKEDEV (which bases the density
        letter on the media format).  For example, a 1.44MB disk in an
        ED drive would be called /dev/fd0E1440 by MAKEFLOPPIES, and
        /dev/fd0H1440 by MAKEDEV.

        This problem is especially sticky with 5.25" 360 KB disks, where
        there are three very different drive types to consider (40-track
        300rpm "PC"; 80-track 300rpm "Quad Density"; and 80- track 360-
        rpm "AT".  These point toward using the drive type in determin-
        ing the density letter (d, q, and h respectively).  Thus fd0d360,
        fd0q360, and fd0h360 would all refer to the same media format in
        different drive types.  There is no BIOS code for the "Quad
        Density" drives, so simply relying on the BIOS code for the
        drive when creating the devices is not sufficient in all cases.

        OTOH, ED 3.5" drives support all 4 different densities, and many
        scripts assume that fd0H1440 is the name for a 1.44MB 3.5" disk.
        Having to know whether you have a HD or ED disk drive is
        confusing to both users and scripts which want to access a known
        media format.  The problem is even worse with DD disks if the
        density letter is based on the drive type.  For example, the
        same 720KB diskette would have to be referred to as /dev/fd0D720,
        /dev/fd0H720, or /dev/fd0E720 depending on the drive type.

        Just to add to the confusion, the current MAKEDEV also makes
        device fd0H2880, which makes no sense in either scheme.

These are the known bugs/problems.  If you know of any other bugs or
design limitations, please let me know at "[email-masked]".

Thanks to those who people who helped to track down these problems!
==================================================================
David C. Niemi (SLMA, Herndon, Virginia, USA)    [email-masked]
Know the difference between the color of the wine and the color of
the glass.  (Jalaluddin Rumi)
==================================================================

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

From: [email-masked] (Richard L. Goerwitz)
Subject: Re: Unicode & Linux's future (was Re: Acid)
Reply-To: [email-masked]
Date: Tue, 6 Sep 1994 02:53:16 GMT

[email-masked] (Joachim Schrod) writes:
>In article <[email-masked]>, [email-masked] (Richard L. Goerwitz) writes:
>> 
>> Am I babbling nonsense, or am I making sense?
>
>I think you underestimate the effort to make a truly multilingual
>environment.
>
>Take Khmer as an example, where syllables form clusters around a
>`determining glyph'.

Perhaps it would be reasonable to aim for support of all unidirec-
tional scripts.

>How about Berber or other similar scripts that have no predefined
>direction?

That's easy:  You just define a direction.

>Unicode might be a nice thing, but it does not care for many scripts
>of this world; so it will not be THE solution, either. ('Though it
>would be a Good Thing to have support for it more widespread.)

No, I understand that many have serious philosophical differences over
whether diacritics should be included as separate characters or not.
This dispute has apparently been resolved inclusively via the ISO
10646 - Unicode merger (the details of which I am not familiar with).

The real point of this thread is simply to get engineers, who are very
good at what they do, thinking about things like multi-byte and wide
characters, and to let them know that there are, for example, estab-
lished typographical conventions for mixing left-right and right-left
scripts (conventions that few if any X text widgets understand).

-- 

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