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
this allows us the flexibility in creating UIs in any programming language
as well as platforms to configure a m0n0wall. a standalone windows client,
> 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
> 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
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
> 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/
| 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 |