493 lines
20 KiB
Plaintext
493 lines
20 KiB
Plaintext
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: Sat, 15 Oct 94 21:13:07 EDT
|
|
Subject: Linux-Development Digest #314
|
|
|
|
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: kuehn@citadel.scd.ucar.edu (Jeff Kuehn)
|
|
Subject: Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks)
|
|
Date: 14 Oct 1994 21:46:08 GMT
|
|
|
|
Dominik Kubla (kubla@Uni-Mainz.DE) wrote:
|
|
|
|
: In article <37k9ss$dha@ncar.ucar.edu> Jeff Kuehn writes:
|
|
|
|
|
|
: Shaune Beattie (sdgb1@cus.cam.ac.uk) 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: butler@cs.tulane.edu (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 <wcreator@kaiwan.com> wrote:
|
|
>In <1994Oct11.171749.2385@ka4ybr.com> mah@ka4ybr.com (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: dheltzel@crl.com (Dennis Heltzel)
|
|
Subject: Re: LINUX Logical volumes
|
|
Date: 14 Oct 1994 00:39:04 -0000
|
|
|
|
Richelo Killian (killianr@beldin.sun.ac.za) 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: jmonroy@netcom.com (Jesus Monroy Jr)
|
|
Subject: Re: We a FAQ: Linux vs. *BSD!!!
|
|
Date: Sat, 15 Oct 1994 20:58:49 GMT
|
|
|
|
Ken Hughes (hughes@napa.eng.uop.edu) wrote:
|
|
: Jordan K. Hubbard (jkh@freefall.cdrom.com) wrote:
|
|
: : In article <jmonroyCxLro2.IF6@netcom.com> jmonroy@netcom.com (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 jmonroy@netcom.com
|
|
Zebra Research
|
|
/386BSD/device-drivers /fd /qic /clock /documentation
|
|
___________________________________________________________________________
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.os.386bsd.development,comp.unix.bsd
|
|
From: jmonroy@netcom.com (Jesus Monroy Jr)
|
|
Subject: Re: We a FAQ: Linux vs. *BSD!!!
|
|
Date: Sat, 15 Oct 1994 21:03:34 GMT
|
|
|
|
Andreas Helke (andreas@orion.mgen.uni-heidelberg.de) wrote:
|
|
: Ken Hughes (hughes@napa.eng.uop.edu) 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 jmonroy@netcom.com
|
|
Zebra Research
|
|
/386BSD/device-drivers /fd /qic /clock /documentation
|
|
___________________________________________________________________________
|
|
|
|
------------------------------
|
|
|
|
From: at@setanta.demon.co.uk (Amrik Thethi)
|
|
Subject: Re: Anyone working on improving NFS?
|
|
Date: Thu, 13 Oct 1994 12:38:43 GMT
|
|
|
|
In article <CxJC8C.7ML@acsu.buffalo.edu> stock@cs.buffalo.edu (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: at@setanta.demon.co.uk
|
|
Cambridge, UK.
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.os.386bsd.development,comp.unix.bsd
|
|
From: jmonroy@netcom.com (Jesus Monroy Jr)
|
|
Subject: Re: We a FAQ: Linux vs. *BSD!!!
|
|
Date: Sat, 15 Oct 1994 21:14:28 GMT
|
|
|
|
Jordan K. Hubbard (jkh@freefall.cdrom.com) wrote:
|
|
: In article <37mflh$f6s@unix1.cc.uop.edu> hughes@napa.eng.uop.edu (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 jmonroy@netcom.com
|
|
Zebra Research
|
|
/386BSD/device-drivers /fd /qic /clock /documentation
|
|
___________________________________________________________________________
|
|
|
|
------------------------------
|
|
|
|
From: basile@rosser.serma.cea.fr (Basile STARYNKEVITCH)
|
|
Subject: Re: ext2fs vs. Berkeley FFS
|
|
Date: 11 Oct 1994 18:10:55 GMT
|
|
|
|
>>>>> "Albert" == Albert D Cahalan <adc@zeta.coe.neu.edu> writes:
|
|
In article <ADC.94Oct11131031@zeta.coe.neu.edu> adc@zeta.coe.neu.edu (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
|
|
(basile@soleil.serma.cea.fr)
|
|
-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: basile@soleil.serma.cea.fr; 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: house@helios.usq.EDU.AU (ron house)
|
|
Subject: Re: ext2fs vs. Berkeley FFS
|
|
Date: Fri, 14 Oct 1994 07:29:17 GMT
|
|
|
|
plm@atcmp.nl (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
|
|
(house@usq.edu.au) Toowoomba, Australia.
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.windows.x.i386unix
|
|
From: daniel@austin.ibm.com (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 <37hegv$4ql@freya.yggdrasil.com>, adam@yggdrasil.com (Adam J. Richter) writes:
|
|
> In article <37c1gb$lo@tartan.metrolink.com>,
|
|
> Craig Groeschel <craig@metrolink.com> wrote:
|
|
> >In article <374nup$aap@freya.yggdrasil.com>,
|
|
> >Adam J. Richter <adam@yggdrasil.com> 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: 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
|
|
******************************
|