RFC - levels

Philip Rackus philipr at corel.com
Thu Mar 16 07:48:29 PST 2000


Agreed.  I was not trying to get into details of how things can modularized -
only that  modularization of the standard can allow for a greater degree of
flexibility.  Once the group decides that breaking things into smaller
components is the way to proceed, then we can start investigating different ways
of accomplishing this and (hopefully) arrive at some consensus as to how to go
ahead.

Phil

"Oldman, Dan" wrote:

> I think you are fooling yourselves if you think that a taxonomy of OS (and
> other) services can be put into a simple level scheme. Think instead about
> grouping services such as base kernel, X, networking, etc. into independent
> "services". An application should be able to query its environment to
> confirm that it has the services it needs (at appropriate revision levels).
> Services should also be able to declare and query their own service needs.

> The LSB's top-level organizational problem then becomes one of naming and
> defining these groups. The details of any group can be farmed out to
> subcommittees. No distribution should be obligated to provide (or install)
> all LSB-defined services, but applications will need to say what they need
> (at both install and run time). Such a mechanism should support a standard

> way to determine requirements and install software from appropriate sources
> (distribution media, sources that are recompiled from the web, etc.)
>
> I'm not an expert on the current distribution methods such as RPM. Some may
> have already addressed this problem from a technical perspective.
>
> -Dan
>
> -----Original Message-----
> From: Philip Rackus [mailto:philipr at corel.com]
> Sent: Thursday, March 16, 2000 8:05 AM
> To: lsb-discuss at lists.linuxbase.org
> Subject: Re: RFC
>
> I've been following this thread closely, and I'm wondering if there isn't
> room for compromise.
>
> If everyone agrees that eventually the goal of the LSB is to define
> different level of standards, how much extra time would it take to define a
> base spec (without X) called ..say LSB 1.0, and the spec including X called
> LSB 1.1 ?  In this scenario 1.0 would basically be a subset of the 1.1 - so
> a distribution that is 1.1 certified would by default be 1.0 certified as
> well.
>
> (This isn't flame bait, just a request for information)
>
> Phil
>
> "Robert W. Current" wrote:
>
> 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?
>
> --
> To UNSUBSCRIBE, email to lsb-discuss-request at lists.linuxbase.org
> with subject of "unsubscribe". Trouble? Email listmaster at lists.linuxbase.org
>
> --
> To UNSUBSCRIBE, email to lsb-discuss-request at lists.linuxbase.org
> with subject of "unsubscribe". Trouble? Email listmaster at lists.linuxbase.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20000316/c7314b11/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: philipr.vcf
Type: text/x-vcard
Size: 543 bytes
Desc: Card for Phil Rackus
Url : http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20000316/c7314b11/attachment.vcf 


More information about the lsb-discuss mailing list