Re: [Leaf-devel] cvs src tree
On Mon, 26 Aug 2002 14:11:13 -0500 guitarlynn [EMAIL PROTECTED] wrote: +packages +glibc-2.0 +glibc-2.1 +glibc-none +binaries I believe the seperation of glibc within packages will avoid confusion between packages with the same package name that actually differ in end use. If we use David's build system for our packages tree, isn't the glibc separation unnecessary? Has anyone evaluated David's build system yet? I'm sure he would appreciate some feedback. Is it a usable system for our packages tree? The tree looks great, however there is no source that I could find located within the tree itself. It appeared able to pull the source from a remote location from the tree, however I thought that we found that doing that would be unacceptable under the GPL anyway (possibly fine within the MIT licensing, I dunno). The GPL does not support linking remote source as I believe we discovered and the reasoning for getting the LEAF source tree up in the first place. As I understand it, we simply need the source posted for compiled binaries and linked from where the compiled binary is available for download AND the source must be located locally. Does this really need to be done? If the source is unmodified, why would we create another internet residence for it (other than mirroring needs, in which case that's how we should handle it, although I don't think the LEAF project is in a disk space position to be mirroring upstream packages). I haven't seen anything in the GPL that says we need to duplicate unmodified source on our site. The last paragraph of section three seems to make linking to upstream sources okay. The distribution method for sources should match the distribution method of the binaries, but the purpose of the GPL is not to force multiple destinations to be available for downloading a single source package. It is to attempt to put legal constraints on the spirit of a community. Since it almost never behooves a company to become a true part of a community, the license tries to enforce the proper behavior from them. Companies (and some people, I should be fair) do not understand communities; they only understand free source code and shortened project timelines. Frankly, the true spirit of the GPL is being followed as long as we allow people to easily do exactly as we have done: download upstream sources, modify them to suit their needs (by patching) and compile them into machine-readable code for their platform. Doing these things will help us as developers sharing a common methodology, too. Also, if we make a modification to a source package (such as Bering has done with the scripts from freeswan) we need to have a proper way to make those modifications available so that people can use them (probably shell script mods are not a good example in this case, since technically they are available in the binary distribution). It should be easy for people to find and separate our modifications so that they can use some or all of them, in conjunction with their own. For instance, if someone wanted to use the freeswan modifications, but they had the regular route program, and they were masochists and had their own modification to remove the 300-line awk script in the manual script, they should be able to identify and modify our changes easily. They should be able to find a patch and exactly how to apply it, so that they can remove the parts of our patch that they don't need and find instructions and a build environment so that they can apply their own patch. Whew, that was pretty long winded. Essentially, we need to understand what the GPL means. It is not meant to be a burden on developers (which disk space is, in our circumstance, it seems) but to be a legal invocation of some concepts. We need to follow those concepts. It is sad when people come onto the list and make GPL developers afraid of ridicule or losing some privilege, when all they need to do is cover some accounting work. Yes, we should consider this a primary effort, but it is not trivial to do it right, people understand that. Our development has grown faster than we have kept up with the details, that's all. The addition of a binary tree will allow for compiled executables/utilities that are not part of any core image or package that are available for LEAF. Please explain the need for a binary tree in src. Its purpose is not clear to me from your explanation above. Is it for source tarballs from other projects? There are several binaries that various people offer that are not part of a LEAF package (su, telnet, etc). It would be strange to stick a non-packaged src in the package src, but another thought would be to simply offer the binary src and not the entire LEAF package since everything else in the packages are script and their own src code. Thoughts? This would be source code that may
[Leaf-devel] Re: [leaf-user] Webbased configuration
On Wednesday 28 August 2002 12:56, Eric Wolzak wrote: (snip) I agree with your summary Eric. Advantage of webmin, there are all kinds of modules. Adaption is much easier than building from scratch. Disadvantage memory and CPU. I would be against using Perl personally. Porting Webmin would not necessarily be any better or faster than starting from scratch IMHO. Alternatively, use the same fields and write the engine in shell.script or php using sh-httpd. or a small server (boa, thttpd) It can be done with sh-httpd. Mosquito has used thttpd, but thttpd is considerably larger (and more versitile). My vote would be to use sh-httpd w/POST patch. Advantage probably, less memory and cpu consuming. ... I think any how, this should be a project for a group, who wants to contribute. I agree here as well. A group along these lines was discussed ~2 months ago. A couple of people were working on formatting Weblet and reworking it and I have developed a shell-atmosphere that will allow generating conf files from either GET or POST sh-httpd atmosphere. Modularization has always been in the plan, however nothing but test coding exists at this time being as I needed to jump through a few hoops to get the CGI environment working with sh-httpd. Anyone who would like to volunteer to work on any ideas, code re-work within the existing Weblet, or developing the new code-base for CLI/WWW configuration integration would be welcome to participate. In previous discussions with Mike N and Charles, the use of the leaf-devel mailing-list is encouraged for this project. This project would be beneficial to work under the LEAF umbrella and stay independant of releases. As everyone else was working with a Bering base, I am presently working with Bering as well (though I have worked on a Dachstein base as well). I am presently starting work on the framework. I believe that this is more of a devel topic, so I am moving the thread to leaf-devel. Is anyone ready to work on and/or discuss any sections of this??? Thx, ~Lynn -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: [leaf-user] Webbased configuration
Alternatively, use the same fields and write the engine in shell.script or php using sh-httpd. or a small server (boa, thttpd) It can be done with sh-httpd. Mosquito has used thttpd, but thttpd is considerably larger (and more versitile). My vote would be to use sh-httpd w/POST patch. IMHO, any web-administration utility should be fairly web-server neutral. Since sh-httpd is small, and presents what I believe is a standard CGI interface to back-end programs, it is a good candidate. It should be possible to use boa, thttpd, apache, or any other CGI-enabled web-server with little difficulty, however. Anyone who would like to volunteer to work on any ideas, code re-work within the existing Weblet, or developing the new code-base for CLI/WWW configuration integration would be welcome to participate. snip I am presently starting work on the framework. I believe that this is more of a devel topic, so I am moving the thread to leaf-devel. Is anyone ready to work on and/or discuss any sections of this??? I can commit to any updates/modifications to sh-httpd that may be required. I think it's possible to dramatically increase the CGI response of the existing sh-httpd when running CGI's, which would be a big help for a CGI driven admin interface. I can also help with architure, debugging, and (hopefully) crafty solutions to difficult scripting problems, but I can't commit to writing a major chunk of code due to current time constraints (although this may change suddenly if the company I work for suddenly craters :-/ ). *WACKY THOUGHT* - If we use sh-httpd as the web-server, and shell-script CGI's, would there be any benifit to wrapping the whole thing into a unified structure? In other words, create a custom script-based CGI interface, rather than trying to match standard CGI...something like a shell-script version of PHP. It could probably be faster/smaller than sticking with a conventional web-server/CGI approach, but would be less portable to other web servers. Something to think about. *WACKY IDEA #2* I've been investigating forth, and will be working on a micro-controller based hygrometer project running forth on an Ateml AVR processor in the near future. I've been wanting access to a scripting language more powerful than shell-script on LEAF, and I think forth might fit the bill. It's possible to compile forth without *ANY* libc requirements, but with the ability to talk *DIRECTLY* to the kernel (so you could load libc and make calls to it, if you really wanted, and do pretty much anything you want...remember the irreplacable part of libc is essentially an interface between C programs and the kernel, the rest is just a bunch of standard routines to make programmer's lives a bit easier). That's a lot of power for an interpreter that would probably weigh in at 10K to 20K Bytes, with code that can potentially run at near optimized C speeds (ie *WAY* faster than shell-script)! I've wanted to code an initial bootstrap loader in forth for a while (something that would boot from CD/Floppy/whatever, and optionally swap out the kernel, allowing fancy boot-time configuration w/o having to re-burn a CD to set kernel options. The ability to make kernel calls from a script, w/o having any libc or /bin/sh dependencies is very cool for a boot-loader. I also think an available forth interpreter could potentially help the construction of a new packaging system as well as fancy CGI admin scripts. I can volunteer time to help craft a forth implementation for LEAF, if anyone else is interested... ...oh, if you really want to get wacky, the web-server could be written in forth, too! ...signing off before I convince everyone I'm clinically insane! :-) Charles Steinkuehler [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: [leaf-user] Webbased configuration
Hello Charles, Lynn , list Alternatively, use the same fields and write the engine in shell.script or php using sh-httpd. or a small server (boa, thttpd) It can be done with sh-httpd. Mosquito has used thttpd, but thttpd is considerably larger (and more versitile). My vote would be to use sh-httpd w/POST patch. IMHO, any web-administration utility should be fairly web-server neutral. Since sh-httpd is small, and presents what I believe is a standard CGI interface to back-end programs, it is a good candidate. It should be possible to use boa, thttpd, apache, or any other CGI-enabled web-server with little difficulty, however. I agree with this. I like the sh-httpd, although I have some problems with persisiting /tmp files. The webconfiguration interface will not get lots of page views at one time, ( at least I hope so ;) ). But depending on what you are doing repeatedly viewing from one page. Anyone who would like to volunteer to work on any ideas, code re-work within the existing Weblet, or developing the new code-base for CLI/WWW configuration integration would be welcome to participate. snip I am presently starting work on the framework. I believe that this is more of a devel topic, so I am moving the thread to leaf-devel. Is anyone ready to work on and/or discuss any sections of this??? I would like to commit. ( time is also sparse :( ) I would propose to get something like webmin does. some routines for individual packages reading in variables combining them with package specific items and then into the engine throwing out a webpage /form after posting the option file is written out in standard option.textfile I can commit to any updates/modifications to sh-httpd that may be required. I think it's possible to dramatically increase the CGI response of the existing sh-httpd when running CGI's, which would be a big help for a CGI driven admin interface. That would be great. I can also help with architure, debugging, and (hopefully) crafty solutions to difficult scripting problems, but I can't commit to writing a major chunk of code due to current time constraints (although this may change suddenly if the company I work for suddenly craters :-/ ). I don't hope so ( for you and the company that is) *WACKY THOUGHT* - If we use sh-httpd as the web-server, and shell-script CGI's, would there be any benifit to wrapping the whole thing into a unified structure? In other words, create a custom script-based CGI interface, rather than trying to match standard CGI...something like a shell-script version of PHP. It could probably be faster/smaller than sticking with a conventional web-server/CGI approach, but would be less portable to other web servers. Something to think about. that sounds good to me. fast and small is something we could need for the doorstop computers still running . *WACKY IDEA #2* I've been investigating forth, and will be working on a micro-controller based hygrometer project running forth on an Ateml AVR processor in the near future. I've been wanting access to a scripting language more powerful than shell-script on LEAF, and I think forth might fit the bill. It's possible to compile forth without *ANY* libc requirements, but with the ability to talk *DIRECTLY* to the kernel (so you could load libc and make calls to it, if you really wanted, and do pretty much anything you want...remember the irreplacable part of libc is essentially an interface between C programs and the kernel, the rest is just a bunch of standard routines to make programmer's lives a bit easier). That's a lot of power for an interpreter that would probably weigh in at 10K to 20K Bytes, with code that can potentially run at near optimized C speeds (ie *WAY* faster than shell-script)! sounds good, but sounds also like a lot of work I am not that kind of a coder. ;) I've wanted to code an initial bootstrap loader in forth for a while (something that would boot from CD/Floppy/whatever, and optionally swap out the kernel, allowing fancy boot-time configuration w/o having to re-burn a CD to set kernel options. The ability to make kernel calls from a script, w/o having any libc or /bin/sh dependencies is very cool for a boot-loader. I also think an available forth interpreter could potentially help the construction of a new packaging system as well as fancy CGI admin scripts. I can volunteer time to help craft a forth implementation for LEAF, if anyone else is interested... ...oh, if you really want to get wacky, the web-server could be written in forth, too! ...signing off before I convince everyone I'm clinically insane! :-) That would make two of us ;) Eric Wolzak --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL
Re: [Leaf-devel] Re: [leaf-user] Webbased configuration
Hi Eric, Lynn, Charles Asking for permission to come aboard. regards Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Webbased configuration
Hi Eric, Lynn, Charles Asking for permission to come aboard. Dive right in! You'll either sink or swim. Please don't swim within 30 minutes of eating. Remember your life-preserver. Go with the flow, swim against the current, or maybe just try treading water...your preference. Please keep your arms and legs inside the vehicle until the ride comes to a full and complete stop. WELCOME ABOARD! ...OK, enough already :) Charles Steinkuehler [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] RE: [leaf-user] Webbased configuration
I also agree perl would be an overkill. What we need is to create a framework like we have for lrps for web based management. Every lrp must have a web based config template that will be used by a master web script. The template format and scripting needs to be developed and standardised. I'm not a programmer nor can I write good programs. I can test and document though. I volunteer for this part. Mohan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of guitarlynn Sent: 30 August 2002 00:33 To: Eric Wolzak Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [leaf-user] Webbased configuration On Wednesday 28 August 2002 12:56, Eric Wolzak wrote: (snip) I agree with your summary Eric. Advantage of webmin, there are all kinds of modules. Adaption is much easier than building from scratch. Disadvantage memory and CPU. I would be against using Perl personally. Porting Webmin would not necessarily be any better or faster than starting from scratch IMHO. Alternatively, use the same fields and write the engine in shell.script or php using sh-httpd. or a small server (boa, thttpd) It can be done with sh-httpd. Mosquito has used thttpd, but thttpd is considerably larger (and more versitile). My vote would be to use sh-httpd w/POST patch. Advantage probably, less memory and cpu consuming. ... I think any how, this should be a project for a group, who wants to contribute. I agree here as well. A group along these lines was discussed ~2 months ago. A couple of people were working on formatting Weblet and reworking it and I have developed a shell-atmosphere that will allow generating conf files from either GET or POST sh-httpd atmosphere. Modularization has always been in the plan, however nothing but test coding exists at this time being as I needed to jump through a few hoops to get the CGI environment working with sh-httpd. Anyone who would like to volunteer to work on any ideas, code re-work within the existing Weblet, or developing the new code-base for CLI/WWW configuration integration would be welcome to participate. In previous discussions with Mike N and Charles, the use of the leaf-devel mailing-list is encouraged for this project. This project would be beneficial to work under the LEAF umbrella and stay independant of releases. As everyone else was working with a Bering base, I am presently working with Bering as well (though I have worked on a Dachstein base as well). I am presently starting work on the framework. I believe that this is more of a devel topic, so I am moving the thread to leaf-devel. Is anyone ready to work on and/or discuss any sections of this??? Thx, ~Lynn -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: [leaf-user] Webbased configuration
combined reply to several posts and some ideas (at the bottom): On Thursday 29 August 2002 14:59, Charles Steinkuehler wrote: to leaf-devel. Is anyone ready to work on and/or discuss any sections of this??? I can commit to any updates/modifications to sh-httpd that may be required. I think it's possible to dramatically increase the CGI response of the existing sh-httpd when running CGI's, which would be a big help for a CGI driven admin interface. Great! I had JamesSturdevant send me his patched sh-httpd binary since several of us had major problems applying the diff he had posted. I can send it to you off-list. I haven't dug through it or done a diff myself, but the POST function does work per my testing. I can also help with architure, debugging, and (hopefully) crafty solutions to difficult scripting problems, but I can't commit to writing a major chunk of code due to current time constraints (although this may change suddenly if the company I work for suddenly craters :-/ ). I understand, I have a little more time once I finish roofing my house (within the weekend, I hope). I can distribute what testing code I have presently, but the architecture will definately need the be the first thing on the todo list. I have compiled the su-wrapper binary that will solve the write permissions problems as well. I'm presently working with SF on fixing my CVS access, as SF has blocked all SSH connections from my Desktop the last couple of days. :-((( BTW, I hope everything is still maintaning for you on the work end! *WACKY THOUGHT* - If we use sh-httpd as the web-server, and shell-script CGI's, would there be any benifit to wrapping the whole thing into a unified structure? In other words, create a custom script-based CGI interface, rather than trying to match standard CGI...something like a shell-script version of PHP. It could probably be faster/smaller than sticking with a conventional web-server/CGI approach, but would be less portable to other web servers. Something to think about. I hate to break any portability, but it would be a serious consideration being that Weblet would essentially be integrated and only LEAF style OS's would likely use it. It would also be a space saver on the floppy end. Good idea! *WACKY IDEA #2* I've been investigating forth, and will be working on a micro-controller based hygrometer project running forth on an Ateml AVR processor in the near future. I've been wanting access to a scripting language more powerful than shell-script on LEAF, and I think forth might fit the bill. It's possible to compile forth without *ANY* libc requirements, but with the ability to talk *DIRECTLY* to the kernel (so you could load libc and make calls to it, if you really wanted, and do pretty much anything you want...remember the irreplacable part of libc is essentially an interface between C programs and the kernel, the rest is just a bunch of standard routines to make programmer's lives a bit easier). That's a lot of power for an interpreter that would probably weigh in at 10K to 20K Bytes, with code that can potentially run at near optimized C speeds (ie *WAY* faster than shell-script)! Good idea, but I don't know if any of us except Charles and David D are familiar with Forth. I think I wrote a hello world! program in Forth around 15 years ago, but I haven't retained any more about the language since then. It was a low-level language similar to machine language if I remember right. :-) I've wanted to code an initial bootstrap loader in forth for a while (something that would boot from CD/Floppy/whatever, and optionally swap out the kernel, allowing fancy boot-time configuration w/o having to re-burn a CD to set kernel options. The ability to make kernel calls from a script, w/o having any libc or /bin/sh dependencies is very cool for a boot-loader. I also think an available forth interpreter could potentially help the construction of a new packaging system as well as fancy CGI admin scripts. Maybe a few of us should spend some time and learn forth. C is about as cryptic of a language as I've learned to interpret, but it sounds as if LEAF could gain a lot by using it. On Thursday 29 August 2002 15:44, Eric Wolzak wrote: I would propose to get something like webmin does. some routines for individual packages reading in variables combining them with package specific items and then into the engine throwing out a webpage /form after posting the option file is written out in standard option.textfile This is what I had in mind. Adding backup would be rather simple as well. The largest sticky point I see at this time is reading and over-writing the existing configuration files. An example would be setting the internal interface network information many packages need this information. It would simplify things to enter the information in it's own file, then source the information to the relevent file needing it.
