[ previous ] [ next ] [ threads ]
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] The MDP Initiative
 Date:  Sat, 29 May 2004 15:44:50 -0700 (PDT)
On Sat, 29 May 2004, Adam Nellemann wrote:
> Fred Wright wrote:
> > On Fri, 28 May 2004, Seth Rothenberg wrote:
> > 
> >>The concern I have with that is, that assumes that
> >>we succeeded in setting up WAN and that WAN is working.
> >>If WAN went down and we were trying to configure
> >>the backup, help out on the WAN wouldn't help.
> > 
> > Yes, not to mention the unpredictable delays in accessing documentation
> > from outside sources.
> Huh, "unpredictable delays"? Are you talking about the usual internet 
> latency here or what? I have several apps which will show some 
> internet page when I access its help pages (such as Thunderbird), and 
> of course there will be a short delay, but I can't see that this would 
> be a problem? (At least not how it would be a larger problem than it 
> is now, where ALL the m0n0wall documentation has to be fetched from 
> the internet.)

Have you considered how poorly this scales with large numbers of m0n0walls
deployed?  If you think this is a purely "academic" concern, check this


Not to mention how Murphy will insure that, just when you really need to
access the documentation, the Internet will be under attack from the
latest Windows worm. :-)

Mac OS X was originally set up to have most of the help accessed over the
net.  Apple got so much flak about this from users that later versions
keep more of it on disk.  No reason to repeat the mistake.

> > It's unlikely that any platform used to host m0n0wall is too tight for
> > space to allow built-in documentation, as long as it's not part of the RAM
> > disk.  Even spinning up a CD to read a help page isn't that bad, and
> > reading it from CF is no problem at all.
> Of course, if there is no objections, it would be preferable to have 
> such m0n0wall "context help" on the CF. I'd personally prefer that it 
> be loaded into RAM though, like the rest of m0n0walls GUI, but I can 
> understand how that would be a problem on low-RAM embedded 
> implementations (and perhaps it is too much ado for a simple help 
> system to check for RAM availablity and only upload if there's enough 
> of it?)

Unless you have fairly large amounts of RAM *and* are reasonably certain
the "real" code won't need a lot, then documentation wouldn't be a very
wise use of it.  If the filesystem buffer cache is sized dynamically, it
would tend to handle this automatically, anyway.

RAM utilization is *already* a major concern on embedded platforms like
the Soekris, even without documentation added.  Note that every unused
program in the image still occupies RAM, and every program that *is* used
occupies RAM twice, once for the "file" and once for the "image".

					Fred Wright