Subject: Linux-Development Digest #314
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sat, 15 Oct 94 21:13:07 EDT

Linux-Development Digest #314, Volume #2         Sat, 15 Oct 94 21:13:07 EDT

Contents:
  Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks) (Jeff Kuehn)
  Re: Kernel 1.1.53 - no BOOM (Larry Butler)
  Re: LINUX Logical volumes (Dennis Heltzel)
  Re: We a FAQ: Linux vs. *BSD!!! (Jesus Monroy Jr)
  Re: We a FAQ: Linux vs. *BSD!!! (Jesus Monroy Jr)
  Re: Anyone working on improving NFS? (Amrik Thethi)
  Re: We a FAQ: Linux vs. *BSD!!! (Jesus Monroy Jr)
  Re: ext2fs vs. Berkeley FFS (Basile STARYNKEVITCH)
  Re: ext2fs vs. Berkeley FFS (ron house)
  Re: New Motif lib's for use with XFree 3.1 ? (Daniel Supernaw-Issen)

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

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

Dominik Kubla ([email-masked]) wrote:

: 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

The problem has been found.  The version of time(1) on my slackware 2.0 system
produces output which is not compatible with one of the awk(1) scripts used to
do the benchmark's data reduction (loopm.awk).  Because this awk script wasn't
correctly parsing the timing, it was incorrectly reporting the number of loops
per minute as 1.0.  The problem should only have affected the shell tests as
only those are reduced with this particular awk script.

I'll be rerunning the tests this weekend so I can put out corrected results
early next week.

My apologies for any wild goose chases I've started w.r.t. scheduler
problems.  (see why the subject is, "Lies,..." :-)

Thanks to David Niemi and Shaune Beattie for checking results.  Hopefully
this is the only error.

--Jeff Kuehn, NCAR/SCD

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

From: [email-masked] (Larry Butler)
Subject: Re: Kernel 1.1.53 - no BOOM
Date: 14 Oct 1994 07:10:19 GMT

In article <wcreator.781994946@kaiwan009>,
Steven M. Doyle <[email-masked]> wrote:
>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)
>

This may be stupid, but I was wondering why the interrupt handler can't
check for received data in both UARTs. If it is possible to poll the UARTS
why can't this be done? Would it make the interrupt handler too time
consuming?

Just a thought,
Larry

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

From: [email-masked] (Dennis Heltzel)
Subject: Re: LINUX Logical volumes
Date: 14 Oct 1994 00:39:04 -0000

Richelo Killian ([email-masked]) wrote:
: Is it posible to create logigal volumes across drives and/or partitions and then mount a single filesystem on that volume? I know it can be done on HP-UX, but I want to do it on my LINUX box?

I've used logical volumes on IRIX a little. Worked pretty nice. I don't 
know if it would be worth the trouble to implement. Perhaps someone will 
write it as an optional add-on to an existing FS, so only people who 
really want it need to incur the overhead & risk.

On a related note, I am S/A on a UNIX system that implements "transaction 
logging" (I'm sure it is called something else on other unices). This is 
really great for data integrity and actually improves performance. The 
basic system is that all FS writes are made to a special log partition as 
change records. A daemon uses these records to update the FS and then 
mark the record as deleted. This works in a sort of circular queue, with 
the daemon monitoring disk activity to only do FS writes when the drives 
are quiet or the queue is near capacity. The system boot sequence checks 
this partition and performs an update to the FS for all records in the 
partition. This means that a power failure only endangeres those changes 
not written to the log partition. Writes to the log partition are not 
buffered and are rather small and require little head movement. 
Obviously, all reads must go through this system also to detect and 
correct reads from blocks affected by logged records. I know this is not 
trivial to implement, but it works great, fsck doesn't even need to be 
run on a FS like this after a crash. It requires minimal extra disk space 
and greatly enhances the logical integrity of the FS.

Just my $.02

Dennis

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

Crossposted-To: comp.os.386bsd.development,comp.unix.bsd
From: [email-masked] (Jesus Monroy Jr)
Subject: Re: We a FAQ: Linux vs. *BSD!!!
Date: Sat, 15 Oct 1994 20:58:49 GMT

Ken Hughes ([email-masked]) wrote:
: Jordan K. Hubbard ([email-masked]) wrote:
: : 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.
:
:       :: [deleted counter arguement] ::
:
: 386BSD-1.0", so please don't start THAT thread again either).  IMHO, the
: only chance for resolving this issue would be for someone to sit down and
: compile a list of features that shows which OS has what and which doesn't.
:
        This is another good idea.
        A list of features.. is always asked for.

