Thank you all for following this thread. We are hosting something this week for a bunch of kids from Yellowknife, 5500Km north-west from here and I it kind of has an impact on my schedule :-)
>Message: 1 >From: "Luis.F.Correia" <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Date: Fri, 1 Mar 2002 19:56:35 -0000 >Subject: [Leaf-devel] Re: Standards and due process :-) > ><LC> :) I'm only aware of a 'almost' religion-like discussion. Of course >reading your conversation makes me aware of how little I do know about >different several standards and processes exist. So my 'adding water' phrase >was meant to be a joke. > I agree with you that there is a tangible emotional content on this list. I will respect other's people emotions while at the same time continue the drive to get a better understanding of our de-facto standards and processes. >My point was only: >In order to 'simplify' the simple act of packaging, from the user's point of >view, >we should split what does not need to be backed up from what does! > >I read almost every day that user X using distro Y backed up root.lrp and >destroyed her/his boot floppy! > >Since that, with my idea, root.lrp would not even appear in the backup >script screen, >the user would be protected from her/himself! > In my mind, the end-user is an active participant in LEAF. Fisrt, he chooses us rather than anybody else. Second, he can be "protected from himself" by providing backup code that implements all the premises of the underlying distribution. Third, he may contribute to his own configuration other files than OUR configuration data: we are not always in a position to choose ALL the files. I am confident that we can meet these requirements by implementing very few changes in what we already do. >I will most certainly benefit from this discussion. Things tend to improve >when >people discuss a lot :) > Indeed, they do :-) Regards, Serge Caron > >Message: 3 >From: "Charles Steinkuehler" <[EMAIL PROTECTED]> >To: "Serge Caron" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> >Subject: Re: [Leaf-devel] Re: Standards and due process :-) >Date: Fri, 1 Mar 2002 17:19:10 -0600 > [snip] >There actually *IS* a baseline implicit in the above. *SOMETHING* has to >get linux booted, create/mount a root filesystem, and load the proverbial >"package". This implies some sort of boot-strapping code, as well as some >sort of "package" format. > >Allow me to wander off on a slight philosophical tangent... OK. However I would like for you to reread my post of Feb 23: > >We want to offer a system based on a model in which components are >distributed from a variety of sources (LEAF, developers, repositories, >clients, etc). We also want this system to be somewhat predictable, if not >completely predictable. Finaly, significant standards are out of our grasp: >the Linux kernel will stay the way it is and so will the various boot >loaders. > >We can start managing things with the initial RAM disk. The convention that [snip] >There are NO required files. Ergo, there is no baseline. It is unimportant >how the designer of this RAM disk will manage the bring the system up and >load the other packages. Nobody else than LEAF will bother to load these >packages and create a running system. So, our base component is this RAM >disk, a life support system that I call an enclosure. Considering the total number of words written for what amounts to be a rather simple set of questions, we are saying the same thing. David's line of reasoning is along "what goes were" or "is this program/file/whatever a valid choice in the context of this distribution". So the valid question is "will this design introduce name space conflicts?". Everybody agrees that we have a de-facto standard for packages. However, the code that loads these packages need not put pressure on this name space. Therefore the *SOMETHING* you are referring to does not have to be a "requirement" as David puts it. More on this later. Back to your philosophical tangent.... > >I think the core question is what makes LEAF LEAF? What are the consistent >features between all the distributions we think of as being part of the LEAF >family? [snip] >Many things come to mind, but I think the core feature is the dynamic >generation of a linux run-time environment on boot. The embedded guys build [snip] >The tiny linux distribution folks are also substantially different from >LEAF. Virtually all of these distributions are based on running from a [snip] >hard-disk, yet be extensible via a packaging system. IMHO, this is the >single most unique and identifying feature of LEAF's many distributions, and >what sets us apart from the broader linux community in general. Additional [out of sequence] >So...who wants to start playing with the packaging system and re-defining >LEAF? I do not think that clearly (and even formally) defining some of LEAF's attributes is an attempt on re-definnig LEAF. I state the obvious when I write "We want to offer offer a system based on a model in which components are distributed from a variety of sources ...". I also state the obvious when describing the tar gzip file with manifest in var/lib/lrpkg/...list as our de facto standard. What is not obvious is that I perceive the end-user as an active part of LEAF, not someone using a limited appliance as designed by the "embedded guys" as you put it. This changed perception makes me question things from a different angle. >It's already been shown that the boot-strap conventions are not required to >make a LEAF system...this is evidence that while essential to a system >actually working, the specific boot methodology is *NOT* a critically core >part of LEAF. No, it is not a critical part of LEAF and neither is the kernel version and/or the bootstrap loader. >Once the packaging system is smart enough to know which files are >configuration files (and maybe even able to tell which files have changed), >it becomes much easier to support a variety of potentially complex issues, >allowing users, developers, or the in-between "tinkerers" to setup backups >and the loading of configuration data the way they want. > I understand we are on a tangent here. The initial proposal was for the unambiguous enumeration of the initial ramdisk contents and introducing the concept of a default store, two ideas that fit nicely in Oxygen 1.9 and Dachstein 1.02, for example. Neither of these ideas puts any pressure on the "packaging system": it is simply exploited the same way in a different perspective. I do not know how you intend to address the difficulty of introducing a "smarter" packaging system. >and I don't want David getting mad at me again ;-) AFAIK, David plays by the rules in chalenging things ;-) >Seriously, I hope to have some time next week to begin to get some of the >ideas bouncing around in my head out into the open, where they can grow and >develop from everyone's input (or maybe they'll shrink back and be killed by >the light). One of the ideas you have bounced in the past few weeks is lowering the baseline. My two discussion floppies are now: http://leaf.sourceforge.net/devel/scaron/discussion4.img and http://leaf.sourceforge.net/devel/scaron/discussion4reduced.img The later has only three binaries in the ramdisk: busybox, fdformat, and hwclock. You already suspect that formatting floppies and setting the clock have little to do with setting up a running LEAF system and that I could say: here is an enclosure that will setup a typical running system with a single binary. I will add to this: it does not require /sbin/init either and you can have a full functionning LEAF configuration without a login program or the usual init/halt/shutdown/runlevel utilities. However, I digress. This reduced enclosure will load arbitrary packages (it even scans the boot device if LRP= is not specified :) and dynamically use replacement utilities as they are installed. ash is not a requirement and the root code will start the usual /etc/init.d/rcS script (and consorts) if it can't find /sbin/init. The point here is that this root code maintains compatibility with the installed LEAF/LRP base using tools that may or may not be part of the final feature set by the time the system is loaded. I am certain of this: the code was made compatible with busybox sed, a utility that I expect to be replaced in ALL installations :-). So, the look and feel of a LEAF distribution can be maintained by preserving the user interface as well as compatibility with the distribution system that LEAF/LRP has established over the years. David's input in this process is clear: by protecting the name space we allow even more choices in building/configuring LEAF systems. Like it or not, your input in this process is just as clear: by constantly lowering the baseline we get a clearer and clearer idea of what we want to protect in user's systems: an installed base of running packages which have requirements that have little or nothing to do with those of bringing up a running system. Even if I would supply a single binary that could do this system setup, this installed based would still require a shell for the simple reason that it uses shell scripts. However, they don't have to use ash or glibc 2.0.7 for that matter. Finally, even arbitrary configurations can be specified for busybox (I know, at one point, there *IS* a minimum which is dictated by the root code: such is life :). These results are obtained by allowing the user to _float_ the baseline by changing the contents of the base system. The root code in the discussion disks will bring up a 2.0, 2.2, or 2.4 kernel, with or without LRP kernel patches, and using a methodology that does not impact your choices in system configuration. All of this with the existing packaging, at the only cost of enumerating the contents of the ramdisk. v5.0.5 of these enclosures also introduces building a baseline database as packages are being loaded and producing a system signature before giving con trol to /sbin/init. You can audit changed files in a running system by requesting an audit which reproduce this system signature before enumerating changed files. It is a simple minded system that can easily be extended into enumerating all files created by the running configuration. It is not a full blown IDS system and is not meant to be. However, you will find it does a good job for little overhead. I hope some of these ideas will help you refine yours, which I am looking forward to read, as always. Regards, Serge Caron > >Message: 5 >Date: Fri, 01 Mar 2002 23:40:46 -0600 >From: "Michael D. Schleif" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >Organization: mds resource >To: Charles Steinkuehler <[EMAIL PROTECTED]> >CC: Serge Caron <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] >Subject: Re: [Leaf-devel] Re: Standards and due process :-) > >Once we know this and know what can be expected -- and, corrallarily, >what cannot be known -- then, and only then, can that system be ``in >control'' and we can say that we are managing that system. Until that >time, there is simply too little known about that system to quantify the >degree of certainty that we can claim. > Believe it or not, we are getting closer and closer to specifying those systems. However, we are not managing these systems in spite of the users but helping them out in doing so. >Perhaps, this is where David parts company, since he is not interested >in building firewalls; rather, his interest -- imho -- lies more in >pushing various limits of these creatively designed systems. Hmmm...I do not know about you but as I pointed out elsewhere, I have large configurations that I manage using Oxygen 1.9. Now, David may not like HOW I do certain things, but there is no inherent barriers into building mean networking systems with an Oxygen distribution. And it is a GREAT reference work on LEAF/LRP. Regards, Serge Caron _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
