Subject: Linux-Development Digest #305
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Fri, 14 Oct 94 05:13:06 EDT

Linux-Development Digest #305, Volume #2         Fri, 14 Oct 94 05:13:06 EDT

Contents:
  Are there GUI libraries? (Andrew C. F. Wong)
  Re: New Motif lib's for use with XFree 3.1 ? (Craig Groeschel)
  Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks) (Jeff Kuehn)
  Re: What is the Status of the Adaptec 2940W SCSI-3 support? (Drew Eckhardt)
  Re: Kernel 1.1.53 - no BOOM (Steven M. Doyle)
  Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks) (Dominik Kubla)
  Re: A badly missed feature in gcc (Thomas Koenig)
  Re: 3Com 509 Driver Problems - Any fixes - Help (Marden H Seavey)
  Re: We a FAQ: Linux vs. *BSD!!! (Brandon S. Allbery)
  PGP for Linux?? (Zack T. Smith)
  Re: Linux NOT logging people out on hangup (Bart Kindt)
  Login program crashes (Bart Kindt)
  Re: weird linux hangs 1.0.9 -> 1.1.51 inclusive... (Dave Perry VA3DP)
  Re: ext2fs vs. Berkeley FFS (Hugh Strong)
  Re: We a FAQ: Linux vs. *BSD!!! (Jordan K. Hubbard)

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

From: h9311310@hkusub (Andrew C. F. Wong)
Subject: Are there GUI libraries?
Date: Fri, 14 Oct 1994 00:06:12 GMT

Dear Linux-fans,

        Are there GUI libraries in C/C++ for Linux (non X)?

        Thanks!!!

Andrew

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

From: [email-masked] (Craig Groeschel)
Crossposted-To: comp.windows.x.i386unix
Subject: Re: New Motif lib's for use with XFree 3.1 ?
Date: 10 Oct 1994 14:34:51 -0400

In article <[email-masked]>,
Adam J. Richter <[email-masked]> wrote:
>We had an X11R6
>beta release that used a downward compatible version version number for
>its shared libraries and seemed to work fine with the R5 binaries that
>we tried.

"Seemed to work fine" or "was binary compatible"?  Big difference.

I don't know if it was decided to standardize on major number 6
for X11R6, or if the new libraries actually were not binary compatible.
I am curious to know.
-- 
Craig E. Groeschel  <[email-masked]>  Not speaking for my employer.
"Do not play this piece fast.  It is never right to play Ragtime fast." Joplin
GCS/E g+ s+/- au* v+ C+ P->+ L+++ U@ u+++ E---(+) N+ !W Y+ t++ b+ e- n++ h* f

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

From: [email-masked] (Jeff Kuehn)
Subject: Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks)
Date: 13 Oct 1994 21:47:08 GMT

Shaune Beattie ([email-masked]) wrote:
: Hmm, think something might have gone wrong with your benchmarks... (the 
: concurrent shell scripts that is). After reading your post I downloaded 
: the byte benchmarks and ran them myself.
: 1) Before I get flamed I am *NOT* posting this as a childish 'my machine 
: is faster than yours thing' but rather that I believe something to be 
: wrong with the ones you posted.
: Ok, the bechmarks were run on a P90-512k cache 16Meg PCI micronics mb 
: conner 540M EIDE hd running kernel version 1.1.53. Both the kernel and 
: the benchmarks were compiled using the pentium gcc with as much 
: optimisation as possible. (nb. if anyone is interested i will post the 
: benchmarks for 486 optimised code to show the gain in using the pentium 
: gcc, in fact surpisingly little).
: I indexed the results against the results you posted for the 1.1.0 kernel 
: for comparrision.

:                      INDEX VALUES            
: TEST                                        BASELINE     RESULT      INDEX

: Arithmetic Test (type = double)               5069.5    11922.9        2.4
: Dhrystone 2 without register variables       56103.3   129726.8        2.3
: Execl Throughput Test                           60.8       82.2        1.4
: File Copy  (10 seconds)                       1310.0     1974.0        1.5
: File Copy  (30 seconds)                        919.0     1865.0        2.0
: File Read  (10 seconds)                     117181.0   224933.0        1.9
: File Read  (30 seconds)                     117335.0   230322.0        2.0
: File Write (10 seconds)                      13856.0    10039.0        0.7
: File Write (30 seconds)                      13643.0    15055.0        1.1
: Pipe-based Context Switching Test             8197.6     8683.4        1.1
: Process Creation Test                          112.1      176.8        1.6
: Shell scripts (1 concurrent)                    81.1      160.9        2.0
: Shell scripts (2 concurrent)                     1.0       84.3       84.3
: Shell scripts (4 concurrent)                     1.0       41.0       41.0
: Shell scripts (8 concurrent)                     1.0       20.0       20.0
:                                                                  =========
:      SUM of 15 items                                                 165.2
:      AVERAGE                                                          11.0

