Subject: Linux-Development Digest #889
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:     Tue, 5 Jul 94 09:13:09 EDT

Linux-Development Digest #889, Volume #1          Tue, 5 Jul 94 09:13:09 EDT

Contents:
  dosemu and lost selection (Dennis Mahle)
  Re: BSD 4.4 Lite (Jinwoo Shin)
  High performance graphics under Linux (or lack thereof) (William Hoffman)
  (?) C64 disk drive interface and file system? (Greg Alt)
  Re: (?) C64 disk drive interface and file system? (Sebastian W. Bunka)
  Re: Linux seems to perform terribly for large directories (Kees J. Bot)
  Re: BSD 4.4 Lite (Chris Bitmead)
  Re: Linux seems to perform terribly for large directories (Chris Bitmead)
  Re: NetBEUI (Jeremy Fitzhardinge)
  Re: Dead shells with 1.1.23! (Michael Klemme)
  Re: Multicasting. (Steve DuChene)
  Re: Frame grabbers and Linux: is it possible? (Luuk Spreeuwers - UT)
  Re: Multicasting. (Laurent Chavey)
  Re: Linux seems to perform terribly for large directories (Rob Janssen)
  Re: DosEmu suggestion (Rob Janssen)
  Re: dosemu and lost selection (Rob Janssen)
  Linux kernel programming book (U.Kunitz)
  Re: Multicasting. (Alan Cox)
  Re: NetBEUI (Volker Lendecke EIFFEL)
  Re: Floppy code broken w. 1.1.23 (Matthias Urlichs)
  Re: SOL'N: DOSEMU/Netware (Matthias Urlichs)
  Re: Linux seems to perform terribly for large directories (Matthias Urlichs)

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

From: dmahle@falcon.depaul.edu (Dennis Mahle)
Subject: dosemu and lost selection
Date: Tue, 5 Jul 1994 02:36:06 GMT

I have just upgraded to 1.1.13 kernel and dosemu-0.52.  This is my
first attempt at dosemu, so I can't comment about earlier versions.
My Problem: When I boot linux, selection (vt cut/paste) works fine 
until I run dosemu.  After a normal dosemu exit, via emuexit, I get
no response from the mouse on a vt.  (Mouse works fine in X, though).

If anyone has a workaround please share... I love dosemu and have 
spoiled myself w/ selection.  

Thanks,
Dennis  aka dmahle@falcon.depaul.edu

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

From: jwshin@nitride.EECS.Berkeley.EDU (Jinwoo Shin)
Crossposted-To: comp.os.mach
Subject: Re: BSD 4.4 Lite
Date: 5 Jul 94 04:32:21 GMT

dneal@sugar.NeoSoft.COM (David Neal) writes:

>I'm desperately searching for the BSD 4.4 Lite FTP site that
>was posted to comp.os.linux.development or comp.os.mach.

I believe kind souls at ftp.cdrom.com has it online.
-- 
Jinwoo Shin                             jwshin@eecs.berkeley.edu
System Administrator                    
Berkeley Sensor and Actuator Center

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

From: wmhoffma@crab.rutgers.edu (William Hoffman)
Subject: High performance graphics under Linux (or lack thereof)
Date: 5 Jul 94 05:14:04 GMT

Hi.

I've been having some trouble porting my DJGPP (DOS 32-bit port of
GCC) graphics code to Linux and svgalib.  I've been able to get all
the functionality ported, but the speed has been left behind.  I was
getting about 10 fps with my test program using DJGPP in DOS, and by
contrast I'm getting about 1 fps under Linux.
   I'm running Linux 1.1.24 on a 486DX2-66mhz machine with 8mb RAM, a
Cirrus 5424 VLB video card, and at least 140mb free in the Linux HD
partition.  There is no disk access during the body of the program,
everything I need is in memory (about 500K total code and data).  I
have no other processes running except a couple gettys and any daemons
Linux starts itself.  The program is written in C++, and the only
changes made to port to Linux were to initialize/shutdown graphics and
to copy the frame buffer to video memory.  I call svgalib's
initialization code, and only use the graph_mem pointer it provides
for my frame buffer copy.  (I don't call any functions in svgalib to
copy the frame buffer.)  Other than that, the code is identical, (even
the Makefile, save a new library reference or two) and works great...
but ten times slower.
     Why?  The overhead caused by multi-threading tasks (especially
ones that are not doing anything) can't cause THAT much of a slowdown,
can it?  Does it have something to do with the way that I'm linking?
It must be something really easy that I'm just overlooking, or I can't
imagine how I'm going to program any kind of high-performance graphics
for Linux.  (I get 5 fps just compiled with Borland C++ 3.1 and
running in DOS REAL mode!)
     Help!

                                        George Hoffman
                                        Linux Novice

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

From: galt@asylum.cs.utah.edu (Greg Alt)
Crossposted-To: comp.emulators.cbm
Subject: (?) C64 disk drive interface and file system?
Date: 5 Jul 1994 06:40:28 GMT

A while back someone mentioned wanting to work on writing a file system
for a C64 disk drive (and the reverse, making a Linux file server for a
C64).  I was wondering what became of that, and how much work has been 
done so far if any.

(also, where can I get a C64 emulator for X Windows under Linux?)

Greg
-- 
---
"Zen fascists will control you.  100% natural.  You will jog for the 
master race... and always wear your happy face" - Jello

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

From: seb@i102pc1.vu-wien.ac.at (Sebastian W. Bunka)
Crossposted-To: comp.emulators.cbm
Subject: Re: (?) C64 disk drive interface and file system?
Date: 5 Jul 1994 09:09:14 GMT
Reply-To: Sebastian.Bunka@vu-wien.ac.at

Greg Alt (galt@asylum.cs.utah.edu) wrote:

: (also, where can I get a C64 emulator for X Windows under Linux?)
check comp.emulators.announce:
there is a cbm FAQ for all this things; even the C64 X11 emulator
is mentioned - too long for crossposting...
Cheers, SWB

                      [ Sebastian.Bunka@vu-wien.ac.at ]
                        phone:                   FAX:
                +43-1-71155260          +43-1-7149110
Location: earth, europe, austria, vienna  Inst. of Bacteriology  Vet.Univ.

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

From: kjb@cs.vu.nl (Kees J. Bot)
Subject: Re: Linux seems to perform terribly for large directories
Date: Tue, 5 Jul 1994 09:31:29 GMT

chrisb@cssc-syd.tansu.com.au (Chris Bitmead) writes:
>
>I'm sure this is not true. Any sorting is probably done by the "ls"
>program or the shell where appropriate.
>See the -f option to ls which prints contents in physical order rather
>than sorted order. If this speeds things up then sorting is part of the
>problem. 

For the fun of it I created a directory with 5000 entries under
Minix-386vm running on a 486dx/33.

A simple 'ls' in this directory took only a fraction of a second, but a
call like 'ls -F' took almost a full minute, just like Linux.

This does not surprise me at all.  What the simple ls call does is:

        read directory  -  sort names  -  print.

The 'ls -F' call does:

        read directory  -  stat each name  -  sort names  -  print.

5000 stat calls causing a linear search in a directory takes quite some
time.  Many of you Linuxers probably have 'ls' aliased to 'ls -F', so
just typing 'ls' will always use a lot of time in a very large
directory.
--
                                Kees J. Bot  (kjb@cs.vu.nl)
                      Systems Programmer, Vrije Universiteit Amsterdam

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

From: chrisb@cssc-syd.tansu.com.au (Chris Bitmead)
Crossposted-To: comp.os.mach
Subject: Re: BSD 4.4 Lite
Date: 5 Jul 1994 17:55:55 +1000

dneal@sugar.NeoSoft.COM (David Neal) writes:


>My apologies for a global posting, and to two newsgroups no less!

>I'm desperately searching for the BSD 4.4 Lite FTP site that
>was posted to comp.os.linux.development or comp.os.mach.

>I've already tried archie, my news-server, my News directory,
>and any place else it might be squirreled away. No luck.

4.4-lite is available in src.doc.ic.ac.uk in /packages/unix/4.4bsd-lite:

ftp> dir
drwxr-xr-x   3 root     other         512 Jun 15 10:04 .
drwxr-xr-x  29 root     root         1024 Jun 15 08:46 ..
-rw-r--r--   1 root     other    43387714 Jun 15 08:58 bsd-4.4-lite.tar.gz
drwxr-xr-x   2 root     other        1536 Jun 15 10:04 split
ftp>

