On Mon, Oct 6, 2008 at 4:42 PM, Bryan Berry <[EMAIL PROTECTED]> 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 -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel