[Server-devel] [XSCE]

Sat Oct 12 13:12:10 EDT 2013

On Sat, Oct 12, 2013 at 9:58 AM, George Hunt <georgejhunt at gmail.com> wrote:
> 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.

The correct answer to the million dollar question. Excellent!

Sameer

> 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:
>
> 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.
> 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/ (signature - second
>> line)
>
> A
>
> _______________________________________________
> Server-devel mailing list
> Server-devel at lists.laptop.org
> http://lists.laptop.org/listinfo/server-devel