Pour pouvoir candidater à un poste de Maître de Conférences (MdC), il convient d'être qualifié. Pour ce faire, il faut envoyer un dossier de qualification avant la date limite de la session de qualification de l'année en cours (le calendrier est disponible sur le site du ministère). Les deux points importants sont (i) le respect du calendrier et (ii) la constitution du dossier. Le tout est régi par le texte de loi en vigueur pour l'année en cours. Pour 2010, c'était celui-ci mais attention, il est mis à jour tous les ans. Il y a plusieurs étapes dans le calendrier:

1. Ouverture du serveur Galaxie: généralement vers mi-septembre. Il faut s'y enregistrer, noter précieusement son mot de passe, sinon c'est la galère et remplir les formulaires (situation, état-civil, thèse etc.). Les inscriptions sont cloturées à peu près un mois plus tard (courant/fin octobre). Attention, les jours précédant la deadline le serveur est souvent en rade. Attention aussi au décalage horaire si vous faites un post-doc à l'étranger.
2. Mise en ligne des rapporteurs sur le site : environs deux semaine après la clôture des inscriptions le nom et l'addresse de contact des rapporteurs (deux personnes) sont mis en ligne.
3. Date limite de soutenance : traditionnellement vers la mi-décembre. Il faut avoir soutenu sa thèse avant cette date (c'est-à dire que le procès verbal de soutenance doit être signé et daté au plus tard à cette date) pour prétendre à la qualification.
4. Date limite d'envoi des dossiers : 2 ou 3 jours après la date limite de soutenance. Juste le temps de souffler après la soutenance, de faire signer son PV de soutenance par tout le monde et d'envoyer. Encore une fois pour les post-doc à l'étranger le cachet de la poste fait foi, il convient donc d'envoyer le dossier avec l'équivalent d'un accusé de réception où la date d'envoi figure clairement.

Pour ce qui est du dossier, les pièces absolument nécessaires sont données sur le site du ministère. Attention, pour certaines sections il faut fournir des pièces supplémentaires qui ne sont pas mentionnées dans le texte de loi (il n'y en a pas pour la section 27-Informatique). Il faut au minimum mettre dans le dossier:

1. La déclaration de candidature signée: il faut l'imprimer depuis le portail galaxie, la signer et la joindre au dossier. C'est indispensable et malheureusement pas bien indiqué.
2. Un CV mentionnant le parcours et fonctions assurées
3. Copie du diplôme de doctorat (ou attestation)
4. Copie des rapports de pré-soutenance de thèse (i.e. les rapports des rapporteurs. C'est quelque chose d'officieux apparemment. Il n'est pas demandé officiellement mais c'est très important).
5. Copie du rapport de soutenance de thèse
6. Descriptif des activités d'enseignement, motivations. Joindre aussi un justificatif (normalement le département où vous avez enseigné vous fournit un justificatif avec le nombre d'heures et matières où vous êtes intervenus).
7. Descriptif des thèmes de recherche et des résultats
8. Liste des publications (si vous les avez mettez quelques indications bibliométriques, telles que le taux de sélection pour la conf par exemple)
9. Exemplaire de travaux, ouvrages ou articles
10. Descriptif des charges collectives assumées. Tout ce que vous avez fait sans que ce soit de l'enseignement ou de la recherche (par exemple faire partie de la commission web de votre labo etc.).
11. Recommandations, attestations et/ou avis de responsables et collègues. Pour les qualifs ce n'est pas important d'en avoir des tonnes mais disont celle de votre directeur de thèse ou de post-doc, plus celles de collègues avec qui vous avez enseignés. Elles sont beaucoup plus importantes pour les candidatures MdC.

Il est conseillé de prendre contact avec ses rapporteurs avant d'envoyer le dossier pour voir si la liste ci-dessus est satisfaisante. En particulier, il n'est souvent pas nécessaire de mettre un exemplaire de la thèse dans le dossier mais la laisser à disposition en ligne (avec l'url figurant dans le dossier papier). Même si seul le dossier papier compte, il est aussi recommandé d'envoyer le dossier sous forme éléctronique aux rapporteurs. Dernier point, la qualification est valable 4 ans. Il est aussi possible d'obtenir communication du rapport en cas de non-qualification et de faire un recours après le deuxième échec.

The Sony VAIO TZ150 is a nifty laptop (or at least that was the case at the time I bought it). Its reasonably fast (and I switched the CD-RW drive with an SSD), slick, battery life is amazing (the original battery can get me around 4 to 5 hours without wireless, 3 hours with despite being 3 years old). The real problem however is in the software. While the BIOS is a standard phoenix bios, sony added a proprietary menu giving only access to a handfull of options (boot device order, activate TCPA, alarm, password protect bios and so on). In particular, switching the VT-x bit of the CPU is disabled by default and not accessible through the menu. Ditto for the AHCI hard drive settings. With the VT-x bit disabled, you can kiss goodbye to running virtual box/kvm/xen at a decent speed. After hours (days) of playing around, I found not only a way to activate it but found a dump of all the settings available. To change a setting, you can proceed as follows.

1. Create a bootable DOS drive, for instance a usb stick with the FreeDOS operating system.
2. Download the SYMCMOS.EXE program. It's a small utility by Phoenix (and I think it is only semi-official, most of the flags are undocumented). Copy it on the usb stick.
3. Reboot your vaio on the usb stick. Once you get the prompt from FreeDOS, run the SYMCMOS.EXE program as so:

   SYMCMOS -v2 -lnvram.txt

   This will give you a file nvram.txt with the value of the bios settings for each valid offset. The file looks like that:

   ( SYMBOLIC CMOS EDITOR - Version 643710-035 )

CRC = 250F
(0000) [0001]
(0003) [0000]
(0006) [0001]
(0009) [0000]
(000C) [0001]
(000F) [0001]
(0018) [0000]
(001B) [0001]
...


4. Modify the file to put the value you want at the correct offset (modify the value between brackets). You might need to reboot on your regular OS to edit the file on your key.
5. Copy the modify file on your usb stick and reboot under FreeDOS. You can now upload the new settings on the nvram by doing:

   SYMCMOS.EXE -v2 -unvram.exe

   You should reboot right after that.
6. Now of course the big question is, what value for which offset ? Well the answer is here. For instance you see that on my model, putting [0001] at the offset 0x363 enables the VT-x feature.

This is just a small tutorial explaining how to obtain the symbolic table of a Phoenix bios, even though the settings might be hidden by the computer manufacturer (in my case Sony). First things first, you need to get ahold of the ROM file. Usually it is hidden inside a self extracting/patching windows executable. In my case the file is called R0052N7.WPH and it was conveninently left in the temp directory of the windows installation (I ran the installer with wine) once the installer bailed realized it was not being run on the original Windows of the sony vaio. We need to use a small unix utility called phnxdeco. The project seem dead but the program is available through the Debian/Ubuntu repositories. As a side note, the program is buggy if compiled for 64bit architectures (the author used long instead of int in a few places). No worries, just get the 32bit executable which will run like a charm on an amd64 (Linux) system. First, let's check that the file is indeed a Phoenix Bios:

phnxdeco R005N7.WPH -l

This should printout some general information (offset of the start of the BIOS, size, …) as well as a list of the different modules/sections wihtin this BIOS file. Now it is time to extract the modules that we want:

phnxdeco R005N7.WPH -xs

This will create a bunch of .rom files containing the code of various sections. We are interested in two of them: STRINGS0.rom and TEMPLATE0.rom. STRINGS0.rom contains all the strings used in the stock BIOS menu (the one from Phoenix). TEMPLATE0.rom contains the menu structure (top-level menu, submenu) and pointers to the text labels in STRINGS0.rom. Copy these files on your FreeDOS usb stick, renaming TEMPLATE0.rom to NODES.rom and STRING0.rom to STRINGS.rom (since it's a FAT16 filesystem, case does not matter). Reboot under FreeDOS. Run SYMCMOS.EXE from the same directory as the .rom files:

SYMCMOS.EXE -V2 -C

This creates a file COMBINE.rom which can then be used to create a symbolic dump of the bios structure and current settings:

SYMCMOS.EXE -V2 -FCOMBINE.ROM -SSYMBOLS.TXT

(note that there is no space between the -F/-S options and the filenames). If everything goes as planned, you get a nice symbolic dump of your bios settings, similar to this one. You can now use it to change various settings using the usual method and brick and destroy your computer to your heart's content.

To create bold small capitals (small capitals are used to typeset surnames in French for instance, and Section titles are in bold in default latex styles), you can do the following:

% in the preamble
...
\usepackage{extra-bold}
...
\begin{document}
...
\textsc{\textbf{Foo}}
...

I assume you have a fairly recent Texlive distribution (such as the one comming with Ubuntu Natty or subsequent releases). Say you have a bunch of TrueType fonts (with .ttf extension) that you want to use in LaTeX. I'll use as a running example the Ubuntu*.ttf located in /usr/share/fonts/truetype/ubuntu-font-family. Follow these steps:

$ mkdir /tmp/foo
$ cp *.ttf /tmp/foo
$ autoinst - - encodings=OT1,T1,T5 *.ttf
# You can specify different encodings, refer to the autoinst manual
$ for i in *.map; do
echo Map "$i".map >> ~/.texmf-config/updmap.d/customfonts.cfg
done
# Make sure that this directory exists
$ mkdir ~/texmf/tex/latex/fontname/
# Replace fontname with the name of your font, here Ubuntu
# The name is not important though it's just to keep each font package
# in its own directory
$ cp *.sty *.map *.fd ~/texmf/tex/latex/fontname
$ mktexlsr ~/texmf
$ update-updmap
$ updmap
# Enjoy. To use a font, just \usepackage{foo} where foo.sty was one
# of the generated .sty that you have copied into your texmf tree
# you can remove the temporary directory
$ cd; rm -rf /tmp/foo


When dealing with arrays, typical code might look like this:
int * tab = malloc(sizeof(int)*10000); int i; for(i = 0; i < 10000; i++) tab[i] = 0; // do something with the array This linear initialization might be prohibitive (either from a theoretical point of view, when computing the complexity of an algorithm or from a practical point of view, if few cells of the array end up being used in the end). A folklore technique to deal with this (at the cost of 3 times the memory use), documented in:

• A. Aho, J. Hopcroft, and J. Ullman. The design and analysis of computer algorithms. Addison-Wesley, 1974. (Ex. 2.12, page 71)
• K. Mehlhorn. Data Structures and Algorithms 1: Sorting and Searching. EATCS Monographs on Theoretical Computer Science. Springer-Verlag, 1984. (Section III.8.1)

is the following: typedef struct _array { int * data; // the actual data unsigned int * set; // auxiliary array 1 unsigned int * back; // auxiliary array 2 unsigned int current; // number of initialized cells unsigned int length; // total length } array; // we don't check the return value of malloc for clarity array * create(unsigned int length) { array * a = malloc(sizeof(array)); a->data = malloc(sizeof(int) * length); a->set = malloc(sizeof(unsigned int) * length); a->back = malloc(sizeof(unsigned int) * length); a->current = 0; a->length = length; return a; } //assumes 0 <= idx < a->length int get(array * a, unsigned int idx, int * found){ int bidx = a->set[idx]; if (bidx >= a->current || a->back[bidx] != idx) { *found = 0; return 0; } else { *found = 1; return a->data[idx]; }; } //assumes 0 <= idx < a->length void set(array * a, unsigned int idx, int val){ int bidx = a->set[idx]; if (bidx > a->current || a->back[bidx] != idx) { //cell has never been set, intialize it: a->set[idx] = a->current; a->back[a->current] = idx; a->current++; }; a->data[idx] = val; return; } What's going on here ? Initially, the three arrays (data, set and back) contain some garbage, that is, random integers. First let's see what happens if we try to read one cell of this array structure, say cell 100.

1. we retrieve a->set[100] which is some random value x
2. since x is an unsigned int, it is larger than a->current (which is 0) and therefore we return, without accessing any data.

Now let's put something in cell 100:

1. Doing the same test as before, we see that cell 100 is not initialized, so we put a->current (which is 0) in a->set[100]
2. Then we put 100 in a->back[0]
3. Then we increment a->current
4. Lastly we set a->data[100] to some value

Now, when we access again cell 100 to get its content, the condition a->set[100] >= a->current does not hold, since a->set[100] is 0 and a->current is 1. The second also does not hold since a->back[0] points back to cell 100. We know therefore that cell 100 has already been set to some value and that it is safe to read it.

Now if we try to read cell 101 (which is uninitialized) two things may occur:

1. It contains something different than 0, in which case it is >= a->current
2. It contains 0. We then read a->back[0] but then we see that it points back to 100 and not 101, and therefore we know that the 0 in a->set[101] is just garbage