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

2013-10-12 Thread Jerry Vonau
On Sat, 2013-10-12 at 15:15 -0400, Tony Anderson wrote:
> 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.'
> 

Comes down to which services are needed at the point of deployment and
the number of clients. The XO was the easiest method to test the waters
of ARM support for the XSCE.

> 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. 

Just wondering what version of Fedora was used for the demo?

> The biggest problem 
> was reconfiguring the build process to use local repositories so the
> build could 
> be done independent of the internet.
> 

Yea that is the easy part of the ecosystem, now try to configure the
services. Fedora's shift to using systemd, updating to a later version
of Apache are some of the fun stuff that the XSCE project addresses in
the F18 release. 

> 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.
> 

Which is about the same as F14, now it is time to bite the bullet and
move forward in time to gain the support for ARM platform officially or
wait for ARM on CentOS.

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

I hope so also.

Jerry


___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel


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

2013-10-12 Thread Tony Anderson

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 
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-requ...@lists.laptop.org wrote:

Message: 2
Date: Sat, 12 Oct 2013 12:58:28 -0400
From: George Hunt
To: xsce-devel,  XS Devel

Subject: Re: [Server-devel] [XSCE]
Message-ID:

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