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 <javascript:>> > http://Nicolas.Thiery.name/ > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/99xrcC4s78UJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
