Well, I see this discussion going exactly the way it previously was >6 months ago when we ended up in agreement of the situation. These are still interesting arguements, but still re-hash. IIRC, I believe Charles and I (at a minimum) are still following the same line of thought. It might make it clearer if I simply digress my IHMO in a simpler manner than before........
The present backend (e3, lrpkg, and lrcfg) are simply not compatible with the present desires of home users and more experienced users alike much of the time. We can't network load packages or images w/o major modification, the system isn't viable (as is) for any front-end other than hand-editing, the use of boot-media other than a floppy (sans DCD) is rather advanced (Martha Stewart won't be making a BeringCD image today), and the additions of any other front-end require quite extreme measures by the user and redundant template code. There are people with Bering that are running systems with each and everyone of these options out there that _have_ jumped through all these hoops to make it work. We can either quickly develop an addition to the existing system and rework it forever to add a few desired options on a regular basis OR we can develop a new system that is capable of all of these things w/o anything but a simple addition/change to the existing package format w/o needing to revisit the system itself to do so. lrpkg, lrcfg, and the *.lrp package format was well thought out and our present use of such indicates that it was worth the effort. Bering was a proof of concept that broke and forced the old LEAF/LRP system into a new way of building the core itself, which is now found to be an acceptable change even by those who were not originally sold on the idea. I see this as the same thing, we can change and people _can_ accept it if they choose, but we _should_ look into the future of LEAF with this concept NOW, instead of looking back wishing we had. The size is non-consequental if no templates are stored and the bulk is done with shell and well placed binaries (as Charles suggests). If you forget the value and power of shell-script, you don't really understand the LEAF/LRP system at all. I see either this concept can be embraced or ridiculed, but if you don't see it as necessary in the future you plainly haven't followed the desires on list for the last year or two. Packetfilter, apkg (Oxygen), LINCE, Mosquito, and individual systems are proof that it is time to move on. I'll write a new system myself if no else feels this way, it may never be complete or ideal, but I imagine that it will be integrated sometime in the future if not now. I don't want to try and save an old system for compatibility, Oxygen, Eiger, DachsteinCD, Bering, PacketFilter, WISP, LINCE, Coyote and many others weren't too concerned with compatibility. If this ends up as a new variant, so be it..... it shouldn't be necessary; PacketFilter was proof of this if anyone spent the time to actually look into that 'package' as well. I see this as a extension of Serge's concept(s), which I don't feel were ever understood due to the way he presented them. -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
