Hi, thanks Nicolas for this exhaustive report. I would like to witness this adventure it in a more pessimistic way, so that people willing to host such a sage days know what kind of problems will appear, and which workarounds are realistic.
Being free software is definitely not a sufficient condition for being usable in "developping countries". The main reason is that free software and internet are closely interdependent (none could have been developped without the other). Compare http://www.ipligence.com/worldmap/ and http://sagemath.org/development-map.html If you plan to have a workshop in a place with no onternet connection nor recent machines, you will experience a lot of problems. We had a preparatory workshop at the same place one year ago (with only 20 local participants) that went much less smoothly (one could even say catastrophic) than that one. A small report was done on the page http://wiki.sagemath.org/days34.5#line-19 = Feedback = == Windows users == - virtualbox is not a solution. People running Windows usually have the last version (not XP), which has the effect of taking all the RAM, even on some not so old laptops. Adding a layer makes things worse. - the existing live CD installed on a USB key is a good option, but : - The .exe file that installs the live-cd on the hard disk of a windows install does not work at all (tested on various machines without success). - Moreover there is no easy way for the participants to spread it afterwards, you need a recent version of unetbootin or some knowledge of sfdisk/hdparm/mkfs/syslinux to make it bootable to some other key. == GNU/Linux users == - People under GNU/Linux mainly run Ubuntu, but do not necessary run the last version (not even some older LTS version). Unfortunately, the only available sage binary for Ubuntu is the last LTS. - Moreover, the Ubuntu Sage binary we get from the Sage repository needs some additional packages (libgfortran3 for example). The solution of such a problem is not as easy when you have to go to some cyber-cafe to download a package and hope that is will be the last missing one (Sage tells you about another dependency only when the previous one is satisfied), especially when the university is far from downtown. - The compilation of the Ubuntu Sage binary was made on some recent hardware, at least the sse2 set of instructions is needed whereas some Pentium 3 do not know sse2 instructions. As explained by Nicolas, requiring a build which is able to run on a Pentium 3 is overkill if participants bring their laptops, it is not the case if you plan to work on a local computer room (the one of ISEA had 1/3 Pentium 3 and 2/3 Pentium 4). A possible reason for this sse2 dependency may be the following bug of the atlas package: if you set SAGE_FAT_BINARY='yes', the architecture will be Hammer (why such a choice ?), without taking the SAGE_ATLAS_ARCH variable in consideration, and atlas won't run on Pentium 3. See http://trac.sagemath.org/sage_trac/ticket/13706 - Installing GNU/Linux on the participants machines is dangerous. Participants do not have backups. Because of a problem of gparted to understand correctly windows extended partition system (at least in november 2011, gparted attributed the labels of 7 extended partitions of one participants above the four primary partitions uncorrectly, letting you erase the wrong primary partition), because we didn't have enough backup space to backup the whole disk, and because we were tired after one week of workshop, we lost the personal data (in particular some important latex files) of one participant, and spend one week at trying to recover some data between the new Linux filesystem and sage binaries. = Workarounds to still distribute sage despite all those problems = As Nicolas explained, you should consider a multiple strategies approach. Here are the remaining realistic ones. I started a wiki page with the following text to help future sage-days organisers, don't hesitate to update it : http://wiki.sagemath.org/HowToSpreadSageDuringAWorkshop == The autoclone USB live == I built a live Debian Sage USB key wich is able to clone itself on another key, indefinitely. I will make the prototype (and the source code) available when i will be back home with a good internet connection. Other features of the key are : personal data persistence, no personal data is duplicated, possibility for the user to share additional data from her key to the cloned one (pdf lecture notes, worksheets, pictures of the workshop,...), lot of softwares (geogebra, latex, editors, gimp, vlc, libreoffice,... there is no need to be small since the bandwith limit is the size of the key). If you have 200 euros to spend, buy one USB key of >= 4GB for each participant plus 10% to saturate the market (some people will have to bring one back to their boss/friend/other). Build a few keys and let the participants clone the other keys (it takes about 16 minutes per key times the logarithm of the number of participants, which is much faster than building each one by yourself in linear time, moreover they will learn how to do it when going back in their university). == Minimal Autonomous Sage Build ("batteries included ?") == To sage binary maintainers: please reconsider having libgfortran distributed with the binaries. Some problems also appeared with openssl. We definitely need to maintain a build that is able to run on any GNU/Linux distro (no dependency except libc6) and old hardware (no sse2). I can help in such a task since i consider it much more important than maintaining many distro-specific builds (8 builds for OSX, 5 for Linux x64). === Server side === It is do-able. Here is an attempt of describing how i did (partially): - build a minimal live Debian system (with only build-essential gfortran m4 binutils openssl libssl-dev) - run it on a real Pentium 3 (using qemu is much slower) - add some swap (using mkswap and swapon) since the build of the html reference manual costs a lot of RAM (about 1GB) and may not be built otherwise. - export variables SAGE_FAT_BINARY='yes' SAGE_ATLAS_ARCH='PIII' SAGE_BINARY_BUILD='yes' - modify atlas spkg according to the track ticket #13706 (or wait until it is fixed). - run make (takes about 19 hours) - copy /usr/lib/libbgfortran.so.3* and /usr/lib/libcrypto.* and /usr/lib/libssl.so* in the ${SAGE_ROOT}/local/lib/ directory - run sage -bdist and md5sum I guess it shouldn't be hard to distribute imagemagick dvipng ffmpeg in the sage binaries as well. === Client side === This will be possibly harder. Concerning the browser java stuff, i do not know how to let the browser know how to pick a jre which is located in the sage binaries. Maybe we should build a firefox extension that installs the equivalent of default-jre and icedtea6-plugin in a portable way ? No idea for howto do this. == GNU/Linux + Sage install == Some participants will want to have GNU/Linux installed on their machine. Unlike Nicolas, i consider this as a long-term saving time point if we want not having to consider windows-related problems in the future. The participants will want GNU/Linux to be installed (as dual boot) on their laptop only at the end of the workshop (this happened both this year and last year), once they are convinced than GNU/Linux beats Windows everywhere :) If you plan to help in installing GNU/Linux, ask the participants to apply earlier, some installs take more time than planned. Bring huge empty haddisks (> 1TB). Participants won't have backup. Backup the whole filesystem (or even the whole device), not only the interesting files, windows has some strange capabilities. dd is your best friend. If you have to resize a windows ntfs partitions (for dual boot): - boot on windows - defragment the disk - run checkdisk - reboot on a live GNU/Linux CD/USB - resize the partitions (e.g. with gparted) - reboot on windows to let it know the sizes have changed - reboot on your GNU/Linux installer and start the install Bring the install binaries of some recent distro (the one you are used to), and all the necessary to make upgrades and to install missing dependencies without internet connection (you must get prepared to wait for 3 hours for a 22MB download, or even to have no internet connection at all). Bring both a USB and a CD of the installer (some computer are not able to boot on USB). If you use a Debian-based distro, apt-cacher will be helping a lot for the upgrades and the installation of missing dependencies offline. Note that by default apt-cacher only caches the packages, not the headers (they change with time). Those headers look small but are big if the internet connection is weak. If you have no internet connection, modify the expire_hours variable in /etc/apt-cacher/apt-cacher.conf to something bigger than the number of hours that are remaining until the end of the sage days, and run a full upgrade from a place with a good internet connection to fill the cache. Bring sage sources a well as the autonomous binary. == Serve a notebook on a LAN == Bring a powerful computer and a wifi router to be able to serve a notebook for the remaining people for which previous solutions did not work (bios not able to boot on USB, participants not willing to install Linux on their machine). Unless you have a very strong server, it is usually not enough for all participants. Ciao, Thierry On Tue, Nov 13, 2012 at 05:23:11AM -0800, Mike Zabrocki wrote: > >I could hope for 4-5 that will use Sage in the long run, and 20 that > > definitely see the point but will get stuck by lack of infrastructure > > and expertise. > These sound like great numbers. > > >> 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. > > > Well, I have a good contact for that: dad :-) We actually already used > > Sage on our home OLPC, although only through a remote Sage server. I > > I just mentioned OLPC because that was an organization I had heard of. > I didn't know your dad was associated, but what an awesome contact to > have. > > I don't yet see how to overcome infrastructure problems. > I would summarize my experience as: > 1. don't use the internet (you can't count on it anyway) > 2. most computers have some old version of Windows > 3. a few students will have their own laptops > 4. Most students will have little or no computer experience > 5. Most want to learn computers and see the point, a few choose to be > luddites and can afford to because the infrastructure is so unreliable > > > Of course, the real thing would be to integrate a resource-optimized > > version of Sage within the Sugar activities. This probably won't be a > > priority for OLPC, since their main target population is children of > > age 6-12, but as you say we could explore other organizations as well. > > At the events I have been involved with, our highest priority was to > minimize the infrastructure difficulties. AIMS in South Africa sounds > like it might be a good place to organize an event since you could > potentially rely on computer access. > > -Mike > > On Monday, 12 November 2012 04:52:27 UTC-5, Nicolas M. Thiery wrote: > > > > On Sun, Nov 11, 2012 at 08:07:06PM -0800, Mike Zabrocki wrote: > > > Wow! Nicolas fantastic report. That was a challenge to do. > > > > Thanks :-) > > > > > 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 could hope for 4-5 that will use Sage in the long run, and 20 that > > definitely see the point but will get stuck by lack of infrastructure > > and expertise. > > > > But as you said: �if our problem was only network, we were in pretty > > good shape to start with�. We had a selection of students that were > > definitely computer-literate (somehow, the main difficulty was to > > prevent them from running to facebook&all and eat up all the bandwidth > > whenever the network was working :-) ), even though most did not have > > programming experience. > > > > > 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. > > > > Well, I have a good contact for that: dad :-) We actually already used > > Sage on our home OLPC, although only through a remote Sage server. I > > doubt the old models can support running Sage locally, but for the > > upcoming models we certainly will have a shot (at least running in a > > terminal). > > > > Of course, the real thing would be to integrate a resource-optimized > > version of Sage within the Sugar activities. This probably won't be a > > priority for OLPC, since their main target population is children of > > age 6-12, but as you say we could explore other organizations as well. > > > > 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. > > -- 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.
