Linux France

LinuxFr.org propose des dépêches et articles, soumis potentiellement par vous, puis revus et corrigés par notre équipe avant publication. C'est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivi, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par mail, ou encore via médias sociaux.

Ce que l’on sait moins, c’est que LinuxFr.org vous propose également à tous de tenir vos propres articles directement publiables, sans validation a priori de notre part. Ceux-ci s'appellent des journaux.

Voici un florilège de journaux que l’on a pu lire. Ceux-ci sont les journaux qui ne sont pas passés en dépêche et les mieux notés par les utilisateurs… qui notent. Lumière sur ceux de la semaine passée, du 14 au 20 mai inclus.

• Le vote par internet, c'est encore mieux quand c'est bien fait… par maclag
• Conseil : Arrêtez d'utiliser Firefox dès aujourd'hui par yeKcim
• Shellshape : gnome-shell the geek way. par Enjolras
• Le code source de Symphony va fusionner avec OpenOffice par gnumdk
• Mandriva ou le GRR (Gag Rhétorique Récurrent) par alsaln
• La distribution Mandriva rendue à la communauté par IceCat

• lien n°1 : Collaborez à l'écriture d'un article
• lien n°2 : Écrivez votre journal
• lien n°3 : Soumettre une dépêche
• lien n°4 : Les journaux LinuxFr.org les mieux notés de la semaine 19/2012

Lire les commentaires

Nous avons le plaisir de vous annoncer la sortie de SPIP 3.0 ! Cette nouvelle version de SPIP (Système de Publication pour un Internet Partagé) vous permet toujours de publier du contenu pour internet et de créer des sites avec une grande facilité. De nombreuses évolutions facilitent son utilisation comme plate-forme de développement. En effet, Wikipédia indique que SPIP « se démarque d'un système de gestion de contenu classique par le soin apporté aux standards de l'édition (respect des règles typographiques, organisation des rôles des participants) […] et privilégie la simplicité d'installation, d'usage et de maintenance, […] ».

SPIP 3.0 s'est aussi nourri de l'activité de la communauté, et inaugure une tendance forte où l'avancée de SPIP est alimentée par les contributions de plugins sur SPIP-Zone.

• lien n°1 : L'annonce sur spip blog
• lien n°2 : Installer SPIP
• lien n°3 : Télécharger
• lien n°4 : Contribuer aux traductions
• lien n°5 : Détail de toutes les nouveautés de SPIP 3.0

Cette nouvelle version est marquée par :

• la réécriture complète de l’espace privé en squelettes qui a permis la mise en place de conventions et mécanismes qui facilitent grandement la création de nouveaux objets éditoriaux et la personnalisation des objets existants ;
• une forte modularité : le noyau a été découpé en 23 extensions (toutes distribuées avec SPIP) qui pourront avoir leurs cycles de vie et de développement propres, facilitant ainsi l'évolution et la maintenance de cette version ;
• une boucle DATA révolutionnaire qui permet de boucler sur tout type de données (CSV, XML, YAML, etc.) et aussi directement sur une URL distante : le Web devient votre base de données !

Elle intègre également de nombreuses autres nouveautés :

• un jeu de squelettes par défaut remanié en profondeur ;
• l'écran de sécurité installé en standard ;
• SVP, un outil pour l'installation et la mise à jour des plugins ;
• jQuery-UI intégré aux plugins fournis par défaut;
• le traitement des raccourcis pris en charge par le nouveau moteur TextWheel ;
• la mediabox et la médiathèque de documents intégrées par défaut ;
• SQLite complètement supporté comme gestionnaire de base ;
• une API généralisée de création de nouveaux objets ;
• les fonctionnalités AJAX des squelettes plus accessibles (ARIA) et qui préservent l'historique de navigation ;
• de nouveaux critères, filtres et balises ;
• etc.

Bonne installation et découverte !

PS: à noter deux points importants avec la sortie de cette version majeure :

• nous arrêtons la compatibilité avec PHP 4, la version minimum requise devient PHP 5.1.0
• le support de la branche SPIP 1.9.2 (et antérieures) n'est plus assuré : il n'y aura plus de mises à jour de sécurité pour cette branche. Nous vous invitons fortement à migrer vers une version plus récente : SPIP 2.1 ou SPIP 3.0.

Lire les commentaires

Après la période des forks hostiles ou encore intéressés, une consolidation de projets issus d'OpenOffice.org se dessine et l'annonce vient d'avoir lieu sur la liste de diffusion : le projet Symphony, géré par IBM, va fusionner avec OpenOffice.org qui est passé de la coupe de Sun à celle d'Oracle pour se retrouver actuellement dans les labs de la fondation Apache (pour devenir Apache OpenOffice).

Cela devrait permettre à OpenOffice de mettre à jour son interface graphique. En effet, une des caractéristiques de Symphony est son interface proche de ce que propose Calligra, à base de panneaux verticaux.

Reste désormais à voir ce que cela va donner et si OpenOffice peut se démarquer de LibreOffice via cette contribution. Chaque suite devrait maintenant évoluer franchement dans des directions différentes vis-à-vis de l'utilisateur, LibreOffice ayant son propre projet d'amélioration de l'interface nommé Citrus UI, ainsi qu'une version dans les nuages (aka Cloud) en chantier.

Côté licences, Apache OpenOffice (sous license Apache v2) ne peut reprendre le code de LibreOffice, alors que LibreOffice, sous double licence LGPLv3+ et MPLv2, peut quant à elle reprendre le code de Apache OpenOffice sous certaines conditions.

NdM : merci à gnumdk pour son journal et aux auteurs des commentaires afférents.

• lien n°1 : Journal à l'origine de la dépêche
• lien n°2 : L'annonce sur la liste de diffusion : [ANNOUNCE] IBM SGA/CCLA Submitted for Symphony Source Code Con
• lien n°3 : Article sur les contributions que cela apporte
• lien n°4 : L'évolution des projets de suite office libres

Lire les commentaires

Un apéro Python aura lieu à Lyon le 24 mai 2012 à partir de 19h à L'Antre Autre (11 rue terme, Lyon 1er). Cet apéro permettra aux passionnés de reptiles de se rencontrer et de discuter autour de ce langage informatique, de son écosystème et de pleins d'autres geekeriesinformations technologiques.

Une présentation éclair aura lieu sur SQLAlchemy et SqlSoup.

Venez nombreux !

• lien n°1 : Page de l'apéro
• lien n°2 : Site de l'Antre Autre
• lien n°3 : Plan d'accès
• lien n°4 : SQLAlchemy
• lien n°5 : SqlSoup

Lire les commentaires

Suite au succès du 16 mai dernier, Linux-Alpes vous donne rendez-vous pour une nouvelle soirée consacrée au logiciel libre, mercredi 20 juin 2012, à partir de 20h00, à Digne-les-Bains dans les locaux de Xsalto (quartier de l'ancien hôpital).

Nous présenterons des logiciels libres et gratuits pour votre ordinateur, comme le navigateur Firefox, le courrielleur Thunderbird ou encore la suite bureautique LibreOffice. La soirée est ouverte à tous, débutants, simples curieux ou déjà utilisateurs de logiciels libres et de GNU/Linux. Venez apprendre et/ou partager votre pratique. Si vous apportez votre ordinateur, les bénévoles vous aideront à installer GNU/Linux, un système d'exploitation libre et gratuit, performant et sécurisé.

• lien n°1 : Site web de Linux Alpes

Plan d'accès

La soirée du 16 mai dernier

Échanges autour des 4 libertés du logiciel libre

Lire les commentaires

La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.

Sommaire

• [LADEPECHE.fr] Législatives. Le Parti pirate s'amarre à la Prairie des Filtres
• [PC INpact] Fleur Pellerin à l'économie numérique, Aurélie Filippetti à la Culture
• [ZDNet.fr] L'Arcep ouvre sa consultation publique sur la neutralité du Net. Les opérateurs inquiets
• [LE FIGARO.fr] Acta : la neutralité du Net fragilisée à Bruxelles
• [écrans] VLC, le lecteur milliardaire
• [La gazette.fr] Open data : la transparence démocratique demeure virtuelle
• [Metamedia] Transferts de pouvoirs

• lien n°1 : April
• lien n°2 : Revue de presse de l'April
• lien n°3 : Revue de presse de la semaine précédente
• lien n°4 : podcast sur dogmazic
• lien n°5 : Divergence Numérique

[LADEPECHE.fr] Législatives. Le Parti pirate s'amarre à la Prairie des Filtres

Par T. Bl., le vendredi 18 mai 2012. Extrait:

Clin d'œil au nom de leur formation, les candidats du Parti pirate aux législatives dans le département organisaient hier un pique-nique sur les bords de la Garonne à la Prairie des Filtres.

Lien vers l'article original: http://www.ladepeche.fr/article/2012/05/18/1356160-le-parti-pirate-s-amarre-a-la-prairie-des-filtres.html

Et aussi:

• [01net.] Le Parti Pirate allemand remporte vingt sièges au parlement de Rhénanie du Nord - Westphalie

[PC INpact] Fleur Pellerin à l'économie numérique, Aurélie Filippetti à la Culture

Par Nil Sanyas, le mercredi 16 mai 2012. Extrait:

On ne se fera pas charmer pour autant Alors que le nom du premier ministre est officiellement connu depuis hier, ceux des ministres ont enfin été dévoilés il y a quelques minutes. Penchons-nous sur les deux ministres qui nous intéressent particulièrement.

Lien vers l'article original: http://www.pcinpact.com/news/70957-fleur-pellerin-numerique-aurelie-filippetti-culture.htm

Et aussi:

• [Silicon.fr] Fleur Pellerin, en charge de l'économie numérique

[ZDNet.fr] L'Arcep ouvre sa consultation publique sur la neutralité du Net. Les opérateurs inquiets

Par la rédaction, le mercredi 16 mai 2012. Extrait:

La consultation, qui se clôturera fin juin, est censée permettre au régulateur des télécoms de démystifier les relations entre opérateurs de réseau. Une décision qui ne plait pas à tous.

Lien vers l'article original: http://www.zdnet.fr/actualites/l-arcep-ouvre-sa-consultation-publique-sur-la-neutralite-du-net-les-operateurs-inquiets-39771796.htm

Et aussi:

• [Silicon.fr] La neutralité du Net fait loi aux Pays-Bas

[LE FIGARO.fr] Acta : la neutralité du Net fragilisée à Bruxelles

Par Marie-Catherine Beuth, le mercredi 16 mai 2012. Extrait:

L'esprit répressif du traité anticontrefaçon pourrait survivre à une non-ratification par le Parlement européen.

Lien vers l'article original: http://www.lefigaro.fr/hightech/2012/05/16/01007-20120516ARTFIG00698-acta-la-neutralite-du-net-fragilisee-a-bruxelles.php

Voir aussi: http://www.april.org/acta

[écrans] VLC, le lecteur milliardaire

Par Emilie Massemin, le lundi 14 mai 2012. Extrait:

Champagne sur le site de VideoLAN Bonne nouvelle pour le célèbre logiciel open-source VLC. Le fameux lecteur multimédia à l’icône en forme de cône de chantier, capable de lire un très grand nombre de formats audio et vidéo, a dépassé jeudi 10 mai le milliard de téléchargements — précisément 1,005 milliard, toutes versions et tous systèmes d’exploitation confondus.

Lien vers l'article original: http://www.ecrans.fr/VLC-le-lecteur-milliardaire,14676.html

[La gazette.fr] Open data : la transparence démocratique demeure virtuelle

Par S. Maréchal, le lundi 14 mai 2012. Extrait:

Les collectivités pionnières ont enclenché un mouvement irréversible, mais les effets de l’open data sur la transparence de l’action publique territoriale se font attendre. La culture de la donnée doit sortir du microcosme technologique pour intéresser les citoyens.

Lien vers l'article original: http://www.lagazettedescommunes.com/113394/open-data-la-transparence-democratique-demeure-virtuelle/

Et aussi:

• [ITRmanager.com] Facebook ou la défaillance de marché?

[Metamedia] Transferts de pouvoirs

Par Eric Scherer, le dimanche 13 mai 2012. Extrait :

Les Mayas avaient donc raison ! 2012 marque la fin d’un cycle et la disparition progressive d’un monde. Car « le basculement de pouvoirs le plus important à l’œuvre actuellement ne se passe pas entre l’Occident et l’Asie, les Etats-Unis et la Chine, le Nord et le Sud, la Droite et la Gauche, mais entre les institutions et les individus, grâce au numérique ».

Lien vers l'article original: http://meta-media.fr/2012/05/13/transferts-de-pouvoirs/

Lire les commentaires

Du 23 mai 12h au 29 mai 2012 12h, quelque 700 000 Français de l'étranger pourront voter par Internet pour les législatives (178 candidats pour 11 circonscriptions). Le Parti Pirate dénonce l'opacité et le manque de sécurité de la procédure de vote, qui pourraient remettre en question la sincérité du scrutin et le respect du secret du vote.

Des délégués des candidats du Parti Pirate ont assisté à la cérémonie officielle de génération des clés de l’urne électronique dédiée aux Français de l'étranger vendredi 18 mai. Ces délégués ont relevé plusieurs lacunes informatiques graves, ainsi que des problèmes de légitimité et de compétence des officiels censés contrôler la sécurité du scrutin.

C'est pourquoi le Parti Pirate propose à tous les citoyens de témoigner pour rapporter les incidents ou difficultés qu'ils auraient rencontrés.

Le code électoral prévoit que les délégués des candidats peuvent consigner dans le procès-verbal du Bureau de vote électronique leurs observations relatives aux opérations du vote par voie électronique.

Les délégués des candidats du Parti Pirate se chargeront de la consignation dans ce procès-verbal des problèmes qui leur seront signalés par les Français de l'étranger.

• lien n°1 : Appel à témoignage

700 000 personnes pourront voter par Internet, soit potentiellement l'équivalent des populations électorales de Marseille et Nantes jointes.

Les problèmes purement informatiques que le Parti Pirate a remarqué sont :

• Impossibilité d'avoir accès au code source des logiciels utilisés.
• Impossibilité d'avoir une quelconque garantie sur la version réellement utilisée des logiciels cités dans le protocole.
• Impossibilité de s'assurer de l'intégrité de la machine utilisée pour générer les clés verrouillant l'urne électronique.
• Impossibilité de tester la sécurité du serveur de vote qui serait mis en ligne sur Internet.

Il y a aussi un problème de légitimité des assesseurs :

• Pour les onze circonscriptions, dans lesquelles se présentent plus de dix partis et 178 candidats, seuls deux partis (dont le Parti Pirate) et cinq candidats étaient représentés pour observer la mise en place des procédures de sécurité.
• Les membres officiels du Bureau de vote électronique avaient une expertise technique limitée. Or, selon la loi, ils sont censés, lors de l'ensemble des opérations de vote électronique, contrôler les moyens mis en œuvre.
• Les logiciels utilisés ont été développés par des sous-traitants privés en dehors de tout contrôle citoyen ou étatique direct.

Enfin les ordinateurs individuels sont facilement attaquables. Il est donc tout à fait possible que certains se voient dépossédés de leur vote ou que le secret du vote soit violé.

Pour le Parti Pirate, tous ces soucis découlent du choix du vote électronique : le contrôle démocratique nécessaire à la légitimité des résultats électoraux ne peut être exercé que par des citoyens, pas uniquement par des machines ou des ingénieurs, et ce contrôle doit être accessible à chacun.

Si vous voulez voter par Internet et avez eu des problèmes, signalez-le nous !

Lire les commentaires

La sortie de la version stable 3.4 du noyau Linux vient d'être annoncée par Linus Torvalds. Le nouveau noyau est, comme d'habitude, téléchargeable sur les serveurs du site kernel.org.

Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche.

PS. : Merci à toutes les personnes qui ont aidé à traduire les courriels de RC quand cette dépêche était dans l'espace de rédaction: laurent wandrebeck, detail_pratique, khalahan, _PhiX_, Damien Szczyt, Akiel et Benoît.

• lien n°1 : LWN 1: Les nouveautés du noyau 3.4
• lien n°2 : LWN 2: Les nouveautés du noyau 3.4
• lien n°3 : LWN 3: Les nouveautés du noyau 3.4
• lien n°4 : Les nouveautés sur le site h-online

Sommaire

• La phase de test
  • RC-1
  • RC-2
  • RC-3
  • RC-4
  • RC-5
  • RC-6
  • RC-7
• Les nouveautés
  • Architecture x32
  • dm-verity
  • Nouveautés pour l'architecture ARM
  • YAMA
• En bref
  • Maturation de btrfs
  • Simplifications dans ext4
  • fadump pour PowerPC
  • UFS dans le noyau
  • Camellia et crc32
  • Discard pour « thin provisioning »
  • IRQ domains
  • Pilote virtio-scsi
  • Du côté de -staging
  • Pilote graphique Nouveau
  • Les autres pilotes graphiques
  • HSI
  • Sous-système remoteproc
  • Chargement retardé des pilotes
  • Améliorations dans Perf
• Statistiques

La phase de test RC-1

La version RC-1 a été annoncée par Linus le 31 mars 2012:

Ok, cela fait deux semaines et la période de merge est terminée. Linux 3.4-rc1 a été envoyé vers les serveurs git, et l'archive tar ainsi que les patches sont en cours d'envoi alors que je tape ceci (cela sera probablement terminé le temps que je finisse).
Et oui, si vous avez compté, cela ne fait que 13 jours. Et si certains attendaient le dernier jour pour envoyer leur demande de merge, je suis persuadé qu'ils seront vraiment ravis d'attendre deux mois supplémentaires jusqu'à la prochaine fenêtre d'intégration. Yay !

Cela dit, il y a encore quatre demandes de merge dans ma boîte mail qui sont en attente et que je vais (probablement) inclure, mais je voulais d'abord obtenir confirmation d'autres mainteneurs. Elles ont donc été envoyées dans les temps, j'ai juste décidé de faire le choix de leur intégration un peu plus tard.
Les quatre requêtes restantes (et les gens dont je veux des commentaires) sont :

- HSI (High Speed Synchronous Serial Interface). Je prévois de l'inclure dans le 3.4, c'est dans ma liste, mais je voulais que ça se sache au cas où quelqu'un aurait des problèmes avec cette dernière. Ping ?
- pohmelfs. Le vieux pohmelfs a été supprimé de staging ; il y en a un tout nouveau en attente sur le banc de touche. Al était un peu mécontent de certains aspects, Evgeniy en a corrigé certains, et la discussion s'est tarie. À nouveau, il y a des chances que je l'incorpore, mais je voulais davantage de commentaires à ce propos.
- La prise en charge préliminaire de drm dma-buf. Dave Airlie m'a envoyé la demande d'incorporation mais n'a pas beaucoup insisté, c'est dans ma catégorie « ok, je peux encore l'inclure pour 3.4 si les gens des pilotes DRM me disent que ça leur facilitera la vie. » C'est donc dans le flou — je n'ai rien contre, mais je ne l'inclurai pas à moins que quelques personnes me disent « oui, s'il te plaît. »
- Le framework DMA-mapping. Ce code a dorénavant quelques confirmations supplémentaires, et se trouve essentiellement dans la même situation que HSI : je l'incorporerai probablement, mais je voulais vraiment avoir l'avis des personnes concernées.

Et c'est tout. Il y a donc quatre demandes d'inclusion en attente, mais à part ça, c'est terminé (à moins que vous ne puissiez démontrer m'avoir envoyé un mail, mais qu'à cause d'une erreur cosmique — impliquant probablement mon incompétence — je l'ai manqué. Hé, ça arrive).
Quoi qu'il en soit, assez parlé de « ce qui reste en attente ». Si vous voulez savoir ce qui a été incorporé, une approche assez lisible est la suivante :

git log --merges --author=Torvalds v3.3..

Parce que j'ai vraiment essayé de faire des messages compréhensibles, avec des informations venant des sous-mainteneurs. Et beaucoup d'entre vous m'en ont envoyé, merci.
Un point important à signaler est que le nettoyage des fichiers d'en-têtes était un truc à faire, mais j'espère qu'on n'aura plus à le refaire. En tout cas, pas avant une version ou deux. Ce nettoyage a provoqué beaucoup de conflits de merge et quelques autres ennuis et, bien que je sois OK pour les résoudre, c'était suffisamment pénible pour que je ne veuille pas recommencer de sitôt. Je sais que des sous-mainteneurs ont eux aussi été embêtés et s'en sont plaint auprès de moi.
Cela dit, je pense que c'était utile. Le découpage de asm/system.h (et à plus petite échelle les nettoyages de bug.h) a peut-être été douloureux, mais les choses sont vraiment plus propres. Je devine donc que nous ferons à nouveau ce genre de chose dans le futur, mais je veux juste oublier à quel point c'est pénible d'ici à la prochaine fois. Ok ?

Dans tous les cas, merci de tester et rapporter toutes régressions.

RC-2

La seconde version candidate du noyau est sortie le 7 avril 2012 :

Une autre semaine, une autre -rc. Cela m'a semblé plutôt calme, mais à en croire les chiffres, c'est une -rc2 assez typique, peut-être même avec un peu plus de modifications qu'à l'accoutumée.

Cela dit, il n'a pas l'air d'y avoir beaucoup de choses effrayantes. Une bonne partie des changements sont des correctifs (que j'espère quasi-finaux) pour les modifications des fichiers d'en-têtes, ainsi que les trois demandes d'inclusion mentionnées dans l'annonce de la -rc1 : HSI (High Speed Synchronous Serial Interface, les bases de dma-buf, et ce qui concerne DMA mapping. Ces trois-là ont été soutenues par plusieurs personnes braillant un « vas-y, envoie ». Pohmelfs n'a pas été mergé, pour la simple raison que personne ne l'a demandé.

