Linux-Development-Sys Digest #695, Volume #6 Sun, 9 May 99 20:13:59 EDT
Contents:
posix.1b signals ("Vladimir G. Stanishev")
Re: Mount multi-track CD ROMs? (Remco van den Berg)
Re: Glibc rant (Juergen Heinzl)
Re: Reliable (!) nic for 2.2 kernel? (Don Baccus)
Re: linux and swap on nfs ("Stefan Monnier "
<[EMAIL PROTECTED]>)
Re: Glibc rant (David T. Blake)
Re: why top give false results? (Jacek Pop�awski)
Re: why top give false results? (Jacek Pop�awski)
Re: Reliable (!) nic for 2.2 kernel? (Leslie Mikesell)
Re: why top give false results? (Phil Howard)
Re: why top give false results? (Remco van den Berg)
G++: Where's the documentation (man pages for header files?) (Ethan Pinkert)
Re: Glibc rant ("G. Sumner Hayes")
----------------------------------------------------------------------------
From: "Vladimir G. Stanishev" <[EMAIL PROTECTED]>
Subject: posix.1b signals
Date: Tue, 04 May 1999 03:23:23 +0100
Hello.
Is there anyone who is familiar with the implementation level of the
POSIX.1b signals and signal functions in the kernel? From looking at the
sources it looks like part of them has been implemented, but I am not so
familiar with the kernel to pretend that I understand it. If anyone
knows more about this and is willing to explain some of it, please email
me. Thanx.
Vladimir
------------------------------
From: [EMAIL PROTECTED] (Remco van den Berg)
Subject: Re: Mount multi-track CD ROMs?
Date: Sun, 09 May 1999 20:16:12 GMT
Are you aware of the things you post to the newsgroups?
If not, this is how it looks:
-Remco
In article <[EMAIL PROTECTED]>, Igor Zlatkovic wrote:
>
>--------------D113662A62ABF2B368977B68
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>--
> o
> O Cheers,
> ______O___
> \________/ Igor Zlatkovic
> \ o / mailto:[EMAIL PROTECTED]
> \ O /
> \ /
> \/
> || University of Applied Sciences
> ___||___ Frankfurt, Germany, EU.
>--------------D113662A62ABF2B368977B68
>Content-Type: text/html; charset=us-ascii
>Content-Transfer-Encoding: 7bit
><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
><html>
><br>
><pre>--
> o
> O Cheers,
> ______O___
> \________/ Igor Zlatkovic
> \ o / <A
>HREF="mailto:[EMAIL PROTECTED]">mailto:[EMAIL PROTECTED]</A>
> \ O /
> \ /
> \/
> || University of
>Applied Sciences
> ___||___ Frankfurt, Germany, EU.</pre>
> </html>
>
>--------------D113662A62ABF2B368977B68--
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: Glibc rant
Date: Sun, 09 May 1999 16:14:40 GMT
In article <[EMAIL PROTECTED]>, Mark Shinwell wrote:
>"G. Sumner Hayes" wrote:
>>
>> Lou Grinzo wrote:
>> >
>> > The original thread had to do with the problems caused by glibc 2.1.
>> > That should not have happened in open, closed, or any other kind of
>> > source, and it shows that someone, somewhere, was asleep at the
>> > switch.
>>
>> The original thread had to do with the problems caused by a glibc 2.0
>> to glibc 2.1 migration. glibc 2.0 was never a stable production
>> release. It's hardly unexpected that there will be differences
>> between development versions of software and final release. Even
>> so, I only had to rebuild 4 packages (ncurses and a couple of others)
>> when moving from glibc 2.0.6 to glibc 2.1.
>
>I seem to recall David Blake's posting earlier in this thread:
>
>"By the way, Xlib and all of the image libraries need to be recompiled
>as well. I would pretty much recommend grabbing every library you can
>get your hands on from a distribution that has a glibc2.1 release, or
>facing the prospect of recompiling a lot of stuff."
... which is completely wrong and I really think it very bad to make
such nonsense public; sorry but X is quite a mouthful and so the somewhat
harsh language.
I've *never* compiled X, the server aside, myself and I've got Motif
here too, bought over a year ago (glibc version). I've got no problems
to link against them, run X programmes or run most of the precompiled
Motif binaries ... ddd was the only one yet that had trouble and this
one depends on the C++ library too.
>> If you didn't want to run development software, you shouldn't have
>> done so. If your distribution used a development version of the core
>> C library in a so-called stable release then you should complain to
>> them if it's a problem for you.
>
>(snip)
>
>This whole argument that "you just recompile all your software" is
>ridiculous. For a start, many people rely on binary (e.g. RPM)
>packages, or closed-source software. It is a nonsense to assume that
>Linux will ever make it into the mainstream market any more than it has
>at the moment based entirely on open-source software.
No, many people just go for a higher number behind the second dot.
>Closed-source software should not be seen as something "that shouldn't
>be there" but rather as something that is _necessary_ to further the
>acceptance of Linux. It's just not viable for some companies to produce
>open-source software.
>
>Hence the glibc developers ought to be doing their damnest to ensure
>that every version of glibc that is released is backwards-compatible.
>Close off as many of the internal calls as is practically possible. It
>doesn't matter if it's a development version or not. Why should a
>development version exhibit an API which is not backwards compatible?
>It might not work properly, right, but the API should be the same.
>_Especially_ when it is just about the most crucial library in the whole
>system.
Crap since the glibc developers have neither the time nor the resources
to test each and every piece of software. In addition the glibc developers
do their job for free so there is basically *nothing* they have to do
and if they want to go on a two year's holiday, leaving you in the dark
they are free to do that too.
In addition just so the API can change is the reason for the versioning
support which comes with it now.
>And if something _really_ needs to be changed, and the library has
>already been adopted by a major distribution packager, then the authors
>of the library ought to observe this and take appropriate action to
>ensure that the mess we have at the moment doesn't arise in the first
>place. Otherwise we will just descend into "DLL hell" (although it's not
>far from it with Red Hat 6.0 at the moment).
Blame the distribution packers here. 2.0.xxx were the first releases
that revealed problems and it would have been no problem for commercial
vendors to give it a try, especially since it comes down to "does not
start up". I even consider the Star Office bashing, software that comes
for free for private users, quite unjust.
Mind I am not a library developer but even so all this "I want",
"I expect" and "they just have to since I ..." ... #%$!
I can quite well understand a certain amount of frustration but this
is going too far and if you believe you can do the job right, go ahead
and if you *really* think you to be qualified enough to judge then make
a constructive comment how things could have been done, or could be
done now, better.
Right now I've got a fine and running system based on pre2. A fine
piece of a library with lots of enhancements, it is fast and it makes
my job easier to try and develop code that runs on other systems
too and the hell I would like to go back.
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
Subject: Re: Reliable (!) nic for 2.2 kernel?
From: [EMAIL PROTECTED] (Don Baccus)
Date: 9 May 1999 13:22:21 PST
In article <[EMAIL PROTECTED]>,
Greg White <[EMAIL PROTECTED]> wrote:
>Don Baccus wrote:
>> ?? 3c509b comes in PCI as well as ISA flavor
>I'll take that a step further:
>I know it is not so.
>3C509 ISA 10 only
At the risk of being impolite: bullshit.
I have a box with an unused NIC in it sitting in front
of me as I type this:
Model: 3c509b-tx, Fast ethernet 10/100, PCI
Who should I believe? You, or the unboxed NIC
sitting on my lap? And, yes, I've checked the
number, and it is 3c509, not 3c590. There's a
picture on the box of the NIC, it's clearly PCI.
I'll be stunned if it transmorgifies itself into
an ISA card when I open the box when I build my
next system.
>3C59x PCI(some PCMCIA) some 10 only, some 10/100
>3C90X PCI(some PCMCIA?) 10/100
--
- Don Baccus, Portland OR <[EMAIL PROTECTED]>
Nature photos, on-line guides, at http://donb.photo.net
------------------------------
From: "Stefan Monnier <[EMAIL PROTECTED]>"
<[EMAIL PROTECTED]>
Subject: Re: linux and swap on nfs
Date: 09 May 1999 12:17:59 -0400
>>>>> "Andi" == Andi Kleen <[EMAIL PROTECTED]> writes:
> It has the same basic problem: You run out of memory, thus you start
> swapping, the swapper calls the network stack, the network stack allocates a
> packet, you have no memory -> deadlock.
That might be the basic problem, but the way you present it, it's easy to
solve: start swapping before you run out of memory (how much memory do you need
to swap one page ?)
That's the standard pre-allocation technique to deadlock avoidance, so I'm sure
people have already thought about it: why doesn't this simple solution work ?
Stefan
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: Glibc rant
Date: 09 May 1999 10:25:03 -0700
Mark Shinwell <[EMAIL PROTECTED]> writes:
>Closed-source software should not be seen as something "that
>shouldn't be there" but rather as something that is _necessary_ to
>further the acceptance of Linux. It's just not viable for some
>companies to produce open-source software.
Making accomodations for closed source software in the development
of open source software is a bad idea. The kernel, for example,
absolutely does not do it - a good example being AFS, which has been
broken in 2.2 development. The kernel developers basically told
the people who had AFS problems to go see their vendors. The kernel
source is available, and the vendors can easily make their product
compatible. Tying the hands of the open source developers to preserve
compatibility with people who will not share their source is a one way
street - all give from the open source developers and all take from the
closed source vendors.
If you want absolute compatibility, talk to the distributions about
how they make it work for you. Talk to your closed source
vendors. They are the ones who need to figure out how to work with a
model in which they are providing closed source programs to an open
source OS, and occasionally using the open source shared object
binaries. Or hire a derned hacker who can make it work for your
systems. But don't recommend handicapping the open source developers.
They won't accept it, and you will only aggravate yourself.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Jacek Pop�awski)
Subject: Re: why top give false results?
Reply-To: [EMAIL PROTECTED]
Date: 9 May 1999 15:45:03 GMT
Remco van den Berg wrote:
>Perhaps you're only looking at the CPU usage of x11amp excluding the
>additional CPU usage of mpg123 ?
>You say x11amp runs mpg123 in the background, so it are 2 processes.
do you really think, that I can't see two processes in top?
top sorts it by cpu usage by default...
even:
uname -a
(and load avg) works bad, and give untrue information
i ask again - how to check how much cpu is used at the moment?
------------------------------
From: [EMAIL PROTECTED] (Jacek Pop�awski)
Subject: Re: why top give false results?
Reply-To: [EMAIL PROTECTED]
Date: 9 May 1999 15:45:42 GMT
Jacek Pop�awski wrote:
>uname -a
i mean "uptime" of course :-)
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Subject: Re: Reliable (!) nic for 2.2 kernel?
Date: 9 May 1999 16:08:02 -0500
In article <[EMAIL PROTECTED]>,
Don Baccus <[EMAIL PROTECTED]> wrote:
>
>>> ?? 3c509b comes in PCI as well as ISA flavor
>
>>I'll take that a step further:
>
>>I know it is not so.
>
>>3C509 ISA 10 only
>
>At the risk of being impolite: bullshit.
>
>I have a box with an unused NIC in it sitting in front
>of me as I type this:
>
>Model: 3c509b-tx, Fast ethernet 10/100, PCI
>
>Who should I believe? You, or the unboxed NIC
>sitting on my lap? And, yes, I've checked the
>number, and it is 3c509, not 3c590. There's a
>picture on the box of the NIC, it's clearly PCI.
Interesting... All of the docs at:
http://support.3com.com/infodeli/tools/nic/3c509b/family.htm
describe ISA cards, and that's all I've ever seen.
There is a 3c905b that is PCI and 10/100. Did they transpose
numbers on the box?
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: why top give false results?
Date: Sun, 09 May 1999 21:22:08 GMT
On 9 May 1999 13:15:01 GMT Jacek Pop�awski ([EMAIL PROTECTED]) wrote:
| I am not sure if it isn't offopic here... sorry anyway...
| Why 'top' shows false results? For example when I run mpg123 to play
| mp3 on my Cyrix 166+ - it shows 40% cpu usage. When I run x11amp
| to play the same mp3 on the same processor - it shows 20-30% !!! But
| x11amp uses mpg123 to play (!). And why if 50% cpu resources is free
| - sometime when I will do a lot with graphics or even text (!) - music
| breaks for a moment?
| What is good way to know how much cpu is in use at the moment?
|
| PS. load avg is bad too :-)
It sounds to me like you need more RAM. The use of another program that
was swapped out can cause your MP3 playing program to get some of it's
pages swapped out (or unmodified pages stolen). Then the next time the
MP3 player has to respond, it has to wait for swap. Do this enough times
and it falls behind the hardware buffer and you hear the break. The fact
that it is using only 50% CPU may not be relevant. How much I/O bus time
is it forced to _increase_ to due to swapping is the question to ask.
--
Phil Howard KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Remco van den Berg)
Subject: Re: why top give false results?
Date: Sun, 09 May 1999 23:38:01 GMT
In article <[EMAIL PROTECTED]>, Jacek Pop�awski wrote:
>Remco van den Berg wrote:
>>Perhaps you're only looking at the CPU usage of x11amp excluding the
>>additional CPU usage of mpg123 ?
>>You say x11amp runs mpg123 in the background, so it are 2 processes.
>
>do you really think, that I can't see two processes in top?
It could be that you were not aware of the fact that there were 2
processes running. I can't see how much you know about unix from just
a single news post. Sorry.
-Remco
------------------------------
From: Ethan Pinkert <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: G++: Where's the documentation (man pages for header files?)
Date: Sun, 09 May 1999 19:34:56 -0400
Hello...
I'm wondering if anyone can provide me with some info on the location of
documentation for G++ header files (ie iostream.h). Does anyone know
where such doumentation exists and if there's an RPM for it?
thanks in advance
-Ethan Pinkert
--
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: Glibc rant
Date: Sun, 09 May 1999 20:03:59 -0400
Mark Shinwell wrote:
> > The original thread had to do with the problems caused by a glibc
> > 2.0 to glibc 2.1 migration. glibc 2.0 was never a stable production
> > release. It's hardly unexpected that there will be differences
> > between development versions of software and final release. Even
> > so, I only had to rebuild 4 packages (ncurses and a couple of
> > others) when moving from glibc 2.0.6 to glibc 2.1.
>
> I seem to recall David Blake's posting earlier in this thread:
>
> "By the way, Xlib and all of the image libraries need to be recompiled
> as well. I would pretty much recommend grabbing every library you can
> get your hands on from a distribution that has a glibc2.1 release, or
> facing the prospect of recompiling a lot of stuff."
Not true in my case. Nor in the general case, if the documentation and
FAQ are to be believed.
Besides, glibc 2.0 was never a public stable release. You're not
seriously suggesting that every development version of software be
downwards compatible with every previous development version, are you?
> > If you didn't want to run development software, you shouldn't have
> > done so. If your distribution used a development version of the
> > core C library in a so-called stable release then you should
> > complain to them if it's a problem for you.
>
> (snip)
> This whole argument that "you just recompile all your software" is
> ridiculous.
Of course. That's why I presented three different scenarios for
people who build things themselves, people who run open-source
distributions, and people who run closed-source binaries.
> Hence the glibc developers ought to be doing their damnest to ensure
> that every version of glibc that is released is backwards-compatible.
1. They do try; that's why symbol versioning was introduced in glibc2.
2. 2.0 was never released.
3. Breaking backwards compatibility from time to time is probably
necessary as technology changes -- say every 3-5 years or thereabouts.
When that happens, bump the major version number. People relying on
the old version can keep it around alongside the new.
> Close off as many of the internal calls as is practically possible.
> It doesn't matter if it's a development version or not. Why should a
> development version exhibit an API which is not backwards compatible?
(Oh, god. You are suggesting what I said you're not seriously
suggesting.)
Because they're trying out APIs to find one that works. That's the
whole point of development releases. Those internal calls aren't
visible in the final release. They were visible in a development
version -- that's a bug, but THE WHOLE POINT OF A DEVELOPMENT VERSION
IS TO FIND THESE PROBLEMS!!! You're expecting a development version
to have the API perfect and set in stone, with no accidental exposures
of internals. That expectation exhibits a total lack of understanding
of how software development works. The development branch is there
precisely to find and correct these problems. It did, a stable version
was shipped, and now you're complaining about it -- so propose a way
to have these development versions appear in perfect form from day
one, please.
> And if something _really_ needs to be changed, and the library has
> already been adopted by a major distribution packager, then the
> authors of the library ought to observe this and take appropriate
> action to ensure that the mess we have at the moment doesn't arise in
> the first place.
Now that's just foolish. If Slackware* used linux kernel 2.1.57 for a
stable release you're seriously suggesting that Linus then has an
obligation to maintain 100% binary compatibility with that kernel
throughout the life of the 2.2 kernel series? That's exactly
equivalent, and so ridiculous to me that I can't even think of a
rational argument for it (let alone one that I would agree with).
> Otherwise we will just descend into "DLL hell" (although it's not
> far from it with Red Hat 6.0 at the moment).
Complain to Red Hat, then.
[Aside:
Note that Windows 3.0 exposed a number of internals that were eliminated
in 3.1, breaking a lot of programs. Windows 95 broke some 3.1 programs
in the same way. NT breaks some 95 programs in the same way, and
Windows 2000 will break binary compatibility in some cases as well.
Similarly MacOS system 7 vs. earlier versions. New (Solaris) SunOS
vs. old SunOS. ANSI C vs. K&R C. Backward compatibility is good, but
in almost every computer system there are times when you have to break
it (partially or completely) in order to get an improved product. It's
a balancing act. You seem to think that binary compatibility is the
sina quo non of system development -- you're entitled to that opinion,
but it's not the Linux way and isn't something I would want to see
unless the initial design specification of the system is perfect.]
--Sumner (a satisfied Red Hat user)
*Which they didn't, AFAIK; the example is used solely for illustrative
purposes.
------------------------------
** 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 PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
