Re: [leaf-devel] Bering Crew looks for expansion
Hello, I'm Etienne Charlier, I live in belgium. I'm sofware analyst/developper since 15years I've been doing Operating system development ( Assembler 370), C/C++ Windows DNA applications, now, i'm working in a 10 people team developping software for customers ( in .NET) Please forgive my english a little bit ( Frenchie) ;-) .. good you can just read me, not hear me ;-) I follow this list since its beginining ( and before on the original lrp mailing list) and I'm really impressed by the level of expertise of all the developpers.. I have +/- 12 bering installed ( some of them running from floppies), most of them running from CD 6 are connected by pair through openvpn tunnels ( only vpn software that I managed to configure when both ends on the tunnel are on volatiles IP addresses ( ADSL PPPOE)) squid, ..tinydns,... I started customizing bering uclibc 2.0 - I managed to make a package with linux-igd ( upnp support) CVS version ( for now staticaly linked) thanks to the http://www.fastflow.it/floppinux/bering/index.html page but by rebuilding the package myself - I'm trying to master the bering-uclibc build environment and trying to make a package with openvpn ( a little bit hard for a .NET /DNA developper/architect ;-) ) - I would also like to make run the dsl_qos_queue program ( http://www.sonicspike.net/software/ ) - A few years ago ( my posts are on the list archive ) I started developping an alternate configuration system based on a unique configuration file stored on the boot floppy ( outside of the .LRP) used to process configuration file templates ( a call was made to a setup.sh or something like that at the end of the linuxrc script). That script generated the actual configuration files that overwrote the one from the packages. - I'm really interested by contributing to the web interface/cdb configuration system mainly for the soho release.. something like the web interface of the router/accesspoint/adsl modem appliances available in the stores ( usrobotics, linksys) - I'll have some spare time ( but disconnected from the Internet) during the End of year hollidays and I would be really interested by learning more deeply the cdb stuff written by Eric Chad Now a survey ??? What would be the advantage and drawbacks of merging the Bering Bering-uclibc distributions ? What would be the advantage and drawbacks of keeping the Bering Bering-uclibc distributions separate ? IMHO, I think that we don't need 2 separate variantes of bering. What do the others gurus think about that ??? Etienne Charlier [EMAIL PROTECTED] - Original Message - From: Erich Titl [EMAIL PROTECTED] To: Eric Wolzak [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, December 18, 2003 11:24 AM Subject: Re: [leaf-devel] Bering Crew looks for expansion Eric At 23:31 17.12.2003 +0100, Eric Wolzak wrote: Hello everybody, As you might know , Jacques has stopped, and gave the rudder to me. My plans with Bering are. 1. update kernel to 2.4.23. 2. update packages 3 revise the documentation and make some improvements. 4 create a basic webinterface. 5 cleanup linuxrc. 6 create a bering light for the soho environment with few options. 7 Translate the Bering Documentation This all under the following conditions A I want to keep rather close to the bering-uclibc group. B A floppy distro should still be possible. But I know I will need help with those plans :) Are there any volunteers for come aboard . Looks like a major issue, I am interested to see this move on. I am about to deploy a few boxes with specialised hardware based on Bering which needed kernel tweaks anyway. Those have been adapted by Eric Spakman for Bering uClibc. I was discussing the differences between the two distributions with members of the Bering uClibc team. I believe the kernel work could be a joint effort. I will try to move my modified kernel to 2.4.23 anyway, based on Jacques' 2.4.20 config and on the kernel building description by the uClibc team. So count me in for this. I don't know to what level Jacques has standardised the package building process. I believe the work done in the uClibc crew is remarkable, it might well be worth the effort to use it for glibc based Bering too. I believe closing ranks with the guys from the uClibc group is worth it, most of your points up there may apply to both distributions. Well what the heck, count me in with the limited time I have... 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: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=ick ___ leaf-devel mailing list [EMAIL PROTECTED]
Re: [leaf-devel] Bering Crew looks for expansion
On Fri, 2003-12-19 at 11:42, Etienne Charlier wrote: Now a survey ??? What would be the advantage and drawbacks of merging the Bering Bering-uclibc distributions ? What would be the advantage and drawbacks of keeping the Bering Bering-uclibc distributions separate ? IMHO, I think that we don't need 2 separate variantes of bering. What do the others gurus think about that ??? Etienne, The main difference I see between the Bering branches is the target audience. The uClibc team is targeting enterprise use, while the Bering team is targeting SOHO/end users. -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering Crew looks for expansion
Hi Etienne I don't consider myself a guru, but being a member of the Bering uClibc team, I feel like I can voice my opinion nevertheless. Now a survey ??? What would be the advantage and drawbacks of merging the Bering Bering-uclibc distributions ? Advantages would obviously be concentrating all efforts on one platform instead of two. Given the limited amount of developers available, that advantage may be considerable, but it's too early to judge - there may be a number of people waiting to get involved in Bering, that we just haven't heard of until now. I guess the drawbacks are that so far, not all binaries compile against uClibc (but the number is getting smaller with each release). And also, developing for uClibc is a bit more difficult than for glibc 2.0, since there's no simple install Debian xx answer - even though there is work on creating a build environment to boot into (look at uclibc.org ad also at buildtool on CVS for details). What would be the advantage and drawbacks of keeping the Bering Bering-uclibc distributions separate ? The obvious, I guess - never touch a running system. People who have a working Bering system would not have to worry about some new version. I can surely understand that people don't want to constantly mess with their firewalls (especially if it took some work to get everything just right), so being able to support the systems that are around would surely be a plus. Having said that, to me, Bering uClibc seems like the only way to go - simply because glibc 2.0 is no longer receiving any updates, and it's just a matter of time until things will just not work with it anymore (just look at the mess NPTL has caused with legacy applications on the newer RedHat systems) - especially with kernel 2.6 being out, it's bound to happen that things will move on, and applications will rely on the newer infrastructure (which glibc 2.0 cannot accomodate). I've looked at newer glibc versions, and they just won't work for a floppy (at least for a simple guy like me :-)). And while I may not need to run things from a floppy (all my leaf boxes run either from CD or CF), being able to boot from one or two floppy/floppies is still something that makes leaf very special - if one removes that, there are a ton of alternatives (Linux or BSD based) that will do the job just fine. In short, I would like to see Bering to live on for quite a while, with enough developers helping Eric, so he doesn't burn out. I would also like to see more work being done _together_ (between the Bering and Bering uClibc crews), to make life easier for both Bering and Bering uClibc developers. If we can make use of eachother's work (like has been done for the kernel in the past), I think all sides will benefit. Just my two Euro cents. Martin --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering Crew looks for expansion
Hi Mike, Now a survey ??? What would be the advantage and drawbacks of merging the Bering Bering-uclibc distributions ? What would be the advantage and drawbacks of keeping the Bering Bering-uclibc distributions separate ? IMHO, I think that we don't need 2 separate variantes of bering. What do the others gurus think about that ??? Etienne, The main difference I see between the Bering branches is the target audience. The uClibc team is targeting enterprise use, while the Bering team is targeting SOHO/end users. I'm curious - what makes you think so? My day work is targeting enterprise use (so, I think I know what they'd ask for, but then, different customers ask for different things, so one can't be sure), and with Bering uClibc, I don't see any of the buzz-words that would make it in the enterprise world (like SLAs, for example). Maybe my perception of Bering uclibc is very different of yours - and if that's so, I'd be curious to hear yours. Martin --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering Crew looks for expansion
Martin Hejl wrote: What would be the advantage and drawbacks of keeping the Bering Bering-uclibc distributions separate ? The obvious, I guess - never touch a running system. People who have a working Bering system would not have to worry about some new version. I can surely understand that people don't want to constantly mess with their firewalls (especially if it took some work to get everything just right), so being able to support the systems that are around would surely be a plus. Having said that, to me, Bering uClibc seems like the only way to go - simply because glibc 2.0 is no longer receiving any updates, and it's just a matter of time until things will just not work with it anymore (just look at the mess NPTL has caused with legacy applications on the newer RedHat systems) - especially with kernel 2.6 being out, it's bound to happen that things will move on, and applications will rely on the newer infrastructure (which glibc 2.0 cannot accomodate). I've looked at newer glibc versions, and they just won't work for a floppy (at least for a simple guy like me :-)). And while I may not need to run things from a floppy (all my leaf boxes run either from CD or CF), being able to boot from one or two floppy/floppies is still something that makes leaf very special - if one removes that, there are a ton of alternatives (Linux or BSD based) that will do the job just fine. What about the possability of moving forward with a mixed approach for the next major version? The core system (and most packages) could be compiled against uClibc, while packages that require it are compiled against a newer glibc that would optionally be installed by those with enough room (ie: running from HDD/flash/CD-ROM/etc). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering Crew looks for expansion
Hi Charles, What about the possability of moving forward with a mixed approach for the next major version? The core system (and most packages) could be compiled against uClibc, while packages that require it are compiled against a newer glibc that would optionally be installed by those with enough room (ie: running from HDD/flash/CD-ROM/etc). If there's a dying need for those applications, I wouldn't have a problem with that approach - but I don't really see the need for that at the time (as I said, the list of apps that won't compile against uClibc is growing shorter by the day). Besides, having to support a mix of glibcs sounds like a nightmare to me - not something a small group could handle, without some true glibc-wizard handling things. Or did you mean a mix of uClibc and glibc 2.0? To my knowledge, that part is already accomplished (since there are libcxxx.lrp packages for Bering uClibc). But to me, that's a dirty hack - it may work for most, but debugging those kinds of setups when things go wrong is a huge mess. Where do you start when somebody writes that after I installed libcxx and package yy, service zz starts segfaulting? - been there, done that (replace xx with whatever HP/UX 11 comes with, yy with Oracle 8 and zz with Apache 1.2) ;-) Martin --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering Crew looks for expansion
On Fri, 2003-12-19 at 13:20, Martin Hejl wrote: The main difference I see between the Bering branches is the target audience. The uClibc team is targeting enterprise use, while the Bering team is targeting SOHO/end users. I'm curious - what makes you think so? My day work is targeting enterprise use (so, I think I know what they'd ask for, but then, different customers ask for different things, so one can't be sure), and with Bering uClibc, I don't see any of the buzz-words that would make it in the enterprise world (like SLAs, for example). Maybe my perception of Bering uclibc is very different of yours - and if that's so, I'd be curious to hear yours. Martin, Let me preface this with, I believe these are good things. Bering-uClibc High Availability (fail-over) http://www.linux-ha.org/ IPv6 http://leaf-project.org/doc/guide/bucu-ipv6.html 6wall Zebra http://leaf-project.org/doc/guide/bucu-zebra.html Comparable to Cisco products in many ways. -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering Crew looks for expansion
Hi Mike, I'm curious - what makes you think so? My day work is targeting enterprise use (so, I think I know what they'd ask for, but then, different customers ask for different things, so one can't be sure), and with Bering uClibc, I don't see any of the buzz-words that would make it in the enterprise world (like SLAs, for example). Maybe my perception of Bering uclibc is very different of yours - and if that's so, I'd be curious to hear yours. Martin, Let me preface this with, I believe these are good things. Bering-uClibc High Availability (fail-over) http://www.linux-ha.org/ IPv6 http://leaf-project.org/doc/guide/bucu-ipv6.html 6wall Zebra http://leaf-project.org/doc/guide/bucu-zebra.html Comparable to Cisco products in many ways. Ok, that makes a lot of sense - but please realize, that Bering uClibc offerst the same thing Bering does (more or less), _plus_ the things you mentioned (as far as I can tell, I'll have to check out the high availibility link you sent). I guess with havving to deal with Management crap all day, enterprise use just has a slightly odd sound to me, for an open source (it probably shouldn't - maybe I've been reading too many Dilbert cartoons :-)) Thanks for clarifying Martin -- You think that's tough? Try herding cats! --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering Crew looks for expansion
Hello All, After my first mail, there were a few support offerings, that I am very gratefull too. in two of them the question came why not combine efforts. Yesterday, I discussed this topic with Mike also ( chat). I told him, i will think a few days about the future of bering. interesting is that my thoughts over the last few days have come up in your last mails. facts are. 1.Updateing and compiling new programms for Glibc is becoming more difficult. 2 Glibc 2.0 isn't updated anymore. 3. Uclibc is more compact and more modern. 4. Getting two entirely parallel branches that differ only in library isn't worth the work spend on it. 5. The number of packages that will compile against Uclibc is increasing, and for the floppy user, all possible packages probably compile. 6. I am not that good at adapting old librarys to new programs ;( The conclusions I came up to so far are. 1. getting the route towards the bering-uclibc team, as I think that is where the future lies. 2. Kernel development can be done together. (2.4.23 , and later 2.6.0) 3. The solution I think Charles also suggested. using uclibc for the core. For special applications that won't compile use another library. but that isn't a floppy item anymore. 4 I still am interested in creating the Bering-light. or lite ? sounds good shortly before christmas ;) Things I am uncertain about. 1.can the group still using the old library be left alone with the older package. 2. Is it an option to bring the new packages with a script to help with replaceing for uclibc. 3 how many people use the old bering, and are willing to update anyhow. and some other questions I haven't formulated enough. And of course I agree to the friendly words from martin and the rest of the uclibc team about working together In short, I would like to see Bering to live on for quite a while, with enough developers helping Eric, so he doesn't burn out. I would also like to see more work being done _together_ (between the Bering and Bering uClibc crews), to make life easier for both Bering and Bering uClibc developers. If we can make use of eachother's work (like has been done for the kernel in the past), I think all sides will benefit. Regards Eric Wolzak --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering Crew looks for expansion
Hi Eric, The conclusions I came up to so far are. 1. getting the route towards the bering-uclibc team, as I think that is where the future lies. 2. Kernel development can be done together. (2.4.23 , and later 2.6.0) 3. The solution I think Charles also suggested. using uclibc for the core. For special applications that won't compile use another library. but that isn't a floppy item anymore. I fully agree on all those points you made. 4 I still am interested in creating the Bering-light. or lite ? sounds good shortly before christmas Well, this surely could be a way to go - if you define light/lite. I think it's a fine line between making things as easy as possible for the average user and trying to apply to Linksys' or Netgear's customers. 2. Is it an option to bring the new packages with a script to help with replaceing for uclibc. I'm afraid I don't quite understand. 3 how many people use the old bering, and are willing to update anyhow. Of course, that's the main question - I _hope_ that there will be quite a few people willing to help out. I _know_ there are a lot of people working with Bering/Bering uClibc, but of course, working on something for oneself is different from being part in a project (I know that from my own experience - I've been working on/with LRP/LEAF for a _long_ time, but it took quite a while until I got involved officially). Martin --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering Crew looks for expansion
On Wed, 17 Dec 2003, Eric Wolzak wrote: Date: Wed, 17 Dec 2003 23:31:40 +0100 From: Eric Wolzak [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: [leaf-devel] Bering Crew looks for expansion Hello everybody, As you might know , Jacques has stopped, and gave the rudder to me. My plans with Bering are. 1. update kernel to 2.4.23. 2. update packages 3 revise the documentation and make some improvements. 4 create a basic webinterface. 5 cleanup linuxrc. 6 create a bering light for the soho environment with few options. 7 Translate the Bering Documentation This all under the following conditions A I want to keep rather close to the bering-uclibc group. B A floppy distro should still be possible. But I know I will need help with those plans :) Are there any volunteers for come aboard . Kind regards Eric Wolzak member of the Bering Crew. (sailing singlehanded at the moment :( ) Eric; I am a user of both Bering and Bering-Uclibc. Boot from a 1680k floppy, like option of cd booting. Use an external 56k modem for my connection to the internet. Need/want to use active-filter and demand dialing options of pppd. Testing can be done with active-filter, like wise can have ppp0 always up my ip is dynamic. I can test things in this environment. I will be wanting to use openvpn work on friends's machine in other city from here. After January 1, 2004 will be willing to help towards making Bering/Bering-Uclibc better. What would you like to do/try? Some days are better than others, I still am having leg/knee problems. I do read my emails usually several times a day. Larry Platzek [EMAIL PROTECTED] --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
