Dear Michael, I got my first paycheck from a computer center (as they were called then :) in September 1970. You do the math. It is obvious that your message below was heathfelt and the product of a long experience. I respectfully request that you humor me into reading this message to the end.
> >Message: 8 >Date: Sat, 09 Feb 2002 02:09:39 -0600 >From: "Michael D. Schleif" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >Organization: mds resource >To: [EMAIL PROTECTED] >CC: LEAF Development <[EMAIL PROTECTED]> >Subject: Re: [Leaf-devel] Preferred package/filesystem location ??? > > [snip] > >I'm a devout believer in systems and process. > [snip] > >Having dealt with systems and processes for more than thirty (30) years, >I place a high value on convention and standards. I am *NOT* talking >about blind restrictions and stricture that chokes the creative spirit; >rather, some simple, commonsense rule-of-thumb that guides the creative >spirit. It's that spirit that brought me to this venture -- how about >you? Personally, I have enough to do putting out fires in the bigger >world, I do not have any compulsion to spend countless hours begrudging >LEAF any type of quality control at all! > Having been there, I know you or your employer at the time also went through James White "Creative Supervision" (circa 1975) and Ed Yourdon's "Structured Walkthrough" (circa 1980) and every other "fashion" that surfaced in this business every 4 years or so. The best of these trends stayed and became "best practice", which is also an euphemism for "they don't know better". Having spent several million dollars of my own money into various development projects, I have learned (sometimes the hard way) to respect the ideas of the people around me. I suspect that you know for a fact that without this respect for people you won't have respected standards. Therefore, you know the value of public discussion, with the joy and deceptions of seeing something built from the ground up. Up until 3 weeks ago, LEAF was a quaint little space with established ways and habits. These, standards do not make. I, like you, want clear definitions and, more than anything else, the consensus that goes with accepted standards. [out of sequence] >We are dealing with a very small system with LEAF. The process of >reaching consensus on conventions, such as filesystem management and >program location, may seem trivial and without value to some; but, as >this system grows, I guarantee that willy-nilly file placement is going >to result in some application stomping on some namespace or another that >some other application insists is its own ;< Trivial and without value? _I_ don't think so! Here is a sequence of definitions that correspond to what we actually _do_: 1) package: is a tar gzipped file named with extension .lrp according to MSDOS conventions; a properly formed package contains its inventory in the file var/lib/lrpkg/<name>.list where <name> is the name of the package file and all paths are relative to root (/). 2) default store: this is the package containing the root of the filesystem (/). 3) implicit exclusion list: this the concatenation of the lists of other packages relative to one specific package; by definition, nothing matches root (/). 4) appliance: this is a package containing a file /etc/inittab; there can be several appliances in a project: the last one loaded SHOULD receive control from /sbin/init. 5) enclosure: this is a package delivered in the format expected by your Linux kernel for initial RAM disks. It is GUARANTEED to receive control from the kernel at /linuxrc. Regardless of what you do, it will ship/install/etc with your product/project/etc. Now, where am I going with this rambling. Over the week-end, Oxygen 1.9 was released as well as a significant update to Dachstein 1.02. Oxygen has 300 (or so) packages: it is a GREAT reference work. On February 4, David Douthitt wrote >Note that Oxygen (now) uses root.gz - which is NOT a tar.gz file, but >a gzipped filesystem image, just like the Linux kernel wants... If I boot an Oxygen 1.9 floppy using the single disk "Linux" configuration and type "apkg -b root", the program attempts to save the package root.lrp instead of the enclosure root.tgz. The process fails because root.lrp is not a replacement for root.tgz and there is not enough space on the disk for both. Further, this enclosure contains the default store. By design, David's enclosure MUST be read by the boot loader BEFORE the kernel. There is (almost) no limit on the capacity of the filesystem and there is always a finite amount of memory in the machine. Therefore, I can always design a test case that will make it impossible to properly backup any enclosure that contains the default store. It follows that "best practice" would be to place the default store in some other package. Immediately, this opens the door to designs like thin servers where the local hard disk is merely a cache. This benefit brought to you from proper definition and discussion. It does not end there. Suppose apkg or some other program can properly save the enclosure. If it does not contain the default store, the contents of the enclosure must be enumerated in a way such that this content is not duplicated in some other package, an obvious waste that is not acceptable in the confined space of a floppy. This is the obvious consequence of definition 3) above. Finally, by the time the enclosure has prepared an acceptable filesystem for /sbin/init, will it replace your design with its own or will it let you run as you wish? This freedom of choice has to exist before it can be respected. There are things that the enclosure cannot do (pivot_root being a prime example) of which an appliance must be aware if it wants to exercise this freedom. I am certain you can say "Been there, done that". By the time David will have fixed his glitches, he will have a product that will conform to most of the above definitions. For those of us that can remember Wirth's "Data + structures = program", the structure of the program reflects the structure of the data. Right now, we want to protect ALL the repositories of LRP packages by maintaining compatibility with the LRP "data type". We also want to go ahead and CREATE something fresh and new, the "venture" as you say. 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 here's what meets the eye: the first time you boot, you must select a 2.4 kernel. This will load iptables and do a standard startup. In fact if you add Shorewall, you will get a darn good Bering facsimile :-). If you save the LEAF package (the enclosure), you must reboot using the 2.2 kernel and this will load ipchains. In either case, you must use ip to configure your network connectivity ip link set eth0 up ip addr add 10.9.8.7/8 dev eth0 Now here are three things that are hidden to the naked eye. 1) the enclosure contains busybox and a list of applets, one of which is klogd. However, the appliance WANTS the full flavor klogd. In this case, the appliance designer must modify (ever so slightly :) the enclosure so that his klogd is used rather than the one in the enclosure. (If you don't know what to do, edit /bin/busybox.links and delete the line that reads /sbin/klogd). This clearly demonstrates that the appliance designer can take a standard enclosure and adapt it for her needs. This is a lot easier than doing everything from scratch, ask Jacques! 2) the enclosure does not contain the library libdl.so.2, a library referenced in 254 programs from David's 300 packages. Common sense dictates to place such a popular library in a way that it will not duplicated on the foppy. However, this library is not required by the code in this enclosure and the enclosure is NOT a baseline specification. This library is obviously not used in the appliance which is mostly Debian startup code. Therefore, it is stored in each of ipchains.lrp and iptables.lrp, packages which should not be construed as mutually exclusive. This is the type of stupid political decision that is made to save face and to witch you must be used after 30 years in this field. You and I have no time or desire left for stupidity and should come to the conclusion that the library be placed anywhere the person shipping this product sees fit. 3) the enclosure can be used to PROMOTE hardware differences. Booting from CD? Use a ... enclosure and get libc2.1 support. Staying with floppy? This ... enclosure will save you 200Kb. Does that apply only to Dachstein 1.02? NO! This kid Johan comes with a very important question for people dealing with embedded systems: can we specify multiple hardware configurations at a level so low (in the enclosure start-up code) that we can reuse the appliance without any modification whatsoever? I believe that the decision always rest with the next level in the chain. As you can see, there is a lot of meat on that bone. I also saved a little something for desert. A distribution is an open process with readily available selection criteria. Neither Oxygen nor Dachstein contains pump used by Jacques Nilo. Now, as long as these gentlemen continue to maintain their present offering, packages like netsnmpd.lrp get out there and serve a purpose. A week ago, I packaged nistnet 2.0.10, the National Institute of Standards and Technology network emulator (here's the dope from their homepage at http://www.antd.nist.gov/itg/nistnet/ ). It never crossed my mind to submit it directly to David or Charles. My reflex was to inform Mike and I was saddened to learn that LEAF does not have an official package repository. >What do you think? > [snip] >Dare to fix things before they break . . . > Well, Michael, if you really want to humor me, I am sure that you will share your thougths. However, you are NOT under the spotlight here and I will understand if you don't have the interest (let alone the time) to do so. Freedom is something I value more than grown up games. Respectfully yours, Serge Caron _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
