[Dextrose] Regarding my OLPC XS Wishlist

[Aleksey Lim]

On Fri, May 27, 2011 at 11:39:54AM -0400, Bernie Innocenti wrote:
> On Fri, 2011-05-27 at 21:14 +0545, Abhishek Singh wrote:
> > Dear All,
> > I've put down my OLPC XS wishlist at
> > http://asingh.com.np/blog/olpc-xs-my-wishlist/ . Please comment upon it.
> > 
> > Thank You.
> 
> Thank you! Forwarding this to the Dextrose list as well.

I've also CCed guys who do XS work in .au

Abhishek: thanks for sharing your wishlist.

>From my side, I see the whole picture in case of school server like having:

* sugar-server[1], the base of any school server. it doesn't provide
  stuff like moodle (too complicated to be basic) or puppet (useless on
  this level, since configuring sugar-server should be just install
  packages/iso and do some automatic work, the higher levels might user
  puppet or so)
* any additional services that might be useful in some deployments but
  are not basic, eg, moodle or wiki.
  sugar-server should provide needed info via reliable API for these
  services.
  in my mind, such services might be formed as separate projects (like
  sugar-server-moodle) to make it possible to attach it on purpose
  (there might be useful configuration tool that is being used in
  sugar-server, mace[2]).
* final products that include components on purpose (but sugar-server is
  a required one). It is entirely depends on local needs.

My own running though your wishlist keeping in mind sugar-server plans:

1) Porting XS to new version of Fedora
   sugar-server will be build on OBS[3] for distros that are being used
   in the field (deb or/and rpm based).
   So, downstream can just use these packages, add new one and create
   the final product (there is an idea to teach OBS to create isos for
   not only SUSE, obs is designed originally)

2) Support for multiple architecture
   see the 1), as well for arches
  
3) Basic Self Tests
   I'm gathering all OLPC XS packages/services/scripts to one project,
   one package, one CLI tool. unittest for this stuff is a from-scratch
   decision.
   Also, having additional projects like sugar-server-moodle, let people
   concentrate, thus test better (including auto tests) this exact
   module.

4) Inclusion of new packages
   Entirely not sugar-server level

5) Content Updates
   no ideas, but would be useful (thanks to new modular desing) to have
   some experiment sugar-server-* modules to test

6) Web content filtering
   Agree, it should be a basic component (and it will be a part of
   sugar-server)

7) Journal Backup on a shared model distribution
   See the 5)

8) Socializing/Communication Platform
   See the 5)
  

[1] http://wiki.sugarlabs.org/go/The_Server
[2] http://wiki.sugarlabs.org/go/The_Server/Architecture#Mace
[3] https://build.opensuse.org/

> 
> -- 
>  _ // Bernie Innocenti
>  \X/  http://codewiz.org
> 
> 

-- 
Aleksey