>Message: 3
>Date: Wed, 27 Feb 2002 22:55:22 -0600
>From: David Douthitt <[EMAIL PROTECTED]>
>Subject: Re: [Leaf-devel] Re: Standards and due process :-)
>To: LEAF Development <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>
>On 2/27/02 at 4:28 PM, Serge Caron <[EMAIL PROTECTED]> wrote:
>
>> You are working under the premise that a file has one and
>> only one package of residence. Please note that this is an
>> observation and not a value judgment of any kind: AFAIK,
>> there is nothing wrong with this premise.
>
>Understood - and true.
>
[snip]
>I don't think you CAN standardize on a mapping. After all, in Oxygen,
>so many things are packages that are part of root.lrp in Dachstein or
>Bering...
>
>> The later claim means that the base system is not extensible.
>
>Don't give up; show us how to be more flexible....
I will do no such thing :-) I will however share my premises.
I view LEAF/LRP as a rich environment to which many people have contributed
over the years and to which many more will contribute. The basis for this
continued success is the notion of the data interchange format commonly
known as a "package".
This is unique amongst all "small" Linux distribution. A package is a tar
gzipped file that contains a manifest under the name
var/lib/lrpkg/<package>.list. The manifest is a simple enumeration of the
package contents. Anybody can create a package and everybody is WELCOMED to
do so.
I work under the premise that there can be name space conflicts between two
arbitrary packages. I also work under the premise that these conflicts are
not for me to solve: they are the responsability of the person assembling
the final product.
Before I go on, consider the following images. Under your premise, you are
contemplating a puzzle where everything has a proper place, and rightly so.
Under my premises, I am contemplating a quilt, with every overlap adding a
layer of warmth, and rightly so.
I do not have to enforce anything but the proper construction of a package.
My loading code implements only two rules: a) if a package intends to store
anything in var/lib/lrpkg, the file must be named
var/lib/lrpkg/<package>.{anything.goes} b) file names of the form
var/lib/lrpkg/<package>.{anything.goes.}links are restricted.
The user is responsible for name space conflicts because the final
configuration is always the user's choice, not mine. If the user does not
want to backup either package, he has nothing else to do. If the user WANTS
to solve a name space conflict, he simply edit and saves the package whose
files should be dropped and reboot, at which time the name space conflict is
resolved. My user is a living participant in the system and if he is curious
enough to download software from the NET, pick and choose LEAF/LRP packages,
it is my opinion that he is a willing partner.
As you can see, educating this user into thinking that there are no other
limits than these is easy. Why did I bother with the concepts of enclosure
and appliance?
The *nix startup sequence is relatively well documented and it is easy to
understand the concept of a package that dictates the startup sequence by
supplying its own copy of /etc/inittab. An appliance is simply a package
that (probably) contains scripts that have little to do with the "standard"
boot sequence found in Linux systems. PacketFilter runs on top of anything
because it takes control from /sbin/init. The other appliance that I have
created, root (which you will find on the discussion3.img floppy), IS the
standard startup sequence found in LRP, *stein, Bering. So everybody SHOULD
(even if intuitively :) understand that there is nothing new here.
So our user can clearly see that an appliance and selected packages will do
the job he has in mind. Good. He can also easily understand that he needs a
Linux kernel and a boot loader. Good. Where is the component that will make
it possible for Linux to start /sbin/init which in turn will start this
appliance?
In the context of persistent storage, our user would have untarred each
package onto this storage and that would be the end of it: the persistent
storage IS the missing component.
We want more than this. Our storage is unspecified: we use RAM, CD, floppy,
flash, etc. Persistence is unspecified. So we need an ACTIVE component that
understand the format of a package and can present to the appliance the look
and feel of a Linux system. Further, we want the appliance to be able to use
the contents of this component as if it were from any other package. The
word enclosure carries the semantics of container and carries the semantics
of being the object of the communication. It encompasses what is required of
the user to think he is running off a regular system.
Because it reuse the concept of the package manifest, the enclosure is just
as easily extensible as any other package. Further it stresses out that
there is NO baseline.
For example, LEAF/LRP has in its unwritten feature set that users must log
in. I have on occasions removed tinylogin and replaced the getty lines in
/etc/inittab with /bin/ash < /dev/ttyn > /dev/ttyn 2>&1. Don't want to
commit to gnu's sed? Use busybox sed during the load sequence and let the
user supply whatever he wants. I want the user to float the baseline any way
she sees fit for her situation. I don't WANT to provide packages for
everything that she MAY want! When she finds a sed she likes, she decides
how and where it will be packaged. As long the tools to do so are available,
who cares what is running in system xyz?
Unlike what you think, I believe that we all share a few common standards. I
am interested in removing the few remaining barriers that will make LEAF
stand out and I will continue to question how low we can bring the baseline.
I believe that by clearly stating our premises and their natural
consequences, we are removing these barriers. It is possible that some
packages are incompatible with some LEAF releases and I don't see why this
should bother me.
I am unmoved with things such as licensing issues or our SF host. Whether it
is the legalese or the services, I will recognize that I am getting a free
ride and I am grateful for that. I trust the leadership and common sense of
Mike and Charles without being servile and I don't give a rat's ass about
personal recognition. Like the copyright notice says "this software is being
released in the hope it will be useful".
v5.0.5 of the enclosure (and an updated discussion floppy) will be released
tomorrow.
Regards,
Serge Caron
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
