Intel vient de faire un nouveau pas vers les utilisateurs de systèmes d'exploitations libres, en donnant un accès public aux spécifications complètes (y compris en ce qui concerne l'accélération 2D et 3D et les fonctionnalités d'accélération de l'encodage/décodage multimédia) de leurs chipsets vidéos récents (965 et G35, c'est-à-dire tout ce qui utilise les puces GMA X3000 et plus : autrement dit, tout ce qui arrive sur le marché depuis à peu près un an).

Intel se chargeait déjà de développer et fournir aux utilisateurs d'X.org un pilote libre et pleinement fonctionnel (ils ont embauché à cette fin la fine fleur des développeurs X.org : http://www.intellinuxgraphics.org/team.html), mais ne diffusait pas de documentations publiques et sans NDA permettant à d'autres développeurs non affiliés de participer aisément au développement ou de corriger des anomalies. Ces spécifications sont placés sous la licence CC-By-ND, non libre, mais qui nous garanti la disponibilité publique et le droit de rediffuser ces documents. La documentation n'est donc pas entachée de NDA.

Par ailleurs, des développeurs Intel ont lancé, il y a deux semaines, un appel à la communauté invitant les utilisateurs d'X.org possédant un chipset graphique Intel à se joindre à leur programme de test des pilotes (ps : dépêchez-vous, la sortie de la version 2.2.1 du pilote, celle qui sera probablement intégrée dans les prochaines versions de Fedora et Ubuntu, est imminente et nous sommes plus particulièrement invités à trouver et signaler les anomalies rapidement).

Rappelons qu'AMD/ATI a aussi entamé une démarche de fond pour mettre les spécifications de ses produits - ou une partie de celles-ci - à disposition des développeurs (tout n'est pas encore disponible), et pour aider au développement d'un pilote libre pour ses produits récents (pilote encore très jeune). Nvidia n'a pas entamé de démarche de documentation ou libération des pilotes, et mérite de brûler aux enfers avec des bananes plantés dans les narines.

Les spécifications : http://www.x.org/docs/intel/
L'annonce officielle : http://www.intellinuxgraphics.org/

Intel Graphics Media Accelerator : http://en.wikipedia.org/wiki/Intel_GMA
Community Testing Members : http://www.intellinuxgraphics.org/community_members.html
xf86-video-intel 2.2.1 release testing : http://lists.freedesktop.org/archives/xorg/2008-January/0321(...)
Call for community testers for intel driver : http://lists.freedesktop.org/archives/xorg/2008-January/0319(...)

> Lire le journal (17 commentaires, moyenne: 4,6).

Serait-ce l'un des premiers bénéfices de la nouvelle orientation d'Intel en faveur de Linux pour leur solutions mobiles ?
Arjan van de Ven, développeur chez Intel, vient d'annoncer la sortie d'un outil permettant d'identifier les applications et pilotes Linux les plus gourmands en énergie de façon très simple et lisible : PowerTOP liste ces mauvais citoyens en ordre décroissant, à la façon de l'utilitaire top(1). Il indique aussi le nombre d'éveils des processeurs par seconde et une estimation de la consommation actuelle en watt. Très user friendly, l'outil affiche même des conseils d'amélioration en fonction de votre configuration noyau (par exemple il recommande, si ce n'est déjà fait, d'activer NO_HZ, CONFIG_USB_SUSPEND, CONFIG_HPET et CONFIG_CPU_FREQ_GOV_ONDEMAND mais de désactiver CONFIG_IRQBALANCE et CONFIG_ACPI_DEBUG). Pas besoin d'être un développeur chevronné donc : tout utilisateur de GNU/Linux doté d'un PC portable devrait pouvoir utiliser cet outil (en revanche, il faut penser à signaler aux développeurs les problèmes de consommation d'énergie que cela permet de découvrir dans leurs logiciels ;).

Un noyau 2.6.21 (ou plus récent) est nécessaire au fonctionnement de PowerTOP, car celui-ci intègre le support des dynticks / tickless idle développé par Ingo Molnar et Thomas Gleixner. Cette fonctionnalité, à activer avec la nouvelle option de configuration CONFIG_NO_HZ, évite au noyau de s'éveiller hz fois par seconde s'il n'a rien à faire. PowerTOP devrait être utilisable sur les processeurs x86 non-Intel, quoique certaines informations (en particulier les informations remontées par l'ACPI concernant les C-states des CPUs) ne seront accessibles qu'avec les processeurs Intel dits « mobiles » (processeurs pour les portables).

