RFC

[Robert W. Current]

djb at redhat.com wrote:
> 
> > Arguably, yes.  And, if it's small middleware, I don't have an issue
> > with considering it's inclusion.  But, libncurses amounts to what, 4M or
> > so?  That's definitely borderline, but arguable.  X, I would have to
> > differ on that point, based on size.
> > $ pwd
> > /usr/X11R6/lib
> > $ du -sh
> > 47M     .
> >
> > To me, that's a scary base.  It sounds like your only talking about ISVs
> > who want to do GUI workstation environments if you want to consider
> > that.  If I had time, I would reference the several dozen articles on
> > why Linux can do what Windows can, solely because it's scalable, and now
> > possibly headed towards the embedded market.
> 
> Oh, so you're worried about size and simply want a standard embedded
> Linux.  Go get EL/IX.

This is exactly the bad attitude that I pray the LSB will not embody. 
"If ya don't like it, piss off."

Size is important.

> 
> Honestly, I don't see what *size* has to do with what gets standardized
> and what doesn't.

Absolutely correct, it has NOTHING to do with it, your missing the
point.

Everything may eventually get standardized.  That's not the issue.

The issue is "what chunk to you pick to spec first, and for what goal,
and what claims are you making about the spec your defining."

>  It's about what ISVs need, period, to build a usable
> application on.  This should probably be more narrowly defined as for
> a server or desktop app and not necessarily an embedded one (or even
> a clustered one).

Or servers.  Or appliances.  Or ... 

So, your now saying, the LSB is a desktop only spec.  I don't think I
honestly believe that starting with the biggest messiest section is the
place to start.

ISVs need a standard, yes.  Standardizing something for only the ISVs
doing desktop applications is also limiting the usefulness of LSB.

X is not a server app..  X is used by stuff like PHP in apache on
occasion, but hardly something I would call "a standard server
requirement."

/me bites my tongue about the frigging 100+M Red Hat install base.

> I think what you really want are different levels of certification.  Right
> now, the LSB is shooting for the very large middle level.  There are tiny
> but growing small levels as well as larger levels that might need to be
> standardized too.  But you have to start somewhere.

Abso-frigging-lutely (oh, sorry, grammar issue again).  Absolutely!  I
totally and whole heartedly agree.

The smaller, and more logical you start with a level, the faster and
more logical your levels will grow.

If what it takes is a kernel and a shell alone being defined as "CORE
LSB" and then the next layer up being called "System LSB,"  Then throw
"X LSB" on top of that.  At least that makes sense.

But to just throw it all in the first round is creating a workload that
is just to big, with no logical foundation to build on.
 
> > Requirements such as X for some ISV software should be addressed.  But
> > they should be addressed through a standard package accounting system.
> 
> Sorry, I don't buy it.  Why not just say "well, the kernel and bash
> are *the* standard...everything else is just a dependency."???  You're
> right, there is a line.  You're just way out on some side that no one
> but you agrees with.

I think you should read more of the comments from actual system
administrators on these issues.

I'm trying to keep from going ballistic here... But I really think there
are too many people who work "creating" software working on the LSB, and
far to few seasoned administrators.

Brilliant coded you may be, I have no doubt in my mind that most system
admins would prefer to keep their "OS Updates" and "Software Updates" a
lot more separated than most Linux distributions now actually do.

> Well, damn....not all ISVs need bash, either.  What's your point?  Most
> do need X.  Deal.

Gad... "Deal"  Pfft... 

Nope.  Either tell me that your going to close the spec, or make it
logical why as a system admin I should accept installing X as base on 20
different servers for no good reason other than Donnie said "Deal."

if you don't wanna hear from users, then don't ask people to join
discussion lists..

What is this a pissing contest?  I am not interested!  I am working with
4 other people, working our frigging asses off trying to develop what I
believe will be 2 solid, usable, and logical distributions.  I think the
LSB could be very very useful, and as such, would be willing to help
it/support it.  But if things are going to turn into an ugly mess that
includes bloat and will take another 5 years to complete, why bother?

I'm looking at what has been done, and what hasn't.  And I am impressed
with most of the progress, but I think the LSB is going to shoot itself
in the foot if it comes out with all these requirements.

I'd rather see the 20+ little pissy distributions stamp "LSB compliant"
on their disks in 6 months, than see a LSB spec that will take 2 years
and only the biggest 4 will comply to.

No one is using the LSB, a LSB compliant distribution doesn't exist. 
Why not start with the basics, get it out there, get it accepted, then
grow it to encompass more?  Why make something that is all encompassing
(which in turn rules out the nitch distributions) that will be much
harder for people to suddenly comply to later?