Subject: Linux-Development Digest #323
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Mon, 17 Oct 94 09:13:13 EDT

Linux-Development Digest #323, Volume #2         Mon, 17 Oct 94 09:13:13 EDT

Contents:
  Outportb, Inportb under Linux ? (Kar Fai Choong)
  Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks) (Erik Blass [SysAdmin])
  Re: WP Project --Info and Volunteers WANTED!!! (J.J. Paijmans)
  Re: Linux Mud (Dominik Kubla)
  Re: [Answer?!] Re: ext2fs vs. Berkeley FFS (Brian Mounce)
  Re: We a FAQ: Linux vs. *BSD!!! (M.C Wong)
  [ANNOUNCE] Linux-SDK Project (Dominik Kubla)
  Re: ext2, UFS, Linux, and Mach (Chris Bitmead)
  Re: ext2fs vs. Berkeley FFS (Chris Bitmead)
  Re: Shared Libs: working toward a permanent solution? (H. Peter Anvin)
  Re: Looking for X graphics/ Plotting libraries (Alexandre Naaman)
  WP Project --Info and Volunteers WANTED!!! (Cory Zito)

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

From: [email-masked] (Kar Fai Choong)
Subject: Outportb, Inportb under Linux ?
Date: Fri, 14 Oct 1994 20:37:11 GMT

Hi,
        I am writing a program under Linux that will requires me to write.
read from the printer (parallel) port directly. I have done it under
Dos with the command "outportb","inportb" in C. (All I am trying to do is to
read/write the IO space at 378h.)

        Are there any commands under Linux which will do the same job ?

        Also, what libraries are there that contains functions that control the
screen. For example, clear screen, changing cursor positions..

Thanks for your help,

Kar Fai Choong
[email-masked]
-- 
Kar Fai Choong

email: [email-masked]
University of Waterloo

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

From: [email-masked] (Erik Blass [SysAdmin])
Subject: Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks)
Date: Sat, 15 Oct 1994 16:48:03 GMT

Dave Perks ([email-masked]) wrote:
: >As several have mentioned previously,
: >this is probably the fault of the process table handling and scheduling
: >algorithms.  This needs to be fixed BADLY.

:                                      ^ no, it needs to be fixed WELL :-)
And they have to go into 1.2 !

Erik

-- 
Erik Blass|Internet [email-masked]
Theegartener Str.38|42651 Solingen|Voice:0212-201660
Ich habe Dinge gesehen, die ihr Menschen niemals glauben wuerdet. Gigantische
Schiffe die brannten an der Schulter des Orion. Und C-Beams - glitzernd in der
Dunkelheit nahe dem Tannhaeuser Tor. All diese Momente werden verloren sein in
der Zeit...so wie Traenen im Regen.       Zeit zu sterben...       [Roy Batty]

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

From: [email-masked] (J.J. Paijmans)
Crossposted-To: comp.os.linux.misc
Subject: Re: WP Project --Info and Volunteers WANTED!!!
Date: 17 Oct 1994 08:49:43 GMT

In article <[email-masked]> [email-masked] (Cory Zito) writes:
>
>After following the discussions on WYSIWYG Word Processing I have decided 
>that its time to get together a development group to create such a beast.
>
>Right now I am looking for input on exactly what people are looking for 
>in a WYSIWYG WP, People who want to help out with the project, and other 
>things that people feel pertain to the project.
>
...

Whatever you do... make sure that the "bread-text" is an ASCII-file.
Take Ventura Publisher as an example: the text is in plain ASCII with
markups. Bells and whistles were coded in 'parallel-files', but even
these were in ASCII. If you had to travel, use a terminal or whatever,
you could continue writing in the text-file and worry about the
lay-out later. Also the Ventura-files were easily emailed, with or
without the 'parallel-files'.

Now if the Ventura markup-style could be exchanged for the LaTeX markups,
you would have the best of both worlds.

Paai.

(BTW, as a reviewer for a computermagazine I've more or less seen
everything that could be seen on the PC...

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

From: [email-masked] (Dominik Kubla)
Subject: Re: Linux Mud
Date: 17 Oct 1994 09:19:00 GMT

In article <[email-masked]> [email-masked] (Dirk Weigenand) writes:

   Try Amylaars driver available from mud.uni-muenster.de. It's a driver
   for LP-Muds capable running in compat and native mode. There is also
   a mudlib available at that adress. This driver is developed on linux

You also might want to look at MudOS 0.9.20. There is a tiny mudlib included
for all of you who would like to start from scratch (dont expect too much,
it has ed and rm, but not even ls ...). There are two rather complete mudlibs
available: TMI-2 and Nightmare.

   Have fun,

I certainly will ;-)

