> [?] into a daemon that manages all aspects of the system's
> configuration, with the webGUI being only a client to that daemon.
Writing a daemon would also include developing or choosing an
appropriate protocol, which adds at least one more layer. To be honest,
I think it's unnecessary bloat for a router/firewall.
> This has generated an outcry - many developers and even users don't
> want to see m0n0wall using anything else but PHP.
Even if I don't really like PHP myself, I'd say it's better to stay on
it, as it's also one feature that makes m0n0wall unique.
One possibilty would also be to write the deamon in plain C and then
spin of PHP processes for each request, but this would slow down the
> Or could you think of a way to get that "core" in PHP?
Especially with PHP 5's OO-features, it should be possible to abstract
things and then write specific classes.
> About the operating system - seems like opinions diverge largely on
> this topic.
The only Unix I really know good is Linux, so I can't really help here.
I've been using FreeBSD only to develop for m0n0wall, and even then, I
editted the files on Linux and built the m0n0wall images over NFS.
If we are going to some OO architecture, it should even be possible to
write the GUI independent of the underlaying operating system. This
mostly depends on a good architecture of the code.
> 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
> embedded systems that don't come with more and can't be upgraded.
I think that 64 MB are way enough for a router/firewall like m0n0wall in
normal environments. fli4l, a Linux based router I've been using for
more than three years, still runs with 16 MB of RAM. However, fli4l
doesn't have a web interface.
Gentoo Linux Developer using m0n0wall | http://hansmi.ch/
Excusing bad programming is a shooting offence, no matter _what_ the
-- Linus Torvalds, to the linux-kernel list