: However, there's little hope of keeping this list up to date give the state
: of change of each OS, unless someone is willing to form a team for this
: purpose.  
:
        I disagree, Dave Burgess did a great job on the 
        "NET/2 *BSD" FAQ, so I believe an appropriate person
        should be nearby.   I'm not saying Dave should do it
        (he's to busy), but I can bet there such a person 
        available.... a neutral to alll parties.

: I wonder how the Windows-DOS-OS/2 people react to these questions?  Does
: anyone ever ask over in those groups?  Or is everyone there resigned to the 
: fact that OS/2 is best or Windows is best or Chicago/Windows 95 will be best
: or that they're all SOL?  :-)
:
        Good point.
        Should we extend the discussion to the other groups?
        
        Do I hear a Yeah on this call?

-- 
Jesus Monroy Jr                                          [email-masked]
Zebra Research
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________

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

Crossposted-To: comp.os.386bsd.development,comp.unix.bsd
From: [email-masked] (Jesus Monroy Jr)
Subject: Re: We a FAQ: Linux vs. *BSD!!!
Date: Sat, 15 Oct 1994 21:03:34 GMT

Andreas Helke ([email-masked]) wrote:
: Ken Hughes ([email-masked]) wrote:
: : I wonder how the Windows-DOS-OS/2 people react to these questions?  Does
: : anyone ever ask over in those groups?  Or is everyone there resigned to the 
: : fact that OS/2 is best or Windows is best or Chicago/Windows 95 will be best
: : or that they're all SOL?  :-)

: You only have to look at the multiple 100 post flamewars that regulary come
: up in comp.os.ms-windows.advocacy. The Windows solution is simply to assign
: a special newsgroup for this discussion.
:
        The "Windows solution"... it sounds like an oxymoron.

        Sorry, that's a low shot, but we need to go beyond
        the convention, because it is efforts (and good technical
        threads -- like this one is becoming) that will 
        lead people back to *BSD and LINUX and not the 
        a solution that does not benifit ourselves.

-- 
Jesus Monroy Jr                                          [email-masked]
Zebra Research
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________

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

From: [email-masked] (Amrik Thethi)
Subject: Re: Anyone working on improving NFS?
Date: Thu, 13 Oct 1994 12:38:43 GMT

In article <[email-masked]> [email-masked] (Matthew D Stock) writes:
>Hi.  Is anyone currently working on improving NFS under Linux?  If I
>remember correctly, one of the big reasons it has performance problems is
>because the caching is done using disk geometry information, which NFS
>doesn't have.
>
>Is my information out of date?  In any case, I'm interested in wokring on
>the problem, so if you have information on where I should start, please let
>me know.

The latest kernels (> 1.1.50 I think) have a simple static 5 block cache
in the NFS client. This improves average performance significantly (~50%).
It is still not multi-threaded in anyway, so multiple processes using
NFS filesystems will be seriously hit.

I think the plan is to modify the system cache so that it can be used
with NFS, but this wont happen before 1.2. Also the client code must be
made muli-threading if you want decent muli-user performance,
I don't know if there are any plans for that.
-- 
Amrik Thethi.                   Tel. +223 421 008 Fax. +223 421 024
Setanta Software Ltd.           Internet: [email-masked]
Cambridge, UK.

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

Crossposted-To: comp.os.386bsd.development,comp.unix.bsd
From: [email-masked] (Jesus Monroy Jr)
Subject: Re: We a FAQ: Linux vs. *BSD!!!
Date: Sat, 15 Oct 1994 21:14:28 GMT

Jordan K. Hubbard ([email-masked]) wrote:
: In article <[email-masked]> [email-masked] (Ken Hughes) writes:
:    Normally I would agree, but in this case I doubt that ignoring the
:    questions will stop them from being asked.  New people come into these

: Read what I said more carefully, please.  I didn't propose to stop the
: questions, I simply proposed to stop the answers.  The questions will
: keep coming in, but will "quench" themselves far more quickly if
: people simply ignore them.  We're always going to have this question,
: there's no doubt, so the best we can do is try to minimize the amount
: of damage it does.
:
        Jordan,
                please consider the damage that a newbie could
        do, if they answered the question.  That alone should
        convince you of the unsoundness of your idea.  

        Yes, there is a big problem with this idea, but we have
        a bigger problem.  That is, I'm tired of agruing with
        you (and a hunderd) other converts (sp?).  I know for
        a fact I can't get you to do the 386bsd thing with me,
        so why should I bother.   By the same token, I am not
        going to allow you to "bad-mouth" 386bsd.  Given the
        oppertunity (sp?) I will continue.   You know my staying
        power in this issue and we won't have any winners in
        an on going "flame-war".   This is a good solution 
        so that we my go back to work.    Mind you, next week
        I'm interviewing for a job of about $70K.  I won't fight
        you, but I can sure make it so you can't win.... 

                resort to reason... rethink your strategy.

:    386BSD-1.0", so please don't start THAT thread again either).  IMHO, the
:    only chance for resolving this issue would be for someone to sit down and
:    compile a list of features that shows which OS has what and which doesn't.

: I don't agree.  As you seem to concur, the FAQ will be out of date and
: essentially useless far too rapidly to make the effort of writing it
: anything but a wasted one.
:
        If you re-read my original statement, I said each appropriate
        group would maintain their respective portion of the FAQ.
        If you're going to have problems updating a simple FAQ list,
        how in the hell to plan to manage 4 terabytes of data ( the
        virtual space of a Pentium).

-- 
Jesus Monroy Jr                                          [email-masked]
Zebra Research
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________

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

From: [email-masked] (Basile STARYNKEVITCH)
Subject: Re: ext2fs vs. Berkeley FFS
Date: 11 Oct 1994 18:10:55 GMT

>>>>> "Albert" == Albert D Cahalan <[email-masked]> writes:
In article <[email-masked]> [email-masked] (Albert D. Cahalan) writes:

(about  structured files with forks -making them dirs.)

    Albert> 1: File operations do not work the same.  Try gzipping a
    Albert> directory without tar. 

    Albert> 2: There is no way to recognize  these directories as
    Albert>     complete units. 

    Albert> 3: File managers will open them as directory trees, 
    Albert>     because that is what they are, NOT record type files.  --

I agree on that.

However, i would like to say (with other people) that this is the Unix
way of doing. This is not neccesarily a good thing. The Unix plain
byte-stream file paradigm is outdated for todays needs.

But a more structured file paradigm requires IMHO a complete rewrite
of all the operating system:

1) Obviously, the kernel must change -not only the filesystem layers,
but also new (or extended) system calls to manipulate file structure.

