[Server-devel] Server-devel Digest, Vol 78, Issue 15

Sat Oct 12 15:15:25 EDT 2013

Hi, George

The following from Sridhar's page appears to be relevant:

  Project vs Distribution vs Product

It is important to define the concepts of project, distribution and product.

A projectis an ongoing effort to develop a technical solution. It is 
under constant flux and hence is not generally intended for end-users. A 
distributionis a packaging of a version/snapshot of the project's files, 
often configured for a particular purpose.

A productis more comprehensive, providing properties such as ease of 
use, QA and accompanying documentation. What makes a product really 
stand out is integration with other parts of the deployment 
organisation's business. This can include factors such as supply chain, 
technical support and the educational programme.

The community XS is a project, open to participation/use by anyone. 
Deployments are encouraged to create their own distribution/product to 
better suit their needs. For OLPC Australia, this will take the form of 
our One Network 
<https://docs.google.com/document/d/1dnhU2F6EntepVXTgN8QpkME8fZVUuPjcCoMUfAVKbcc/edit?pli=1#heading=h.60mn085jgn8e>product.

This section outlines the architecture of the community XS.

    Scenarios

Here are some scenarios that the community XS should be compatible with. 
Non-conflicting combinations of these should also be possible.

 1.

    it hosts the network, acting as an access point itself

 2.

    it hosts the network, and bridges to an external wireless access point

 3.

    it acts as a gateway to another network, such as the Internet

 4.

    it participates on an existing network, without hosting core services

 5.

    one XS server serves the whole school

 6.

    many XS servers participate on the same network

 7. the XS optionally provides services such as collaboration,
    registration, roster groups (presence segregation), backups and
    content on a modular basis

I do not see the distinction you make between XS and XSCE. XS-0.7 was
developed by Daniel Drake as an ongoing effort started by Martin Langhoff.
The major difference is that this project was a part of OLPC and not the
community.

The real question is whether the community is adopting and continuing 
the XS project or starting a new one.

As a continuation of the XS project, the first step could have been to
build XS-0.7 with a Fedora base. This essentially requires performing 
the build
process with a Fedora repository instead of CentOS. This would have made
XS-0.7 available for ARM-based platforms.

Sridhar did not mention 'remix' in his description. Generally for 
servers, the distinction is distribution + desktop vs distribution + 
server.

In the discussion of scenarios, Sridhar does not mention the most 
important point of the school server architecture, the distinction 
between LAN and WAN.
Here is a revised description. Note: all of Sridhar's scenarios are 
currently fully supported by XS-0.7.

 1.

    it hosts the LAN network

 2.

    it may be connected to one or more wireless routers

 3.

    it acts as a gateway to another network (WAN), such as the Internet

 4.

    it participates on an existing network (WAN) , without hosting core
    services for that network

 5.

    one or more XS servers serve the whole school, dependingi on the
    number of XOs deployed.

 6.

    many XS servers may participate on the same (WAN) network

 7. the XS provides services such as collaboration, registration, roster
    groups (presence segregation), backups and content. These services
    may be used or not at the discretion of the deployment.

See below for specific comments.

On 10/12/2013 12:57 PM, server-devel-request at lists.laptop.org wrote:
> Message: 2
> Date: Sat, 12 Oct 2013 12:58:28 -0400
> From: George Hunt<georgejhunt at gmail.com>
> To: xsce-devel<xsce-devel at googlegroups.com>,	XS Devel
> 	<server-devel at lists.laptop.org>
> Subject: Re: [Server-devel] [XSCE]
> Message-ID:
> 	<CADfCcpU-XQ2=wDjWRbHcrwfmJKTZs=tANGb_kiSeio6ZSNwWzw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Tony,
>
> I'd add to Tim's comments:
>
> Sridhar, early in the XSCE design,  made a distinction between project, and
> product, which I find useful -See-
> https://docs.google.com/document/d/1dnhU2F6EntepVXTgN8QpkME8fZVUuPjcCoMUfAVKbcc/edit--
> follow the "Product vs Distribution vs Product" link.
>
> XS0.7 was a product, whereas XSCE is attempting to be a project. By
> reconceptualizing, and restructuring the install process, now with the
> higher level server description language, called "ansible", we are
> attempting to position the code base to be flexible, and applicable, to new
> distributions, hardware, processors, needs and requirements.
I still do not understand who is the user of Ansible. It would seem to a 
be a tool for use of the XSCE project, not its clients.
>
> As such, XSCE is not meant to be directly usable until it is married with
> specific hardware, and a set of requirements. Two examples come to mind:
>
>     1. In September, I installed an XO4  and a trimslice at two schools in
>     Haiti. One with gateway function via 3G modem and Internet In A Box on an
>     XO4, the other with IIAB function on a Trimslice, and a large storage
>     battery, to deal with intermittent power.
I assume you used an external usb drive to store the IIAB content. How 
many XOs did these school servers support?
>     2. There is now a $100 low power quad core ARM becoming available (6
>     watt 2GB memory- CubeBox ) which XSCE software stack may be adapted to
I think we may have to seriously explore having a school server with an
external usb hard drive and how this can be packaged to maximize stability.
The newer small form factor systems appear to support SSD internally via
mSATA. However, economical SSD storage is currently insufficient for IIAB.
>
> XSCE project moved away from Centos, partially because we wanted to run on
> ARM as well as i386/x86_64.
>
> Also, we did not want dependencies on punji, kickstart, or anaconda that
> would lock us into fedora, as we looked forward towards running on
> debian/ubuntu, or such.
This direction I do not understand unless it is anticipated that Fedora 
would not
support some significant new architecture.

Rebasing on Fedora was clearly necessary to support ARM.
>
> Yes, much of what we have done does not directly add value in the
> classroom. But hopefully it positions our code base to be relevant in the
> classroom for the next 10 years.
>
> It's also true that we have not yet defined a product, or turnkey solution.
> Be we have a growing cadre of programmers,  with skills to do that. It
> appears that Activitycentral is moving in that direction with DXS.
Since XSCE-0.4 has a version number, it is hard not to call it a product.
>
> George
By now everyone is familiar with my frustration. I see some incredibly 
talented people doing the impossible. However, this talent is, in 
effect, re-inventing the wheel.

Configuring an XO as a school server is a terrible idea. Once I saw the 
Spruce Goose with an aeronautical engineer. His comment, 'Just because 
something can be done, doesn't mean it should be done.'

Building XS-0.7 on a Fedora base instead of CentOS should be 
straightforward.
Abhishek Singh at OLE Nepal did it for me in a few hours. The biggest 
problem
was reconfiguring the build process to use local repositories so the 
build could
be done independent of the internet.

It is particularly frustrating when I imagine the wonderful enhancements 
this community could bring to XS. The original concern expressed by 
Abhishek and I was that XS-0.6 was based on an obsolete version of 
Fedora. This problem was
elegantly addressed by Daniel Drake in XS-0.7.

I hope we can have a real dialog on these issues in SF.

Tony

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/server-devel/attachments/20131012/daf257f1/attachment-0001.html>