[ previous ] [ next ] [ threads ]
 From:  "Dan Bond" <dan dot bond at gmail dot com>
 To:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Re: [m0n0wall-dev] SUGGESTION: M0n0wall flashsize and Recommendedmemory
 Date:  Fri, 15 Sep 2006 21:33:03 +0100
Which is, if i'm not mistaken, how pfSense works. I tried it once but
there are things that m0n0wall just does better due to everything
running off a flash disk. For instance, when you want to turn off your
m0n0wall, you just pull the power because, unless you're writing a
config change at that point, there will be no disk activity. PfSense
is like any normal system, you've got to shut it down properly. Not to
mention for systems which go very long times between reboots (like
firewalls) the act of loading a large image once requires much less
disk activity than accessing each binary, config file and whatever
else every time you want to use them.

Or at least that's my thinking, could be wrong. The whole idea of
modularising fits much better into the pfSense design i'd say, where
as m0n0wall would, as you say, need a whole new image built to add or
remove features. Not saying that's a bad idea, I love the idea of a
menu driven build system where you select which modules you want and
it builds your image for you menuconfig style. Would mean tracking
down bugs might get a little more difficult though.


On 15/09/06, Chad R. Larson <clarson at eldocomp dot com> wrote:
> Jonathan De Graeve wrote:
> >> I would hate to see m0n0wall leave the embedded arena.
> >
> > We wouldn't, we still try to keep everything as small as possible.
> > Although largering the RAMsize a bit (I think it even would still fit on
> > the 8MB flash because the FS is compressed) could give me the option to
> > add sleepycat DB support (the library eats 1MB) but in turn offers us:
> > Concurrent insert/delete and even replication of CP db's to different
> > system!!!!. This in turn giving us the possibility to allow concurrent
> > CP operations.
> I have two thoughts on this.  The first I mentioned a couple of days ago, which
> was modularizing the distinct features (like Captive Portal).  Make them like
> plug-ins, or adjust the build tools so things not being used can be left out of
> the image.
> The other is actually executing off the CF binaries and using the RAM only for
> buffers, swap space and data segments.  We could then add as much functionality
> as you are willing to buy flash for (short of running enough programs
> simultaneously to run out of swap).
>          -crl
> --
> Chad R. Larson (CRL22)    chad at eldocomp dot com
>   Eldorado Computing, Inc.   602-604-3100
>      5353 North 16th Street, Suite 400
>        Phoenix, Arizona   85016-3228
> Information transmitted by thise-mail is proprietary to MphasiS and/or its Customers and is
intended for use only by the individual or entity to which it is addressed, and may contain
information that isprivileged, confidential or exempt from disclosure under applicable law. If you
are not the intended recipient or it appears that this e-mail has been forwarded to you without
proper authority, you are notified that any use or dissemination of this information in any manner
is strictly prohibited. In such cases, please notify us immediately at mailmaster at mphasis dot com and
delete this mail from your records.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch