Hi John,
this is a little depressing. After spending years (and tons of emails)
discussing the need for a kernel 2.6 version of LEAF, there has been
no response on this list on the topic.
Sorry, Martin, I only read the list as a newsgroup, every week or so.
No problem. I just started to doubt the value of the time spent (and not
mainly by me - Dirk and Eric put in as much, if not more, time as I
have). It's not about ego (hence my line about not looking for a good
job, well done response), it's simply about finding out if one is
wasting one's time. I don't gain anything if people use the new branch
(or Bering uClibc, or any other LEAF branch), so if I'm working on
something that nobody is really interested in, I guess I'd better stop
wasting my time and do something more productive. If there is interest,
and people will use it (and some will contribute), it's much easier to
justify the time spent. To me, that's really all it comes down to.
It's important to me because LEAF still seems by far the simplest
small, easily customizable distribution for running Shorewall; and the
latest Shorewall-4 with the excellent shorewall-perl compiler handles
IPsec only in the new kernel 2.6 style with nf-policy-match support.
Well, there's an new issue, I guess. Somebody will have to build a
perl.lrp package that provides everything shorewall-perl needs. I guess
size isn't much of an issue (I doubt that anybody who knows what they're
talking about is going to expect a 2.6 kernel, a useful set of tools
plus perl to fit onto one floppy). But since I have no experience
whatsoever with that part of shorewall (I got by just fine with the part
of shorewall provided with Bering uClibc), I'm afraid somebody else will
have to provide that set of tools. I can help with the buildtool stuff,
so I'm sure it can be done as a collaborative effort - but I doubt I'll
find the time or energy to provide that all by myself (that's mainly
what the paragraph about focusing on the core features, on things that
those who build the packages need themselves and can actually test
themselves, was all about in my first email in this thread).
Without really understanding the leadership structure of the project
I don't think there's much of a leadership structure. Everybody is
free to contribute, or to create a branch of their own if they want to
do something different from what everybody else is doing. At least,
that's the way I understood the evolutionary development model that Mike
proposed - and I like the idea. It just didn't seem to really work too
well in the past (since it seemed it always came down to a small group
of people doing the development). But this _could_ change now, with a
new branch that uses the (IHMO) solid base of Bering uClibc, uses the
same build toolchain (so people who know how to build packages for
Bering uClibc, can build packages for the new branch without having to
re-learn anything). That was mainly the reason for my frustration - we
provided a working image, the devel toolchain is the same as for the
current stable release, so not getting any feeback was a bit
disappointing. Maybe I sent the email too soon - but maybe the email
served as a wakeup call as well, getting more people out of the let's
see how that progresses mode (one that I often fall into myself...).
I
had assumed from a mailing list archive reading it was futile to work
on a kernel 2.6 branch; you seem to have proved otherwise, so perhaps I
will find the time to collaborate.
Well, maybe that wasn't made very clear (or, more likely, it never
really was clear to any of the participants of the discussion at the
time - it's hard to say anything for sure before one has tried it. And
then, the 2.6 kernel has changed over the last 2+ years, since the
discussion first came up). To me, it always seemed impossible to
continue to support floppies with kernel 2.6. That still holds true - at
this point, it doesn't look like it's doable. I would still like to find
a way to boot from floppy, but at this point, it doesn't look like it
will happen.
But using a 2.6 kernel booting from something with more storage is
surely possible (obviously, by now), it just meant a considerable amount
of work, and at the time the discussion first came up, it just didn't
seem reasonable to spend that time, given the marginal benefit a 2.6
kernel would have meant.
For me, the reason to start working on that was first of all, because I
wanted to see if it could be done (to get past the gee, wouldn't it be
nice if... stage), and maybe more importantly, because I have a few PC
Engines ALIX boxes lying around here that I feel would benefit from a
2.6 kernel (if and how much they'll benefit from it remains to be seen -
I've not had time to actually work on that part yet).
I would be very happy to see LEAF to get a broader developer base, with
people working on all kinds of things, rather than just waiting for the
the core developers to provide something (I never liked