: ok, first off, obviously most of the tests are faster by ~2 times... 
: (would have expected slightly more... but thats benchmarks for you :)
: the sole reason I'm posting this is to draw your attention to the Shell 
: scripts 2,4,8... a factor of 2 is to be expected... but there is *NO* way 
: my machine is 80 times faster than yours... I really think something 
: might have gone astray there. Just that if you are spending time 
: comparing kernel speeds (a task I don't envy after only running the 
: benchmark 3/4 times) then it might be wise to look into this.

David Niemi and I have been sharing a similar discussion.  We have yet to
be able to pin-point just where the problem might be regarding the
differences we're seeing.  I will post as soon as we have some speculation
about what might be happening to produce such poor results in the cases I've
run versus those he has run.  I've been worried up till now since all of the
benchmark results I've seen except David's indicate there is a problem. 
But now I have two independent confirmations that the shell results are
not necessarily correct.  (balanced by several results to the contrary as
well)  I intend to keep looking until the disparity can be adequately
explain/understood.  Hopefully my results are incorrect: an easily remedied
result of a systematic error.  The problem is that we haven't been able to
find the problem yet.

Which version of the libraries/compiler/ld.so/shell are you using?

Thanks to all the folks who are running the benchmark as well.  This is a
time consuming process and you all deserve a share of the credit!

--Jeff

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

From: [email-masked] (Drew Eckhardt)
Crossposted-To: comp.os.linux.help
Subject: Re: What is the Status of the Adaptec 2940W SCSI-3 support?
Date: 13 Oct 1994 22:18:05 GMT

In article <[email-masked]>,
Phil Andrew <[email-masked]> wrote:
>In article <[email-masked]>,
>       [email-masked] writes:
>>In comp.os.linux.development, Wigs ([email-masked]) wrote:
>>
>>> Could the people in the know please forward any information they have on
>>> this.
>>
>>-> Projects-Map on sunsite.
>>
>
>Well, since Adaptec will not even release details of the lowly 2940, I do
>not think they will be too pleased about doing so for the 2940w.

This is only partially true -

        1. Adaptec will not release programming details regarding
            the interface to their microcode without a NDA, but 
            you _can_ write your own.

        2. Adaptec will release full programming details on the board
            and chip.

        3. Adaptec's technical support often lies about the second fact,
            suggesting that a NDA is required and refusing to let you
            speak with the supervisor.

>I really do not think that there is a lot of demand for support at the
>moment.

A survey done some time ago suggested that there were 200,000-400,000
Linux users.  

>However, if I am wrong on this, and anyone has written a driver for either
>card, I would be most grateful to know about it,

A driver has been written for the 274x and 284x boards, and seems to 
be reasonably stable.  Some one is currently modifying it to grok 
the 2940 boards.

-- 
Since our leaders won't respect The Constitution, the highest law of our 
country, you can't expect them to obey lesser laws of any country. 
Boycott the United States until this changes.

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

From: [email-masked] (Steven M. Doyle)
Subject: Re: Kernel 1.1.53 - no BOOM
Date: 12 Oct 1994 13:50:30 -0700

In <[email-masked]> [email-masked] (Mark A. Horton KA4YBR) writes:
>Console: colour EGA+ 132x44, 24 virtual consoles
>Serial driver version 4.00 with no serial options enabled
>tty00 at 0x03f8 (irq = 4) is a 16550A
>tty01 at 0x02f8 (irq = 3) is a 16550A
>tty02 at 0x03e8 (irq = 4) is a 16550A
>tty03 at 0x02e8 (irq = 3) is a 16550A

One interesting point is the sharing of IRQ's between tty0/2 and tty1/3.  This may
be causing part of your problem (only thing I can suggest not knowing exactly how
your link is set up)

Good luck.
-- 
| Steven Doyle, AKA World Creator   | #include <std_disclaimer>              |
| Sysop, NETDimension (818)592-6279 | For information on Artificial Worlds   |
| [email-masked]               | send email to [email-masked] for  |
| [email-masked]        | an information package.                |

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