The split directory contains the .tar.gz file split into 85 x 512000 byte
pieces.




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

From: chrisb@cssc-syd.tansu.com.au (Chris Bitmead)
Subject: Re: Linux seems to perform terribly for large directories
Date: 5 Jul 1994 17:37:56 +1000

iiitac@uk.ac.swan.pyr (Alan Cox) writes:

>In article <Cs94z0.s9@pe1chl.ampr.org> pe1chl@rabo.nl writes:
>>The directory is accessed only with linear seaches.  So, when it is
>>large, it becomes exceedingly slow to access it.
>>Another factor is that removing files only frees their slots, but does
>>not compact the directory.  So, after that it remains as slow as it was
>>until you remove and re-create the directory.

>There are two issues far more significant. Firstly it does user lookups for
>each file in -l mode which can be quite slow (especially with NIS running),

This shouldn't be a problem. All the user info should be read in one go,
and it shouldn't matter whether you are reading 1 or 1000 files.

>also unix directories are sorted, DOS ones are not.

I'm sure this is not true. Any sorting is probably done by the "ls"
program or the shell where appropriate.
See the -f option to ls which prints contents in physical order rather
than sorted order. If this speeds things up then sorting is part of the
problem. 

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

From: jeremy@suite.sw.oz.au (Jeremy Fitzhardinge)
Subject: Re: NetBEUI
Date: 5 Jul 94 06:33:20 GMT

In <1994Jul4.140346.10868@uk.ac.swan.pyr> iiitac@uk.ac.swan.pyr (Alan Cox) writes:
>>This is something I'm wondering too. It seems that everybody and my brother in
>>law is writing filesystems for Linux, but no-one seems to be planning to add SMB
>>client for the kernel. Anybody interested? I have no experience in such work so
>>maybe we can found someone who has and also I have plenty of projects to go
>>so let's not trust that I'll do it.
>
>Lan Manager has no inode concept which makes things fun. Doing it as a userfs
>is feasible but 'interesting'

I've mostly completed an ftp userfs.  I've been told that SAMBA has an ftp-like
user interface: it may be possible to take that code and mash it together with
the ftpfs userfs, and come up with something that people may find useful.

Not having inodes is not really a problem: nfs doesn't either, but its easy
enough to fake them.  At worst, all you need to do is allocate inode numbers
locally and map them to the files.

        J

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

From: klemme@uni-paderborn.de (Michael Klemme)
Subject: Re: Dead shells with 1.1.23!
Date: 5 Jul 1994 10:34:45 GMT

Thomas Boutell (boutell@netcom.com) wrote:

> I've always had a bunch of xterms kick in during my .xinitrc. This has
> never been a problem previously. But since I upgraded from 1.1.12
> to 1.1.23, one or two xterms out of ten or so always fail. The
> window manager asks me to position a tiny window, which goes
> away immediately. 

> Most bizarre of all, today my "Console" xterm (which should come
> up running nothing) came up running vim on a file that should
> have been running in another xterm, which never appeared.
> When I hit a key or two, the xterm filled itself with garbage
> instead.

> Everything else is fine -- I have had no other problems
> with 1.1.23.

I have the same problem with every kernel I tried since 1.1.12. 
Syslog records a message saying something like "pty closed".

This only happens when I start X ==> when the system load is high. 
The behaviour is the same with Xfree2.[01][.1].

I am running Linux on a 386dx40 with 8MB RAM.


Greetings

        Michael
--
     Michael Klemme
     Gesamthochschule Paderborn, Germany
     EMail: klemme@uni-paderborn.de

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

From: s0017210@cc.ysu.edu (Steve DuChene)
Subject: Re: Multicasting.
Date: 5 Jul 1994 08:39:35 GMT

Alan Cox (iiitac@uk.ac.swan.pyr) wrote:
: In article <2v501b$bv@aurora.engr.LaTech.edu> dgarrett@orbit.cs.engr.latech.edu (Don Garrett) writes:
: >  Is there multicast support under any of the linux network systems,
: >or is it in the works?

: In the works.
: Alan

        Fogive my dumb question, but what is multicasting vis-a-vis networks?
