RE: [Leaf-devel] Re: Standards and due process :-)
Adding water to a boiling and already full kettle... Why can't we use a concept similar to this: vfat is used Package name: pppd-2.1.4 Package files: pppd-2.1.4-bin.lrp, pppd-2.1.4-conf.lrp pppd-bin.lrp contains all necessary binaries and 'non-editable' scripts, pppd-conf.lrp contains all configurable files. All we will need then is to backup only the ???-conf.lrp files. I am perfectly aware of the problems this solution brings along, but hey, at least it's one more opinion/idea! Take care -Original Message- From: David Douthitt [mailto:[EMAIL PROTECTED]] Sent: Friday, March 01, 2002 3:39 AM To: LEAF Development Subject: Re: [Leaf-devel] Re: Standards and due process :-) On 2/28/02 at 4:24 PM, Serge Caron <[EMAIL PROTECTED]> wrote: > For example, LEAF/LRP has in its unwritten feature set > that users must log in. I have on occasions removed > tinylogin and replaced the getty lines in > /etc/inittab with /bin/ash < /dev/ttyn > /dev/ttyn 2>&1. This is similar to what Trinux does - no login. > Don't want to commit to gnu's sed? Use busybox sed during > the load sequence and let the user supply whatever he > wants. Oxygen doesn't use sed during boot. > I want the user to float the baseline any way > she sees fit for her situation. I don't WANT to provide packages for > everything that she MAY want! When she finds a sed she likes, she > decides how and where it will be packaged. As long the tools to do so > are available, who cares what is running in system xyz? With the maximal fragmentation in Oxygen, one can strip out GNU sed for minised (or whatever) if it is desired - just rm sed.lrp and put in the desired msed.lrp... It sounds almost like you want a "minimal set" of enumerated binaries and functions, and then Oxygen would add set X and Dachstein would add set Y. It sounds like ANSI FORTH (did I say this before?). ANSI FORTH has a CORE Word Set, and a FLOAT Word Set, etc. An ANSI compliant FORTH may have a minimal number of Sets, but if they are compliant then it is "ANSI Compliant with the CORE, [...etc...] Word Sets." Is this what you have in mind? ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
> Adding water to a boiling and already full kettle... > > Why can't we use a concept similar to this: > > > vfat is used > > > Package name: pppd-2.1.4 > Package files: pppd-2.1.4-bin.lrp, pppd-2.1.4-conf.lrp > > pppd-bin.lrp contains all necessary binaries and 'non-editable' scripts, > pppd-conf.lrp contains all configurable files. > > All we will need then is to backup only the ???-conf.lrp files. > > I am perfectly aware of the problems this solution brings along, > but hey, at least it's one more opinion/idea! I'm strongly considering something like this if I ever get back to working on the packaging system again (currently stuck in boot-strap & development environment issues), although I'd probably do something like: pppd-2.1.4.leaf pppd-2.1.4.conf There's also the issue of using a single "default store" package, which could possibly also be supported by the same package system. The user could then choose how they wanted to backup...by individual package, or "en masse". Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: Standards and due process :-)
> >-Original Message- >From: David Douthitt [mailto:[EMAIL PROTECTED]] >Sent: Friday, March 01, 2002 3:39 AM >To: LEAF Development >Subject: Re: [Leaf-devel] Re: Standards and due process :-) > [snip] > >It sounds almost like you want a "minimal set" of enumerated binaries and >functions, and then Oxygen would add set X and Dachstein would add set Y. > Nope. No. Nein. Niet. Non. :-) There is NO baseline. There is one standard: the formation of a package. The final decision on a configuration always rest with the user and she expects the tools to do her job. I have given specific and realistic examples of how and why the user may want to float the baseline of a specific distribution, be it Oxygen or anything else. If somebody else is already implementing these examples then we should understand that our users will want to be able to do the same. Last but not least, I have used persistent storage as an example where NO code from the "distribution" runs before /sbin/init, the point where I assume the user or some other package will take control. This is the absence of a feature set and you can't possibly get any lower than this. Again, in the example of persistent storage, the user will use from the "distribution" whatever has value to her, be it the menu system or the package management software apkg. The existence of this one standard does in no way reflect on anybody's premises. It does reflect on the user's ability to use arbitrary packages with arbitraty distributions. My loading code implements only two rules: a) if a package intends to store anything in var/lib/lrpkg, the file must be named var/lib/lrpkg/.{anything.goes} b) file names of the form var/lib/lrpkg/.{anything.goes.}links are restricted. If a package does not satisfy these two rules, the package is skipped. Let the user sort out the issue. The exact feature set of a distribution is obtained by the unambiguous enumeration of its packaging. In the example that I have given, the contents of the initial ramdisk has a feature set (whatever that is) that is augmented by the feature set of other packages. If you choose to split this feature set across multiple packages, you still have the same feature set with the added "feature" of being able to delete or replace some components in the form of other packages. Spliting the feature set in 3, 10 or 27 packages does not change the attributes of the package concept. Please note that the unambiguous enumeration of the packaging answers significant parts of questions like "Which distribution should I use?" and "Will this work with ?". This is the basis of LEAF: uneducated users and gurus alike should find something of value here. I also note that you gave more importance to packaging than to the fundamental difference between our respective set of promises. However, here lies a richness that should be exploited. In particular, it addresses Michael's quest by explicitly stating that name space conflicts are to be solved by the user. As long as he follows sound practices (like reflecting installations in full blown systems), Michael's packages should work with ANY "distribution". In case of doubt, the user decides. Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] q regarding an ftp site for leaf-project.org
At 2002-02-28 10:51 -0600, guitarlynn wrote: >All of your concerns are well-founded and I approve of this line >of consideration. However, when considering the wide availability >of download mirrors and the format restrictions binding each of them, >a different line of consideration will likely be required to mirror >downloads. None of these download mirrors support full site/project >mirroring that I am aware of. I'll try to evaluate the available sites next week. If someone else would like to do this, feel free. A few Open Source hosting sites are listed here: http://dmoz.org/Computers/Open_Source/Hosting/ http://dmoz.org/Computers/Software/Operating_Systems/Linux/Projects/Hosting/ >I don't speak for anyone but myself, but what I was interpreting from >David D's original idea was simply a possible way to mirror our >download section. This would have no impact on the LEAF site itself or >the way that it is run or formatted. Maybe I confused the "Site Update (2002-02-27)" thread and this one. I think David is proposing something much different than you do. I think he is proposing a replacement for the /pub and /devel structure for our files. David, Would you please clarify your suggestion? >Do you think that seperating out the releases under different names in >a download mirror would seperate the release from the project? >I doubt it personally. Unknown, and this is what I'm concerned with. I continually try to present our project as a cohesive whole. Separating things in this manner may lead to fragmentation. >Would seperating the releases from the site seperate them from the >project? ... yes, I think this would. I believe this would be equivalent to a lead developer deciding he/she no longer wished to participate in LEAF at the release/branch level. -- Mike Noyes <[EMAIL PROTECTED]> http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000&page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Evolution as a project development model
At 2002-02-28 10:51 -0600, guitarlynn wrote: >On Thursday 28 February 2002 08:29, Mike Noyes wrote: > > > Lynn, > > Your description above closely resembles what SF calls a Foundry. I > > believe we are more than that. In your opinion, are we a "Linux > > Embedded Appliance Foundry", or are we a project that uses evolution > > as a development model? In my opinion, we are the latter. > >I think of LEAF more like the Gnome or KDE projects. Lynn, Gnome and KDE are single platforms that developers can write to. They use a monolithic development model for the base. Their base is then used as a resource to build things. Are different Gnome/KDE bases available to choose from? If not, they don't correlate well to our project. > > My resistance to the idea directly relates to the amount of time and > > effort that went into gathering everyone under one roof. I'm leery of > > anything that might lead us back to the fragmentation of the past. > >That is completely understood. I think the maturity and tolerance of >other ideas are far more accepted with LEAF than were constrained >within the limitations of the past. The fragmentation in the past >seemed to be developers going directions that were not accepted under >the opinion of the person hosting/controlling the "project" site. Was >Matthew's, Coyote, George Toft's, David D's, or Charles' branches ever >hosted on the LRP site, or any one site for that matter? Not that I can >remember. They were treated more like what LEAF refers to as "affiliate" >versions. They weren't even given that much recognition. The only thing allowed was mailing list use. As a result, fragmentation ensued. >I believe that is a profound and clear fundamental difference that has >no predecessor with LRP. Agreed. >The acknowledgement and existance of LEAF "affiliates" assumes the >position that you seem most concerned with, and the only seperation >between release and affiliate here appears to be the opinion and >process of the individual lead developer. Correct to some extent. However, most of our affiliates crate components (specifically firewalls) that our developers make use of when creating releases/branches. This means we don't have to create something from scratch, and allows for a faster development cycle. It also provides a synergy between the affiliated projects that is beneficial to both. There are a couple of other levels of involvement. Pim van Riezen [1] decided not to join or affiliate with us, but he does participate on the mailing lists. Ken Frazier [2] decided he didn't want anything to do with us. [1] http://freshmeat.net/projects/cish/ [2] http://www.frazierwall.com/ > From your theory of the project "evolution" model, I would assume >includes by definition that one release would eventually "eat up" >other releases. I don't see this happening per se because of the >different directions that everyone is headed. Think of evolution within a family/species, not food chain. As I sated previously [3], releases/branches survive on their merits, and the willingness of their lead developer(s) to continue working on them. [3] http://www.mail-archive.com/leaf-devel%40lists.sourceforge.net/msg04417.html >As directions from different projects head towards the same direction, >some may merge together (or rather join forces for development >reasons). Most won't! The reasoning for this, in my mind, lies in the >simple core target media a single floppy disk. This target media >will always promote different ideas and process direction. This sounds like healthy evolution to me. :-) You forgot one important thing that will prevent infinite release/branch creation. There are limited resources (developers/users) in our environment (LEAF). Mind share will prune the week eventually. Developer(s) will only work on a release/branch as long as they receive recognition of their effort. I see this every day on the SF support lists. Abandonment of unused projects is common. >Has the process of the past ever proven evolution were targets and >evolution were the same? The mere existance of LRP, Coyote, what-ever >Matthew will call his new router-system, Mosquito, Duckling, and >associated releases of LEAF (not to mention countless others) >thoroughly proves otherwise. Some simply will not exist in the umbrella >that we call LEAF and the simple existance of any or all of these >denies the concept of evolution itself as being a driving force >between LEAF releases. You just proved that evolution works on a macro level. We are using it within this project on a micro level. I doubt we're the first project to try this, but I was unable to locate an example of a prior attempt. However, I was able to locate a paper describing the benefits of chaotic evolutionary development. http://papers.maxwell.af.mil/research/ay2000/awc/hept.htm >The maturity, selflessness, and tolerance of the lead developers make >LEAF what it is, including you Mike . there are fundamenta
[Leaf-devel] Re: Leaf-devel digest, Vol 1 #599 - 7 msgs
It seems my day is being rearranged for me :-) > >Message: 7 >From: "Luis.F.Correia" <[EMAIL PROTECTED]> >To: LEAF Development <[EMAIL PROTECTED]> >Subject: RE: [Leaf-devel] Re: Standards and due process :-) >Date: Fri, 1 Mar 2002 11:36:13 - > >Adding water to a boiling and already full kettle... > Unless you are aware of something specific, all I see here are adults having a conversation and agreeing on having different point of views. Yours is welcomed as well. >Why can't we use a concept similar to this: > > >vfat is used > > > >Package name: pppd-2.1.4 >Package files: pppd-2.1.4-bin.lrp, pppd-2.1.4-conf.lrp > >pppd-bin.lrp contains all necessary binaries and 'non-editable' scripts, >pppd-conf.lrp contains all configurable files. > >All we will need then is to backup only the ???-conf.lrp files. You are squarely putting pressure on the packaging without having agreed that there is a packaging standard to begin with. At this point in time we have a de facto packaging standard, the tar gziped file with manifest in var/lib/lrpkg/file.list. In theory, there are no sacred cows and this could be revisited as well. However, this is not my purpose. I want to document the existing standard and its natural consequences on our global LEAF packaging. David is expressing a point of view that can be understood as a puzzle where everything fits neatly in a grand plan. I am expressing a point of view that can be understood as a quilt where the user builds a motif of his choice. The natural consequence of David's point of view is that users and packagers alike must follow a grand plan and it can be argued that this creates a framework in which these people can work. Michael's quest is to obtain an understanding of this grand plan so that his packaging remains correct. The natural consequence of my point of view is that there is no grand plan. Once a user has selected a number of packages which he intends to configure into an "appliance" of some sort, the onus is on the user to solve name space conflicts, if there are any. In this framework, ordinary users decide if Machael's packaging is right for them and he onlly has to deal with common sense in building his packages. I do not see why both point of views cannot coexist. From a strictly mathematical point of view, one is a subset of the other and therefore, both are valid. From a strictly human point of view, a controlled environment may be better for uneducated users and a loose environment may be better for more creative types. I don't know, I am no psychologist :-) In either points of view there are substantial benefits obtained by unambiguously enumerating the contents of components. One such benefit is that the feature set of a "distribution" becomes a lot more obvious. Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: Standards and due process :-)
Correcting subject line. Done :) I honestly cannot express myself in very fluently in English. Therefore, you will have to bear with me for a while. Try to rearrange my sentences so that they make some sense. Comments below start with [snip] >Adding water to a boiling and already full kettle... > Unless you are aware of something specific, all I see here are adults having a conversation and agreeing on having different point of views. Yours is welcomed as well. :) I'm only aware of a 'almost' religion-like discussion. Of course reading your conversation makes me aware of how little I do know about different several standards and processes exist. So my 'adding water' phrase was meant to be a joke. [snip] >All we will need then is to backup only the ???-conf.lrp files. You are squarely putting pressure on the packaging without having agreed that there is a packaging standard to begin with. At this point in time we have a de facto packaging standard, the tar gziped file with manifest in var/lib/lrpkg/file.list. In theory, there are no sacred cows and this could be revisited as well. I agree with you that we do have a 'de facto packaging standard' as you pointed out. My point was only: In order to 'simplify' the simple act of packaging, from the user's point of view, we should split what does not need to be backed up from what does! I read almost every day that user X using distro Y backed up root.lrp and destroyed her/his boot floppy! Since that, with my idea, root.lrp would not even appear in the backup script screen, the user would be protected from her/himself! You know, must Windows guys like me are teached from the early beginning to reboot, reboot and reboot whenever something simple as a mouse change occours. That 'teaching' makes us do very wrong things like backup and reboot. Well, now I'm digressing... but I guess that you'll see the picture. As for the rest of your comments, I must leave the discussion as it is :) I will most certainly benefit from this discussion. Things tend to improve when people discuss a lot :) Have a nice weekend! However, this is not my purpose. I want to document the existing standard and its natural consequences on our global LEAF packaging. David is expressing a point of view that can be understood as a puzzle where everything fits neatly in a grand plan. I am expressing a point of view that can be understood as a quilt where the user builds a motif of his choice. The natural consequence of David's point of view is that users and packagers alike must follow a grand plan and it can be argued that this creates a framework in which these people can work. Michael's quest is to obtain an understanding of this grand plan so that his packaging remains correct. The natural consequence of my point of view is that there is no grand plan. Once a user has selected a number of packages which he intends to configure into an "appliance" of some sort, the onus is on the user to solve name space conflicts, if there are any. In this framework, ordinary users decide if Machael's packaging is right for them and he onlly has to deal with common sense in building his packages. I do not see why both point of views cannot coexist. From a strictly mathematical point of view, one is a subset of the other and therefore, both are valid. From a strictly human point of view, a controlled environment may be better for uneducated users and a loose environment may be better for more creative types. I don't know, I am no psychologist :-) In either points of view there are substantial benefits obtained by unambiguously enumerating the contents of components. One such benefit is that the feature set of a "distribution" becomes a lot more obvious. Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Introducing myself
Well, I guess I never did properly introduce myself... I'm currently working as a developper for a Portuguese Institute, preparing a Windows NT 4 Unattended Installation that provides for a fully working workstation for front and backoffice users. I have been in contact on and off with Linux for the last 8 years. I was introduced to LRP by one of Leaf developpers, Pedro Barreto. I have as contributed little to the general cause, but I've been learning a lot in the last 2 years. I have made my own home router, based on EigerStein with pppd and a lot of small changes to fit my designs. I am currently able to recompile kernels and compile (small) applications. Maybe if I do have some free time, I will dedicate more time to Leaf. That's it! take care! One thing I would like to see LRP as the pre-historic mud from where we DID evolve, not as the holy grail. What we do owe to Dave Cinege is his initial idea. Luis Correia URC - Unidade de Redes e Comunicações - Intranet & Internet IIES - Instituto de Informática e Estatística da Solidariedade ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
> >It sounds almost like you want a "minimal set" of enumerated binaries and > >functions, and then Oxygen would add set X and Dachstein would add set Y. > > Nope. No. Nein. Niet. Non. :-) > > There is NO baseline. > > There is one standard: the formation of a package. > > The final decision on a configuration always rest with the user and she > expects the tools to do her job. There actually *IS* a baseline implicit in the above. *SOMETHING* has to get linux booted, create/mount a root filesystem, and load the proverbial "package". This implies some sort of boot-strapping code, as well as some sort of "package" format. Allow me to wander off on a slight philosophical tangent... I think the core question is what makes LEAF LEAF? What are the consistent features between all the distributions we think of as being part of the LEAF family? There are *LOTS* of tiny linux distributions, and a rapidly growing number of embedded linux distributions...what makes LEAF different from any of these? Many things come to mind, but I think the core feature is the dynamic generation of a linux run-time environment on boot. The embedded guys build a complete environment on their high-powered development machine, then burn a static filesystem image into their ROM, flash, or whatever storage media they're using, and that's pretty much the end of it. You may not even be able to write to a file, much less be able to install a package for new functionality. The tiny linux distribution folks are also substantially different from LEAF. Virtually all of these distributions are based on running from a hard-disk, and are essentially slimmed down versions of various full releases. Typically, if you don't have a hard-drive (or a good aproximation of one), you can't effictively run one of these distributions. LEAF, LRP, and a few other micro-distributions are designed to run without a hard-disk, yet be extensible via a packaging system. IMHO, this is the single most unique and identifying feature of LEAF's many distributions, and what sets us apart from the broader linux community in general. Additional characteristics like the linuxrc script, and the 2.2 series kernel patches, exist due to the requirements of having a packaging system and dynamically constructing the run-time environment at boot. We've inherited a set of packaging and boot-strap conventions from LRP. It's already been shown that the boot-strap conventions are not required to make a LEAF system...this is evidence that while essential to a system actually working, the specific boot methodology is *NOT* a critically core part of LEAF. So...who wants to start playing with the packaging system and re-defining LEAF? Once the packaging system is smart enough to know which files are configuration files (and maybe even able to tell which files have changed), it becomes much easier to support a variety of potentially complex issues, allowing users, developers, or the in-between "tinkerers" to setup backups and the loading of configuration data the way they want. Lots of nifty ideas about this, but not enough time to jot everything down, and I don't want David getting mad at me again ;-) Seriously, I hope to have some time next week to begin to get some of the ideas bouncing around in my head out into the open, where they can grow and develop from everyone's input (or maybe they'll shrink back and be killed by the light). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] [ leaf-Support Requests-524646 ] trouble loading module for nic
Support Requests item #524646, was opened at 2002-03-01 18:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=213751&aid=524646&group_id=13751 Category: Dachstein Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Charles Steinkuehler (cstein) Summary: trouble loading module for nic Initial Comment: Hi, I have read all of the docs for my distib of leaf (Dachstein) and am still having some trouble. I downloaded the RTL8139.o module for my nic cards and placed them in /lib/modules and added it to the /etc/modules config file. The docs for this driver say that pci-scan must also be installed, so i did that. I then backed everything up and rebooted. The nic cards are not found or working. Lsmod shows the other modules that have loaded but not the one I added (yes they are in the /lib/modules and the config file). When I try to insmod the module it says 'process busy' Please help!!! Thanks.. Jeff p.s. have learned alot and keep up the good work. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=213751&aid=524646&group_id=13751 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Charles Steinkuehler wrote: > > > >It sounds almost like you want a "minimal set" of enumerated binaries and > > >functions, and then Oxygen would add set X and Dachstein would add set Y. > > > > Nope. No. Nein. Niet. Non. :-) > > > > There is NO baseline. > > > > There is one standard: the formation of a package. > > > > The final decision on a configuration always rest with the user and she > > expects the tools to do her job. > > There actually *IS* a baseline implicit in the above. *SOMETHING* has to > get linux booted, create/mount a root filesystem, and load the proverbial > "package". This implies some sort of boot-strapping code, as well as some > sort of "package" format. Yes -- the bounds to which are the objects of my lines of questioning . . . [ snip ] > Once the packaging system is smart enough to know which files are > configuration files (and maybe even able to tell which files have changed), > it becomes much easier to support a variety of potentially complex issues, > allowing users, developers, or the in-between "tinkerers" to setup backups > and the loading of configuration data the way they want. Believe it or not, this is the end to all of my lines of questioning. Once we know this and know what can be expected -- and, corrallarily, what cannot be known -- then, and only then, can that system be ``in control'' and we can say that we are managing that system. Until that time, there is simply too little known about that system to quantify the degree of certainty that we can claim. Perhaps, this is where David parts company, since he is not interested in building firewalls; rather, his interest -- imho -- lies more in pushing various limits of these creatively designed systems. Yes, that is admirable creativity and inventiveness -- kudos, David! However, my primary interest in LEAF is management, monitoring and security based. I, for one, do *not* see these priorities as mutually exclusive; rather, I believe that these, and others equally different, views can coexist and grow and flourish together under the aegis of LEAF . . . > Lots of nifty ideas about this, but not enough time to jot everything down, > and I don't want David getting mad at me again ;-) > > Seriously, I hope to have some time next week to begin to get some of the > ideas bouncing around in my head out into the open, where they can grow and > develop from everyone's input (or maybe they'll shrink back and be killed by > the light). I look forward to new ideas . . . -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel