Hey, all! Thanks for running this, Nicolas, and providing the detailed report!
For converting people to linux: I'm working with a computer lab in Maseno, where we've now got linux dual-booting on all of the machines (about 40). Over the last couple months, we've gained a number of linux converts: windows in the developing world tends to be pirated and without regularly updating anti-virus software. So the machines 'gunk up' over the course of just a week or two of use to the point of being nigh-unusable. Providing an easily-accessible linux desktop as an option lets people decide for themselves, and once they've tried it, they're overwhelmingly preferring linux. Of course, live-usb's are a perfectly good way to provide such an experience as well. I just got a pile of 8gb usb sticks for $5 each from Canada; setting aside $250 and a bit of time could then provide live usb sticks for up to 50 participants at a sage-days event (with leftovers going towards the next event, of course). 4gb is probably a bit tight for a full installation plus sage, but could cut cost a bit. And with 8gb, we could also include open-office and a couple good text editors, making a good case for general linux use. As a last note, there's an algebraic geometry workshop happening in Mombasa, Kenya, sometime between May and June next year; I'm trying to figure out what the dates are now! We could potentially try some things out there, as well! Best, -tom On Sunday, November 11, 2012 12:00:34 PM UTC+3, 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-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.