Dominik
--
===========================================================================
eMail: [email-masked]    sMail: Dominik Kubla, Lannerstrasse 53
                                            55270 Ober-Olm, F.R. of Germany
>>> Save the environment NOW! <<<           ******  European  Union  ******

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

From: bam@ver1 (Brian Mounce)
Subject: Re: [Answer?!] Re: ext2fs vs. Berkeley FFS
Date: 13 Oct 1994 18:21:43 GMT
Reply-To: [email-masked]

Leonard N. Zubkoff ([email-masked]) wrote:
> In article <[email-masked]> Stephen Tweedie <[email-masked]> writes:

>   In general, Linux's ext2fs is significantly faster than ffs.  I don't
>   have hard performance data right beside me, but I can get it if you
>   like.  From memory, ext2fs is typically 10% to 50% faster than ffs for
>   general use; some operations (such as unpacking a large tar archive) can
>   achieve a much greater speedup.

[snip]

> Yes, my Linux system did this five times faster than a SparcStation!

I wrote a C program to build a 6-level directory structure with 12000
directories and about 13K files (about 70 MB total).    This was used 
to test a DB structure for use on HPUX and SunOs workstations.
It took 60 minutes (wall clock time) to build on a Sparc 10/41 and
an HP 750.

It took only 15 minutes (four times faster) on my 8MB 486DX2/50 Linux machine
with a WD Caviar IDE drive.

--
 Brian Mounce                             Design Automation Division
 [email-masked]                          Texas Instruments, Inc.
 MSGid BAMM                               MS 3937 PO BOX 655311
 214-917-3647                             Dallas, TX 75265

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

Crossposted-To: comp.os.386bsd.development
From: [email-masked] (M.C Wong)
Subject: Re: We a FAQ: Linux vs. *BSD!!!
Date: Mon, 17 Oct 1994 03:20:42 GMT

Would that be a good idea to compile list/table of features of each OS,
where each of the features is assigned a score of 
VOTE/SOPHISTIFICATION/OR_WHAT_EVER_YOU_CALL_IT. So for a newbie to decide,
he/she only needs to run through the list for the feature(s) he/she want 
, adds up the scores, and decide for himself/herself. Of course the score 
assigned to either OS features must be done by someone with rich experience with
them and with an OPEN mind. 

Also, the features can again be broken down to different
categories of granularity, eg : supported hardware, availablility of applications,
ease of use and installation, stability etc etc etc. For one to decide 
quickly between the two, if I can't even get OS X installed on my non-supported
Y machine, there is no need to look ahead and ask more about which is
better, given that I won't be able to use it in the end.

Anyway, one needs to toss the coin if the score works out to be equal! 

JM2CW!

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 M.C Wong                                  Email: [email-masked] 
 Australian Telecom Operation              Voice: +61 3 272 8058        
 Hewlett-Packard Australia Ltd             Fax:   +61 3 898 9257        
 31 Joseph St, Blackburn 3130, Australia   OS: FreeBSD-1.1.5.1
 http://hpato.aus.hp.com/users/mcw/www/mcw.html

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

From: [email-masked] (Dominik Kubla)
Subject: [ANNOUNCE] Linux-SDK Project
Date: 17 Oct 1994 10:12:32 GMT

I want to inform all of you, that Linux International's SDK project is back
in business. It has been sleeping due to the lack of volunteers, also there
has been a most active discussion on the mailing list some time ago.
Now there is at least ONE volunteer to work with me on that project.

Originally the goal was to provide a full-fledged development environment,
including interface builders and CASE tools. That has been downgraded to
the following agenda:

* Development of an Integrated Development Environment (aka IDE) similiar to
  that of the Borland or Watcom Compileres under Windows. It will eventually
  include the following frontends (but due to extensibility it might become
  even more ...):
  - X11-based Editor
  - GNU C/C++/Objective-C compilers
  - GNU Pascal compiler
  - F2C Fortran-77 translator
  - CVS version controlling system
  - GNU gdb debugger
  - GNU gprof profiler
  - X11-based information browsers (man, info and html format)
  - X11 GUI design tool
  - DejaGNU program testing system
  - GNATS problem tracking system 
  - Linux-specific tools (like dll-tools)

* Tk/Tcl will be used for the actual development, but might be replace if
  necessary. (This is partly because many of the frontends already exist in
  tk/tcl ...)

* Provide a complete documentation of the Linux environment. Fortunately we
  can take advantage of the Linux Documentation Project and the other already
  existing documentation.

