Hi Paul, thanks for your feedback
> With that > experience, > my question would be, what significant benefits does the 2.6 kernel > provide to a minimalist system? For me, the main reason was new drivers. It appears that more and more things are only added to the 2.6 kernel, and not to the 2.4 line. Sooner or later, it will be difficult to get network adapters to work that haven't been around for ages. > I'm still interested in a firewall I can run from a write-protected > floppy, always have been. It seems the 2.6 kernel is larger, which is a > disadvantage. In that case, the branch with 2.6 kernel will not be for you - I don't see a way to get a working image with 2.6 kernel onto a floppy (and even with a two floppy setup it still seems very tight, since one needs a kernel plus initrd on the first floppy). But sooner or later, floppy support will have to go anyway - since there won't be any new systems that are shipped with a floppy. For embedded systems, floppies have been dead for quite a while, and it seems that these days, even standard desktops no longer come with a floppy. Don't get me wrong - I didn't like having to admit that we had to drop floppy support (and if we find a way to continue floppies, we will - simply because it will give us the extra incentive to keep things small and avoid any kind of bloat). I haven't used real floppies with leaf boxes in ages (I _have_ used it in VMs, but simply because the floppy images where available and easy to boot from), and I haven't looked back. I don't miss the unreliability of floppies (especially superformatted floppies) one bit. Losing the ability to write protect the boot media is a bummer, but if that's absolutely needed, one can create a CD to boot from, and use that instead of floppies (granted, not as simple and convenient as moving the write-protect thingie in a floppy, but still, a usable alternative). But I'm not trying to convert you to moving away from floppies - if they work for you and you don't have any issues with that setup, by all means, stick with it, until your requirements change. > I wouldn't argue that, for > instance, the new locking & dispatching aren't improvements, but do they > remedy real problems for a LEAF implementation? Surely not, as far as I'm concerned. > It seems one branch of hardware development is making small, motorless > systems that would make nice LEAF applicances, so we might need support > for them in new kernels. An example for that would be the ALIX box from PC-Engines. There doesn't appear to be a watchdog driver in either kernel version yet, but at least I've found a patch for kernel 2.6 It seems that "Low power computing" is getting popular with chip manufacturers these days, so I guess we'll see more and more single chip systems, that have a lot of the needed stuff on chip (like the AMD Geode LX800 with its random number generator, crypto support, watchdog). I doubt that support for these new systems will be added to the 2.4 kernel. Another thing I'm interested in with kernel 2.6 (once it matures) is the Open Source Atheros wifi driver. Again, I doubt that will make it into kernel 2.4. > The 2.4 kernel brought us stateful packet inspection, and that was a > very > GOOD thing. I'm just unaware of a NEED for the 2.6 kernel at present. I don't think there is a "NEED" for 2.6 kernel in leaf right now. But there will be at some point (the point when modern hardware will hardly be supported anymore - just like with 2.2 Kernel today. I doubt you would be able to get any of the current Gigabit cards to work with a 2.2 kernel - but I must admit, I haven't tried it). So before things get too bad on the driver front, it seems smart to start working on something that will give us a perspective for the next 5+ years (just like Bering did with switching to kernel 2.4, when many people said that 2.2 could do all they needed, IPTables was too complicated and IPChains did just fine and so on). I guess in short, there is no dying need to switch to kernel 2.6 right now. There might be a few years from today. And if we only start working on that when there's a dying need, I'm afraid the project will be dead before we're finished (since either users will have moved away due to the lack of support for their hardware, or they'll have moved away since the quickly hacked together 2.6 version is not as stable as Bering/Bering uClibc). So, even though we don't desperately need 2.6 kernel right now, it would be a bad choice to (IMHO) to just sit there and be happy that all we need to do today can be done with kernel 2.4 Martin ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
