Subject: Linux-Development Digest #225
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sun, 25 Sep 94 14:13:19 EDT

Linux-Development Digest #225, Volume #2         Sun, 25 Sep 94 14:13:19 EDT

Contents:
  Re: [STATUS] Linus Floppy Driver Development (Steve Kneizys)
  STB Lightspeed VL works, but has another mode (132x60) (ET4000) (Thomas E Zerucha)
  ftape 1.13b overrun ([email-masked])
  Re: 1+ Gig SCSI Drives (Thomas E Zerucha)
  Re: RFD: new moderated newsgroups (H. Peter Anvin)
  Re: Linux on Pentium P90 PCI---which motherboard? (H. Peter Anvin)
  Hayes ESP driver? (Chris D Fanning)
  Missing stdarg.h and (sort of) varargs.h (Stephen Vance)
  Re: Multiprocessing Pentium Systems (Huw Leonard)
  aha2940 driver.....almost (Mike Jerger)
  Re: ftape 1.13b overrun (Timothy Murphy)
  Re: BSD/386 vs. Linux Performance (Steven Pritchard)
  Re: Linux on Pentium P90 PCI---which motherboard? (Mike Cruse)
  Re: Missing stdarg.h and (sort of) varargs.h (Dan Pop)
  Re: RFD: new moderated newsgroups (Ahmed Naas)
  Re: elf benchmarks (getting closer) (H.J. Lu)
  Re: RFD: new moderated newsgroups (Jeff Kesselman)

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

Subject: Re: [STATUS] Linus Floppy Driver Development
From: [email-masked] (Steve Kneizys)
Date: 25 Sep 94 10:25:33 EST

Daniel Garcia ([email-masked]) wrote:
: Slaving away in a dark room, [email-masked] (Pyramids-R-Us) produced:
: >Aonther problem is that there is no simple way to mount a floppy.
: >The big question is 'where?'  since a floppy can be mounted on ANY
: >directory.  Also I don't want my unprivelged users to be able to mount

: What if they did something like on the sgi's, where you can specify 
: a mount point for dos disks, and run a daemon that will mount the floppy
: automagically (at least, for a dos disk).  Pretty neat though.  Perhaps
: if we had something like that for msdos disks only, all others needing
: to be mounted manually (therefore, by root)?

Sounds like a neat idea...if root starts such a daemon, then I like it!
Having msdos automount, but not minix, would solve much of the security
problem that I would run into.

Steve...

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

From: [email-masked] (Thomas E Zerucha)
Crossposted-To: comp.os.linux.misc
Subject: STB Lightspeed VL works, but has another mode (132x60) (ET4000)
Date: 25 Sep 1994 15:05:38 GMT

The STB Lightspeed VL is a really fast card based on the W32i/ET4000.
But I noticed it also has video mode 0x21 which adds 132x60 capability,
but this was not in the setup.S, though it was simple to add.

I remember asking for a card that supported 132x60 text and no one mentioned
this (Trident and Oak were the only others that I know supported this mode).

I am really pleased with this card.  It does DOS, Windows, and Linux - X
windows very fast and it coexists with my monochrome adapter and my 8514/a
card and doesn't require anything funny in the memory map.  It also seems to
have VESA modes in ROM.

People occasionally ask what video card to get.  They should definately
check out this card.  I paid just  under $200, which is the current street
price in my area.  (You may have other applications which would dictate
using a different card, so investigate your options - I am just saying I
know this card works for my application).
---
[email-masked] - main email address

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

From: [email-masked]
Subject: ftape 1.13b overrun
Date: 25 Sep 1994 11:30:46 -0400
Reply-To: [email-masked]

Date: Sun, 25 Sep 1994 17:03:58 +0000
From: Andre Couture <[email-masked]>
Sender: Andre Couture <[email-masked]>
Reply-To: Andre Couture <[email-masked]>
Subject: ftape 1.13b overrun
To: Bas Laarhoven <[email-masked]>
cc: "comp.os.linux.help" <[email-masked]>, 
    "comp.os.linux.development" <[email-masked]>
Message-ID: <Pine.3.89.9409251602.A3133-0100000@cyborg>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

I have installed the ftape1.13b, 
compiled ok, installed ok, ...

The problems are when I write to tapes, I get a lots of write errors and 
also a lots of overruns.

The tape has been formatted under DOS or Windows (CBWLITE) ? not too sure 
as my brother did it!

Is there any formatting tools comming up for Linux?

Does anybody experiencing the same problems?

