Linux-Development-Sys Digest #730, Volume #7 Sun, 2 Apr 00 20:13:19 EDT
Contents:
Re: How compatible is Linux with .. Linux (Juergen Heinzl)
Re: Partition Access (Daniel Kiracofe)
Re: How compatible is Linux with .. Linux ("Peter T. Breuer")
Re: Partition Access ("Someone Insignificant")
Re: How compatible is Linux with .. Linux (Lee Webb)
Re: Partition Access ("Someone Insignificant")
Re: Partition Access ("Someone Insignificant")
Re: How compatible is Linux with .. Linux ([EMAIL PROTECTED])
Re: Partition Access (Daniel Kiracofe)
Re: Partition Access ("Someone Insignificant")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: Sun, 02 Apr 2000 22:20:04 GMT
In article <[EMAIL PROTECTED]>, H. McKame wrote:
>Hi
>
>My company is currently finishing its product on Red Hat 6.1.
>Given the multiplicity of Linux versions, we are worried about
>distributing our product on Linux in general.
>
>You out there that have already gone this route, could you please
>share your experience:
>
>- How compatible are Linux versions between vendors on the executable
>format (a.out), and on the object format (.o) ? On what Linux versions
>will a pre-link on RedHat 6.1 link and execute correctly ?
[...]
It depends 8-/
>- How does one measure this compatibility (egcs version? glibc
>version? xf86 version?)
glibc version and kernel. One problem is the glibc and all those
vendor specific patches as one cannot be 100 per cent sure a
binary compiled against glibc-2.x.y on one distribution runs
on another with glibc-2.x.y too. Been there, seen that, thanks
a lot RH.
Okay, first think to keep in mind is that a binary linked
against glibc-2.x.y will only run on machines where x and y
are equal or higher.
Say, development .. glibc-2.1.1. On site .. 2.1.1 (ok), 2.1.2 (ok),
2.1.3 (ok) but not the other way round, say development .. 2.1.3,
on site .. 2.1.1 (nada).
The kernel is another issue as not all system calls available
in 2.2.x are available in 2.0.x too.
So in possible use a test machine having the latest 2.0.x kernel
and glibc-2.1.1 installed. Both stock versions, not some distribution
specific source. If your stuff runs there it should give you some
confidence.
Of course it is up to you to set the limits like "at least kernel
2.2.0" a./o. "at least glibc-2.1.2".
>- How general is the rpm packaging format for the release?
It is not a universally used format but there are converters to
other formats, so this is not much of a problem. You still may
use both, RPM and a simple tar archive to avoid any hassle for
the customer.
You may consider a BETA programme too, say some selected customers
who are willing to run into trouble due to system dependencies
but getting the software for something less later on.
Cheers,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: Daniel Kiracofe <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development,comp.os.linux.development.apps,linux.dev.c-programming,linux.redhat.development
Subject: Re: Partition Access
Date: Sun, 02 Apr 2000 17:32:58 -0400
Someone Insignificant wrote:
>
> Ive been haveing a bit of trouble locateing information on partition access
> in Linux. The Linux information scattered throughout the internet has an
> abundance of knowledge aimed at users, system administrators, etc, but for a
> developer, information is becomming harder to find.
>
> Specifically, what I need to be able to do is:
>
> a) determine the disk drives attached to a system.
> b) determine the partitions on those disk drives.
> c) seek/read/write blocks on any of the detected partitions.
>
For a developer, the source for fdisk might not be a bad place to
start...
--
/* Daniel */
E-mail: [EMAIL PROTECTED]
Webpage: http://www.cis.ohio-state.edu/~kiracofe
"Fear is only afraid of the absence of itself" - Mediocrates
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: 2 Apr 2000 22:30:38 GMT
In comp.os.linux.development.system Don Waugaman <[EMAIL PROTECTED]> wrote:
: In article <8c80ku$482$[EMAIL PROTECTED]>,
: Peter T. Breuer <[EMAIL PROTECTED]> wrote:
:>I recommend you to fly in a plane controlled by a software written by
:>a technical incompetent you were too "polite" to tell to go and fix
:>his software.
: You are equating politeness with inassertiveness. That's a singularly
: bad trap to fall into. Technical correction can be done in polite
: manner. Being polite in correcting someone does not mean being some
: kind of milquetoast. Pointing someone asking for help in the right
: direction does not give you free rein to insult their ignorance (which
: is *not* the same as a lack of intelligence).
Interesting point. It's a well-phrased point and has considerable merit
(but I'm hardly likely to put bruised feelings before bruised truth, or
I wouldn't be being honest with myself or you).
Ignorance is quite orthogonal to intelligence, and I'm quite capable of
detecting the latter I hope! Indeed, ignorance is very often a hallmark
of intelligence, since an intelligent person doesn't rely on learning by
rote.
That said, a person asking about how to test their own software on
linux distributions gets a solid zero for intelligence. They
can't be serious!
: Compare for instance:
: "From your question, I'm not sure you have enough of a technical background
: on Linux at the moment to be able to do much with the answer I'd have to
: give you. Perhaps you should either rephrase the question somewhat, giving
: a brief overview of the issues you know about already, or have someone with
: a broader technical background ask this question."
Nice :-). This reminds me of a scene in "A mote in God's Eye". The
part where flag captain Blaine tells Renner that the tactful way to put
it to the senator would have been "that turns out not to be the case".
(Sorry if the names are wrong - it's been about ten years since I read
that book).
: with what you wrote. This makes substantially the same point you made in
: your initial reply, and cuts no slack by comparison, but is *more* likely
: to have a positive response simply because it is *more polite*.
Quite possibly. I'm not sure that it's worth it, however. The software
in question can't be worth much or a more technically rehearsed
person would have been placing the question, no? You'd expect a
responsible architect or group leader would have asked for directions to
the policy documents of the various distros, and contact points! Well,
they wouldn't even have asked on the newsgroup at all. Can you imagine
a person who has to organize and design software asking about libraries
and being unaware of configuration file placements, compiler issues,
standards, policies ...?
: Politeness is the oil that lubricates contact points in any system of two
: or more humans. Don't throw sand in the gears just because you think it's
: the only way to get your point across - that reflects more on you than on
: who you are communicating with.
If you examine the original reply again, you'll find its not as brusque
as you are making it out to be. I'd quote it here, if I weren't working
across a modem link and an xterm.
Peter
------------------------------
From: "Someone Insignificant" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development,comp.os.linux.development.apps,linux.dev.c-programming,linux.redhat.development
Subject: Re: Partition Access
Date: Sun, 02 Apr 2000 22:51:22 GMT
Mark, I have lost all patience and here is my response:
> > of the device, the number of blocks on the device. Also, standard calls
to
> > the C library lseek() function are limited to a maximum of 2 gig.
>
> then obviously you shouldn't use the 32b versions of lseek.
> Linux has supported 64b file operations for a while now, even on ia32.
>
I am aware that 64 bit file operations are supported....i was asking for
documentation on them. If they were not supported, one would not be able to
partition the drive to the limits that fdisk now currently supports.
> > Solutions such as reading the information from the /proc filesystem
simply
> > are not adequate. This would work fine if I were developing a shell
script
> > or simple program, however, this library is part of a much larger
system,
> > and needs fine grained control and as close a route to the source of the
> > information as possible.
>
> this is a specious argument, since the premise is that /proc is somehow
> not a fundamental means of kernel<>user communication. while there are
> some ioctls that might do some of the things you want, they're gradually
> disappearing, since /proc is very definitely the right way.
I never stated that the /proc filesystem was not valid. I simply stated that
it was not valid for my particular application. Im sorry that you felt
injured by these comments, however, I cant tell by your statement "the right
way" that you are still hanging on to the absolutes of childhood, and should
probably seek therapy. Im sure that were I to inspect the source code for
any of the filesystem currently available on linux, that they do not query
the /proc filesystem to obtain device information, and a knowledgeable
systems programmer will be able to verify this.
> > Its times like these when I wish I had a nice, cushy cubicle in RedHat,
just
> > down the hall from the fileing cabinet where this type of information is
> > undoubtedly stored, but, short of that, I am hopeing someone can throw
up
> > specific links to this type of info.
>
> you're drastically mistaken about the role of mere distribution-vendors
> like Redhat in the ongoing design of Linux.
>
Am I? Then why are quite a few of the original developers of Linux working
at RedHat? Including the developer of the raw device ( /dev/raw ), whom I
conversed with less than 2 days ago?
> > develop my application this way. Quite simply, dont bother. This is the
way
> > it needs to be written.
>
> you require someone to add "low-level" interfaces to the kernel
> to make you happy? that is not how it works. if you want to change
> the way Linux does it (/proc), then you must:
> - provide a good argument proving that that /proc is inadequate.
> - provide at least a skeleton of an implementation that is clearly
> better. note that this sort of information is not performance
> sensitive, so "better" means "more maintainable to the kernel",
> and to a minor extent "more usable at the user-level".
Never did I make mention for someone to add a special kernel hook or
interface for my benefit. I simply asked that if anyone knew of
documentation
that was available, for the interface(s) that already exist, please post
some links,
so that persons like myself may become educated on the finer points of
systems
programming, and persons like yourself will stop wandering the earth
shadowed
by a level of ignorance so great, that it gives rise for cause to rethink
darwin's
theories on evolution.
mike
[EMAIL PROTECTED]
------------------------------
From: Lee Webb <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: Sun, 02 Apr 2000 20:21:48 +0100
So does this mean that you are only a good programmer, or worthy of a decent
(and respectful) reply, if you're on the Kernel list?
Come on...let's quit this - everyone has a right to post to these newsgroups (be
they seasoned programmers, accomplished designers or NEWBIES), so don't try to
make others feel inferior or less capable than yourself.
One as "developed" as yourself should realise that everyone has to start from
somewhere. It's hard enough doing so without getting cut-down for posting (what
ONE indiviual) believes to be irrelevant or ridiculous.
Believe me, I'm not doubting for one moment that you don't know what you're
talking about, but a little respect doesn't hurt..
Lee.
--
Boycott Amazon: http://www.gnu.org/philosophy/amazon.html
"Peter T. Breuer" wrote:
>
> In comp.os.linux.development.apps Esteban Soto <[EMAIL PROTECTED]> wrote:
>
> : I just can't imagine a software capable of "controlling a plane" that was
> : written by a lonely programmer... i guess in the real world things are
> : usually built by groups of people... aka TEAMS.
>
> Is this relevant? Presumably the person in question has a team behind
> him! Or, I hope, in front.
>
> The precise answer to the precise question above is "it depends".
> Revolutionary software is usually written by one person, at least to the
> point where it becomes financially or socially interesting.
>
> : I'm sure Linux wouldn't have come this far if it was developed by a bunch of
> : unpolite, technically able people who could not comunicate.
>
> Err .. think again :-). Obviously you aren't on the kernel list!
>
> Peter
------------------------------
From: "Someone Insignificant" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development,comp.os.linux.development.apps,linux.dev.c-programming,linux.redhat.development
Subject: Re: Partition Access
Date: Sun, 02 Apr 2000 23:00:44 GMT
I received these harsh and reprehensible comments from someone
who decided that they would vent their marrital frustrations on me,
and didnt have the nerve to post his ramblings here.
Please, read and enjoy, knowing all the while that your programming
position at XYZ Company is secure. 8)
mike
[EMAIL PROTECTED]
ps. My reply can be found in this thread as well.
=================
> of the device, the number of blocks on the device. Also, standard calls to
> the C library lseek() function are limited to a maximum of 2 gig.
then obviously you shouldn't use the 32b versions of lseek.
Linux has supported 64b file operations for a while now, even on ia32.
> Solutions such as reading the information from the /proc filesystem simply
> are not adequate. This would work fine if I were developing a shell script
> or simple program, however, this library is part of a much larger system,
> and needs fine grained control and as close a route to the source of the
> information as possible.
this is a specious argument, since the premise is that /proc is somehow
not a fundamental means of kernel<>user communication. while there are
some ioctls that might do some of the things you want, they're gradually
disappearing, since /proc is very definitely the right way.
> Its times like these when I wish I had a nice, cushy cubicle in RedHat,
just
> down the hall from the fileing cabinet where this type of information is
> undoubtedly stored, but, short of that, I am hopeing someone can throw up
> specific links to this type of info.
you're drastically mistaken about the role of mere distribution-vendors
like Redhat in the ongoing design of Linux.
> develop my application this way. Quite simply, dont bother. This is the
way
> it needs to be written.
you require someone to add "low-level" interfaces to the kernel
to make you happy? that is not how it works. if you want to change
the way Linux does it (/proc), then you must:
- provide a good argument proving that that /proc is inadequate.
- provide at least a skeleton of an implementation that is clearly
better. note that this sort of information is not performance
sensitive, so "better" means "more maintainable to the kernel",
and to a minor extent "more usable at the user-level".
Mark Hahn.
[EMAIL PROTECTED]
------------------------------
From: "Someone Insignificant" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development,comp.os.linux.development.apps,linux.dev.c-programming,linux.redhat.development
Subject: Re: Partition Access
Date: Sun, 02 Apr 2000 23:03:59 GMT
Just in case Mark turns out to be the next Usenet serial killer,
goodbye and I love you all 8)
mike
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Reply-To: [EMAIL PROTECTED]
Date: Sun, 02 Apr 2000 23:38:03 GMT
Centuries ago, Nostradamus foresaw a time when Peter T. Breuer would say:
>In comp.os.linux.development.system Don Waugaman <[EMAIL PROTECTED]> wrote:
>: In article <8c80ku$482$[EMAIL PROTECTED]>,
>: Peter T. Breuer <[EMAIL PROTECTED]> wrote:
>:>I recommend you to fly in a plane controlled by a software written by
>:>a technical incompetent you were too "polite" to tell to go and fix
>:>his software.
>
>: You are equating politeness with inassertiveness. That's a singularly
>: bad trap to fall into. Technical correction can be done in polite
>: manner. Being polite in correcting someone does not mean being some
>: kind of milquetoast. Pointing someone asking for help in the right
>: direction does not give you free rein to insult their ignorance (which
>: is *not* the same as a lack of intelligence).
>
>Interesting point. It's a well-phrased point and has considerable merit
>(but I'm hardly likely to put bruised feelings before bruised truth, or
>I wouldn't be being honest with myself or you).
>
>Ignorance is quite orthogonal to intelligence, and I'm quite capable of
>detecting the latter I hope! Indeed, ignorance is very often a hallmark
>of intelligence, since an intelligent person doesn't rely on learning by
>rote.
Intelligence isn't as simple as measuring how high someone's "IQ" is;
it is an issue of many aspects.
There are people that are so "dramatically intelligent" that they are
virtually unable to communicate with other people. The level of thought
involves abstractions that aren't easy to put into words.
>That said, a person asking about how to test their own software on
>linux distributions gets a solid zero for intelligence. They
>can't be serious!
No, they may instead be getting a "solid zero for having all the clue
that they need."
The questions may result from *ignorance.* Unlike stupidity, and
possibly terminal rudeness, ignorance is a treatable condition.
The questions asked about how to test Linux apps may not have been
the *ideal* questions where *direct* answers would prove valuable.
In contrast, your responses have been so flavored with distain and
disrespect as to hide the other value of what you've suggested.
>: Compare for instance:
>
>: "From your question, I'm not sure you have enough of a technical background
>: on Linux at the moment to be able to do much with the answer I'd have to
>: give you. Perhaps you should either rephrase the question somewhat, giving
>: a brief overview of the issues you know about already, or have someone with
>: a broader technical background ask this question."
>
>Nice :-). This reminds me of a scene in "A mote in God's Eye". The
>part where flag captain Blaine tells Renner that the tactful way to put
>it to the senator would have been "that turns out not to be the case".
>(Sorry if the names are wrong - it's been about ten years since I read
>that book).
>
>: with what you wrote. This makes substantially the same point you made in
>: your initial reply, and cuts no slack by comparison, but is *more* likely
>: to have a positive response simply because it is *more polite*.
>
>Quite possibly. I'm not sure that it's worth it, however. The software
>in question can't be worth much or a more technically rehearsed
>person would have been placing the question, no? You'd expect a
>responsible architect or group leader would have asked for directions to
>the policy documents of the various distros, and contact points! Well,
>they wouldn't even have asked on the newsgroup at all. Can you imagine
>a person who has to organize and design software asking about libraries
>and being unaware of configuration file placements, compiler issues,
>standards, policies ...?
Give them a *bit* of benefit of doubt. They may have tried out
a Red Hat Linux CD install, and ported the software to run there.
And are now wondering how to deploy the software more widely.
Which doesn't justify asking if they're "responsible architects" or not.
--
Whatever is contradictory or paradoxical is called the back of God.
His face, where all exists in perfect harmony, cannot be seen by man.
[EMAIL PROTECTED] - - <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: Daniel Kiracofe <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development,comp.os.linux.development.apps,linux.dev.c-programming,linux.redhat.development
Subject: Re: Partition Access
Date: Sun, 02 Apr 2000 18:51:13 -0400
Mark Hahn wrote:
> > this is a specious argument, since the premise is that /proc is somehow
> > not a fundamental means of kernel<>user communication. while there are
> > some ioctls that might do some of the things you want, they're gradually
> > disappearing, since /proc is very definitely the right way.
Ah yes, /proc, The One True Kernel Interface. So tell me, why should
the kernel go to all the trouble of printing out it's data structures in
human readable ASCII and then have my program go all the trouble to
parse the ASCII, when I could just get a copy of the necessary struct
directly? /proc is great for humans, and I've used it with Perl before,
but from C, it's cumbersome...
--
/* Daniel */
E-mail: [EMAIL PROTECTED]
Webpage: http://www.cis.ohio-state.edu/~kiracofe
"Fear is only afraid of the absence of itself" - Mediocrates
------------------------------
From: "Someone Insignificant" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development,comp.os.linux.development.apps,linux.dev.c-programming,linux.redhat.development
Subject: Re: Partition Access
Date: Sun, 02 Apr 2000 22:53:41 GMT
Daniel,
In addition to being flamed by a user now calling himself "knowledgable",
I have
since located the source to "cfdisk" and I am disecting it know.
As soon as I gather enough information, I will post a toolkit for this
type of
programming somewhere, as I am not the only person who has been asking for
it.
Let me know if you would like a copy.
Mike
[EMAIL PROTECTED]
"Daniel Kiracofe" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Someone Insignificant wrote:
> >
> > Ive been haveing a bit of trouble locateing information on partition
access
> > in Linux. The Linux information scattered throughout the internet has an
> > abundance of knowledge aimed at users, system administrators, etc, but
for a
> > developer, information is becomming harder to find.
> >
> > Specifically, what I need to be able to do is:
> >
> > a) determine the disk drives attached to a system.
> > b) determine the partitions on those disk drives.
> > c) seek/read/write blocks on any of the detected partitions.
> >
>
> For a developer, the source for fdisk might not be a bad place to
> start...
>
> --
> /* Daniel */
> E-mail: [EMAIL PROTECTED]
> Webpage: http://www.cis.ohio-state.edu/~kiracofe
>
> "Fear is only afraid of the absence of itself" - Mediocrates
>
------------------------------
** 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
******************************
