[Server-devel] XSCE 0.3
dfarning at activitycentral.com
Wed May 29 13:36:58 EDT 2013
On Tue, May 28, 2013 at 11:53 PM, Tony Anderson <tony_anderson at usa.net>wrote:
> This is going to take some time to provide a useful reply.
> Perhaps, the easiest way is to comment on the XSCE specification:
Thanks for your thorough analysis. I wasn't sure if anyone actually read
the project spec:) We create the project spec by informally establishing a
consensus about what we think is important and achievable given our
resources and time before the next feature freeze.
> >In everyday usage it provides various services which extend capabilities
> of the connected laptops while being totally transparent to the user.
> The school server provides the storage capacity not available on the XO.
> In the deployments I serve, there is no internet access. The school server
> is 'an internet in a box'.
While this in not our primary deployment target, this is a direction that I
would like to see the project go. As we stabilize the services, it would be
valuable to add the tools for curators to maintain local content.
>NEW IN 0.4 - XS-Stats - Enables deployments to collect anonymous
> student usage.
> School staff need the ability to keep a 'gradebook' with information on
> student accomplishments that is not anonymous. The above feature is a need
> for the deployers, not the school.
> >NEW IN 0.4 - Backup and Restore.
> This has been provided since XS-0.4. The primary problem here is that the
> backup is considered as a backup (for use in emergency restore situations).
> The real need is to maintain the Journal on the school server for active
> recall as needed. Over time, the Journal grows to fill the available
> capacity on the XO. Currently, the fix is to delete Journal items. The
> current backup also deletes these items from the backup.
> Currently, I am using a modified ds_backup.py script which treats the
> Journal as a store for documents. These are uploaded to the school server.
> Metadata only entries are uploaded to a log and deleted from the datastore.
> The user has the option to delete documents from the data store and then to
> reload them from the school server.
Have you looked at the webdev work to used provide additional storage to
laptop. NOTE: Our web-dev work is currently blocked by our ability handle
external USB harddrives... which I think will land in 0.4
> School servers can be either an XO or standard x86 based hardware.
> 1. Large memory capacity (2GB+)
> 2. Large persistent store (500GB+)
> 3. Operates directly from 12vdc battery (e.g. car or marine deep
> 4. Low power consumption (e.g. <2x XO 4.0). Power consumption
> dictates the size of the solar panel required to charge the batteries.
> 5. Headless operation. Schools with a monitor, keyboard, and mouse
> attached the school server will be tempted to use them as a client system -
> with negative impact on stability.
> 6. Low cost (e.g. < 2x an XO or < $400)
> Most other requirements are satisfied automatically be the system chip set
> (e.g usb ports, ethernet port, etc.)
I tend to agree with you here. Our emphasis on XOs was to start with a
known piece of reference hardware, the XO-1.75, and expand from there. With
a little tweaking XSCE works on most standard x86 based hardware.
> Standard Hardware
> >For greater flexibility some schools will want to use standard hardware.
> Raspberry Pi
> The Trim-Slice indeed appears to meet the requirements for a school
> server. I plan to try one in the next few weeks. One interesting
> possibility is to boot from an SD card for installation and
> trouble-shooting (via SSH).
> The Raspberry Pi is attractive (esp. for low cost); however, I am
> concerned about it's physical packaging in a school environment.
+1 Each release we are going to try to add one of two pieces of hardware.
> >Command line configuration/administration should eventually be
> discouraged as the system matures. Future target users are often not
> familiar with Linux system administration. Initial setup or fixing a
> problem with their server is not a good time to introduce system
> administration skill.
> System administrators and a deployments development team will use the
> command line because it is the most efficient tool available. In general,
> server administration is not and should not be done on a production machine.
This is interesting. One of the most common requests I hear from
deployments is "What do we do if we don't have a Bernie, Daniel, or Tony
>  Remote Configuration
> >NEW IN 0.4 -- Remote administration – There are several systems such as
> CFEngine and puppet which enables remote management.
>  Command Line
> The problem here is that the school server is not connected to the
> internet. There are many available and proven technologies to manage
> networked computers.
> It would be handy if the XOs at a school could be managed from the school
> server. Perhaps Puppet is the right technology for this task.
> Where a 'mother ship' is possible managing school servers (and XOs) at
> multiple schools, the problem is often that the school server connection to
> the internet (WAN) is via DHCP. One solution is for the school server to
> call home periodically.
I think that this will be an area for development in 0.4. We are
experimenting with the mothership concept where a deployment has a
mothership with a fixed IP that school server use to call home. This is how
our openvpn system works.
> >Service:Jabber server Purpose: collaboration > 15 clients needs to work.
> Provider: ejabberd
>  Extended Services
> Actually, Ejabberd serves all connected XOs (>100 at most schools). I
> doubt that 'collaboration' in this technical sense is widely used in
> deployments. Sadly, it is not in the deployments I service.
> Currently, all XOs are connected in the same emulated 'mesh' network. I
> think this would be better configured so that XOs in a single classroom
> form a 'mesh'. This can be done by the administration tools included with
+1. We need an ejabberd expert to tune ejabberd.
>Service: Web server
> Purpose: Building block for many other extended services
> Provider: apache
> Apache, of course, services web requests.
> >Service: proxy server and web cache
> Purpose: bandwidth, web-filtering, web-monitoring
> Provider: squid
> I suspect that squid is of little use for school servers not connected to
> the internet. It will certainly be needed if all connected XOs are surfing.
> I really think that we may never see a deployment which provides direct XO
> access to the internet for all XOs due to cost and bandwidth issues.
> In the developing world, the internet provider is a telecom company which
> charges for time and megabytes downloaded. Most require special contracts
> for shared usage. A more likely scenario is that the school server will
> download information from the internet (e.g. email) in batch by a cron job.
+1 The target that we have kept in mind was the edge of the internet. How
do we maximize value while minimizing cost for these schools.
>Service: Virtual Private Network (VPN)
> Purpose: Creating secure point-to-point or site-to-site connections in
> routed or bridged configurations and remote access facilities
> Provider: openvpn
> I assume this could be a good alternative where a 'mother ship' is
I think of it as step toward mother ship.
> >NEW IN 0.4 -- Service: Content filtering (TimM??)
> Purpose: age-appropriate surfing, legal compliance, religious risks
> Provider: dansguardian and opendns
> One concern - the development team for the deployment must make it very
> clear (in writing - CYA) that the school server provides a filtering
> mechanism but the responsibility for using this capability belongs totally
> to the school administration. I don't think any of us want to be the target
> of legal action if some child finds something inappropriate on the internet.
+1 I am very clear that while we enable the filtering tools. It is the
deployments responsibility (and liability) to set it up to meet their needs.
> NEW IN 0.4 -- Service: 1-N WebDEV(JerryV, GeorgeH)
> Purpose: Journal submissions to teacher, academic record (homework etc)
> Provider: WebDAV
> This is an important requirement. Is this implementation documented?
> >NEW IN 0.4 -- Service: Statistics Collection
> Purpose: Collects users statics for academic research
> Provider: pilot monitoring system
> >NEW IN 0.4 -- Service: Book server (SameerV, AlexK, GeorgeH struggling!)
> Purpose: compete with Khan Academy?
> Provider: pathagar
> OLE Nepal has provided Pustakalaya capability on the school server since
> XS-0.4. This capability is provided at the schools I am servicing using
> Django (as does Pathagar). The webkit based Browse Activity supports the
> library directly (eliminating the need for the Library activity). The
> important point is that there are two parts to this requirement: (1) a
> means to add items to the library and (2) a means to download items
> selected by the user to the XO for offline use.
I have contacted OLE Nepal several times about adding Pustakalaya to XSCE.
Them seem too busy with their own fires to worry about an upstart project
Could you help with this.
> >>NEW IN 0.4 -- Service: Internet in Box
> Purpose: Provide offline content
> Provider: ???
>  Future Features and Objectives
> I hope to have the opportunity to work with 'Internet in a Box' this
> summer. Possibly, XS could be installed on the Seagate device. Possibly,
> the content on the Seagate could be added to the school server.
+1 We are working with braddock on this. He has done some very clever work!
The seagate device does not have the processor or memory to handle the XSCE
load. Hopefully we can help braddock provide IIAB on XSCE within the next
> >>Content curation (beyond dumping stuff into Apache directories)
> I am not sure I understand what is meant here. Certainly the deployment is
> responsible for curating the content on the school server.
This one of the edges we are exploring. I tend to lean towards your point
of view that content is the deployments side of the problem.... But there
are tools we can provide to make that curation easier.
> Khan Academy
> Currently installed at the schools I am servicing, including the
> exercises. There are 40 topics for primary school (through pre-algebra).
> There is some difficulties. The videos can be converted to ogv at
> considerable expense in computer time (ffmpeg2theora). Alternatively, mp4
> and mp3 capability can be added to the XOs. The videos and exercises are
> licensed under Creative Commons. However, the student profile is not. This
> means an alternative must be developed.
>  Future services
> Please consider adding features and objectives to this list if you feel
> they should be included in a future release. If you consider the feature
> important and are willing and able to do the necessary work please sign
> your name to take responsibility for that service.
> Note: Daniel Drake has provided an effective mechanism to add capabilities
> to the server via 'usbmount'. MediaWiki can be added by a simple script
> (the only tricky part is adapting to pgsql). Wiki4Schools is also
> available. Django was added in the same way.
> There are some capabilities that would be very desirable:
> 1. Email. This requires an email client on the XO (there have been some
> attempts to build such a activity, e.g. Gmail.activity). The email system
> should operate locally among the registered XOs as well as batch-forward
> and receive email via usb key from a local internet cafe or from a periodic
> connection via gsm. The system should also provide mailing lists (e.g.
> school computer club).
> 2. Printer. The ability to attach a printer to the school server. XOs
> should be able to put printable items in a print queue. The school
> administration should be able to select which items are to be printed (ink
> and paper cost $). Having print drivers on the XO should not be required.
> 3. Portable Journal. In the Lesotho schools, there are not enough XOs for
> one to be permanently assigned to a student or teacher. Even in a true OLPC
> environment, laptops at home will be used by family members.
> There should be a login facility to identify users. Separate datastores
> should be kept for each user. The datastore backup should backup up by
> user, not serial-number. The Journal should enable a logged-in user to load
> his/her Journal from the school server (metadata) and documents as needed.
> This facility should certainly support changing laptop assignment (e.g.
> when the user's laptop needs repair).
> 4. Wiki collaboration. The school server in general assumes that it is
> provided by an external deployment and that it will not be modified by the
> clients (except for the Journal). There should be a means for students and
> teachers to create collaborative documents, Wiki-style.
> Perhaps this can be done by setting up a local wiki in mediawiki. Perhaps,
> something like Tiddly-wiki or etherpad would be useful.
> The school server provides services. There can never be a definitive
> specification of those services. At least, the above are my thoughts at the
Thanks for the feedback. Would you mind installing 0.3 on a trimeslice or
x86 piece of hardware and providing more feedback on issues you face? You
time spent on the coalface makes you feedback particularly valuable to us.
Activity Central: http://www.activitycentral.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Server-devel