>Message: 3 >Date: Wed, 6 Feb 2002 22:04:10 -0600 >From: David Douthitt <[EMAIL PROTECTED]> >Subject: Re: [Leaf-devel] Useful comments from Dave >To: LEAF Development <[EMAIL PROTECTED]> > >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. >
[snip] > >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... > This disk http://leaf.sourceforge.net/devel/scaron/idontexist.img contains _two_ kernels named charles (2.2.19-3) and jacques (2.4.16) as well as _one_ enclosure. When you save the LEAF package and reboot, you have to use the alternate kernel. Start with the 2.4 kernel, save some stuff using either the root or log package, save the enclosure and report to this assembly that indeed you can move between either kernel effortlessly. Not only can you swap back and forth easily, it is easy to forget which kernel you used last :-) > >"Project default store"? Eh? > In the setup above, this would be root.lrp. However in a truly embedded system it could be cmos, flash, ... >> 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. > These are all examples of stuff that happens _after_ init takes control. The proposal is for what happens before. > >What makes up the bulk of scripting in most LRP systems is /linuxrc - >which amounts to everything that happens before init is run. > Hmmm...perhaps this should be qualified? Clearly, LEAF v5.0.1 runs without ctar, ticker, watchdog, ipfwd and this imply that this project has produced no other binaries than the kernel tgz patches. All LEAF/LRP releases are "only" scripts (no offense intended to anyone who wrote those :-). What happens in linuxrc is not really relevant to Dachstein, Shorewall, etc. What is relevant is that by the time they receive control, there is no difference between the fact they were loaded from ROM, floppy, flash, ESP :-) [ not in order ] >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. The contents of LEAF v5.0.1 is publicly posted at http://leaf.sourceforge.net/devel/scaron/leaf.htm I don't see either ipchains or iptables. It does not imply that enclosures does not use network services. It implies that if such is the case, it will have to cooperate with the appliance it is serving and it is left to the appliance designer to supply all the missing tools and code. >The less I say about the state of current marketing the better... [snip] > >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. > [snip] > >To me, forensics is the science of studying what has happened after a >crime has been committed by studying the evidence which remains. > Forensic means "belonging to public discussion and debate", some of which do happen in courts or legal proceedings. I do know for a fact that consumers decide. Whether the product is over-engineered or over-marketed (and priced) is irrelevant: I am not proposing something on merit, just as an evolution. >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... > [ not in order ] > >To me, "LEAF appliance" is a marketing term: translation "LEAF >distribution" - or better yet: "LRP-derived floppy-based LINUX >distribution." That explains it best... > Hmmm, you are avoiding a realistic answer. Unfortunately, you are contradicting a previous post stating that it is not necessary to maintain a distribution to provide an "appliance". > >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. > Thank you for sharing that. This information will be usefull to Charles. However, I am _not_ using Dachstein. I have used Charles's floppy released as an example to demonstrate the separation between what happens from power-up to /sbin/init and from /sbin/init until the user gets control. I can do the same analysis with Bering, for example, and come up with similar results. >Automatic loading of packages was proposed in 1995.... why doesn't >Dachstein do this? > Please take this up with Charles. >> 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: [snip] > As a matter of fact, the proposal is painfully clear that the contents of an enclosure is *NOT* specified. However, whatever the designer places in it *MUST* be explicitly enumerated. Design your RAM disk as you see fit! Just provide an unambiguous enumeration of its contents. >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. > As you can see from the transition from LEAF v5.0.0 to v5.0.1, things are being deleted without touching anything in either of these two "distributions". It is up to these authors to try the concept or not. One thing that I find mildly amusing is that people are confused because the feature set is never specified. The busybox in the v5.0.0 tar.gz version (2.2 kernel) had much more applets than the one in the v5.0.0 gz version (2.4 kernels). So in v5.0.1, the feature set is the same in both versions (but still unspecified :). >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.. >-- That will be a positive contribution to which I look forward to. Regards, Serge Caron _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
