Hi I also work in Science in many countries in Africa [1]. My preferred single solution is a standalone Ubuntu desktop (laptop) installation. As it dual boots, it is minimally invasive. The procedure is simple. "AIMS-desktop" currently only needs network for the install, and if it reaches network afterwards it can updated through the usual graphical means [2]. This method overcomes the problems with system administration by simplifying everything to one system [3] and overcomes problems with regular electricity and network outages, as each user has a laptop battery. A small UPS for the data projector is advisable to minimise frustration. It is also non-negotiable to me that each participant leaves the workshop with the software in working order.
On the road to this the main obstacles were PPAs for rstudio, sage, and casapy (another huge python-based source-tree-cum-kitchen-sink piece of science software, like Sage!), which is now done simply by repacking upstream debs or binaries -- while debian-ugly it really turned out to be by far the easiest. Future work on aims-desktop becoming a standalone installer include perhaps rebranding to something generic like science-desktop (brought to you by AIMS ;) and refactoring it so that science-desktop-minimal fits into 4G, in order to use relinux (or remastersys) [4] to make an install CD which includes Ubuntu (2G), Sage (1.6G), and dependencies like tex (1+G). We may have a different flavour or install method to overcome this 4G limitation as we really want the science-desktop-minimal to inlcude scipy, gedit-plugins-extra, rstudio-desktop, texlive-full, texmaker, openjdk, and barring licensing/distribution problems, non-free codecs as well, or separately. science-desktop-standard is currently around 12G and science-desktop-extra around 20G. The eventual aim would be an easily maintained (minimal variation from, mostly just metapackages with dependencies) science flavour of Ubuntu, like kubuntu, xubuntu, etc. I'm not sure of the technical details yet, but this might be a 16G USB installer, with the usual 1-2G installer and all the extra packages loaded onto that memory stick. As I am working on this alone, and mostly because my day job keeps me busy, it's taken years! to get this far. I'll have time within the next quarter or so to update aims-desktop from 12.04 to 12.10, or to decide to support LTS only; and to build a sage buildbot slave for 12.10, or to build a LXC/KVM machine to provide builbot slaves for many Ubuntu versions. It does look like this is becoming more part of my day-job, officially; it doesn't mean other administrative work is reduced though... If anyone wants to help out, do let me know though. Two opportunities now include 1) investigating a minimal install with ubuntu + sage PPA for relinux, which will produce a downloadable ISO (though with the username/pass already set) and 2) writing a script to download a few packages onto a standard Ubuntu USB installer so that sage, gfortran, and a few other things can be installed after an Ubuntu install by a one-liner. AIMS centres can also act as regional hubs. Unfortunately due to bandwidth costs, public mirror hosting is unlikely, but hosting for internal use is likely; proxies are commonly deployed. At AIMS South Africa we install hundreds of laptops annually for our students and regional students who heard about it. AIMS Ghana and AIMS Senegal is poised to do the same. In the meantime speak to me about hosting sage days at an AIMS centre, where you will arrive with Sage already installed on all computers, and the most reliable internet you can find in an African university. If someone knows where to get the funding, I would look forward to a July 2014 Sage days in Cape Town. [1] http://www.nature.com/news/education-africa-s-counting-house-1.11757 [2] https://launchpad.net/aims-desktop [3] http://hplgit.github.com/edu/uiopy/uiopy.html [4] http://relinuxkit.org/, http://www.geekconnection.org/remastersys/ubuntu.html Regards, Jan On 12 November 2012 06:07, Mike Zabrocki <mike.zabro...@gmail.com> wrote: > Wow! Nicolas fantastic report. That was a challenge to do. I hope > you managed a convert or two in Africa. My experience with computer > classes as part of a summer school (in Ghana, Kenya, Tanzania and > Madagascar) is similar except I never had a wifi network and most > of my students didn't have regular computer access. > > Most of my students were complete novices > to the computer, but willing to learn. Installing sage was several > steps beyond what we tried. I would say that most of the infrastructure > that we had access to would not support sage (most computers were > dated pre-python, though I did not have the expertise to make this work). > > I think to break the barrier and make a true sage days really productive, > I think that you would need to partner with some organization like OLPC > (one laptop per child) or arrange to minimize the problems with > your hardware. > > -Mike > > On Sunday, 11 November 2012 04:00:34 UTC-5, Nicolas M. Thiery wrote: > >> Dear Sage devs, >> >> The fall school on Discrete Mathematics in Bobo Dioulasso, Burkina >> Faso, aka Sage Days 43, just finished. For two weeks we had courses >> (combinatorics of words, dynamics, tilings, ...) interspersed with >> on-hands tutorials using Sage. The public consisted mostly from >> graduate students, from subsaharian Africa and some further away >> countries. >> >> That was a good occasion for a real-life evaluation of a claim I have >> been desiring to make for a long time: �Sage, being open-source, is >> well adapted for universities in developing countries�. >> >> Let's see about this. >> >> A couple words of context: >> -------------------------- >> >> - 70 participants total; in average 40-50 were there. >> - Most participants had a laptop (or netbook for a few of them): >> - 90%: windows, 5% mac, 5% Linux Ubuntu (usually in double-boot with >> Windows) >> - Laptop age ranging from 2003 to 2012; 4 years on average >> - RAM: 500k-6Gb; 1Gb on average? >> - Network: one ADSL line for 60 persons in the conference center >> Well, when it actually worked, which was not that often. >> We finished using a cell-phone shared over wifi. >> The local wireless network itself was down quite often. >> No network at the university itself or nearby >> - Among the organizers were Sage devs with good experience on running >> Sage workshops and doing system/network administration, ... >> - Sam had brought a big bunch of power cables. I screwed up not >> bringing my own wireless router to at least guarantee a reliable >> local network. >> >> Strategies we tried or considered: >> ------------------------------**---- >> >> (a) Installing Sage on Linux/Mac with the binaries from Sagemath.org >> (b) Installing Sage on Linux/Mac from sources >> (c) Installing Sage on Linux from a custom built fat binary >> (d) Installing Sage on Windows with the virtual machine >> (e) Running a Sage server on my laptop (8 cores, 8Gb) >> (f) Using a remote Sage server >> (g) Installing Linux and reducing the problem to (a-c) >> (h) Booting on a live Debian USB key, custom-build by Thierry Monteil >> with Sage, self-cloning and persistence. >> (i) Using a local PC lab after installing Sage on them >> >> I would like to use the occasion to send my kudos to all those who >> strive hard at making Sage easier to use one way or the other. >> >> How it went: >> ------------ >> >> (a) Went smoothly on Mac when appropriate binaries were available. We >> had to recompile a few of those binaries. >> >> (a) failed most of the time on Linux by lack of gfortran. Since we did >> not have a reasonable network, apt-get install was not an option. >> We did not have iso's of all the Ubuntu versions that were in use. >> 3D plotting was usually not available (by lack of appropriate Java >> plug-ins). >> >> (b) Compiling from source was not a viable option on Linux for the >> same reason as above: build-essentials was usually not there. On >> Mac that was ok, provided we had under hand the appropriate >> version of XCode. >> >> (c) This fat binary was built by Thierry Monteil on an old pentium 3 >> (!) with a minimal Debian install. Installation and usage went >> smoothly, except that 3D plotting was usually not available. >> >> (d) Virtual machine: Installation went smoothly on about 20 machines >> (with close guidance). It failed on 2-3 machines due to resource >> limitations (disk, ...). >> >> However, except for about five recent machines, the memory >> footprint was just too high: any non trivial calculation or plot >> made the laptop swap and become simply too slow to use. >> >> The french keyboard was not properly self-detected. Due to the >> network, we could not look up on the web for help. We ended up >> finding how to configure it from a shell. I'll create a ticket. >> >> The Sage version available was a bit old (5.1) though that was not >> an issue for us this time (but it could have been). >> >> The usage was on the complex side for most participants. They >> typically tended to reclick on the ova, creating a new virtual >> machine each time. Also uploading worksheets was tricky; it would >> be much simpler if the virtual machine was setup to access the >> user directory on the host machine or if the web client was >> running on the host. >> >> (e) Running a local Sage server: This is a priori good short term >> solution, except that participants don't leave with Sage running >> on their machine. My laptop easily handled the dozen people using >> it. However the unreliability of the local wireless network ruined >> the game more often than not. We have no data for how this would >> have scaled if all participants had gone this way. >> >> (f) Using a remote Sage server: given the network situation, we did >> not even bother trying. >> >> (g) Installing Linux, 3-4 machines: we were of course all favorable >> to encourage participants to switch to Linux. However, installing >> a new system always means taking a risk, especially since most >> participants did not have backups (or even did not have a clue >> what a backup was ...). Besides we did not want to spend too much >> time on system administration. >> >> (h) Live USB key, ~30 machines: this worked smoothly on most PC's >> after fighting a bit with the BIOS to boot from USB. Some HP >> laptops resisted. Pro: we could include some extra documents >> (tutorial files, ...) on the key. Con: it forced people out of >> their usual work environment. The self-cloning was an important >> feature to quickly replicate updated versions of the key (log(n)), >> and promote future diffusion around the participants. >> >> (i) Local PC lab: we ended up dropping the idea because the available >> PC labs either lacked network or electrical power. Potential pros >> and cons: more consistent hardware simplifies the >> installation. But the hardware tends to be older. The room can >> possibly be used for running Sage in the long run. But the >> participant don't leave with Sage running on their machine. >> >> Summary: >> -------- >> >> - The two main bottlenecks were network and available memory. >> - The virtual machine seldom was a viable option. >> - The Live USB key was by far the most robust option, though not ideal >> for long term use by the participants (and it does not work on Mac, >> or at least not easily). >> - We really had to plan for multiple strategies to ensure that at >> least one would work for each participant. >> - It seems unlikely that someone without serious Sage experience would >> have a chance to setup a Sage tutorial in similar (and alas typical) >> conditions. >> >> Altogether, and for what it's worth, this experience suggests that >> Sage sill has quite some way to go before we can claim that it is >> indeed well adapted for universities in developing countries. >> >> Recommendations: >> ---------------- >> >> Of course one could rightfully argue that things would be *much* >> easier if Linux was more widely spread in universities with little >> resources (which would make a lot of sense as well). But since we >> can't do much on that front at the Sage scale, here are some tentative >> recommendations for improving Sage itself: >> >> - Sage on Windows: there *is* an important use case for having a >> native port of Sage on Windows. Over time, the virtual machine *may* >> become a viable option as memory limitations become less >> stringent. For this, it is crucial to reduce the memory footprint to >> its bare minimum. Using the host web browser is the most obvious >> step. >> >> - Precompiled binary for Linux: besides the usual distro-specific >> binaries, it would be very helpful to have two (32bit / 64bit) fat >> Sage binaries that would work without dependencies on as many >> distros and processors as possible. Even if this means a slightly >> larger archive and lack of optimizations on recent >> processors. Compiling on a Pentium 3 was probably overkill, but >> Pentium 4 would be good at this point in time. If there is a way to >> include Java plugins that would be great as well. >> >> I let Thierry Monteil comment more on how he built those binaries. >> >> - Having more Sage mirrors in Africa (although the network issues were >> more in the last kilometer). >> >> - Keeping on reducing the Sage's startup time and memory by lazy >> importing more stuff in Sage. >> >> Again, kudos to all who strive and will strive at improving the >> usability of Sage! >> >> Cheers, >> ** Nicolas >> -- >> Nicolas M. Thi�ry "Isil" <nth...@users.sf.net> >> http://Nicolas.Thiery.name/ >> > > > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To post to this group, send email to sage-devel@googlegroups.com. > To unsubscribe from this group, send email to > sage-devel+unsubscr...@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel?hl=en. > > > -- .~. /V\ Jan Groenewald /( )\ www.aims.ac.za ^^-^^ -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
