<div dir="ltr"><div><div><div><div><div><div><div><div>No, you can't quite blame Martin for this one.<br><br></div>I won't go into the various people who've said it, but much of the hope behind the XO-1, Sugar, and Schoolserver was that everyone would rally around them as the superior solution.  Millions of XOs would be sold, and everyone would develop Sugar applications.<br><br></div>In practice, this never happened.<br><br><br></div></div>XSCE in many ways is an improvement from the original schoolserver.  But from what I have seen it still seems somewhat oriented towards micro-deployments.  Or at least everyone loves talking about their micro-deployments.<br><br></div>The question I am raising is if micro-deployments are enough.<br><br></div>A newspaper article locally republished here contained the point that "Organizations don’t die because they provide no value; they die because they fail to provide enough value to enough people."  And although the original source appears to be religious[*], if you substitute "Judaism" with "Sugar" and "Synagogues" with "Sugar Labs" much of the article still is true.<br><br></div>How do we get enough value into future versions of XSCE and Sugar?  How do we convince deployments that they are worth using, and volunteers that they are not wasting their time?<br><br></div>As much as technical details may be fun to argue about, I think we need to determine the more fundamental answers.  This is more of an IAEP discussion though than anything.<br><br>[*] <a href="http://www.jta.org/2015/02/08/news-opinion/opinion/op-ed-are-voluntary-dues-enough-to-get-people-to-join-synagogues">http://www.jta.org/2015/02/08/news-opinion/opinion/op-ed-are-voluntary-dues-enough-to-get-people-to-join-synagogues</a><br><div><div><div><div><div><br><div><div><div><br><br></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 10, 2015 at 8:42 PM, Tony Anderson <span dir="ltr"><<a href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I can't speak to XSCE, but I have never understood the problems you cite. I think, try to be diplomatic, that there is problem of terminology. When the SLOBS talk about negotiating privatesly with a deployment, they apparently mean a national initiative (Uruguay, Peru, Rwanda, Australia, Paraguay). I think there are many of us who work with what is affectionately known  as micro-deployements or boutique deployments.<br>
<br>
In the latter context, I have never understood this problem. The Martin Langhoff model you describe fits the needs perfectly. Even if the school has a policy not to provide DHCP or whatever, the solution is to connect the schoolserver to that network as the WAN (and the WAN sees it as a device.). So far I have not run into a 'micro-deployment' where there is enough networking around to make that even a question. Naturally, it seems clear that if a deployment does not like the design of the schoolserver, they are free to adapt it to their needs or not use it. I don't see that we have any obligation to adapt to those needs (that was the idea, I thought, of Activity Central - to provide a way for deployments to obtain technical resources to adapt the community products to their needs).<br>
<br>
My own project is to provide a 1TB hard drive with all of the relevant software and content to set up a complete deployment (at one school). It is assumed that this deployment does not have regular access to the internet and needs to access that content from the school server. The deployment model is exactly as you describe.<br>
WIthin that constraint, the goal is to allow the deployment to prepare routers, XOs, and the schoolserver with support from someone familiar with computers but not necessarily with the command line. Some command line use is essential (I haven't found a way around) and the instructions assume that the installation is done from an XO (assuming a deployment has those). The devil is in the details, and these seem as endless as a visit to Hell.<span class="HOEnZb"><font color="#888888"><br>
<br>
Tony</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 03/11/2015 03:02 AM, Samuel Greenfeld wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You are taking my remarks a bit out of context, although it is hard for me to tiptoe around explaining things while trying not to insult anyone.<br>
<br>
>From the schoolserver perspective, schoolservers as originally implemented were meant to be an all-in-one system.  They provide DHCP for the laptops, act as the Internet gateway, provide anti-theft & backup services, etc.<br>
<br>
Sugar & XOs have hardcoded logic expecting the schoolserver to be called "schoolserver".  Schoolservers are also expected to have certain hardcoded IP addresses in case an XO runs into anti-theft problems, etc.<br>
<br>
But in larger networks/school districts, I have seen schoolservers installed into networks where they are not allowed to control DHCP.  They often were not the Internet gateway, and local policies might not allow them to be called "schoolserver".  Occasionally the schoolserver isn't even in the same building as the XOs, and may be on a completely different subnet.<br>
<br>
This is a whole concept I once called "Sugar for the Enterprise {school district}" but I don't know if that is worth pursuing at this time.<br>
<br>
<br>
XSCE is interesting in that it supports things like Internet-in-a-box which are not XO specific.  And from what I've seen, the XSCE community may in some ways be more active than the Sugar community.<br>
<br>
But it is unclear to me what features the XSCE community is implementing to support deployments other than those they are directly involved with, or what the feedback loop is there.<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>