PowerTOP détermine ces informations sur la consommation électrique en identifiant les applications et les pilotes qui « réveillent » le noyau (donc les CPUs) très fréquement (par exemple lorsqu'on utilise une mauvaise API pour surveiller un fichier, un répertoire, un changement d'heure, la connexion d'un périphérique USB, un changement de configuration réseau, lorsqu'un pilote est sollicité en permanence par des nuées d'IRQ, ...) ou les application qui réveillent régulièrement le noyau pendant trop longtemps. En effet, les fonctionnalités ACPI d'économie d'énergie ne sont réellement effectives que lorsque le noyau maintient les processeurs dans un des états (C-state) de repos (C3, ou mieux, C4) ; toute application qui sollicite le noyau très fréquemment (par un appel système par exemple) - même pour une tache très simple, rapide, sans gros calculs - conduit les CPUs à basculer en mode « non économique » (C-states C0 ou C1). L'ajout d'une fonctionnalité permettant d'identifier les applications les plus consommatrices d'accès disques (très gourmands en énergie) est envisagée.

Pour les développeurs, et de de façon plus synthétique : si votre application surveille (en anglais « poll », « monitor », ...) en permanence le système pour être avertie de changements d'états potentiels (par exemple l'arrivée de données dans un répertoire ou sur une socket) il est préférable d'utiliser les API (comme select(2), poll(2) et inotify(7)) permettant d'attendre passivement que le noyau la prévienne lorsque c'est utile plutôt que de réveiller le noyau plusieurs fois par seconde en vérifiant depuis l'application si le changement a eu lieu. Il convient aussi de regrouper autant que possible les lectures ou écritures sur le disque dur.

Voila quelques exemples (plutôt centrés sur le bureau Gnome) de problèmes déjà découverts - et en général, patchés - pour l'essentiel par les développeurs d'Intel :

• Certaines options du noyau ont une influence considérable (voir les recommandation indiquées plus haut).


• Certains logiciels se révèlent très gourmands, et réveillent le noyau des centaines, voir des milliers de fois par secondes alors que des solutions alternatives existent. Firefox, Evolution, gnome-power-manager, gaim (maintenant appelé Pidgin), ntpd (celui de ntp.org, pas openntpd, qui est mieux ;), dhcdbd, le mixer_applet2 de gnome, les pilotes intel i915 et ipw2100, les pilote appletouch (pour les macs) et ibm_acpi se sont révélés être de très grands consommateurs de ressources. Intel a écrit un patch dans la plupart des cas.


• L'utilisation des graphismes 3D est souvent très gourmande (il faut donc éviter Beryl/Compiz lorsque son portable tourne sur batterie et qu'on veut économiser de l'énergie).


• Une simple animation persistante dans le navigateur web force xorg à se réveiller régulièrement. Plus intéressant : le curseur clignotant (blinking cursor) du terminal gnome réveille xorg très souvent, même lorsque le terminal n'a pas le focus ou lorsqu'il est en arrière plan. Vous pouvez désactiver ce clignotement à partir des options de configuration de gnome-terminal.


• Sur un macbook, on gagne une heure d'autonomie lorsqu'on décharge le module uhci_hcd (note : ce module est nécessaire pour avoir le support du clavier, mais ça donne une indication utile pour les développeurs).

Voila. À nous de jouer maintenant : avec cet outil nous pouvons très facilement repérer les gros consommateurs de ressources (pilotes et logiciels) sur nos distributions, avec notre matériel/pilotes, nos logiciels et nos configurations préférés. Apparemment les développeurs d'Intel ne se sont pas penchés sur le bureau KDE. Il serait aussi intéressant de voir l'influence de certaines options de configuration d'xorg et de comparer les divers pilotes (par ex. "ati" vs. "radeon" vs. "fglrx" ou bien "nv" vs. "nouveau" vs. "nvidia", et l'impact de leurs options de configuration respectives comme Composite, EnablePageFlip, etc.) par exemple. N'oubliez pas : pour que les résultats soient pertinents, il faut faire tourner PowerTOP avec un noyau 2.6.21 ou plus, activer CONFIG_NO_HZ, et ne pas brancher le portable sur le secteur (tourner sur la batterie).

Il nous faut remonter les problèmes dans les bugstrackers des logiciels et distributions concernés. Il y aura ainsi de fortes chances pour que les prochaines versions de nos distributions nous apportent quelques heures d'autonomie supplémentaires sur nos portables ou PDA (« plusieurs heures » est un objectif à portée de main, il me semble, si l'on considère aussi que ces distributions incluront un 2.6.21+ avec « dynticks », voir un 2.6.23 avec les corrections pour hal, et peut-être les patchs d'Intel) :)

