Linux-Development-Sys Digest #645, Volume #7 Thu, 2 Mar 00 16:13:18 EST
Contents:
Re: Binary compatibility: what kind of crack are they smoking? (Michael C. Vergallen)
Re: Needed: A General Solution For The Lib/Distro Version Problem (was: Binary
compatibility... (Donovan Rebbechi)
Re: Absolute failure of Linux dead ahead? ("Mr Foo Bar")
Re: Backing out of ext3 filesystem (C. Chan)
Re: Absolute failure of Linux dead ahead? (Jon)
Re: Backing out of ext3 filesystem (Marc SCHAEFER)
Re: Electric Fence for C++ ??? ([EMAIL PROTECTED])
Re: Binary compatibility: what kind of crack are they smoking? (Mario Klebsch)
Re: Binary compatibility: what kind of crack are they smoking? (Mario Klebsch)
Re: Absolute failure of Linux dead ahead? (Wolfgang Weisselberg)
Re: Semaphore quustion ... part 2!! Bug ? ("Lawrence K. Chen, P.Eng.")
Re: Why a file system ? (Grant Edwards)
Re: Absolute failure of Linux dead ahead? (Jon)
Re: Absolute failure of Linux dead ahead? (Kaz Kylheku)
Re: Binary compatibility: what kind of crack are they smoking? (Mario Klebsch)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Michael C. Vergallen)
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 16:20:03 GMT
In article <89lvjg$r92$[EMAIL PROTECTED]>, Joseph T. Adams wrote:
>History may well look at RMS as one of the most influential (and
>perhaps underappreciated) individuals of the late 20th century.
>Linus, ESR, Larry Wall, and various others have been as well, but I
>believe all of these folks have acknowledged that but for RMS and his
>work, theirs never would have happened.
Actually Linus ,the FSF and all the unnamed others have made Unix
systems available to the masses... Sun han been forced to acknowledge
that freeing up their Source was the only way to move forward becuase some
things Sun does well namely SMP on large systems. Linux will improve by
this by allowing more poeple to see what kind of finetuning is needed to
make Linux scale like solaris does now ( 64 CPU's etc..) aldo it seems that
poeple have been able to scale linux to 32 nodes on a system based on Sparc
1 CPU's.
Michael
--
Michael C. Vergallen A.k.A. Mad Mike,
Sportstraat 28 http://www.double-barrel.be/mvergall/
B 9000 Gent ftp://ftp.double-barrel.be/pub/linux/
Belgium tel : 32-9-2227764 Fax : 32-9-2224976
------------------------------
From: [EMAIL PROTECTED] (Donovan Rebbechi)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Needed: A General Solution For The Lib/Distro Version Problem (was:
Binary compatibility...
Date: 2 Mar 2000 16:20:17 GMT
On 2 Mar 2000 10:10:07 GMT, Mark S. Bilk wrote:
> 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).
Exactly. Binaries have these kinds of problems.
> 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.
Not usually a problem. Most distributions will install an
up to date compiler. The compiling method will work well
assuming of course that the source is available. Moreover,
compiles get faster as CPUs do.
> I don't know if this guarantees that there will be no
> conflicts, but commercial applications generally don't
> come with source.
The commercial apps IMO should just ship with everything statically
linked except libc. And they should ship with a copy of the libc version they
need. ( this is what applix does )
>There's also the additional complexity of different Linux
>distributions having corresponding files in different places
>in the filesystem.
Yep.
I think they need to quit quarreling and get LSB up and running.
>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.
Well they would come true if the distributors were willing to get something
like LSB on the road.
>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.
Impossible. A more realistic goal would be that the packages ship
in some format that includes this information.
> 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 believe this has already been done. You can install multiple versions
of the same runtime. Compile time is more difficult though.
>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 think they need to do some more work on LSB.
--
Donovan
------------------------------
From: "Mr Foo Bar" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Thu, 2 Mar 2000 16:57:13 -0000
<snip>
>
> Well, I really don't care that much, however - I believe 64+ bit
> machines will be the norm before 2038 (and I'll be eighty by then ;-)
Yes and drawing a pension ? Into which you made contributions ? Starting
before 2000 ? :-)
------------------------------
From: [EMAIL PROTECTED] (C. Chan)
Subject: Re: Backing out of ext3 filesystem
Date: 2 Mar 2000 11:16:45 -0600
In article <[EMAIL PROTECTED]>,
Sander van Malssen <Anonymous, Reply> wrote:
>
>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
That's what I thought, but when I tried it I got:
Feb 29 13:49:23 localhost kernel: EXT2-fs: ide0(3,3): couldn't mount
because of unsupported optional features.
I'm pretty certain the filesystem was cleanly unmounted under ext3.
--
C. Chan < [EMAIL PROTECTED] >
PGP Public Key: finger [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Jon)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Thu, 02 Mar 2000 17:52:16 GMT
On Thu, 02 Mar 2000 08:20:02 -0500, mlw <[EMAIL PROTECTED]>
wrote:
> > > 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.
>
> I am not sure that I care about this one, it is 37 years away. In 37
> years, 64 bit computers will be obsolete.
This is precisely the logic that *created* the Y2k problem.
Thinking that the problem will go away by itself due to software
or hardware obsolesence is a huge mistake. Anything you write
today that will break in 2038 and happens to have your name on it
will generate a following of People Who Curse Your Name in 37
years. Corporations have a nasty tendency to buy/invest only
once and hire consultants to fix things later on. This results
in much longer than expected lifespans for hardware and software.
Jon
------------------------------
From: Marc SCHAEFER <[EMAIL PROTECTED]>
Subject: Re: Backing out of ext3 filesystem
Date: 2 Mar 2000 12:11:21 GMT
C. Chan <[EMAIL PROTECTED]> 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
Yes, the journal is just a plain file. However, please mount it as
ext3 first, then umount (so that transactions are correctly recovered),
then mount as ext2 and remove the journal file (if you want).
: filesystem then be unmounted and remounted again as ext3, and if
: so does the journal need to be cleared?
I would clear it (it's not very difficult).
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Electric Fence for C++ ???
Date: 02 Mar 2000 12:56:27 -0500
It will only work if you manually link. At least that's true on
glibc2.1.
Otherwise g++ will put -lc before -lefence.
------------------------------
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: Thu, 2 Mar 2000 19:51:01 +0100
Ian Molton <[EMAIL PROTECTED]> writes:
>Mario Klebsch wrote:
>>
>> 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)?
>I think this /proves/ its a troll...
Hey, that are you thinking of me? This thread was about binary
compatibility and ABIs, so what does a specification like GNU/Linux
offer on this one? There probably are lots of GNU/Linux systems (i
also have one), but what do they offer for binary distributed
software other than the common interface of the linux kernel?
Calling all Linux based system GNU/Linux does not make them compatible
to each other.
BTW, Binaries are the only reason, why I am using Linux. If this does
not work reliable, and I can only run programs, where the source is
available, I would switch to one of the BSD variants immediately.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
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: Thu, 2 Mar 2000 19:43:56 +0100
Gregory Neil Bastow <[EMAIL PROTECTED]> writes:
>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.
I realized that, too! I never wrote smething else.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Wolfgang Weisselberg)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: 2 Mar 2000 19:53:00 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 02 Mar 2000 17:52:16 GMT,
Jon <[EMAIL PROTECTED]> wrote:
> On Thu, 02 Mar 2000 08:20:02 -0500, mlw <[EMAIL PROTECTED]>
> wrote:
[2038]
> > I am not sure that I care about this one, it is 37 years away. In 37
> > years, 64 bit computers will be obsolete.
> This is precisely the logic that *created* the Y2k problem.
Yep, but it's not applicable ...
> Thinking that the problem will go away by itself due to software
> or hardware obsolesence is a huge mistake.
How many machines do *you* know that are in active use today
*and* were so 15,20,30 years ago?
Also the 2038-problem differs because it is Not There on 64bit
machines with any semi-well written software (which uses the time
struct). Thus, repair means just a recompile on a 64bit machine.
Since you'll have to recompile anyway, there's no problem.
There's no such fix for 00-stupidity and 101 incompatible ways
of comparing times.
-Wolfgang
------------------------------
From: "Lawrence K. Chen, P.Eng." <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Semaphore quustion ... part 2!! Bug ?
Date: Thu, 02 Mar 2000 14:36:13 -0500
Well, we're talking about Linux here....it doesn't necessary follow Unix....I
know the problem has bitten me before in porting code that has worked for
years on other Unix platforms.
But, this problem lies somewhere in the kernel.....but I don't really know
what I need to be looking for to see why it isn't happening.
There's a queue for semaphores in there, but I can't tell from the comment
header if its supposed to work or not.
I believe this is the problem.....
The semop call in the kernel does the check to see if the requested operation
would block by doing it and then it checks the queue to see if there are any
operations that are waiting...if an operation would block, it undoes the
operations that it did complete and queues up the request and goes to sleep.
Checking the queue for operations that are waiting to be woken up....doesn't
necessary translate to the operation being allowed to occur.
Perhaps...what semop should do is check if there is a request pending in the
queue on the semaphore first....(FIFO).
[EMAIL PROTECTED] wrote:
>
> 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.
--
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: grant@nowhere. (Grant Edwards)
Subject: Re: Why a file system ?
Date: Thu, 02 Mar 2000 20:31:43 GMT
In article <[EMAIL PROTECTED]>, Nicolas Boulay wrote:
>> Have a look what a rich world you find just in the /proc filesystem -
>> you will probably be amazed.
>
>A file is nearly everything but some peripherical need more speed like
>video card, so you have to find an other system !
Nope.
$ man mmap
--
Grant Edwards grante Yow! Psychoanalysis?? I
at thought this was a nude
visi.com rap session!!!
------------------------------
From: [EMAIL PROTECTED] (Jon)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Thu, 02 Mar 2000 20:41:25 GMT
On 2 Mar 2000 19:53:00 GMT, [EMAIL PROTECTED]
(Wolfgang Weisselberg) wrote:
> On Thu, 02 Mar 2000 17:52:16 GMT,
> Jon <[EMAIL PROTECTED]> wrote:
> > On Thu, 02 Mar 2000 08:20:02 -0500, mlw <[EMAIL PROTECTED]>
> > wrote:
>
> [2038]
> > > I am not sure that I care about this one, it is 37 years away. In 37
> > > years, 64 bit computers will be obsolete.
>
> > This is precisely the logic that *created* the Y2k problem.
>
> Yep, but it's not applicable ...
>
> > Thinking that the problem will go away by itself due to software
> > or hardware obsolesence is a huge mistake.
>
> How many machines do *you* know that are in active use today
> *and* were so 15,20,30 years ago?
2 that I've worked with personally. There are thousands of
others... witness the demand for Cobol programmers that occured
in 1999.
> Also the 2038-problem differs because it is Not There on 64bit
> machines with any semi-well written software (which uses the time
> struct). Thus, repair means just a recompile on a 64bit machine.
> Since you'll have to recompile anyway, there's no problem.
This assumes the hardware will be replaced. This is not always
true. Take XYZ Corp. who just invested $UmpteenMillion in their
new WhizBang5000 Unix-based computer system. There's a *very*
good chance that system will still be there in 2038, operating
all of XYZ Corp.'s critical accounting and MRP functions. Why
replace it? It cost a whole lotta cash and it still works just
fine. Beside that, how would XYZ explain to their investors that
they need to spend $UmpteenMillions times 2 to buy an all new
system, just because their old multimillion dollar machine can't
figure out what year it is?
Jon
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 02 Mar 2000 20:43:17 GMT
On Thu, 02 Mar 2000 17:52:16 GMT, Jon <[EMAIL PROTECTED]> wrote:
>On Thu, 02 Mar 2000 08:20:02 -0500, mlw <[EMAIL PROTECTED]>
>wrote:
>
>> > > 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.
>>
>> I am not sure that I care about this one, it is 37 years away. In 37
>> years, 64 bit computers will be obsolete.
>
>This is precisely the logic that *created* the Y2k problem.
Not exactly. We have the abstract time_t type which can be widened and
code can be recompiled. Correctly written programs don't depend on the
specific representation of time_t. They use abstract functions for manipulating
it, such as difftime(), and use robust time representations for communicating
across a network or storing time into files.
Those programs have a Y2037 problem today which will go away when they are
recompiled.
On the other hand, the COBOL spewing mainframe nutbags, and other programmer
types, that used two digit fields created a problem by not *abstracting* time
related code. The two digit representation was explicitly woven into the
program logic. Recompiling the software doesn't help, because there is no
straightforward way to fix the time abstraction in one place.
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Date: Thu, 2 Mar 2000 20:05:09 +0100
Wolfram Gloger <[EMAIL PROTECTED]> writes:
>[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?
I have done, and I must admit, I learned something new, that mitigates
the problem. The linker now refuses to load the X11 libraries based on
libc5 with programs based on libc6. Why can't the linker get this
information from the libs?
>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
Whow, they solved a problem, that would never have orrured, when at
least each major change to the interface of a library would have
relsulted in a changed filename, too. Yes, in this respect, it is
different from LD_LIBRARY_PATH.
73, Mario
--
Mario Klebsch [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
******************************
