Hi Tom, Do you have a link to a workshop web page?
Regards, Jan On 20 November 2012 15:35, tom d <sdent...@gmail.com> wrote: > Hey, all; > > So the Mombasa algebraic geometry workshop is set for 6-28 July, 2013. > Which is really long! They're interested in having some sage sessions; if > anyone's interested in coming out I can plan to be there for an overlapping > time and co-hosting the Sage sessions. (However, the first week I'll be in > Ethiopia.) Basically, drop me a line and we can talk about scope and > further details that should be nailed down. > > > 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> >> 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.
