On 2/5/02 at 4:31 PM, Serge Caron <[EMAIL PROTECTED]> wrote: > In the concept of an enclosure, I abstract the binary > format of the initial RAM disk. The same enclosure is > offered in tar.gz and initrd.gz formats, with references > to 2.2 and 2.4 kernels respectively. There is nothing > preventing cross usage of these files if the user builds > the appropriate support in his Linux kernel, a fact that > extends beyond the scope of this project as I understand > it. Therefore, I believe this is a sane decision and I > will stick by it.
The initial RAMdisk configuration is either in *.gz or in *.tar.gz formats. A standard Linux kernel without LRP patches cannot handle a *.tar.gz format file for an initial RAM disk; this precludes the abstraction you were talking of. Also, the use of 2.4 precludes the use of ipchains without special configuration; there are other 2.4 requirements that don't exist in 2.2. One can't take this initial RAM disk and swap back and forth easily - unless you are referring to its contents only - but even then, one has to account for Linux 2.2 vs. Linux 2.4... ipchains vs iptables... > Mankind is full of talented people and marketers are some > of them. The less I say about the state of current marketing the better... > Actually, I am explicitly proposing that the contents of > the initial RAM disk be enumerated in an unambiguous way > and that the project default store (usually root) be > separated from the RAM disk. "Project default store"? Eh? > I am also explictly proposing > that the person designing an enclosure be absolutely free > to put anything they want in their enclosure and do > whatever they want before /sbin/init receives control. That's what happens now - and with Oxygen, even more so. Want to use fcron instead of cron? You can. Want to not run cron at all? Can do that too. Want to run with lrpkg instead of apkg? You can. Want to use rcf instead of seawall? You can. What makes up the bulk of scripting in most LRP systems is /linuxrc - which amounts to everything that happens before init is run. > Potential users will decide what is useful and not, just > as consumers decide which product lives and which dies. Consumers don't always decide in favor of the clearly technically superior; look at Beta video tape. Another example: most engineers would tell you that the IBM PC architecture should have been gutted and replaced completely a decade ago. > Finally, I am explicitly proposing that the person > designing yet another way to stick a RAM disk in a kernel ...you don't stick RAM disks into the kernel... > be responsible for providing the conversion code from an > existing scheme to their new one. "Conversion code"? "Existing scheme"? > It seems to me that I am > proposing a lot of freedom for people to try different > ideas without having to redo the work all of the time. Redo what work? > The word distribution keeps coming back with slightly > different meanings, or so I understand. To me, a distribution is: * A collection of programs combined with an OS kernel combined in such a way as to make the combination useful. This includes FreeBSD, OpenBSD, Dachstein, Oxygen, Windows NT, HP-UX... > Following my post > regarding the conversion of an existing disk, here are the > forensics on Charles's Dachstein 1.0.2 floppy: To me, forensics is the science of studying what has happened after a crime has been committed by studying the evidence which remains. > 1) if the instructions were followed exactly, the new > root.lrp would contain ipchains 1.3.10, the bridge > configuration utility (brcfg), a symlink to > /etc/init.d/network (/sbin/net) and the seed for the > /random number generator > (/var/lib/random-seed). root.lrp would also contain > /lib/libss.so.2 a library used for system specific ext2 > filesystem functions that is not referenced by any of the > 43 packages on Charles CD; /usr/sbin/ipfwd, an obsolete > (?) utility for routing incoming pptp traffic, > /usr/sbin/traceroute which has a (lame) busybox > equivalent, and /usr/sbin/icmpinfo. That's it! I know that you're using Dachstein, but in Oxygen: * ipchains is a package (ipchains.lrp) * bridge utilities are packaged (brctl.lrp) * libss - probably packaged in ext2fs.lrp * busybox is now at 0.62.0 - make sure it's current * There is a tracert.lrp which is quite current. > 2) I decided to modify my own instructions to add the > ipchains package separately and to add /sbin/brcfg, > /sbin/net and /var/lib/random-seed to the etc package /sbin/net and /var/lib/random-seed are not in /etc.... > syslinux.cfg was modified to read LRP=ipchains,etc,... Automatic loading of packages was proposed in 1995.... why doesn't Dachstein do this? > However the real question is this: since everything that > is Dachstein_1.0.2_floppy_version can be reduced to this > single 40Kb file, what is a LEAF distribution and what is > a LEAF appliance? To me, "LEAF appliance" is a marketing term: translation "LEAF distribution" - or better yet: "LRP-derived floppy-based LINUX distribution." That explains it best... > I believe we are old enough to see that Dachstein and > Bering (and other derivatives) provide "standard" > services. Still sounds like a "Base System Standard" - that is, standardizing on what binaries are available after the smallest possible number of packages are loaded - and where they are. How does your proposal compare to the Linux Filesystem Standard (LFS) and the licensing used by the author of djbtools and qmail? If you are trying to specify exactly what root.lrp (root.gz) includes - Oxygen is a good example of why that can't work. Oxygen includes in root.gz: * busybox (statically linked, 77+ apps) * snarf (statically linked) * shell scripts, including configurations * basic directory structure * a few parts of asmutils (chroot perhaps) Oxygen does NOT include in root.gz: * libc * cron * init * inetd * sed * many more... If I had to guess, I would say that it will probably be a good while before Dachstein or Bering remove these from their root archives. What I WOULD like to see (maybe I can do this...) would be a script analyzer or testbed that would pull out all commands that were needed by a script and analyze them against a running LEAF to see if the LEAF provided everything that was necessary. Testing options would be nice too, to see that a script would work in a LEAF environment.. -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
