I'm glad to announce that we have the current release of
Theano (0.8.2) in Debian unstable now, it's on its way into the testing branch and the Debian derivatives, heading for Debian 9.
The
Debian package is maintained in behalf of the Debian Science Team.
We have a binary package with the modules in the Python 2.7 import path (python-theano), if you want or need to stick to that branch a little longer (as a matter of fact, in the current
popcon stats it's the most installed package), and a package running on the default Python 3 version (python3-theano).
The comprehensive
documentation is available for offline usage in another binary package (theano-doc).
Although Theano builds its extensions on run time and therefore all binary packages contain the same code, the source package generates arch specific packages
for the reason that the exhaustive test suite could run over all the architectures to detect if there are problems somewhere (
#824116).
what's this?
In a nutshell, Theano is a computer algebra system (CAS) and expression compiler, which is implemented in Python as a library.
It is named after a Classical Greek female mathematician and it's developed at the LISA lab (located at MILA, the Montreal Institute for Learning Algorithms) at the Universit de Montr al.
Theano tightly integrates multi-dimensional arrays (N-dimensional, ND-array) from NumPy (
numpy.ndarray), which are broadly used in Scientific Python for the representation of numeric data.
It features a declarative Python based language with symbolic operations for the functional definition of mathematical expressions, which allows to create functions that compute values for them.
Internally the expressions are represented as directed graphs with nodes for variables and operations.
The internal compiler then optimizes those graphs for stability and speed and then generates high-performance native machine code to evaluate resp. compute these mathematical expressions
.
One of the main features of Theano is that it's capable to compute also on GPU processors (graphical processor unit), like on custom graphic cards (e.g. the developers are using a GeForce GTX Titan X for benchmarks).
Today's GPUs became very powerful parallel floating point devices which can be employed also for scientific computations instead of 3D video games
.
The acronym "GPGPU" (general purpose graphical processor unit) refers to special cards like NVIDIA's Tesla
, which could be used alike (more on that below).
Thus, Theano is a high-performance number cruncher with an own computing engine which could be used for large-scale scientific computations.
If you haven't came across Theano as a Pythonistic professional mathematician, it's also one of the most prevalent frameworks for implementing deep learning applications (training multi-layered, "deep" artificial neural networks, DNN) around
, and has been developed with a focus on machine learning from the ground up.
There are several higher level user interfaces build in the top of Theano (for DNN, Keras, Lasagne, Blocks, and others, or for Python probalistic programming, PyMC3).
I'll seek for some of them also becoming available in Debian, too.
helper scripts
Both binary packages ship three convenience scripts,
theano-cache,
theano-test, and
theano-nose.
Instead of them being copied into
/usr/bin, which would result into a
binaries-have-conflict violation, the scripts are to be found in
/usr/share/python-theano (python3-theano respectively), so that both module packages of Theano can be installed at the same time.
The scripts could be run directly from these folders, e.g. do
$ python /usr/share/python-theano/theano-nose to achieve that.
If you're going to heavy use them, you could add the directory of the flavour you prefer (Python 2 or Python 3) to the
$PATH environment variable manually by either typing e.g.
$ export PATH=/usr/share/python-theano:$PATH on the prompt, or save that line into
~/.bashrc.
Manpages aren't available for these little helper scripts
, but you could always get info on what they do and which arguments they accept by invoking them with the
-h (for
theano-nose) resp.
help flag (for
theano-cache).
running the tests
On some occasions you might want to run the testsuite of the installed library, like to check over if everything runs fine on your GPU hardware.
There are two different ways to run the tests (anyway you need to have
python ,3 -nose installed).
One is, you could launch the test suite by doing
$ python -c 'import theano; theano.test() (or the same with
python3 to test the other flavour), that's the same what the helper script
theano-test does.
However, by doing it that way some particular tests might fail by raising errors also for the group of known failures.
Known failures are excluded from being errors if you run the tests by
theano-nose, which is a wrapper around nosetests, so this might be always the better choice.
You can run this convenience script with the option
--theano on the installed library, or from the source package root, which you could pull by
$ sudo apt-get source theano (there you have also the option to use
bin/theano-nose).
The script accept options for nosetests, so you might run it with
-v to increase verbosity.
For the tests the configuration switch
config.device must be set to
cpu.
This will also include the GPU tests when a proper accessible device is detected, so that's a little misleading in the sense of it doesn't mean "run everything on the CPU".
You're on the safe side if you run it always like this:
$ THEANO_FLAGS=device=cpu theano-nose, if you've set
config.device to
gpu in your
~/.theanorc.
Depending on the available hardware and the used BLAS implementation (see below) it could take quite a long time to run the whole test suite through, on the Core-i5 in my laptop that takes around an hour even excluded the GPU related tests (which perform pretty fast, though).
Theano features a couple of switches to manipulate the default configuration for optimization and compilation.
There is a rivalry between optimization and compilation costs against performance of the test suite, and it turned out the test suite performs a quicker with lesser graph optimization.
There are two different switches available to control
config.optimizer, the
fast_run toggles maximal
optimization, while
fast_compile runs only a minimal set of graph optimization features.
These settings are used by the general
mode switches for
config.mode, which is either
FAST_RUN by default, or
FAST_COMPILE.
The default mode
FAST_RUN (optimizer=fast_run, linker=cvm) needs around 72 minutes on my lower mid-level machine (on un-optimized BLAS).
To set
mode=FAST_COMPILE (optimizer=fast_compile, linker=py) brings some boost for the performance of the test suite because it runs the whole suite in 46 minutes.
The downside of that is that C code compilation is disabled in this mode by using the linker
py, and also the GPU related tests are not included.
I've played around with using the optimizer
fast_compile with some of the other linkers (
c py and
cvm, and their versions without garbage collection) as alternative to
FAST_COMPILE with minimal optimization but also machine code compilation incl. GPU testing.
But to my experience,
fast_compile without another than the linker
py results in some new errors and failures of some tests on amd64, and this might the case also on other architectures, too.
By the way, another useful feature is
DebugMode for
config.mode, which verifies the correctness of all optimizations and compares the C to Python results.
If you want to have detailed info on the configuration settings of Theano, do
$ python -c 'import theano; print theano.config' less, and check out the chapter
config in the library documentation in the documentation.
cache maintenance
Theano isn't a JIT (just-in-time) compiler like Numba, which generates native machine code in the memory and executes it immediately, but it saves the generated native machine code into
compiledirs.
The reason for doing it that way is quite practical like the docs explain, the persistent cache on disk makes it possible to avoid generating code for the same operation, and to avoid compiling again when different operations generate the same code.
The compiledirs by default are located within
$(HOME)/.theano/.
After some time the folder becomes quite large, and might look something like this:
$ ls ~/.theano
compiledir_Linux-4.5--amd64-x86_64-with-debian-stretch-sid--2.7.11+-64
compiledir_Linux-4.5--amd64-x86_64-with-debian-stretch-sid--2.7.12-64
compiledir_Linux-4.5--amd64-x86_64-with-debian-stretch-sid--2.7.12rc1-64
compiledir_Linux-4.5--amd64-x86_64-with-debian-stretch-sid--3.5.1+-64
compiledir_Linux-4.5--amd64-x86_64-with-debian-stretch-sid--3.5.2-64
compiledir_Linux-4.5--amd64-x86_64-with-debian-stretch-sid--3.5.2rc1-64
If the used Python version changed like in this example you might to want to purge obsolete cache.
For working with the cache resp. the compiledirs, the helper
theano-cache comes in handy.
If you invoke it without any arguments the current cache location is put out like
~/.theano/compiledir_Linux-4.5--amd64-x86_64-with-debian-stretch-sid--2.7.12-64 (the script is run from
/usr/share/python-theano).
So, the compiledirs for the old Python versions in this example (11+ and 12rc1) can be removed to free the space they occupy.
All compiledirs resp. cache directories meaning the whole cache could be erased by
$ theano-cache basecompiledir purge, the effect is the same as by performing
$ rm -rf ~/.theano.
You might want to do that e.g. if you're using different hardware, like when you got yourself another graphics card.
Or habitual from time to time when the compiledirs fill up so much that it slows down processing with the harddisk being very busy all the time, if you don't have an SSD drive available.
For example, the disk space of build chroots carrying (mainly) the tests completely compiled through on default Python 2 and Python 3 consumes around 1.3 GB (see
here).
BLAS implementations
Theano needs a level 3 implementation of
BLAS (Basic Linear Algebra Subprograms) for operations between vectors (one-dimensional mathematical objects) and matrices (two-dimensional objects) carried out on the CPU.
NumPy is already build on BLAS and pulls the standard implementation (libblas3, soure package: lapack), but Theano links directly to it instead of using NumPy as intermediate layer to reduce the computational overhead.
For this, Theano needs development headers and the binary packages pull libblas-dev by default, if any other development package of another BLAS
implementation (like OpenBLAS or ATLAS) isn't already installed, or pulled with them (providing the virtual package
libblas.so).
The linker flags could be manipulated directly through the configuration switch
config.blas.ldflags, which is by default set to
-L/usr/lib -lblas -lblas.
By the way, if you set it to an empty value, Theano falls back to using BLAS through NumPy, if you want to have that for some reason.
On Debian, there is a very convenient way to switch between BLAS implementations by the alternatives mechanism.
If you have several alternative implementations installed at the same time, you can switch from one to another easily by just doing:
$ sudo update-alternatives --config libblas.so
There are 3 choices for the alternative libblas.so (providing /usr/lib/libblas.so).
Selection Path Priority Status
------------------------------------------------------------
* 0 /usr/lib/openblas-base/libblas.so 40 auto mode
1 /usr/lib/atlas-base/atlas/libblas.so 35 manual mode
2 /usr/lib/libblas/libblas.so 10 manual mode
3 /usr/lib/openblas-base/libblas.so 40 manual mode
Press <enter> to keep the current choice[*], or type selection number:
The implementations are performing differently on different hardware, so you might want to take the time to compare which one does it best on your processor (the other packages are libatlas-base-dev and libopenblas-dev), and choose that to optimize your system.
If you want to squeeze out all which is in there for carrying out Theano's computations on the CPU, another option is to compile an optimized version of a BLAS library especially for your processor.
I'm going to write another blog posting on this issue.
The binary packages of Theano ship the script
check_blas.py to check over how well a BLAS implementation performs with it, and if everything works right.
That script is located in the
misc subfolder of the library, you could locate it by doing
$ dpkg -L python-theano grep check_blas (or for the package python3-theano accordingly), and run it with the Python interpreter.
By default the scripts puts out a lot of info like a huge perfomance comparison reference table, the current setting of
blas.ldflags, the compiledir, the setting of
floatX, OS information, the GCC version, the current NumPy config towards BLAS, NumPy location and version, if Theano linked directly or has used the NumPy binding, and finally and most important, the execution time.
If just the execution time for quick perfomance comparisons is needed this script could be invoked with
-q.
Theano on CUDA
The function compiler of Theano works with alternative backends to carry out the computations, like the ones for graphics cards.
Currently, there are two different backends for GPU processing available, one docks onto NVIDIA's CUDA (Compute Unified Device Architecture) technology
, and another one for
libgpuarray, which is also developed by the Theano developers in parallel.
The
libgpuarray library is an interesting alternative for Theano, it's a GPU tensor (multi-dimensional mathematical object) array written in C with Python bindings based on Cython, which has the advantage of running also on OpenCL
.
OpenCL, unlike CUDA
, is full free software, vendor neutral and overcomes the limitation of the CUDA toolkit being only available for amd64 and the ppc64el port (see
here).
I've opened an
ITP on libgpuarray and we'll see if and how this works out.
Another reason for it would be great to have it available is that it looks like CUDA currently runs into problems with GCC 6
.
More on that, soon.
Here's a litle checklist for setting up your CUDA device so that you don't have to experience something like this:
$ THEANO_FLAGS=device=gpu,floatX=float32 python ./cat_dog_classifier.py
WARNING (theano.sandbox.cuda): CUDA is installed, but device gpu is not available (error: Unable to get the number of gpus available: no CUDA-capable device is detected)
hardware check
For running Theano on CUDA you need an NVIDIA graphics card which is capable of doing that.
You can recheck if your device is supported by CUDA
here.
When the hardware isn't too old (CUDA support started with GeForce 8 and Quadro X series) or too strange I think it isn't working only in exceptional cases.
You can check your model and if the device is present in the system on the bare hardware level by doing this:
$ lspci grep -i nvidia
04:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940M] (rev a2)
If a line like this doesn't get returned, your device most probably is broken, or not properly connected (ouch).
If
rev ff appears at the end of the line that means the device is off meaning powered down.
This might be happening if you have a laptop with Optimus graphics hardware, and the related drivers have switched off the unoccupied device to safe energy
.
kernel module
Running CUDA applications requires the proprietary
NVIDIA driver kernel module to be loaded into the kernel and working.
If you haven't already installed it for another purpose, the NVIDIA driver and the CUDA toolkit are both in the non-free section of the Debian archive, which is not enabled by default.
To get non-free packages you have to add
non-free (and it's better to do so, also
contrib) to your package source in
/etc/apt/sources.list, which might then look like this:
deb http://httpredir.debian.org/debian/ testing main contrib non-free
After doing that, perform
$ apt-cache update to update the package lists, and there you go with the non-free packages.
The headers of the running kernel are needed to compile modules, you can get them together with the NVIDIA kernel module package by running:
$ sudo apt-get install linux-headers-$(uname -r) nvidia-kernel-dkms build-essential
DKMS will then build the NVIDIA module for the kernel and does some other things on the system.
When the installation has finished, it's generally advised to reboot the system completely.
troubleshooting
If you have problems with the CUDA device, it's advised to verify if the following things concerning the NVIDIA driver resp. kernel module are in order:
blacklist nouveau
Check if the default Nouveau kernel module driver (which blocks the NVIDIA module) for some reason still gets loaded by doing
$ lsmod grep nouveau.
If nothing gets returned, that's right.
If it's still in the kernel, just add
blacklist nouveau to
/etc/modprobe.d/blacklist.conf, and update the booting ramdisk with
sudo update-initramfs -u afterwards.
Then reboot once more, this shouldn't be the case then anymore.
rebuild kernel module
To fix it when the module haven't been properly compiled for some reason you could trigger a rebuild of the NVIDIA kernel module with
$ sudo dpkg-reconfigure nvidia-kernel-dkms.
When you're about to send your hardware in to repair because everything looks all right but the device just isn't working, that really could help (own experience).
After the rebuild of the module or modules (if you have a few kernel packages installed) has completed, you could recheck if the module really is available by running:
$ sudo modinfo nvidia-current
filename: /lib/modules/4.4.0-1-amd64/updates/dkms/nvidia-current.ko
alias: char-major-195-*
version: 352.79
supported: external
license: NVIDIA
alias: pci:v000010DEd00000E00sv*sd*bc04sc80i00*
alias: pci:v000010DEd*sv*sd*bc03sc02i00*
alias: pci:v000010DEd*sv*sd*bc03sc00i00*
depends: drm
vermagic: 4.4.0-1-amd64 SMP mod_unload modversions
parm: NVreg_Mobile:int
It should be something similiar to this when everything is all right.
reload kernel module
When there are problems with the GPU, maybe the kernel module isn't properly loaded.
You could recheck if the module has been properly loaded by doing
$ lsmod grep nvidia
nvidia_uvm 73728 0
nvidia 8540160 1 nvidia_uvm
drm 356352 7 i915,drm_kms_helper,nvidia
The kernel module could be loaded resp. reloaded with
$ sudo nvidia-modprobe (that tool is from the package nvidia-modprobe).
unsupported graphics card
Be sure that you graphics cards is supported by the current driver kernel module.
If you have bought new hardware, that's quite possible to come out being a problem.
You can get the version of the current NVIDIA driver with:
$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module 352.79 Wed Jan 13 16:17:53 PST 2016
GCC version: gcc version 5.3.1 20160528 (Debian 5.3.1-21)
Then, google the version number like
nvidia 352.79, this should get you onto an official driver download page
like this.
There, check for what's to be found under "Supported Products".
I you're stuck with that there are two options, to wait until the driver in Debian got updated, or replace it with the latest driver package from NVIDIA.
That's possible to do, but something more for experienced users.
occupied graphics card
The CUDA driver cannot work while the graphical interface is busy like by processing the graphical display of your X.Org server.
Which kernel driver actually is used to process the desktop could be examined by this command:
$ grep '(II).*([0-9]):' /var/log/Xorg.0.log
[ 37.700] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20150522
[ 37.700] (II) intel(0): SNA compiled: xserver-xorg-video-intel 2:2.99.917-2 (Vincent Cheng <vcheng@debian.org>)
...
[ 39.808] (II) intel(0): switch to mode 1920x1080@60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none
[ 39.810] (II) intel(0): Setting screen physical size to 508 x 285
[ 67.576] (II) intel(0): EDID vendor "CMN", prod id 5941
[ 67.576] (II) intel(0): Printing DDC gathered Modelines:
[ 67.576] (II) intel(0): Modeline "1920x1080"x0.0 152.84 1920 1968 2000 2250 1080 1083 1088 1132 -hsync -vsync (67.9 kHz eP)
This example shows that the rendering of the desktop is performed by the graphical device of the Intel CPU, which is just like it's needed for running CUDA applications on your NVIDIA graphics card, if you don't have another one.
nvidia-cuda-toolkit
With the
Debian package of the CUDA toolkit everything pretty much runs out of the box for Theano.
Just install it with
apt-get, and you're ready to go, the CUDA backend is the default one.
Pycuda is also a suggested dependency of the binary packages, it could be pulled together with the CUDA toolkit.
The up-to-date CUDA release 7.5 is of course available, with that you have Maxwell architecture support so that you can run Theano on e.g. a GeForce GTX Titan X with 6,2 TFLOPS on single precision
at an affordable price.
CUDA 8
is
around the corner with support for the new Pascal architecture
.
Like the GeForce GTX 1080 high-end gaming graphics card already has 8,23 TFLOPS
.
When it comes to professional GPGPU hardware like the Tesla P100 there is much more computational power available, scalable by multiplication of cores resp. cards up to genuine little supercomputers which fit on a desk, like the DGX-1
.
Theano can use multiple GPUs for calculations to work with highly scaled hardware, I'll write another blog post on this issue.
Theano on the GPU
It's not difficult to run
Theano on the GPU.
Only single precision floating point numbers (float32) are supported on the GPU, but that is sufficient for deep learning applications.
Theano uses double precision floats (float64) by default, so you have to set the configuration variable
config.floatX to
float32, like written on above, either with the
THEANO_FLAGS environment variable or better in your
.theanorc file, if you're going to use the GPU a lot.
Switching to the GPU actually happens with the
config.device configuration variable, which must be set to either
gpu or
gpu0,
gpu1 etc., to choose a particular one if multiple devices are available.
Here's is a little test script
check1.py, it's taken from the docs and slightly altered.
You can run that script either with
python or
python3 (there was a single test failure on the Python 3 package, so the Python 2 library might be a little more stable currently).
For comparison, here's an example on how it perfoms on my hardware, one time on the CPU, one more time on the GPU:
$ THEANO_FLAGS=floatX=float32 python ./check1.py
[Elemwise exp,no_inplace (<TensorType(float32, vector)>)]
Looping 1000 times took 4.481719 seconds
Result is [ 1.23178029 1.61879337 1.52278066 ..., 2.20771813 2.29967761
1.62323284]
Used the cpu
$ THEANO_FLAGS=floatX=float32,device=gpu python ./check1.py
Using gpu device 0: GeForce 940M (CNMeM is disabled, cuDNN not available)
[GpuElemwise exp,no_inplace (<CudaNdarrayType(float32, vector)>), HostFromGpu(GpuElemwise exp,no_inplace .0)]
Looping 1000 times took 1.164906 seconds
Result is [ 1.23178029 1.61879349 1.52278066 ..., 2.20771813 2.29967761
1.62323296]
Used the gpu
If you got a result like this you're ready to go with Theano on Debian, training computer vision classifiers or whatever you want to do with it.
I'll write more on for what Theano could be used, soon.
PocketCHIP is the pocket sized
Linux terminal I always used to want. Which is to say, it runs (nearly)
stock Debian, X, etc, it has a physical keyboard, and the hardware and
software is (nearly) non-proprietary and very hackable. Best of all, it's
fun and it encourages playful learning.
It's also clunky and flawed and constructed out of cheap components.
This keeps it from being something I'd actually carry around in my pocket
and use regularly. The smart thing they've done though is embrace these
limitations, targeting it at the hobbiest, and not trying to compete with
smart phones. The PocketCHIP is its own little device in its own little
niche.
Unless you're into hardware hacking and want to hook wires up to the GPIO
pins, the best hardware feature is the complete keyboard, with even
Escape and Control and arrow keys. You can ssh around and run vi on it,
run your favorite REPL (I use ghci) to do quick programming, etc.
The keyboard is small and a little strange, but you get used
to it quickly; your QWERTY muscle memory is transferrable to it.
I had fun installing nethack on it and handing it to my sister who
had never played nethack before, to watch her learn to play.
The screen resolution is 480x272, which is pretty tiny. And, it's a cheap
resistive touchscreen, with a bezil around it. This makes it very hard to
use scroll bars and icons near the edge of the screen. The customized
interface that ships with it avoids these problems, and so I've been using
that for now. When I have time, I plan to put a fullscreen window
manager on it, and write a pdmenu menu configuration for it, so
everything can be driven using the keyboard.
I also have not installed Debian from scratch on it yet. This would be
tricky because it uses a somewhat patched kernel (to support the display
and wifi). The shipped distribution is sadly not entirely free software.
There are some nonfree drivers and firmwares. And, they included a non-free
gaming environment on it (a very nice one for part of the audience, that
allows editing the games, but non-free nevertheless). They did do a good
job of packaging up all the custom software they include on it, although
they don't seem to have
published source packages for everything.
(They might be infringing my GPL copyright of flash-kernel by distributing
a modified version without source. I say "might" because flash-kernel is
a pile of shell scripts, so you could probably extract the (probably
trivial) modifications. Still.. Also, they seem to have patched
network-manager in some way and I wasn't able to find the corresponding source.)
The battery life is around 5 hours. Unfortunately the "sleep" mode only
turns off the backlight and maybe wifi, and leaves the rest of the system
running. This and the slightly awkward form factor too big to really
comfortably fit in a pocket limit the use of PocketCHIP quite a bit.
Perhaps the sleeping will get sorted out, and perhaps I'll delete the GPIO
breakout board from the top of mine to make it more pocket sized.
Talks have been finished, and as a special present to the participants, Pavneet has organized an excursion that probably was one of the best I ever had. First we visited the 
During the ceremony, Pavneet also announced the winners of the 
Excellent life music in a bit schick/sophisticated atmosphere was a good finish for this excellent day. With Herb from MacTeX and his wife we killed two bottles of red wine, before slowly tingling back to the hotel.
A great finishing day of talks.
I have a long overdue blog entry about what happened in recent times. People that follow 
After the closing of the session, one part of our group went off to the baseball match, while another group dived into a Japanese-style Izakaya where we managed to kill huge amounts of sake and quite an amount of food. The photo shows me after the first bottle of sake, while just seeping on an intermediate small amount of genshu (kind of strong undiluted sake) before continuing to the next bottle.
An interesting and stimulating first day of TUG, and I am sure that everyone was looking forward to day 2.
Version 0.0.5 of 
But then we also like to confirm the bugs are really gone, which (atm) requires manual
checking, and to look for the words "reproducible" and "deterministic"
(and spelling variations) in debian/changelogs of all uploads, to spot reproducible work
not tracked via the BTS.
And we still need to catch up on the backlog of weekly reports.
Bugs submitted with reproducible usertags
It seems 
If that wasn't all bad enough, now there is a new threat: while you are relaxing in the sun, scammers fool your phone company into issuing a replacement SIM card or transferring your mobile number to a new provider and then proceed to use it to take over all your email, social media, Paypal and bank accounts. The same scam has been appearing around the globe, from 
For phone companies, SMS messaging came as a side-effect of digital communications for mobile handsets. It is less than one percent of their business. SMS authentication is less than one percent of that. Phone companies lose little or nothing when SMS messages are hijacked so there is little incentive for them to secure it. Nonetheless, like insects riding on an elephant, numerous companies have popped up with a business model that involves linking websites to the wholesale telephone network and dressing it up as a "security" solution. These companies are able to make eye-watering profits by "purchasing" text messages for $0.01 and selling them for $0.02 (one hundred percent gross profit), but they also have nothing to lose when SIM cards are hijacked and therefore minimal incentive to take any responsibility.
Companies like Google, Facebook and Twitter have thrown more fuel on the fire by encouraging and sometimes even demanding users provide mobile phone numbers to "prove they are human" or "protect" their accounts. Through these antics, these high profile companies have given a vast percentage of the population a false sense of confidence in codes delivered by mobile phone, yet the real motivation for these companies does not appear to be security at all: they have worked out that the mobile phone number is the holy grail in cross-referencing vast databases of users and customers from different sources for all sorts of creepy purposes. As most of their services don't involve any financial activity, they have little to lose if accounts are compromised and everything to gain by accurately gathering mobile phone numbers from as many users as possible.
It has been often said that you should continually try new things in life so that
a. Unlike the fish you do not mistake the pond to be the sea.
b. You see other people, other types and ways of living and being which you normally won t in your day-to-day existence.
With both of those as mantras I decided to take a leap into the unknown. I was unsure both about the visa process as well as the travel bit as I was traveling to an unknown place and although I had done some research about the place I was unsure about the authenticity of whatever is/was shared on the web.
During the whole journey both to and fro, I couldn t sleep a wink. The Doha airport is huge. There are 5 Concourses, A, B , C, D, E and around 30+ gates in each Concourse. The ambition of the small state is something to be reckoned with. Almost 95% of the blue workers in the entire airport were of Asian sub-continent. While the Qatari Rial is 19 times stronger to us, the workers I suspect are worse-off than people doing similar things back home. Add to that the sharia law, even for all the money in the world, I wouldn t want to settle therein.
Anyways, during the journey, a small surprise awaited me, Ritesh Raj Saraff, a DD was also traveling to Debconf. We bumped into each other while going to see the Doha City, courtesy Al-Hamad International Airport. I would probably share a bit more about Doha and my experiences with the city in upcoming posts.
Cut to Cape Town, South Africa, we landed in the city half an hour after our scheduled time and then we sped along to University of Cape Town (UCT) which was to become our home for the next 13 odd days.
The first few days were a whirlwind as there were new people to meet, old people whom I knew only as an e-mail id or an IRC nickname turned out to be real people and you have to try to articulate yourself in English, which is not a native language of mine. During Debcamp I was fortunate to be able visit some of the places and the wiki page had a lot of places which I knew I wouldn t be able to complete unless I had 15 days unlimited time and money to go around so didn t even try.
I had gone with few goals in mind :-
a. Do some documentation of the event In this I failed completely as just the walk from the venue to where the talks were energy-draining for me. Apart from that, you get swept in meeting new people and talking about one of million topics in Debian which interest you or the other person and while they are fulfilling, it is and was both physically and emotionally draining for me (in a good way). Bernelle (one of the organizers) had warned us of this phenomenon but you disregard it as you know you have a limited time-frame in which to meet and greet people and it is all a over-whelming experience.
b. Another goal was to meet my Indian brethren who had left the country around 60~100 years mostly as slaves of East India company In this I was partially successful. I met a couple of beautiful ladies who had either a father or a mother who was Indian while the other was of African heritage. It seemed in them a yearning to know the culture but from what little they had, only Bollywood and Indian cuisine was what they could make of Indian culture. One of the girls, ummm women to be more truer, shared a somewhat grim tale. She had both an African boyfriend as well as Indian boyfriend in her life and in both cases, she was rejected by the boy s parents because she wasn t pure enough. This was deja vu all over again as the same thing can be seen here happening in casteism so there wasn t any advice I could give but just nod in empathy. What was sort of relevation was when their parents or grandparents came, the name and surnames were thrown off and the surname was just the place from where they belong. From the discussions it emerged that there were also lot of cases of forced conversions to Christianity during that era as well as temptations of a better life.
As shared, this goal succeeded partially, as I was actually interested in their parents or grand-parents to know the events that shaped the Indian diaspora over there. While the children know only of today, yester-years could only be known by those people who made the unwilling perilous journey to Africa. I had also wanted to know more about Gandhiji s role in that era but alas, that part of history would have to wait for another day as I guess, both those goals would only have met had I visited Durban but that was not to be.
I had applied for one talk My Experience with Debian and one workshop for Installation of Debian on systems. The My Experience with Debian was aimed at newbies and I had thought of using show-and-tell to share the differences between proprietary Operating Systems and a FOSS distribution such as Debian. I was going to take simple things such as changelogs, apt-listbugs, real-time knowledge of updates and upgrades as well as /etc/apt/sources.list to share both the versatility of the Debian desktop and real improvements than what proprietary Operating Systems had to offer. But I found myself engaging with Debian Developers (DD s) rather than the newbies so had to change the orientation and fundamentals of the talk on the fly. I knew or suspected rather that the old idea would not work as it would just be repeating to the choir. With that in the back of mind, and the idea that perhaps they would not be so aware of the politics and events which happened in India over the last couple of decades, I tried to share what little I was able to recollect what little I was able to remember about those times. Apart from that, I was also highly conscious that I had been given just the before lunch slot aka You are in the way of my lunch slot. So I knew I had to speak my piece as quickly as possible being as clear as can be. Later, I did get feedback that I was fast and seeing it through couple of times, do agree that I could have done a better job. What s done is done and the only thing I could do to salvage it a bit is to make a presentation which I am sharing as below.
I just published the videos from 
Of course, for me, the really interesting part here is near the end of the
chain, with 
(Unfortunately, I forgot to take a screenshot of Nageru itself during this
run.)
Solskogen was the first time I'd really used Nageru in production, and
despite super-extensive testing, there's always something that can go wrong.
And indeed there was: First of all, we discovered that the local Internet
line was reduced from 30/10 to 5/0.5 (which is, frankly, unusable for
streaming video), and after we'd half-way fixed that (we got it to
25/4 or so by prodding the ISP, of which we could reserve about 2 for
video demoscene content is really hard to encode, so I'd prefer a lot
more) Nageru started crashing.
It wasn't even crashes I understood anything of. Generally it seemed like the
NVIDIA drivers were returning GL_OUT_OF_MEMORY on things like creating
mipmaps; it's logical that they'd be allocating memory, but we had 6 GB of
GPU memory and 16 GB of CPU memory, and lots of it was free. (The PC we used for encoding was much,
much faster than what you need to run Nageru smoothly, so we had plenty of
CPU power left to run x264 in, although you can of course always want more.)
It seemed to be mostly related to zoom transitions, so I generally avoided
those and ran that night's compos in a more static fashion.
It wasn't until later that night (or morning, if you will) that I actually
understood the bug (through the godsend of the