[Server-devel] XS wishlist

Fri May 27 14:08:07 EDT 2011

On 05/27/2011 10:15 PM, Sameer Verma wrote:
> Came across this via Twitter: http://asingh.com.np/blog/olpc-xs-my-wishlist/
>
> Here is a copy and paste for archival purposes:
>
> Sameer
>
> ---------------------------
> elow is a list of changes that I wish to have in the OLPC XS (some of
> which comes from our own list of customization):
>
> Porting XS to new version of Fedora
> Fedora Project has come to the release of version 15 of their Linux
> distribution host a lot of interesting features, but OLPC XS is still
> stuck with Fedora 9 (which itself has moved to “End of Life”). This
> state hinders us from using more stable software components, access to
> bug-fixes, and improved infrastructure. This also forces packagers to
> package software for Fedora 9. Porting XS to Fedora 15 will bring into
> all the awesomeness, but again it will be a lot of work porting the
> patches and packages (developed by OLPC community) to Fedora 15.
>
> Support for multiple architecture
> Though XS is targeted to be run on generic low-end servers (mostly
> i386 architecture), but the recent trend of hardware price fall,
> deployers will tend to use more advanced hardware (which might support
> x86_64 architecture). Current XS effort is targeted at i386 (32 bit)
> builds, but adding x86_64 (64 bit) builds would not be that
> cumbersome, and would definitely attract deployers eyeing 64bit
> hardware.
>
> Basic Self Tests
> It would be great to have basic self tests embedded into the XS, which
> will help the school side to diagnose and fix the problem easily.
> Individuals at the school looking after the school server might not be
> proficient with GNU/Linux and would have a hard time to diagnose and
> fix a problem with XS; this is a case with the Nepalese deployments.
> Adding to this, for a fix, either the support team needs to be
> dispatched to the school (which might be located in a remote place),
> or the ask the school to bring back the school server to the support
> centre. Given the scenario in Nepal, with just a single support
> centre, this fix can cost a lot of time, effort, and money. Basic self
> tests, with mechanism to provide instructions on now to fix simple
> problems is greatly going to ease the hassle. The self tests can
> contain testing services, network status and such.
>
> Inclusion of new packages
> systemd: a replacement for SysVinit and Upstart that acts as a system
> and session manager.
> usb-modeswitch: a library/utility for handling Mode-Switching USB
> Devices on Linux. This package is required to access internet through
> 3G cards (e.g. Mobile broadband).
> ipcheck: a Dyndns.org client to register your dynamic IP address. It
> helps to configure the server with dynamic dns and with port
> forwarding enabled on the Internet gateway, eases accessing the
> schoolserver from anywhere on the Internet.
> MySQL: a relational database server, and a de-facto backend for many
> services. Also it would be good to ditch PostgreSQL for Moodle. MySQL
> management is easy than PostgreSQL and there is more documentation,
> community support and human resource for MySQL.
> PHP with required extensions: a powerful server-side HTML embedded
> scripting language. OLE Nepal’s digital library “E-Pustakalaya” runs
> on PHP and MySQL. Also we might need some PHP extensions like
> php-mysql, php-gd, php-xml.
> Python 2.x and Python 3.x: an interpreted, interactive,
> object-oriented, extensible programming language. Python 2.x should be
> included for backward compatibility as many python scripts and
> applications still use the 2.x version. Python 3.x should be included
> for forward compatibility — more apps would be coded in 3.x version in
> coming days.
> Expect: a Unix automation and testing tool and used to automate
> interactive applications such as telnet, ftp, passwd, fsck, rlogin,
> tip, etc. E-Pustakalaya uses Fedora Commons which has a interactive
> setup; we use expect to automate the installation by providing all
> answers to the setup program. Expect is useful to create headless
> installers, and it also has a python wrapper.
> libicu and unicode support: Adding unicode support in XS will help to
> have localized web applications hosted on the XS (using gettext
> framework).
> Java: Adding a Java Runtime Environment (JRE) would add support for
> running java based applications (e.g. Tomcat, Fedora Commons, etc.)
> tzdata and extensions: Adding timezone data and its wrapper libraries
> in various languages will help the support for timezone data in
> applications hosted on XS (e.g. SchoolTool needs pytz).
> SchoolTool: a free administrative software for schools around the
> world. It provides a good administrative interface and facilities.
> I’ve already packaged SchoolTool for Fedora and tested it on XS. OLE
> Nepal is also in transition to pilot SchoolTool to a few schools. Also
> that a integration of Moodle and SchoolTool is being worked out.
> Moodle 2.x: a Course Management System (CMS), also known as a Learning
> Management System (LMS) or a Virtual Learning Environment (VLE). The
> moodle on current XS is outdated. Moodle 2.x hosts improved interface
> and additional features than its previous versions. With Moodle, a few
> other features would be interesting:
> Using MySQL instead of PostgreSQL
> Integration with SchoolTool: See
> http://docs.moodle.org/en/Development:SchoolTool_Integration for
> details.
> A mechanism to consolidate Moodle data. The scenario would be like XS
> would be shipped with some sample data, teachers and students at the
> school would create some data, and additional data would be pushed
> periodically through content updates. So there should be a mechanism
> to consolidate all the data and retain it, without losing the previous
> data while doing content update.
> Content Updates
> XO laptops with a limited storage can not hold much content, so heavy
> content (e.g. E-Pustakalaya) is offloaded to the school server. Also
> that the XS hosts sugar activity updates. In Nepalese deployment, we
> generate content bundles including E-Pustakalaya and E-Paath along
> with new releases of sugar activities every three month, and the
> deployment team would generally visit each schools and update the
> content. Nepalese XS is equipped with scripts to handle headless
> content updates. Additionally we are also doing content update through
> network/internet wherever feasible. Content update through network can
> be really troublesome with deployment scenario of schools having
> limited connectivity to internet and/or having only LAN level access
> among schools. Devising content update would involve creating a
> unified format for content bundles and devising a way to deploy
> content updates easily through network with a minimal payload on the
> content server. I would suggest a torrent based mechanism to handle
> content deployment – it will offload content through local peers and
> handle data checksums and all. Meanwhile a mechanism to support
> loading content on a USB harddisk would be great as it will help to
> deliver the content to the XS with no internet connectivity.
>
> Web content filtering
> XS with internet access are configured as a internet gateway for XO
> laptops and other devices connecting to the network. This poses one
> problem – children can be subjected to websites related with vandalism
> and pornography. A content filtering mechanism for web browsing would
> solve this problem. Additionally some file extensions and websites can
> be blocked, so as to help traffic shaping. I would suggest
> Dansguardian as a tool for this purpose. We have been using
> Dansguardian on NE-XS (the Nepalese clone of OLPC XS), and has been
> successfully using it. Dansguardian supports message/information
> templates in case a extension or a website is blocked. Also that it
> supports unicode message. Hence using a Dansguardian with customized
> message templates in local languages would help a great for content
> filtering, meanwhile displaying appropriate message in case of site
> blockades.
>
> Journal Backup on a shared model distribution
> I am aware that OLPC projec emphasizes the laptop distribution model
> having 1:1 child-laptop ratio, that is to say each kid owns a laptop,
> but sharing a laptops among few kids (say one laptop to be shared
> among 3 kids) can be beneficial sometimes. For developing countries
> like Nepal, it might take some time to arrange funds for mass OLPC
> deployments. In such a scenario, where mass deployments might take
> time, grounding on in available resources (XOs) would seem appropriate
> than to wait to gather enough resources for mass deployments. This
> focuses on having the XOs shared and utilized rather than keeping them
> unused. Having said that, physically sharing a laptop among few kids
> might seem no-brainer, but the complexity lies in how the XS interacts
> with the school server and how services are provided/consumed. One
> important aspect of this is Journal backup. XS has a service call
> id-manager (idmgr) which registers a laptop with school server. The
> registration uses the XO serial number as a unique key to maintain the
> list and various service like ds-backup is provided based upon the
> key. In the laptop-sharing scenario, the journal created on a laptop
> might actually belong to more than one user, and managing journal
> backups and restore can be troublesome. Meanwhile, multiple users
> using one laptop means that more journal entries would be created and
> hence the frequency for journal backup would increase inherently. To
> solve this problem, the idmgr and the ds-backup service somehow needs
> to recognize the user creating the journal entry rather than just
> based upon the XO serial. Unfortunately, I do not know how to force
> user logins on sugar; and forcing user logins consequently is going to
> confuse the kids. Another way might be to use one folder per user per
> XO serial. But then we need to tell idmgr and ds-backup on which
> journal entry should go into which folder. I don’t yet have a clear
> idea on how to implement this, but I would definitely like to have
> this feature included with the XS
>
> Socializing/Communication Platform
> I have always been looking forward to implementing a socializing and
> communication platform on the XS that will help users to socialize and
> communicate. By this I mean inter-school and intra-school
> communication. Also that this framework can be used to send messages
> and notifications to users (teachers, administrators, and students).
> Implementing an offline mail queue which keeps mail lined up and sends
> them when it has internet connectivity would be a great features.
> Schools in Nepal have sparse Internet connectivity, and such a mail
> queue might help inter-school communication. I’m looking forward to
> use Open Atrium as a tool for this purpose. Also a multi-node system
> of Open Atrium, if it can be implemented, with a inter-node
> communication, would ease the task a lot.
>
> These were some of the customizations I envision would help a great
> deal with the XS. I’m not even sure if items off my wishlist are
> feasible at this time. What is your XS wishlist?
> _______________________________________________
> Server-devel mailing list
> Server-devel at lists.laptop.org
> http://lists.laptop.org/listinfo/server-devel
Thanks Sameer for posting, I was just about to post this to the mailing
list. This wishlist contains some of the items that we are already doing
at OLE Nepal, and some which we would like to have integrated into OLPC
XS. I hope the recommended changes would benefit the whole community.

-- 
Abhishek Singh
System Engineer
Open Learning Exchange (OLE) Nepal
साझा शिक्षा ई-पाटी
http://www.olenepal.org
Tel: +977-1-5544441 ext. 301


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.laptop.org/pipermail/server-devel/attachments/20110527/7502e2c4/attachment.pgp