Re: RFC

["Robert W. Current Jr. Ph.D." <current@hel-inc.com>]

On Wed, 15 Mar 2000, Aaron Gaudio wrote a very long reply:

-- Quick comments, I'll reply completely tonight --

> Why should vendors and developers have to worry about packaging up
> their software in every conceivable package format? Many give up and let
> third parties do it, but this is not a good solution either because it makes
> such packages less accessible to the people who want them and don't necessarily
> want to compile their own.

A lot of this seems to miss the point that if a standard installation
location, and standard method of script handling, and a standard format
for storing information about what packages contain is defined, the
packaging is totally irrelevent.

If .debs and .rpms write to the same area with the same style of info
about what they installed, you can use both on the same system and not
have any problems.  (if you think it's impossable or impractical, then I
think we need to look over what alien does.)

> Perhaps, but this should be kept to a minimum. LSB is not a standards
> think-tank trying to guide the course of Linux. They are merely trying to
> document the de facto standards, only making directional decisions when
> no de facto standard is obvious. At least, this is how I understood it.

If de facto standards were to be used, then it's pointless to have a LSB.
you would end up just lettin the person who sells the most disks discribe
the standard.  

> Top down standards rarely work, and even more rarely are adhered to. LSB
> should not be in the business of such work, it should rather be collating
> what's already out there, keeping in mind that some contraversial decisions
> might have to be made, but should be kept to a minimum.

I don't want to get into that argument....  It's like trying to sell "Open
Source is secure" or something.  "rarely work" is a statement that I want
nothing to do with.

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!

I for one truely believe there are enough talanted people interested in
seeing the LSB work that it has a chance.  I truely believe that if the
standards are based on some logic, the people sitting at the table will
all listen.

So, yes, that is a "top down" standard.  That's what I believe it should
be.  To say it should just list the de facto standards sounds like it's
just wasting everyones time.

> > As a result, "Linux" should be defined as "An Operating System" and the
> > LSB should be working to define "The OS" and not "Linux Software."  The
> > blurred line of where the OS ends, and where the software starts is the
> > fundumental thing that has caused a complete lack of progress in
> > defining what the LSB is and does since it's very beginning.
> 
> Where exactly is this line? Technically, it would be at the kernel. Linux is
> the kernel, and all else is the software. Having the LSB issue a kernel
> standardization would not only be futile, it would help little in terms
> of compatibility. 

(I hope your not taking this personally, I tend to write somewhat flamable
stuff to make the debate more interesting, nothing personal).

Are you a lawyer for Microsoft??  "What is Linux?"  Come on.

Call it a kernel, call it whatever, that's not the discussion the LSB
needs to get involved with.

L S B.  Linux is one word in that.  Standard is another.  And Base ...

Linux = It's going to be/contain/involve Linux

Standard = Setting some "common ground" for those who want to use it to
work from.

Base = It's NOT to be involved with the software.  It's just the minimal
basics of a system.  Netscape is not a "base" application.

If you want to argue what the hell "base" means, you can gladly do it for
days, weeks, months, years... but not with me...

In this context, for this project, base means "minimal set required to
build on."

> > It's time to draw the line in the sand.  It's time to lay down "what the
> > OS is" and "where the software sits on the OS."  That is the struggle. 
> > That must be done.  Once this issue is addressed, and finally laid to
> > rest, THEN, and ONLY THEN, will we be able to move forward onto the new
> > frontier.
> 
> That is, IMO, what the LSB is doing. Your chief complaint seems to be that
> you don't include some of the things that LSB considers the OS. Let's not
> throw out the entire spec because it differs on your opinion of which
> software belongs in that definition, though. Deal with such differences
> individually.

Absoluely.  I will argue that till the bitter end if nessessary, and I
just might have to do that.

I do NOT, I repeat, NOT, accept that X, any X libaries, any X tools, or
anything to do with X is part of a "base."

BULL.  Sure X is commonly used, sure it should be standardized, but it's
NOT THE BASE OF LINUX!  SPIN IT OFF TO ANOTHER COMITTEE, put it in a
seperate layer called something else.

I think far to many people are underestimateing the amount of work that
will go into defining the base.  If you set up the base without X, you
still have to deal with issues such as:

