Linux-Development-Sys Digest #621, Volume #7 Thu, 24 Feb 00 18:13:23 EST
Contents:
Re: Binary compatibility: what kind of crack are they smoking? (Albert Ulmer)
File systems ("Matthew Baldwin")
Re: Real Time Protocol (Francesco 'Kinkie' Chemolli)
APIC errors in 2.3.45 (bill davidsen)
Re: Binary compatibility: what kind of crack are they smoking? ("Mark Langsdorf")
Re: changing glibc (Juergen Heinzl)
Re: Linux CPU stats (bill davidsen)
Re: Binary compatibility: what kind of crack are they smoking? (Kaz Kylheku)
Re: Binary compatibility: what kind of crack are they smoking? (Adam Ierymenko)
Re: Binary compatibility: what kind of crack are they smoking? (Adam Ierymenko)
Re: Binary compatibility: what kind of crack are they smoking? (Colin Watson)
Re: (Q) Whatever happened to kerneld? (Paul Kimoto)
----------------------------------------------------------------------------
From: Albert Ulmer <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Date: Thu, 24 Feb 2000 19:46:02 +0000
Mario Klebsch wrote:
> >> P.S. We should stop to compare this aspect of Linux to Windows, and
> >> see how great Linux is. We should compare against other UNIX systems,
> >> (e.g. Solaris, HP-UX,...) and then we will see, that great is not that
> >> great. :-(
>
> >That must be why all those major Unix vendors are wholeheartedly
> >embracing Linux and extending it with the best their systems have to
> >offer...
>
> They are doing it, because almose everyone askes them about, not
> because Linux is superior. They would have a much easier job, if Linux
> would be a complete OS, not just a kernel.
But Linux *is* only a kernel. If your talking about an operating system,
you should be calling it GNU/Linux, like i.e. Debian does. This is the
correct way of saying: Hey, I'm using the Linux kernel as a foundation
for all the wonderful GNU tools and utilities. Anything else should be
derived from the LSB and FSH, so all distributions are compatible.
All of this would not be a problem if people could finally start keeping
definitions of the concepts they're using in their minds. This may sound
unnecessary in times of PnP and Rio etc., but it sure saves you a few
headaches when serious computing is the topic.
------------------------------
From: "Matthew Baldwin" <[EMAIL PROTECTED]>
Subject: File systems
Date: Thu, 24 Feb 2000 20:01:50 GMT
I'm developing an FTP File System for Linux kernel 2.2.x and am having a
couple of problems, mainly in the mounting of the 'file system'. The open,
release, read and write functions have been implemented and were based on
the corresponding NFS functions, however when mounting I get a message, in
the /var/log/messages (which I am watching whilst testing), along the lines
of bread failed and the mount command tells me the kernel does not support
the filesystem type. However, I have written the code to register the file
system and block device etc, does anyone know what the bread failure has to
do with?
Also, I have written functions to send FTP commands to the server and they
work fine, however the sock_recvmsg function doesn't seem to read
anything...does anyone have any experience of using kernel sockets that
could give me some pointers here.
Any help would be greatly received, thanks.
Matthew Baldwin
http://www.cs.bris.ac.uk/~mb8094/ / http://www.tdbsoftware.co.uk/
[EMAIL PROTECTED]
------------------------------
From: Francesco 'Kinkie' Chemolli <[EMAIL PROTECTED]>
Subject: Re: Real Time Protocol
Date: 25 Feb 2000 10:53:00 +0100
Reply-To: [EMAIL PROTECTED]
Michael Stickel <[EMAIL PROTECTED]> writes:
> Diego Betancor wrote:
> >
> > Does anyone know of any RTP (Real Time Protocol) stack out there. I
> > would like to put the payload (G723) and send it like who send a UDP.
>
> Would be nice to write RTP/RTCP support for the Linux Kernel.
I disagree. RTP is an user-level protocol built on top of UDP. It is better
handled at the user-level IMO.
--
/Kinkie
Se sulla scatola c'e` scritto "Per windows 95 e superiori", dovrebbe
funzionare sotto Linux, vero?
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: APIC errors in 2.3.45
Date: 24 Feb 2000 21:17:14 GMT
I have been playing with the 2.3 kernels, and I note an odd thing on
2.3.45, reports of multiple APIC problems.
================================================================
APIC error interrupt on CPU#1, should never happen.
.... APIC ESR0: 00000008
.... APIC ESR1: 0000000a
.... bit 1: APIC Receive CS Error (hw problem).
.... bit 3: APIC Receive Accept Error.
APIC error interrupt on CPU#1, should never happen.
.... APIC ESR0: 00000002
.... APIC ESR1: 00000002
.... bit 1: APIC Receive CS Error (hw problem).
APIC error interrupt on CPU#1, should never happen.
.... APIC ESR0: 00000002
.... APIC ESR1: 00000002
.... bit 1: APIC Receive CS Error (hw problem).
APIC error interrupt on CPU#1, should never happen.
.... APIC ESR0: 00000002
.... APIC ESR1: 00000002
.... bit 1: APIC Receive CS Error (hw problem).
APIC error interrupt on CPU#1, should never happen.
.... APIC ESR0: 00000002
.... APIC ESR1: 00000002
.... bit 1: APIC Receive CS Error (hw problem).
APIC error interrupt on CPU#1, should never happen.
.... APIC ESR0: 00000002
.... APIC ESR1: 00000002
.... bit 1: APIC Receive CS Error (hw problem).
APIC error interrupt on CPU#0, should never happen.
.... APIC ESR0: 00000002
.... APIC ESR1: 00000002
.... bit 1: APIC Receive CS Error (hw problem).
================================================================
I tried this on a dual Celeron, dual Xeon, and even dual p5-133mmx, and
they all got APIC errors (I can't swear they were the same error, but
APIC).
I doubt that all of my systems have somehow come down with hardware
problems which didn't cause a problem on and 2.0 or 2.2 kernel, so any
words of wisdom would be appreciated.
Does this ring any bells? Any useful thoughts? It doesn't seem to hurt
anything, but I don't like things which claim to be hardware errors,
because the kernel developers tend to stop looking for the problem. and
I don't believe that all my hardware is suddenly bad.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
When taking small children to a carnival, always have them go potty
*before* you let them go on the rides, and let them eat all the junk
food and candy *after*.
------------------------------
From: "Mark Langsdorf" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Date: Thu, 24 Feb 2000 15:20:03 -0600
Adam Ierymenko wrote in message <[EMAIL PROTECTED]>...
>Kaz Kylheku wrote:
>
>> Should the libstdc++ developers stop in their tracks and not work on
2.9?
>
><rest of good reply deleted>
>
>I understand this from a technical perspective. I am speaking
>from a user-friendliness perspective, both as an end-user and
>from the point of view of a developer.
>
>I wasn't speaking from a textbook technical point of view. I
>was speaking from a convenience and usability point of view.
>
>One thing that Microsoft understands and *nix developers
>don't is this:
>
>In the OS world, usability matters a lot more than technical
>excellence or elegance. It doesn't matter what's under the
>hood.. people buy a car based on how well it drives and what
>it looks like (often the latter even more than the former). They
>don't care if the engine meets the latest and greatest textbook
>engineering guidelines, nor do they care how academic
>engineering experts would judge the design of the car if they
>were presented as say a project in a mechanical engineering
>course.
>
>I'm not suggesting that *nix in general or Linux in particular
>abandon it's concern for what's under the hood. I am simply
>drawing attention to the fact that it is due to issues like this
>that Linux is virtually unusable to anyone who
>doesn't know Unix/Linux very well.
One thing that the people comparing Linux to Windows
don't understand is this:
The people doing core development for Linux don't care
if it's used by most people. They appreciate people giving
them money, I'm sure, but they wrote Linux code for free
before people gave them money to write it. If the Linux
buzz dies because it isn't user friendly enough, they'll keep
on coding until their satisfied with the technical elegance.
What does that mean? If you want them to adapt a
solution, proposing it in terms of "user convenience" does
not get you very far. If you could come up with a smarter
system of dynamic libraries, though, they might go for
that. I mean, if you implemented and everything, instead of
saying that someone else should do it for you.
What's so hard about that?
-Mark Langsdorf
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: changing glibc
Date: Thu, 24 Feb 2000 21:38:57 GMT
In article <[EMAIL PROTECTED]>, Mario Klebsch wrote:
>[EMAIL PROTECTED] (Paul Kimoto) writes:
>
>>[This is not really a c.o.l.d.*system* matter.]
>
>>In article <[EMAIL PROTECTED]>,
>>Rasmus B�g Hansen wrote:
>>> On Thu, 24 Feb 2000 [EMAIL PROTECTED] wrote:
>>>> Has anyone successfully changed glibc and can give me advice, how to
>>>> migrate.
>
>>See the glibc FAQ at http://sourceware.cygnus.com/glibc/glibc-faq.html .
>
>>> The glibc 2.0 series was as far as I know some kind of semi-beta, and
>>> things were changed between 2.0 and 2.1. Binary compatibility will
>>> probably not work (as told above).
>
>>Most (well-written) programs _will_ work.
>
>Nice statement, but It doesn't help much, if you only have a binary of
>the program, that does not work. :-( This happened to me with applix
>office. There is a glibc version on the CD, but I cannot get it to
>work with glibc2.1.2.
Try the update .. 4.4.1 would work mostly,, 4.4.2 does work without
problems for me (glibc-2.1.2 && glibc-2.1.3pre4). For me it was
actually the only real troublesome thing but I used 2.0.110 - 2.0.112
too, so some things updated on the fly beforehand..
Cheers,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: Linux CPU stats
Date: 24 Feb 2000 21:46:41 GMT
In article <FpCn4.8733$[EMAIL PROTECTED]>,
Brian <[EMAIL PROTECTED]> wrote:
| I'm a windows (c, vb, java) programmer, with little experience with Linux.
| I've created a program in Windows which can monitor the CPU Performance of a
| "remote" NT server.
|
| I also want to monitor the CPU Performance of a Linux system.
|
| Can anyone point me in the right direction on how to get the CPU performance
| of a linux box?
If you want CPU performance run benchmarks. I think you want CPU
utilization, or "what the CPU(s) is/are doing." See various things in
/proc, such as stat and cpuinfo.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
When taking small children to a carnival, always have them go potty
*before* you let them go on the rides, and let them eat all the junk
food and candy *after*.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 24 Feb 2000 22:00:36 GMT
On Thu, 24 Feb 2000 15:20:03 -0600, Mark Langsdorf <[EMAIL PROTECTED]>
wrote:
>
>Adam Ierymenko wrote in message <[EMAIL PROTECTED]>...
>>Kaz Kylheku wrote:
>>
>>> Should the libstdc++ developers stop in their tracks and not work on
>2.9?
>>
>><rest of good reply deleted>
>>
>>I understand this from a technical perspective. I am speaking
>>from a user-friendliness perspective, both as an end-user and
>>from the point of view of a developer.
>>
>>I wasn't speaking from a textbook technical point of view. I
>>was speaking from a convenience and usability point of view.
>>
>>One thing that Microsoft understands and *nix developers
>>don't is this:
>>
>>In the OS world, usability matters a lot more than technical
>>excellence or elegance. It doesn't matter what's under the
>>hood.. people buy a car based on how well it drives and what
>>it looks like (often the latter even more than the former). They
>>don't care if the engine meets the latest and greatest textbook
>>engineering guidelines, nor do they care how academic
>>engineering experts would judge the design of the car if they
>>were presented as say a project in a mechanical engineering
>>course.
>>
>>I'm not suggesting that *nix in general or Linux in particular
>>abandon it's concern for what's under the hood. I am simply
>>drawing attention to the fact that it is due to issues like this
>>that Linux is virtually unusable to anyone who
>>doesn't know Unix/Linux very well.
>
> One thing that the people comparing Linux to Windows
>don't understand is this:
> The people doing core development for Linux don't care
>if it's used by most people.
I have no clue what you two are talking about. I was just stating the facts:
DLLs are a big pain under Windows that causes usability problems. An app that
dies because some DLL was changed by another app is not a usable app. In Linux
we tend not to have this problem because all of the shared libraries are
versioned. Moreover, there is versioning capability that allows a new library
to detect old clients and emulate old behavior. And there are headaches with
missing libraries or missing symbols in libraries. Just try running some Win98
programs on Win95, or vice versa.
When you download a Linux binary that doesn't work because some library is
missing, you should blame the developers of that application. At the very
least, their installation procedure should detect the missing library and tell
the user what is wrong, like ``You have glibc 2.0 installed, this program needs
glibc 2.1''.
------------------------------
Date: Thu, 24 Feb 2000 17:20:16 -0500
From: Adam Ierymenko <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Mario Klebsch wrote:
> [EMAIL PROTECTED] (Colin Watson) writes:
>
> >Hmm. I don't know what flavour of Linux you've used, but it's clear it's
> >not one that handles dependencies very well. A sensible distribution
> >will handle your library problems transparently. Of course, third-party
> >software that hasn't been packaged for your distribution won't have this
> >convenience,
>
> There is no such thing as a Linux OS! There is RedHat Linux,
> SUSE-Linux, debian Linux, and lots of other. Face it, Linux already
> has fragmented.
>
> This will kill Linux, because if you want to support Linux, you have
> to support more than a hand foll of operating systems, that only
> differ slightly. And although you officially are supporting Linux, you
> are not supporting all thos linux systems, that are not just installed
> from CD, but self compiled.
Actually, if all the distros would just standardize on one
package manager format, it would be OK. Right now it's
RPM and DPKG... or maybe make DPKG and RPM able to
install each others' packages?
------------------------------
Date: Thu, 24 Feb 2000 17:30:18 -0500
From: Adam Ierymenko <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Mario Klebsch wrote:
> [EMAIL PROTECTED] (Kaz Kylheku) writes:
>
> >Your inability to run some proprietary binary on Linux because you don't have
> >the right version of some library pales by comparison to having unknown
> >software break when you install something.
>
> But that is no reason to implement this questionable feature in linux,
> too. I am aware, Linux always was the windows of the UNIX systems, but
> this is doing no good!
>
> >>So what happens when commercial vendors distribute C++
> >>binaries? What !#$!#%! library do they use? Or do they have
> >>to have a version for:
>
> >They can simply require a particular version. How can they do anything else?
>
> But requirering a version often is not enough! I recently tried to
> build a libstdc++-2.8.1. When the library was build, the executable
> requiering it still failed. We are at a point, where a user cannot
> reproduce libs like that, and requirering libs, that cannot be
> reproduced, is a bad thing!
>
> >If your developers build the program using libstdc++ 2.8.0 , and your testers
> >validate with libcstdc++ 2.8.0, what else can you do but tell users that they
> >need 2.8.0?
>
> linking statically! (I never thought, I would suggest this, but most
> linux distributions use too much dynamic linking, and this library
> chaos only makes it worse) As long as there are no stable versions or
> we have the problems of different incompatible versions of a library
> having the same name (like libX11,...), linking statically against
> those libraries os the only option. Of course, there is an
> alternative, but that is not the favorite for comercial software:
> Distribute the soruce and let the linker on the target system
> determine all those system dependencies.
I've never had many problems with X libraries. Personally
I think that the only libraries that really ought to be linked
statically are libraries that change often and tend to produce
a problem a lot. The biggest one that comes right off the top
of my head is stdc++... it changes when the compiler version
changes which is an incredible pain in the ass. C++ is
without a doubt the worst offender.
------------------------------
From: [EMAIL PROTECTED] (Colin Watson)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Date: 24 Feb 2000 22:36:46 GMT
In article <[EMAIL PROTECTED]>,
Adam Ierymenko <[EMAIL PROTECTED]> wrote:
>Mario Klebsch wrote:
>> There is no such thing as a Linux OS! There is RedHat Linux,
>> SUSE-Linux, debian Linux, and lots of other. Face it, Linux already
>> has fragmented.
>>
>> This will kill Linux, because if you want to support Linux, you have
>> to support more than a hand foll of operating systems, that only
>> differ slightly. And although you officially are supporting Linux, you
>> are not supporting all thos linux systems, that are not just installed
>> from CD, but self compiled.
>
>Actually, if all the distros would just standardize on one
>package manager format, it would be OK. Right now it's
>RPM and DPKG... or maybe make DPKG and RPM able to
>install each others' packages?
alien.
Not that this solves the problem; the different distributions have
different filesystem layouts. alien does (with the -g option) let you
perform the unpack and build stages separately, though, which gives you
the chance to rearrange things yourself.
The libraries problem remains, though, as dependencies can't sensibly be
translated between distributions (even forgetting about package
formats). Modulo bugs, open source does generally solve this.
--
Colin Watson [[EMAIL PROTECTED]]
"There is perhaps in every thing of any consequence, secret history,
which it would be amusing to know, could we have it authentically
communicated." - James Boswell
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: (Q) Whatever happened to kerneld?
Date: 24 Feb 2000 18:07:45 -0500
Reply-To: [EMAIL PROTECTED]
In article <893tfg$140u$[EMAIL PROTECTED]>, Timothy Murphy wrote:
> How are modules loaded automatically in kernel 2.2.14 ?
> I chose autoloading when compiling the kernel,
> and expected to find kerneld or kmod running,
> but neither appear to be, although both are on the system.
kerneld(8) should not be running. kmod is part of the kernel
and does not appear as a separate process.
(Cf. /usr/src/linux/Documentation/kmod.txt.)
> As far as I can see, some modules _are_ loaded automatically
> when their use is called for,
> but others don't seem to be called properly (as they used to be),
> eg ppp, scsi (when compiled as modules).
>
> In any case, what is the mechanism now for autoloading?
> Has it changed?
Are you using different modutils? Very recent versions (2.3.*)
have a lot of aliasing knowledge already built in.
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
** 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
******************************
