Hello all, I apolologize for leaving in the middle of an important conversation. Unfortunately, this will happen from time to time. Life gets in the way :-)
>Message: 4 >Date: Fri, 15 Feb 2002 18:26:00 -0800 >From: Matt Schalit <[EMAIL PROTECTED]> >Subject: Re: [Leaf-devel] Re: Standards and due process :-) >To: [EMAIL PROTECTED] > > >No problem, my feelings weren't hurt. I was stating a fact. You Good. We are in the business of change and it is a business of emotions and feelings, not one of logic and certainly not one of wright or wrong. 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. 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. This does not require any adherence to any foreign code, programs or the like. In fact I can implement the entire concept in Oxygen 1.9 by editing two DATA files. The first one is root.list which contains the single entry ./ and which I replace with the unambiguous enumeration of the contents of root.gz (see the appendix below). The second one is any other file I choose as my default store: my personnal preference is home.lrp and I edit home.list to contain the single entry ./. I can use Oxygen 1.9 right now, even without the backup code that will be part of a later update. I obviously use it in ways that its author has not envisionned. Further, root.gz with the edited root.list satisfies in every way the definition I have put forward for the concept of an "enclosure". 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 :). 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. " 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. 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. 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. 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 :). v5.3.0 is my "standard" busybox ash experiment: I have tested on many occasions the compatibility of busybox ash to the Debian ash. In this case, I simply replaced the busybox in the original enclosure with the busybox found in Oxygen 1.9. busybox ash is not a drop in replacement for ash, but it is getting better all the time. In this case, there is a "Segmentation fault" in the following construct: # 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. 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). 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? Regards, Serge Caron Appendix: contents of root.list in my Oxygen 1.9 setup: linuxrc bin/ash bin/bash bin/busybox bin/dnsdomainname bin/help bin/lf bin/ll bin/logrotate bin/lx bin/netlock bin/pwd bin/run-parts bin/sh bin/sleep bin/snarf bin/strip_comments bin/timeread lib/modules/boot/3c509.o lib/modules/boot/3c59x.o lib/modules/boot/8390.o lib/modules/boot/cdrom.o lib/modules/boot/eepro100.o lib/modules/boot/ide-cd.o lib/modules/boot/ide-disk.o lib/modules/boot/ide-mod.o lib/modules/boot/ide-probe.o lib/modules/boot/isofs.o lib/modules/boot/modules.conf lib/modules/boot/ne.o lib/modules/boot/rtl8139.o lib/modules/boot/smc-ultra.o lib/modules/boot/tulip.o lib/modules/boot/wd.o sbin/chroot sbin/ip sbin/lsmod sbin/mkram sbin/sysctl var/boot/modules var/boot/config/README var/boot/config/big.vol var/boot/config/cdrom.cfg var/boot/config/config.cfg var/boot/config/develop.cfg var/boot/config/dos.cfg var/boot/config/firewall.cfg var/boot/config/floppy.cfg var/boot/config/large.cfg var/boot/config/largenet.cfg var/boot/config/misc.cfg var/boot/config/net.cfg var/boot/config/oxygen.cfg var/boot/config/rescue.cfg var/boot/config/setup.cfg var/boot/config/smallnet.cfg var/boot/config/std.vol var/boot/config/test.cfg var/boot/config/testcd.cfg var/boot/config/tiny.cfg var/boot/linuxrc/find.cdrom var/boot/linuxrc/functions.cdrom var/boot/linuxrc/functions.dhcp var/boot/linuxrc/functions.general var/boot/linuxrc/linuxrc var/boot/linuxrc/main.load var/boot/linuxrc/mkdevices var/boot/linuxrc/mkfloppies var/boot/linuxrc/new.load var/boot/linuxrc/old.load var/boot/linuxrc/sysconf var/lib/random-seed var/lib/lrpkg/config.md5 var/lib/lrpkg/root.busybox.list var/lib/lrpkg/root.conf var/lib/lrpkg/root.exclude.list var/lib/lrpkg/root.help var/lib/lrpkg/root.list var/lib/lrpkg/root.mount var/lib/lrpkg/root.posix.list var/lib/lrpkg/root.version var/lib/lrpkg/sys.packages var/lib/dialer/* var/spool/* _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
