Subject: Linux-Development Digest #141
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Fri, 9 Sep 94 01:13:33 EDT

Linux-Development Digest #141, Volume #2          Fri, 9 Sep 94 01:13:33 EDT

Contents:
  Re: Survey: who wants f77,cc,c++,hpf for linux? (Richard Maine)
  Re: Alpha Linux (Richard Coleman)
  Re: XFconfig86 problems - HELP! (Mike Treadwell)
  Re: Unicode & Linux's future (was Re: Acid) (Andries Brouwer)
  Re: News Spool File System - new filesystem type?? (Alan Barrow)
  Hangs with 1.1.49 ? (Ray Bellis)
  Re: News Spool File System - new filesystem type?? (Pete Deuel)
  Re: Survey: who wants f77,cc,c++,hpf for linux? (Carl Schott)
  ATI Mach64... Does it work...? (Pete Walker)
  Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library) (Gary R. Hook)
  Re: SyQuest removable SCSI driver? (Rob Janssen)
  Re: [Q] on Linux/MIPS port (Andreas Busse)

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

Crossposted-To: comp.lang.fortran
From: [email-masked] (Richard Maine)
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
Date: Thu, 8 Sep 1994 15:13:02 GMT

On 7 Sep 1994 22:24:25 -0700, [email-masked] (Larry Meadows) said:

Larry> Given the interest in Linux, I thought I'd post a short survey:

Larry> 1. Are people interested in a commercial compiler suite for Linux on
Larry>    Intel Architecture platforms? The suite would include...

I have no C/C++ needs that gcc and friends don't satisfy.  I can't imagine
a commercial product successfully competing there; anyway I wouldn't pay
more than pocket change for one.

For f77, f2c is marginal, and g77 isn't yet out of beta.  However, I
don't do new code in f77 any more.  I might pay a little for an f77
compiler on Linux, but not enough to make it worth your while.  Say <$100.

Hpf is built on f90.  I'm not personally interested in the HPF extensions,
but if your HPF would include a *full* f90 for Linux, then I'd definitely be
interested (say to the tune of $500-$1000).  Subsets need not apply.

Larry> 2. How much would people pay for such a product [ loaded question ]?

See above.

Larry> 3. What distribution media would be required?

CDROM preferred.  Floppy ok.  Various tape media I could deal with
one way or another, but would be last resorts.

Larry> 4. Is there interest in accompanying GUI/non-GUI debuggers and
Larry>    performance analysis tools?

Minor.

--
This is all in reference to my personal interests, not NASA's.
I can't speak for NASA, and I did, I'm sure the answers would be
different.  I don't run Linux out at work anyway, but I do use it at
home.

--
--
Richard Maine
[email-masked]

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

From: [email-masked] (Richard Coleman)
Subject: Re: Alpha Linux
Date: 08 Sep 1994 15:17:22 GMT

>   : Why drop one? 
>   : 16 bits = short int
>   : 32 bits = int
>   : 64 bits = long
>
>    128 bits = long long   :)

I've always thought that C should have some way
of letting you decided how many bytes to use
for your computation.  It could be as simple as
having the types

int8   ( = char )
int16  ( = short )
int24
int32  ( = int )
...

up to some reasonable value like
int128.  Of course, other syntatic sugar
would probably be necessary, but the idea
*appears* simple enough.

As we move to 64bit chips and beyond, it seems
like this will become very desirable.

Richard Coleman
[email-masked]

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

From: [email-masked] (Mike Treadwell)
Crossposted-To: comp.windows.x.i386unix,comp.os.linux.help
Subject: Re: XFconfig86 problems - HELP!
Date: 8 Sep 1994 15:08:19 GMT

Carlos Dominguez ([email-masked]) wrote:

: 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. 

You are not alone, Carlos. I've been having troubles with an S3 card. At
one point, I had the same error you do. Xfconfig86 was trying to write a
temp file to the CD-ROM. I had to change the links to the cd so it wrote
into a "real" directory. That fixed that problem.

