[Server-devel] [XSCE]

Sat Oct 12 12:58:28 EDT 2013

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.

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

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.

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.

George

On Sat, Oct 12, 2013 at 11:54 AM, Tim Moody <tim at timmoody.com> wrote:

> Everyone will be shy to respond, but here's my take.  First, the
> motivation is that the benefit of a school server, especially in non or
> occasionally connected environments, is assumed.  Secondly, let's be clear
> that you asked about goals, not what we've accomplished.
>
> The goal of the XSCE project is to continue development of the OLPC XS
> project along the following lines:
>
> 1. Absorb features from all the various incarnations of XS including 0.7,
> Nepal, Australia, and any others and make it available on a variety of
> platforms including intel, but also incredibly cheap and incredibly low
> power devices, such as the XO but also raspi, trimslice, cubox, and others
> as they come to market.  These features fall into three broad categories,
> infrastructure such as routing, support for XO specific services, and
> general (web) server based applications and content.
>
> 2. Move installation and configuration from something that happens along
> with the OS installation to something an end user could do using a gui
> whenever she likes, if required.
>
> 3. Provide a mechanism whereby features can be contributed by interested
> members of the community without rebuilding a disk image or an rpm.
>
> Answers to specific questions below.
>
>  -----Original Message----- From: Tony Anderson Sent: Friday, October 11,
>> 2013 11:10 AM To: xsce-devel at googlegroups.com Subject: Re: [XSCE]
>>
>> Hi, All
>>
>> Help me understand a little about where this project is going.
>>
>> I understood XSCE initially as an attempt to use an XO as the school
>> server. This was motivated by two requirements: (1) support for deployments
>> which were constrained to use XO and (2) use of the XO-1.75 as the school
>> server to enable use of the lower power ARM architecture.
>>
>> Apparently one outcome is that the XS-0.7 install procedure was replaced
>> by a requirement to add school server capabilities to a previously
>> installed build (e.g. 13.2).
>>
>> The XS architecture separated the disk into two partitions: root and
>> library. The intent was to separate software (root) from content (library).
>> This would support backup of the library partition since the root partition
>> could be restored by a new install followed by simple copy of the backup to
>> the library partition. Does XSCE maintain this architecture?
>>
>
> XSCE requires that the OS be pre-installed, so the disk partitioning is a
> priori.  However, some of us have encouraged people to place content in the
> /library directory so that it can take advantage of a separate partition if
> there is one.  It would certainly be possible to mount external devices as
> /library.
>
>
>
>> The XO build is installed as a copy of an image from a usb drive to the
>> internal store.
>>
>
> Work is being done on this installation mechanism, but up to now server
> content has been installed as an rpm, which has dependencies on other rpms
> and scripts to do various work like configuring networking, etc.  The
> repositories can be remote or local.  The new ansible install still
> operates at the time of initial installation, but avoids having to build
> rpms and holds the promise of incremental configuration.
>
>
>> The XS install is a normal OS install in which a minimal Linux OS
>> executes a script from a ramdisk to access the USB flash drive, decompress
>> files and to copy them to the newly created partitions.
>>
>> Apparently, XSCE is installed by the previously installed OS (13.2). What
>> is the dependency of XSCE on this OS? Does the XSCE install replace it?
>>
>
> In the rpm and ansible scenarios it does not replace the OS on the XO or
> any other device.
>
>
>> Naturally, the XO software build is for a client machine. It is based on
>> graphical user interface, keyboard, and track pad.
>>
>> A server is intended to supply services to other computers (clients) via
>> a network. As such, it is intended to be operated headless. Control of the
>> server is normally by a remote login and command line operations.
>>
>> How does XSCE handle the change from a client machine to a server? Does
>> it require a monitor and keyboard (or touchscreen)?
>>
>
> Like XS, XSCE requires a monitor and keyboard (built into the XO) for
> installation, but can be basically headless thereafter.  Most of us turn on
> sshd and do the entire install remotely.  Probably other devices can come
> up with sshd capability already on and be entirely headless, if you can
> figure out their ip address.
>
>
>> There is discussion of a home page. In XS-0.7 there is no home page. The
>> only way to interact with the server is via ssh. Is this home page in XSCE
>> the portal to a web site supported by XSCE or an administrative interface
>> to XSCE?
>>
>
> My experience of XS is that the home page is moodle.  I have been working
> on a high level home page aimed at end users from which there would be
> links to installed services.  It is intended to support local languages.
>
>
>
>> For historical reasons, server administration is done in English (similar
>> to the fact that air traffic control is done in English).
>> I assume from this that a multi-language home page is the home page of a
>> web site on the server, not server administration.
>>
>
> yes.  however, several web-based administration tools are in the works.
>
>
>
>> There has been much discussion of Ansible (vs Puppet). Is Ansible
>> intended as a means to implement the build process for XSCE or as a means
>> to implement and customize the install of XSCE or as a means to administer
>> an XSCE installation?
>>
>
> The implementer of ansible cleverly added an rpm build mechanism, but it
> is really aimed at installation, and, I hope, eventually at administration,
> either remote or local.
>
>
>> The general philosophy of XS is to build a single installable version of
>> the software (currently XS-0.7). After installation, scripts are
>> provided to configure the software, primarily to match the local network.
>>
>> I think the assumption is that the server has ample disk capacity so that
>> there is no need to limit the installed software packages to those that the
>> deployment actually uses. For example, Moodle is installed but rarely used.
>> XS-0.7 sets up a root partition of 8GB and the rest of the available
>> capacity is given to the library partion.
>>
>> It is certainly understandable that this assumption would not apply to a
>> school server based on an XO laptop.
>>
>> However, it has always been clear that the XO is a terrible choice for a
>> server platform to be used only as a last resort. The primary reason for a
>> school server is to give access to content beyond the limited capacity of
>> the XO.
>>
>> Even though the OLPC project is intended to address the problem of the
>> 'digital divide', many developers seem to assume that deployed XOs have the
>> same access to the internet as they themselves have. Even if a school has a
>> DSL line shared by 100 XOs, that is not the same as a developer with access
>> to a broadband network shared among a handful of users.
>>
>> I think it is important that the XSCE project define its goals and
>> assumptions clearly.
>>
>> In the case of the XS-0.7, the assumptions are that the deployment has
>> limited or no access to the internet, that it has a school server with
>> large disk capacity, the server can support a local wifi network, the
>> server can operate without system administration (essentially unattended
>> except for power on and power off) for a full school year, the server can
>> share internet access when connected to a WAN (ISP) with the XOs connected
>> on the local network, and that the software on the school server be stable
>> and updated at most once between school sessions.
>>
>
> I think the XSCE community assumes that all of the above represents the
> most common scenario.  I grant that the requirement for large disk
> capacity, which I know you take to be axiomatic, is not met by all of our
> target platforms in ways that we find satisfactory yet.
>
>
>
>> Tony
>>
>>
>> On 10/11/2013 09:58 AM, George Hunt wrote:
>>
>>> for Haiti, I just disabled multiviews in
>>> /etc/httpd/conf.d/xs-portal.**conf (commented out)
>>>
>>>
>>> On Fri, Oct 11, 2013 at 9:14 AM, Tim Moody <tim at timmoody.com
>>> <mailto:tim at timmoody.com>> wrote:
>>>
>>>     just before I left for travels there were problems at the Haiti
>>>     deployment with the multilingual home page I put together.  Can
>>>     someone summarize where that currently stands?  Was it simply
>>>     commented out and not used?  I want to sort this out.
>>>
>>>
>>>
>>
> --
> Sig inserted by AutoHotkey ver. 1.1.11.01 (signature - first line)
> WLMail QuoteFix -> http://www.dusko-lolic.from.**hr/<http://www.dusko-lolic.from.hr/>(signature - second line)
>
A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/server-devel/attachments/20131012/8143dc9c/attachment-0001.html>