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@corel.com]
Sent: Thursday, March 16, 2000 8:05 AM
To: lsb-discuss@lists.linuxbase.org
Subject: Re: RFCI'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@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@lists.linuxbase.org
with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org--
To UNSUBSCRIBE, email to lsb-discuss-request@lists.linuxbase.org
with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org
begin:vcard n:Rackus;Phil tel;fax:(613) 761 9175 tel;work:(613) 728-0826 x-mozilla-html:FALSE url:http://opensource.corel.com org:;<A HREF="http://opensource.corel.com";><IMG SRC="http://linux.corel.com/products/linux_os/graphics/1199_2726_gra_linuxpower.gif";><BR><FONT SIZE=2>opensource.corel.com</FONT></A><BR> version:2.1 email;internet:philipr@corel.ca title:Product Development Manager Opensource Communications adr;quoted-printable:;;1600 Carling Avenue=0D=0A;Ottawa;Ontario;K1Z 8R7;Canada x-mozilla-cpt:;19504 fn:Phil Rackus end:vcard