Hello Erich, >Also with >adding a big glibc you will hit other problems like initrd space and >system RAM (LEAF is enterily run in RAM) so a big flashdisk is not >the only requirement. > >Agreed, I may be biased in that I hardly ever see a system with less >than 64 Mb
Yes, that's true. But the nice thing about being small is that you can use it on older systems and embedded devices. You also have more room for packages etc and a lot more reasons ;-) >And maybe not all the current Bering packages >are compatible with a newer glibc without recompiling? > > >Absolutely, but using a current glibc might allow us I don't see any benefit in using very big libraries, the distro will grow enormesly. Why using things like busybox for it smallness and wasting a lot of space with libraries? In this case I would say, why not use a full distro? >I personal don't see anything against uClibc, but probably I'm biased >:-) > > >You should be :-) . It is probably a probability issue (due to the >increasing number of uClubc users) that I see more uClibc problems >showing up on the list than the ones with glibc. This is the main >reason >for me to stay on the glibc base. In the years that we use uClibc now, we didn't have any problem with it. There have been some very small issues (all solved by small patches and in the uClibc mainline now), and there are probably a (very) few programs that can be compiled yet. But we didn't have any stability problems. Some users have uptimes of more than a year without any problem. I can't remember ever seeing uClibc problems (on releases) in the uClibc list. In functionality and stability uClibc is equal to glibc, only a lot smaller. >I personally like the buildtool environment, the only drawback for >me >is, that it appears to abandon the standard GNU config/installation >procedures which requires a port of each and every package. I wonder >if, >for a glibc environment, we could use precompiled binaries from a >current distro. Not true, buildtool is using the standard GNU configure and make structure, it's nothing more than a sort of Debian "rules" system where the correct configure and make parameters are called and to create the right structure to create lrp packages. (ok it is a lot more, but all standard) It's the same as doing configure --blah --blahblah --foo and make, "install" it and strip binaries and libraries. Nothing fancy, just a meta system above the standard GNU way to do it in repeatable and standard way. You only doesn't have to do it by hand anymore. No porting necessary. Ofcourse you can use precompiled binaries in some cases, but a lot of binaries needs specific configure and make options to function right in the target environment. So most cases needs a recompile anyway to do it right. >About webconf. Why not help Nathan to improve his webconf system? > > >In some aspect I did, I ported it to glibc :-). :-)) >Nathan did a great job to create an extendable framework for a >webconfiguration system in line with the modular nature of LEAF >packages. This means that you can extend webconf anyway you like. >With the base webconf system you can edit the packages like with >lrcfg but by using package specific "lwp" packages you can make a >nice interface to a package configuration and still have the choice >to do it the "old fashioned way" by using the CLI (lrcfg). >So the only thing webconf "lacks" now is some lwp packages to provide >a "nice" interface to the lrp packages (there are already some >created by Nathan) > > >You are right and Andrea already offered to do so. >For a few years I hear talking about a nice GUI or a new config >system on this list, Nathan actually builded a nice extendible and >advanced system which I believe can be better than f.e. m0n0wall and >solves the "config issue". So why not put our effort in helping >Nathan? What's wrong with his system? > > >Nothing at all. It just takes as much time as any other Web based >GUI >(and the increasing number of incompatible browsers dos not help >much). >Not being fluent in haserls dialect makes this more difficult too. >But >these are excuses.... LOL, but any config system we can think of means work. So no excuses :-))) >We'll see if I can muster the effort of writing a few .lwps >cheers >Erich Cheers, Eric ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ leaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/leaf-devel
