Yes, let&#39;s remove the &#39;potential naming conventions&#39; section; it doesn&#39;t belong in this particular document.<br><br>&gt;  I happen to think that the dual-desktop Sugar/Gnome approach of the <br>&gt; XO-1.5 is brilliant and I&#39;d like to see it on every Gnome desktop for example.<br>
<br>+100.  Indeed, getting Gnome design mavens to weigh in and find fault with and help out with Sugar development so that they are comfortable with that would be an excellent community-building exercise.  <br><br>SJ<br><br>
<br><div class="gmail_quote">On Thu, Oct 29, 2009 at 5:04 PM, Sean DALY <span dir="ltr">&lt;<a href="http://sdaly.be">sdaly.be</a>@<a href="http://gmail.com">gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
My apologies for the delay, I&#39;ve had a very full plate.<br>
<br>
I wish to comment on Question 2, &quot;Should SL be neutral about<br>
<div class="im">distributions containing Sugar, and refuse to endorse one over<br>
another?&quot;<br>
<br>
</div>This question is unfortunately ambiguous. Let me explain, then answer<br>
it in the manner of my Norman forbears ;-)<br>
<br>
A key part of the Sugar Labs message is that hardware is secondary -<br>
that Sugar should potentially run on most anything; one could say<br>
&quot;hardware-agnostic&quot;.<br>
<br>
Implied in that message is that operating systems are secondary, too.<br>
The VirtualBox solutions are well-crafted with their approach of<br>
aiding parents and teachers get Sugar up and running without<br>
installing an entirely new OS just to do so.<br>
<br>
Distributions are secondary as well. They provide the basis for Sugar<br>
to run, but for classroom needs, the less said the better; an ideal<br>
Sugar machine is turned on and shows the Home View shortly after,<br>
finds the rest of the class on the network, and so on.<br>
<br>
This is not to demean the enormous work that goes into distributions<br>
to work on varied hardware, nor to make Sugar work over the varied<br>
distributions (and I&#39;m not forgetting the enormous XS school server<br>
work). It&#39;s just that Sugar benefits from the meme that the distro or<br>
hardware is irrelevant. Sugar benefits because the industry-centric<br>
discussion of &quot;Windows machines versus Apple machines versus Linux<br>
machines&quot; becomes an education-centric discussion of &quot;how best to help<br>
children learn with a screen on a computing device&quot;.<br>
<br>
Concerns about preferable treatment towards one distro or another<br>
distract from a supertruth: the true competitor of Sugar and the<br>
distros it runs on is the system preinstalled on most PCs, which today<br>
is Microsoft Windows.<br>
<br>
There is a key difference between the GNU/Linux distributions and the<br>
two other predominant proprietary operating systems: GNU/Linux systems<br>
are open and thus closest to our education mission of &quot;low floor, no<br>
ceiling&quot;.<br>
<br>
>From a marketing perspective - the point of view of &quot;how best to<br>
inform millions of teachers that there is an alternative?&quot; - we are<br>
obliged to seem to &quot;endorse&quot; one distro over another. But that&#39;s a<br>
function of our combat to find a place for Sugar, not playing<br>
favorites... &quot;The right tool for the job&quot;. On a grassy hillside, we<br>
send in the cavalry; on a swift river, we launch the boats. Worrying<br>
about preferring the cavalry to the marines misses the point of our<br>
objective... nobody would send the boats up the hill.<br>
<br>
So. Fedora is playing a key role in the OLPC-OS and on today&#39;s Sugar<br>
on a Stick for the forseeable future; however, it&#39;s weak with OEMs and<br>
in education. Not to worry, Ubuntu is gaining traction with OEMs (cf.<br>
M. Shuttleworth goal: &quot;Ubuntu as the default alternative to Windows&quot;).<br>
meanwhile, OpenSuSE has the most complete education-oriented offer and<br>
LTSP work. Other distros offer different advantages; the list goes on.<br>
The Try Sugar page should be a colorful garden of choices available;<br>
which shouldn&#39;t stop us from prominently recommending (as opposed to<br>
&quot;endorsing&quot;, which implies exclusivity) a low-risk way to experience<br>
Sugar to bewildered first-time visitors.<br>
<br>
Today, Sugar on a Stick is the pillar of our marketing and<br>
brand-building because it disassociates Sugar from the XO or indeed<br>
any hardware; it makes Sugar instantly understandable to anyone that<br>
it is software. As a Sugar Labs brand, it needs to be protected. To be<br>
supported, it needs to be a stable software stack. None of which<br>
precludes anyone from doing any liveUSB they wish with Sugar on it; it<br>
just shouldn&#39;t be called Sugar on a Stick.<br>
<br>
I&#39;ve said before that our marketing mix would inevitably need<br>
adjustments as OEM deals happen. Such deals will mean Sugar reliably<br>
preinstalled and supported on thousands of machines, a fabulous<br>
development for children. This would not be bad news for Sugar on a<br>
Stick, which I believe will remain the best way to try (and possibly<br>
the best way to deploy) Sugar for years to come; as the OLPC XOs will<br>
remain Sugar&#39;s native home and overwhelming installed base for years<br>
to come (supporting which I feel as a personal responsibility).<br>
Rather, all these ways will together contribute to the perception that<br>
Sugar will work on something old, something new, something borrowed,<br>
something blue.<br>
<br>
(On a related topic, we are not even debating the role of desktops,<br>
which only goes to show how poorly their role is perceived in the<br>
stack, particularly in comparison to distros. I happen to think that<br>
the dual-desktop Sugar/Gnome approach of the XO-1.5 is brilliant and<br>
I&#39;d like to see it on every Gnome desktop for example.)<br>
<br>
So yes, we should be neutral about distros in general, while choosing<br>
the best distros for solving the challenges we face... at the risk of<br>
appearing to &quot;endorse&quot; one over another, or two over five, or four<br>
over nine, or whatever.<br>
<br>
thanks<br>
<br>
Sean<br>
<br>
P.S. The potential naming conventions section is a marketing<br>
discussion, and although it&#39;s an attempt to seek solutions, it<br>
unfortunately completely disregards how the existing brand is being<br>
built.<br>
<div><div></div><div class="h5"><br>
<br>
<br>
<br>
<br>
On Tue, Oct 27, 2009 at 11:14 PM, Sean DALY &lt;<a href="http://sdaly.be" target="_blank">sdaly.be</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>&gt; wrote:<br>
&gt; I need to express my position on the two questions I haven&#39;t yet.<br>
&gt;<br>
&gt; I will do so tomorrow, it&#39;s late I&#39;m a bit tired to express myself<br>
&gt; clearly tonight.<br>
&gt;<br>
&gt; thanks<br>
&gt;<br>
&gt; Sean<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Oct 27, 2009 at 6:05 PM, Samuel Klein &lt;<a href="http://meta.sj" target="_blank">meta.sj</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>&gt; wrote:<br>
&gt;&gt; We are close to consensus consensus on the first two points.   Help with<br>
&gt;&gt; wording a final report would be appreciated.  I wish I could extrapolate<br>
&gt;&gt; Bill B&#39;s position from some of his earlier comments, but I cannot :)<br>
&gt;&gt;<br>
&gt;&gt; We don&#39;t have consensus on the specific wording of the 3rd question, but do<br>
&gt;&gt; on the underlying principle of &#39;not being confusing&#39; -- there are two<br>
&gt;&gt; suggestions that a more specific name than &quot;Sugar on a Stick&quot; be used, as<br>
&gt;&gt; that name is a normal English phrase and could naturally refer to a whole<br>
&gt;&gt; class of distributions.<br>
&gt;&gt;<br>
&gt;&gt; Since there&#39;s already a mailing list and some history behind &quot;Sugar on a<br>
&gt;&gt; Stick&quot;, are there any others on this list that would like to see a more<br>
&gt;&gt; specific name?  Does anyone expect this list to refer to all distributions<br>
&gt;&gt; of Sugar on removable devices, or is there broad agreement that this is for<br>
&gt;&gt; a specific team, concept, and product?<br>
&gt;&gt;<br>
&gt;&gt; Finally, are there any other questions that have been raised that people<br>
&gt;&gt; feel we should address?<br>
&gt;&gt;<br>
&gt;&gt; SJ<br>
&gt;&gt;<br>
&gt;&gt; On Thu, Oct 22, 2009 at 11:51 PM, Benjamin M. Schwartz<br>
&gt;&gt; &lt;<a href="mailto:bmschwar@fas.harvard.edu">bmschwar@fas.harvard.edu</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Samuel Klein wrote:<br>
&gt;&gt;&gt; &gt; Ben, Bill, DSD and Faisal -- can you please weigh in and share your<br>
&gt;&gt;&gt; &gt; thoughts?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Happy to.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &quot;Should Sugar Labs be a GNU/Linux distributor, rather than just an<br>
&gt;&gt;&gt; upstream producing Sugar releases?&quot;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Yes.  Sugar Labs should do whatever is needed to make Sugar easily<br>
&gt;&gt;&gt; available to our audience.  When this goal is best achieved by<br>
&gt;&gt;&gt; distributing complete operating systems including Sugar, we should have no<br>
&gt;&gt;&gt; qualms about doing so.  However, Sugar Labs should also continue to<br>
&gt;&gt;&gt; emphasize the availability of Sugar through the mechanisms of existing<br>
&gt;&gt;&gt; distro package managers, in order to reach users who already run GNU.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &quot;Should SL be neutral about distributions containing Sugar, and refuse to<br>
&gt;&gt;&gt; endorse one over another?&quot;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Yes.  Sugar Labs does not now have a mechanism for making blanket<br>
&gt;&gt;&gt; endorsements, and it should not instate one.  Conversely, Sugar Labs<br>
&gt;&gt;&gt; should help users to choose their best option for deploying Sugar,<br>
&gt;&gt;&gt; depending on their individual needs, and this will typically mean<br>
&gt;&gt;&gt; recommending a particular distribution best suited for each user.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &quot;Should &#39;Sugar on a Stick&#39; be a phrase that SL asks its community to avoid<br>
&gt;&gt;&gt; using unless they refer to the SoaS-Fedora distribution?&quot;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; No.  We should give this distribution a unique, identifiable name that<br>
&gt;&gt;&gt; cannot be confused with a generic description of an entire class of<br>
&gt;&gt;&gt; distributions.<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; SoaS mailing list<br>
&gt;&gt; <a href="mailto:SoaS@lists.sugarlabs.org">SoaS@lists.sugarlabs.org</a><br>
&gt;&gt; <a href="http://lists.sugarlabs.org/listinfo/soas" target="_blank">http://lists.sugarlabs.org/listinfo/soas</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
</div></div></blockquote></div><br>