Version Numbers?  (Kernel X and glibc Y make LSB v0.1?)
Init Issues
Test Suites
Documentation
Clasification of "needed" vs. "un-nessessary" applications...


Why confuse the whole issue with X?  May 18th 1998.  Yes 1998, when the
LSB started.  Where has it gotten?

Not to say that people haven't done a lot of good, but the fact remains, X
is a lot of extra, un-nessary work to define a "Base."

> These issues are discussed in broad strokes in the mission statement. Are you
> suggesting that the LSB should change their mission statement, which does not
> limit itself to what you are proposing above.

Uh... *THUMP*   Clue bat....  

YES!

LSB should very seriously consider changing it's mission statement.

Promoting a set of standards is vague!  (Posix, FHS, we like these, cheer,
cheer cheer!!!  Hip Hip Horray!)

F that...

The statement should read:

The LSB is working to define a basic set of standards that Linux
distributions can VOLENTERLY comply to, in order to aid ISV's, software
developers, system administrators, and system users.  In as such, broad
UNIX standards (POSIX, FHS, etc..) will be applied, as well as
clearification of how these standards apply to Linux specifically.

> > Software, where do we draw the line?
> > If it's "required" for POSIX compliance, it's "Standard."
> > If it's undeniably "standard issue", it's "standard."
> 
> Here's the problem. What does "undeniably standard issue" mean? It will
> mean different things to different people. For instance, you feel that
> X11 is not "undeniably standard issue" because a server can run without
> X11. True, but not including some mention of X11 in LSB leaves out an
> entire class of applications whose vendors will want to know what to 
> expect from an X-enabled system (e.g. what toolkit to use?) and that is
> to the detriment of compatibility, the chief mission of the LSB.

Heh.. Yes, this is the issue.

If you need an answer from me, I'll give you one.  10M

There is no reason to have a base system over 10M

put whatever you think you need in there, but that's all you get.

No X.


But, this is where I would like to see some discussion.  What is the base,
what isn't.


And, it is NOT NOT NOT deterimental to compatibility, quite the oppisite!
If you know it's suppose to be in "the base" and your system is LSB
compliant, it's there <period>   If you know you need it for your software
to install, and it's not part of "the base" you know absolutely with out a
doubt, that it's not going to be in "the base" so don't look there, you
know you should be checking for it in the "installed package database"
wherever that is... (depending on distribution now, maybe standardized
later).


Quick nit pick: (I'll finish later)

> > --------------------
> > Defined: Generally meaning "Open Source" but not defined to mean only
> > compiled on the local system from source, or only GNU or GPL.  Only
> > meaning software that is available to users in SOME way, so that they
> > may compile it themselves.
> 
> All GNU (and BSD and a variety of others) software is compilable by the user,
> therefore even "core" utilities would fall under this definition.

Your definately reading this totally wrong, and totally out of context.

If it's part of "the base" then by definition it's not /usr/local, but
/usr

Pfffttt..   Sorry, it's when i got here I realized I am going to have to
sit down and explain this to everyone better tonight.

Compilable SOFTWARE, that is _not_ part of the _base_ goes in /usr/local,
according to my PROPOSAL.

See?  Maybe not... I don't know.  it's soo fuc... clear to me right now i
think I am just frusturated that I can't seem to make everyone understand
what I am saying.

> /usr/local/etc is not prescribed by the FHS. /etc is not really for
> scripts, although I imagine one could put some in there (except, of course,
> initscripts which are a little different). /etc is for configuration.

Tangant... Tangent alert!

Scripts?  Well, that's all fine and dandy... My personal /etc is full of
so many hand made scripts that it's not even funny... but that's totally
irrelevent also....

the point is, in some init levels, some services start... in others, other
services start.

By default, I PROPOSE, "base" services all start in the init levels that
correspond to stuff in /usr,  multi-user/network initlevels allow stuff in
/usr/local to start...

The devision goes cleanly into both FHS and init if you look at it that
way.  but again, i feel i am glossing over what I am trying to say, and
the picture might still not be clear to some people.

k

All in all, good discussion...  I gotta run, I'll get back to it tonight.

(again, warning, I'm colorful occasionally, but i don't mean any of it
directed at anyone personally, I don't wanna turn this into Usenet circa
1995)

Rob C.