-- 
| Steven A. DuChene   sduchene@cis.ysu.edu  or  s0017210@cc.ysu.edu      
| Youngstown State University  | Computer Science / Math / Mech. Eng.
|They all laughed at Albert Einstein. They all laughed at Columbus. 
|Unfortunately, they also all laughed at Bozo the Clown. 

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

From: luuk@mi.el.utwente.nl (Luuk Spreeuwers - UT)
Subject: Re: Frame grabbers and Linux: is it possible?
Date: Tue, 5 Jul 1994 08:07:10 GMT

sklein@ramz.ing.tu-bs.de (Sascha Klein) writes:

>In article <9407011132.AA18843@ipvvis.unipv.it>, rubini@ipvvis.UNIPV.IT 
>(Alessandro Rubini) writes:
>|> We are looking to buy a frame grabber for our lab: the PC products are quite
>|> attractive and cheap, but we won't shoot ourselves by running windoze or such.
>|> We'd better have support for two concurrent cameras and for storing sequences,
>|> if available.
>|> 
>|> So my questions:
>|> - Is there a driver for any of the available grabbers out there?
>|> - Either, are there docs about the software interface so to write the
>|>     driver ourselves?
>|> 
>|> Please, help me bringing a linux box in the lab ;-)
>|> 
>|> Thankyou in advance
>|> /alessandro

>I am programming the DT2861 (Data Translation) frame grabber board. There is
>no driver, so i have to programm the board myself. This is not very
>difficult, because the documentation from Data Translation is very good. I
>have a complete description of the registers of the board and some examples
>for programming.

>Sascha Klein

I have written a driver for the IRIS frame grabber board. The driver and
info on the board you can obtain by the WWW:

        http://utelmi01.utwente.nl:1994/staff/luuk/myhomepage.html

Greetings,
Luuk
--
====================================================================
dr.ir. L.J. Spreeuwers                           _/    _/ _/_/_/_/
University of Twente                            _/    _/    _/
Laboratory for measurement and instrumentation _/_/_/_/    _/

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

From: chavey@bambam.cis.udel.edu (Laurent Chavey)
Subject: Re: Multicasting.
Date: 5 Jul 1994 11:29:36 GMT

What protocol standard are you planning to use for multicasting.
Is any "video conferencing" support in the work ?


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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Linux seems to perform terribly for large directories
Reply-To: pe1chl@rabo.nl
Date: Tue, 5 Jul 1994 07:59:21 GMT

In <1994Jul4.140054.10696@uk.ac.swan.pyr> iiitac@uk.ac.swan.pyr (Alan Cox) writes:

>In article <Cs94z0.s9@pe1chl.ampr.org> pe1chl@rabo.nl writes:
>>The directory is accessed only with linear seaches.  So, when it is
>>large, it becomes exceedingly slow to access it.
>>Another factor is that removing files only frees their slots, but does
>>not compact the directory.  So, after that it remains as slow as it was
>>until you remove and re-create the directory.

>There are two issues far more significant. Firstly it does user lookups for
>each file in -l mode which can be quite slow (especially with NIS running),
>also unix directories are sorted, DOS ones are not.

That is true for the "ls" program, but the original post was referring to
copying files to that large directory...

Anyway, GNU "ls" caches the user info, I think.  This may not be true
for all versions of "ls".
(or is it just the fact that my entire passwd file fits in one buffer?)

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: DosEmu suggestion
Reply-To: pe1chl@rabo.nl
Date: Tue, 5 Jul 1994 08:02:39 GMT

In <1994Jul4.142703.11656@uk.ac.swan.pyr> iiitac@uk.ac.swan.pyr (Alan Cox) writes:

>In article <2v6gbk$p7q@solaria.cc.gatech.edu> byron@gemini.cc.gatech.edu (Byron A Jeff) writes:
>>Well consider this: If Linux and DOSEMU share the same Enet card for TCPIP
>>then essentially you're putting a network in a single box. Mui confusing
>>if you have the same IP for both.

>Much better would be to find the dos interrupt interface to one of the DOS
>tcp/ip packages, and make that work in DOSEMU as calls to the 'real' kernel
>TCP/IP linux side.

