Chad R. Larson wrote:
> At 06:14 PM 4/2/2004, Adam Nellemann wrote:
>>In any case, any kind of traffic grapher (IMHO the current SVG
>>implementation as well) should be made a plugin, seing as many people
>>won't need or use this feature (actually I think the same could possibly
>>be said about the VPN and/or DynDNS features). Making it a plugin would
>>also allow a traffic grapher to have such "bloated" requirements as you
>>mention, since RAM challenged users could then either choose a "leaner"
>>grapher plugin, or omit this feature altogether (opting instead for a SNMP
> The point you missed is that all this stuff lives in the CF image. When
> m0n0wall boots, it creates a RAM drive and populates it by decompressing a
> root filesystem stored on the CF. So, making these features plugins
> doesn't stop the "bloat".
Huh? So you are saying that a plugin that isn't included in the image,
will still bloat? Or am I misunderstanding what you are trying to
point out here?
> Further, you are either going to have to set up some development
> environment to generate the CF image anyway. Or else, you've migrated from
> the original idea of running on an embedded system like the Soekris or WRAP
> boards to something with a hard drive or NFS client.
Well, actually I DO run my m0n0wall on a non-embeded PC (pending the
purchase of a better platform for it), but I ALSO happen to use a
CF<->IDE converter, allowing me to run the generic-PC image from a CF
card (mainly for noise-elimination, but also to avoid those
moving-part failures.) IMHO that is as close to an embeded system as
to make the difference moot (and at least I don't have any problem
with to little RAM or CPU power!)
This being said, I'm afraid I don't really get what you are trying to
say here either? What does this have to do with the discussion about
taffic graphs and plugins?