[Server-devel] Server-devel Digest, Vol 18, Issue 6

Martin Langhoff martin.langhoff at gmail.com
Mon Oct 6 00:42:09 EDT 2008


On Mon, Oct 6, 2008 at 4:42 PM, Bryan Berry <bryan.berry at gmail.com> wrote:
> DG may not be a good long term solution, but the pilots need it asap and
> it still isn't part of the default install. Greg is right that the XS is
> already a production project but it lacks one of the key features that
> all the pilots need -- basic content filtering. The deployments that
> need it most are those w/ the least technical skills and least likely to
> complain on this mailing list.

Bryan,

I am working as fast as I can, but this is not a product yet. The
order in which I am tackling things is *very* carefully considered --
IOWs everyone screams "ASAP" :-/ but it takes quite a bit of thinking
and analysis to figure out the right order.

What you tell me about how DG works is *very* valuable. You say that
its filtering is so blunt that it needs quite a bit of fiddling. This
brings about a problem: if it is not good enough (as a filter) to
"just work" and needs a lot of tweaking wrt its filtering rules with
special knowledge of filters, rules and pattern matching... then we
have only a partial solution in DG.

Your team knows DG and can manage it, I'm not concerned about you guys
:-) but in other locations, getting DG to install + autoconfigure is
just not good enough by a very large margin, and that *is* worrying
me.

>> So it's a task better pushed to a proxy/filter "upstream" at the ISP
>> network -- for any large deployment, we should start advising the
>> local team to arrange with the ISP(s?) involved the co-location of 1
>> server. This server gives us an opportunity to perform
>>
>>  - filtering at one central place
>>    = better scale up / scale out economies (making bayesian costs more
>> reasonable)
>>    = larger "scoring" pool, so good/bad content gets flagged faster
>> and for everyone
>
> I am not a fan of a centralized solution.

Perhaps stop and give a bit more thought. When I say "better
economies" what I am saying is that to support a DG with bayesian
filtering we'll probably need to *quadruple* the XS specs for every
school. It also kills our "XO as XS" plans.

> 1) It sounds a way off and we need a working solution asap.

I agree that we need a filtering solution for pilot sites - I am just
worried that DG is not a good fit. You have a solution right now for
your situation (you're running FG already), and you know and
understand the DG filtering tweaks.

> 2) In Nepal we will work w/ a variety of regional ISP's to provide
> bandwidth to schools. I expect many, many other countries will do the
> same. I will trust the regional ISP's to provide bandwidth, but not
> content filtering as well.

 - It is trivial for the MoE to setup a co-located server at the ISP.
 - The server is under the control of MoE.
 - The performance advantages are *huge*.

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff


More information about the Server-devel mailing list