En dehors des correctifs sur les fichiers d'en-têtes et les 3 incorporations retardées, il n'y a que les correctifs habituels. Je serai plus strict en ce qui concerne les inclusions à partir de maintenant car il y a eu beaucoup de « bruit » et pas uniquement des corrections. J'en suis en partie responsable : une série de modifications d'Eric Paris visant à grandement améliorer l'usage de la pile dans le contexte SElinux.
La plupart des changements concernent quelques architectures (arm, tile, powerpc, x86) et les pilotes (particulièrement le réseau, mais aussi regulator, drm et mmc), ainsi que quelques mises à jour sur la gestion de l'énergie.

J'espère que la -rc3 aura un résumé carrément plus court.

RC-3

C'est le 15 avril que la version RC-3 a été annoncée par Linus :

Bon, ça fait donc huit jours depuis la -rc2, principalement parce que j'ai passé du temps à courir après deux bugs que je pouvais reproduire plutôt que de rendre cette version disponible hier. L'un était un oops dans la couche de gestion d'erreur scsi, et l'autre un plantage étrange sur x86-32. Bug introduit par mes soins. Oops.

Enfin bref, un jour de retard, mais nous sommes maintenant plus stables du fait de la correction de ces problèmes dans la -rc3. Les deux étaient suffisamment obscurs pour ne pas toucher grand monde, mais je déteste annoncer des versions candidates avec des problèmes que je peux reproduire personnellement.

Ceci dit, je ne pense pas qu'il y ait grand chose de bien excitant dedans. Il s'agit principalement de mises à jour de pilotes, avec une poignée de correctifs d'architecture et de réseau. Les statistiques de modifications sont assez barbantes, exception faite de la mise à jour du pilote mtip32xx et d'un changement trivial dans kyrofb (remplacement des «unsigned long» par «u32» afin que ça fonctionne correctement en 64 bits) — cette rc se résume en gros par un bon nombre de simples remplacements.

Et des statistiques barbantes sont une bonne nouvelle. Cela signifie simplement « beaucoup de petits trucs ». Je l'admets, cela aurait été encore mieux si cela avait été « à peine quelques petits trucs », mais nous sommes raisonnablement tôt dans la séquence des versions candidates, je ne m'inquiète donc pas trop.

RC-4

La version RC-4 est disponible depuis le 21 avril :

Tout semblait calme depuis un moment, mais ça a changé hier. Je pense que soit les gens envoient leurs requêtes juste avant que je ne rende disponible les -rc, soit c'est un problème de gens qui travaillent de lundi à vendredi et qui finissent la semaine en m'envoyant leurs requêtes.
Peu importe le pourquoi, cela signifie que mon « oh, les choses se calment » de jeudi s'est transformé en « Uhhuh, en fait pas encore » le vendredi, quand plus de la moitié des modifications de cette -rc ont débarqué.

Ceci étant dit, même avec la pointe du vendredi, je pense que les choses ont tout de même été assez calmes. Nous avons eu quelques modifications annulées et un peu de nettoyage, mais la majorité sont des petits correctifs triviaux. Presque tous se situent dans les pilotes, avec quelques mises-à-jour du côté des systèmes de fichiers (la plupart étant des corrections de boutisme venant de Al) qui se sont glissées. Le traditionnel (sans renommage) fichier de différence est dominé par le déplacement du logo de démarrage m68k, mais nous utilisons tous les fichiers de différence de git maintenant, n'est-ce pas ? Auquel cas c'est 50% de pilotes (usb, mfd, xen, mmc, gpu, media…), 20% arch, 15% fs, et une poignée de trucs ici et là.

Mais rien de tout cela n'a vraiment l'air effrayant. Il semble que la sortie de la 3.4 soit dans les clous, mais n'hésitez pas à brailler si vous repérez des régressions.

Je serai sans connexion pendant quelques jours (classe de plongée sous-marine etc), mais si le modèle « les gens m'envoient leurs trucs le vendredi » se vérifie, je parie que cela ne changera rien pour personne. D'autant que j'aurai mon portable et mon environnement de travail, donc si un truc surgit, tout se passera bien. Je ne suis simplement pas autant en ligne que d'habitude.

RC-5

Huit jours après la RC-4, Linus a annoncé sur la liste de diffusion la sortie de la version RC-5 :

À nouvelle semaine, nouvelle -rc. Techniquement ça fait 8 jours — j'ai retardé la sortie d'une journée dans l'attente de quelques tests.
Tout comme la -rc4, une bonne partie des modifications sont arrivées vendredi (et quelques autres hier). Et cela ne s'est pas calmé, au contraire. -rc5 a presque 50% de modifications en plus que n'en avait -rc4. Ce n'est pas bon.

Ceci étant dit, je ne pense pas qu'il y ait quoi que ce soit de très effrayant là-dedans. C'est ennuyeux, certes (je hais vraiment les vilains problèmes d'ABI d'autofs avec lesquels je me suis battu ces derniers jours, par exemple), et j'aurais préféré que les choses fussent plus calmes, mais la plupart des changements sont assez petits et triviaux. C'est réparti de manière assez équitable : 50% de pilotes, 20% d'architecture, 15% de systèmes de fichiers (principalement btrfs et nfs), 5% de réseau, ainsi que du bruit aléatoire.

RC-6

La grande nouvelle de la journée du 6 mai 2012 a bien évidemment été l'annonce de la version RC-6 par Linus :

Une nouvelle semaine, une nouvelle -rc — et je pense que nous sommes proches de la 3.4 finale. Merci donc de tester.

Il y a toujours plus de modifications que je ne le voudrais — et j'apprécierais que les choses se calment davantage encore, mais globalement les changements restent petits et simples.
Environ la moitié des modifications sont dans les pilotes (et la partie réseau représente presque la moitié de ça), le reste provenant principalement de arch (powerpc et arm), fs (btrfs et nfs), ainsi que du réseau (hors pilotes).
Mais tous les changements semblent vraiment triviaux, donc au final je le sens plutôt bien.

En avant pour les tests.

RC-7

Enfin la dernière version candidate a été annoncé 12 mai 2012 :

C'est quasi certainement la dernière -rc de cette série : les choses se sont vraiment calmées, et j'ai même envisagé de rendre disponible le 3.4 en cette fin de semaine, pour finalement conclure qu'une semaine de plus ne pouvait pas faire de mal.

Le résumé des modifications donne une bonne vision d'ensemble : il s'agit principalement de petites corrections ici et là pour des petits problèmes très précis. La plus grosse modification (et celle qui touchera probablement le plus de gens) est le changement i2c de Nouveau — il s'agit de la suppression de la dernière modification. Les routines i2c spécifiques ayant leurs propres problèmes et les routines génériques i2c-algo-bit ayant été corrigées, Nouveau utilise maintenant les génériques.
Le reste est principalement constitué de petites modifications dans diverses zones : pilotes (réseau, drm, scsi, son et md), mises à jour de arch (arm, powerpc et x86) et divers autres endroits : cœur du réseau, un correctif de compat, des choses comme ça. Rien d'effrayant.

Alors lancez-vous et testez. Et ne m'envoyez aucune demande d'inclusion à moins qu'elle ne contienne que des correctifs pour de très vilains bugs. Je ne veux plus de ces stupides correctifs pour supprimer des warnings du compilateur etc.

En plus de cette annonce sur la LKML, Linus a décidé, comme il le fait régulièrement, de poster un petit texte sur son compte Google+ afin d'inciter les gens à tester cette dernière version candidate :

Dernière -rc avant la sortie de 3.4 ! Dépêchez-vous avant épuisement des stocks !
Du fait de l'édition limitée de 3.4-rc7, et si vous voulez que votre maman soit fière de vous demain, vous feriez bien de vous dépêcher. Et si vous êtes une maman, montrez à vos enfants que vous êtes exceptionnelle, car vos machines n'utilisent que le plus récent et le meilleur.
Parce que vous le valez bien.

Et si vous êtes un développeur, rendez-nous tous fiers en n'envoyant pas davantage de « correctifs des warnings du compilateur » ou autres modifications sans intérêt. Si vous m'envoyez une demande d'inclusion ou un patch destiné à la version finale de 3.4, il vaudrait mieux que cela concerne une regression majeure, un oops ou un correctif de sécurité.
Compris ?

Les nouveautés Architecture x32

Aux côtés de ses cousines x86 et x86-64, la nouvelle architecture x32 fait son entrée dans le nouveau noyau Linux 3.4.