If you want to support this project, please drop me a mail at:

  [email-masked]

The following facilities exist for the benefit of the development team and
other interested people (some of them for the development team only):

Mailing list: [email-masked]
  To join send a mail to [email-masked] with the words
  'subscribe linux-sdk <your-address> in the body'

FTP-Server:   ftp://ftp.Uni-Mainz.DE/pub/Linux/SDK
  This where the test releases will show up, there is an additional hidden
  area for the developers.

WWW-Server:   <TBA>
  This were the latest status update will be kept, accompanied by additonal
  Information.

MUD-Server:   <Developers only>  
  This is a MUD which will be used as 'Virtual Conference Room' and is only
  accessible to the development team.

Cheers,
  Dominik Kubla (Project coordinator)

--
===========================================================================
eMail: [email-masked]    sMail: Dominik Kubla, Lannerstrasse 53
                                            55270 Ober-Olm, F.R. of Germany
>>> Save the environment NOW! <<<           ******  European  Union  ******

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

From: [email-masked] (Chris Bitmead)
Subject: Re: ext2, UFS, Linux, and Mach
Date: 17 Oct 94 17:08:27

In article <[email-masked]> [email-masked] (travis jensen) writes:

>I am considering a project to take the ext2fs and put a layer
>of vaneer over it so it could be mounted as a UFS file system.
>This would allow Mach to be able to share Linux partitions (and
>vice-versa).
>
>A couple of questions:
>
>Is this even possible?  I figure anything is possible, but is
>this a project of weeks, months, years, or millenia?
>
>Where can I find documentation on the ext2fs?  I would like
>something a little better than source. :)
>
>Is this being done already?  If so, who is doing it?

Ext2fs has been ported to Mach/Hurd, by the current maintainer of the code
I think.

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

From: [email-masked] (Chris Bitmead)
Subject: Re: ext2fs vs. Berkeley FFS
Date: 17 Oct 94 17:26:49

In article <[email-masked]> [email-masked] writes:

>In article <[email-masked]>
>[email-masked] (Chris Bitmead) writes:
>In another article someone writes:
>   > Stuff about adding 'forks' to the filesystem deleted
>
>   But the question still remains: Why do you want this???
>
>Because it makes things simpler for many uses, especially for stuff like
>associating documents with applications and the like -- file is generally not
>clever enough to do this sort of thing. 

Why not directories still? Soon you'll want to categorize your documents
and you'll want two or more levels of "forks".

>One could almost certainly write a far
>more intuitive Desktop type frontend to X if you could be sure that all files
>had associated info/data/resource forks.

Then just invent a suitable convention, a la NeXT Step.

>   You say you would like a "main fork" in a file and then various
>   "attribute" forks. Why this is better than a directory I don't know.
>
>Because it makes it easier to write code. Even if it's syntactic sugar
>'f0=open(foobar:INFO,RD_ONLY);' makes a good deal of sense, especially in
>cases where foobar is an executable. 

Syntactic sugar is a very poor reason. Syntactic sugar issues belong
firmly in user space.

>I know you can stash a good deal of this
>stuff in your .Xdefaults file and in /usr/lib/foobar or whereever, but it's
>not exactly intuitive is it? 

.Xdefaults isn't intuitive at the best of times. Use some Gui interface
front end for modifying your .Xdefaults.

>Using data forks means that it becomes far easier
>for a naive luser to move software about without breaking it by accident.

Naive users are incapable of using vi and modifying .Xdefaults anyway, and
under your system they will have to understand forks as well. The only
answer is a nice gui program that hides all this.

>   Why should there be one "main" fork? And why are you too lazy to use cp -r
>   to copy them?
>
>Okay, you copy a fully working X application from one machine to another so
>that it behaves in the same way on the new host as it did on the first one.
>Now ask someone who doesn't have a great deal of experience with X to do the
>same thing. Ask them to do the same thing with a Mac Application. I'll bet
>good money that they do a far better job of the latter.

What you're saying is that you don't like the separation of the
app-defaults files from the binary. The X designers could have started a
convention of putting them into the one directory, but they probably
didn't because the app-defaults files are machine independant, but the
binaries are not, thus they don't belong together. If you would prefer
them in the one directory however, be my guest. But you don't need kernel
support for it.

>   What if you start to want forks with sub-forks. Soon you'll start to want
>   the full facilities of directories, and we might as well leave it the way
>   it is.
>
>Oh don't be stupid.

I don't see the stupidity. If you build in a limitation to an OS, (like
single level forks), then immediately users are  going to complain, why
they can't have multi level ones.

