[Server-devel] Server-devel Digest, Vol 75, Issue 25
sverma at sfsu.edu
Thu Aug 1 12:33:49 EDT 2013
On Mon, Jul 29, 2013 at 11:33 PM, Tony Anderson <tony at olenepal.org> wrote:
> As I have unsuccessfully tried to explain many times. OLE Nepal, with help
> from Daniel Drake, an effective and proven means to add selected
> to the base server. Since this capability takes advantage of the running
> server, all of its normal system administration capabilities are available
> yum, etc.).
This is true, but not documented well and not known. For instance, we
use munin and openvpn on the XS 0.7 in Jamaica, and those are
"add-ons". It would be good to document this and discuss approaches
for installing complementary services.
> The other difference with the school server is that disk capacity should not
> a constraint. This means leaving Moodle installed but unused has negligible
> Making http://schoolserver go directly to Moodle is probably not justified.
> should probably create a home page or, at least provide an example that
> deployments could modify to their needs.
Good point. There is a cost to Moodle if it is the landing page,
because it eats up CPU cycles for PHP and postgres. In fact, when load
testing XS 0.6 on the XO-1 (pages 137-148
it was the postgres cycles and swap that killed it! We could hardly
get past 20 simultaneous or so.
The landing page should be something less heavier than Moodle, unless
of course you have hefty servers and don't care of the hits that
postgres+PHP will bring. For instance, running Pathagar
(python-django) on a sqlite backend on a SheevaPlug took hits upto
about 500 simultaneous users (spread using a gaussian distribution
over 60 seconds) before it started to fail. I suspect a XO-1 running
Pathagar will outperform a XO-1 running Moodle.
> On 07/29/2013 07:56 PM, Sameer Verma wrote:
>> On Mon, Jul 29, 2013 at 11:56 AM, Tony Anderson <tony at olenepal.org> wrote:
>>> The XS-0.7 release of the school server software is built with CentOS
>>> The main problem is that CentOS does not support the ARM isa.
>>> XSCE, as I understand it, arose to fill an urgent need to implement the
>>> school server on ARM to reduce the power requirements of the school
>>> Also in my understanding, XSCE was ported to run on the Fedora base used
>>> the XO for Sugar. This was needed to enable XO hardware to be
>>> used for the school server.
>> Another reason for the XSCE push was to make the server less
>> monolithic and allow deployments to select components. For instance,
>> Moodle is integral to XS 0.7. Most projects (to my understanding) use
>> the admin pages in Moodle (added to stock Moodle by OLPC) and not
>> Moodle itself. Most people on this list do not have a good exposure to
>> the continued use of Moodle in an institution (I use it at work every
>> day), so Moodle has failed to take root. In my opinion, for Moodle to
>> take root, it needs to come populated with sample courses and a set of
>> simple directions to add more. From what I gather, there are NO
>> instructions/documentation on the use of Moodle in the OLPC context.
>> This is most likely because we all hit the 24 hour limit per day :-)
>> Is it salvageable? Yes! We need a good set of courses and a repo to
>> host at and download from. A Youtube search for "moodle backup
>> restore" will show you how easy it is.
>> Moving along, XSCE hopes to provide a menu approach to select the
>> services you need (Pathagar, Drupal, <your favorite service>). That
>> requirement, along with AU's need to have a server per classroom (XO
>> based server) got mixed up in the granularity requirement.
>>> In short, there is no reason to do anything to run the school server on
>>> Intel isa, just use XS-0.7.
>> As of now, this is true. XS 0.7 is rock solid, and it's stability
>> comes from the CentOS/RHEL underpinnings. Once XSCE is able to provide
>> a menu to "remove Moodle, add Pathagar" AND provide a CentOS base, the
>> reasons for XSCE may get stronger.
>> In case you were wondering, I am NOT a fan of using Fedora for a
>> server. Stability and upgrade paths are my primary concerns.
>>> In my understanding, the Sugar Desktop runs on Fedora on both Intel and
>>> architectures. The fact that Sugar is extensively tested and supported in
>>> the Fedora environment probably outweighs any stability advantage of
>>> On 07/29/2013 06:00 PM, server-devel-request at lists.laptop.org wrote:
>>>> We are mixing our channels abit here.
>>>>>> A Sugar based desktop on CentOS is pretty unlikely. As Peter noticed,
>>>>>> there are many dependencies necessary for a recent Sugar which are not
>>>>>> present in CentOS. CentOS intentionally lagges fedora by several
>>>>>> releases for stability. If someone wanted to do it badly enough, it
>>>>>> would be possible to backport the fedora 18 GTK stack to CentSO
>>>>>> A school server based on CentOS or Ubuntu LTS is more likely. The
>>>>>> challenge is remaining compatible with XOs. For hardware
>>>>>> compatibility, a XO requires recent OLPC-OS versions which are based
>>>>>> on recent fedora version.
>>>>>> The step necessary to make XSCE on CentOS run on _Commodity_X86_
>>>>>> hardware are not that great. The problem is that it would require
>>>>>> maintain a non-XO branch in parallel with the XO compatible branch..
>>>>>> Anyone have the time, energy, and flame retardant skin to tackle that?
>>> Server-devel mailing list
>>> Server-devel at lists.laptop.org
More information about the Server-devel