From: [email-masked] (Dominik Kubla)
Subject: Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks)
Date: 14 Oct 1994 02:58:57 GMT

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

   Shaune Beattie ([email-masked]) wrote:

   : ok, first off, obviously most of the tests are faster by ~2 times... 
   : (would have expected slightly more... but thats benchmarks for you :)
   : the sole reason I'm posting this is to draw your attention to the Shell 
   : scripts 2,4,8... a factor of 2 is to be expected... but there is *NO* way 
   : my machine is 80 times faster than yours... I really think something 
   : might have gone astray there. Just that if you are spending time 
   : comparing kernel speeds (a task I don't envy after only running the 
   : benchmark 3/4 times) then it might be wise to look into this.

   [...]

   Which version of the libraries/compiler/ld.so/shell are you using?
                                                 ^^^^^
That is the point. Usually under linux /bin/sh is linked to /bin/bash.
But imagine if it was either pdksh,ash or a stripped down bash (that is
using config.h.mini resulting in a bash w/o history and readline) or
even a zsh. That will make a lot of difference.
I think that the library or the compiler are only do little to the
performance (but i might be wrong). I am not so sure about ld.so ...

   Thanks to all the folks who are running the benchmark as well.  This is a
   time consuming process and you all deserve a share of the credit!

What about using the SPEC benchmark ? v1.2 is available on FTP. I will try to
run the suite over the weekend.

Dominik

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

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

From: [email-masked] (Thomas Koenig)
Subject: Re: A badly missed feature in gcc
Date: 12 Oct 1994 20:34:35 GMT
Reply-To: [email-masked]

Ian McCloghrie ([email-masked]) wrote in comp.os.linux.development,
        article <ianm.781991694@eldritch>:

>Even more fun is the difference between NULL.  Used to be, in K&R,
>that NULL was defined as "0".  In ANSI, it's defined as "(void *) 0".

This turns out not to be the case.

I'd suggest reading the comp.lang.c FAQ, which explains it
quite clearly.
--
Thomas Koenig, [email-masked], [email-masked].
The joy of engineering is to find a straight line on a double
logarithmic diagram.

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

From: [email-masked] (Marden H Seavey)
Crossposted-To: comp.os.linux.help
Subject: Re: 3Com 509 Driver Problems - Any fixes - Help
Date: 13 Oct 1994 22:27:48 GMT

Stanley Owen Jester ([email-masked]) wrote:
: Will  a 3c501 card work with Linux sllackware 2?
: I know it is old, but it is for home, so I won't need much horsepower.
The 3c501 is not supposed to work with Linux.  See the hardware FAQ.

What we have just found, however, is that the 3c503 card Rev C WILL NOT WORK!
3c503 Rev A DOES work, but 3COM won't supply it anymore, just the Rev C.  We
tried this on SCO UNIX too.  Don't get the Rev C of the 3c503 card.

Marden Seavey
[email-masked]

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

Crossposted-To: comp.os.386bsd.development,comp.sys.unix
From: [email-masked] (Brandon S. Allbery)
Subject: Re: We a FAQ: Linux vs. *BSD!!!
Date: Thu, 13 Oct 1994 21:48:20 GMT

In article <[email-masked]>, [email-masked] (Tony Porczyk) says:
+---------------
| [email-masked] (Jesus Monroy Jr) writes:
| >     Can we get together and write a single FAQ on this?
| Outstanding idea.
+------------->

My suggestion:

Q: Which is better, Linux or FreeBSD?