On sait que l'architecture x86-64 est une modernisation profonde de la vénérable architecture x86. Les registres généraux passent de 32 bits à 64 bits et leur nombre double (16 registres au lieu de 8). La mémoire virtuelle n'est plus limitée à 4 Go, le bit NX est implémenté.  L'appel système SYSCALL64 est très rapide et les instructions vectorielles disponibles sont au moins au niveau du SSE2.
Toutes ces nouveautés, et le fait que sa prise en charge est désormais mature, font qu'il est désormais presque absurde d'utiliser une distribution en mode x86.

Néanmoins, certains développeurs sont d'avis que l'architecture x86 garde quelques avantages. Par exemple le fait de se limiter à 32 bits signifie que les pointeurs mémoires sont plus petits et induisent donc moins de pression sur les mémoires caches du processeur. C'est un point important, notamment pour l'embarqué, car le bon fonctionnement du cache est absolument crucial pour les performances du processeur.
C'est quand même dommage de devoir choisir entre les indispensables 16 registres de x86-64 et l'empreinte mémoire réduite de x86. Serait-il possible de créer une nouvelle variante qui ne retiendrait que les meilleurs aspects de ces deux architectures ?

C'est précisement le but qu'avait en tête H. Peter Anvin quand il a posté sur la LKML les patchs proposant l'architecture x32.
Les programmes compilés avec l'ABI x32 tourneront donc en profitant à plein des 16 registres 64 bits (comme sous x86-64) mais leurs pointeurs mémoires seront limités à 32 bits (comme sous x86). Bien entendu, ces programme seront limités à un espace d'adressage de 32 bits (4 Go) mais cela ne constitue pas vraiment un obstacle pour la plupart d'entre eux, en particulier dans l'embarqué.

D'après les premiers tests, postés sur le site spécialement dédié à x32, les performances semblent encourageantes.
Le test 181.mcf du benchmark SPEC CPU2000 a été utilisé car il est extrêmement dépendant de la mémoire et il profite à fond d'une réduction de la pression sur le cache. Selon ce test, effectué sur un processeur Core i7, on obtient un gain de vitesse d'environ 32% par rapport au mode x86-64. Comme prévu les performances sont très proches de celles d'x86 (moins de 1% d'écart).
Le gain induit par les pointeurs mémoire 32 bits est donc bien visible.

Si on regarde le test 186.crafty on devrait cette fois mettre en évidence le gain induit par l'utilisation des 16 registres 64 bits puisque ce test est très dépendant du processeur. Là encore, la nouvelle architecture tient ses promesses puisque l'architecture x32 n'est que 5% plus lente que x86-64 mais qu'elle enregistre un gain de 29% par rapport à x86.

Les patchs de H. Peter Anvin ont été assez bien accueillis sur la liste de diffusion du noyau mais Linus a quand même grogné sur un point précis. À l'origine les valeurs relatives à la gestion du temps (time_t, off_t ou timeval) devaient être en 32 bits ce qui impliquait que l'architecture x32 serait soumise au bug de l'an 2038 (overflow du nombre de secondes entre 1970, l'origine du temps UNIX, et l'année 2038).
Linus a été prompt à envoyer un scud en soulignant que ce point était inacceptable:

J'ai eu des journalistes qui m'ont posé la question et j'ai toujours répondu qu'en 2038 nous utiliserions tous des processeurs 64 bits. Je pense que c'est une réponse tout à fait raisonnable.
Mais si ces processeurs 64 bits font en fait tourner un mode « rapide » 32 bits alors cette réponse perd toute sa pertinence. À notre époque, c'est une erreur fondamentale que d'avoir off_t et time_t en 32 bits. Je detesterai d'avoir à introduire ça dans le noyau, ça me ferait gerber.

Ce point a été rapidement corrigé en introduisant une gestion du temps spécifique sur 64 bits pour l'architecture x32 (c'est la fonction COMPAT_USE_64BIT_TIME). D'autres objections ont été soulevées mais les révisions successives des patchs ont finalement convaincu Linus d'intégrer cette ABI x32 dans la branche principale du noyau.

Bien entendu, un tel changement mixant les caractéristiques de plusieurs architectures a des impacts bien au-delà du noyau Linux. La gestion de la nouvelle architecture x32 doit être ajoutée dans GNU binutils, dans la Glibc et dans le compilateur GCC. Les distributions binaires doivent décider d'utiliser ce mode et proposer des exécutables x32 dans leur dépôts.
C'est donc un travail de longue haleine qui commence et nous verrons dans les prochaines années si l'architecture x32 arrive à convaincre dans le monde de l'embarqué.

dm-verity

La couche du device-mapper présente dans le noyau est une interface virtuelle servant à faire communiquer entre eux des périphériques blocs. Cette gestion des volumes logiques permet, par exemple, de faire du RAID logiciel ou du chiffrement de disques entre divers périphériques en mode blocs.
La couche device-mapper du noyau 3.4 accueille un nouveau module nommée dm-verity qui fera sans doute quelque peu polémique auprès des libristes les plus vigilants.

Le but de dm-verity est de vérifier l'intégrité des blocs de données d'un périphérique. Pour cela une empreinte est prise pour chaque bloc et chaque hash est mappé sur son bloc respectif via dm-verity. Comme le périphérique virtuel est monté en mode lecture seule, il n'est pas possible de changer le hash, ce qui assure l'intégrité des données contre toute tentative de modification frauduleuse.
Bien entendu, pour que la chaine de confiance soit absolue, il faut que la machine puisse avoir une phase de boot protégée. Cela se fait en utilisant tboot ou TrustedGRUB ou encore en démarrant à partir d'une clé USB ou d'un CD considérés comme sûrs. L'utilisateur de dm-verity va alors fournir au système le hash de la racine et cette information est la clé qui permettra de vérifier, de proche en proche, que les blocs du périphérique (et donc les exécutables) n'ont pas été modifiés. C'est la technique classique de l'arbre de hachage qui est ici utilisée (Merkle tree).
La documentation indique que la vérification se fait via l'outil veritysetup avec la syntaxe suivante:

veritysetup -a vroot /dev/sda1 /dev/sda2 hash_de_la_racine

Théoriquement à ce stade le lecteur attentif des dépêches noyau LinuxFr devrait se demander « Mais en quoi est-ce différent du sous-système EVM qui avait été décrit dans la news Linux 3.2 ? ».
Excellente question cher lecteur attentif ! Et bien tout d'abord EVM fonctionne obligatoirement avec une puce TPM (Trusted Platform Module) alors que dm-verity n'a pas cette dépendance. Il peut utiliser une puce TPM (via TrustedGRUB notamment) mais, comme nous l'avons vu plus haut, il peut aussi se contenter d'un boot à partir un périphérique externe qui aura été gardé en lieu sûr (clé USB ou CD).
Ensuite, la vérification des hashs se fait seulement à la demande, quand le noyau à besoin de réellement accéder aux blocs sous-jacents (lors d'un accès disque). Cela évite une coûteuse phase de vérification de tous les hashs lors du démarrage et améliore donc les performances.

Le développeur Mandeep Singh Baines a indiqué que dm-verity était déjà utilisé par Google dans son projet Chrome OS :

dm-verity fait partie de l'infrastructure de boot sécurisée de Chrome OS. Le module est utilisé pour vérifier l'intégrité du système de fichiers root lors du démarrage. Cette partition root est montée via un mapping dm-verity afin de vérifier, de façon complètement transparente, que chaque bloc correspond au hash qui a été passé lors du boot.

Une présentation de dm-verity a été effectué lors du sommet Plumber 2011 qui s'est déroulé à San Diego en août dernier. Dans le fichier pdf de présentation on apprend que la vitesse de vérification a été un facteur crucial lors du choix d'architecture de dm-verity. Certes, EVM est une solution plus complète, mais la nécessité de ne pas ralentir le démarrage d'une machine Chrome OS a conduit au développement de cette alternative. Avec dm-verity il est ainsi possible de booter en 1,2 seconde une partition root de 891 Mo.

Bien entendu, cette technique de vérification d'intégrité peut aussi être utilisée par des constructeurs peu scrupuleux qui voudraient bloquer l'accès des utilisateurs à leur machine. Il est particulièrement inquiétant de lire le mail envoyé sur la LKML par Wesley Miaw qui travaille pour Netflix. Cette société américaine propose un service payant de streaming vidéo. On comprend facilement qu'elle puisse chercher à bloquer l'enregistrement de ce flux vidéo sur les smartphones et tous les autres périphériques basés sur Linux :

Netflix voudrait que dm-verity soit incorporé dans le noyau Linux. Au cours de l'année écoulée, nous avons travaillé avec Google afin de porter dm-verity sur un certain nombre de périphériques électroniques grand public tournant sous une version embarquée de Linux.
La demande pour cette fonction a été importante et nous voyons pas mal de bénéfices à ce que dm-vérity fasse partie du noyau officiel.

Netflix a une politique de certification officielle des plateformes avant que l'utilisateur ne puisse accéder au flux vidéo (voir cet exemple avec les smartphones OMAP 4). On peut craindre que dm-verity ne soit utilisé pour bloquer toute tentative de changement des binaires et que le hash racine ne reste entre les mains du constructeur. Ce ne serait pas la première fois qu'une technologie potentiellement utile serait ainsi détournée pour asservir les utilisateurs.
Comme le résume Jonathan Corbet sur l'article LWN dédié à ce sujet :

Certains vendeurs vont, sans aucun doute, choisir d'inclure des outils comme dm-verity sans donner aux utilisateurs la possibilité de le désactiver. Ce n'est pas une bonne chose, mais ce n'est pas non plus quelque chose de nouveau.

Nouveautés pour l'architecture ARM

L'architecture ARM a le vent en poupe en ce moment et le noyau Linux 3.4 accueille de nombreuses nouveautés qui améliorent sa prise en charge et ajoutent des fonctionnalités.

La première de ces nouveautés est l'unification de la gestion des horloges dans un nouveau sous-système dédié nommé « Common CLK ».
C'est un travail de longue haleine qui a été entrepris par Mike Turquette, Jeremy Kerr et Ben Herrenschmidt puisque la première version a été proposée sur la LKML il y a plus d'un an.
Auparavant le noyau Linux gérait de façon complètement séparée ce code de gestion des horloges matérielles. Chaque implémentation vivait dans des répertoires dédiés aux diverses architectures. Plutôt que cette solution inefficace d'un code spécifique pour chaque plateforme, le nouveau sous-système propose une gestion matérielle unifiée :

The common clk framework is an interface to control the clock nodes available on various devices today. This may come in the form of clock gating, rate adjustment, muxing or other operations. The net result is consolidation of many different struct clk definitions and platform-specific clock framework implementations.

La documentation indique que l'option de configuration COMMON_CLK doit être choisie lors de la compilation et que l'interface est divisée en deux parties bien distinctes. La première s'appuie sur le code commun (un struct clk unique ainsi qu'une API unifiée dans include/linux/clk.h) tandis que la seconde regroupe les callbacks spécifiques qui s'enregistrent avec clk_ops.
Maintenant que ce sous-système commun unifié est disponible on va sans doute assister à la conversion progressive des pilotes dans les prochaines versions du noyau.

Ce travail n'est pas vraiment spécifique à l'architecture ARM mais, étant donné la diversité qui existe sur cette architecture, c'est pour elle que ses effets bénéfiques vont se faire sentir avec le plus de force. Alors qu'avant il était impossible de compiler une image noyau identique pour deux plateformes ARM ayant des struct clk différentes, il devient maintenant envisageable, à moyen terme, d'avoir une image multi-plateforme unique pour ARM. Moins de duplication de code et, comme l'écrit Mike Turquette, le but est bien d'avoir « The One Image to Rule Them All » !

Outre cette infrastucture « Common CLK » le noyau 3.4 accueille également les patchs de DMA-mapping qui ont été écrits par Marek Szyprowski. Le DMA (Direct Memory Access) c'est la possibilité d'envoyer les données d'un périphérique directement dans la mémoire RAM, sans intervention du processeur. Bien entendu, cette technique doit tenir compte des particularités de l'architecture matérielle sous-jacente et une API unifiée est disponible dans le noyau Linux.
Le problème, c'est que les développeurs ARM n'utilisaient pas vraiment ce code commun et qu'une certaine « balkanisation » était observée dans l'arbre des sources. Marek a mis fin à cette anarchie et ses patchs simplifient la gestion des particularités de l'architecture ARM.

