Hi Chad,

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 
>>solution).
> 
> 
> 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?


Regards,

Adam.