[Dextrose] [Sugar-devel] Sugar Server project initiation announce

[Aleksey Lim]

On Sat, Jun 11, 2011 at 01:18:35AM -0700, Sameer Verma wrote:
> On Sat, Jun 11, 2011 at 12:06 AM, David Farning
> <dfarning at activitycentral.com> wrote:
> >> -----Original Message-----
> >> From: Martin Langhoff [mailto:martin.langhoff at gmail.com]
> >> Sent: Friday, June 10, 2011 11:46 PM
> >> To: David Farning
> >> Cc: Aleksey Lim; server-devel at lists.laptop.org;
> > sugar-devel at lists.sugarlabs.org;
> >> olpc-au at lists.laptop.org; dextrose at lists.sugarlabs.org
> >> Subject: Re: [Dextrose] [Sugar-devel] Sugar Server project initiation announce
> >>
> >> On Fri, Jun 10, 2011 at 10:44 PM, David Farning <dfarning at activitycentral.com>
> >> wrote:
> >> > You are 100% correct in these criticisms and concerns about Activity
> >> > Central. We are a new company working in a new market. Failures and
> >> mistakes are inevitable.
> >> > If you have been hurt by those mistakes, I apologize and accept full
> >> > responsibility for them.
> >>
> >> Hi David! Look -- thanks for being so frank and open. Past it the past, and
> > I've
> >> made mistakes aplenty myself. What I was trying to say
> >> was: you seem to be doing the same thing again. Like now. I mean -- today.
> >>
> >> How 'bout taking a slightly different tack? You just posted last week about
> > cookie
> >> licking, which if you think about it... that perhaps applies to those big
> > Ubuntu
> >> announcements last year for example.
> >> Perhaps could apply to this server thing -- we don't know yet. As I said, I
> > frankly
> >> hope I am wrong.
> >>
> >> Anyway -- of course there may be business reasons for your forking. Happens.
> >>
> >> It's just that on the "working with the existing project", the score isn't
> > looking too
> >> good. I mean -- Aleksey subscribed to the xs-devel list, and his first message
> > there
> >> was the opener of this thread.
> >>
> >> Classic.
> >
> > Based on Aleksey's past history of making good technical decisions, producing
> > good implementations based on his designs, and his ability to work effectively
> > with the existing community, I believe that what he produces will be a net gain
> > for the Sugar/olpc ecosystem.
> >
> > As such, AC has given him the freedom to spend the next 6 months working on the
> > server project.
> >
> > The technical decisions of how Aleksey solves the problem are separate from the
> > business decisions of where Activity Central allocates its developer resources
> >
> > david
> >
> > _______________________________________________
> > Sugar-devel mailing list
> > Sugar-devel at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
> >
> 
> Again, I like where this discussion is going, so it may be worthwhile
> to take some of this back to the drawing board. There is the issue of:
> 
> 1) distro independence
> 2) content mgmt vs server admin separation
> 3) school vs library approach (curricular aka XS vs referential aka pathagar)
> 
> Without building yet another school server, can we merge/improve upon
> what's already here?
> Incidentally, Nick Doiron has a post up on the Khan Academy videos
> being served offline (I've thought of the same situation, but with TED
> videos). http://mapadelsur.blogspot.com/2011/06/khan-academy-follow-up.html
>  Neil Dsouza of http://teachaclass.org is in Indonesia (I think)
> setting up offline servers to serve Khan videos in an offline format.
> I hope to speak with him next week to see if we can collaborate/merge
> any of the efforts.

I can't get rid of feeling that we are still talking about a bit
different things:

Thats the core difference between OLPC XS and Sugar Server ways,
OLPC XS and Sugar Server and too different in two major cases:

1. Product vs. Project

        OLPC XS (how I got it and XS's clones from my pov)
        is a product from OLPC, ie, final product when you need to download
        in ISO, for example, and follow detailed instructions how to proper
        maintain it

        Sugar Server is a community, SL, project. Within this project
        happens (by all interesting people/deployments) development of
        core modules

2. OS vs. Tools

        OLPC XS (how I got it and XS's clones from my pov) is, due to
        its design, behaves as an OS: what sugar-server does on its own
        w/ humble deps[1] w/ only by one CLI tool in non-root manner
        (except initial install), XS does by having 3 projects/packages,
        bunch of shell/python scripts, running one process in root,
        creating local users (of course from root) (it is highly not welcome
        if are talking about one service I'm going to run on server, already
        configured and supported, to just serve XOs around). In other
        words XS assumes that it entirely control the OS.
        
        Sugar Server is being designed as one local sugar-server that serve
        only sugar specific features (no network setup, no iptabales
        setup, no Apache, no Moodle, no new local user, not root
        processes, etc) as a decent server does - on its own, you need only
        start it (event from sources directory); the second layer, which
        is independent to the 1st one, configuring the rest of system services
        that might be useful on bare systems, ie, what XS does but this
        level is optional and it is: only about configuring external
        services not sugar specific, each configured service might be
        formed as a separate configuration project and deployed as a
        separate package. The core of this level is the mace[2] utility
        and optional sugar-server-base configuration project w/ common
        stuff.

In other words, Sugar Server is being designed as a project of useful
and well designed/supported local tools. For example AU might use it in
such way: include to its build system 3 binary packages (w/o patching) -
sugar-server, server-sugar-base, mace; configure them to use only id
service for sugar-server (it might be useful even in AU case when
students will just click "Reqister" to get info about jabber server),
configure mace to configure only jabber (though, if only jabber is
installed there is no need in special steps), somehow (it is AU
decision) process all these steps for final school servers, eg, by
having 4th binary package or composing master image to clone/flash it on
XOs.

Back to your concerns:

> 1) distro independence

hmm, but do we have distro dependent stuff on Sugar Server level?
Of course we have on downstream level, but we can think to solve it. For
example mace is designed in such way - the configuration, that mace will
apply to the final systems, are being kept in distro independent
manner[3], ie, for Apache vhost you need only to type its content (in
Apache systax) and mace will manage to place it to the particular distro
dependent place (to /etc/httpd/config.d on fedora and to
/etc/apache/enabled-services on debian). We can think about another
useful way to help downstream do its work smoothly (another idea might
be reusing Open Build Service to create final images for
fedora/debina/fedora-for-XO).

> 2) content mgmt vs server admin separation
> 3) school vs library approach (curricular aka XS vs referential aka pathagar)

Could you elaborate these issues?

> Choice is good. Fragmentation, not so much.

Once more, Sugar Server is not about fragmentation (it is not one more
school server) but about modularization and using these modules on
purpose in downstream.

[1] http://wiki.sugarlabs.org/go/The_Server/1/Components#sugar-server
[2] http://wiki.sugarlabs.org/go/The_Server/Mace
[3] http://git.sugarlabs.org/server/base/trees/master/etc

-- 
Aleksey