My system is:
486dx50 EISA
20MB RAM
Adaptec 1742A (EISA-Enhanced mode)
Colorado 250MB attached to the floppy.
Quantum LPS525 HDD

OS Kernel 1.1.51

Here is some info from the messages file:

[005]    fdc-io.c (fdc_config) - FC-10 controller not found.
[006]    fdc-io.c (fdc_probe) - Type 82077 or compatible FDC found.
[007]    fdc-io.c (fdc_fifo_enable) - fifo already enabled, thresshold 0.
[008]   fdc-io.c (fdc_init) - FDC fifo successfully enabled.
[009]  ftape-io.c (_ftape_open) - drive wakeup method: Colorado.
[010]    ftape-io.c (ftape_report_raw_drive_status) - warning: error status

set!
...
[023]   ftape-io.c (ftape_report_error) - errorcode: 26.
[024]   ftape-io.c (ftape_report_error) - Non-Fatal ERROR:.
[025]   ftape-io.c (ftape_report_error) - Power On Reset Occurred ....
[026]   ftape-io.c (ftape_report_error) - ... caused by unknown command 0.
[027]  ftape-io.c (_ftape_open) - error code   : 26.
[028]  ftape-io.c (_ftape_open) - error command: 0.
[029]  ftape-io.c (_ftape_open) - status: new cartridge.
[030]   ftape-io.c (ftape_report_vendor_id) - got 16 bit id: 0047.
[031]   ftape-io.c (ftape_report_vendor_id) - CMS rom version: 87.
[032]   ftape-io.c (ftape_report_vendor_id) - CMS signature: a5.
[033]   ftape-io.c (ftape_report_vendor_id) - CMS status: 4.
[034]  ftape-io.c (_ftape_open) - ftape drive type is: Colorado
DJ-10/DJ-20.
[035]   ftape-io.c (ftape_set_data_rate) - Data rates set to 1 Mbps.
[036]   ftape-io.c (ftape_get_tape_parameters) - segments_per_cylinder 4.
[037]   ftape-io.c (ftape_get_tape_parameters) - segments_per_track 150.
[038]   ftape-io.c (ftape_get_tape_parameters) - segments_per_head 600.
[039]   ftape-io.c (ftape_get_tape_parameters) - sectors_per_segment 32.
[040]   ftape-io.c (ftape_get_tape_parameters) - tracks_per_tape 28.
[041]   fdc-io.c (fdc_init) - FDC fifo successfully enabled.
[042]    ftape-read.c (read_header_segment) - segments-per-track:   150.
[043]    ftape-read.c (read_header_segment) - tracks-per-cartridge: 28.
[044]    ftape-read.c (read_header_segment) - max-floppy-side:      6.
[045]    ftape-read.c (read_header_segment) - max-floppy-track:     149.
[046]    ftape-read.c (read_header_segment) - max-floppy-sector:    128.
[047]    ftape-read.c (read_header_segment) - first data segment: 2.
[048]    ftape-read.c (read_header_segment) - `last' segment is 4199, 29
Kb.
[049]    ftape-read.c (read_header_segment) - 121652 Kb usable on this
tape.
[050]     ftape-eof.c (extract_file_marks) - number of file marks: 10.
[051]     ftape-eof.c (extract_file_marks) - eof mark in segment 17, sector
10.
[052]     ftape-eof.c (extract_file_marks) - eof mark in segment 18, sector
1.
[053]     ftape-eof.c (extract_file_marks) - eof mark in segment 20, sector
17.
[054]     ftape-eof.c (extract_file_marks) - eof mark in segment 21, sector
1.
[055]     ftape-eof.c (extract_file_marks) - eof mark in segment 500,
sector 6.
[056]     ftape-eof.c (extract_file_marks) - eof mark in segment 501,
sector 1.
[057]     ftape-eof.c (extract_file_marks) - eof mark in segment 554,
sector 7.
[058]     ftape-eof.c (extract_file_marks) - eof mark in segment 555,
sector 1.
[059]     ftape-eof.c (extract_file_marks) - eof mark in segment 641,
sector 9.
[060]     ftape-eof.c (extract_file_marks) - eof mark in segment 642,
sector 1.
[061]   fdc-io.c (fdc_init) - FDC fifo successfully enabled.
[062]   fdc-io.c (fdc_init) - FDC fifo successfully enabled.
[063]   fdc-io.c (fdc_init) - FDC fifo successfully enabled.
[064]   ftape-write.c (_write_segment) - empty segment, nothing written.
[065]   ftape-write.c (_write_segment) - empty segment, nothing written.
[066]  fdc-isr.c (fdc_isr) - single overrun error.
[067]   fdc-isr.c (determine_progress) - Unexpected error at sector offset
0.
[068]     ftape-rw.c (ftape_smart_stop) - tape stopped passing segment: 12.
[069]   ftape-write.c (_write_segment) - write error, retrying (0).
[070]  fdc-isr.c (fdc_isr) - single overrun error.
[071]   fdc-isr.c (determine_progress) - Error at sector offset 2.
[072]   fdc-isr.c (retry_sector) - request skipping of 3 sectors.
[073]     ftape-rw.c (ftape_smart_stop) - tape stopped passing segment: 23.
[074]   ftape-write.c (_write_segment) - write error, retrying (0). 
[075]     ftape-write.c (copy_and_gen_ecc) - bad sectors in map: 1.
[076]           ftape-rw.c (setup_segment) - segment: 30, bad sector map:
000000
[077]        fdc-isr.c (fdc_isr) - single overrun error.
[078]         fdc-isr.c (determine_progress) - Error at sector offset 13.
[079]         fdc-isr.c (retry_sector) - request skipping of 15 sectors.
[080]     ftape-rw.c (ftape_smart_stop) - tape stopped passing segment: 31.
[081]       ftape-rw.c (setup_segment) - segment: 30, bad sector map:
00000040.
...
[244]  ftape-io.c (_ftape_close) - error: unable to update header segments.
[245]  ftape-io.c (_ftape_close) - == Non-fatal errors this run: ==.
[246]  ftape-io.c (_ftape_close) - fdc isr statistics:.
[247]  ftape-io.c (_ftape_close) -  id_am_errors     : 4.
[248]  ftape-io.c (_ftape_close) -  id_crc_errors    : 0.
[249]  ftape-io.c (_ftape_close) -  data_am_errors   : 0.
[250]  ftape-io.c (_ftape_close) -  data_crc_errors  : 0.
[251]  ftape-io.c (_ftape_close) -  overrun_errors   : 78.
[252]  ftape-io.c (_ftape_close) -  no_data_errors   : 9.
[253]  ftape-io.c (_ftape_close) -  retries          : 91.
[254]  ftape-io.c (_ftape_close) - repositions       : 90.
[255]  ftape-io.c (_ftape_close) - last segment      : 2251.
[000] kernel-interface.c (ftape_close) - _ftape_close failed.

=====
Andre Couture,
[email-masked] (prefered)
     _/_/_/_/  _/_/_/_/  _/_/_/_/         Centre Informatique Couture
    _/           _/     _/         938934 Ontario Inc.  Phone:
+1-613-762-0262
   _/           _/     _/          155 Queen St.        FAX:  
+1-819-775-9697
  _/           _/     _/           Suite 900            Roma: 
+39/6-5125-745
 _/           _/     _/            Ottawa, Ontario      Delphi:    
CoutureA
_/_/_/_/. _/_/_/_/. _/_/_/_/.

@receiver file

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

From: [email-masked] (Thomas E Zerucha)
Subject: Re: 1+ Gig SCSI Drives
Date: 25 Sep 1994 15:18:08 GMT

THE LIMIT ON DOS PARTITIONS IS 8.25GB NOT 1GB

The disk access (int13) allows for 512 byte sectors * 255 sectors * 63 heads
* 1023 Cylinders, which equals 8.25G.  (actually it is 64 heads and 1024 
cylinders since the size call for these asks for the last valid number and
these start at zero).

Not all drivers handle this properly (dos or linux)  The following
is a repost of an analysis I did:

I have noticed that many SCSI drivers don't implement biosparam correctly
for disks > 1G.  What follows is code that exactly duplicates the Qlogic
DOS driver's parameter returns.  It is possible that a DOS version of one
of the older drivers also cannot support >1G drives.  Here is the list:

Drivers that cannot go above 1GB (because they only support 64/32/<1024).

aha152x         aha1740         pas16           t128            wd7000

Drivers that implement large partitions (though may not do the 8Gb
truncation, and may not do exactly 1Gb partitions the same)

aha1542         buslogic

Drivers that have a custom system for determing this

fdomain         segate          ultrastor       53c7,8xx

The following is my code for this function and has been verified:
---cut here--- 
int                 qlogic_biosparam(Disk * disk, int dev, int ip[])
{
/* This should mimmic the DOS Qlogic driver's behavior exactly */
        ip[0] = 0x40;
        ip[1] = 0x20;
        ip[2] = disk->capacity / ( ip[0] * ip[1] );
        if( ip[2] > 1024 ) {
                ip[0] = 0xff;
                ip[1] = 0x3f;
                ip[2] = disk->capacity / ( ip[0] * ip[1] );
                if( ip[2] > 1023 )
                        ip[2] = 1023;
        }
        return 0;
}
---cut here---
Notes: The first three lines of the routine handle <= 1Gb partitions.
Since ip[2] is number of cylinders v.s. the dos call which returns the
largest cylinder, 1024 under Linux will be 1023 under DOS and will fit
in the appropriate API calls.  The code within the first if handles larger
disks.  Normal DOS cannot return cylinder numbers higher than 1023, so the
last if truncates it (notice that I duplicate the 1023 as used by the DOS
driver although 1024 would work).

Advanced DOS BIOSes can go up to 4096 cylinders.  I don't know if any SCSI
drivers allow this.  I also don't know if any DOS drivers only support <1Gb
SCSI disks, so adding the above code to a driver would confuse the DOS
side on such a card.  It is also possible that different drivers have a
different 1Gb or 8Gb cutoff.

---
[email-masked] - main email address

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

From: [email-masked] (H. Peter Anvin)
Subject: Re: RFD: new moderated newsgroups
Date: Sun, 25 Sep 1994 15:03:36 GMT

In article <[email-masked]>,
Jeff Kesselman <[email-masked]> wrote:
>
>Hold up a minute guys.  I've already posted the fact that a 'private 
>club' is inappropriate to USENET (IMO) BUT, your statements are a bit to 
>general for my tastes.  There ARE such things as moderated groups, where 
>the moderator decides which posts to pass on and which to kill,and they 
>ARE very useful things.  Its not censorship as you can always post your 
>note to some other group, or start your own alt. or even regular group IF 
>you want to go through the effort to get it to happen.
>

Agreed, in general.  But private clubs belong to mailing lists, not
newsgroups.

        /hpa

-- 
This message was sent from a system running Linux, the freeware UNIX
clone.  Get yours from tsx-11.mit.edu or sunsite.unc.edu.

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

Crossposted-To: comp.os.linux.misc
From: [email-masked] (H. Peter Anvin)
Subject: Re: Linux on Pentium P90 PCI---which motherboard?
Date: Sun, 25 Sep 1994 15:07:48 GMT

In article <[email-masked]>, Mike Cruse <[email-masked]> wrote:
>David S. Vickers ([email-masked]) wrote:
>
>We have five Gateway 2000 P5/90 machines with 32 megs ram, 2 Gig
>Segate barracuda SCSI drives, NCR53c825 PCI controllers, NEC
>Multispin 3X CD/Rom drives and ATI Mach 64 4 Meg video cards.
>Installation was not quite straight forward since everything
>was bleeding edge, but, they are very fast. Especially with
>the Barracuda drives. We are having some crashes though with 
>the 1.1.50 kernel, seems to be related to heavy network traffic.
>I do mean heavy. Anyway the machines are great except their 
>standard keyboards are very non (101 key) standard. They've 
>added things like diagonal cursor keys and one thing that really 
>sucks is that you can (very easily) accidentally put the KB in
>program/remap mode and totally confuse it and yourself.
>

Personally, I really like these keyboards.  They have an extra * key
between Ctrl and Alt which I use an Xmodmap to configure as the X
Super key (extra shift key; X supports Mode_shift, Shift, Alt, Ctrl,
Meta, Super and Hyper, but on PC keyboards generally Alt == Meta),
which I use for all my personal Emacs key bindings.

        /hpa

        

-- 
This message was sent from a system running Linux, the freeware UNIX
clone.  Get yours from tsx-11.mit.edu or sunsite.unc.edu.

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

From: [email-masked] (Chris D Fanning)
Subject: Hayes ESP driver?
Date: 21 Sep 1994 05:44:37 GMT

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

From: [email-masked] (Stephen Vance)
Subject: Missing stdarg.h and (sort of) varargs.h
Date: 25 Sep 1994 15:24:37 GMT

Has anyone noticed the conspicuous absence of stdarg.h?  Or that there is
a <sys/varargs.h> which tries to include a non-existant <varargs.h>?  This
is true of the 1.0.8 source tree as well as a 1.1.49 tree patched up from
a 1.1.29 base.  It sort of complicates a port I'm working on, but I'll
create one for everyone if I need to.

Steve

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

From: [email-masked] (Huw Leonard)
Subject: Re: Multiprocessing Pentium Systems
Date: Fri, 23 Sep 1994 18:44:49 GMT

In article <[email-masked]> [email-masked] (Mark Bolzern) writes:
>>I've just seen some new dual processor pentium systems in Computer
>>Shopper.  They look swell for the money, but there isn't a single OS
>>that can take advantage of them.  Anybody have any thoughts about how
>>hard it might be to make Linux one of the first OS's to take advantage
>>of these systems?

>Not quite true... SCO MPX will work with many of them.  But it would still
>be good to have Linux available......

WinNT works well on many multi-processor systems. IBM seems to be on the verge 
of releasing an SMP OS/2, as well. The problem, as I understand it, is that 
there is no firm multi-processor standard yet. The problem with working up an 
SMP or MPX version of Linux would be having to support all of the wierd 
variations of the architecture. Perhaps when manufacturers have a consistent 
standard, multi-processor Linux would be more feasable.

Is this opinion incorrect? Comments?

============================================================
Huw Leonard - Speaking only for himself

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

From: [email-masked] (Mike Jerger)
Subject: aha2940 driver.....almost
Date: 23 Sep 1994 16:34:13 GMT

I've been working on the 2940 driver.....it recognizes the card using
the pci stuff but apparently there are some other differences between
the 2940 and the 2740/2840 that I am not aware of.  The documentation
that I got from adaptec only defines the pci interface stuff.  If
anyone knows anything about this and want to play with the code, I
can mail it to you.

Mike

-- 
===============================================================================
It must suck to be you.

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

From: [email-masked] (Timothy Murphy)
Subject: Re: ftape 1.13b overrun
Date: 25 Sep 1994 17:22:14 +0100

[email-masked] writes:

>The problems are when I write to tapes, I get a lots of write errors and 
>also a lots of overruns.

>Does anybody experiencing the same problems?

I get the same overruns with my Colorado Jumbo
(with Linux 1.1.50 on a 386/25).

The difference is that ftape-1.13 is able to recover,
whereas earlier versions of ftape were not, in my experience.

My impression is that it is worse with tar than afio.

-- 
Timothy Murphy  
e-mail: [email-masked]
tel: +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland

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

From: [email-masked] (Steven Pritchard)
Subject: Re: BSD/386 vs. Linux Performance
Date: 25 Sep 1994 10:24:54 -0600

[email-masked] (Michael Nelson) writes:

>Anyone have any performance stats comparing BSD/386 (BSD/OS) with Linux?
>Network, disk, and overall...

Check out September's "Open Computing" p. 83.  The article sort-of 
compares BSD/386 and Linux to each other and to commercial unices.

Steve
-- 
[email-masked]             |  Steven
[email-masked]             |  Pritchard
GCS/M/S d? p+ c++(++++) l++ u+(-) e+ m+(---) s/+ !n h--- f+ g+ w@ t++ r- y?

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

From: [email-masked] (Mike Cruse)
Crossposted-To: comp.os.linux.misc
Subject: Re: Linux on Pentium P90 PCI---which motherboard?
Date: 24 Sep 1994 21:05:12 -0700

David S. Vickers ([email-masked]) wrote:

: [email-masked] (Vaughan R. Pratt) writes:
: >If Linux runs on your Pentium P90 PCI, or you know of a working such,
: >I'd appreciate knowing what motherboard did the trick.
: >-- 
: >Vaughan Pratt                        http://boole.stanford.edu/boole.html

We have five Gateway 2000 P5/90 machines with 32 megs ram, 2 Gig
Segate barracuda SCSI drives, NCR53c825 PCI controllers, NEC
Multispin 3X CD/Rom drives and ATI Mach 64 4 Meg video cards.
Installation was not quite straight forward since everything
was bleeding edge, but, they are very fast. Especially with
the Barracuda drives. We are having some crashes though with 
the 1.1.50 kernel, seems to be related to heavy network traffic.
I do mean heavy. Anyway the machines are great except their 
standard keyboards are very non (101 key) standard. They've 
added things like diagonal cursor keys and one thing that really 
sucks is that you can (very easily) accidentally put the KB in
program/remap mode and totally confuse it and yourself.

Mike Cruse

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

From: [email-masked] (Dan Pop)
Subject: Re: Missing stdarg.h and (sort of) varargs.h
Date: Sun, 25 Sep 1994 17:00:09 GMT

In <[email-masked]> [email-masked] (Stephen Vance) writes:

>Has anyone noticed the conspicuous absence of stdarg.h?  Or that there is
>a <sys/varargs.h> which tries to include a non-existant <varargs.h>?  This
>is true of the 1.0.8 source tree as well as a 1.1.49 tree patched up from
>a 1.1.29 base.  It sort of complicates a port I'm working on, but I'll
>create one for everyone if I need to.

No need to reinvent the wheel:

ues4:~/tmp 48> ls /usr/include/stdarg.h
ls: /usr/include/stdarg.h: No such file or directory
ues4:~/tmp 49> cat test.c
#include <stdarg.h>

main()
{
return 0;
}
ues4:~/tmp 50> gcc test.c
ues4:~/tmp 51> 

Mistery! /usr/include/stdarg.h does not exist, but gcc doesn't complain.
Have I just discovered a gcc bug?

NO. At the end of the gcc man page (but who's reading it that far? :-)
you can see:

       /usr/include       standard directory for #include files
       LIBDIR/include     standard gcc directory for #include files

So:

ues4:~/tmp 51> ls /usr/lib/gcc-lib/i486-linux/2.5.8/include/
README        stdarg.h      va-clipper.h  va-m88k.h     va-sparc.h
float.h       stddef.h      va-h8300.h    va-mips.h     va-spur.h
limits.h      syslimits.h   va-i860.h     va-pa.h       varargs.h
proto.h       va-alpha.h    va-i960.h     va-pyr.h

Good! gcc is not broken and stdarg.h and varargs.h are not missing.
No need to recreate them.

Dan
--
Dan Pop 
CERN, CN Division
Email: [email-masked]
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

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

From: [email-masked] (Ahmed Naas)
Subject: Re: RFD: new moderated newsgroups
Date: Sun, 25 Sep 1994 15:01:23 GMT

Jeff Kesselman ([email-masked]) wrote:

[Follow up directed to comp.os.linux.misc]

: general for my tastes.  There ARE such things as moderated groups, where 
: the moderator decides which posts to pass on and which to kill,and they 
: ARE very useful things.

Yes, they are. But let us see if they are needed in this case:

The main Linux developers have their own channels of communications, mainly
e-mail I suspect. A secondary channel is the linux-activists mailing lists,
which have fairly high S/N. C.o.l.development is a third tier channel for
every one to voice their view regarding Linux development issues. It might
get abused every now an then, like right now, but these are the hazards of
USENET.

All in all, I see no purpose served by a new set of moderated groups.

: Its not censorship as you can always post your 
: note to some other group, or start your own alt. or even regular group IF 
: you want to go through the effort to get it to happen.

There are enough superflous newsgroups already, why compound the problem?

-- 
The above is a result of random neuron activity in the writer's brain.
Ahmed M. Naas                                      [email-masked]
======================================================================

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

From: [email-masked] (H.J. Lu)
Subject: Re: elf benchmarks (getting closer)
Date: 25 Sep 1994 11:53:03 GMT

John Richardson ([email-masked]) wrote:
: As a quick followup to my very unscientific benchmark: 
:  
: The with the latest gcc (23-Sept) and the 4.6.11 elf libraries,  
: elf narrows the time gap to about a 3.5% difference using the qsort() test.

The ELF/PIC library may not be in core all the time. The ELF binary
may have to load it everytime it runs. Please re-compile your login
shell with ELF and then re-run the "benchmark." If that is the case,
ELF may be faster :-).

--
First I thought he was on hunger strike. Later I was told he was
praticing YanXin QiGong.

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

From: [email-masked] (Jeff Kesselman)
Subject: Re: RFD: new moderated newsgroups
Date: Sun, 25 Sep 1994 07:38:52 GMT

In article <[email-masked]>,
Laurent Julliard <[email-masked]> wrote:
>I second Stephen's opinion. Some guys need a little refresh about the 
>Internet philosophy...
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>WHOA!!!! What about the philosophy of openess and non-censorship on 
>internet??
>I would strenuously OPPOSE such a move. I WILL vote against it!!
>
>[email-masked]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
Hold up a minute guys.  I've already posted the fact that a 'private 
club' is inappropriate to USENET (IMO) BUT, your statements are a bit to 
general for my tastes.  There ARE such things as moderated groups, where 
the moderator decides which posts to pass on and which to kill,and they 
ARE very useful things.  Its not censorship as you can always post your 
note to some other group, or start your own alt. or even regular group IF 
you want to go through the effort to get it to happen.

Jeff Kesselman

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

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