I have digged up the "PC/TCP" kernel interface, but it seems like too much
work to be worth the trouble for me.
I will probably do some more work on the packet driver interface in DOSEMU
so that you can at least access all the cards and loopback.  Of course you
need different IP addresses for all the dosemu's.

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: dosemu and lost selection
Reply-To: pe1chl@rabo.nl
Date: Tue, 5 Jul 1994 08:06:38 GMT

In <1994Jul5.023606.2714@hal.depaul.edu> dmahle@falcon.depaul.edu (Dennis Mahle) writes:

>I have just upgraded to 1.1.13 kernel and dosemu-0.52.  This is my
>first attempt at dosemu, so I can't comment about earlier versions.
>My Problem: When I boot linux, selection (vt cut/paste) works fine 
>until I run dosemu.  After a normal dosemu exit, via emuexit, I get
>no response from the mouse on a vt.  (Mouse works fine in X, though).

>If anyone has a workaround please share... I love dosemu and have 
>spoiled myself w/ selection.  

Disable all mouse support in dosemu and try again.
Same for serial port support.

Once you find what causes it, try to re-enable what you really need.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: kunitz@informatik.hu-berlin.de (U.Kunitz)
Crossposted-To: comp.os.linux.misc
Subject: Linux kernel programming book
Date: 5 Jul 1994 12:12:49 GMT

Hi Linuxer,

There is a german book about Linux kernel hacking:

Linux-Kernel-Programmierung 
  Algorithmen und Strukturen der Version 1.0

                          Linux Kernel Programming
                            Algorithms and Structures of the Version 1.0

by

Michael Beck, Harald Boehme, Mirko Dziadzka, Ulrich Kunitz, Robert
Magnus, Dirk Verworner

Language: _german_
386 pages
CD-ROM
79.90 DM

Publisher: Addison-Wesley Germany
ISBN 3-89319-712-5

Contents:

1) Linux -- The Operating System
2) Compilation of the Kernel
3) Kernel Introduction 
4) Memory Management
5) Interprocess Communication
6) The Linux File System
7) Device Driver under Linux
8) Network Implementation
A) System Calls
B) Kernel-Near Commands
C) The proc File System
D) The Boot Process

At the moment Addison-Wesley doesn't plan to publish an english
translation of the book. If you would like reading the book in english,
send Email to

  linux@Informatik.HU-Berlin.De ,

use the subject

  Linux Kernel Programming Book ,

and write something like

  Yes, I want to read the book in english.

We appreciate any kind of support for our little campaign.

There is also a WWW page with information about the book:

http://www.informatik.hu-berlin.de/topics/linux/buch/linux-book-engl.html

Ciao, Uli
-- 
I know tha >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> t in my
heart I f >>>> Ulrich Kunitz >>>> kunitz@informatik.hu-berlin.de >>>> eel like
going ho >>>>               >>>> Voice: (030) 513 11 52         >>>> me again 
But I k <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< now ...  

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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Multicasting.
Date: Tue, 5 Jul 1994 11:15:43 GMT

In article <2vb687$hcc@news.ysu.edu> s0017210@cc.ysu.edu (Steve DuChene) writes:
>Alan Cox (iiitac@uk.ac.swan.pyr) wrote:
>       Fogive my dumb question, but what is multicasting vis-a-vis networks?

Sending data to a group of machines not just one or all. Its used extensively
by the MBONE research projects (get the MBONE.FAQ from somewhere).

ALan


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

From: lendecke@namu04.gwdg.de (Volker Lendecke EIFFEL)
Subject: Re: NetBEUI
Date: 05 Jul 1994 11:55:18 GMT


In article <jeremy.773390000@suite.sw.oz.au> jeremy@suite.sw.oz.au (Jeremy Fitzhardinge) writes:

   I've mostly completed an ftp userfs.  I've been told that SAMBA has an ftp-like
   user interface: it may be possible to take that code and mash it together with
   the ftpfs userfs, and come up with something that people may find useful.

   Not having inodes is not really a problem: nfs doesn't either, but its easy
   enough to fake them.  At worst, all you need to do is allocate inode numbers
   locally and map them to the files.