>   Don't be influenced by the over-featurism that NT offers. There's no need
>   for this crud.
>
>Actually, my model for this sort of thing is the Mac filesystem. I wouldn't
>call it overfeatured, but it does a lot of stuff very well, and very easily,
>that is a royal PITA to accomplish with Unix.

Obviously you've never heard of user level libraries. Solve it once and
stop complaining.

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

From: [email-masked] (H. Peter Anvin)
Subject: Re: Shared Libs: working toward a permanent solution?
Reply-To: [email-masked] (H. Peter Anvin)
Date: Fri, 14 Oct 1994 21:42:41 GMT

Followup to:  <[email-masked]>
By author:    [email-masked]
In newsgroup: comp.os.linux.development
>
> Unfortuantely, life's not that simple.  What if you take the address of
> a static variable, and store it into a structure?  That structure member
> might contain a pointer to a static variable local to the shared
> library, or it might contain a pointer to memory in the main program's
> data segment.
> 
> Or what the library routine needs to return the pointer to a static
> variable, like gethostbyname() does?
>

Not a problem -- just use global memory references.

All I originally proposed was to use a segment register instead of
ebx-relative addressing -- set up a segment register to *alias* the
memory, and after that use, for example

        movl %gs:(%edi),%eax

Instead of

        movl (%ebx+%edi),%eax

Also, use:

        addl %gs:__libbase, %esi        # Create absolute pointer

Instead of:

        addl %ebx, %esi                 # Create absolute pointer

It's a kluge, but it saves a register, which is a premium resource on
the i386 architecture.

Since GCC *already* can handle ebx-relative PIC addressing, it shouldn't
be a difficult modification.  The difficult part much have been
implementing PIC in the first place.
 
> Or what if the library program wants to call strlen(), strcpy(), or
> strcat()?  Those routines won't know if the passed in pointer is in the
> program's data segment, or in the shared library's data segment.  

How does the PIC routines now handle that?

> Without compiler support, people who code shared libraries would have
> to be very aware of the segmentation issues, since they would have to
> handle them by hand --- just as we do in the kernel.  I doubt that would
> be popular with applications programers.

I think you read too much into this.  Yes, putting shared libraries
into their own segments is an architecturally attractive proposition,
but it is quite non-UNIXy, and you have to deal with 48-bit pointers.
It is not an option for Linux.  However, the segment registers are
still there, even though they are unused, and can be used to implement
offset-shifting without losing the ebx register, which the current
version of the ELF libraries use.

        /hpa

-- 
INTERNET: [email-masked]             --- Allah'u'abha ---
IBM MAIL: I0050052 at IBMMAIL     HAM RADIO:   N9ITP or SM4TKN
FIDONET:  1:115/511 or 1:115/512  STORMNET:    181:294/1 or 181:294/101
AN UNDETECTABLE ERROR HAS OCCURRED [actual MS-Windows 3.1 error message]

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

From: [email-masked] (Alexandre Naaman)
Crossposted-To: gnu.gcc.help
Subject: Re: Looking for X graphics/ Plotting libraries
Date: 17 Oct 1994 05:08:37 GMT

CookieMonster ([email-masked]) wrote:

: I am working on a small project, and need some library routines to do 
: some simple X windows graphics: Pop open a window, take some disk data, 
: and graph the data in the window with auto-scaling, axis, etc. SInce I 
: want to spend more time on the data producing side of the program, I need 
: a package that can do the plotting for me.

If you are familiar with Borland's BGI stuff I suggest you take a look at
xbgi. I don't remember where I got it sorry :)

Ciao,

Alex.

--
Alexandre Naaman                    |  Try out my home page :
Mechanical Engineering Student      |  http://www.polymtl.ca:8001/zuse
Ecole Polytechnique de Montreal     |       /naaman/Mosaic/home.html

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

From: [email-masked] (Cory Zito)
Crossposted-To: comp.os.linux.misc
Subject: WP Project --Info and Volunteers WANTED!!!
Date: 16 Oct 1994 17:26:57 -0600

After following the discussions on WYSIWYG Word Processing I have decided 
that its time to get together a development group to create such a beast.

Right now I am looking for input on exactly what people are looking for 
in a WYSIWYG WP, People who want to help out with the project, and other 
things that people feel pertain to the project.

In a couple of days I should have a web site and a project goals sheet up 
(after I get some input)

Thanks,

Cory Zito

-- 
*  Cory Zito   *    Email: [email-masked]                    *
*  AA9GB       *    In protest of .sigs this sig is blank           *
*  Saxophonist *                                                    *
*  Student     *                                                    *

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

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