[ previous ] [ next ] [ threads ]
 From:  Manuel Kasper <mk at neon1 dot net>
 To:  Chris Buechler <cbuechler at gmail dot com>
 Cc:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] Re: [m0n0wall] Survey results
 Date:  Mon, 31 Oct 2005 20:27:30 +0100
On 28.10.05 10:07 -0400, Chris Buechler wrote:

> My only remaining question is - Manuel, what do you think?  The
> founder of the project is the only one that hasn't come out and
> stated a long, drawn out opinion, but rather mostly only with
> things to stimulate conversation.  That was certainly the best
> approach until everybody else got out their opinion, now I think we
> should hear what Manuel is thinking at this point.  :)

I don't even know where to start...

There are two important decisions to be made that will dictate the
possibilities of m0n0wall in the future. The first one is the
programming language/architecture question. I think it's undisputed
that m0n0wall will need a real core daemon to control all aspects of
the system and also to separate the webGUI and make it just one of
possibly several means of managing the system.

The survey indicates that most people don't care much about which
programming language the core is written in, but on the other hand,
we'd apparently get more contributed code with PHP than with anything
else. This is not surprising to me, as PHP is easy to learn and lots
of people know at least a little PHP because they've used it before
for dynamic web pages. It doesn't mean that we'd get quality code
though. I'm still not convinced that PHP can be used for the core of
m0n0wall as it has been proposed. This is mostly due to the lack of
thread support and general not-designed-for-this-purpose-ness. Once
we need to start fork()ing, the advantages of PHP as a relatively
memory-friendly interpreted language fade away.

Calling PHP scripts through a web server on demand isn't a solution
either, since a) the huge overhead of spawning a PHP CGI process
every time would just make things even slower (unless someone can
find a small web server that will run PHP natively - no, thttpd is
not an option), and b) we need something that can keep certain
things, such as the parsed configuration, in memory at all times.

Now, before anyone starts a huge outcry: I'm not saying that PHP
shouldn't be used for the webGUI anymore. I think it's a very good
solution for that purpose (and 83% of the users seem to agree), but
just not for everything. If we'd use an open standard like XML-RPC to
communicate with the core (SOAP seems to be a bit too bloated),
that'd be a very nice solution.

I realize that it's not exactly popular among you, but personally,
I'd still like to use Java for the core. It's just the simplest
C-like language, and also much safer than C/C++. Its greatest
disadvantage is its bloat. Execution speed probably wouldn't even be
a problem in our application, as Java is likely still much faster
than PHP, but memory usage is an issue. I've run some tests with GCJ
and also JamVM, but so far, I haven't been able to implement a simple
XML-RPC server that consumes less than 10 MBs of RAM (because of all
the library classes that need to be loaded).

Moving away from the MFS approach, as is likely going to happen at
some point in the future, will free up some RAM, but since we want
m0n0wall to run happily with 64 MB, we can't just waste that.

I haven't actually run any tests with Perl or Python - maybe someone
could implement a simple XML-RPC server and determine its RSS after a
request just so we can get a rough idea of their memory requirements?
I don't know about Python, but I assume that Perl can easily eat away
several MBs as well.

The most efficient solution, and also the most popular one after PHP
(according to the survey) would be C. It's also the likely choice if
we can't find any higher-level alternative that suits our needs.

The second question is which operating system to use. FreeBSD 6.0 is
the most popular choice, and I don't think it'd be a bad one
(although I haven't done much with it yet). OpenBSD's performance is
still much lower than FreeBSD 4.x, but it's easier to understand
(less code) and the things that were developed for it (pf etc.) tend
to work very well. pf is really much better than ipfilter, but OTOH,
we may not be able to satisfy all m0n0wall traffic shaper users with
ALTQ. (FYI, I'm now running a net4501 with OpenBSD 3.7 as a bridge
with ALTQ between m0n0.ch and the cable router to prioritize the
upstream traffic). Linux would be tempting because of the hardware
support and just maybe a smaller kernel and userland (don't know how
much of that is still true with 2.6 though).

So, in spite of the results of the survey and the discussion on this
mailing list, I'm less sure than ever about the answers to those two
burning questions. We'll have to do some prototyping to figure out
more pros/cons and determine whether some of the proposed products
are suitable at all. If anybody wants to help with that (i.e.
evaluating programming languages/toolkits or operating systems for
their suitability), let me know.