I find the following comments useful: >Message: 9 >Date: Sun, 03 Feb 2002 23:51:01 -0800 >From: Matt Schalit <[EMAIL PROTECTED]> >Subject: Re: [Leaf-devel] A new look on LEAF components >To: [EMAIL PROTECTED] > [snip] > >Are all LEAF's now and in the future packet filters? >
>Message: 10 >Date: Mon, 4 Feb 2002 06:32:53 -0600 >From: David Douthitt <[EMAIL PROTECTED]> >Subject: Re: [Leaf-devel] A new look on LEAF components >To: LEAF Development <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] > [snip] >> It's a shame that you didn't try Oxygen 1.8.0. You would have >> found quite a few differences that were not in the packaging. > >Matt's quite right; Oxygen is probably the furthest away from its LRP >base. Some quick examples of the most dramatic changes (as defined by >current development): [snip] > >I'm not sure I understand how your project is supposed to work. >-- Without presuming on what I did (or did not) try, the concept of an enclosure does not favor any particular design, developer choice, or "look and feel". What it does promote is a facility for moving from environment A to environment B, be it Oxygen or Dachstein or whatever. You are quick in making a distinction between Dachstein and Shorewall, the later being a commodity in the context of your sentence, if I understand correctly. There is no guarantee to Joe User that happens to like Shorewall enough to build on it for his own needs that he will be able to move his stuff to a cool new environment like Oxygen. On the other hand, the ordinary sysadmin that can write a script without feeling the urgency to rewrite the entire LEAF effort will find the concept of an enclosure usefull. After all, HER stuff is protected and she is one quick "cp -a root.lrp ..." away from moving to something else. Further, you can replace the ENTIRE set of files in the enclosure without loosing the base concept. Finally, it does promote some social responsibility. If LEAF provide a package repository, it creates a pull effect, that is a center of attention were everybody can go to find something. If it also provides "reference" kits (bootdisk, kernels, modules, whatever) it suddently has a broad offering as well as sharing the experience of working with these different environment, be it glibc 2.1.x or MacIntosh processors. If Charles, Jacques, or David create a "distribution", it creates a push effort that lacks the LEAF project synergy. I believe there is room in this project for people who will take a base kit and come up with something that has nothing to do with the LEAF internals. Maybe Lynn has a redundant router project to share or somebody else has Dead Gateway Detection. There is no easy way for them to create this appliance unless they conquer the difficulty of providing their own boot disk, startup code and the like. In contrast, the person making a nmap.lrp package, for example, has a rather simple and well defined task. I do hope that somebody will provide alternate "enclosures". That is the purpose of the effort. Better libraries, better menus, better support for typical embedded devices like flash disks, etc. Not only do I agree that POSIXness and silly kernel patches must go, I expect people creating enclosures to document each aspect of building of boot image in the comfort of their user's computer. This is Linux and people are also expected to work from source. PacketFilter is just a network setup script designed to drop IP traffic. Yet it is usefull enough to build a small workstation, an unforeseen benefit. As I plainy wrote in the documentation: "I do not intend to maintain an LRP distribution just for the purpose of providing an environment in which to run PacketFilter." I believe this is clear enough. I am sure other people with something worthwhile to contribute will appreciate the support of the LEAF project. Let's make it easy for them to do so. Regards Serge Caron _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
