Am Mittwoch, 19. Oktober 2011, 17:08:55 schrieb Andrew: > 19.10.2011 17:38, Erich Titl пишет: > > Hi Folks > > > > at 19.10.2011 14:46, Andrew wrote: > >> Hi. > >> > >> 18.10.2011 21:41, KP Kirchdoerfer пишет: > >>> On the other hand, I'm currently thinking about the idea to build a > >>> "later" branch to testdrive uClibc 0.9.32. I haven't tested the > >>> already built packages and images in production, but a first try > >>> looks promising (see Trac ticket #36). > >> > >> Yes, I also thinking on new '5.0' branch, with fresher kernel, uClibc > >> (it seems like 0.9.32 has nptl - so stack protection in gcc can be > >> enabled), reworked toolchain (with separated 'host' and 'target' > >> binaries and more common way toolchain assembly w/o magic tricks and > >> dirty hacks) to make possible cross-compilation for/on other > >> platforms and so on. I think I'll have time to start new branch in > >> some weeks when I made some changes to buildtool and check them. > > > > Wouldn't you think we should straighten out 4.x before thinking about > > 5.x, and I mean no known bugs whatsoever. > > > > I have no idea how far the acceptance of 4.x went. For myself I have > > not dared yet to upgrade our production firewalls to 4. One of the > > reasons is that we are running them in a 7x24 environment. Another > > reason is the missing seamless upgrade path. > > > > What do you reckon native threads will buy us, typically there are few > > processes running on a firewall. What kernel issues have we identifid > > which force us to upgrade and if we have them why not go for a 4.x. > > > > In my numbering environment a 5 would mean something completely > > different, like kernel 3 or support for multiple processor > > architecture or a completely revamped build environment. > > > > my 0.000002 gold grams (can't trust the bloody money anymore) > > > > Erich > > I mean '5.0' because it'll have newer kernel (3.0/3.1/newer - really 3.x > kernel versioning doesn't mean great difference from 2.6.x > branch)/toolchain (versions and directory structure)/etc; toolchain > reorganization should give possibility to build packages for different > architectures. > > About uClibc - NPTL is required for enabling GCC stack protection; also > uClibc 0.9.30.3 conflicts with some packages (asterisk, yate). Upgrading > kernel is also enough important - on 2.6.38 and newer versions global > lock aka 'big kernel lock' is removed and this should improve > performance on SMP systems. > > And, in any case, opening new branch doesn't mean stopping of work on > 4.x branch; 5.x looks like it requires a lot of modifications and IMHO > it'll require months of work till beta release (one of 'heavy' steps - > full review of makefiles to remove building hacks) - in that time 4.x > can be developed - all fixes from userland (version upgrading and so on) > can be easily imported in 5.x branch.
Hi; I fully agree with Andrews points of view - but some more thoughts about the questions/issues Erich raised. I don't know how widely 4.x has been accepted, I even don't know how small our user base has become. According to SF statistics we have an average of 12 download per day since 4.1 has been released. This small, and even smaller if you count in 10 downloads of the README (and to my surprise the same number for the source tarball). But it's even harder to figure out how much of a single downloads is used to deploy one or more machines. And how much of the users who installed 4.0/1 don't see a need to update? How much want to do, but don't have the time yet are satisfied with the 3.x versions? Also the leaf-user list is quiet - are there no users any longer, or are they just satisfied with the work and use LEAF silently? The 190 downloads in two weeks may also be a good number, given that LEAF has zero press in the last years - though I do believe it's as good as any other small distro given the task it's developed for. Maybe it's lack of press is related to the lack of a fancy web-interface, but then that's something *I* do not care about. I use LEAF for years as a rock-solid and as safe as possible software for my routers - and it just works. Updating a router has never been as seamless, as one wants to have it. But with version 3, the reworked apkg and moving configuration to configdb, it was for the time easy to update a router within minor versions. With version 4 a lot of the basics has been changed (/dev/hda is now /dev/sdat - which affects leaf.cfg and syslinux,cfg), the new kernel requires new modules... But version 4 also added "hardware autodetection", which will make upgrading easier in the future (hopefully) and together with configdb.lrp the pain has now been reduced a lot since the early LEAF days. Don't know yet how much work it will be if we go with a version 5, another reason to start working on it in 2012 :) I recently replaced a router with 24/7 service. I used a spare machine, installed LEAF Bering-uClibc 4, and due to autodetection I was able to put it up in a few hours (reducing the number of modules provided with initrd by default included) - didn't copy the old configdb.lrp but used the upgrade to cleanup the configs from old cruft instead. The spare part than replaced the production router (which ran an ancient LEAF Bering-uClibc 3.x version) with a downtime of less than two minutes. Regarding getting version 4 stable and fixing bugs, I'm aware of only one that is not part of TRAC: ulogd doesn't work. I've put some time into this issue and prepared additional packages, but there was no way to get either ulogd 1.x nor 2.x working. The tickets in Trac reported by users has been solved, the currently open ones are either boring, though important work - like documentation, adding licenses...or might be resolved with a new build enviroment (support of new architectures) or will be a major change with reworking a lot of packages (building busybox apps as executables), which can/should be happen during rework. just my Franken (which is limited to 1,20 Euro by Swiss Bank AFAIK) kp ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
