Serge Caron wrote: > > I apolologize for leaving in the middle of an important conversation. > Unfortunately, this will happen from time to time. Life gets in the way :-)
I, too, have been erstwhile distracted and now is not the best time to take on all detractors. It is disconcerting when one's words are taken other than literally and totally out of context. Never let it be said that that, alone, stopped me ;> Nevertheless, now that Serge is back online, a few comments are in line: [ snip ] > It is emotions and feelings that will drive Mike to discount his opinion > because he is not producing "code" and it is emotions and feelings that > prompt Charles to put value where value is due. I entirely support the > expression of these emotions and feelings (which includes humor: I guarantee > that if you can laugh at yourself, you will NEVER cease to be amused :). > > My personal experience is that you ride change, much like a horse, sometimes > just for fun, sometimes to get from point A to point B. Sometimes, I ride the horse, because I am a horseman and horsemanship (change management) is a job at which I excel. > In this case, I have submitted an idea supported by a bunch of definitions. > The idea is that the contents of our initial RAM disks be unambiguously > enumerated which imply that root (/) be moved to any other package (your > choice!) which I call the default store. ``Unambiguous enumeration'' sounds precipitously close to defining convention, since convention, by definition, is ``General agreement or concurrence; arbitrary custom; usage; conventionality.'' When you distill a process down to its basic steps, then you have discovered that process's standard mode of operation. O, my! There is that dangerous word: standard. Nowhere in this process of discovery have I mentioned stricture, restriction, preclusion, obstruction, commandment, law, edict -- nor any other synonym for boundary, imposition nor limitation. That, dear readers, is intentional. [ snip ] > I have seen this idea mocked and the discussion go all over the map from > intents of imposing a "de facto" standard to attempts of restricting the > expression of individuality of developers. Yet, given the fact that Oxygen > 1.9+ may be compatible with tar.gz and plain gz ramdisks, and given the fact > that the default store always retain the "standard" LRP format, I can only > see benefits from this idea for Oxygen. Because it is an idea, it can be > implemented by anybody in the form of their choice and does not have to BE > part of a product offering. It can be documented and left at that. In my > case, I wanted to use the product NOW and I choose to edit the two files. > Further, when Oxygen 1.9+ becomes available, I will drop my home.lrp on the > new kit and reboot with all my stuff intact. Instant upgrades are always > interesting :). And, they are *possible*, because you have discovered the conventions and standards inherent in Oxygen 1.9+. If that is all that you have accomplished, that would be enough to illustrate my point. However, your theses are far more extensible than that, which prompts me to pursue this further . . . > Not only do I think that David Douthitt is wright when he says there is no > baseline, I aim to write my code for a minimalist implementation of > everything (including sed :). My baseline is lower than his. However, > Michael Schleif is also wright when he says "In fact, a system, such as leaf > and lrp, is and always has been founded on a -- confusing -- myriad of tacit > specifications. It is this implied set of conventions that I am > addressing -- the fact that these specifications are largely unwritten and, > therefore, understood by a very small minority. " To distill a set of foreign processes into a common set of shared conventions and standards *IS* a baseline! If there is nothing in common between any two LEAF distributions, then there could not be such camaraderie as evidenced by this List Service. Fact is, there is more in common between these several distributions than there is between any two developers themselves. The fact that this genre, if you will, ``a class of artistic endeavor having a characteristic form or technique'', otherwise known as Linux Embedded Appliance Firewall, has a future and is moving from the status quo toward mainstream 2.4x kerneldom, tells me that this dialectic is a process in motion. What longterm purpose does it serve to keep these specifications arcane? > I believe that it is possible to have these specifications without a > baseline. When told that it was impossible to abstract something that would > be common to 2.2 and 2.4 kernels, I actually produced a floppy on which > people can comment. To quote from my February 11 post: > >You CAN voice your opinion and submit suggestions WITHOUT spending long > >hours in quality control. And so can anyone else. There is a disk at > > http://leaf.sourceforge.net/devel/scaron/discussion.img. It contains one > >boot loader, two kernels, four packages, one enclosure, and one appliance. > >This appliance is the ENTIRE startup code from Bering beta3 and which I > made > >compatible to Linux 2.2 kernels by changing 5 lines. Two packages are > >ne2k-pci cards modules for 2.2 and 2.4 kernels: they are mutually > >incompatible :-). The last two packages are ipchains and iptables (how did > >you guess?). There is about 10kb left to play with. What is a `specification', if not a convention, a standard by which this is differentiated from that? Now that we are formally in motion, evolving into what is to become the next generation LEAF, what can it hurt to try and distill a baseline -- granted, a moving, changing, evolving beast -- and publish the record of these changes, so that foreigners and onlookers alike can have some rudimentary understanding of that process unfolding? > Now, a FLOPPY that contains TWO kernels and compatible modules should at > least generate some interest in the process, especialy one that loads ip > filtering code according to kernel version. So far, I must report NO mail. That all of that can fit on one floppy is remarkable. > The code that I have submitted to support these ideas also promotes ease of > deployment, ease of documentation, extensibility, and support for run of the > mill "appliances". The fact is, much of the code that runs once init > receives control is the same in LRP, *stein, Bering and a number of other > derivatives. Once he has a grasp that everything else can be enumerated, > Michael can take the "root" appliance in the above floppy and document its > tacit specifications. Again, this can be done from the "appliance" point of > view without being reflected in code. I make no pretence at being a scribe -- a thinker, organize, experimenter, critic, yes -- a skilled documentor, no. Occasionally, I publish a bit of code that has helped me do good things with a system that might be of some use to others. However, we have onboard already several skilled documentors (e.g., Mike Noyes. guitarlynn, &c.) > In the meantime, I haved continued to lower this baseline. The page > http://leaf.sourceforge.net/devel/scaron/leaf.htm has been updated to > reflect release of v5.0.3 as well as introduce v5.1.0 and v5.3.0. This > documents (alas poorly) the process of creating enclosures and shifting the > baseline anyway the end user sees fit. Doing this made me realize how I can > change the backup code to avoid loosing files enumerated in the xxx.links > package lists, which happens, for example, when a busybox applet is replaced > with the real thing. v5.0.3 also drops the POSIXness stuff, without breaking > *stein and Bering, AFAIK: see the caveat below :). Again, notice that these notions of convention and standards that I espouse are not carved in stone nor immutable. It is fair to say, ``Today, as developer of the Chicago distribution, I prefer that all packages include a specific set of package-specific files under /var/lib/lrpkg/ ...'' Tomorrow, with the advent of new packaging conventions and standards, /var/lib/lrpkg may change to /opt/leaf and the set of files certainly will change, as will the format of their contents. The fact that conventions and standards change hopefully indicates evolutionary progress. Whether or not users -- especially, potential users -- understand that these conventions and standards exist and their purpose, is that communication issue that I am trying to address. [ snip ] > # Modules required to complete the boot process > if [ -r $BOOTDIR/etc/modules ] ; then > # (Do not process comments and white space.) > (blind cat $BOOTDIR/etc/modules; echo) | > sed -e "s/#.*$//1" -e "/^[[:space:]]*$/d" | > while read module args; do > blind insmod $BOOTDIR/lib/modules/"$module".o $args > done > fi > > There is nothing wrong with this construct and it will run perfectly if it > is moved around in the script (the segmentation faults happens in the pipe > between sed and the while clause). In the problem at hand, the file is empty > and the startup continues correctly. It is the ONLY thing to report for the > scripts in this enclosure when using a 2.2 kernel. There is about a dozen > "Segmentation fault"s when using a 2.4 kernel, none of them fatal. When reality collides with convention and standards, impetus for further change may follow. Perhaps, the convention was inaccurately stated? Perhaps, such a collision will prompt discussion and the community will learn something profound from some inadvertent deviation from convention and positive change ensues? Nevertheless, like it or not, those days where the lone ranger gallops off and reinvents not just the wheel, but also the entire hummer, to unanimous accolades of dozens of expectant users are disappearing. LEAF is an umbrella that covers many expressions of a few core ideas; but, the basic system that we bootup is complex and its performance and functionality ought to meet a predefinable set of expectations. What we build ontop of that core system is anybody's guess -- how it fits onto the core system should not be a guessing matter . . . > The availability of these concepts and tools makes the experiment and > discussions possible. Please note that the floppy has been upgraded to > http://leaf.sourceforge.net/devel/scaron/discussion2.img. This particular > code is designed to reflects the concepts introduced left and right in this > post and on the formal presentation page. It can be used with other > libraries as well: there are only 19 binaries involved, all of them standard > Debian or busybox fare. 14 of these binaries are used ONLY by the "root" > appliance above. AFAIK, e3 is used only by us, humans. This leaves ash, > busybox, tinylogin, and sed for the best experiments :o). Isn't an exhaustive list of required files a de facto standard? > Those interested to comment on the ideas are more than welcomed to do so, > emotions and all. I also need a replacement script for Charles mail script > which happens to use netcat, a utility that I do not want in production > equipment. Which smtp _output_only_ program should I use and is there a > script compatible to Charles's syntax? I must admit, I do not understand this netcat reference -- care to expand? What do you think? -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