Encore une nouveauté ARM intégrée dans ce noyau 3.4, la fonction « jump label » est maintenant utilisable pour les machines ARM et Thumb-2.
Comme indiqué dans la dépêche du noyau 2.6.37 cette fonction « jump label » (d'ailleurs renommée depuis en « static keys ») permet de réduire drastiquement le coût des points de traçage, mais elle nécessite d'écrire un code assembleur adapté à chaque architecture. C'est Vincent Rabin qui s'est chargé de ce travail pour ARM et cette fonction est utilisable avec l'option de configuration HAVE_ARCH_JUMP_LABEL.

Le JIT (compilateur à la volée) qui permet d'accélérer le traitement des paquets réseau du filtre Berkeley Packet Filter, est maintenant disponible sur architecture ARM.
Cette fonction est utilisable via l'option HAVE_BPF_JIT et elle s'active avec un petit echo 1 > /proc/sys/net/core/bpf_jit_enable.

Enfin, du côté de la prise en charge du matériel, le développeur Peter De Schrijver a écrit un patch ajoutant la gestion de la plateforme Tegra3 avec son « processeur compagnon ». On voit ainsi que NVidia, société pour laquelle travaille Peter, souhaite améliorer la prise en charge native de ses SoCs dans la branche principale.
Le noyau 3.4 apporte également la prise en charge de la plateforme Exynos5 de Samsung. C'est le tout premier System on Chip à utiliser le nouveau coeur Cortex-A15.

YAMA

Après plus d'un an et demi d'hésitations et de débats, le module de sécurité YAMA a finalement été intégré dans le noyau Linux 3.4.
Cet ajout est une bonne occasion pour évoquer les controverses qui persistent entre les développeurs au sujet de la sécurité de Linux. Il a toujours été difficile de trouver un équilibre entre la sécurité à tout prix, au détriment même de la propreté du code et de sa maintenabilité, ou bien une approche plus pragmatique et mesurée.

Tout commence le 16 juin 2010 avec un mail de Kees Cook sur la liste de diffusion du noyau. Kees, qui était alors responsable sécurité chez Canonical, soutient que l'appel système ptrace est potentiellement dangereux et il propose un patch pour bloquer cette faille.
La commande ptrace est souvent utilisée pour les phases de déboguage car elle permet à un processus d'éditer l'espace mémoire d'un autre processus. D'après Kees Cook, un attaquant peut exploiter cette capacité afin d'élargir la surface d'attaque d'une compromission initiale :

Une faiblesse particulièrement troublante de l'interface des processus sous Linux est qu'un simple utilisateur peut examiner le statut et la mémoire de chacun de ses processus.
Par exemple, si une application (par exemple Pidgin) est compromise, alors il est possible pour un attaquant de s'attacher à un autre processus (par exemple Firefox, une session SSH, un agent GPG, etc.) afin d'extraire des informations sensibles additionnelles et continuer son attaque.

Le patch de Kees est simple puisqu'il se contente d'ajouter un sysctl (une interface de paramétrage) contrôlant le comportement de ptrace. Ce nouveau paramètre, nommé ptrace_scope, peut prendre les valeurs « 0 » ou « 1 ». Par défaut, c'est « 0 » qui est utilisé (mode « classic ») et cela signifie que le comportement de ptrace ne change pas par rapport à la situation actuelle. En revanche, quand ptrace_scope est à « 1 » (mode « restricted »), alors un processus ne peut lancer ptrace que sur ses processus fils et toute tentative d'examiner la mémoire des autres processus échouera.

On notera que le travail de Kees Cook s'inspire largement d'une fonction qui existe déjà dans Grsecurity. L'option CONFIG_GRKERNSEC_HARDEN_PTRACE interdit en effet de lancer ptrace sur des processus arbitraires et limite le choix aux processus fils.

Les réactions sur la LKML n'ont pas été d'un enthousiasme délirant et Alan Cox a été prompt à manifester son opposition au patch de Kees :

Les autres distributions font ça de façon rationnelle en utilisant des choses comme SELinux. Cela permet de décrire les relations de façon complète et on contrôle tous les chemins d'accès, pas seulement ptrace, pouvant être utilisés par un attaquant.
Même si tu t'en tapes d'utiliser les mêmes fonctions de sécurité que le reste du monde, de toute façon ton patch, et les autres trucs que tu as postés, tout ça doit aller dans un module de sécurité à part.
Donc NAK. Si tu veux réutiliser des morceaux de grsecurity alors, s'il te plaît, écris un module noyau grsecurity qui se basera sur les hooks qui existent. Arrête de pourrir le cœur du code. C'est aussi simple que ça. L'infrastructure existe alors utilise-là.

James Morris, le responsable de SELinux, a même souligné que son module de sécurité avait déjà un booléen, nommé allow_ptrace, et permettant de contrôler le comportement de ptrace. Pourquoi alors réinventer la roue ?
Le problème c'est que tout le monde ne veut pas utiliser SELinux. Les réfractaires sont nombreux et ils sont d'avis que SELinux est trop compliqué à utiliser. Même un hacker aussi réputé que Ted Ts'o avoue être découragé :

Il y a un bon nombre de gens qui n'utiliseront jamais SELinux. Tous les deux ou trois ans, je jette un nouveau coup d'œil sur SELinux, ma tête explose devant la complexité (non nécessaire ÀMHA) et je prends une nouvelle fois le large.

La situation paraît donc complètement bloquée entre les zélotes d'un module SELinux ultra-puissant mais complexe et les partisans d'une solution plus simple, même si elle est moins complète.
La solution régulièrement évoquée pour faire face à ce problème est « l'empilage des modules de sécurité » (LSM stacking). Avec cette solution, il devient possible d'avoir un « gros » module qui couvre le cas général (comme SELinux) et un ou plusieurs autres modules qui ne s'occupent que de fonctions bien précises sur lesquelles l'utilisateur veut avoir le contrôle.
Actuellement, le code LSM du noyau ne permet le chargement que d'un seul module de sécurité, à l'exclusion de tous les autres. Avec le LSM stacking cette limitation disparaîtrait et le noyau Linux offrirait plus de souplesse à ses utilisateurs.

En attendant que les développeurs se mettent d'accord sur une solution technique propre pour implémenter cet empilage des modules, Kees Cook a donc réécrit son patch afin d'isoler le code à l'intérieur d'un nouveau module de sécurité nommé YAMA.
En plus de la restriction d'utilisation de ptrace, on trouve dans le module des protections supplémentaires sur l'utilisation des liens symboliques (symlink) et des liens matériels (hardlink).

L'intégration du module YAMA a été proposée sur le LKML le 21 juin 2010… mais, dès le 2 août, Kees a posté un message indiquant qu'il était obligé de retirer le module puisque Christoph Hellwig avait posé un veto empêchant l'inclusion dans le noyau.
Les objections de Christoph se concentrent sur le fait que YAMA n'est pas un module de sécurité cohérent et qu'il n'est qu'une collection hétéroclite de divers patchs visant à bloquer des failles potentielles.

À ce stade de la situation on ne peut que comprendre la frustration de Kees :

Je commence à être fatigué de devoir porter mes patchs d'un côté ou de l'autre entre les sous-systèmes ou les modules de sécurité. Vous m'avez demandé de tout mettre dans un module et maitenant vous me dites que je ne devrais pas faire ça.
La situation est très simple. Soit vous me laissez mettre tout ça dans un module pour que les gens puisse choisir de l'activer. Soit vous m'aidez à améliorer les patchs, afin qu'ils intégrent directement les sous-systèmes.
Comme la seconde solution a été refusée à plusieurs reprises, il m'a été suggéré d'opter pour la première, ce que j'ai fait. L'option de tout abandonner n'est pas envisageable.

La flame war discussion a donc été relancée et certains développeurs ont tenté d'expliquer à Kees ce qu'il reprochaient à ses patchs :

Tu n'évoques pas la solution que t'a suggérée Al : Il faut avant tout réfléchir au problème de façon approfondie au lieu de balancer des patchs qui ne s'occupent que d'un seul cas de figure.
Ici on ne bloque qu'un seul type spécifique d'attaque sans créer un modèle conceptuel de la menace. C'est la grande distinction entre SELinux, Tomoyo, Smack et puis tes patchs à toi. Ces modules de sécurité forment un modèle de ce qui est important à protéger et de comment le protéger. Ils ne se contentent pas d'appliquer des règles arbitraires pour empêcher certaines attaques.
Les gens s'inquiètent parce que ton module pourrait grossir en accumulant des tonnes de règles spécifiques qui créeraient une sécurité apparente sans vraiment procurer une sécurité réelle.

Kees Cook a tenté de faire valoir son point de vue et a souligné la situation impossible dans laquelle il se trouvait confiné :

Vous pouvez voir, comme moi, que la situation est un catch 22. "Nous n'avons pas besoin de la fonction d'empilage parce qu'il n'y a rien à empiler" et "nous n'avons pas besoin d'un micro-module parce qu'il est impossible d'empiler les modules".

Le blocage étant total, il a été décidé d'attendre la prochaine conférence sur la sécurité du noyau afin que la situation se décante et que les protagonistes puissent se parler directement. C'est donc en septembre 2011 que James Morris et les autres développeurs responsables de la sécurité se sont retrouvés. Dans le programme, on peut voir que Kees Cook animait une discussion portant le titre suivant: « LSM Architecture: modularity, stacking ».
Le compte-rendu que Paul Moore a fait du « Linux Security Summit 2011 » indique que le sommet à bien joué son rôle et que l'avis des développeurs a changé au sujet du stacking et de la concurrence entre les modules. Cette évolution s'est matérialisée en mars 2012 quand James Morris a officiellement accepté d'intégrer le module de sécurité YAMA dans sa branche destinée au noyau Linux 3.4. Le fait que ce code soit déjà en cours d'utilisation dans divers projets n'est sans doute pas étranger à cette inclusion :

Le principal ajout est le nouveau module de sécurité YAMA, écrit par Kees Cook, et qui a été discuté l'année dernière au sommet sur la sécurité. Son but est de rassembler divers mécanismes de sécurité DAC en un seul endroit. Cela marque également un changement de politique en ce qui concerne les modules LSM qui étaient auparavant tous des mécanismes complets de contrôle d'accès.
Chromium OS utilise YAMA et je crois qu'il y a des plans pour Ubuntu.

Kees a précisé qu'en fait Ubuntu utilisait déjà YAMA depuis octobre 2011 et il a également fourni un lien vers l'inclusion de YAMA dans Chromium OS.
Selon la documentation présente dans les sources du noyau, on voit que seule la restriction de ptrace a été implémentée pour l"instant dans YAMA (just ptrace restrictions for now). Il est fort probable que les autres restrictions, celles qui concernent symlink et hardlink, intégreront plus tard le module.

Un choix est donc désormais offert entre l'implémentation (souvent difficile) d'une politique de sécurité complète ou bien l'activation d'un module visant à regrouper divers patchs de renforcement de la sécurité.
Nous verrons dans les prochains noyaux si la solution idéale que constituerait le « stacking LSM » parviendra à s'imposer.

En bref Maturation de btrfs

Les distributions de Novell (SuSE Linux Enterprise) et d'Oracle (Unbreakable Enterprise Kernel) veulent absolument se différencier par rapport à Red Hat. C'est pour ça qu'elles ont choisi de supporter officiellement (1 - 2) le système de fichiers btrfs, même si il est encore considéré officiellement comme « experimental » dans la branche principale du noyau.
Leurs patchs de fiabilisation arrivent maintenant dans le noyau 3.4 afin que tous les utilisateurs puissent en profiter.
On trouve donc un gros patch de Jeff Mahoney, employé par SuSE, qui améliore la gestion des erreurs. Auparavant, c'était un simple et rustique appel à la macro BUG_ON qui était souvent utilisé (on enregistre l'erreur et on arrête le système). Maintenant la plupart des erreurs bénéficient d'un traitement spécifique et le crash du noyau est évité. Comme le résume Chris Mason :

Nous avons mergé les patchs de gestion d'erreurs venant de SuSE. Ils sont déjà incorporés dans le noyau SLES et ils apportent à Btrfs la possibilité d'interrompre les transactions et de passer en mode lecture seule en cas d'erreur.

Le message de Chris récapitule les autres nouveautés concernant btrfs pour cette version du noyau. On peut voir notamment qu'un gros travail de performances a été effectué sur la gestion des métadonnées, sur la coopération avec le cache de page de Linux ou encore sur la réduction de l'empreinte CPU (voir par exemple les patchs de Josef Bacik).
En ce qui concerne les métadonnées du système de fichiers il est possible d'utiliser des blocs plus grands que 4 Ko. La limite est maintenant portée à 64 Ko et les tests montrent que l'optimum du gain de performances est atteint avec une taille de bloc égale à 32 Ko. Cette fonction s'active lors de la création du système de fichiers avec mkfs.btrfs -l 32K.

Tout ce travail d'optimisation des performances porte ses fruits si on compare les graphes postés par Chris Mason entre les versions 3.3 et 3.4 du noyau.

Simplifications dans ext4

En ce qui concerne le système de fichiers ext4, il n'y a pas de changements révolutionnaires, mais on trouve néanmoins plusieurs patchs de nettoyage intéressants.
Ted Ts'o, qui peste depuis plusieurs mois devant le nombre d'options présentes dans ext4, a procédé à diverses simplifications du code. Par exemple, l'option de montage journal=update, qui a été introduite il y a dix ans pour faciliter les migrations depuis ext3, a été retirée du noyau 3.4. C'est la même chose pour l'option resize permettant de changer la taille lors du mount. Après tout, on utilise resize2fs alors pourquoi avoir cette option redondante ?
Un autre patch utilise une table pour stocker les options de mount, ce qui, là encore, simplifie le code puisqu'on peut supprimer une centaine de lignes.
Ted a également proposé de retirer les options bsddf et minixdf qui conduisent l'outil df à se comporter comme sous BSD ou MINIX… mais les cris d'orfraie sur la LKML l'ont finalement dissuadé.
Pas découragé pour autant, il a fait remarquer qu'ext4 était le seul système de fichiers à proposer une option permettant l'activation ou la désactivation des attributs étendus lors du mount (options noacl et nouser_xattr). C'est fort peu utile, mais avant de supprimer ce code, il faut tout de même alerter la communauté. Son patch se contente donc pour l'instant de marquer ces options comme obsolètes (deprecated) et elles seront probablement retirées dès le prochain noyau.

fadump pour PowerPC

Dans cette version du noyau, l'architecture PowerPC a gagné un mécanisme de capture des donnés (dump) lors d'un éventuel crash de la machine. Ce nouveau système repose sur une coopération avec le firmware, ce qui explique son nom de fadump (firmware assisted dump).

Lors du boot initial le noyau se sert du firmware Power pour sélectionner des régions de la mémoire et les réserver au stockage des données pour analyse post-mortem. Au moment du crash, c'est le firmware qui prend la main et qui sauve les données (ainsi que les registres systèmes et les entrées dans la tables des pages).
Après ces opérations l'administrateur peut redémarrer normalement. Le noyau va noter qu'il y a eu un crash (puisqu'une entrée dump-kernel aura été créée) et il va soigneusement éviter de toucher les zones mémoire réservées. Un programme en espace utilisateur pourra ensuite être utilisé pour lire /proc/vmcore et récupérer ces données pour analyse ultérieure. Ensuite, il ne faudra pas oublier de faire un petit echo 1 > /sys/kernel/fadump_release_mem pour libérer la mémoire qui avait été réservée au stockage des données du crash.

La documentation de fadump écrite par Mahesh Salgaonkar explique les deux avantages de cette procédure par rapport aux classiques kexec et kdump. Tout d'abord, le système est réinitialisé proprement avec une version fraiche du noyau et ensuite, aussitôt que la copie du dump est effectuée, la mémoire peut être réutilisée. Pas besoin d'un second reboot.
Pour profiter des avantages de fadump il vous faudra un noyau compilé avec l'option de configuration CONFIG_FA_DUMP.

UFS dans le noyau

Le titre de ce paragraphe peut prêter à confusion puisqu'il ne s'agit pas du système de fichiers bien connu Unix File System mais bien de la norme Universal Flash Storage.
C'est l'organisation de standardisation JEDEC qui s'est chargée de créer cette nouvelle norme destinée au stockage sur mémoire Flash dans les appareils mobiles (smartphones, tablettes ou encore appareils photo). De nombreuses sociétés de l'embarqué (Nokia, Sony Ericsson, Texas Instruments, STMicroelectronics, Samsung, etc) ont travaillé à l'élaboration de la norme afin qu'elle offre une plus grande vitesse et une moindre consommation que le standard actuel des cartes SD. L'architecture de communication utilisée est similaire à SCSI afin de profiter de la gestion des commandes multiples et d'offrir un modèle de programmation bien connu.

Les patchs de Santosh Yaraganavi ajoutent au noyau le pilote UFS pour le host controller. Selon la documentation, un peu de travail reste à faire en ce qui concerne la gestion de la consommation, mais on peut noter que Linux est le premier OS à offrir la gestion de la norme « Universal Flash Storage ».

Camellia et crc32

L'optimisation des algorithmes de chiffrement va peut-être devenir un paragraphe récurrent des dépêches noyau. En effet, après les patchs évoqué dans les dépêches du 3.2 et du 3.3, le développeur finlandais Jussi Kivilinna a frappé de nouveau.

Cette fois c'est l'algorithme Camellia qui est concerné. Rappelons qu'il s'agit de l'algorithme de chiffrement symétrique 128 bits arrivé en tête lors du concours NESSIE de l'Union européenne .
Comme pour ses patchs précédents Jussi a écrit une implémentation en assembleur optimisé pour l'architecture x86_64 (camellia-x86_64-asm_64.S). Le gain en performances est tout à fait notable par rapport au code C générique du noyau puisque, sur un processeur Core2 T8100, on relève un écart s'échelonnant de 10 % à plus de 70 % (en mode ECB).

Jussi Kivilinna n'est pas le seul à traquer la performance et le noyau Linux 3.4 incorpore également les patchs crc32 de Bob Pearson. Le contrôle de redondance cyclique (CRC pour Cyclic Redundancy Check) est utilisé partout afin de détecter les erreurs de transmission et il est important que le code soit optimisé soigneusement.
Bob a modifié le fonctionnement de la routine lib/crc32.c afin de remplacer la boucle principale et la boucle rem_le par des compteurs à incrémenter. Selon les tests on peut espérer un gain supérieur à 6 % sur architecture x86.
Comme le code semble dégrader les performances des PowerPC il a été entouré de ifdef CONFIG_X86 afin de ne pas pénaliser les autres architectures.

Discard pour « thin provisioning »

Depuis le noyau 3.2, la couche « device mapper » permet de faire de l'allocation fine et dynamique (thin provisioning). Dans le cadre d'un SAN, plutôt que d'allouer vraiment tous les blocs à un client, on va les allouer à la volée pour économiser de l'espace. Chacun des clients aura un volume virtuel à sa disposition, mais ce volume n'occupera que l’espace réellement consommé.

Cette cible DM de « thin provisioning » est maintenant capable de gérer la fameuse fonction discard. Cette commande est très importante pour les disques de stockage de type SSD (à base de mémoire flash), car elle permet au système d'exploitation d'indiquer au disque quels sont les blocs de données qui peuvent être effacés. Dans le cas du « thin provisioning » un appel à discard provoquera la suppression des mappings et, si les blocs ne sont plus partagés, l'ordre de suppression sera envoyé au périphérique sous-jacent.

Cette utilisation plus efficace du périphérique de stockage n'est pas la seule nouveauté intégrée dans la fonction de « thin provisioning » du noyau 3.4. On trouve également la possibilité d'utiliser des images en lecture seule comme origine. La lecture des blocs s'effectue sur cette image tandis que les écritures se font sur un autre périphérique.
C'est très utile dans le cas des environnements virtualisés puisque l'hôte peut ainsi accueillir les systèmes invités sur un volume géré par « thin provisioning » tout en ayant l'image de base stockée sur un autre périphérique partagé entre les machines virtuelles.

IRQ domains

Une IRQ c'est une demande d'interruption (Interrupt Request) envoyée au processeur pour lui signaler que le matériel a besoin qu'une action urgente soit effectuée (entrée/sortie, avancement d'une horloge, défaut matériel, etc).
Linux se doit de gérer parfaitement les machines qui ont plusieurs contrôleurs d'interruptions et, pour atteindre ce but, un nouveau sous-système nommé « IRQ domains » fait son entrée dans le noyau 3.4.

