[Leaf-devel] Freeswan/IPSEC 1.98b for Bering available
Please check: http://leaf.sourceforge.net/article.php?sid=47 for the details Those updated packages are untested. Please report success/problems. Jacques --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] Affiliates
But when webadmin is upgraded, a license may change. I'm sorry to hear this, but those that write the code usually get to choose the license. Don't worry. It is a far future. # I'm developing kernel 2.4. It is going to use the linuxrc code of Bering. Great. Is there an announcement list I can use to keep up to date with the developments of IPnuts? Also, should I change the name on our affiliates page to IPnuts? If so, will you have a new topic icon for IPnuts available in the near future? I'm glad to change Mosquito to IPnuts. But floppy version is IPnuts 3.4 Mosquito, so you don't need to change icon and link. IPnuts Mosquito include only free package,and kernel supports only floppy device, not ide. And If possibble,I will want to maintain free version. --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Bering RC3 uClibc
I managed to build an (allmost) complete version of Bering RC3 against uClibc 0.9.12. This version is *a lot* smaller than the original version build against GLIBC2. I tested the following modules: weblet, root, initrd, dhcpd, pump, ezipupd, dnscache... I don't use pppd, so I couldn't test it but it compiled without a problem. I had some problems with the symbolic links stdin, stdout and stderror to /dev/fd in root.dev.mk (I couldn't log in) so I removed them, still everything works like expected. I don't know exactly what the problem is with stdin etc but maybe it's got something to do with uClibc, tinylogin or the version of ash I use (slack 8.1). I don't have the ip patched version of ifupdown and included ifconfig and route. There is a new version of ifupdown (0.6.4-4.3) that makes it possible to use udhcp and make things even smaller. I don't know if uClibc is the way to go for LEAF, but it's rappidly evolving. Glibc 2.0.7 is not maintained and Glibc 2.2.x is just to big to fit on a floppy. An other 'advantage' of uClibc is that you can get rid of nss libs and nsswitch.conf. Regards, Eric Spakman --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Bering RC3 uClibc
In my experience you have to be careful with uClibc.. I also tried migrating to it and while the binaries seemed to run, I got various glitches and strange behavior. BTW, WISP-Dist's initrd is based on busybox/ash/sed compiled against uClibc. E.Spakman wrote: I managed to build an (allmost) complete version of Bering RC3 against uClibc 0.9.12. This version is *a lot* smaller than the original version build against GLIBC2. I tested the following modules: weblet, root, initrd, dhcpd, pump, ezipupd, dnscache... I don't use pppd, so I couldn't test it but it compiled without a problem. I had some problems with the symbolic links stdin, stdout and stderror to /dev/fd in root.dev.mk (I couldn't log in) so I removed them, still everything works like expected. I don't know exactly what the problem is with stdin etc but maybe it's got something to do with uClibc, tinylogin or the version of ash I use (slack 8.1). I don't have the ip patched version of ifupdown and included ifconfig and route. There is a new version of ifupdown (0.6.4-4.3) that makes it possible to use udhcp and make things even smaller. I don't know if uClibc is the way to go for LEAF, but it's rappidly evolving. Glibc 2.0.7 is not maintained and Glibc 2.2.x is just to big to fit on a floppy. An other 'advantage' of uClibc is that you can get rid of nss libs and nsswitch.conf. Regards, Eric Spakman --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel -- Best Regards, Vladimir Systems Engineer (RHCE) --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: Bering RC3 uClibc
I agree, but it runs for a few days now and I don't have any problems with it. All binaries work and I didn't see any glitches or strange behavior. The version of uClibc I used is the latest stable one. I will look at WISP, thanks for pointing me to that. Eric Spakman Vladimir I. wrote: In my experience you have to be careful with uClibc.. I also tried migrating to it and while the binaries seemed to run, I got various glitches and strange behavior. BTW, WISP-Dist's initrd is based on busybox/ash/sed compiled against uClibc. --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Bering RC3 uClibc
On Tue, 2002-07-09 at 07:40, Vladimir I. wrote: In my experience you have to be careful with uClibc.. I also tried migrating to it and while the binaries seemed to run, I got various glitches and strange behavior. Which binaries caused problems? uClibc gets better and better all the time and now supports many applications. -Richard --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Bering RC3 uClibc
Hmm... Don't remember exactly now. I think it was Zebra. Richard Doyle wrote: On Tue, 2002-07-09 at 07:40, Vladimir I. wrote: In my experience you have to be careful with uClibc.. I also tried migrating to it and while the binaries seemed to run, I got various glitches and strange behavior. Which binaries caused problems? uClibc gets better and better all the time and now supports many applications. -Richard -- Best Regards, Vladimir Systems Engineer (RHCE) --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Bering RC3 build with uClibc
On Tue, 2002-07-09 at 08:30, Eric Spakman wrote: Hello, I managed to build an (allmost) complete version of Bering RC3 against uClibc 0.9.12. This version is *a lot* smaller than the original versionbuild Cool. against GLIBC2. I tested the following modules: weblet, root, initrd, dhcpd, pump, ezipupd, dnscache... I don't use pppd, so I couldn't test it but it compiled without a problem. I had some problems with the symbolic links stdin, stdout and stderror to /dev/fd in root.dev.mk (I couldn't log in) so I removed them, still everything works like expected. I don't know exactly what the problem is with stdin etc but maybe it's got something to do with uClibc, tinylogin or the version of ash I use (slack 8.1). In my experience, the version of ash provided by busybox works pretty well. Why did you decide to use slack ash instead? I don't have the ip patched version of ifupdown and included ifconfig and route. There is a new version of ifupdown (0.6.4-4.3) that makes it possible to use udhcp and make things even smaller. It is unfortunate that the ifupdown patch is not public; Bering is less than 100% open source as a result. I don't know if uClibc is the way to go for LEAF, but it's rappidly evolving. Glibc 2.0.7 is not maintained and Glibc 2.2.x is just to big to fit on a floppy. If enough of us use uClibc-based LEAF packages, perhaps there should be a uClibc branch in the LEAF package repository. One problem is that new uClibc versions are released fairly frequently; perhaps we could standardize on the current release (0.9.12), and provide new branches for new releases. An other 'advantage' of uClibc is that you can get rid of nss libs and nsswitch.conf. Regards, Eric Spakman -Richard --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Bering RC3 build with uClibc
On Tue, 2002-07-09 at 10:39, Richard Doyle wrote: On Tue, 2002-07-09 at 08:30, Eric Spakman wrote: I don't know if uClibc is the way to go for LEAF, but it's rappidly evolving. Glibc 2.0.7 is not maintained and Glibc 2.2.x is just to big to fit on a floppy. If enough of us use uClibc-based LEAF packages, perhaps there should be a uClibc branch in the LEAF package repository. One problem is that new uClibc versions are released fairly frequently; perhaps we could standardize on the current release (0.9.12), and provide new branches for new releases. Richard, I'd prefer a single uclibc tree in bin/packages. We can specify the version used in the commit message. The other possibility is static complies. I thought someone said that uClibc static binaries were actually smaller than ones compiled dynamically. Is this correct? Note: we already have some uClibc static packages. I currently plan on adding them to our bin/packages/nolibc tree. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Bering RC3 build with uClibc
On Tue, 2002-07-09 at 11:01, Mike Noyes wrote: On Tue, 2002-07-09 at 10:39, Richard Doyle wrote: On Tue, 2002-07-09 at 08:30, Eric Spakman wrote: I don't know if uClibc is the way to go for LEAF, but it's rappidly evolving. Glibc 2.0.7 is not maintained and Glibc 2.2.x is just to big to fit on a floppy. If enough of us use uClibc-based LEAF packages, perhaps there should be a uClibc branch in the LEAF package repository. One problem is that new uClibc versions are released fairly frequently; perhaps we could standardize on the current release (0.9.12), and provide new branches for new releases. Richard, I'd prefer a single uclibc tree in bin/packages. We can specify the version used in the commit message. Sounds workable. The other possibility is static complies. I thought someone said that uClibc static binaries were actually smaller than ones compiled dynamically. Is this correct? I doubt it, but haven't done any tests. If true, I'd happily save space by statically compiling all my binaries, but it sounds too much like a free lunch. Note: we already have some uClibc static packages. I currently plan on adding them to our bin/packages/nolibc tree. I like the idea of separate bin/packages/nolibc and bin/packages/uclibc trees. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ -Richard --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Bering RC3 build with uClibc
On 9 Jul 2002, Richard Doyle wrote: On Tue, 2002-07-09 at 11:01, Mike Noyes wrote: [...] The other possibility is static complies. I thought someone said that uClibc static binaries were actually smaller than ones compiled dynamically. Is this correct? I doubt it, but haven't done any tests. If true, I'd happily save space by statically compiling all my binaries, but it sounds too much like a free lunch. No free lunch. If you have only one executable, static linking is smaller. If you have multiple executables that use a particular library, it will almost certainly be more efficient to link dynamically. -- Re: the value of uClibc... I think it is good that someone is doing this, but it is also good to be clear that the gain in code size comes at a potential narrowing of applicability due to incompatibility with glibc. For closed boxes, this is probably actually desirable... but one of the selling points of LEAF is its adaptability. To the extent that uClibc fails to implement features of glibc (e.g. localization), the usefulness of LEAF based on it will be necessarily limited. To reiterate I think there is room for both, but the tradeoffs should be made clear to new LEAF users. --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Antivirus and other issues
Hi all, We are developing an antivirus gateway based on Leaf Bering. Right now we have been able to acomplish the following: 1) Using emailrelay (http://emailrelay.sourceforge.net) we have been able to implement an smtp gateway. In proxy mode there is no need for a physicall storage without violating the RFC. This is because the queue is in RAM but no ackowledge is sent untill it receives it from the destination smtp server. Using the preprocessor directive we have been able to hook an antivirus into it to check the mail. For emailrelay to work we had to upgrade leaf to use glibc 2.2 using a colister howto as it didnt work with 2.0 This is not a problem in our case as we plan to use a Compact Flash for storage (minimum 32 MB). 2) Using pop3vscan (http://pop3vscan.sourceforge.net) we have been able to make a pop3 gateway with virus checking. Again we have used f-prot as the AV engine. We dont know if this works with glibc 2.0 as we have not tried. Things to do: 1) Test this environment under heavy load. We plan to use postal and rabid for this testing (http://www.coker.com.au/postal/). 2) Use AVP as the antivirus engine or at least the daemon version of f-prot. Right now we are using the comandline version of f-prot, and we think a daemon AV engine is needed for such a system. 3) Try squid-vscan (http://www.openantivirus.org/projects.php) with null storage. This project seems to be in very early stage and is has no hooks into f-prot nor AVP. Surely some C coding will be needed. 4) Try all this with the latest bering release (right now we are using rc2). Well this is it. All the code is GPL (besides antivirus engines of course). Please, tell us if we can use some kind of download area. Also, any testers and developers will surelly be appreciated. Thanks in advance. Regards. -- Jaime Nebrera Herrera [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Weblet Dev Demo Update
I have made the following changes: There is now a link at the botom of the page that lets you download the weblet.lrp file. This will make it easier to play with the changes I have been making or to make changes to this base. A few minor changes to the weblet.structures file and to the content files. As it now stands you can creat a content file in the content folder that has no HTML coding at all and it will display reasonably. The only HTML you need/may wish to add is to format the contents the way you wish. If/when there is further buy-in to these changes we will document everything so that it will be easy to use. Richard Amerman +,~wzf¢+,¦ì¢·o$áyyé¶ç߶§Æ§vkkj+zm§ÿí)äç¤r¿±òÞi÷^½éfj)b b²ÒÞi÷^½éeËl²«qç讧zØm¶?þX¬¶Ë(º· ~àzwþX¬¶ÏåËbú?æuëÞ
Re: [Leaf-devel] Affiliates
First of all, I would like to thank-you, kitakura, for updating us on your project and clarifying any assumptions that I made based on what little information I interpreted from various websites. TY :-) I offer my apologies for any false information/assumptions that I may have made! On Monday 08 July 2002 19:26, kitakura wrote: Packages in http://www.s-me.co.jp/mosquito/mos3_4/packages/ are GPL lisence.(and Other open source license decided by Auther.) WebAdmin is GPL. ( only japanese. a part is english) but, since we assert license, the user interface code of WebAdmin for [, such as VPN, ] a specific package is unacquirable in online. WebAdmin has the menu form which can be added. # And If not related to me, WebAdmin is used also for # firewall distribution of Japan in time. So, the only closed-source code is some form of VPN application that your distribution is using that is not easy to work around either! Good job! config.lrp is also my code. it is GPL.This can gather configuration file written .conf. I think that it is useful. Webadmin.lrp,config.lrp,rc.lrp ,etc.lrp and root.lrp can not use other leaf distribution ,since they are imcompatible. But other packages may be compatible with little modify,I think. A part of them includes code for Webadmin and rc.( but they are gpl.) Great! But when webadmin is upgraded, a license may change. I'm sad to hear that, but this is difficult to avoid when something goes commercially owned. # I'm developing kernel 2.4. It is going to use the linuxrc code of Bering. # I am thankful to many developers. This is where I was really concerned. Are you using Bering and/or Dachstein IDE code for sale-only products that do not have open code equivilents (ie... floppy-only free offerings) or planning to use Bering linuxrc code in something closed-source? I personally have reservations about these possibilities, when it is not 100% personal code in the particular application (not to reflect on any other developer with this opinion). I guess what I am getting at is this: How would you feel if I modified Webadmin.lrp and release it as a closed-source commercial offering? I not saying that this is what is being done... but rather looking at what _could_ happen at some point in the future. -- ~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 Stuff, things, and much much more. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] Affiliates
# I'm developing kernel 2.4. It is going to use the linuxrc code of Bering. # I am thankful to many developers. This is where I was really concerned. Are you using Bering and/or Dachstein IDE code for "sale-only" products that do not have open code equivilents (ie... floppy-only free offerings) or planning to use Bering linuxrc code in something closed-source? I personally have reservations about these possibilities, when it is not 100% personal code in the particular application (not to reflect on any other developer with this opinion). I guess what I am getting at is this: How would you feel if I modified Webadmin.lrp and release it as a closed-source commercial offering? I not saying that this is what is being done... but rather looking at what _could_ happen at some point in the future. Don't worry. I am following GPL . --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
