I'm replying this message cause I fully desagree with the statement
that m0n0 whould not evolve with new and very usefull things just cause
people use it inside soekris or wrap boards.
I personally use it in most cases within wrap boards, but I have some
cases where I run mono inside Dual Xeon 2.8 - 4 Gb RAM. Why we can not
have this stuff in m0n0, but disabled? if you choose to run m0n0 inside
a SBC board, no problem, just keep this features disabled, but if you
have machine power why not?
the problem may be the U$3,00 plus to go from a 32MB CF to a 64MB? I
don't think so. Or may have more RAM, but this is a real problem?
I developed lots of stuff to m0n0 in the last 3 months, but I gave up
to post here, cause the answer is allways the same: "Bullshit, m0n0
isn't developed for this purpose". Among this things I have squid
integration in 1.2b1, snort integration in 1.2b1, database support for
logging purposes, an even the internationalization. All of them ( don't
really think this ) too heavy for SBC boards, but not to the PC case.
Dinesh Nair wrote:
> On 29/09/2004 07:40 Mitch (WebCob) said the following:
>>> In that situation, the user database Dinesh discussed is exactly
>>> what they need.
>> I prefer that idea... just think it has to be on par with comparable
>> services (user capacity wise) or else we lose users... As an individual,
> my concern with the capacity of the user db is that m0n0wall is usually
> run on soekris boxes and those do not have the capacity which a full
> fledged PC/server would. in addition, each of the username/password
> pairs would need to be stored in config.xml which then has to be synced
> with the CF card on _every_ change. this would mean that the webGUI
> performance will start to suffer as the number of users in the builtin
> db increases. i had initially suggested a max of 16 to address this
> however, what i'll do now is to make this max number of users a
> configurable parameter but m0n0wall users need to be warned that a large
> number of users in the builtin db will affect webGUI performance
> adversely. somehow, as a developer, i feel i have a responsibility to
> not give users the tools they can shoot themselves in the foot with.