Linux-Development-Sys Digest #643, Volume #7 Thu, 2 Mar 00 06:13:17 EST
Contents:
Re: Absolute failure of Linux dead ahead? (Christopher Browne)
cardctl command... ("Jae H. Choi")
Re: [Q] How to change the max. amount of open files ("Sake")
Re: Binary compatibility: what kind of crack are they smoking? (Mario Klebsch)
Re: [Q] How to change the max. amount of open files (Kaz Kylheku)
Re: Struct size and allocate problem! need help. ("Jaron")
Q: Find Sound Mixing Tool. ("Kim, Hui Jin")
Re: Q: Find Sound Mixing Tool. (Erik de Castro Lopo)
Re: Electric Fence for C++ ??? (Anes Lihovac)
Re: Binary compatibility: what kind of crack are they smoking? (Wolfram Gloger)
Needed: A General Solution For The Lib/Distro Version Problem (was: Binary
compatibility... (Mark S. Bilk)
Re: [Q] How to change the max. amount of open files ([EMAIL PROTECTED])
Re: Semaphore quustion ... part 2!! Bug ? ([EMAIL PROTECTED])
Re: Binary compatibility: what kind of crack are they smoking? (Gregory Neil Bastow)
Re: Backing out of ext3 filesystem (Sander van Malssen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 02 Mar 2000 05:25:24 GMT
Centuries ago, Nostradamus foresaw a time when Ron House would say:
>If Linux has an Achilles heel, it has now becomne clear what it is:
>binary incompatibilities.
>
>Can anyone explain what was so very important about glibc that required
>incompatibility with the previous calling convention? Or why, just a few
>months later, another incompatible change was made? Perhaps there is a
>very good reason, or perhaps it is a misguided quest for efficiency, but
>either way there are thousands of Linux systems out there failing to run
>Linux programs. Add to that the efforts of RedHat, who bung the latest
>stuff in their distributions before it has been tested adequately, and
>we have a recipe for snatching failure from the jaws of victory.
Wait, wait! There are other scary items forthcoming:
a) Resolution of the 2038 problem. 2^31-1 seconds from Jan 1, 1970
happens to be in 2038. Stuff Will Break Then.
This is the end-of-epoch that is the UNIX equivalent to the "Year 2000
cliff" that everyone worried last year about.
b) Resolution of the 2GB file problem on 32 bit architectures. This
is, again, a 32-bit-ism that is starting to bite people working with
today's Very Large Disk Drives. The comprehensive fix to this will
likely be synchronized with the 2038 problem, as resolutions for both
likely involve moving from 32 bit values to 64 bit values.
There will be some period of "inconvenience" at whatever point libraries,
filesystems, and kernels have to be synchronized together to fix this.
c) One of these days, someone may actually come up with a C++ ABI that
would be expected to interoperate widely. No approach for this is yet
available.
d) Many of the problems go away when you've got tools that automatically
recompile software using local tools thus maximizing compatibility, and
possibly even performance. The BSD Ports system provides this, and
Debian looks to be looking towards this. (Which has the further merit
of diminishing C++ ABI worries...)
>Work, serious work, is needed on overcoming the problems caused by these
>sorts of changes, or the potential user base will go elsewhere.
Have you written any test tools today?
(I only wrote a few lines worth, personally, but that's just me...)
Part of the problem Red Hat has had is that they didn't have anyone
truly responsible for system testing. Testing was generally "supposed
to be done," but without any pointed responsibility, this doesn't
necessarily happen. About six months ago, I'm told they hired
someone to be responsible for testing, which should lead to there
being some automated tests that should be helpful. The acquisition
of Cygnus is pretty interesting in that Cygnus has been collecting
test suites for compilers for rather a while now, hopefully providing
them with some expertise that might rub off.
--
There's no such thing as nonexistence.
[EMAIL PROTECTED] - - <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: "Jae H. Choi" <[EMAIL PROTECTED]>
Subject: cardctl command...
Date: Thu, 2 Mar 2000 00:45:28 -0500
when I do cardctl insert command, it gives me the error message that it can
not find the pcmcia driver... does that mean my pcmcia controller driver is
missing or my pcmcia card's drivers is missing??
I am currently using 3com 572 ethernet card.. Can anybody help me??
Jae H. Choi
[EMAIL PROTECTED]
------------------------------
From: "Sake" <[EMAIL PROTECTED]>
Subject: Re: [Q] How to change the max. amount of open files
Date: Thu, 2 Mar 2000 00:34:54 -0500
Just wondering, what kind of program would have to keep 2048 open files at
any
instant of time ?
Lawrence K. Chen, P.Eng. <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> That didn't work for me.
>
> I tried it with $NEW_VALUE == 2048 and 10240, but the maximum that I can
get
> is still 1024.
>
> And my application can use up to 2048 (which it automatically tries to get
> when it starts up by using getrlimit/setrlimit).
>
> [EMAIL PROTECTED] wrote:
> >
> > In article <89ilcc$8jt$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> > > Hi..
> > >
> > > can anyone point me to the source file, which i would need to change
> > in a
> > > SuSE Linux Distribution, in order to increase the maximum open files
> > allowed
> > > ? I need to increase this value, since some applications (like SQUID)
> > handle
> > > too much open files for the system right now, which causes SQUID
> > (e.g.) to
> > > stop working. You would do me a favor, if you could not only respond
> > to the
> > > forum, but also to my email address, since i only can check the forum
> > via
> > > DejaNews.
> > >
> > >
> >
> > To extent those values is much easier, just:
> >
> > echo $NEW_VALUE > /proc/sys/file-max
> > echo $NEW_VALUE > /proc/sys/inode-max
> >
> > You will find lots of other interesting info in /proc, like:
> > /proc/interrupts
> > /proc/ioports
> > /proc/dma
> > /proc/<processID>/...
> >
> > Hope it helps
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> --
> Who: Lawrence Chen, P.Eng. Email: [EMAIL PROTECTED]
> What: Software Developer URL:
http://www.opentext.com/basis
> Where: Open Text, BASIS Division Phone: 614-761-7449
> 5080 Tuttle Crossing Blvd. Fax: 614-761-7269
> Dublin, OH 43016 ICQ: 12129673
> DISCLAIMER: All opinions expressed are mine and *NOT* my employers
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Date: Wed, 1 Mar 2000 22:17:31 +0100
Gregory Neil Bastow <[EMAIL PROTECTED]> writes:
>Just make sure you say GNU/Linux when you mean more than the kernel, boys
>and girls.
What the hell is GNU/Linux? YALD (Yet Another Linux Distribution)?
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: [Q] How to change the max. amount of open files
Reply-To: [EMAIL PROTECTED]
Date: Thu, 02 Mar 2000 05:56:06 GMT
On Thu, 2 Mar 2000 00:34:54 -0500, Sake <[EMAIL PROTECTED]> wrote:
>Just wondering, what kind of program would have to keep 2048 open files at
>any
>instant of time ?
Something that streams files to thousands of network clients concurrently,
maybe? It would have a large number of open files, not to mention socket
descriptors.
------------------------------
From: "Jaron" <[EMAIL PROTECTED]>
Crossposted-To:
alt.os.linux,comp.os.linux.development.apps,comp.unix.sco.misc,comp.unix.sco.programmer,comp.unix.unixware.misc,tw.bbs.comp.linux
Subject: Re: Struct size and allocate problem! need help.
Date: 2 Mar 2000 06:22:01 GMT
ThankX all for suggestions.
At this point. what I worry about is the portability ?
Because I want this program works for many UNIX environment like
SCO UNIX, UnixWare, UNIX SVR4.2 and Linux...
So if I change this structure as below( change unsigned long to 4 unsigned
char)
struct a {
unsigned char a1;
unsigned char a2;
unsigned short a3;
unsigned short a4;
/*unsigned long a5;*/
unsigned char a5[4];
};
Do you think this is better ?
*------------------------------------------------*
I use the structure as below:
uchar RXBuf[2048];
void F1 ((uchar *) P)
{
..
len = recvfrom (sock, (char *)RxBuf, sizeof (RxBuf), 0, .....);
...
bcopy (RxBuf, P, len);
...
}
void F2(void)
{
F1 ((uchar *) a );
...
}
------------------------------
Date: Thu, 02 Mar 2000 15:28:00 +0900
From: "Kim, Hui Jin" <[EMAIL PROTECTED]>
Subject: Q: Find Sound Mixing Tool.
Crossposted-To: comp.os.linux.development.apps,comp.os.linu.misc
Hi there.
These days, I am trying to develop Sound mixing program.
For Example, the program can make one wav file that mixed with two wav
file.
anybody know program like this?
Or anybody can tell me about some kind of way to develop this program.
Have a nice day!
------------------------------
From: Erik de Castro Lopo <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linu.misc
Subject: Re: Q: Find Sound Mixing Tool.
Date: Thu, 02 Mar 2000 07:43:40 +0000
Kim, Hui Jin wrote:
> =
> Hi there.
> =
> These days, I am trying to develop Sound mixing program.
> For Example, the program can make one wav file that mixed with two wav
> file.
> anybody know program like this?
> Or anybody can tell me about some kind of way to develop this program.
Have a look at the Linux Sound and Music page:
http://www.bright.net/~dlphilp/linuxsound/
Erik
-- =
+-------------------------------------------------+
Erik de Castro Lopo [EMAIL PROTECTED]
+-------------------------------------------------+
"A program invented (sic) by a Finnish computer hacker and handed out
free =
in 1991 cost investors in Microsoft $11 billion (=A36.75 billion) this
week."
-- Andrew Butcher in the UK's Sunday Times, Feb 20th, 1999
------------------------------
From: Anes Lihovac <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Electric Fence for C++ ???
Date: Thu, 02 Mar 2000 09:09:14 +0100
Anes Lihovac wrote:
>
> Hi !
>
> I am searching for a Library which like EFENCE
> but for C++ !!!
>
> Any suggestion ???
> Thanks
> Ciao
> Anes
You (above) are both right. I thought Efence isn't able to manage
C++.
Thank you.
Best regards
Ciao
------------------------------
From: Wolfram Gloger <[EMAIL PROTECTED]>
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Date: 02 Mar 2000 09:55:42 +0100
[EMAIL PROTECTED] (Mario Klebsch) writes:
> Switching from rpath to LD_LIBRARY_PATH (/wetc/ld.so.config is nothing
> else, but it does not reside in the environment) is not the
> sollution.
You still haven't read any documentation on ld.so, have you?
ld.so.config (or rather, the database of libraries in
/etc/ld.so.cache) _is_ completely different from LD_LIBRARY_PATH.
Hint: here is an excerpt from `ldconfig -p' on my system.
libm.so.5 (ELF-libc5) => /lib/libm.so.5
libc.so.5 (ELF-libc5) => /lib/libc.so.5
libdl.so.1 (ELF-libc5) => /lib/libdl.so.1
libstdc++.so.27 (ELF-libc5) => /usr/i586-linux/lib/libstdc++.so.27
libm.so.6 (ELF-libc6) => /lib/libm.so.6
libstdc++-libc6.1-2.so.3 (ELF-libc6) => /usr/lib/libstdc++-libc6.1-2.so.3
Regards,
Wolfram.
------------------------------
From: [EMAIL PROTECTED] (Mark S. Bilk)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Needed: A General Solution For The Lib/Distro Version Problem (was: Binary
compatibility...
Date: 2 Mar 2000 10:10:07 GMT
The complex problem below, and others involving running
multiple programs that use various library versions that
themselves have been linked with different libraries, etc.,
have been described in this thread, and many before it.
With the present system for managing all this, there seem
to be several solutions for the general case of installing
a software package (I'm only a beginner at this, and may
have some of it wrong):
o Get it as a binary package, and acquire and install all
the libraries that it needs. This can be done automat-
ically, but library conflicts can arise (where the
program requires lib A linked with lib B1, but another
needs lib A linked with lib B2, and the two A's get
the same name, or if not, cause trouble if both programs
run at the same time).
o Get it as object files. Apparently this has problems,
too (e.g., see below).
o Get it as source and compile it. This requires having
installed the correct compiler that the program was
written for, along with everything that it needs.
I don't know if this guarantees that there will be no
conflicts, but commercial applications generally don't
come with source.
There's also the additional complexity of different Linux
distributions having corresponding files in different places
in the filesystem.
The various current types of wishful thinking, e.g., that
everyone will upgrade to each new version of libraries sim-
ultaneously, or that new library versions won't be necessary,
or that all distros will converge, etc., are apparently not
going to come true. In fact, they may become less true in
the future than they are now, as more and more people produce
new software and new distros.
The ideal solution to all this would allow totally auto-
matic installation of all software -- binary, object, or
source, along with all the libraries, compilers, and what-
ever else they need, and would install them on any distro,
in a form in which they could be simultaneously run with
any and all other software, without causing any conflicts,
ever.
A single package version should be able to be installed on
all versions of all Linux distros, given sufficient disk
space for holding lots of library and compiler versions.
And the infrastructure for doing it should be portable
among all systems without requiring modification; for
example, the linker would be the same for all distros, and
could find out where various types of files are from a
distro.conf file in the root directory of the filesystem.
Achieving this goal, without requiring any understanding,
let alone intervention, by the user, would seem to require
that sources, object files, libraries, and executables
carry with them absolutely complete and unambiguous infor-
mation about everything they require for installation and
subsequent execution. Also that libraries, etc., have long
compound names (or be kept in version-specific directories)
that permit all possible versions to be automatically and
unerringly distinguished.
I'm talking about a new design for the structure of these
things (call it the New System), a design that would be
arrived at by temporarily forgetting about how annoying it
will be to switch everything over to the New System, and
just conceptualizing how to do it the best and simplest way
that will guarantee that everything will work perfectly now
and in the future, with new application, library, compiler,
and distro versions being accommodated effortlessly.
Of course it should be human-engineered for the developer,
too, so it should not require, e.g., umpteen permutations
to be embedded in every makefile.
If it's possible to use an incremental solution -- imple-
menting the New System by simply making package installers
and linkers, etc., more clever, that would be great, but if
deeper changes are necessary, I think it would be best to
bite the bullet as soon as possible, before most of the
computers in the world are using Linux, and it will require
more work to change everything over.
It's obviously possible to reach these goals, since all the
variant factors are known. Simultaneously achieving simpli-
city, minimal resource use, and minimal change from the
current system (which should help reduce the probability of
unforeseen problems in the future), will require skill,
artistry, and cooperation.
I'd love to see a discussion here on ways to do it (by those
who are more familiar with the intricacies than I am). Or,
since I come across several huge and totally new (to me)
concepts and projects in software engineering every week
here, if there are people already doing this work, please
give a pointer to them.
In article <[EMAIL PROTECTED]>, Martin Schenk <[EMAIL PROTECTED]> wrote:
>JEDIDIAH wrote:
>>
>> >This assumes that there exist no third party binary only apps. This in
>> >the long term is a dangerous assumption.
>>
>> No it doesn't. The concept of 'relink-at-install-time' actually
>> has some precedent in Unix. As long as the standard system is
>> considered to have a full build enviroment, this issue should
>> never really be a problem.
>
>On principle, I agree with this - but in practice this is not immune to
>problems either. When installing Oracle, a lot of the stuff gets
>relinked -
>alas installing Oracle 8.0.5 on my SuSE 6.2 based machine (glibc 2.1
>development, should run glibc2.0 and glibc2.1 binaries without problems)
>did not work until I downloaded a different version of the C-compiler
>and a special set of "glibc2.0-development on a glibc2.1-based system"
>libraries (the SuSE help database explains what has to be done).
>
>I also needed a different version of the Openlink drivers (to use the
>ODBC API under linux) - and finally could not build me program with
>Solid (another database, uses the ODBC API natively) anymore.
>
>I'm sure that one can get all these things to work properly, but it
>certainly is pain.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: [Q] How to change the max. amount of open files
Date: Thu, 02 Mar 2000 10:23:55 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Thu, 2 Mar 2000 00:34:54 -0500, Sake <[EMAIL PROTECTED]> wrote:
> >Just wondering, what kind of program would have to keep 2048 open
files at
> >any
> >instant of time ?
>
> Something that streams files to thousands of network clients
concurrently,
> maybe? It would have a large number of open files, not to mention
socket
> descriptors.
IBM message queueing system MQSeries takes for its server even:
echo 32768 > /proc/sys/file-max
echo 65536 > /proc/sys/inode-max
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Semaphore quustion ... part 2!! Bug ?
Date: Thu, 02 Mar 2000 10:33:43 GMT
In article <[EMAIL PROTECTED]>,
"Lawrence K. Chen, P.Eng." <[EMAIL PROTECTED]> wrote:
> Each process pretty much locks the semaphore again right after it
> unlocks....which effectively prevents any body else from getting a
chance to
> lock the semaphore. Either do some more work between unlock->lock
> periods...or do something that at least causes a context switch so at
least
> another process gets a crack at trying to do something.
>
> Either that....or use a two stage semaphore.
>
> something like:
>
> lock semaphore 1
> lock semaphore 2
> free semaphore 1
> do operation
> free semaphore 2
>
This is an obviously well working implementation that should be easy to
port to anykind of semaphores.
I just wonder, why it is necessary to use a second semaphore, even if
there is no operation between unlocking an locking of a single thread.
Does the list of "by the lock blocked" threads not work fifo?
Ok, this would be implementation spezific, and it's always better to be
on the save side, but I still wonder.
Joerg
(irgei)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Gregory Neil Bastow <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Date: 2 Mar 2000 10:46:04 GMT
In comp.os.linux.development.system Christopher Browne <[EMAIL PROTECTED]> wrote:
: Centuries ago, Nostradamus foresaw a time when Gregory Neil Bastow would say:
:>Just make sure you say GNU/Linux when you mean more than the kernel, boys
:>and girls.
: The observation that "Linux, the kernel" != "Linux, the system" was,
: and is, a useful observation.
Indeed. I think everyone but Mario had realised that since the outset of
the thread. Hence my sarcasm.
: The observation that "Linux, the system" depends on a lot of software
: that the FSF had some part in producing was also a relevant
: observation.
: Much of the "politicalization" (is there a good word for that?) of the
: issue has been "less clearly good." It looks more like RMS is begging
: for recognition, and if he had been a bit more gracious about this,
: there wouldn't have been the flame wars.
I think many people mistakenly think that RMS wants personal recognition
for the success of GNU/Linux. Everything he has ever said or done
suggests otherwise. The problem, as he sees it, (and I see it this way,
too) is that in the success of GNU/Linux, people are forgetting that the
Free Software Foundation (which is probably 75% responsible for the fact
that we have such a kick-arse system) is doing things a particular way to
prove a particular point and to allow people to use the software they need
without compromising the principles that FSF is trying to evangelise.
It is unfortunate that after finally succeeding in proving their point,
and succeeding in their 10-year-old mission the FSF have been robbed of
the chance to make people associate the success of the project with their
principles and their methodologies by simple whims of nomenclature.
Right though he may be, RMS's subsequent attempts to close the stable door
after the horse had bolted have done nothing but detriment his/our cause.
-Greg
------------------------------
From: Sander van Malssen <[EMAIL PROTECTED]>
Subject: Re: Backing out of ext3 filesystem
Date: Thu, 02 Mar 2000 11:48:32 +0100
Reply-To: Anonymous, Reply
C. Chan wrote:
>
> I'd to experiment with the ext3 journaling patches. Is it possible
> to mount a filesystem as ext2 after it has been mounted as ext3
> with the journalling option? Also, if it is possible, can the
> filesystem then be unmounted and remounted again as ext3, and if
> so does the journal need to be cleared?
No problem, the on-disk formats for ext2 and ext3 are exactly the same
(apart of the
journal file which is really just an ordinary file in the file system).
You can switch
back between the two as much as you want, as long as the filesystem is
unmounted properly
before remounting it with the other fs type.
Cheers,
Sander
------------------------------
** 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
******************************