Auparavant c'étaient les fonctions irq_alloc_desc et irq_free_desc qui étaient utilisées afin d'éviter les collisions dans les assignations des numéros des interruptions.
Ce mécanisme ayant été jugé perfectible (pas de possibilité de faire du reverse mapping), un nouveau-système propre et générique a été développé. Il s'inspire du code PowerPC et s'active avec l'option de configuration IRQ_DOMAIN.
Comme l'explique la documentation, ce mécanisme générique permet maintenant au noyau Linux de gérer proprement le mapping entre les IRQ des divers contrôleurs (hwirq) et l'espace global des interruptions.

Pilote virtio-scsi

Virtio est une interface virtuelle qui permet au noyau de gérer efficacement les entrées/sorties pour les systèmes virtualisés. C'est le pilote virtio-blk qui s'occupe des périphériques en mode blocs mais, à partir de ce noyau 3.4, une alternative devient disponible. Elle prend la forme du pilote virtio-scsi écrit par Paolo Bonzini, un développeur Red Hat.

Ce pilote virtio-scsi propose le multiplexing (plusieurs unités de stockage logique sur un seul port PCI) mais son auteur le définit surtout comme plus extensible que virtio-blk. Avec ce dernier, il est nécessaire de définir la liste des fonctionnalités du périphérique et chaque ajout implique une mise à jour de cette spécification, de l'hôte QEMU ainsi que des pilotes des systèmes invités.
Avec virtio-scsi, l'hôte fournit juste une couche de transport SCSI et les ajouts de fonctionnalités se feront plus facilement (Paolo cite les fonctions « discard », « extended copy » ainsi que « write same »).
Les développeurs Linux n'aiment pas vraiment introduire du code qui fait doublon dans le noyau et Paolo a dû batailler ferme pour convaincre James Bottomley de l'utilité de son pilote aux côtés de virtio-blk.
Pour profiter de ce pilote alternatif sur vos systèmes, il vous faudra un noyau compilé avec l'option SCSI_VIRTIO. Ce code est encore considéré comme expérimental pour le moment.

Du côté de -staging

Pas mal de mouvements dans cette branche -staging dédiée au code pas encore assez mature pour rejoindre la branche principale.
Par exemple, les mécanismes « zcache » et « zram », qui s'occupent de compresser les pages mémoire, bénéficient d'un nouvel allocateur mémoire. Auparavant, c'était l'allocateur « xvmalloc » qui était utilisé mais un remplaçant plus efficace a été développé par Nitin Gupta. Ce nouvel allocateur se nomme « zsmalloc » et il est conçu tout spécialement pour stocker des pages RAM compressées et réduire la fragmentation.
Par ailleurs, le mécanisme de compression zcache utilise maintenant le sous-système CRYPTO du noyau pour son algorithme de compression. Avant, c'était un code ad-hoc qui était employé mais les développeurs Linux ont fermement indiqué qu'il fallait réutiliser le mécanisme standard. On peut choisir son algorithme au boot avec une syntaxe du type zcache=lzo ou zcache=deflate.
Greg Kroah-Hartman ayant indiqué qu'il n'accepterait plus aucun ajout de fonction, on peut penser que ces patchs seront les derniers avant la sortie de -staging pour « zcache » et « zram ».

Toujours dans -staging les patchs écrits par Arve Hjønnevåg ajoutent la prise en charge des alarmes Android dans le noyau. Encore un petit pas vers la gestion intégrale d'Android dans la branche principale.

Le sous-système « RAMstee », après un petit imbroglio initial, a également été intégré dans -staging (1 - 2). L'idée derrière « RAMstee » est très intéressante puisqu'il s'agit de permettre aux machines au sein d'un cluster de créer une sorte de pool commun de mémoire vive. Ainsi, quand une machine est un peu juste en RAM et sur le point de devoir faire appel au swap, elle va pouvoir envoyer ses données dans la RAM de sa collègue.
Le mécanisme est toutefois complexe (voir la documentation) et il faudra attendre sa stabilisation avant de le voir intégrer la branche principale.

Enfin, petit évènement, le dernier morceau du pilote de virtualisation Hyper-V écrit par Microsoft quitte enfin la branche -staging. Vous pouvez maintenant « profiter » de ce pilote en passant les options de configuration HYPERV et HYPERV_STORAGE lors du build.
C'est la fin d'une saga débutée en juillet 2009 et qui, du fait des atermoiements et des problèmes de qualité du code, n'aura pas redoré le blason de la firme de Redmond.

Pilote graphique Nouveau

Pour faire une habile transition avec la brève précédente consacrée à -staging, notons le patch de Ben Skeggs qui transfère le pilote Nouveau de -staging vers drivers/gpu/drm. Jusqu'à présent, les développeurs considéraient que Nouveau était encore susceptible de changer son interface binaire et donc devait rester dans l'antichambre du noyau. Le passage en version 1.0 marque un engagement de stabilité et autorise maintenant une sortie de -staging.
Comme l'écrit Ben :

Il n'y a pas vraiment de raison de rester dans cette branche, de toute façon nous devons maintenir l'ABI pour éviter d'énerver les gens.

Ben a également ajouté le code permettant de faire fonctionner la toute récente carte de type Kepler (GeForce GTX 680). Attention toutefois, puisqu'il ne s'agit pas pour l'instant d'exploiter la puissance de cette carte, le patch n'ajoute que le modesetting ce qui permet d'éviter d'avoir à se rabattre sur Vesa.

Les autres pilotes graphiques

Le pilote DRM dédié au Soc Samsung Exynos gagne une prise en charge de la norme HDMI 1.4 et un pilote virtuel permettant la gestion des écrans sans fil.

Côté AMD, on voit arriver la prise en charge des cartes Southern Islands (Radeon HD 7700, 7800 et 7900) ainsi que des processeurs Fusion de type Trinity. Les cartes Northern Islands reçoivent des patchs écrits par Jérome Glisse et permettant la prise en charge du tiling 2D.
Pour avoir une idée de la complexité du travail des développeurs de pilotes GPU, vous pouvez d'ailleurs aller lire ce post de Jérome dans lequel il raconte la difficile traque d'un bug affectant la sortie VGA des puces Llano.

Du côté d'Intel, le pilote i915 active enfin par défaut le mode d'économie d'énergie RC6 sur les puces Sandy Bridge. On trouve également la possibilité d'entrelacer les flux HDMI et SDVO en sortie ainsi qu'une amélioration des performances d'environ 10% grâce au patchs PGTT (Per-process Graphics Translation Table) et Swizzling.

HSI

Le noyau 3.4 accueille les patchs de Carlos Chinea, qui travaille pour Nokia, et permettant la gestion du sous-système HSI (High Speed Synchronous Serial Interface).
Il s'agit d'un bus série utilisé dans les téléphones mobiles et destiné à faire communiquer les « applications engines » (APE) avec le modem du mobile. HSI permet de multiplexer jusqu'à 16 canaux avec des latences faibles et une communication bidirectionnelle simultanée (full-duplex).

Pour l'instant, aucun pilote n'utilise ce nouveau bus série, mais Carlos a indiqué qu'il travaillait sur le support d'une carte TI OMAP. D'autres développeurs ont manifesté leur intérêt auprès de Linus afin qu'il accepte ces patchs (Several people piped up to say "yeah, we want this").

Sous-système remoteproc

Les systèmes complets sur une puce (SoC) contiennent souvent des cœurs de calcul très hétérogènes. Si on regarde par exemple le SoC OMAP 4 de Texas Instrument, on constate qu'il est constitué de deux processeurs Cortex-A9, de deux processeurs Cortex-M3 et d'un DSP de type C64x.
Comment faire dialoguer le plus proprement et le plus simplement possible ces divers cœurs de calcul ?

C'est ici qu'entre en scène le nouveau sous-système remoteproc et le mode de communication rpmsg qui ont été introduits dans le noyau 3.4.
Le sous-système remoteproc permet au processeur principal de contrôler plus simplement les divers processeurs hétérogènes qui existent sur la puce SoC. C'est une sorte de couche d'abstraction du matériel puisqu'il n'est plus besoin d'avoir des pilotes spécifiques pour gérer l'allumage (rproc_boot) ou l'extinction (rproc_shutdown) de ces processeurs spécifiques.
En plus de cette simplification qu'apporte remoteproc (voir la documentation), le bus rpmsg intégré permet au pilotes noyau de communiquer facilement avec les cœurs hétérogènes via une interface de type virtio. Un pilote d'exemple utilisant le bus rpmsg a été écrit par Ohad Ben-Cohen afin de faciliter le travail des futurs utilisateurs.

Le résultat net de ces changements c'est que les SoC peuvent maintenant disposer d'un sous-système générique de contrôle et de communication entre leurs divers cœurs hétérogènes de calcul. Au lieu d'avoir une prolifération de pilotes variés, il suffira maintenant d'utiliser remoteproc, en ajoutant juste un peu de code bas-niveau spécifique à la plateforme.

Chargement retardé des pilotes

Un mécanisme amélioré de chargement des pilotes lors du boot a été ajouté dans ce nouveau noyau 3.4.
Dans les machines modernes, les périphériques sont devenus très complexes avec souvent plusieurs blocs fonctionnels interconnectés. L'ennui, c'est que dans ces configurations, il devient très difficile de déterminer l'ordre dans lequel les pilotes respectifs doivent être démarrés.
Grant Likely, l'auteur du patch, décrit ainsi le problème :

Une « carte son » typique consiste en plusieurs périphériques : un ou plusieurs blocs codecs (souvent attachés via i2c ou spi), un bus son (souvent i2s), un contrôleur dma et une certaine quantité de code spécifique à la machine/architecture afin de tenir tout ça ensemble.
À l'heure actuelle le code du noyau doit faire une vraie gymnastique afin d'enregistrer tous ces composants dans la couche son et le pilote qui « tient tout ensemble » doit attendre que tous les autres pilotes soient chargés.

On voit donc qu'il s'agit là d'un problème de gestion des dépendances. Un pilote ne peut pas être chargé tant que les pilotes des autres composants ne sont pas déjà chargés. La solution semble donc simple : il suffit de déclarer une relation de dépendance entre les pilotes comme on le fait pour les diverses options dans les fichiers Kconfig de linux.
Le problème c'est que cette solution consistant à déclarer les dépendances ne marche pas dans le cas soulevé par Grant Likely et qui concerne les périphériques ayant plusieurs blocs fonctionnels interconnectés :

Considérez le cas où un pilote A dépend d'une ressource gpio qui est apportée par un pilote B. En théorie, il faudrait indiquer que le pilote A dépend du pilote B, mais en fait le pilote A n'a aucun moyen de savoir de quel pilote B il s'agit, puisqu'il est différent pour chaque système.

Ces « périphériques » ne sont plus vraiment des entités matérielles bien distinctes. Il sont formés à partir de nombreux composants séparés au niveau matériel et qui ne sont réunis que par une « glu » logicielle. La conséquence, c'est que le noyau Linux n'a aucun moyen de savoir quelles sont les dépendances entre ces composants tant que ceux-ci n'ont pas commencé à dialoguer.
Alors, comme dirait Lénine, que faire ?

La solution de Grant Likely n'est pas d'une élégance absolue mais elle constitue un progrès indéniable par rapport à la très vilaine collection de hacks qui est utilisée actuellement. Le patch « driver probe deferral mechanism » permet tout simplement à un pilote de signaler qu'il n'a pas toute les ressources nécessaire à son bon fonctionnement et que son chargement doit être retardé afin d'être tenté à nouveau plus tard.
Par exemple, un pilote SDHCI peut avoir besoin de la collaboration d'un contrôleur i2c GPIO avant de pouvoir fonctionner correctement.
Si le pilote du contrôleur est déjà disponible lors du chargement du pilote SDHCI, alors tout se passe bien et on ne change rien au comportement précédent. En revanche, si le pilote du contrôleur i2c n'a pas encore été chargé, alors un message -EPROBE_DEFER sera envoyé pour signaler le problème et le pilote SDHCI sera mis dans une liste d'attente (pending list). À chaque chargement réussi d'un pilote, le ou les pilotes en attente seront testés de nouveau pour voir si leurs dépendances sont satisfaites.
Comme indiqué dans le message d'annonce sur la LKML, c'est une approche « low-tech » mais qui a l'avantage d'être simple et de fonctionner correctement.

Améliorations dans Perf

L'outil de tracing intégré dans le noyau, perf, a été mis à jour avec de nombreuses nouvelles fonctions.
Tout d'abord, les fonctions top, stat et record peuvent maintenant examiner des groupes de threads ou de processus. Il suffit de fournir la liste des PID séparés par une virgule de cette façon : perf top -p 21483,21485. On peut également filtrer par utilisateur avec l'option --uid. Pour que perf se contente d'afficher les tâches tournant sous mon utilisateur, il suffira donc de faire un petit perf top --uid patrick.