A: Neither is intrinsically "better".  The answer is the same as for any
   operating systems X and Y:

        1. Does it do what you need?  If not, don't waste your time on it.
           (This one probably doesn't matter for FreeBSD vs. Linux.)

        2. Are the programs and/or device drivers you need available?

        3. Assuming you've found some OSes that pass the above two, try them
           all out.  Use them for as long as practicable, preferably for
           several weeks apiece.

        4. If one of them does what you need more easily (this includes
           administration and usage), prefer it.

        5. If it's easier to get support for one than the other locally,
           all other things being equal, use it.  (That is, if you have no
           local Linux gurus but have a FreeBSD expert around, you are better
           off using FreeBSD, all other things being equal.)

        6. If they're all about equal, use the one which *you* find easiest
           to work with.  Don't pay attention to your friends or the Usenet
           (or IRC, etc.) on this one; the question is which one you
           *personally* find easiest to work with --- after all, who will be
           using your installation, you or them?

        7. If you still can't decide, try repeating the above with stricter
           guidelines.

        8. Still can't decide?  You're unlikely to get this far without
           deciding on one, but if you do you might as well flip a coin.
           ---But if you really haven't got a personal preference at this
           point you're probably a computer yourself :-)

(The unstated point being that, insofar as technical merits are concerned,
they're basically equal.)

++Brandon
-- 
Brandon S. Allbery KF8NH         [44.70.4.88]           [email-masked]
Linux development:  iBCS2, JNOS, MH                                      ~\U
Waiting For Godot^H^H^H^H^HRothenberg

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

From: [email-masked] (Zack T. Smith)
Subject: PGP for Linux??
Date: Mon, 10 Oct 1994 18:07:16 GMT

Hi,

Can anyone tell me whether PGP (the encyption utility) been ported Linux?
I haven't been able to find it in the archives...

Thanks,

Zack Smith

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

Crossposted-To: comp.os.linux.admin
From: [email-masked] (Bart Kindt)
Subject: Re: Linux NOT logging people out on hangup
Date: Fri, 14 Oct 1994 06:02:31 GMT

In article <[email-masked]> [email-masked] (Jaye Mathisen) writes:

>In article <[email-masked]>,
>Joe Beiter <[email-masked]> wrote:
>>
>>We have a network of 5 linux systems running .47 and .50 with three
>>being used as dialup systems (with digiboards).
>>
>>Since each has 8 modems on them we are finding this problem to be both
>>valid and *very* annoying. Our latest suspect is bash but we're pretty
>>baffled.

>I'm having the same problem with bash processes (and lynx) on a BSDI/386
>box as well.  I haven't a clue as to why they're not getting killed.

I am running a multi-line SLIP dialin server. For months we have had problems 
that sometimes the "sliplogin" program was not getting killed.  We finally 
found that the problem is in the Kernel " close() " function; this function 
does sometimes *not return*.  We have fixed the problem with a patch that 
re-kills the program after a 15 second timeout, when it is still 'alive'. The 
problem is definately in the kernel, but we have never found anybody who could 
do something about it.  Our dirty patch keeps our system online, but does not 
fix the root of the problem.  You problem could very well be the same.

====================================================================================
Bart Kindt (ZL4FOX) System Operator, Efficient Software NZ LTD, Dunedin, New Zealand
====================================================================================

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

From: [email-masked] (Bart Kindt)
Subject: Login program crashes
Date: Fri, 14 Oct 1994 06:12:42 GMT

Hi.  I am running a multi-line SLIP dial-in server.

Sometimes when a user dials in, and it goes wrong, the LOGIN program, which is 
executed by Mgetty, crashes.  It stays active forever, and the modem stays 
on-line as well.  When I Kill the login program,  Mgetty gives a heavy error 
on the main virtual terminal (something like: cannot initialise port, 
operation aborted) after which it goes full cycle and starts again, and resets 
the modem. All hunky dory after that.
When login hangs, and I give a 'ps', I see often:   ... login +++     Which is 
a typical modem escape code as the 'login name'.  Sometimes I have two lines 
of junk...

The login program I am using came with the Slackware 1.2 distribution.

Anybody knows of any later versions of Login may have solved this problem?

Can you please reply by E-Mail, 

Thanks,

====================================================================================
Bart Kindt (ZL4FOX) System Operator, Efficient Software NZ LTD, Dunedin, New Zealand
====================================================================================

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

From: [email-masked] (Dave Perry VA3DP)
Subject: Re: weird linux hangs 1.0.9 -> 1.1.51 inclusive...
Date: Thu, 13 Oct 1994 17:44:22 GMT

Michael Clarkson ([email-masked]) wrote:

: Looking at  the postings relating to this problem, it appears that the
: connecting piece of hardware is the NE2000 Ethernet Card. In fact we seem
: to have crudely fixed the problem by , by slowing down the reads/writes
: performed by the Network Card.

What do you mean by this? Did you define REALLY_SLOW_IO? Something else?

: If anyone else could suggest a better fix, please let me know.

FWIW, our system is closing in on 12 days of uptime since replacing the NE2000
with a 3c509. 
--
Dave Perry VA3DP     | Any opinions expressed here are mine and are not
[email-masked] | necessarily those of Carleton University.
                     | "Moo-ahhhh" - FZ

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

From: [email-masked] (Hugh Strong)
Subject: Re: ext2fs vs. Berkeley FFS
Date: 10 Oct 1994 19:04:18 GMT

Peter Mutsaers ([email-masked]) wrote:
: >> On 10 Oct 1994 14:50:20 GMT, [email-masked] (Hugh Strong) said:

:   HS> For instance, to open the main (data) fork of a file, one
:   HS> might write

:   HS>                 fd = open("MyDataFile",O_RDONLY);

:   HS> The icon (for a window manager) for the file could be
:   HS> accessed by the following call.

:   HS>                 fd1 = open("MyDataFile:ICON",O_RDONLY);

:   HS> The state of an editing session on the file could be
:   HS> saved in yet another fork

: This will break existing code; there are programs that assume that ':'
: is part of a filename. The *only* character that cannot be part of a
: filename is the '/', which is the directory separator.

You are suggesting a better notation, in all likelyhood.  Still,
can you tell me what program makes use of this wonderful feature, or
is it just a problem of how a few users name their files? 

: So the only way to go is to create a directory with files in it that
: belong together. It has been that way since the beginning. What is
: wrong with that.

Everything, if you wish to give files attributes.
UNIX programs read and write *files*, not directories.
This *would* break existing code, if we were to suddenly start 
using separate directories to store little bits of fluff associated
with each file.  Forks are for storing information that pertains
to a particular file, not for keeping separate but related
data sets together in one large file.

Really, keeping everything the way it was in My Father's Time for
the pure simple joy of it is not a good idea.

: It is basic in the Unix philosophy that files are untyped and that the
: kernel does not care what is in the file. Adding such things is
: completely against the Unix way of thinking.

Forks are untyped and unstructured as well.  Nothing should prevent
you from writing any arbitrary chunk of data into a fork, except
lack of priveledges.  

: Of course, if you want to mount filesystems that have such 'compound'
: files, you could map them in the Unix filesystem hierarchy as
: directories that contain the various components of this file. Then all
: existing programs (like cp, mv) can work without any change.

:   HS> I believe that NTFS handles extended attributes in a similar way.

: Unix *should not* handle attributes. Giving meaning to the different
: files is up to the (user space) programs.

The ext2fs already does.  These are kernel mode extensions, and I
don't think that they are such Bad Things.  But I am talking about
forks which would be read and written entirely by USER mode code.  
In particular, I gave two examples of things that could be 
done in user mode.  

I think that forks offer a simple and consistent way
to associate arbitrary data with files.   

: -- 
: Peter Mutsaers                  |  AT Computing bv,  P.O. Box 1428,
: [email-masked]                    |  6501 BK  Nijmegen, The Netherlands
: tel. work: +31 (0)80 527248     |
: tel. home: +31 (0)3405 71093    |  "... En..., doet ie het al?"

                                        -- Hugh Strong
                                        [email-masked]

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

From: [email-masked] (Jordan K. Hubbard)
Crossposted-To: comp.os.386bsd.development,comp.sys.unix
Subject: Re: We a FAQ: Linux vs. *BSD!!!
Date: 13 Oct 1994 11:28:45 GMT

In article <[email-masked]> [email-masked] (Jesus Monroy Jr) writes:

           This is a weekly question.
           More often than not, we get into a flame war
           on this.  Let's stop this silliness!!!

The only way we're going to stop this silliness is to simply start
ignoring the querants.  If someone asks "Which is better?  Which is
better?", jumping up and down all the while, and everybody just flat
out _ignores_ the question and goes about their business as if nothing
happened, folks will eventually get the point and stop asking.

Consider carefully: It's not the questions that start the bloody flame
wars, it's everyone's pathetic attempts to answer!  "Well, xxx is
better because of yyy.."  "No it's not!"  "Yes it is, you moron!  Just
look at blah blah blah!"  "Well, you're a complete idiot who obviously
wouldn't know an operating system if it bit you - yyy is _obviously_
better because bleh bleh bleh!".  And so downhill it goes from there.

No FAQ will ever satisfy the two sides, and would rapidly become
obsolete even if it did.  Dave Burgess's FAQ _tries_ to answer this
question about as well as any FAQ could, and people still aren't
remotely satisfied.  One German magazine reviewer who compared FreeBSD
to Linux ended up making an unfavorable judgement of FreeBSD because
_it didn't have enough shells_ bundled in by default!  He completely
ignored the other issues, he just wanted his bloody tcsh to be happy.
This almost perfectly exemplifys the average querant - they don't
really want to know which is better in general (as if "better in
general" meant anything anyway), they want to know which is better for
THEM, and how the hell are we supposed to know that?

           The distraction is overwhelming and we need a solution.

The solution is obvious, and in right front of our faces.  Don't even
bother with such questions.  Ignore them.  If you're dead-set on
answering questions, then there are PLENTY of more worthy questions
posed every single day that could use meaningful answers.  Why waste
time with people who only want to know which brand gives you whiter
teeth, fresher breath, cures acne or gets out those nasty grass
stains?  Such people are better off watching daytime television talk
shows or reading "USA Today" anyway ("Today on Sally Jesse Rafael,
we'll be asking the question "Which is better?  Linux or FreeBSD?",
and we'll also be interviewing 3 truck drivers who like to do long
cross-country trips with live hamsters in their shorts.")

Sheesh!

                                        Jordan

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

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