[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC



On Wed, 15 Mar 2000, Jeffrey Watts wrote:

> On Wed, 15 Mar 2000, Robert W. Current Jr. Ph.D. wrote:
> 
> > I totally and firmly disagree.  The LSB is a committee of
> > representitives from all major distributions who have choosen to sit
> > down at a table and form some standards.  That was the goal.  To now
> > stand up from the table and say "Red Hat sells the most disks, so
> > RPM's are standard, we can all go home and just follow Red Hat" is
> > just total CRAP.  Forgive me, but it's CRAP!
> 
> Your conversation smacks of advocacy, and implies that Red Hat is
> dictating the standards, which is unfair to say the least.  Either you
> don't have experience with many Linux distributions (from your thread I
> gather that you use BSD and maybe Debian), or you have a problem
> communicating effectively in English (which is suggested by your frequent
> misspellings and poor command of grammar).

Divergance from the issues, and into personal attacks?

I have used (Regularly):
Solaris
DEC UNIX (now Tru64)
IRIX
FreeBSD
NetBSD
Slackware
Debian
Redhat
Mandrake
Open Linux
SuSE

no, that's not everything, but if you want me to state qualifications, I
don't understand the point?

SuSE and Red Hat both use .rpm's, true, but the rpm's aren't even
"standard" (SuSE doesn't use version numbers, and for a long time followed
what looked to be rpm'ed up Slackware Tarballs).

yea, my grammer sucks, and my spelling sucks, cause frankly, I type fast,
and don't see it's an issue for general email.


What the heck does that have to do with the issue?

> It is good that you are stimulating conversation in lsb-discuss, but I
> fear that most of your comments are simply noise.  I've been lurking here
> for a while, and I am personally interested in Linux standards -- but I
> hate to see this effort get confused by a discordant voice simply because
> that voice doesn't understand the goals or role of the LSB.

I am not "just finding out about the LSB."  I suggest you look back at
where the LSB started if you think I don't know anything about it.

I am speaking up now, because I feel that it's gone too far off on a
tangent.

> Well, that makes the LSB useful to about 10% of the application makers out
> there.  Your arguments are self-defeating.

Again, hogwash.

LSB is the cornerstone.  Not a building.  You build on the cornerstone.

Making the LSB not require X doesn't mean that the LSB will prohibit the
use of X.  (If it did, then your statment would make sence, but I never
suggested that the LSB define a base set that made it impossable to use
X).

I am saying, there is a base.  Add X as a "layer."  Stuart did well in
discribing it as "middleware," and I partially agree with him.  But I
think in his discription, he isn't seeing that "base" and "middle" are
layers, and IMHO, the LSB should be the "base" that the "middleware" sits
on.

ISV's, and GNU/GPL/BSD/etc programmers will most likely have to contend
with some "dependancy" outside the base, no matter how big you make the
base.  Therefore, there is no logical reason to make the base big enouth
to make everyone happy... It will just end up getting too big and
clumbersome.

Therefore, you make a "base" and you lay out the structure for the
"middleware" (such as X), to be added.  Then maybe you can have a
reasonable discussion about package management.

X isn't a "base" componant of Linux.

X is software.

X is (according to your numbers) a "dependancy" for 90% of Linux software,
but a dependancy does not make it a base application.  It's just a
dependancy.

Give it's great importance as a dependancy, surely, it is the ideal thing
to consider when it comes to "how to allow packages/software to be added
on top of the base."  How do you test for X?  Where is it expected to be?
Should there be a "package database" somewhere that lists that X is
installed, what files are included, and what versions?

But, that's just structure for software to build into, not actually
"base."

What if Berlin takes a quantum leap?  What if X is obsolete?  What if 4.0
of XFree86 is just a "tiny" step for XFree86, and 5.0 comes along and
makes radical changes?  What of the new Linux PDA's that obviously don't
use standard X?

X is just too much of a "fuzzy" flexability to be considered "base."

As well, I would say, what of Commercial X?  The base is LSB-Linux because
all software is common, but if you were to pull out one X variant and put
in another (MetroX? XiGraphics?) then how can you say it's the same base
set when it clearly is not.

Rob.

(Sorry, I only profread stuff I am bing payed to chck it .. :P   My life
and time is too short to waste it on that...)


Reply to: