[ previous ] [ next ] [ threads ]
 
 From:  Dinesh Nair <dinesh at alphaque dot com>
 To:  Manuel Kasper <mk at neon1 dot net>
 Cc:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] The future - summary
 Date:  Fri, 14 Oct 2005 14:46:13 +0800
On 10/14/05 04:24 Manuel Kasper said the following:
> There have been a lot of interesting comments and mixed opinions,
> which is what I was hoping for. Thanks for participating in this
> discussion so far! Now - I've read all of the 70 posts to the "The

i'd have loved to participate there, but time pressures only allowed 
lurking. oh well.

> I have proposed to turn the part of m0n0wall that handles the actual
> configuration of the system (which is now the boot scripts that are
> called by the webGUI whenever necessary) into a daemon that manages
> all aspects of the system's configuration, with the webGUI being only
> a client to that daemon. Because unfortunately PHP does not lend

i too think this is an excellent progression for m0n0wall, as it allows us 
to abstract the UI away from the actual configuration tasks. this would 
also make the UI more responsive, as today updating a very large config.xml 
can take a couple of seconds on some CF cards.

however, i dont think PHP would be a good choice for this daemon, purely 
for the reasons already brought up, i.e. that it doesnt thread well.

another alternative would be to place an XMLRPC or SOAP interface to a http 
daemon, and allow that httpd daemon to handle threading et al. the UI would 
be a separate layer which would communicate to the m0n0wall via this 
XMLRPC/SOAP interface.

this allows us the flexibility in creating UIs in any programming language 
as well as platforms to configure a m0n0wall. a standalone windows client, 
anyone ?

> proposed to use another language for the task. It was never proposed
> to use anything else but PHP for the webGUI.

introducing another language would mean having to port and slim down the 
framework for that language. perl, python and ruby all have large 
frameworks needed to support the language and with MFS being used, this 
will only serve to increase the memory requirements for m0n0wall.

> So it looks like my idea of a central "core" daemon isn't going to
> work, and I ask you: how else could we improve the current state of

i think it'd work, with some changes to the architecture. core http daemon 
tasks   (threading, process management et al) could be in C, with PHP 
scripts on the m0n0wall providing the XMLRPC/SOAP interface as well as 
modifying config.xml.

> About the operating system - seems like opinions diverge largely on
> this topic. Some think OpenBSD is the way to go, others claim that
> FreeBSD 6 would be a better choice (hardware/wireless support,
> performance), there are some DragonFly advocates, some think highly

i'm perhaps biased in this in that i wouldnt like to see m0n0wall move away 
from freebsd. admittedly the jump from 4.x to 5.x has caused problems and 
5.x is not the best release of freebsd around. however, these are being 
fixed for 6.x. many people (me included) are in fact skipping 5.x for an 
eventual bump of 4.x to 6.x directly when it becomes a litte more 
production ready.

as can be clearly seen in the freebsd roadmap, 5.x has a short shelf life.

while the other BSDs have strengths of their own, nothing (to me anyways) 
beats what freebsd offers. its more of an allrounder in the x86 space, with 
  still a superior network performance benchmark. since m0n0wall is a 
network element providing firewall, qos, vpn and nat services, this needs 
to be taken into account.

> At the moment, we assume at least 64 MB of RAM, and I don't think we
> should increase that minimum amount due to the large number of

i doubt we should be increasing this, and 64MB seems like a good target to 
stay with.

> continue using the MFS approach, we're still limited by available
> RAM. We might also consider ditching MFS when we switch to another

speed of execution is important, and the MFS approach at the least takes 
out disk i/o from the equation. additionally, the number of SATA/IDE based 
drivers out there may also bloat up the freebsd kernel used on m0n0wall. 
space is a factor here.

-- 
Regards,                           /\_/\   "All dogs go to heaven."
dinesh at alphaque dot com                (0 0)    http://www.alphaque.com/
+==========================----oOO--(_)--OOo----==========================+
| for a in past present future; do                                        |
|   for b in clients employers associates relatives neighbours pets; do   |
|   echo "The opinions here in no way reflect the opinions of my $a $b."  |
| done; done                                                              |
+=========================================================================+