> >Message: 1 >Date: Wed, 13 Feb 2002 13:54:34 -0800 >From: Matt Schalit <[EMAIL PROTECTED]> >Subject: Re: [Leaf-devel] Re: Standards and due process :-) >To: [EMAIL PROTECTED] > > >Hey Serge,
Hello Matt, First, the important stuff: >or any of us lacked passion. That's kind of insulting. And what Please accept a direct apology from me to you for no other reason than the fact that your feelings were hurt. > It's plenty interesting to read your threads and see the breadth >of your opinions. I've said before that it's always refreshing to Thank you. Please DO NOT PUT your flame thrower away! >exactly happened three weeks ago? You showed up? And you tore the low >level guts out of Dachstein and want to call that PacketFilter? And My posts are polite and as factually true as I can make them. PacketFilter is a 60kb file that cannot contain Dachstein. If you read the manual, Charles is directly credited for allowing this 60kb file to be distributed with his stuff. Further, as pointed out to David elsewhere, I do not intend to make a distribution just for the purpose of providing an environment in wich to run PacketFilter. This leaves you with very little material to support your opinion that I want to promote a dumb filtering device to the level of Dachstein. >you don't like our file structure and our documentation? You think we >make "stupid decisions" in our "quaint little space" and that comlicates >your life? Indeed. > As you acknowledged in the beginning of your message, you have collected things out of context. The onus is on you to support your comments. Regards Serge Caron >--__--__-- > >Message: 9 >Date: Wed, 13 Feb 2002 22:34:18 -0600 >From: David Douthitt <[EMAIL PROTECTED]> >Subject: Re: [Leaf-devel] Re: Standards and due process :-) >To: LEAF Development <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] > >On 2/13/02 at 8:16 PM, Serge Caron <[EMAIL PROTECTED]> wrote: > >How's this different from Oxygen and Dachstein and how they read their >configuration data from the floppy? I can create a package which >contains nothing but configuration files, put it onto a floppy disk, >and boot the Oxygen Bootable CDROM using that configuration.... > The point is that this default store is loaded last, overwriting anything loaded from ANY package. It is not package specific and it is all inclusive (as far as /etc and /var go). >And I DON'T have to rewrite all of the packages... Neither do I. As a matter of fact, I cannot rewrite stuff on CD when the package writer did not provide a partial backup list for Charles partial backup code. I also do not want to load binaries frow write-enabled media, as much as I can avoid it :-). Last, but not least, I will retain SOME system functionality when the default store goes belly up or missing. > >For booting purposes the use of root.lrp is dead; however, a script to >convert root.lrp to a root.gz is practically a neccessity. The LRP >patches can't be used on any kernel newer than 2.4.5 last I heard; so >this kills the use of a *.tar.gz file for booting. > Am I to understand that this will be a ONE-TIME script, run as part of an installation procedure, or is this a viable option that users sticking with 2.2 kernels will have in the long run? >a real Repository would be with hyperlinks, descriptions, home pages, >etc.... and requires a new package extension. I've not done as much >as I ought, but it mainly uses a new file /var/lib/lrpkg/<pkg>.desc >which contains all of the information.... > Grrreat! Here is the dope for http://leaf.sourceforge.net/devel/scaron/nistnet.lrp >The second one is nistnet 2.0.10, the National Institute of Standards and >Technology network emulator and here's the dope from their homepage at >http://www.antd.nist.gov/itg/nistnet/ > >The NIST Net network emulator is a general-purpose tool for emulating >performance dynamics in IP networks. The tool is designed to allow >controlled, reproducible experiments with network performance >sensitive/adaptive applications and control protocols in a simple laboratory >setting. By operating at the IP level, NIST Net can emulate the critical >end-to-end performance characteristics imposed by various wide area network >situations (e.g., congestion loss) or by various underlying subnetwork >technologies (e.g., asymmetric bandwidth situations of xDSL and cable >modems). > Regards, Serge Caron _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
