La journée commence, (comme les autres jours d’ailleurs) par un petit déj à la cafétéria de la résidence, qui est, plutôt pas mal du tout, s’en suit une petite marche jusqu’au bâtiment où la conférence se tient, SITE.
Un petit passage au bureau d’enregistrement pour récupérer mon pack, (une sacoche, la facture, un petit carnet Google,) et je vais m’asseoir dans l’amphi ou va se tenir la welcome session où Dan Langille va nous faire rire.
Donc, Dan nous explique deux trois trucs sur ce qu’il à fait depuis l’année dernière, à savoir, déménager en Floride la semaine précédant BSDCan ’07, revenir pour organiser la conférence, retourner là bas après, et se faire licencier en juin. Passer l’été en Floride, puis bouger en Pennsylvanie. Comme il a un peu d’argent, il a décidé d’en donner un peu, ainsi qu’une invitation à vie à BSDCan pour qui réussirait à faire marcher Flash sur amd64, ainsi qu’un port d’Opera pour amd64. Comme à son habitude, on rigole bien, il fait quelques comptes, «qui est venu à toutes les BSDCan, à 4, à 3, à 2, qui est vierge», et la question piège, «qui n’est jamais venu», «qui habite dans le coin ou est venu en voiture», «qui vient de l’hémisphère sud.» Il raconte aussi quelques histoires sur le passage de la douane pour entrer sur le territoire Canadien, ce qu’il ne faut pas faire, ce qu’il ne faut surtout pas faire, et ce qui est bien de faire…
Suit ensuite Resource-limiting on the Virtual Private Server avec les
slides par Fred Clift de Verio/NTT, qui explique ce qu’ils ont
fait en terme de visualisation pour de l’hébergement avant que jail(8)
n’existe. Ça a l’air vraiment pas mal, avec plein de limitations a la rlimit,
mais en ajoutant des limites sur les IO disques, le réseau, les syscalls, etc…
Avec un système de burst avec un système assez complexe de calcul mais plutôt
efficace a postériori.
Maintenant, Pawel Jakub Dawidek, A closer look at the ZFS file system. Il
commence donc à éplucher ZFS comme un oignon, et nous explique, couche par
couche, qui sert à quoi, qui fait quoi, pourquoi, et pourquoi c’est une bonne
idée. S’en suit ensuite une explication de pourquoi RAID-Z est mieux que
RAID5/RAID6, une explication sur comment l’intégrité est assurée, une
explication sur les snapshots, sur comment la récupération des données
fonctionne forcément lorsqu’il y a une corruption. Pour terminer, il nous
montre ce qu’il à dans les tuyaux dans perforce, ce qui arrivera dans HEAD dès
qu’il aura fini ses jeux de tests. Suivent des questions, avec à chaque fois
des exemples «si on veux ajouter des disques ?», zpool create,
zpool add, et hop, c’est plus grand, «et si on veux remplacer les
disques par des plus gros ?», zpool create mirror / raidz, zpool replace, zpool export, zpool import, et hop, c’est plus grand. Et une
nouvelle salve d’applaudissement…
Après une pause déjeuner bien méritée, je vais aller écouter Poul Henning Kamp
nous parler de Measured (almost) does Air Traffic Control. Il nous parle
de la suite de la conf qu’il y a fait il y a deux ans sur l’embarqué dans
l’aviation danoise. C’est à dire la surveillance de transmetteurs d’aide à la
navigation (DME, VOR…). La surveillance est basée sur des NanoBSD avec FreeBSD
6.2, le démon MeasureD qui récupère des informations de plein de méthodes
différentes, et qui parlent via des ports séries aux différents équipements
(transmetteur, jauge du réservoir de carburant, état des batteries…) MeasureD
sait aussi multiplexer, c’est à dire qu’au centre de contrôle, il y a un
MeasureD qui va interroger les différents autres sites et qui garde les
données en local. Il y a un module pour
bsnmp(1)
qui parle à MeasureD.
Il y a aussi une interface X écrite en Tk pour l’affichage. Ensuite, il nous
montre ce qu’il à fait chez lui en mesurant un peu tout, jusqu’à mesurer les
variations du champ magnétique terrestre, avec des PIC qui ont plein de GPIO
et qui parlent même 1-Wire. Puis, il nous parle de FifoLog, un log circulaire,
de taille fixe, compressé, dans lequel on peut se promener par timestamp, et
qui est multiplexé, et qui sert à remplacer syslog dans ces équipements, parce
que lorsque le stockage qu’on à est une carte flash, c’est mieux de ne pas
écrire trop de choses trop souvent, et surtout, d’écrire un secteur entier à
la fois, même si il faut faire du bourrage pour le remplir. Tout ça me donne
des idées pour nos projets d’électronique.
Vient ensuite Rafał Jaworowski qui nous parle de
Porting FreeBSD/ARM to Marvell Orion System-On-a-Chip.
Il commence par nous faire une petite
historique sur ARM, une architecture RISC 32 bits, très populaire, qui a plein
d’incarnations différentes par plein de constructeurs, ainsi que ses origines
et qui nous vient d’Acorn Computers, Acorn RISC Machine → Advanced RISC
Machine → ARM Architecture. De cette diversité vient plusieurs groupes de CPU
qui viennent tous en plusieurs types, MMU, taille du cache, etc. De plus,
l’idée du SoC est d’avoir les périphériques (GPIO, Ethernet, PCI, UART, PCI,
USB, SATA, Crypto, SPI) intégrés à la puce qui contient le CPU. Vient ensuite
l’explication sur ce qu’il à fait, faire booter le CPU, gérer la RAM, faire
marcher les GPIO, le mbus qui est le bus interne, les drivers critiques,
timers, contrôleur d’interruptions, après ça, uart(4) et ehci(4)
fonctionnaient tout seuls en s’attachant sur le mbus. Je n’oserai pas en dire
plus, tout ce dont ça parle est un chouilla au dessus de mon niveau de
compétences, mais c’était intéressant à écouter.
Et pour terminer la journée avant d’aller boire un coup, Leslie Hawthorn qui est la responsable du programme Google Summer Of Code, nous parle étonnamment, de Google SoC. Ça change, une conf qui ne parle pas technique. Et, elle parle, elle parle, elle parle, plus vite que Robert Watson, c’est pour dire, et tout ça en machant un chewing gum… Elle nous parle donc du Summer Of Code, de comment ça a germé chez Google, de comment ils sont parti dans l’inconnu, et comment, en ayant prévu la première année 200 étudiants, ils ont finalement terminé à 400 parce que, ben, ils étaient tous très bon. Du fait qu’ils ont donné plus de 10 millions de dollars aux étudients et aux projets.
Et la journée est finie, on va pouvoir aller boire un coup, manger, et geeker dans le salon du troisième étage…