Re: [Server-devel] Server-devel Digest, Vol 18, Issue 6
On Mon, Oct 6, 2008 at 6:52 PM, Bryan Berry <[EMAIL PROTECTED]> wrote: > I completely realize that and I hope you and Greg use my e-mails as > ammunition to get more resources :) thanks! :-) > I am also trying to communicate that for us and probably many other > pilots DG is a higher priority than moodle at this moment. Moodle is not just "nice lms" but "UI for various things". So for example, if DG is to be tweakable in any user-friendly way, we need to login via Moodle first. So let me get "moodle as infrastructure component" out of the way. And for schools that don't have internet connectivity, moodle is a central place for resources. That's an important focus as well. > I think the XO as XS plan has been dead a long time. Not dead, and has a lot more going in it -- and I hope you'll be surprised. Might require a tad of user (teacher/principal) education. If you want, we can make "remove the screen" part of the install instructions :-) > Since we are working on DG, we want to make sure our work makes its way > upstream. What work on DG can we incorporate on the XS? Do you see a way for DG to be dynamic / smart enough to work reasonably 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 This "upstream proxy" is something I'll probably provide as an XS "companion" or as an "alternative configuration" for the XS image. It's easier to build that than it is to solve problems that are actually impossible :-) > Regarding the testing methods, I believe that Tony is hoping to hear > that his work creating testing scripts won't be totally orphaned. Oh, is he working on some? Fantastic! Tony, can you post your notes / plans / intentions! :-) > 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. Thanks! - we agree on the need for more resources. 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
Re: [Server-devel] Server-devel Digest, Vol 18, Issue 6
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
Re: [Server-devel] Server-devel Digest, Vol 18, Issue 6
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
Re: [Server-devel] Server-devel Digest, Vol 18, Issue 6
Martin Langhoff wrote: > Been ruminating on this a bit. The more I think about it, the more > clear it is that DG on the XS is not a good long term solution. 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. > 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. 1) It sounds a way off and we need a working solution asap. 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. -- 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