Une autre nouveauté est la possibilité de faire du profiling de précision au sujet des branches de code exécutées par le processeur. Cette fonction se base sur un module récent des processeurs Intel, le LBR (pour Last Branch Record).
D'après les explications présentes dans le message d'Ingo Molnar, il suffit d'activer la fonction avec perf record -b pour ensuite avoir la liste des branches qui sont exécutées le plus souvent par le processeur.

Enfin, la fonction record de perf dispose maintenant d'une interface graphique basique en GTK. Elle manque encore un peu de fignolage puisque, entre autres, il n'est pas possible de profiler un système KVM invité et qu'il n'y a pas de tri des colonnes, ni de code couleur pour les pourcentages. C'est toutefois un ajout bienvenu et qui va s'étoffer dans les versions suivantes du noyau. Le patch a été écrit par Pekka Enberg et la fonction s'active avec perf report --gtk.
Bien entendu, c'est une occasion unique et inespérée d'ajouter pour la première fois une nimage une copie d'écran dans une dépêche noyau :

Statistiques

En ce qui concerne les statistiques du cycle de développement du noyau 3.4, le site LWN a publié son traditionnel article récapitulatif.

En terme de patchs, le total s'établit à 10 734 (au 11 mai) alors qu'il était de 10 449 pour le noyau précédent. Ce sont 1 271 développeurs différents qui ont contribué au moins un patch dans ce cycle et, comme la dernière fois, c'est Mark Brown qui est en tête de liste avec 284 patchs.

Si on classe les développeurs non plus en terme de patchs mais en terme de lignes modifiées, alors c'est Joe Perches qui occupe la première place. Il faut dire que Joe s'est attaqué à la remise en ordre du style de codage de nombreux fichiers afin qu'ils respectent les conventions Linux. On trouve, parmi de nombreux autres, ce monstro-patch de 10 000 lignes pour corriger les espaces et passer l'épreuve de checkpatch sans générer d'alertes : 314 files changed, 50359 insertions(+), 50455 deletions(-).
C'est un travail ingrat, mais qui est incontestablement utile, puisqu'il apporte de l'uniformité dans le code source du noyau.

Enfin, un coup d'oeil sur le classement des entreprises montre une nouveauté assez étonnante. En effet, pour la toute première fois, Red Hat abandonne sa première place au profit d'Intel (seulement 960 patchs contre 1 138 pour la firme de Santa Clara). Linux n'était pas menacé par la monoculture, mais c'est toujours réjouissant de voir que le classement des top contributeurs évolue.
Red Hat garde toutefois sa prééminence en terme de tags Signed-off, parce qu'elle emploie de nombreux lieutenants de Linus.

Lire les commentaires

Lors du prochain lundi des libertés numérique, CLX vous propose un atelier sur le chiffrement avec GPG. Cet événement se terminera par une « keysigning party ». Si vous ignorez ce que c’est, mais que les problématiques de vie privée et de confidentialité vous intéressent, venez nous rencontrer à l’UFJ, rue du mal assis à Lille le 21 mai à partir de 19h30.

Les éléments abordés seront principalement basés sur la signature électronique en pratique.

GPG, pourquoi/comment ?

• Rappels théorique, tailles de clé, et algorithmes

En pratique

• Ligne de commande
  • Création d’une paire de clés
  • Partager ma clé publique
  • Rendre accessible ma clé publique au reste du monde
  • Gérer son trousseau
  • Chiffrer et déchiffrer un document
  • Signer un document
  • Vérifier une signature
• En graphique : le cas Thunderbird
• Pour les développeurs : signer ses développements (commits git ou package)

• lien n°1 : CLX
• lien n°2 : Plan d'accès

Lire les commentaires

L'association Gulliver et la médiathèque de Vern-sur-Seiche vous invitent à participer à Libre sur Seiche, grande opération de découverte des logiciels et œuvres libres, du 22 au 26 mai 2012 à l’Espace culturel Le Volume.
Jeux vidéo, musique, littérature, cartes du monde, généalogie… De la technologie à la culture et au divertissement, l’univers du Libre est accessible à tous. Cette manifestation propose des démonstrations de logiciels, des rencontres, des débats et des animations.

• lien n°1 : Programme de la manifestation
• lien n°2 : Communiqué de presse
• lien n°3 : C'est ou ?
• lien n°4 : Le Volume

Au programme de la semaine :

• Du 22 au 26 mai : exposition sur le Libre
• Mercredi 23 mai de 14h à 17h : jeux sous licence libre
• Mercredi 23 mai à 20h : débat avec des artistes sur « l'Art et le Libre »
• Vendredi 25 mai à 20h : conférence-débat « Le Libre, j'y participe ! », autour d'OpenStreetMap, un projet de carte mondiale participative
• Samedi 26 mai (journée) : pôles à thèmes, démonstrations, présentations, pique-nique le midi

Lire les commentaires

Cette année le CRDP de l'académie de Versailles organise, le 27 juin 2012, un InterTice sur le thème des logiciels libres dans l'Éducation ainsi qu'une « Install party » Debian & Ubuntu.

Intertice Logiciels Libres, c’est une sélection d’ateliers pratiques destinés à vous présenter un large panel d’usages pédagogiques possibles avec des logiciels libres. Toutes les disciplines pourront y trouver de quoi enrichir leurs pratiques. En plus de ces ateliers et animations, nous avons l’immense privilège cette année de recevoir Richard Stallman en personne ! Il proposera une conférence sur le thème « Logiciels Libres et éducation ».

Venez échanger sur les usages pédagogiques des logiciels libres dans différentes matières telles que les sciences, les lettres, la musique…

• lien n°1 : Le site
• lien n°2 : Qui est Richard Stallman ?
• lien n°3 : L'évènement de l'an dernier

Lire les commentaires

Pour la troisème année consécutive, les hackeurs du Tetalab et les artistes de Mixart-Myrys unissent leurs talents pour vous présenter ce délicat mélange de technologies et de spectacles qui feront le bonheur des petits et des grands.

Tout ceci se passe au sein du Toulouse Hacker Space Factory.

Cet évènement grandiose se déroulera du vendredi 25 au dimanche 27 mai à Toulouse dans le surprenant hangartistique de la culture alternative situé au 12 rue Ferdinand Lassalle (près des Ponts Jumeaux). Ouverture des portes à 18 heures pour 72 heures presque non-stop d'activités destinées à tout le monde, et même aux non-geeks et leurs enfants. Vous pourrez par exemple apprendre à souder vous même votre zombadge.

Tous les détails sont dans la seconde partie de la dépếche

• lien n°1 : Site du THSF
• lien n°2 : Mixart Myrys
• lien n°3 : Où est-ce ?
• lien n°4 : THSF en 2011
• lien n°5 : Épicerie
• lien n°6 : Tetalab

Une idée du programme

• Conférences : Benjamin Bayart, Tor2web, Lord Epsylon, Jpeg2000, Tetaneutral…
• Ateliers : Snootlab, Arduino, Usinette, Blender, LinuxEdu…
• Concerts : Popthefish, Elektric Geïsha, Mutah+Béné, Filastine, Moldover…
• Installations : Rétrogaming, Labobyrinthe, Al1 & Ant1…

Le programme complet donne les détails pour les diverses conférences, mais aussi les performances live, les ateliers disponibles, et pour les nombreux concerts, sans compter les gens qui vont venir hacker le festival des hackers par des actions surprises ;-) À noter que la totalité des festivités du week-end est en entrée libre, mais qu'il sera demandé une « participation libre et nécessaire » permettant d'augmenter l'indépendance du lieu.

Que vous soyez jeunes parents ou vieux loup, plus intéressés par une conférence ou bien par une mise en pratique en atelier, hardcore hacker, joueur de pacman, ou bien festif jusqu'à pas d'heure : ce week-end est pour vous, dans ce lieu galactique de rencontres et partages des cultures et savoirs-faire qu'est Mixart-Myrys.

Et une jolie nimage qui indique qu'il y aura des possibilité de restauration sur place. Pour le repas d'ouverture, vendredi à 20h, une réservation par mail est demandée : reservation@mixart-myrys.org . Une autre jolie nimage d'un atelier, et une dernière pour la root.

Lire les commentaires

La core team Maarch est fière de vous annoncer la publication de la version 1.3 de Maarch Entreprise (licence GPL 3).

Maarch Entreprise est un Système d’Archivage Électronique (SAE) perfectionné, auquel sont ajoutées des fonctionnalités de Gestion Électronique de Documents (GED) et de Gestion Électronique de Courriers (GEC). Maarch Entreprise est un outil de production unique, entièrement open source et distribué sous licence libre.

La version 1.3 de Maarch Entreprise est une petite révolution car elle s'agrémente de fonctionnalités de gestion de contenu tous formats ! Et va toujours plus loin dans sa capacité à vous proposer des fonctionnalités de GED et de GEC performantes.

Pour découvrir toutes les nouveautés et installer cette nouvelle version, inscrivez vous à notre Install Party prévue le 15 juin 2012 dans nos locaux à Nanterre.

• lien n°1 : Install Party : les détails et inscriptions
• lien n°2 : Site communautaire
• lien n°3 : Accés aux démonstrations
• lien n°4 : Documentation des applications
• lien n°5 : Maarch et l’économie du Libre

Écrite en PHP 5, Maarch Entreprise est une application web optimisée pour la circulation et la conservation de documents dans un environnement certifiable NF Z 42-013, ISO 14721 (OAIS) et MoReq2.

Les nouveautés de la version 1.3 Module de gestion de contenu (Content Manager)

Le module de gestion de contenu ajoute une dimension ECM à notre solution SAE.

• Ajout de modèles de documents tout formats : En plus des modèles sous Open Office et Libre Office, Maarch Entreprise permet par exemple de gérer les modèles de document avec la suite Office sous Word, Excel ou Powerpoint.
• Signature électronique : La signature électronique de document est possible sous Maarch Entreprise par le paramétrage de documents signés sous Acrobat ou par le biais de clé de signature.
• Publipostage La fusion de modèles Microsoft Office, Open Office ou LibreOffice avec des données saisies dans les documents, courriers ou bases de contact.
• Réservation de documents : Lorsqu’un utilisateur souhaite modifier un document, une notification est envoyée aux personnes impactées et le document ne leur est plus accessible jusqu’à ce que l’utilisateur libère le document en question.

Notification par courriel et flux RSS

Le module de notification est amélioré afin de prévenir les utilisateurs de tout type d’évènement survenu dans l’application, par courriel ou flux RSS.

• Perfectionnement du système d’historisation : Le niveau de précision est affiné. Dans les versions précédentes de Maarch Entreprise tous les évènements étaient déjà tracés mais avec un niveau de précision moins fin.
• Notification : Les utilisateurs peuvent être prévenus d’évènements comme l’ajout de pièce jointe ou de note à un document ou courrier principal, d’évènements survenus lors du processus de traitement (qui a fait quoi, quand). Pour les administrateurs, une notification peut désormais leur être envoyée lors de la suppression d’utilisateur, la modification du plan de classement ou l’arrivée à la taille critique des espaces de stockage.

Accès à l’application depuis smartphone et tablettes

Maarch Entreprise 1.3 est accessible depuis smartphone et tablette, et permet l’ajout de notes sur les documents.

• Accès aux documents et aux corbeilles de traitement par Webapp : Tout type de document versé dans Maarch Entreprise est visible, en fonction des lecteurs de vos tablettes et Smartphone (pdf, suite office, etc..).
• Annotation des documents possible : Ajouter directement vos notes sur vos documents enregistrés sous Maarch Entreprise.

Perfectionnement de la recherche sur les corbeilles

L’objectif étant d’utiliser la recherche avancée pour effectuer des recherches dans les corbeilles de chaque utilisateur, et trouver ainsi de façon plus simple un courrier au sein de ses corbeilles. Il permet également une action directe depuis le résultat de la recherche.

• Corbeilles invisibles : Trouver un document même lorsque celui-ci n’est plus dans les corbeilles. Par exemple un courrier clos dont l’utilisateur est en copie . Le courrier n’est plus visible en consultation dans la corbeille des courriers en copie, mais peut être retrouvé grâce à cette recherche.

Choix du statut du document dès son versement

Les utilisateurs peuvent choisir à l’enregistrement / versement du document le statut de celui-ci et ainsi envoyer directement le document dans la corbeille correspondante. En version 1.2 et précédentes, un seul statut était possible au versement : NEW. À partir de la version 1.3, le statut des documents peut être « À Valider », « Clos »…

Amélioration des fonctionnalités courriers

• Pouvoir lier des courriers entre eux : Pouvoir, par exemple, lier un courrier sortant avec un courrier entrant afin de retrouver plus aisément vos réponses.

Diverses améliorations

• Supervision de l'application : Ajout de log au format « log4php », standardisation des logs pour intégration dans des outils professionnels tel que Nagios.
• Ergonomie : Ajout de logos, traductions, page de traitement…
• Installeur : Désormais un installeur vous aide à installer sereinement l'application.

Maarch Entreprise 1.2 en quelques chiffres sur 1 an d'existence c'était :
+ 10.000 téléchargements dans 160 pays ! (statistiques sourceforge.net)

Lire les commentaires

Nous sommes en milieu de mois et ceux qui ne sont pas encore passés par leur marchand de journaux ce mois-ci peuvent actuellement trouver en kiosque :

• GNU/Linux Magazine n° 149 ;
• Linux Pratique n°71 ;
• MISC n°61 et son dossier sur la sécurité (forcément) des bases de données ;
• GNU/Linux Magazine hors-série n°60 dédié à Android et ses bonnes recettes pour développer
• et enfin, Linux Inside n°4 qui s'intéresse au Dual Boot « parfait », du partitionnement à la création d'un menu de boot à votre image.

Et toujours trouvable en kiosque pour les retardataires, GNU/Linux Pratique Essentiel n°25, MISC hors-série n°5 sur le cryptographie et Planète Linux n°69.

NdM : la revue de presse est ouverte et collaborative. Si vous voulez parler de votre magazine préféré, ou prendre en charge un magazine spécifique, n'hésitez à nous rejoindre sur l'espace de rédaction de LinuxFr.org . Nous pourrons même vous faire gagner un abonnement au magazine choisi !

• lien n°1 : GNU/Linux Magazine n° 149
• lien n°2 : GNU/Linux Magazine hors-série n°60 sur Android
• lien n°3 : Linux Pratique n°71
• lien n°4 : MISC n°61
• lien n°5 : LinuxInside n°4
• lien n°6 : Revue de presse précédente (avril 2012)

GNU/Linux Magazine n° 149 titre sur Btrfs, le système de fichier destiné à remplacer ext3/ext4. Vous ferez un tour très pratique des fonctionnalités de ce FS qui met à niveau les FS classiques des distributions Linux : modification de la taille, compression à la volée, mise en place de RAID 0, 1 10, les snapshots (reposants sur les sous-volumes), le tout agrémenté des lignes de commande qui vont bien. Le plus long article reste cependant issu d'Open Silicium avec la mise en œuvre par le menu d'une caméra IP à moins de 40€. Vous apprendrez la bidouillabilité pour pas cher et un peu de temps si le sujet vous intéresse.

Toujours côté embarqué et/ou temps réel, vous découvrirez Migen, un framework Python pour maniper et générer des circuits logiques et Nife, un langage proche du Forth pour l'embarqué et l'application pratique de la transformée de Fourier pour faire du traitement de signal sur ARM. Sinon, ce numéro passe en revue les nouveautés du noyau 3.3, vous propose le guide d'installation de Gnome 2 et Java sur OpenBSD pour y développer dans ce langage, le déploiement de SNORT et Base pour la détection et l'analyse des détections d'intrusion. Pour finir, côté astuce, un proxy local pour gouverner tous les autres proxy !

Que les développeurs se rassurent, GNU/Linux Magazine hors-série n°60 pense à eux, ils n'ont pas été oubliés. Enfin, principalement les javaïstes avec un smartphone tournant sous Android, mais bientôt, les amateurs de Blackberry ou encore Tizen grâce ầ OpenMobile. Ces Cookbooks sur Android (successions de how-to) sont très pratiques pour monter en compétence rapidement sur des problématiques classiques ou un peu moins. Les articles, classés à mon avis par ordre de difficulté, sont organisés sous forme de repas, cookbook oblige :

• Les entrées vous permettront de faire face très rapidement à des problématiques courantes à quasiment toute application : comment faire un menu, utiliser les notifications, proposer un widget, stocker des paramètres, sans oublier l'inutile et barbant splashscreen.
• Les plats principaux vont un cran plus loin et proposent l'utilisation de Zing, de Google Maps et la géolocalisation, l'utilisation de SQLite pour la persistance, etc.
• Quant aux desserts, ils mettent en avant des fonctionnalités moins connues et/ou utilisées : le backup manager de Google pour archiver ses données dans les nuages, utile lors d'une réinstallation complète par exemple, le système de PUSH C2DM, les services web (XML-RPC) et l'affichage d'une page web
• Pour finir, la partie digestif vous propose d'installer les outils pour tester au mieux votre application, que ce soit en installant Android sur une VM ou de faire votre propre ROM Android

GNU/Linux Pratique n°71, toujours aussi éclectique, aborde tout un tas de sujets, mais l'audio (et le multimédia) sont un peu plus à l'honneur avec Ampache pour faire votre propre logiciel de streaming audio à la Deezer/Spotify, Audacity et sa dernière version et surtout la découverte très détaillée (avec mise en œuvre incluse) de Popcorn Hour, lecteur multimédia très complet. Parmi les autres sujets, l'installation de Subversion pour faire du LaTeX, la gestion de projets en ligne avec Feng Office, XWiki pour vos bases de connaissances, MODX comme système de gestion de contenu ou encore BSD comme OS au quotidien avec la version PC-BSD pour remplacer (avantageusement ?) une Ubuntu par exemple. Du côté des apprentissages et tutoriels, vous découvrirez comment fonctionnent les transactions sécurisées sur Internet (et comment créer votre propre certificat), la mise en place d'un serveur DHCP et d'un cache local de paquets logiciels. Et enfin, si d'aventure vous avez encore des réticences à contribuer à des logiciels libre, un dernier article battra en brèche les (faux) problèmes que cela pose.

Le dossier MISC n°61 s'intéresse à la sécurité des bases de données. Même si ce n'est qu'un pan de la sécurité d'un SI en général, c'est un très vaste sujet que MISC aborde via cinq articles touchant à différentes solutions :

• Tout d'abord la problématique de l'injection SQL : comment bien savoir les réaliser avec un article sur l'optimisation (cible : MySQL) de celles-ci, avant un second article destiné à mettre en avant les bonnes pratiques pour les prévenir.
• La présentation des faiblesses de configuration par défaut de MySQL 5.5 et SQL Serveur 2008 entraînant des soucis potentiels de sécurité, ainsi que les moyens de « durcir » les installations.
• Toujours sur les aspects de préventions, vous aurez une rapide présentation de GreenSQL, un pare-feu applicatif qui se positionne en reverse-proxy afin de filtrer les requêtes pour MySQL et PostgreSQL (en version FLOSS, la version propriétaire couvrant SQL Server).
• Enfin, un dossier sur la sécurité des données n'aurait pas été complet si Oracle n'avait pas été abordé. L'article dédié aborde la problématique d'élévations de privilèges (manuellement ou via Metasploit) et d'exécution de commandes (code Java grâce aux JVM embarquées).

Les autres articles en marge de ce dossier sont nombreux et abordent des thématiques variées. Parmi ceux-ci, j'ai noté l'« exploit corner » qui aborde une vulnérabilité Android permettant de passer root, le « pentest corner » qui montre, suite à des retours d'expériences d'audits de code que la sensibilisation des développeurs est indispensable, vous découvrirez qu'il est possible de mettre à mal la fameuse « plausible deniability » mise en avant par TrueCrypt et l'utilisation astucieuse des clés shellbags de Windows pour faire de l'analyse Forensique. Je vous laisse découvrir le sommaire détaillé.

Lire les commentaires

Lilypond est un logiciel destiné à produire des partitions musicales de qualité optimale. Il vient de remporter le premier prix de l'un des concours les plus prestigieux pour les logiciels libres musicaux. Il s'agit du concours international LOMUS 2012 (LOMUS comme LOgiciel MUSical) organisé chaque année par l'AFIM.

LilyPond est un logiciel de gravure musicale, destiné à produire des partitions de qualité optimale. Ce projet apporte à l’édition musicale informatisée l’esthétique typographique de la gravure traditionnelle. LilyPond est un logiciel libre rattaché au projet GNU.

L’AFIM est l’Association Française d’Informatique Musicale. Elle a pour but le développement de l’informatique musicale en France, de ses relations avec les autres disciplines artistiques et scientifiques, de ses liens internationaux. Elle pilote notamment l’organisation de Journées d’Informatique Musicale JIM et participe au comité de pilotage de Sound & Music Computing SMC.

NdM. : le second prix a été attribué à Pyo (un module Python de traitement de signal numérique sous licence GPLv3).

• lien n°1 : Résultats du concours LOMUS 2012
• lien n°2 : Lilypond
• lien n°3 : AFIM

Lire les commentaires

Dédié au monde scolaire, le logiciel libre Images Actives (CRDP de l'Académie de Versailles) permet de transformer une image en une petite animation interactive offrant notamment la mise en évidence de certaines zones et l'affichage de légendes. Jusqu'ici l'animation était exportée au format SWF (compilation à la volée basée sur le compilateur libre Flex).
Ce format posait le problème de l'accessibilité sur les appareils mobiles iOS. La question d'un export HTML5 était posée (voir la dépêche du 8 mai dernier annonçant la v1).

• lien n°1 : Le site Images Actives
• lien n°2 : Un exemple
• lien n°3 : Plugin jQuery images actives
• lien n°4 : DLFP : Images actives V1

Un modèle « tablettes numériques »

C'est chose faite depuis aujourd'hui (16 mai). Un modèle « tablette numérique » a été ajouté. L'image interactive peut être exportée au format HTML (exemple). L'utilisateur a la possibilité de compacter l'image source et les polices dans le fichier HTML afin d'obtenir un unique fichier. Il peut aussi obtenir un widget compatible avec le logiciel iBooks Author d'Apple afin d'insérer son animation dans un manuel scolaire sur iPad.

Quel que soit le système d'exploitation, Images Actives dispose d'un mécanisme de mise à jour : il suffit aux utilisateurs actuels de lancer le logiciel pour se voir proposer la nouvelle version.

Images actives tout-terrain

Le double export (SWF + HTML5) confère aux images actives une portabilité universelle : l'export SWF conserve une pertinence pour les environnements qui ne supportent pas HTML5 (parc de navigateurs anciens ou certaines applications telles que les tébéiciels - logiciels de tableaux numériques interactifs). L'export HTML5 permet de cibler les appareils mobiles qui excluent Flash. En réalité, tant l'export Flash que l'export HTML5 sont basés sur le format SVG. Le fichier source (extension .xia) est une archive contenant des fichiers svg, xml, css plus les images, les sons et les polices ajoutés par l'utilisateur. Tout a été fait pour garantir aux utilisateurs la pérennité de leurs contenus.

Ouvrir le développement

L'export HTML5 ne propose pas encore toutes les fonctionnalités de l'export Flash : si le zoom ou le mode "quiz" ont été portés en HTML5, il y manque encore la possibilité d'enregistrer des légendes audio. Celles-ci ne sont proposées qu'en export SWF. Tout a été fait, cependant, pour que l'export HTML5 puisse évoluer : il est implémenté sous la forme d'un plugin jQuery. Ce choix témoigne d'une réelle volonté d'ouverture du développement à la communauté.

Lire les commentaires

Je viens de finir un petit projet en Go la semaine dernière, un assembleur vers du MIPS simplifié. Voici un petit retour d'expérience, en espérant que ça serve !

NdM : merci à G.bleu pour son journal.

• lien n°1 : Journal à l'origine de la dépêche
• lien n°2 : gopiler

Sommaire

• Mise en situation
• Le programme
  • Rentrons dans le code
  • Et Go dans tout ça ?
    • Le makefile
    • Les tests
    • Le multiplatforme !
    • Les outils en plus
  • Écrivons un peu de code
    • Le retour de plusieurs variables
    • La gestion des options
    • Les conteneurs
      • Map
      • Array
      • Slice
    • L'héritage
      • Les structures
      • Les méthodes
      • Les interfaces
    • Les autres fonctionnalités
      • Les goroutines
• Conclusion

Mise en situation

Pour mes études, j'ai un projet (le dernier avant la vie active !) de réalisation de microprocesseur MIPS « from scratch ».

Le CPU est designé sous Xilinx ISE (grosso modo un IDE dans lequel on peut réaliser des designs de composants à base de portes logiques). Par la suite, il sera chargé sur un FPGA, celui-ci connecté à un robot afin de lui faire suivre une ligne sur le sol.

De fait, une fois le CPU designé, il faut réaliser un programme en assembleur MIPS, puis le convertir en binaire afin de l'intégrer dans le design du CPU sous la forme d'un module en VHDL. En gros, en entrée du module arrive l'adresse du program counter et le module sort l'instruction correspondante.

Les plus attentifs auront déjà pointé du doigt le souci : comment convertir proprement le code assembleur MIPS en binaire ?

• À la main, ne riez pas, c'est ce que m'a proposé mon prof quand je lui ai posé la question ! À sa décharge, les élèves suivant ce cours ne sont pas informaticiens mais plutôt orientés électronique.

• Utiliser un assembleur déjà existant. La solution « ne pas réinventer la roue » de référence. Le problème : l'output sera en binaire (logique, me direz-vous) mais je veux du code binaire lisible ! (en gros mon output doit être 000101011100110 afin de pouvoir directement copier coller le code dans le fichier de mon module VHDL). Ajouter à cela que je ne veux pas de header ELF ou quoi que ce soit, juste la transcription du code que j'ai écrit. Je pense, bien-sûr, qu'il y a des solutions pour arriver à ce que je veux. Néanmoins, j'ai du temps en ce moment et apprendre un nouveau langage me semble plus formateur qu'apprendre les options d'un outil qui ne me servira plus par la suite !

• Écrire un assembleur à la main. La solution que j'ai choisie, et qui me donne donc la possibilité de réaliser ce journal ! Un assembleur n'est pas aussi complexe qu'un compilateur (et de loin !), mais permet déjà de s'amuser sur un nouveau langage.

Le programme

Linus Torvald :

Show me the code !

Céans mon bon monsieur ! En espérant que tout le monde aime SourceForge…

Comme dit plus haut, il s'agit d'un assembleur MIPS « simplifié » :

• Toute les instructions ne sont pas disponibles (pas de jump ou de subi par exemple). La raison est tout simplement que mon processeur ne prend pas en charge ces instructions et que je préfère avoir une erreur à la compilation si j'oublie ce détail que de devoir débugger une erreur qui n'en est pas une par la suite… Malgré tout, il est très simple d'ajouter ces fonctionnalités comme nous allons le voir.

• Pas de header ELF pour le programme. Comme j'ai dit, l'idée est de copier la sortie de l'assembleur dans un fichier pour que mon cpu l'utilise "tel quel". Pas d'OS, pas de logique supérieure, rien ! Donc, pas besoin d'header.

Rentrons dans le code

J'ai divisé mon assembleur en 3 parties :

• Le parser/lexer : réalisé avec yacc pour le premier. On vérifie la grammaire et la sémantique afin de générer une liste d'instructions sous la forme d'un tableau de structures ainsi qu'une map faisant la conversion nom des label => adresse.
• Le binder : transforme chaque instruction du tableau précédent en une instruction binaire à proprement parler (avec vérification en fonction du contexte)
• Le main : qui wrap ces deux parties, les connecte entre elles et gère les options fournies par la ligne de commande.

Et Go dans tout ça ?

Il convient avant tout de parler un peu de la philosophie de Go avant d'aller plus loin.
En effet, l'idée est de fournir des outils tout prêts à l'utilisateur. On se base sur un maximum de règles standards et donc un minimum de configuration (voire en fait pas de configuration du tout dans bien des cas !).

Le makefile

L'exemple le plus frappant de ce concept est le makefile. Si dans les versions antérieures à la 1.0, Go possédait un simili makefile (il était déjà beaucoup plus simple qu'un makefile typique pour du C), tout cela est révolu !
Maintenant un projet Go n'a besoin pour compiler que de ses sources. Un coup de "go build" et tout se fait tout seul. Plus de gestion des dépendances, plus de problèmes de conflits d'includes (de toute façon, il n'y a pas d'include en Go)… voilà qui devrait intéresser, je pense, tous ceux qui se sont essayés à C++ et à ses célèbres erreurs de compilation hyper-verbeuses, pour cause de conflit de define pour avoir placé un include au mauvais endroit.

Petite remarque tout de même : Mon projet contient un makefile !
Bien que minimaliste, celui-ci est donc toujours présent.
La raison est multiple :

• La commande "go build" construit votre binaire… et c'est tout ! J'aime pouvoir automatiser la génération de tarball, le nettoyage du projet, etc.

• Mon projet utilise yacc (donc conversion du fichier parser.y en parser.go). De fait, go build ne met pas à jours parser.go si parser.y est mis à jour. D'où la nécessité de gérer cette dépendance

Les tests

De la même manière, réaliser des tests est simplissime. Pour écrire des tests pour le fichier foo.go, vous n'avez qu'à créer le fichier foo_test.go et… c'est tout ! Ce fichier se fera automatiquement compiler et ses fonctions commençant par Test seront exécutées à chaque lancement de "go test".

Dans le fichier, on importe le package "testing", et on appelle la méthode testing.T.Fail() ou testing.T.Error("C'est la dèche !") pour signaler que le test a échoué :