I'm currently writing a SMB-Client for Linux using Jeremy's userfs. The
first try was to take the client code from Andrew Tridgell's Samba and
add the necessary code to talk to the kernel.
But because of a huge amount of unnecessary stuff, the executable grew to
500 kb (including debugging info), so I started to rewrite it from scratch
on the weekend. I cannot promise anything, but it's fun to mount a 
dir exported by samba. (I do not have a WfW-Server to test it under
real-world conditions, but I think samba running locally should give
you nearly the same).
My program does not talk to the smb-client program, I implement the
SMB-Protocol directly. Samba is a great help for this.

    Volker

   +=================================================================+
   ! Volker Lendecke               Internet: lendecke@namu01.gwdg.de !
   +=================================================================+
--



    Volker

   +=================================================================+
   ! Volker Lendecke               Internet: lendecke@namu01.gwdg.de !
   ! Innersteweg 11                Voice:    ++49-551-703126         !
   ! D-37081 Goettingen, Germany                                     !
   +=================================================================+

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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Floppy code broken w. 1.1.23
Date: 5 Jul 1994 14:28:17 +0200

In comp.os.linux.development, article <CsC8r7.BoD@wg.saar.de>,
  bof@wg.saar.de (Patrick Schaaf) writes:
> 
> Matthias is correct. I still maintain that the patch is ugly.
> 
No argument here.  (I am referring to Patricks second sentence.  ;-)

Of course, the old kernel code (hardcoded device numbers for floppy and HD
driver and calling the has-changed functions directly) is ugly as well.
Since the ugliness will disappear as soon as the SCSI driver is updated,
I'm not too concerned; apparently, neither is Linux, else he wouldn't have
accepted the patch in the first place...

-- 
Torquemada's Law
   When you are sure you're right, you have a moral duty to
   impose your will upon anyone who disagrees with you.
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: SOL'N: DOSEMU/Netware
Date: 5 Jul 1994 14:42:41 +0200

In comp.os.linux.development, article <1994Jul2.082255.17702@dragon.s.bawue.de>,
  danny@dragon.s.bawue.de (Daniel T. Schwager) writes:
> 
> 1) Johannes Stilles worked on SLIP-based solution (connectint SOSS via
>    slip-packetdriver to a modem (/dev/ttypxx) and build a slip-connection
>    to linux slip-stuff). Johannes mentioned that the troughput is about 
>    1-2kb/sec.
> 
Ugly. Better use

> 2) running soss through the internet dosemu-packet-driver. Could be a problem
>    because of the second IP and the linux-kernel (is this true ??)
> 
which avoids all the problems of (1) while not creating any problems (1)
doesn't already have.

I don't know 
> 3) running soss via a second ethernet card (not recorgnizing by linux 
>    while booting):

Even more ugly, 'cause you need hardware. :-/

>       - the following unix-command do not scan recursivly thourgh the 
>           mountet soss-drive (novell-network-drive):
>         'find /novell-drive -print'
> 
find -noleaf.

-- 
I am your density.
  -- George McFly in "Back to the Future"
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Linux seems to perform terribly for large directories
Date: 5 Jul 1994 14:58:04 +0200

In comp.os.linux.development, article <jadestarCsD8rJ.A7n@netcom.com>,
  jadestar@netcom.com (Jim Dennis) writes:
> 
>    Wouldn't this be a function of the filesystem drivers?  Couldn't one
>    create a filesystem that had some sort of indexed directory structure
>    (like Novell's)?
> 
Or Apple-HFS or IBM-HPFS or ...

The problem isn't to write such a file system, the problem is to
(a) justify the effort, (b) have the time / need, (c) have the experience.

All three haven't shown up in one person yet. :-/

You might want to patch your Netnews software (which after all is the main
user of such huge directories) to create a subdirectory based on the last
digit of the filename. Or of the article number modulo 26 plus 'a'. Or
something like that.

>    Have the file system drivers changed this much between .99.13 and 1.1.x?
> 
No, but the underlying buffer management has.

>    Has anyone considered doing a 'journaling' enhanced fs for Linux?
> 
Yes, but (a) journaling / log file systems per se don't give you better
performance for directory management.

>    Do I ask enough questions for a newbie?
> 
Yep.  ;-)

-- 
The truth is the safest lie.
        -- Anonymous
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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


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