On Mon, 2008-10-06 at 17:42 +1300, Martin Langhoff wrote: > 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.
I completely realize that and I hope you and Greg use my e-mails as ammunition to get more resources :) I am also trying to communicate that for us and probably many other pilots DG is a higher priority than moodle at this moment. > 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. I think the XO as XS plan has been dead a long time. I think the XS has to be headless otherwise it will be appropriated for other purposes. An XO can't be used as an XS. The teachers or principal will almost assuredly see it as a spare XO and give it to a child that doesn't have one, perhaps their own. > > 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. Since we are working on DG, we want to make sure our work makes its way upstream. > > 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*. I think this is relatively trivial for our team in Nepal but non-trivial for most MoE's Regarding the testing methods, I believe that Tony is hoping to hear that his work creating testing scripts won't be totally orphaned. I want to assure you that I am not criticizing you personally, Martin. I have immense respect for you. I am arguing that XS development needs more resources and in particular areas. -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org _______________________________________________ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