Now I had a nice blue Xwindow and no mouse. :(

Mike

[email-masked]

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

From: [email-masked] (Andries Brouwer)
Subject: Re: Unicode & Linux's future (was Re: Acid)
Date: Thu, 8 Sep 1994 15:15:25 GMT

[email-masked] (Richard L. Goerwitz) writes:

>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.  How should this be handled?

You can choose: either consider initial, medial and final qof to be
three distinct letters (in which case the kernel, properly instructed
using loadkeys and setfont, will display them correctly for you),
or consider them to be one letter, and have a process between the kernel
and your application, that handles input and output.
Similarly, one has these possibilities in Greek (for final and non-final
sigma) and in English (for capitalization and fi,fl ligatures).

The example of English shows that one may leave the choice between
a and A to the user. It is easy to make a program that will be right
about capitalization most of the time, but impossible to make a program
that is always correct. 
It also shows that there are details that only matter in high quality
printing.

It is the same with Arabic. No doubt it will be easiest if you indicate
yourself which form of the letter you want, but teaching emacs to do
the choosing for you should not be too difficult either.
That special glyphs exists for certain combinations of letters only
matters in high quality printing.
I think I once showed you in private mail how easy it is to produce
Arabic with TeX.

Anyway, none of this concerns the kernel, with the possible exception
of the directionality of the text.

>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)?

There is only one natural order, and that is the time order.
What is said first is stored first.
The order on a storage medium has nothing to do with the appearance
when printed.

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

Unicode includes symbols for direction change. That suffices for most
purposes. For specialized cases you need special programs.

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

Plan 9 made a different choice, but I found that very few applications
need to know how many bytes there are in a symbol. That is, recoding
these programs to make them use "runes" is usually unnecessary.
(However, columns are often messed up, and strlen() has to be replaced.)
Unicode in UTF-8 encoding yields symbols encoded with a variable number
of bytes, but most programs only copy text strings, or parse them into
identifiers etc., and since ASCII is embedded as a collection of symbols
each represented by a single byte, this does not pose any problems.

So, internal representation is no problem. Input is easy enough with
some version of loadkeys when the alphabet is small, and requires a
separate daemon when the alphabet is large, or when your input is not
easily converted to the internal representation. 

Output is difficult. The precise rules are complicated, and fonts take
a lot of space. The console driver can only handle the very simplest
cases.

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

From: [email-masked] (Alan Barrow)
Crossposted-To: news.software.b
Subject: Re: News Spool File System - new filesystem type??
Date: 9 Sep 1994 00:16:25 GMT

Good comments about moving away from the "one file=one article" scheme of
C-News/INN deleted.....

Just an observation:

As an admin that ran both a "notes" site and 2 B-news/C-news/INN sites
for the last 4-5 years, I sure like the convenience of having the 
old clunky flat text files. 

Notes may not be a good example to use, but it had a database type
approach similar to our current history approach. (index file and a
single data file) for each group.

There were advantages (fewer inode problems, maybe it was faster, who
knows) but on a regular basis a "bad" (malformed, etc) article would trash 
a group database. There were no recovery tools, and you would usually 
lose the entire group. Heaven forbid a system failure.

The same is true of WinNet, a Windoze uucp based new/mail app. It is
actually a pretty usable reader, in fact. But it also uses a database, and 
a reboot/power failure, GP fault, whatever while processing articles 
will often trash the DB.

I think the modern news systems could avoid most of the the defects in
the notes and WinNet approach. (just a small matter of programing) :-)

But, I really like being able to do "brute force" emergency admin of my 
spool dir using OS cmds and other tools. (find, reap, even rm -rf soc/* on 
a bad day)

The convenience of the current approach make it worth enduring the performance
and space hits. A new design would have to be faster, compress 2-3X, and 
totally compatible with INN to get my interest. Even then I would think hard.
800 Mb of files under 1k is not pretty. NOV makes it endurable. But it
works, and I rarely have to "fix" the article base.
 
Someone else wrote:

>:The Right Way to implement this kind of filesystem would be a
>:user-space process, reading and writing the raw device -- essentially
>:just using /dev/hd<foo> as a database.  Putting it in the kernel gains
>:you nothing but more kernel bloat.

I do agree with Ian here. Make it general enough, like the real DB's do
on unix. You can write to a raw partition, or to a file, depending on
your preferences. Unix does not care. Individual OS's often have
restrictions that make one approach preferable. An example:

        HP-UX 8.0- Max raw partition 2Gb, Max individual file size was 
        2Gb less FS overhead. 
        
        HP-UX 9.0x- Max raw partition is still 2Gb, but with LVM
        (logical volumes) you could easily have a logical volume of 4Gb
        or more. (In or out of a filesystem) You can have a bigger file
        than you can have a raw partition. (due to lseek limitations)

With the general approach like "real DB's", you pick what is best for
your site. At least we do not (usually) have to worry about backup and
restore of article bases. This adds another layer. (Just another tool that 
would be needed)

Someone else wrote:

>I hate to disagree, but doing it through the kernel gains you portability.

I really disagree here. I have never seen an instance when moving a
function from user space to the kernel made it more portable. Usually
the opposite occurs. This is how we ended up with Streams, etc. (To
avoid driver writing) Stick with things you can implement with POSIX
type generic calls. (Good luck on your project, though :-> )

But do not let me persuade anyone from writing the next generation
system. (Or even an enhancement) If it were not for the Rich Salz's and
Henry Spencer's, I would still be stuck using (and repairing) Notes! :-)

Have fun!

 Alan Barrow  km4ba         | If a little knowledge.....
 Work: [email-masked]       |    is a dangerous thing.....
 Home: [email-masked]  |       then what is the Anti-Dote???

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

From: [email-masked] (Ray Bellis)
Subject: Hangs with 1.1.49 ?
Date: 08 Sep 1994 15:25:41 GMT

I'm having problems where my linux box hangs when doing any significant
network access, such as compiling or running X applications (I've got
/usr remote mounted using NFS).

When the system hangs there aren't any debug messages, the system
just stops dead.  This didn't used to happen when running 1.0.9.
Unfortunately I can't stay running 1.0.9 since the precompiled
version on the Slackware 2.0 distribution doesn't contain the
devices I need, and if I build 1.0.9 myself it hangs when trying
to detect my NE2000 ethernet card.

I've posted this to the development group because it seems to be
a problem with the new kernel.

Thanks,

Ray.
--
==============================================================================
R. P. Bellis                            E-Mail: <[email-masked]>
Computing Officer
MRC Centre in Brain and Behaviour
Dept. of Experimental Psychology
University of Oxford                    Whois:  (RB83)
South Parks Road                        Tel:    +44 865 271359
Oxford OX1 3UD                          Fax:    +44 865 310447
==============================================================================

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

From: [email-masked] (Pete Deuel)
Crossposted-To: news.software.b
Subject: Re: News Spool File System - new filesystem type??
Date: Thu, 8 Sep 1994 21:57:24

In article <[email-masked]> [email-masked] (Lennart Regebro) writes:
>From: [email-masked] (Lennart Regebro)
>Subject: Re: News Spool File System - new filesystem type??
>Date: 8 Sep 1994 15:00:04 -0000

>In <[email-masked]> [email-masked] (Rob Robertson) writes:

>>I don't think this would work, as so many words in usenet postings are
>>misspelled that looking them up in a dictionary, probably won't buy
>>you anything, cuz they won't be found!
>>              ^
>>               c whut i meen?

>The very common words 'Newsgroups:', 'Subject:', 'References:', 'alt.sex'
>and 'cuz' would still be common enough to be in a common directory.

Well, the easiest way to compile such a dictionary, I would think, is to do 
like Webster's does--steal the top 50,000 from the front page of the 
Times.  Of course, *we* keep stats on word frequency in all the groups for 
about...  a week?  Whatever news admins feel is a good amount of 
time...

But, not on *my* system!  :)
(Maybe someone with access to a 3-6 processor machine would volunteer?!!)

My .02...

Pete
===================================================
     "Actually, I'm a lab mouse on stilts..."

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

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

From: [email-masked] (Carl Schott)
Crossposted-To: comp.lang.fortran
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
Date: Thu, 8 Sep 1994 15:30:37 GMT

Larry Meadows ([email-masked]) wrote:
: Hello

: Given the interest in Linux, I thought I'd post a short survey:

: 1. Are people interested in a commercial compiler suite for Linux on
:    Intel Architecture platforms? The suite would include true compilers
:    for extended Fortran 77, ANSI C, Draft-ANSI C++ with extensions, and
:    High Performance Fortran. C, f77, and C++ could support shared memory
:    parallelism (thread-based) if system support is available in Linux.
:    HPF would support socket-based communications on networked systems,
:    and could support custom interconnects.

gcc/g++/f2c are sufficient for my C/C++/Fortran-77 needs, but I WOULD be
interested in a Fortran-90 compiler.  AFAIK, there's no free version of 
such a compiler under development.

: 2. How much would people pay for such a product [ loaded question ]?

~$300

: 3. What distribution media would be required?

Floppy/net/QIC-80

: 4. Is there interest in accompanying GUI/non-GUI debuggers and
:    performance analysis tools?

Not as much as in the compiler itself, but it might be a selling point
if included (depending on features/performance).

Carl Schott

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

Crossposted-To: comp.os.linux.help,comp.windows.x.i386unix
From: [email-masked] (Pete Walker)
Subject: ATI Mach64... Does it work...?
Date: Thu, 8 Sep 1994 15:22:43 GMT

Hi Xfreers,

Notice that Mach64 is listed under 'others' group in Hardware-HOWTO and
just wanted to know if anyone has the Mach64 card working under
Xfree and if so what was the proceedure used to get it going.
I am purchasing one of these cards (VLB) and wants to know if it is a 
good decision or safe ivest investment. Thanks for your replys.

-- 
Best Regards

Peter
==================================================================
Peter Walker            
[email-masked]
_________________________________________________________________       

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

From: [email-masked] (Gary R. Hook)
Subject: Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library)
Date: Thu, 8 Sep 1994 15:36:01 GMT
Reply-To: [email-masked]

In article <[email-masked]>, [email-masked] (David Barr) writes:
|> >
|> >Why don't you just use LD_LIBRARY_PATH to point to the different library
|> >location.
|> 
|> LD_LIBRARY_PATH is a hack, and a painful one at that.
|> 
|> 1) It increases load time
|> 2) It applies for _all_ libraries, not just the one you're interested with.
|> 3) It interacts badly with ld, such that when things are compiled with
|>    LD_LIBRARY_PATH set, the program then assumes that it will continue
|>    to be set.

But there has to be a mechanism for telling the loader where to find
libraries.  IMHO the mistake is in letting ld see the variable and
use the value.  It would be consistent to have LD_LIBRARY_PATH be
strictly runtime.  The downside is (2), but there's got to be some
pain :-) doesn't there?

________________________________________________________________________
Gary R. Hook                         | "Yes, John, but when Pirates of
AIX Application Enabling             | the Caribbean breaks down, the
IBM Corporation, Southlake, Texas    | pirates don't eat the tourists."
The above opinions are all mine.     | - the lawyer in "Jurassic Park"

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

From: [email-masked] (Rob Janssen)
Subject: Re: SyQuest removable SCSI driver?
Reply-To: [email-masked]
Date: Thu, 8 Sep 1994 19:00:48 GMT

In <[email-masked]> [email-masked] (Aaron Turner) writes:

>Hi all,
>I have a SyQuest 3720S (270MB SCSI removeable HD) running off a SB16 
>SCSI-2.  I was wondering if someone has written a driver for it like the 
>one SyQuest provides for DOS that allows automatic recognition of a new 
>cartridge when I swap cartridges.  (without the driver you can't swap 
>cartridges without rebooting.)  Is there one for Linux?  If not could one 
>be written?  If so could someone point me the way?  I can get any spec I 
>might need about the drive (how it reports swapping, etc.) since I work 
>at SyQuest.  Or would someone be willing to write it?  I'm very new to 

Removable disks are already supported.  Just unmount the disk, swap
the cartridge and mount the new one.

>Linux and have a little programming background, but nothing like this.  I 
>could get you anything you might need- I might even be able to con one of 
>my friends who programmed the DOS version to give you some info.  BTW, 
>yes, I do know that I can just umount & then mount the new cartridge, but 
>since I swap cartridges so much this is becoming a pain.  TIA for anyone 
>who can give me some insight!

Ahaaaa!  You want to swap cartridges without unmounting.
That cannot be done.  The system *has* to be informed about removing
the cartridge before you actually do it.  It has to write back information,
and return the state of the filesystem to "clean".
Linux is not DOS!

However, if there is some signal from the drive that you press the
button to unmount the disk, the unmount operation maybe could be done
automatically.  I don't know if this Syquest model supports "door locking"
and has motor-driven eject, but if it does this could be possible.

(drives with door locking are locked as long as the disk is mounted, so
that you cannot swap the disk without first unmounting it.  This is
intentional)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Andreas Busse)
Subject: Re: [Q] on Linux/MIPS port
Date: 8 Sep 1994 09:52:34 GMT

In article <1994Sep2.103748.4362@ludens>, [email-masked] writes:
|> Hello,
|> 
|> I've read the annonuncement and FAQ on the MIPS/linux port, and there are
|> still things I'd like to know...
|> Does this port work only for that specific board ?

Currently yes, since we only have this one (besides the MIPS Magnum 4000
on which I am writing this article...). However, it shouldn't be a problem 
to port Linux/MIPS to other ARC (Advanced Risc Computer, a specification of MIPS, Microsoft and a lot of other companies) compliant boards, since they 
all have ISA, EISA, VLB or PCI bus systems.
That means: if your MIPS board runs Windoze NT, it will probably run 
Linux/MIPS too, perhaps after *slightly* patching the kernel. There
might be some differences in the address maps and how DMA is handled.
 
|> What about other architectures based on MIPS processors ?

See above.

|> Once this project is done, how difficult would be to port _that_
|> to a MIPS based DECstation for example ? I'm curious because we have a bunch
|> of DECstation 3100's (Running MIPS R3000 as I know and Ultrix). Currently
|> we can only use them for X terminals (lack of memory and hd) but maybe with
|> the efficient memory management of linux ( e.g. shared libs and dynamic buffer
|> cache - things that Ultrix never heard about ) we could use them as regular
|> workstations...
|> Is such a porting project planned anywhere ? I'd contribute, but I have not
|> enough time, resources and experience to start it alone.
|> Generally, I think it'd make sense to port linux (as a free, modern and usable
|> unix clone) to architectures which are the latest ones (like ALPHA and PowerPC)
|> but they're reliable, incorporate standards (like SCSI)  and widely used.
|> 
|> tivadar
|> 

The major problem is that these old DECstations have R3000 processors.
There are some differences in the MMUs and in the instructions set of 
the R3xxx and R4xxx which will make a R3xxx port a bit more complicated. 
Another thing is that DECstations don't have an ISA (or similar "industry standard") bus. Most drivers must be rewritten to the specific I/O subsystem these boxes have. 
However, the R3xxx and R4xxx processors are similar enough to take
advantage of our port. It should be at least possible to provide
user-mode binary compatibility between R3xxx and R4xxx boxes - and this
would help a lot ! BTW, this is what MIPS has done anyway - the stuff
I write on my MIPS 4030 runs perfectly on our MIPS 3330 and vice versa.
It will also help that our Mips Port is native little-endian, just like 
your PC and your DECstation.

We already received several questions what's about DECstations 
while others prefer to wait for the ultraP (a module which holds
both a Pentium and a R4x00 and lets you choose which CPU to use)
or whatever will come along.
I guess there will be a lot of MIPS board running Linux/MIPS in
near future - we just need a little help since we can't buy all
of them !

Andy

===============================================================================
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  [email-masked]
===============================================================================

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

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