• Le site de PowerTOP : http://www.linuxpowertop.org/


• Explications sur son fonctionnement : http://www.linuxpowertop.org/powertop.php


• Problèmes déja découverts (firefox, gaim, ...), conseils divers et patchs proposés : http://www.linuxpowertop.org/known.php


• La liste de diffusion de PowerTOP : http://www.bughost.org/pipermail/power/2007-May/thread.html . Voir aussi le canal IRC #powertop sur the irc.oftc.net.


• L'annonce sur LKML (la liste de diffusion des développeurs du noyau linux) : http://lkml.org/lkml/2007/5/11/365 (voir aussi les messages concernant uhci_hcd sur les macbooks http://lkml.org/lkml/2007/5/12/223 ou des problèmes avec hal http://lkml.org/lkml/2007/5/12/149 ).


• Quelques liens montrant la suractivité actuelle d'Intel pour développer des plateformes mobiles basées sur Linux : http://softwarecommunity.intel.com/articles/eng/1093.htm , http://www.intel.com/pressroom/archive/releases/20070417supp(...) , https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007(...) , http://www.mobilelinuxinfo.com/278/intel-to-push-linux-based(...) .


• Plus d'information sur la nouvelle fonctionalité « dynticks » du noyau 2.6.21 : http://lwn.net/Articles/223185/ et http://kerneltrap.org/node/7749


• Les C-states et l'ACPI sur les processeurs mobiles Intel : http://www.intel.com/technology/itj/2006/volume10issue02/art(...)

À vos portables ! ;)

> Lire le journal (30 commentaires, moyenne: 3,3).

Lors du 5th USENIX Conference on File and Storage Technologies (FAST '07) qui s'est déroulé du 12 au 16 février 2007 à San Jose (en Californie), deux passionnantes analyses statistiques sur la fiabilité des disques durs ont étés présentées, par une équipe de chercheurs de Google d'un coté, et par une équipe de chercheurs de l'université Carnegie Mellon de l'autre. Ces deux études ont étés élaborées à partir des données recueillies sur de très larges échantillons de disques (plus de 100 000 unités dans les deux cas) en condition d'utilisation réelle (ce ne sont pas des tests de laboratoire). Ce sont les premières analyses publiées qui soient basées sur des échantillon de cette envergure.

Ces nouvelles études mettent à mal quelques idées reçues bien ancrées, par exemple :

* Les températures de fonctionnement auparavant considérées comme trop élevées (40 - 45°C) ne sont pas un facteur de panne déterminant.
* Les (très onéreux) disques SCSI et FC ne sont pas plus fiables que les disques SATA (bons marchés)
* La « mortalité infantile » (le fait que les disques tombent en panne durant les premiers mois) n'est pas un phénomène significatif.
* Les données remontées par S.M.A.R.T. permettent très rarement d'anticiper une panne prochaine.
* La probabilité pour que deux disques d'un même système / lot tombent en panne dans un laps de temps court (par exemple avant que l'array RAID soit reconstruite) est très importante.
* Le taux d'activité des disques n'affecte pas significativement leur longévité

Mais des secrets de polichinelle ont été confirmés :

* La fiabilité des disques varie selon les constructeurs (Google ne cite pas de noms)
* La fiabilité des disques (MTTF/MTBF) indiquées officiellement par les constructeurs (par ex. 1 000 000 heures) est très largement sur-évaluée.

Ainsi l'étude de Bianca Schroeder conduit à décrédibiliser le RAID5 dans son rôle d'agent critique pour la fiabilité du stockage, et à préconiser, en lieu et place du RAID5, et lorsque la fiabilité est cruciale, une double réplication des données. Google, dont l'infrastructure de stockage s'appuie sur le système de fichier distribué GFS et sur des disques SATA et PATA (plutôt que SCSI) semble confirmer par la pratique cette recommandation inédite.