import "testing" func TestFoo(t *testing.T) { // Les fonctions de test commencent par Test // et respectent cette signature if test_is_ok() != nil { t.Error("t'es parti pour fixer ton code !") // Erreur avec message } if test_sans_message != nil { t.Fail() // Erreur sans message } // Si aucun appel à Fail ou Error, alors le test est considéré comme réussit } Le multiplatforme !

Encore une très bonne nouvelle : Go est multiplatforme de base !
Voulant partager mon logiciel avec mes petits camarades (Je précise que je suis en Corée du Sud actuellement… pas la peine de dire quel OS utilise tout ce joli monde !), autant dire que cette fonctionnalité a fortement pesé dans la balance pour le choix de Go.

En outre, selon la doc il est possible de cross-compiler à partir de n'importe quelle platforme pour n'importe quelle autre juste en changeant ses variables locales comme GOOS ou GOARCH (et bien-sûr en compilant sa chaîne de compilation pour l'architecture cible). Toutefois, je n'ai pas testé cette possibilité, j'ai préféré rebooter sous windows (à ma décharge, j'aurais de toute façon dû le faire pour vérifier que mon binaire fonctionne bien !)

J'ai toutefois trouvé un peu bizarre que la gestion du retour à la ligne ne soit pas fournie comme en C++ (avec std::endl). De fait, on doit faire attention à ce léger détail et différencier les cas selon les OS à la main, ce qui est assez dommage.

Les outils en plus

En bonus, go fourni des outils des plus sympa :

• go fmt
  Cette commande permet de mettre à LA norme le code. Notez le "LA" majuscule, il n'y en a qu'une (certains diront qu'elle est horrible mais nous ne sommes pas vendredi, je laisse cela à d'autres). Du coup, pas de conflits à ce niveau, tous les codes go écrits pas tous les développeurs du monde auront la même forme.
  Petit bémol pour ma part : cette norme utilise des indentations de 8 caractères et ne coupe pas le code à 80 colonnes. Résultat, celui-ci est bien souvent trop long à mon goût (ainsi qu'à celui de mon Emacs en multicolonnes. Là où je peux mettre 3 colonnes en C la plupart du temps, je suis limité à 2 en go… 33% d'espace perdu, snif !)

• go tool yacc
  La commande go tool permet d'accéder à la foultitude d'outils intégré dans la commande go. Parmi eux se trouve yacc, le célèbre parser. Cette version est une réécriture en go de celui de plan9. Autant dire que sa présence à été déterminante dans mon choix d'utiliser go pour mon projet (un parser à la main… non merci !)

Écrivons un peu de code

Après tout ce temps à parler des outils, parlons du code, du vrai !

Le retour de plusieurs variables

En voilà une bonne idée ! Toute fonction peut renvoyer plusieurs variables au lieu d'une seule dans la plupart des langages.
De fait, on retrouve dans la lib standard de Go un bon nombre de fonctions renvoyant à la fois la valeur qu'on leur demande ainsi qu'un type "*Error" pouvant être soit "nil" (c'est-à-dire pointer sur rien) soit initialisé, signifiant alors une erreur. Plus besoin de "tricher" - comme en C - en donnant en argument de la fonction un pointeur sur la variable à compléter, puisque la variable de retour est déjà occupée par le code d'erreur.
De même, le parcours de tableau s'en trouve simplifié :

for i,elm := range array { fmt.Println("l'élément", i, "a pour valeur", elm) }

range est un mot clé permettant de parcourir un tableau en renvoyant, à chaque itération, la position ainsi que l'élément courant.
Notez aussi le ":=" permettant de déclarer "à l'arrache" des variable en fonction du type de la variable qu'on lui assigne. Un vrai bonheur pour gagner en lisibilité dans les cas triviaux.

La gestion des options

Encore une bonne nouvelle ! La gestion des passages d'options étant une fonctionnalité essentielle à 90% des logiciels, le package "flag" s'occupe de cela avec brio !

import "flag" var f_input = flag.String("i", "", "Input file.") var f_output = flag.String("o", "", "Output file. (stdout if nothing specified)") var f_type = flag.String("t", "vhdl", "Type of output : binary, print, vhdl") func main() { flag.Parse() fmt.Println("lecture du fichier", *f_input) ... }

Ai-je vraiment besoin d'expliciter ? On déclare les flags en dehors des fonctions, on appel flag.Parse() avant d'utiliser les flags (notez qu'il s'agit de pointeurs, on met donc une "*" pour les déréférencer)
Remarquez que l'option --help/-h est gérée automatiquement !

Les conteneurs

Go possède de manière intégrée au langage les conteneurs les plus utilisés :

Map

Son nom est suffisamment explicite : une clé, une valeur.
Problème, selon moi : si la clé ne correspond à aucune valeur, la valeur nulle est renvoyée. De fait, dans mon programme, j'utilise une map pour faire la correspondance entre les labels et leur adresse réelle. Si je demande l'adresse d'un label inexistant, la map va me renvoyer la valeur 0, puisque c'est l'équivalent de la valeur nulle pour un int…
Problème : cette valeur peu tout à fait être valide dans le cas d'un label situé en début de code ! C'est d'autant plus étrange que le langage autorise le renvoi de plusieurs valeurs, comme nous l'avons vu précédemment…

Array

Un joli tableau unidimensionnel de taille constante… rien à redire.

Slice

Un type fourre-tout : c'est un genre de tableau à taille variable.
En réalité, le slice - comme son nom l'indique - représente un morceau de Array. De fait, plusieurs slices peuvent pointer en même temps sur le même Array, par exemple.

Je cherchais à utiliser un vecteur pour stocker chacune de mes instructions une fois parsées/lexées. J'ai eu la surprise de voir que le conteneur Vecteur avait été supprimé de la bibliothèque standard il y a quelques commits…
La réponse s'est trouvée sur la mailling list de Go : utiliser des slices !
Voici comment faire :

var s0 := []int{0, 1} // on créé un un slice sur un tableau contenant 0 et 1 var to_insert = 42 S0 = append(s, to_insert) // on utilise la fonction buildtin "append"

Simple ? Bon maintenant, voyons comment supprimer l'élément numéro i (en C++ j'aurais fait "vect.remove(i)")

s0 = append(s[:i - 1], s[i + 1:]...)

Pas glop ! Je pense qu'un peu de sucre syntaxique n'aurait pas été de trop pour cacher cette complexité inutile !
Pour ceux qui se posent la question, append ajoute des éléments à un slice. De fait, on doit transformer le slice s[i + 1:] en une suite d'élément avant de l'ajouter à s[:i - 1]. C'est ce qu'on fait avec la commande "s[i + 1:]…"

L'héritage

Dans Go l'héritage dans la grande tradition OO n'existe pas ! (et ce n'est pas pour me déplaire à titre personnel).
Le tout s'articule autour de trois concepts (que je n'illustrerai pas avec mon programme puisse que celui-ci n'en n'utilise pas le premier.)

Les structures

Plutôt que de déclarer des classes, on crée des structures. Celles-ci pouvant gérer l'héritage d'une façon amusante :

type plat struct { name string } type choucroute struct { plat saucisses int } func main() { ch := choucroute{plat{"choucroute"}, 4} fmt.Println("Je vais me tapper une", ch.name, "avec ", ch.saucisses, "saucisses dedans !") // ces deux lignes sont rigoureusement identiques fmt.Println(ch.name) fmt.Println(ch.plat.name) }

On remarque donc que, en ajoutant dans choucroute une structure plat de manière anonyme (le nom "_" l'équivalent en Go de John Doe…), les éléments de plat sont intégrés dans choucroute !

Les méthodes

Une fois notre jolie structure déclarée, il est possible de lui adjoindre des méthodes :

func (ch Choucroute)manger() { ch.saucisses-- fmt.Println("Miam ! Encore", ch.saucisses, "saucisses !") } func (_ Plat)manger() { // remarquez le "_" pour indiquer qu'on ne fera rien avec l'objet et qu'il n'est donc pas nécessaire de le nommer. fmt.Println("Beark !") } Les interfaces

En Go, tout se base sur du Duck typing. De fait, afin de pouvoir manger à la fois un plat de seconde zone ou de la délicieuse choucroute, on peut déclarer une interface qui contiendra la fonction manger :

type mangerer interface { manger() } func main() { bouffe := []mangerer bouffe = append(bouffe, choucroute{ "choucroute", 4 }) bouffe = append(bouffe, plat{ "bouts de tétons de mme Félipé" }) for _, pl := range bouffe { pl.manger() } }

De fait, le duck typing faisant son travail, notre slice peut contenir n'importe quelle structure possédant une fonction ayant pour signature "manger()".

Au final, un gain de légèreté monstrueux comparé au C++ et à ses déclarations d'objets et d'héritage particulièrement verbeuses.

C'est beau, c'est simple, ça me fait pleurer !

Les autres fonctionnalités Les goroutines

Bien sûr, je n'ai pas pu tout tester dans mon programme.
Je pense notamment à une des principales fonctionnalités mise en avant : la concurrence.
Mon programme n'utilise qu'un fil d'exécution. De fait, je n'ai pas pu utiliser les channels ni le mot clé go.
Toutefois, ayant déjà fait un peu joujou avec par le passé, j'ai trouvé l'idée vraiment excellente. Les channels permettant à une routine d'attendre qu'une autre lui envoie un objet pour continuer. De fait, on résout le soucis de synchronisation de manière beaucoup plus simple qu'en plaçant des mutex sur les ressources critiques !

Conclusion

Je suis globalement très satisfait de Go, j'ai l'impression d'un langage rapide, et ce dans tous les sens du terme :

• Rapidité de compilation.
  Quasi instantanée ! (dois-je comparer à un poid lourd comme C++ ?)

• Rapidité de développement.
  Tout va très vite. Le duck typing permet de redéfinir ses structures très rapidement, on n'écrit que le minimum.
  De même, tout le monde est convaincu de l'importance des tests, mais la flemme nous fait généralement (en particulier pour les petits projet comme le mien) tester à la main la fonctionnalité sur laquelle on travaille actuellement et basta !
  De fait, le système de test intégré à Go est, pour moi, un pur bonheur, tant il est simple et efficace !

• Rapidité d'exécution.
  Le débat est lancé ! Pour certains, le compilateur de Go est trop jeune et pas suffisamment optimisé (ce qui explique sa vitesse de compilation).
  Les auteurs de Go ont notamment publié un article pour battre en brèche cette idée en montrant comment obtenir des performances proches du C++ en optimisant son code.

D'un autre côté, il s'agit d'un langage jeune, avec tous les problèmes inhérents :

• Peu de bibliothèques tierces pour le moment. Au vu de la simplicité d'interfaçage de Go avec C, des projets de bindings de grosses bibliothèques fleurissent un peu partout, mais pour le moment rien de très stable/utilisable.

• Un compilateur jeune.
  En effet, pour le moment le runtime est compilée statiquement dans le logiciel. Cela explique la taille supérieure au mégaoctet du moindre "hello world". Par exemple, mon logiciel faisant dans les 800 lignes de Go se retrouve compilé dans un binaire de 1.6 Mo…
  Enfin bon, vue la taille actuelle de nos disques durs et tant que Go n'aura pas pour vocation de tourner sur de l'embarqué, je ne suis pas sûr que ce soit un si gros point noir.

Lire les commentaires

Alter Way lance sa deuxième édition de la Libre Académie. La Libre Académie est un cursus d'intégration de nouveaux collaborateurs qui comprend plus de 200 heures de formations.

Le premier bilan de ce programme a été positif. Après un choix parmi 200 candidatures, 5 personnes ont été recrutées de manière définitive (sur 6). Trois ont suivi le cursus Administrateur Système et les autres le cursus Développeur Web. Un tiers de la promotion a intégré la formation dans le cadre d'une reconversion professionnelle.

La deuxième promotion sera exclusivement orientée sur des cursus Développeurs : Web et S.I.. Deux sessions seront proposées :

• Une qui s'orientera vers le métiers de Développeur PHP5/Drupal nommée « Développeur Digital (sic) ».
• La seconde mettra davantage l'accent sur le Système d'Information avec PHP5 et les frameworks Zend et Symfony. Une nouveauté sera d'intégrer systématiquement dans les cursus une approche DevOps. Elle permettra aux développeurs de mieux comprendre l'importance du travail collaboratif et de l'agilité et des impératifs… Le parcours de formation d'une durée de 4 mois, mêle théorie, pratique et contributions.

Cette deuxième édition s'adresse à tout jeune diplômé, autodidacte, personne en reconversion bref toute personne qui veut travailler dans le libre.

• lien n°1 : Pour candidater à la Libre Académie

Lire les commentaires

La Guilde (Guilde des Utilisateurs d'Informatique Libre du Dauphiné) organise un atelier d'initiation à Dolibarr animé par Fernando Lagrange, ce mardi 22 mai, de 18h à 21h dans les locaux de l'Ensimag à Saint Martin d'Hères.

Tous les détails sur cet événement dans la suite de la dépêche.

NdM.: Dolibarr est un « progiciel de gestion intégré (PGI, ERP en anglais) et gestion de la relation client (GRC, CRM en anglais) open source pour les petites et moyennes entreprises, les indépendants, auto-entrepreneurs ou les associations. »

• lien n°1 : Ateliers de La Guilde
• lien n°2 : Site de La Guilde
• lien n°3 : Lieu du rendez-vous
• lien n°4 : Site officiel Dolibarr
• lien n°5 : Page wikipedia Dolibarr

Conditions d’accès

L'atelier est gratuit mais limité à 12 participants. Il est donc impératif de s’inscrire à l'avance par courriel à : contact AT guilde POINT asso POINT fr ou bien directement sur la page des Ateliers de notre wiki. Il n'est pas nécessaire d’être membre de notre association pour y participer mais la priorité sera donnée aux adhérents si il y a trop de demandes. Possibilité d'adhésion sur place.

Adresse
681, rue de la passerelle
Domaine universitaire
38402 Saint Martin d'Hères

En attendant la fin des travaux, la salle est l'amphi E1 (le même que celui des conférences habituelles).

Matériel

Bien noter qu'il faut apporter son propre ordinateur. Le logiciel Dolibarr comporte énormément de fonctionnalités. L'atelier portera essentiellement sur l'aspect « facturation ».

Contact

En cas de besoin, vous pouvez contacter Fernando Lagrange le président de la Guilde (fernando CHEZ demo-tic.org).

Lire les commentaires

Le mois passé était organisée la Foire du Libre 2012 du Louvain-li-Nux sur le campus de Louvain-la-Neuve (Belgique).

À cet événement, des conférences ont été enregistrées et sont maintenant disponibles en ligne. Voici la liste:

• Réaliser un syllabus sous licence libre, c'est possible! par le professeur Olivier Bonaventure - Vidéo.
• Présentation de Multipath TCP, une nouvelle fonctionnalité pour le noyau Linux par Christoph Paasch du département d'informatique de l'UCL - Vidéo.
• iCampus, la plateforme de cours en ligne de l'UCL utilisant Claroline par les responsables du projet - Vidéo.
• La communauté Mozilla par un membre de la communauté - Vidéo.
• CommunesPlone, la gestion de sites web (et plus encore) de la plupart des communes wallonnes par Joël Lambillotte de CommunesPlone - Vidéo.
• Le modèle économique d'OpenERP et les services proposés par Fabien Pinckaers, CEO d'OpenERP - Vidéo.
• Comment gagner de l'argent avec du Libre par Lionel Dricot (ploum) - Vidéo.

En espérant que ces conférences vous plaisent,
Bon visionnage et bonne journée!

• lien n°1 : Playlist de l'événement
• lien n°2 : Page Youtube du Louvain-li-Nux
• lien n°3 : Louvain-li-Nux

Lire les commentaires