2) Reasonably, the executable format of programs should take advantage
of such structured files (and looking into recent executable or object
formats such as ELF or perhaps COFF easily advocates the need of
structured files).

3) Hence, the execution model (ie the execve call or its successors)
should also change.

4) all IO libraries should support the better IO model.

5) perhaps the languages should better support a structured IO model.

6) Probably, there won't be a universally agreed upon file (meta)
structure. Hence, there should be several kind of files; this
advocates file servers and microkernel techniques.

(perhaps TRON model of files -which contains stream of either bytes or
filetables like directories- might be interesting).

This won't be Unix anymore. this won't be Linux neither.

It is time to wait for Hurd or VSTa...

-- 

Basile STARYNKEVITCH   ----  Commissariat a l Energie Atomique
([email-masked])
-only my opinions-
---

--

Basile STARYNKEVITCH   ----  Commissariat a l Energie Atomique
DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France
fax: (33) 1- 69.08.23.81;    phone: (33) 1- 69.08.40.66
email: [email-masked];  homephone: (33) 1- 46.65.45.53

N.B. Any opinions expressed here are solely mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.

Please cite a small part of my mail in all answers
Veuillez citer une petite partie de mon courrier dans vos reponses

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

From: [email-masked] (ron house)
Subject: Re: ext2fs vs. Berkeley FFS
Date: Fri, 14 Oct 1994 07:29:17 GMT

[email-masked] (Peter Mutsaers) writes:

>Unix's idea of plain byte-streams has been very successful and
>provides a lot of flexibility because assumptions on the contents of
>files are put into user space. I see no recent developments whatsoever
>that have changed such needs and have outdated this paradigm.

I agree. I once calculated how many distinct file types were
available on the HP3000 under MPE. I don't remember the number,
but it was in the millions of trillions when you combined all
possible parameter values. The most obvious characteristic of
that OS was its bugginess when you wanted to put something in
a file that HP hadn't anticipated.

--

Ron House.             USQ
([email-masked])     Toowoomba, Australia.

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

Crossposted-To: comp.windows.x.i386unix
From: [email-masked] (Daniel Supernaw-Issen)
Subject: Re: New Motif lib's for use with XFree 3.1 ?
Date: Thu, 13 Oct 1994 15:20:30 GMT

In article <[email-masked]>, [email-masked] (Adam J. Richter) writes:
> In article <[email-masked]>,
> Craig Groeschel <[email-masked]> wrote:
> >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.
> >
[much deleted]

Ok, Question:

I understand that the yggdrasil xfree3.1-beta was built with the old version
number - is yggdrasil making available xfree3.1 (non-beta) built the same way? 
And if so, is it available via anonymous ftp?  It would be much appreciated as 
I'm one of those motif users who's gotten a bit burned by all this.

Daniel Supernaw-Issen

i speak for nobody but myself - I certainly don't speak for IBM.

-- 
My other life is worth living.

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

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