Je saisi l'occasion pour faire une remarque militante. Nous savons maintenant qu'un jeux de replicats sur 3 disques durs SATA est plus fiable qu'un système RAID5 matériel en SCSI. Nous savions déjà que cette première option était bien meilleur marché. En outre, le contrôleur RAID physique est lui-même un point individuel de défaillance. Et surtout, les logiciels nécessaires (firmware (micro-code) de la carte, pilotes, outils de gestion à chaud (online management)) ajoutent leurs lots de bugs, d'autant plus critiques que les constructeurs se montrent réticent à rendre les spécifications et les listes de bugs des firmwares publiques. Ces informations faciliteraient l'écriture, l'amélioration, l'audit, et la maintenance des pilotes pour les OS libres (par exemple : connaître en détail les bugs des diverses versions des firmwares permettrait aux pilotes de les contourner) ; elles permettraient l'écriture d'outils libres de gestion à chaud du contrôleur RAID matériel (outils qui nous font généralement cruellement défaut (pensez à Adaptec, par exemple)). L'attractivité des contrôleurs RAID matériels en environnement serveur est donc fortement remise en cause (du moins lorsque la fiabilité prime sur les performances), mais les fabriquants de chipsets ont les cartes en main pour améliorer la situation pour l'ensemble des Unix libres (comme Linux, *BSD et OpenSolaris).

Notons que le 2007 Linux Storage & Filesystem Workshop s'est déroulé conjointement au FAST '07. Nous aurons certainement prochainement des informations sur les nouveaux enjeux et perspectives concernant l'évolution des systèmes de fichiers de Linux.

* FAST '07 : http://db.usenix.org/events/fast07/
* Failure Trends in a Large Disk Drive Population, Eduardo Pinheiro, Wolf-Dietrich Weber and Luiz Andr´ Barroso (Google Inc.) : http://labs.google.com/papers/disk_failures.pdf
* Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?, Bianca Schroeder, Garth A. Gibson (Computer Science Department Carnegie Mellon University) : http://www.usenix.org/events/fast07/tech/schroeder/schroeder(...)
* Spécifications matérielles: Theo de Raadt appelle de nouveau au lobbying : http://linuxfr.org/2005/03/19/18549.html
* S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) : http://fr.wikipedia.org/wiki/Self-Monitoring%2C_Analysis_and(...)
* MTTF (Mean Time To Failure) et MTBF, (Mean Time Between Failures): http://fr.wikipedia.org/wiki/Moyenne_des_Temps_de_Bon_Foncti(...)
* RAID (Redundant Array of Inexpensive Disks) : http://fr.wikipedia.org/wiki/RAID_%28informatique%29
* SCSI (Small Computer System Interface) : http://fr.wikipedia.org/wiki/Small_Computer_System_Interface
* SATA (Serial ATA) : http://fr.wikipedia.org/wiki/Serial_ATA
* FC (Fibre Channel) : http://fr.wikipedia.org/wiki/Fibre_Channel

> Lire le journal (18 commentaires, moyenne: 3,4).

Un chercheur français du DCSSI, Loïc Duflot, à récemment publié un papier[1] sur un trou de sécurité dans l'architecture même de x.org, faille suffisante pour circonvenir les protections habituelles (type SELinux, GRsecurity etc).

La description du problème est assez complexe mais securityfocus a publié une interview de Duflot très éclairante[2] : il s'agit de profiter de l'accès direct (sans passer par le noyau), par X11, a certaines fonctionnalités des processeurs x86 pour pouvoir détourner les flux logiciels, et exécuter du code à l'insu du noyau (et de ses éventuelles couches de protections).

Les développeurs x.org, pour l'essentiel payés par les distributions commerciales, sont-ils trop occupés à coder des environnement 3D ? ont-ils peur de casser la compatibilité avec les pilotes propriétaires (ATI / nVidia, qui sont maintenant nécessaire pour vendre des distribution commerciales), comme le suppose Theo de Raadt [3][4]? Ce qui est certain, c'est que les patches permettant la séparation des privilèges (réduire le nombre de lignes tournant en root dans x.org) développées par OpenBSD n'ont pas été intégrées par l'équipe d'x.org.

Quoiqu'il en soit, nous allons certainement garder notre trou dans le X pendant quelques années: visiblement, personne chez x.org n'a décidé de régler ce problème (qui requiert, tout de même, un refactoring complet !). Moralité, mais tout le monde le sait, n'installez pas de serveur X11 sur vos serveurs en production. Où n'utilisez pas l'architecture i386.

[1] Papier de Loïc Duflot
http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest20(...)
[2] Interview de Loïc Duflot http://www.securityfocus.com/columnists/402
[3][4] Les commentaires peu diplomatiques de Theo de Raadt sur le sujet:
http://marc.theaimsgroup.com/?l=openbsd-misc&m=114738577(...)
http://marc.theaimsgroup.com/?l=openbsd-misc&m=114233317(...)

> Lire le journal (85 commentaires, moyenne: 4,3).