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: assume vfat is used /assume 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 21. 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: assume vfat is used /assume 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/package.{anything.goes} b) file names of the form
var/lib/lrpkg/package.{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 fill in package name work with fill in distribution name?.
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=1000page_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: snip 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 fundamental differences in you having the power over this site w/o
[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: assume vfat is used /assume 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 LC [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. LC :) 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. LC 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! rant 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. /rant 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
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
