[Server-devel] Regarding my OLPC XS Wishlist

[Aleksey Lim]

On Thu, Jun 02, 2011 at 06:29:51PM +1000, Sridhar Dhanapalan wrote:
> On 28 May 2011 08:31, Aleksey Lim <alsroot at activitycentral.org> wrote:
> > 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.
> 
> We are looking to make our XS-AU[0] more modular to suit different use
> cases. Our initial goal

> (completed over a year ago)
If I got it right, it is still the same OLPC XS code base but w/ tweaks?
sugar-server in that case is a new project w/ more tough and localized
design.

> work on a single interface to integrate well into existing networks.
> Installation is via USB and fully scriptable via kickstart files.
>
> The current XS is very monolithic and bureaucratic. It requires
> moderate sysadmin skills to install and maintain. Maintaining the
> presence service is cumbersome and impractical in our schools. The
> turnover of teachers and students is far too high to ensure that
> anything gets managed properly.

> We're looking to slim down the XS-AU such that we can have a simple
> collaboration server (which we currently call "XS Lite") that is
> installable in a classroom as a drop-in appliance.

ie, just having jabber server and somehow let students know where it is?

> is an ejabberd.

btw, I'm planing to use Prosody instead of ejabberd. I have really bad
experiance w/ ejabberd - on jabber.sugarlabs.org it eats too many
resources for regular 10-30 online users. Prosody is slim and light app
and it alsready works fine w/ sugar-0.88.

> Registration, Moodle, Squid, backups and so on are
> unnecessary. Each teacher can run their own server for their own
> class. Conveniently, this could easily run on an XO (XS-on-XO).

in other workds there is no need in sugar specific stuff at all - just
install jabber server from packages (maybe w/ sugar specific patches) and
write its url on studensts' boxes.

> > 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)
> 
> You're using SuSE as a base? That sounds like an awful lot of work
> porting to a distribution that isn't widely used. Why not stick with
> the current platform, which benefits from Red Hat engineering and has
> a much larger developer, installation and user base? Not to mention
> that the XOs use the same platform, meaning that skills can be shared
> across client and server.

OBS is not only suse (in fact, they renamed it from openSuse Build
Service to Open Build System recently). In other words, it can create
package for any rpm/deb based distro, but, afaik, it can create iso only
for opensuse for now (and plan is looking how it might be done for other
distros, but anyway using obs as a packages farm is good w/o having
isos).

> The XS-AU has been working pretty well on Fedora 11 for quite some
> time. We've reconfigured it so that it runs as a set of packages on
> top of Fedora 11[1] rather than being a fork. We're quire confident
> that it'll work on Fedora 13 without much effort. Fedora 14 will need
> a bit of work since it has a newer version of Python.
> 
> 
> Sridhar
> 
> 
> [0] http://dev.laptop.org.au/projects/xs-au/wiki
> [1] http://dev.laptop.org.au/projects/xs-au/wiki/Install_on_an_existing_Fedora_installation
> 
> 
> 
> Sridhar Dhanapalan
> Technical Manager
> One Laptop per Child Australia
> M: +61 425 239 701
> E: sridhar at laptop.org.au
> A: G.P.O. Box 731
>      Sydney, NSW 2001
> W: www.laptop.org.au
> 

-- 
Aleksey