[IAEP] [Marketing] OLPC rules out Windows for XO-3

[Bert Freudenberg]

IAEP is not a "catch all". 

It's hard to delineate exactly what's appropriate and what's not, but the exchange below clearly belongs on the developer list. Everyone who is interested in that kind of detail and able to follow the discussion is certainly subscribed to that other list. So as soon as a topic swings too much into technobabble it should be taken off IAEP. IMHO.

Thanks to Ian for speaking up. Self-moderation works :)

- Bert -

On 09.06.2010, at 00:56, forster at ozonline.com.au wrote:

> Ian
> 
> Do you think that the solution is to create a new and more narrow list which meets the needs of deployers and teachers or to narrow the scope of IAEP and moderate it to keep it within scope?
> 
> My understanding if IAEP is thats its a "catch all", if you only follow one list, its the one to follow to keep across all issues. I cannot recall a moderator stopping a thread. Does it need to be moderated to keep it within "A discussion list for Sugar and the learning theories that it espouses"?
> 
> The issues with starting a more aggressively moderated deployers and teachers list is that its one more list to monitor and that it might never get critical mass.
> 
> Tony
> 
> 
>> Guys,
>> 
>> I have been an avid follower of IAEP for over a year now. I was, and still am, very attracted to the theme of the list serve.
>> 
>> But I find increasingly, I delete 90% of the emails as they hold no interest to me as a regional coordinator of OLPC projects in the Pacific Islands.
>> 
>> I am sorry, but this stream of ARM processors and SCIM/M17N/IBus/etc holds no interest to me and I really can't see how it adds value to the IAEP theme. I find the list serve has been taken over by technical developers and it is no longer helpful in delivering educational information to me.
>> 
>> I guess I must be having a bad morning, but this time I just had to make a comment.
>> 
>> Ian Thomson 
>> PacRICS and OLPC Coordinator
>> SPC
>> Phone +687 26 01 44
>> 
>> 
>> -----Original Message-----
>> From: iaep-bounces at lists.sugarlabs.org [mailto:iaep-bounces at lists.sugarlabs.org] On Behalf Of Sayamindu Dasgupta
>> Sent: Wednesday, June 09, 2010 4:35 AM
>> To: Peter Robinson
>> Cc: Rafael Enrique Ortiz Guerrero; marketing; bens at alum.mit.edu; iaep
>> Subject: Re: [IAEP] [Marketing] OLPC rules out Windows for XO-3
>> 
>> On Tue, Jun 8, 2010 at 9:23 PM, Peter Robinson <pbrobinson at gmail.com> wrote:
>>> On Tue, Jun 8, 2010 at 4:43 PM, Sayamindu Dasgupta <sayamindu at gmail.com> wrote:
>>>> On Tue, Jun 8, 2010 at 7:52 PM, Peter Robinson <pbrobinson at gmail.com> wrote:
>>>>> On Thu, Jun 3, 2010 at 11:18 PM, Chris Ball <cjb at laptop.org> wrote:
>>>>>> Hi,
>>>>>> 
>>>>>>   > Linux has been running well on ARM for a long long time.
>>>>>> 
>>>>>> Yeah.  In specific, today I got Sugar running on the ARM SoC we'll be
>>>>>> using for XO-1.75 and XO-3, and it didn't require any porting at all.
>>>>>> It would have happened yesterday, but I had to work out how to get
>>>>>> past the Sugar intro/login screen without a keyboard.  :-)
>>>>> 
>>>>> That's cool! A couple of questions....
>>>>> 
>>>>> What's the plan for the boot loader, is it planned to use OF still and
>>>>> port it to the ARM platform or is it planned to use one of the more
>>>>> mainline ARM bootloaders such as uboot or the like.
>>>>> 
>>>>> Also what's the plan with the virtual keyboard support in sugar. It
>>>>> might be worth looking at the MeeGo/Moblin based VKB stuff as a basis.
>>>>> Its skinnable and supported various inputs via scim and integrates
>>>>> with that. Let me know if you need more info as I've been packaging
>>>>> some of this up in Fedora as part of my work with the aforementioned
>>>>> UIs in Fedora.
>>>>> 
>>>> 
>>>> At one point I had tried to evaluate the possible virtual/on-screen
>>>> keyboards that could be used for Sugar, and at that time it looked
>>>> like each used their own keyboard layout data format. Something which
>>>> leverages existing mechanisms like SCIM/M17N/IBus/etc would certainly
>>>> be an improvement. Could you point me to the source code repo of VKB -
>>>> I would love to take a look.
>>> 
>>> I'm not sure if this is the the best current upstream because of the
>>> changes in the Moblin/MeeGo side of things but the git here is
>>> relatively recent
>>> 
>>> fvkbd is the actual virtual keyboard. This is also in Fedora.
>>> http://git.moblin.org/cgit.cgi/fvkbd/
>>> 
>>> scim-panel-vkb-gtk is the scim overlay stuff. It will be in Fedora 14
>>> and likely pushed back to F-12/F13.
>>> http://git.moblin.org/cgit.cgi/scim-panel-vkb-gtk/
>>> 
>> 
>> Thanks for the links. This also seems to use its own data format¹ for
>> defining the keyboards, but it looks like it is much more
>> mature/flexible than the other options I have seen so far.
>> 
>> FWIW, I had written a tool² which could parse XKB layout definitions
>> (symbol files) and produce the corresponding SCIM layouts, and I have
>> used it to generate OFW keytables as well³. I think that this tool
>> (with some modifications) will be able to migrate our existing
>> keyboard layouts to the format required by fvkbd.
>> 
>> Thanks,
>> Sayamindu
>> 
>> 
>> [1] http://git.moblin.org/cgit.cgi/fvkbd/tree/layout
>> [2] http://dev.laptop.org/git/users/sayamindu/xkb2scim/
>> [3] http://dev.laptop.org/git/projects/xkb2ofw/