Accueil › Agrégateur de nouvelles › Sources ›

Linuxfr.org

Version imprimableVersion imprimable
Syndiquer le contenu
URL: https://linuxfr.org/news
Mis à jour : il y a 12 heures 37 min

Mageia 6 est sortie

20 juillet, 2017 - 21:35

La très attendue Mageia 6 est enfin disponible. Des problèmes de compatibilité avec des périphériques pas très libres — mais très utilisés — sont la cause principale de ce retard.

En attendant cette sortie, la communauté des développeurs avait publié la robuste version 5.1 qui sera maintenue pendant encore 3 mois. L'enjeu était de faire mieux et d'éviter les régressions.

De nombreux testeurs utilisent au quotidien cette version depuis la parution de la RC. Elle semble tenir toutes ses promesses :

  • passage à Wayland par défaut pour GNOME (Xorg reste disponible) et vous pouvez l'essayer avec KDE Plasma
  • ajout du media « Live » avec l'environnement Xfce aux côtés des classiques KDE Plasma et GNOME, le tout sous grub2 remplaçant de grub1
  • ajout de dnf2 en tant que gestionnaire de paquetages alternatif au classique urpmi et de l'interface graphique dnfdragora en plus du classique rpmdrake
  • prise en charge d'AppStream pour ajouter des méta-données aux outils comme GNOME Software et Plasma Discover pour découvrir des logiciels à installer
  • retour de la portabilité sur processeur ARM (pour les plus aventureux)
Sommaire Les nouveautés principales de Mageia 6

Bien qu’il ne s’agisse pas d’une nouvelle fonctionnalité, Mageia 6 prend en charge plus de 25 environnements de bureau et gestionnaires de fenêtres (les détails seront disponibles lors d’une prochaine publication sur le blog) ! Que ce soit KDE Plasma 5.8.7 (LTS), GNOME 3.24.2, MATE 1.18, Cinnamon 3.2.8, Xfce 4.12.1, LXQt 0.11…

KDE Plasma

Le passage de Qt4 à Qt5 permet d'alléger notablement KDE Plasma que l'on ne peut plus qualifier de lourd.
Presque toutes les applications KDE 4 ont été migrées vers Plasma, de sorte que vous bénéficierez d'une belle expérience unifiée.

GNOME

Wayland est activé par défaut, l'utilisation de Xorg reste possible au besoin, si votre matériel est défaillant. Sur chipset Intel (voire AMD et sans doute nVidia), le HDMI est géré de base pour envoyer la vidéo vers un LCD, le bluetooth aussi pour envoyer l'audio sur votre chaîne HiFi.

Les extensions gnome-shell les plus classiques sont disponibles en paquets de base : hibernate-status, alternate-tab, apps-menu, auto-move-windows, common, drive-menu, launch-new-instance, native-window-placement, onboard, overrides, places-menu, screenshot-window-sizer, user-theme, window-list, windowsNavigator, workspace-indicator permettant d'utiliser GNOME au clavier efficacement tout en conservant quelques fonctionnalités utiles.

XFCE et les autres…

Une version « Live » est distribuée en ISO aux côtés de KDE Plasma et GNOME pour permettre de tester un environnement plus léger. Vous pouvez tester sur clé USB ou DVD. Voici la gamme complète des ISO de Mageia :

  • 32-bit Installation classique DVD
  • 64-bit Installation classique DVD
  • GNOME 64-bit Live DVD
  • Plasma 64-bit Live DVD
  • Xfce 32-bit Live DVD
  • Xfce 64-bit Live DVD
En synthèse des mises à jour

Tous les logiciels dans les dépôts ont été reconstruits et mis à jour pour inclure les derniers et les plus important logiciels de l’écosystème open source, vous trouverez ci-dessous quelques-uns des principaux composants inclus dans cette version :

  • Système de base : noyau Linux 4.9.35 (LTS), systemd 230, X.org 1.19.3, Wayland 1.11.0, Mesa 17.1.4
  • Toolkits : Qt 5.6.2 (LTS), GTK+ 3.22.16
  • Environnements de bureau : Plasma 5.8.7 (LTS), GNOME 3.24.2, MATE 1.18, Cinnamon 3.2.8, Xfce 4.12.1, LXQt 0.11
  • Applications : LibreOffice 5.3.4.2, Firefox 52.2.0 ESR, Thunderbird 52.2.1, Chromium 57
Dans le détail des nouveautés de Mageia 6 Prise en compte de Wayland

wayland est un protocole de serveur d'affichage plus simple et plus efficace que l'architecture de Xorg qui utilise un gestionnaire de fenêtre composite fonctionnant de concert avec le X Window System.

Avec l'introduction des compositeurs (permettant des effets de transparence, d’ombre portée, etc), X.Org ne peut plus être performant car il constitue une étape supplémentaire entre l’application et le compositeur ainsi qu’entre le compositeur et le matériel.

Wayland a été proposé pour succéder à X11 : un serveur Wayland joue à la fois le rôle de compositeur (gestionnaire de fenêtres) et de serveur d’affichage.

Wayland est donc une évolution majeure dans l'architecture Linux même si elle n'est que peu visible pour la majorité des utilisateurs. Une couche logicielle est fournie pour faire fonctionner les anciennes applications.
Une conséquence possible de la disponibilité de wayland devrait être la disponibilité de jeux nécessitant un affichage performant.

MCC : le Centre de Contrôle Mageia

Cet utilitaire qui permet de configurer le système contribue fortement à la réputation de Mageia. Il est hérité de Mandrake puis de Mandriva Linux et s'est perfectionné au fil des années et des versions. Il a bénéficié d'une heureuse cure de jouvence. De nouvelles icônes ont joliment amélioré la convivialité de MCC.


Cette illustration vient de la version anglaise mais rassurez-vous, Mageia vous propose une version française lors de l'installation. Mageia est certainement la plus française des grandes distributions.

Ajout de DNF2

Proposé par Fedora, dnf a été logiquement intégré à Mageia. Il est disponible en plus de l'outil classique d'installation urpmi.

Les apports de AppStream

Les utilisateurs bénéficient de l'outil dnfagora dans la continuité de rpmdrake, pour une interface graphique améliorée et cohérente. Cela permet à l'utilisateur de rechercher un logiciel correspondant à son besoin, en se basant sur des meta-données consolidées entre distributions.
C'est un apport en complément du travail de Debian pour http://madb.mageia.org avec les copies d'écran des applications graphiques, il y a aussi la possibilité de participer à la QA de Mageia

Mageia 6 pour l'architecture ARM

Le port ARM (re-)prend vie : démarré avec Mageia 1, il est désormais disponible sur les miroirs pour architecture armv5tl et armv7hl (respectivement ARMv5 et ARMv7, ce qui inclut le RaspberryPi). Attention, cela reste réservé aux aventureux, des images d'installation pourront être disponibles par la suite, si suffisamment de personnes se montrent intéressées.

Par exemple, les serveurs de base de données PostgreSQL 9.4 et 9.6 sont disponibles : http://madb.mageia.org/package/list/t_group/68/application/0/arch/armv7hl/page/2
Pour ceux intéressés, vous pouvez aussi suivre le statut des paquets inclus selon l'architecture : https://pkgsubmit.mageia.org/arm-status.html

Participer à l'activité de Mageia et de sa communauté

Nos amis francophones de MLO sont très actifs dans le soutien en français aux utilisateurs de la distribution avec tutoriels et forums officiels pour Mageia.

Pour autant, la difficulté à sortir une distribution dans les temps a pesé pour certains :

  • Mageia 5 est sortie en juin 2015
  • Mageia 5.1 est sortie en décembre 2016
  • Mageia 6 arrive enfin en juillet 2017 pour une date initiale (re-)planifiée en mars ou mai 2017, mais initialement prévue en août 2016, reportée à décembre 2016 pour diverses raisons.
  • entretemps cauldron (la version de dév') a continué d'évoluer, pris en compte Wayland notamment, des mises à jour de beaucoup de logiciels (et de jeux) sur le mode rolling release (« jouez aux dés », si vous en avez envie, c'est votre choix, cela a été le nôtre pendant toute cette période).

C'est un vrai travail de motivation et de recrutement, d'accueil de nouveaux contributeurs qui a permis la sortie de cette version Mageia 6. En bref, vous êtes les bienvenus à rejoindre le projet et à le faire perdurer (ce qui nous tient à cœur et nous motive, pouvant permettre à chacun d'apprendre beaucoup plus qu'il n'en aurait espéré de son passage sous Linux). Les contributeurs à Mageia sont présents sur la plupart des événements du libre : Fosdem, RMLL, JDLL, POSS, premier samedi, kernel-recipes… n'hésitez pas à venir à notre rencontre.

Comme Mageia 5 est bien maîtrisée, vous avez au moins jusqu'au 31 octobre 2017 pour passer à Mageia 6 qui — elle — vous permettra d'être tranquille jusqu'au 16 janvier 2019 :-)

Bon passage à Mageia 6 _o/* !

Télécharger ce contenu au format Epub

Lire les commentaires

Matrix pour décentraliser Skype, Whatsapp, Signal, Slack et Discord

20 juillet, 2017 - 20:15

Matrix est un projet libre (licence Apache v2) définissant une nouvelle base (un ensemble d'API HTTP) pour une communication décentralisée, fédérée et temps réel.

TL;DR Pour se faire une idée rapidement, le plus simple est de cliquer ici et de voir immédiatement à quoi cela ressemble en pratique : accès au salon LinuxFr via le client Riot.

Sommaire Présentation

Matrix propose de la communication décentralisée, mais ce n'est pas de la communication distribuée (contrairement à Tox par exemple), donc pour fonctionner cela nécessite quand même au moins un serveur (plusieurs serveurs pouvant être fédérés) que l'on appelle communément « homeserver ».

La question que l'on peut se poser directement, c'est la différence avec XMPP : j'en parle un peu plus loin dans la dépêche.

Identité et serveurs

Un utilisateur se connecte sur son homeserver via un client au moyen d'un identifiant unique appelé matrix user ID (MXID) qui est de la forme @username:homeserver.tld et d'un mot de passe.

Les MXID sont cependant prévus d'être mis un peu en retrait par rapport aux 3rd party ID (3PID) qui correspondent aux emails ou aux numéros de téléphone.

Les serveurs d'identité (qui sont optionnels) permettent de faire le lien entre MXID et 3PID.

Enfin il y a les Application Services qui permettent de faire la passerelle avec d'autres protocoles (RC, Slack, Skype, Lync, etc.).

Salons de discussions et serveurs

Les discussions entre utilisateurs se passent dans des salons, par exemple le salon #matrix:matrix.org où se trouvent les développeurs de Matrix (qui est très fréquenté et très actif).
Cependant :

  • #matrix:matrix.org n'est qu'un alias spécifique au homeserver matrix.org, et n'importe qui peut lui donner un autre alias correspondant à son propre homeserver (par exemple #newmatrix:example.com). Le vrai identifiant du salon est en effet un nombre aléatoire.
  • Les messages échangés dans un salon sont stockés sur chacun des homeservers des utilisateurs participant au salon.

La conséquence, c'est que si le homeserver matrix.org disparaît demain, les utilisateurs inscrits sur matrix.org (donc avec une adresse type @user:matrix.org) ne pourront plus se connecter, mais les participants de #matrix:matrix.org continueront comme si de rien n'était (sauf qu'ils remarqueront que les utilisateurs de matrix.org ne sont pas là). De nouveaux participants pourront même rejoindre le salon via un autre alias (#newmatrix:example.com).

Le principe de la fédération

Une analogie possible serait de comparer au fonctionnement des emails :

  • Chaque fournisseur d'emails est indépendant, avec ses utilisateurs et son serveur conservant les emails.
  • Si le fournisseur d'email n'est pas ouvert vers l'extérieur, les utilisateurs peuvent communiquer entre eux et les emails restent sur le serveur.
  • Si le fournisseur d'emails est ouvert vers l'extérieur, les utilisateurs peuvent communiquer avec des utilisateurs d'autres fournisseurs, et les emails échangés se retrouvent alors sur les serveurs respectifs.

Matrix fonctionne de la même manière :

  • Chaque homeserver est indépendant, avec ses utilisateurs et son serveur conservant les salons de discussions (avec leurs messages échangés).
  • Si le homeserver n'est pas fédéré, les utilisateurs ne peuvent communiquer qu'entre eux et les salons de discussions restent sur le serveur
  • Si le homeserver est fédéré, les utilisateurs peuvent communiquer avec des utilisateurs d'autres homeserver, et les salons de discussions impliquant des utilisateurs de différents homeservers se retrouvent répliqués sur les homeservers respectifs.

Tout comme pour les emails, il n'y a donc pas de dépendance particulière à un homeserver en particulier, en tout cas en ce qui concerne les salons.

Note : en ce qui concerne les serveurs d’identité (c’est optionnel) pour l’instant il vaut mieux rester sur ceux de matrix.org.

Héberger un utilisateur n'est pas anodin, tout comme quelqu'un peut abuser de sa messagerie, un utilisateur de votre homeserver peut rejoindre un salon très fréquenté et surcharger ainsi votre homeserver (qui devra répliquer le salon).
Cependant, si votre homeserver est rapide (gros CPU/RAM ou pas beaucoup de charge), les utilisateurs de votre homeserver auront de meilleures performances pour se connecter et poster/récupérer des messages (même si les messages envoyés mettront du temps à être répliqués sur les autres homeservers surchargés).

Différence avec XMPP

La FAQ de Matrix présente elle-même les différences avec XMPP : What is the difference between Matrix and XMPP?.

Mais essentiellement on peut dire que :

  • XMPP est une spécification pour qu'un système puisse échanger des messages. Elle peut être étendue par un ensemble « d'extensions » élémentaires, dont la plupart sont optionnelles.
  • Matrix est une spécification pour qu'un système puisse stocker des données arbitraires (« events ») et définit un moyen de synchroniser et résoudre les conflits entre les serveurs fédérés. Il n'y a pas de spécifications d'extensions comme XMPP mais Matrix inclut nativement beaucoup plus de fonctionnalités (ils parlent eux-mêmes de « kitchen sink ») afin de garantir que les différents clients disposent de fonctionnalités compatibles.

La relation entre XMPP et Matrix est abordée un peu plus loin dans « Concurrence avec les autres protocoles décentralisés ».

Implémentations

Matrix n'est qu'une spécification, et il y a pleins d'implémentations différentes de serveurs et de clients disponibles. Mais, notons en particulier :

  • Synapse est l'implémentation de référence actuelle du serveur (appelée usuellement homeserver) et son futur remplaçant est Dendrite (qui semble être environ 300 fois plus rapide !). Il est aussi sous licence Apache v2.
  • Riot est un client multi plate-formes qui semble être de loin le plus populaire (fonctionne sous un navigateur, sous iOS, sous Android et sous forme d'application indépendante sur votre Bureau). Il est aussi sous licence Apache v2.
Fonctionnalités

À terme, les solutions autour de Matrix permettraient de remplacer Skype, Whatsapp, Signal, Slack et Discord car voici les fonctionnalités incluses :

  • appels audio/vidéo entre deux personnes ou bien audio/visio conférences entre plusieurs personnes
  • messagerie instantanée entre deux personnes ou pour un groupe, incluant la possibilité d'échanger photos, vidéos ou n'importe quel type de fichiers
  • chiffrage des communications de bout en bout
  • plusieurs clients peuvent être utilisés simultanément avec la même identité
  • en installant son propre homeserver, on peut fonctionner complètement en autonome ou bien en rejoignant la fédération

Note : cela pourra efficacement concurrencer Slack et Discord quand les fonctionnalités autour des Groupes d'utilisateurs seront implémentées.
Note 2 : Des fonctionnalités autour de l'IoT et de la VR sont aussi prévues, mais je n'ai pas vraiment eu le temps de voir où cela en était.

Remarquons tout de même que le fait de rassembler tous les usages dans un seul logiciel/protocole a un effet de bord gênant : on est poussé à utiliser la même identité pour tout. Avec plusieurs logiciels il est plus naturel de jongler avec plusieurs identités pour éviter de mélanger (par exemple identité professionnelle sous Slack, identité gamer sous Discord, identité personnelle sous Whatsapp et identité publique sous IRC).
Pour l'instant le multi-utilisateur est encore à l'étude.

Tutoriel d’installation

Vous pouvez suivre cet excellent tutoriel : Run your end-to-end encrypted chat server using Matrix and Riot.

Par défaut Matrix/Synapse utilise le serveur STUN de Google (issue 501) car c'est utile pour faire fonctionner l'audio/vidéo si vous êtes derrière une box par exemple.

Pour l'instant, pour être vraiment indépendant de Google ou si vous voulez traverser un firewall/NAT difficile (typiquement dans une entreprise), vous pouvez installer un serveur TURN. Voici comment faire avec Synapse et coturn.

Riot, un client populaire

Afin de vous faire une idée de Matrix et Riot, rien de plus facile que d'aller sur l'application web Riot pour, par exemple, accéder au salon #riot:matrix.org regroupant les développeurs et la communauté Riot (pas de création de compte requise) ou se créer un compte et ensuite discuter avec le chatbot @riot-bot:matrix.org. Cela permet de se faire une idée des possibilités avant d'installer l'application sur votre bureau ou sur votre smartphone.

Je vous invite d'ailleurs à venir faire un tour ici pour discuter de la dépêche : accès au salon LinuxFr via le client Riot.

À noter que Riot n'est pas encore complètement finalisé, mais qu'il y a une certaine attention aux détails. Par exemple, l'implémentation des notifications push est intéressante : Riot’s magical push notifications in iOS.

En revanche, l'application Riot sous Android peut être très gourmande en énergie lorsque Google Cloud Messaging n'est pas disponible (par exemple en utilisant F-Droid sans installer les GApps), car dans ce cas là les notifications push ne fonctionnent pas.

Le projet peut-il réussir ?

La notion de réussite est bien entendu toute relative. Mais, dans le cas d'un outil de communication, la réussite peut se mesurer à la taille du réseau (loi de Metcalfe), car l'outil n'a que peu d'utilité s'il n'y a pas grand monde avec qui communiquer (et il sera alors inévitable que son développement stagne ou périclite).

D'un point de vue grand public, il semblerait la plupart des protocoles/services/outils de communication ayant réussi dernièrement sont ceux ayant apportés une « killer feature » : ils ont apporté une réelle nouveauté, ou bien tellement amélioré quelque chose par rapport à l'existant que l'on peut parler de « rupture technologique ». Citons par exemple : Facebook, Skype, Instagram, Whatsapp, Snapchat
Note : il y aussi le succès chinois impressionnant de WeChat, mais son succès est plus difficile à analyser du fait de la politique d'intervention chinoise.

Des messageries instantanées tentent actuellement de percer en se lançant sur le créneau du chiffrage (ou de la vie privée) : Signal ou Telegram.
Note : chiffrage n'entraîne pas forcément l’impossibilité de censure, comme on vient de le voir avec Telegram qui accepte de supprimer des contenus terroristes.

Si on regarde les caractéristiques qui définissent Matrix, on peut se demander si ce sera suffisant pour réussir :

  • logiciel libre : à fonctionnalité équivalente, je ne suis même pas sûr que cela pèse significativement dans la balance par rapport à d'autres facteurs (marketing par exemple)
  • décentralisé : je ne connais aucun logiciel ayant vraiment réussi grâce à sa fonctionnalité de décentralisation
  • intégration des fonctions de plusieurs logiciels : le risque est certainement d'être moyen/bon partout et pas exceptionnel sur un point en particulier (« Jack of all trades, master of none »)
  • interopérable : on pourrait presque penser que c'est un handicap car cela ne pousse pas les utilisateurs à changer

On peut citer les succès/échecs relatifs du protocole XMPP, de logiciels interopérables comme Trillian ou Pidgin, de Google+ ou Google Hangouts.
Cependant, il y a d'autre contre-exemples comme Facebook Messenger, Apple Facetime, Slack, ou Discord dont les succès ont peut-être plus à voir avec une expérience utilisateur excellente (en particulier au niveau intégration) qu'avec une technique excellente.

Une des leçons à retenir avec XMPP, est le cas Google Talk. L'un des dangers avec un protocole ouvert c'est qu'un des acteurs utilise la technologie pour attirer les utilisateurs pour ensuite en profiter pour pousser leur propre technologie en parallèle (qui sera bien entendu bien mieux compatible avec ses propres services). Et c'est peut-être exactement ce qu'a fait sciemment ou inconsciemment Google Talk.

Au niveau de la concurrence, outre les protocoles XMPP, IRC, et SIP, voici donc quelques logiciels dont les fonctions sont actuellement plus ou moins couvertes par Matrix :
Skype, Whatsapp, Signal, Slack, Discord, Tox, Ring, Wire, SecuShare (Psyc), Zyptonite, Wickr, Telegram, Ricochet, ChatSecure, MatterMost, Mumble, Jitsi, Threema, Briar, Viber, Facetime, Google Hangouts, Google Duo, Mastodon, Facebook Messenger, Semaphor, Trello, Ricochet, OnionShare, Kik, SnapChat, Asana, HipChat, TeamSpeak, Delta Chat, BlueJeans, Jabber

Enfin, même Amazon vient de se lancer sur le créneau avec son Anytime (sans doute pour imiter le succès de WeChat).

Certains ont tenté de comparer les différentes solutions entre elles :

On voit donc que le chemin semble relativement ardu pour Matrix, ils n'ont clairement pas choisi la voie la plus facile (et c'est tout à leur honneur).

Mais il semblerait que l'engouement soit là ; si l’on regarde ces deux graphiques :


Encore un autre standard ?

Je mets le lien vers le fameux comics XKCD, car de toutes façons il y aura toujours quelqu'un pour le faire :

Les développeurs de Matrix (et à ce stade presque tous les développeurs) sont conscients de ce comics et des écueils associés. Ils ont quand même le mérite de tenter de résoudre le problème plutôt que de juste se satisfaire de l'état existant.

Concurrence avec les autres protocoles décentralisés et passerelles

Les protocoles décentralisés ne sont pas vraiment en « concurrence » les uns avec les autres au sens traditionnel du terme.
La plupart des développeurs travaillant sur le thème de la décentralisation partagent souvent la même idéologie et les mêmes objectifs, souvent en opposition avec toute une industrie essayant de garder leurs utilisateurs en otages dans leurs silos respectifs (cf. discussion sur le sujet).

Du coup la valeur d'un réseau décentralisé est à évaluer (loi de Metcalfe) en fonction de l'ensemble des utilisateurs des réseaux décentralisés (pour peu qu'il existe des passerelles entre les réseaux).

Ainsi, Matrix peut fonctionner avec des « bridges » (passerelles) permettant de communiquer avec d'autres réseaux/protocoles (comme IRC ou XMPP) : Matrix Application Services.

Spam

On peut affirmer sans trop se tromper que le spam est un des fléaux qui empoisonnent l'utilisation des emails.
Cela atteint un tel point qu'il devient difficile d'héberger ses propres emails car on peut être rapidement « blacklisté » par les principaux fournisseurs d'emails (Gmail par exemple). La conséquence indirecte est que cela a tendance à concentrer les pouvoirs dans un nombre plus restreint de fournisseurs (et donc a dé-fédérer).

Actuellement, il n'y a pas grand-chose de disponible pour lutter contre les abus (spams, propagande, messages injurieux, alternative factsfake news et autres). Il n'y a même rien en développement si ce n'est une grosse réflexion sur ce qu'il faudrait faire. Si vous avez des idées sur le sujet, c'est le moment idéal pour participer.

Mais cela pourrait être un axe très intéressant de développement car c'est un problème contre lequel butte tous les grands acteurs comme Google, Facebook ou Twitter (à l'aide de milliers de modérateurs).

Conclusion

Pour mon cas d'utilisation (discussions informelles entre amis et avec la famille), l'état actuel est complètement utilisable. Un soin particulier a en effet été apporté pour que l'interface utilisateur soit accessible et pas trop confuse. Du coup, je n'ai pas eu de difficulté particulière à convaincre des utilisateurs à me rejoindre (ils ont juste eu à aller sur leur magasin d'application favori et de télécharger l'application).

Limitations

Pour vous donner une idée un peu concrète des limitations actuelles, voici quelques exemples de soucis que j'ai rencontrés pour mon cas d'utilisation (cependant d'autres personnes auraient sans doute choisi de souligner d'autres choses plus importantes à leurs yeux).

Pour celui qui administre un homeserver, la gestion est encore très manuelle :

Le chiffrage de bout en bout (e2e encryption) fonctionne sur le principe, mais il reste du travail pour que ce soit vraiment utilisable :

  • L'identité des participants d'un salon est (pour l'instant) toujours en clair
  • Les métadata associées aux messages sont aussi (pour l'instant) toujours en clair
  • L'interface utilisateur pour échanger les clés entre clients est encore très manuelle et assez pénible (issue #2996)
  • Quelqu'un rejoignant en cours de route un salon chiffré n'a pas accès aux messages précédant son arrivée (issue #2286)

La visioconférence à plusieurs (trois personnes et plus) ne fonctionne pas très bien et nécessite que votre homeserver soit fédéré (mais la migration vers une solution autour de Jitsi est en cours) (issue #1869)

La gestion de groupes d'utilisateurs (afin de pouvoir concurrencer Slack et Discord) est prévu très prochainement mais n'est pas encore disponible (issue #3842).

Le partage d'écran dans un chat vidéo fonctionne mais n'est pas encore vraiment public (il faut shift-cliquer sur le bouton vidéo) et il n'est pas encore possible de partager juste une fenêtre (issue #3025)

Il n'y a pour le moment rien pour lutter contre le spam, cela tombe bien, car il n'y a pas encore de spam. Ce serait presque une marque de reconnaissance, « un problème que l'on aimerait avoir », car cela signifierait que le succès est suffisamment indéniable pour que les spammeurs s'intéressent à Matrix.
En particulier votre identité d'utilisateur (par exemple @nom:example.com) n'est pas très privée et se retrouve sur le « user directory » public dès que vous participez à un salon public (un peu comme si votre adresse email se retrouvait dans un annuaire global public si vous êtes présent dans une liste de diffusion publique).

Enfin il faut avouer que le nom « Matrix » n'est pas très « SEO-Friendly » et évolue peut-être en terrain miné. Si par exemple on cherche « Matrix IoT » on tombe sur un autre Matrix qui se présente comme « The World's First IoT App Ecosystem ». De même si on cherche « Matrix VR », on tombe sur plein de résultats qui n'ont rien à voir avec Matrix.org.

Aider le projet Matrix

Matrix est développé depuis 2014 sous l'impulsion initiale de deux employés de Amdocs : Matthew Hodgson et Amandine Le Pape (qui est inscrite sur LinuxFr !). Aujourd'hui, Matrix.org n'a pour l'instant pas de statut particulier (Association à but non lucratif ou fondation par exemple).

Matrix s'est développé très rapidement ces derniers temps, grâce au fait que onze personnes étaient payées/sponsorisés par Amdocs (et aussi OpenMarket) pour travailler spécifiquement dessus. Cependant, la société a décidé dernièrement de réduire les fonds alloués de 60 %, ce qui met le projet soudainement dans une situation difficile.

Les développeurs font donc appel à la communauté pour pouvoir en partie financer le développement : A Call to Arms: Supporting Matrix!

Télécharger ce contenu au format Epub

Lire les commentaires

Revue de presse — juillet 2017

19 juillet, 2017 - 18:20

L’été est là et son lot de numéros doubles de vos magazines préférés que vous retrouverez en kiosque aussi. Voici notre revue de la presse papier, celle que vous pouvez encore trouver, en 2017, chez votre marchand de journaux.

Au sommaire de ce mois‐ci, il y a du Raspberry Pi, forcément, mais pas que. Il y a aussi :

  • GNU/Linux Magazine France no 206, pour lequel nous ne ferons que paraphraser ici le Pr Hammond : « Je déteste valgrinder Duke Nukem 3D, bordel ! Mélanger comme ça la détection d’erreur avec le jeux vidéo… C’est mieux de faire les choses dans l’ordre ». Sur quoi, Georges aurait répondu « Va te faire branler, trotskard. » ;
  • Linux Pratique no 102, qui vous remet d’office à la programmation par l’exemple avec la réalisation d’un jeux type Pong avec le langage Processing. Mais aussi l’installation de Mastodon, de la diffusion avec VLC, le chiffrement complet de l’ordinateur ou encore l’immanquable cahier dédié au Raspberry Pi ;
  • MISC magazine no 92 revient sur les techniques de « reverse engineering » et les outils actuels pour parvenir à ses fins en fonction de la plateforme. Les smarts cities (suite et fin ?) et aussi du cul ! Enfin, plus sérieusement (MISC oblige), l’analyse d’un sex toy connecté (ils l’avaient oublié dans le hors‐série toujours en vente d’ailleurs) ;
  • Hackable Magazine no 19 toujours à fond sur la bidouille, l’Arduino (émetteur 443 MHz), le Raspberry Pi (supervision) et des liaisons radio pour sextobjets connectés sur le réseau LoRa ;
  • Linux Pratique hors‐série no 39 refait le tour du shell et de la ligne de commande ;
  • GNU/Linux Magazine hors‐série no 91, point de RaspPi, mais de l’Android et la création d’une application de Geocaching afin de découvrir les aspects avancés de la programmation pour ce système d’exploitation pour mobiles (structuration projet, manipulation des capteurs, communication Bluetooth, SMS et la partie publication au monde incluant toute l’interaction avec le Play Store et les possibilités de monétisation ;
  • Linux Inside nos 35 et 36, après l’ultime, voici le guide pratique et le spécial projets Raspberry Pi ;
  • et Linux Identity offre cette fois du Tails avec son petit guide, en plus de la cohorte habituelle des kits, packs et starters pour récupérer des distributions en masse sur d’innombrables CDDVD‐ROM contenant de l’Ubuntu en pagaille, Xubuntu, Ubuntu GNOME, Ubuntu Mentholée, Ubuntu Origins (aka Debian) et Tails. On le répète, mais on attend toujours la clef USB !

Et toujours :

  • Planète Linux no 96, avec Linux Mint 18.1, Korora 25 et AntiX 16 ;
  • MISC hors‐série no 15 : la sécurité des objets connectés.
GNU/Linux Magazine no 206

Linux Pratique no 102

MISC no 92

Hackable Magazine no 19

Linux Pratique hors‐série no 39

GNU/Linux Magazine hors‐série no 91

Linux Inside nos 35 et 36

Télécharger ce contenu au format Epub

Lire les commentaires

Version 2.11 de la billetterie e‐venement

19 juillet, 2017 - 18:12

e‐venement est un logiciel libre de billetterie informatisée sous licence GPL. La version 2.11, XI.I Samhain, est sortie fin juin 2017.

Moins technique sur les usages que les précédentes, elle augmente l’expérience de l’utilisateur au travers d’ajouts ergonomiques, de personnalisation des données affichées, d’aides à la saisie et de stockage d’informations pertinentes à son métier.

Cette nouvelle version d’e‐venement apporte comme toutes les précédentes son lot de nouveautés et de corrections de bogues. Mais elle amorce à elle seule le virage vers le futur d’e‐venement. On notera en particulier l’apparition de la vente en ligne.

De nouvelles orientations

Des choix importants se sont profilés au cours de son développement et ont amené à repenser les actuels et futurs développements.

De nouvelles fonctionnalités, mises en place au travers de services internes et en particulier utilisées par de nouvelles API (dont une API de vente en ligne), offrent de nouvelles perspectives en termes d’innovation et de continuité avec les futures versions d’e‐venement. Nous nous rapprochons doucement mais sûrement de la version 3 d‘e‐venement.

Le tournant est pris, la volonté suit. Que cette nouvelle mouture d’e‐venement apporte à tous, utilisateurs, intégrateurs et développeurs, l’envie d’aller toujours plus loin dans ce métier passionnant qu’est la billetterie.

Télécharger ce contenu au format Epub

Lire les commentaires

Agenda du Libre pour la semaine 29 de l’année 2017

17 juillet, 2017 - 12:10

Calendrier Web, regroupant des événements liés au Libre (logiciel, salon, atelier, install party, conférence), annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 17 événements (0 en Belgique, 15 en France, 0 au Luxembourg, 2 au Québec, en Suisse et 0 en Tunisie) est en seconde partie de dépêche.

Sommaire [QC Montréal] (3L)-Logiciels Libres en liberté - Le lundi 17 juillet 2017 de 18h00 à 21h00.

Accueil rencontre:
(3L)-Logiciels Libres en liberté groupe d’utilisateurs de Logiciels Libres, de niveau débutant qui tiendra sa rencontre régulière mensuelle tout les 3ième lundi de chaque mois.Amener vos portables et votre bonne humeur. Venez  jaser sur les logiciels libres, Nous montrer vos découvertes, poser vos questions?

[FR Lyon] Debian et Cie - Le lundi 17 juillet 2017 de 19h30 à 21h30.

Atelier Debian - ALDIL

En moyenne, tous les 3èmes lundi de chaque mois, l'ALDIL, Association Lyonnaise pour le Développement de l'Informatique Libre organise des ateliers autour du système d'exploitation GNU/Linux Debian.

L'occasion de découvrir et d'échanger avec les membres de la communauté ses trucs et astuces.

Chaque atelier s'articule autour d'un thème pour découvrir de nouvelles fonctionnalités ou approfondir ses connaissances.

Ces ateliers ont lieu à la MJC Montchat de 19h à 21h30 au : 53, rue Charles Richard, 69003 Lyon.

Ces ateliers sont ouverts à tous… libres et gratuits

[FR Reims] G.L.O.U. - Le mardi 18 juillet 2017 de 18h00 à 20h30.

Le G.L.O.U. est l'occasion de boire un coup entre amis des libertés, et de discuter de tout et de rien.

Les vacances d'été ont commencé, mais l'association est toujours là.

Nous vous proposons de se retrouver autour d'un verre, condition primordiale, avec ou sans alcool, mardi 18 juillet 2017 à 18h00.

Lieu

Grand comptoir de Reims
à l'intérieur de la Gare de Reims centre.

[FR Paris] Atelier Emacs - Le mardi 18 juillet 2017 de 19h00 à 22h00.

Nous sommes quelques emacsiens à nous réunir à Paris pour apprendre les uns des autres : c’est ouvert aux non-emacsiens, aux débutants, aux utilisateurs avancés et aux vimistes !

Le prochain atelier aura lieu le mardi 18 juillet de 19h à 22h chez inno3.fr, au 137 Boulevard de Magenta 75010 Paris.

Nous commencerons avec un petit tour de table, puis Bastien fera une brève introduction au langage Emacs Lisp.

Le nombre de participants est limité à 12.

Pour vous inscrire, il vous suffit d'envoyer un mail à Bastien : bzg@bzg.fr

[FR Grenoble] TupperVim - Le mardi 18 juillet 2017 de 19h00 à 23h00.

La Guilde des Utilisateurs d'Informatique Libre du Dauphiné organise un atelier TupperVim.

Le format est à mi chemin entre un atelier pratique et un apéro informel, pour échanger des trucs et astuces sur le célèbre éditeur de texte.

N'hésitez pas à venir, débutants ou confirmés, pour apprendre des choses, discuter avec d'autres vimistes, et prendre l'apéro.

[FR Callian] Linux et les Logiciels Libres - Le mercredi 19 juillet 2017 de 18h00 à 21h00.

Venez découvrir Linux et les logiciels libres, mais aussi vous faire aider avec votre matériel informatique quel qu'il soit, imprimante, box, tablette, smartphone y compris.

Cette année, nos objectifs évoluent, c'est à dire les logiciels libres restent comme l'objectif principal, mais aussi d'aider les gens avec leur matériel informatique quel qu'il soit, imprimante, box, tablette smartphone y compris.

Venez avec vos machines même sous Windows ou Mac/os, nous ne vous laisserons pas tomber, nous considérons, que vous n'êtes pas responsable de l'hégémonie commerciale des produits non libres.

Mais pourquoi venir aux réunions ?
1°) Découvrir, Essayer, Installer Linux
2°) Régler vos problèmes Windows ou Mac

Venez nombreux, même par curiosité ! Les animateurs seront heureux de vous accueillir et nous insistons.

L'accès est totalement libre et gratuit !

Merci de vous inscrire par mail et d'indiquer le soucis à régler si besoin.

[FR Perpignan] Initiation Programmation - Apéro Coding - Le mercredi 19 juillet 2017 de 18h00 à 21h00.

Atelier Initiation Programmation suivi d'un apéro à partir de 19H au hackerspace de Perpignan le Alicelab.

Venez avec votre portable, places limitées, contacter Stephane (téléphone sur le site du alicelab.fr) pour plus de renseignements.

[QC Montréal] Meetup Technologies Web et Logiciels Libres - Le mercredi 19 juillet 2017 de 18h00 à 20h00.

Le 19 juillet rejoignez-nous pour une séance autour de 2 thématiques :
1/ Présentation de Angular
2/ Docker : comment mettre en place son environnement de développement personnel ?

[FR Champs-sur-Marne] Mapathon Missing Maps - Le mercredi 19 juillet 2017 de 18h30 à 21h30.

Venez nous aider à cartographier sur OpenStreetMap, la carte du monde collaborative et libre !

CartONG, et le FOSS4G Europe vous invitent à un mapathon Missing Maps pour découvrir la cartographie participative et humanitaire dans OpenStreetMap : pas besoin d'être un expert, c'est accessible à tout le monde !

Pourquoi ?

L’objectif du projet Missing Maps est de créer des cartes pour les zones de crise des pays en voie de développement qui en ont le plus besoin. En effet, on peut penser qu'aujourd'hui toutes les parties du monde sont cartographiées, mais en réalité nombreuses régions ne possèdent encore aucunes cartes. L'objectif de Missing Maps est donc de cartographier toutes ces zones encore invisibles sur les cartes, pour permettre par la suite aux collectivités locales et acteurs de l'humanitaire de pouvoir agir plus efficacement en cas de crise. 

Comment ? 

Avec la plateforme de cartographie libre et contributive OpenStreetMap (OSM, le « Wikipédia des cartes ») un outil formidable pour « remplir les blancs », n'importe qui peut participer à la cartographie de n'importe quelle zone de la planète : il suffit d'un ordinateur, d'une souris et d'une connexion internet ! Grâce à la couverture globale d'image satellites disponible aujourd'hui, il est possible de tracer facilement routes, bâtiments ou cours d'eau, autant d'informations très utiles pour les organisations humanitaires et de développement sur le terrain.
 

Le programme de la soirée

Nous vous proposons de découvrir comment contribuer à OpenStreetMap durant un « mapathon ». Cet événement s'inscrit dans le cadre de l'initiative globale Missing Maps, projet humanitaire qui vise à cartographier en amont les parties du mondes vulnérables aux catastrophes naturelles, crises sanitaires, environnementale, aux conflits et à la pauvreté. 

Au programme :

  • 18h30 : accueil des participants
  • 18h40 : Mot de bienvenue, présentation du projet Missing Maps et du déroulement de la soirée
  • 18h50 : Présentation de la contribution dans OSM
  • 19h00 : Cartographions !

Lightning Talks 

  • 21:30 Fin du mapathon

Où?

A l'ENSG, salle L005, 6 et 8 Avenue Blaise Pascal Cité Descartes - Champs-sur-Marne 77455 Marne la Vallée Cedex 2

Un grand merci à l'ENSG et le FOSS4G Europe pour l'accueil et le soutient

Venez nombreux, et n'oubliez pas votre ordinateur portable, et souri(re)s !

[FR Chartres] OpenAtelier - Le mercredi 19 juillet 2017 de 20h00 à 23h59.

L'OpenAtelier est un moment de rencontre et de partage ou les membres et curieux sont invités à échanger sur leurs idées et leurs projets.

Les espaces techniques sont également ouverts aux réalisations (électronique, informatique, menuiserie, impression 3D, découpe vinyle…).

Pour les curieux, c'est le bon moment pour venir découvrir l'association et ses membres.

[FR Toulouse] Rencontre Tetalab - Le mercredi 19 juillet 2017 de 21h00 à 23h00.

Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

[FR Paris] Soirée de Contribution au Libre - Le jeudi 20 juillet 2017 de 19h30 à 22h30.

Parinux propose aux utilisateurs de logiciels libres de se réunir régulièrement afin de contribuer à des projets libres. En effet, un logiciel libre est souvent porté par une communauté de bénévoles et dépend d'eux pour que le logiciel évolue.

Nous nous réunissons donc tous les dans un environnement propice au travail (pas de facebook, pas de télé, pas de jeux vidéos, pas de zombies).

Vous aurez très probablement besoin d'un ordinateur portable, mais électricité et réseau fournis.

En cas de difficulté, vous pouvez joindre un des responsables de la soirée, Emmanuel Seyman (emmanuel (at) seyman.fr), Paul Marques Mota mota (at) parinux.org, ou Magali Garnero (Bookynette) tresorier (at) parinux.org.

Pour obtenir le code d'entrée de la porte cochère, envoyez un mail au responsable.

On peut amener de quoi se restaurer (Franprix, 8 rue du Chemin Vert, ferme à 22h)

Regazouillez sur Twitter - Wiki des soirées

Programme non exhaustif

  • Fedora (sa traduction)
  • Parinux, ses bugs et son infrastructure
  • April, … y a toujours quelque chose à faire
  • Open Food Facts/ Open Beauty Facts, sa base de données, ses contributeurs, sa roadmap
  • Schema racktables, son code
  • Agenda du Libre, mise à jour et amélioration du code
  • Ubuntu-Fr, son orga, ses événements
  • En vente libre, maintenance et commandes
  • Open street map, une fois par mois
  • Linux-Fr sait faire
  • …

tout nouveau projet est le bienvenu.

[FR Montpellier] Les logiciels libres, parlons-en ! - Le vendredi 21 juillet 2017 de 17h00 à 19h00.

Le Faubourg Marché, qu’est-ce que c’est ?

Le Faubourg Marché est une permanence partagée qui permet aux associations d’accueillir ensemble, les publics de ces associations une fois par semaine, le vendredi entre 17h00 et 19h00, au 19, rue du Faubourg de Nîmes, 34000 Montpellier.

L’idée est de s’informer et d’informer les adhérents des diverses associations sur le fonctionnement du lieu et des associations, et notamment sur les 5 partenaires qui l’animent et lui permettent ainsi d’exister (autour.com, L’Accorderie, enercoop, modulauto, La Nef). Lors de cette permanence partagée vous pourrez rencontrer les associations La Graine (monnaie locale de Montpellier), éCOhabitons, Montpellier à pied, et bien sûr Montpel’libre.

Alors, si vous avez un peu de temps le vendredi soir, voici une occupation qui me semble très intéressante.
Montpel’libre est une association et un groupe d’utilisateurs (GULL), qui propose une multitude d’activités dans le cadre de la promotion des logiciels libres, et des Communs.
Depuis longtemps déjà, Montpel’libre participe à l’économie sociale et solidaire en organisant tout un éventail d’ateliers et de manifestations, au développement durable et à l’innovation sociale au travers de permanences et ateliers de présentations des logiciels libres et évidement les cartoparties, véritable actions citoyennes, sur le thème de l’accessibilité des personnes en situation de handicap.
L’activité économique, l’intérêt collectif, le fonctionnement démocratique, autant d’éléments que porte Montpel’libre, en proposant un accès entièrement libre et gratuit à une éducation populaire, au travers de ses ateliers à destination de tous les publics.

Les logiciels libres parlons-en ! Ouvrons le dialogue sur l’ouverture des données ! Partageons nos expériences pour une meilleure répartition des connaissances.

Ces permanences sont suivies d’un Apéro « refaire le monde » convivial et partagé, de 18h30 à 21h30. Elles ont lieu au Faubourg marché, tous les vendredis de 17h00 à 19h00 :

  • vendredi 7 juillet 2017 de 17h00 à 19h00
  • vendredi 21 juillet 2017 de 17h00 à 19h00
  • vendredi 28 juillet 2017 de 17h00 à 19h00

Entrée libre et gratuite sur inscription. Une simple adhésion à l’association est possible.

Cet événement est proposé dans le cadre du partenariat qui lie le Faubourg Marché et Montpel’libre.

Vendredis 7, 21 et 28 juillet 2017 de 17h00 à 19h00
Le Faubourg - 15, rue du Faubourg de Nîmes, 34000 Montpellier

Tramway lignes 1, 2 et 4 arrêt Corum
GPS Latitude : 43.614186 | Longitude : 3.881404
Carte OpenStreetMap

[FR Villeneuve d'Ascq] Libre à Vous - Le samedi 22 juillet 2017 de 09h00 à 12h00.

Vous souhaitez tester GNU/Linux sur votre ordinateur, vous recherchez un logiciel pour une fonction précise, des conseils ou de l'aide sur les logiciels libres?

Libre à Vous est une permanence destinée à vous faciliter l'utilisation de l'informatique. Vous repartirez avec « le plein » de logiciels libres, fiables, évolutifs, performants et gratuits.

C'est chaque samedi matin au Centre d'Infos Jeunes à la ferme Dupire, 80 rue Yves Decugis à Villeneuve d'Ascq (métro Triolo) de 9h00 à 12h00.

Entrée Libre. Tout Public.

[FR Valenciennes] Permanence ValLibre - Le samedi 22 juillet 2017 de 09h30 à 12h00.

Permanence assistance informatique.

Dépannage petits bobos informatiques.

Initiation à l'informatique libre.

Tous les samedis ouvrables sauf les derniers samedis du mois et les samedis en période de vacances scolaires.

Si besoin particulier, la prise de rendez-vous est fortement conseillée.

Téléphone accueil MQCV : 03 27 22 43 90

[FR La Couronne] Permanence - accueil public - Le samedi 22 juillet 2017 de 10h00 à 13h00.

Notre permanence d'accueil avec le sourire, le café et les gâteaux !

Lieu de rencontre et d'échange convivial pour discuter informatique et outils numériques.

Cette association permet à chacun de découvrir également l'univers de Linux et par extension de tous les **logiciels* et matériels libres*.

Entrée Libre. Tout Public. 

[FR Valenciennes] Atelier (wiki) HainautPédi@ - Le samedi 22 juillet 2017 de 10h00 à 12h00.

Atelier pour les contributions au wiki territorial HainautPédi@

http://hainautpedia.vallibre.fr

Les ateliers HainautPédi@ sont organisés pour que les contributeurs se rencontrent et fassent évoluer ensemble le contenu du wiki.

Ces séance sont à accès libre, elles permettent également aux personnes intéressées de prendre contact avec la communauté afin d'apprendre concrètement le fonctionnement du projet.

Lors d'un atelier, des machines sont accessibles pour compléter le wiki ou simplement expérimenter.

Rendez-vous à l'espace numérique de la bibliothèque municipale de Valenciennes. Dernier samedi du mois.

Télécharger ce contenu au format Epub

Lire les commentaires

Paris Open Source Summit 2017 — Rappel — Appel à communications

17 juillet, 2017 - 00:07

Organisé par le pôle Systematic, avec le soutien de la région Île‐de‐France et de la ville de Paris et opéré par Weyou Group, la troisième édition du Paris Open Source Summit se tiendra les 6 et 7 décembre prochains, avec plus de 150 exposants et partenaires, 100 conférences et 5 000 visiteurs attendus.

L’appel à communications est ouvert jusqu’au mardi 25 juillet 2017 à minuit, sur les thématiques Tech, Solutions et Ecosystem.

Il convient de rappeler que Paris Open Source Summit est le fruit de la fusion de Solutions Linux et de l’Open World Forum, ce qui en fait un évènement particulièrement important.

Voyez la seconde partie de l’article pour plus d’informations.

Le Paris Open Source Summit est à la fois une vitrine de l’écosystème francophone, une chambre d’écho internationale et un lieu de rencontres professionnelles et de collaboration. Il se veut être le premier événement européen de la filière du Libre et de l’open source.

« Enabling Digital Everywhere »

L’édition 2017 s’articulera autour de la révolution du numérique, qui atteint tous les territoires et impacte tous les domaines.
Le numérique est devenu nécessaire pour l’ensemble des activités et des métiers, même parmi les plus traditionnels. Aujourd’hui les aspects collaboratifs, nomadisme et ouverture, ainsi que l’émergence de nouveaux horizons comme la blockchain, l’Internet des objets, le cloud, l’intelligence artificielle, l’e‐commerce ou le Big data sont l’avenir et déjà le quotidien de l’industrie.

Le numérique est générateur d’énormes opportunités d’innovations qui nécessitent un contexte de confiance pour être pleinement concrétisées. Il doit donc être associé à une logique d’ouverture, de mutualisation, de pérennité et de souveraineté.

L’Open Source et les modèles ouverts, sur lesquels reposent aujourd’hui massivement le numérique, est une réponse à ces nécessités.

Cette édition 2017 de l’OSS de Paris aura ainsi à cœur de mettre en lumière la place du Libre et de l’Open Source, dans la révolution numérique de nos sociétés.

Comité de programme

Élu en mars dernier à la tête du comité de programme du Paris Open Source Summit 2017, Pierre Baudracco, fondateur de la société BlueMind, s’est entouré de personnalités reconnues du monde de l’Open Source pour élaborer ce programme 2017 :

  • VP Tech et DevOps : Jonathan Clarke, cofondateur de Normation, organisateur de DevOps-Rex ;
  • VP Solutions : Laurent Séguin, directeur commercial et marketing de l’éditeur Maarch, président de l’AFUL ;
  • VP Ecosystem : Bastien Guerry, entrepreneur d’intérêt général pour le ministère de la Culture, ancien salarié de Wikimedia, cofondateur d’OLPC France, contributeur d’Emacs ;
  • VP international : Éric Adja, directeur adjoint de la francophonie économique et numérique à l’OIF (Organisation internationale de la francophonie) ;
  • VP grand utilisateur : Alain Voiment, directeur technique adjoint de la Société Générale.
Appel à communications

Partagez vos expériences sur les trois thématiques à l’honneur cette année :

Tech

Destinée aux technophiles, à ceux qui font tourner nos infrastructures, celles‐la même où l’adoption généralisée du logiciel libre a commencé, et à ceux qui innovent encore et toujours avec les technologies de demain. Elle ouvrira le capot des applications qui nous entourent pour explorer toutes les couches qui les font tourner : de l’infrastructure du data‐center au cloud et aux conteneurs, la gestion en production par déploiement automatique ou configuration continue et les innovations technologiques autour des données et de l’utilisateur final.

Solutions

Destinée principalement aux utilisateurs finals, entreprises, administrations, collectivités ou toute organisation. L’objectif est de présenter des réponses opérationnelles de solutions Open Source pour les nouveaux usages du numérique, ainsi que pour les besoins métier nouveaux ou en mutation.

Ecosystem

Il accueillera les analyses et réflexions sur les enjeux de société liés au mouvement du logiciel libre, sur le « Libre » au‐delà du logiciel, sur les modèles économiques des biens communs informationnels, sur la place du logiciel libre en France et dans la francophonie et au‐delà, en Europe et dans le monde. Le thème « L’Open Source et le droit » sera organisé en collaboration avec EOLE (European Free and Open Source Law Event).

Sponsors
  • Diamond : Inria ;
  • Platinium : Alterway, Smile ;
  • Gold : BlueMind, Henix, Red Hat, SensioLabs ;
  • Silver : Axelor, Centreon, Cozy.io, XiVo.
Télécharger ce contenu au format Epub

Lire les commentaires

Les journaux LinuxFr.org les mieux notés du mois de juin 2017

16 juillet, 2017 - 08:26

LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l’équipe de modération avant publication. C’est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, 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 des modérateurs. Ceux‐ci s’appellent des journaux. Voici un florilège d’une dizaine de ces journaux parmi les mieux notés par les utilisateurs… qui notent. Lumière sur ceux du mois de juin passé.

Télécharger ce contenu au format Epub

Lire les commentaires

OCaml 4.04 et 4.05

16 juillet, 2017 - 08:26

La version 4.05.0 du langage OCaml vient d’être publiée, le 13 juillet 2017 ; quelque mois après la sortie de la version 4.04.0, annoncée le 4 novembre 2016. OCaml est un langage fonctionnel de la famille des langages ML (dont font partie SML et F#). Il s’agit d’un langage fonctionnel multi‐paradigme fortement typé qui permet de mélanger librement les paradigmes fonctionnel, impératif et objet.

Il s’agit des deux premières versions après le passage à un cycle court de développement (6 mois). Elles contiennent assez peu de changements majeurs et peuvent être considérées comme des versions de maturation, en particulier pour la nouvelle phase d’optimisation Flambda introduite dans la version 4.03.

On note cependant l’intégration de deux nouveaux outils dans le compilateur : un profileur de mémoire et un fuzzer ; mais aussi quelques améliorations du langage et de la bibliothèque standard. Pas mal de changements ont aussi eu lieu dans les entrailles du compilateur et n’ont pas encore débouché sur des changements visibles à la surface du langage.

Une des nouveautés les plus surprenantes de ces cycles de développement est probablement l’apparition d’une nouvelle syntaxe alternative à OCaml, nommé Reason(ml), sous l’impulsion d’une équipe de Facebook.

Sommaire Outils de développement

Du côté des outils de développement, deux nouveaux outils ont été intégrés à la distribution OCaml: un profileur de mémoire, Spacetime, et un fuzzer, afl-fuzzer.

Spacetime: profileur de mémoire

Le nouveau profileur de mémoire baptisé spacetime n’est pas activé par défaut à cause de son impact sur la performance et la mémoire des processus profilés. Il est cependant aisément disponible à travers un switch opam, le gestionnaire de paquets d’OCaml qui gère aussi les versions installées du compilateur Ocaml. Installer un compilateur OCaml avec le prise en charge de spacetime activée se fait avec une simple ligne :

$ opam switch 4.05.0+spacetime

Une fois spacetime activé, n’importe quel programme peut être profilé en définissant la variable d’environnement OCAML_SPACETIME_INTERVAL. On peut, par exemple, s’intéresser à la consommation mémoire lors de l’analyse des dépendances du compilateur :

$ OCAML_SPACETIME_INTERVAL=50 codept ocaml-compiler

Les traces sont ensuite sauvegardées sous la forme spacetime-$process-id et peuvent être analysées grâce à l’outil perf_spacetime qui dispose d’un mode terminal et d’un mode service Web permettant d’explorer en détails la consommation mémoire.

Dans le cas illustré, on peut voir que la consommation de la mémoire se structure en cycles composés d’une phase d’exploration durant laquelle la consommation de la mémoire croît, suivie d’une phase de résolution qui permet au ramasse‐miettes de collecter la majorité de la mémoire utilisée dans la phase précédente.

Intégration de afl-fuzzer

American fuzzy lop (aussi connu sous le nom de afl-fuzzer) est un fuzzer, c’est‐à‐dire un outil pour tester des logiciels en leur injectant des données aléatoires en entrée.

Contrairement à la plupart des fuzzers, afl-fuzzers va plus loin que la simple injection de données aléatoires non corrélées : il observe le comportement interne du programme testé pour essayer de forger des données d’entrée qui vont explorer de nouvelles branches du code à éprouver. Cela permet d’améliorer le taux de couverture du test, au prix d’une nécessaire instrumentation du code. La mouture 4.05 d’OCaml permet désormais d’ajouter cette instrumentation au code compilé grâce à une simple option de compilation.

Comme exemple basique d’utilisation, on peut considérer ce code qui échoue sur un cas très particulier :

let () = let s = read_line () in if String.length s > 5 then match s.[0], s.[1], s.[2], s.[3], s.[4] with | 'e', 'c' , 'h', 'e', 'c' -> failwith "Échec improbable" | _ -> ()

Pour analyser ce code avec afl fuzzer, il suffit d’utiliser la nouvelle option -afl-instrument d’ocamlopt, fournir quelques cas de base, puis de lancer afl-fuzz lui‐même, qui va utiliser un algorithme générique sur ces cas de base pour générer de nouveaux cas à tester :

ocamlopt -afl-instrument test.ml afl-fuzz -i input -o output ./test.ml

Ce dernier trouve rapidement que, par exemple, echec#Ε$5<ȹpu|Ϧģ fait planter le programme. Cependant, il n’est pas assuré de trouver une entrée minimale (ici « echec ») faisant échouer le programme.

Évolution du langage OCaml Exceptions locales

Parmi les particularités d’OCaml, il y a ces exceptions qui sont suffisamment rapides pour être utilisées en tant que structures de contrôle. OCaml 4.04 introduit une notation simplifiée pour les exceptions locales :

let recherche_premier (type a) predicat table= let exception Trouve of a in try Array.iter (fun x -> if predicat x then raise (Trouve x) ) table; None with Trouve x -> Some x

Avant l’introduction de cette nouvelle notation, il fallait passer par un module local pour définir l’exception :

let recherche_premier (type a) predicat table= let module M = struct exception Trouve of a end in try Array.iter (fun x -> if predicat x then raise (M.Trouve x) ) table; None with M.Trouve x -> Some x

De plus, dans le futur, ces exceptions locales pourraient faire l’objet d’optimisations spécifiques.

Ouverture locale de module dans les motifs

Une des nouveautés d’OCaml 4.04 est la possibilité d’ouvrir localement un module à l’intérieur d’un motif :

module M = struct type t = A | B | C type u = List of t list | Array of t array end let est_ce_la_liste_ABC x = match x with | M.( List [A;B;C] ) -> true | _ -> false

Comme dans le cas des expressions, ouvrir localement un module permet d’importer les types et valeurs dans la portée (scope) courante sans polluer la portée en dehors du motif. Cette construction permet également de rétablir une certaine symétrie entre motifs et expressions, comme dans l’exemple suivant uniquement valide depuis OCaml 4.04 :

module N = struct type r = { x : int } end let N.{ x } (* { x } est un motif ici *) = N.{ x = 1 } (* { x = 1} est une expression de ce côté-ci *) Représentation en mémoire optimisée

Il est désormais possible d’optimiser la représentation en mémoire des variants avec un seul constructeur et un seul argument ou des enregistrements avec un seul champ en les annotant avec [@@unboxed] :

type 'a s = A of 'a [@@unboxed] type 'a r = { f: 'a } [@@unboxed]

Sans l’annotation [@@unboxed], ces deux types seraient représentés en mémoire sous la forme d’un bloc OCaml composé d’un en‐tête et d’un champ :

┌────────┬───────────┐ │ entête │ champs[0] │ └────────┴───────────┘

Pour des types plus complexes, l’en‐tête contient des informations sur le nombre de champs dans le bloc et sur l’étiquette du constructeur. Cependant, pour ces cas particuliers, l’en‐tête n’apporte aucune information et il est possible de l’élider.

Cette optimisation est particulièrement utile dans le cadre des types algébriques généralisés, puisqu’elle permet d’introduire des types existentiels sans payer de coût en mémoire. Par exemple, si l’on souhaite oublier le type des éléments d’une liste, on peut introduire le type algébrique généralisé suivant :

type liste = Any: 'a list -> liste [@@unboxed]

Grâce à l’annotation [@@unboxed], le type liste aura exactement la même représentation en mémoire qu’une liste classique, et représente une version du type 'a list qui interdit toute manipulation dépendante du type 'a des éléments de la liste.

Dans la plupart des cas, cette optimisation est transparente à l’usage. Cependant, les bibliothèques de liaison (bindings) C‐OCaml doivent faire attention à ce changement de représentation en mémoire. Afin d’éviter de briser les bibliothèques de liaison existantes, cette optimisation n’est pas activée par défault, mais doit l’être au cas par cas avec l’annotation[@@unboxed] ou via l’option de compilation -unboxed-types.

Vers des chaînes de caractères immuables

La migration vers des chaînes de caractères immuables, initiée dans OCaml 4.02, se poursuit avec l’apparition d’une option de configuration du compilateur permettant d’en faire le comportement par défaut. Cette option n’est pas encore activée par défaut dans 4.05, mais des discussions sont en cours pour l’activer dans la prochaine version (4.06).

Évolution de la bibliothèque standard

La bibliothèque standard continue d’évoluer doucement, soit pour pallier des incohérences, avec par exemple l’introduction d’une fonction map pour les ensembles Set, soit pour s’adapter à l’évolution du code idiomatique OCaml, avec par exemple l’ajout de variantes de fonctions utilisant des options plutôt que des exceptions pour gérer les éléments manquants dans des Set ou des Map.

Amélioration du compilateur

Ces deux cycles de développements auront vu aussi un grand nombre d’améliorations internes du compilateur et de son écosystème : le système de construction du compilateur est en train de subir un sévère ménage de printemps, tandis que les tests d’intégration continue ont été améliorés, notamment pour mieux supporter les anciennes versions de Windows. Parallèlement, un travail de fond est en cours pour améliorer le déverminage de programme OCaml et préparer le changement de modèle de mémoire nécessaire pour une future version multicœur d’OCaml.

Ces évolutions n’apportent pas encore de changements visibles pour la plupart des utilisateurs, mais devraient porter leurs fruits dans les versions à venir.

Un changement plus visible, même s’il ne concerne essentiellement que des utilisateurs experts, est l’intégration progressive d’une architecture de greffons (plugins) dans le compilateur. Pour l’instant, ces greffons peuvent, par exemple, transformer l’arbre de syntaxe abstrait comme le ferait un préprocesseur basé sur les points d’extensions, effectuer une passe de vérification supplémentaire sur les types inférés par le vérificateur de type du compilateur, ou encore modifier la représentation interne Lambda.

Reason

En dehors de l’évolution du langage lui‐même, un projet inhabituel est né récemment dans les locaux de Facebook1. Ce projet se nomme Reason et a pour but de rénover la syntaxe d’OCaml. Il a été initié par un petit groupe mené par Jordan Walke (le créateur initial de la bibliothèque React).

L’objectif

La raison de Reason (huhu !) est que la syntaxe d’OCaml rebute certaines personnes. Cependant, OCaml s’inscrit de plus en plus dans le milieu industriel (comme le montrent les exemples de Facebook, mais aussi Jane Street, dans une tout autre mesure). Dans un désir de démocratisation, l’équipe ReasonML décida de créer une nouvelle syntaxe pour OCaml du nom de Reason. Comparé à la syntaxe originale d’OCaml, Reason se rapproche de la syntaxe de JavaScript. Par exemple, les accolades et les points‐virgules font un retour en force :

let hello name_opt = let name = match name_opt with | None -> "world" | Some x -> x in Format.printf "Hello %s!" name

devient :

let hello name_opt => { let name = switch name_opt { | None => "world"; | Some n => n; }; Format.printf "Hello %s!" name }

D’une certaine manière Rust a eu la même idée en proposant une syntaxe très proche du C++. Elixir rejoint le même objectif dans une autre mesure.

La syntaxe de Reason essaye également d’augmenter la cohérence interne de la syntaxe et de corriger des erreurs historiques. Par exemple, les constructeurs de types se lisent de droite à gauche comme les fonctions dans Reason :

type constructeur_de_type 'argument = { id:int, x:'argument }

L’objectif est, bien entendu, plus large et a amorcé notamment un élan autour des outils qui peuvent aider le développeur à utiliser OCaml. Le top‐level interactif amélioré utop, qui semble unanimement reconnu comme étant l’outil pour tester du code OCaml, fut réutilisé pour Reason et l’accueil auprès des nouveaux développeurs (extérieurs à la communauté OCaml) fut couronné de succès.

Le service d’aide à l’édition merlin, qui permet d’intégrer la coloration syntaxique, mais aussi l’inférence de type dans les éditeurs, eut aussi son intégration avec Reason et tout ceci apporta une légitimité à la continuation de ces projets pour Reason mais aussi pour OCaml.

Enfin, le gestionnaire de paquets opam reste toujours la pierre angulaire de l’écosystème d’OCaml et donc l’est aussi par définition pour Reason. Ce dernier se voit donc désormais utilisé par des gens n’ayant pas forcément en tête les subtilités de l’écosystème d’OCaml (comme ocamlfind).

Au‐delà de cette nouvelle syntaxe, l’équipe de Reason attache donc une attention particulière à l’environnement de développement d’OCaml. Cela permet notamment d’apporter une réelle critique extérieure aux outils de développement OCaml et en particulier une critique justifiée sur la difficulté de prise en main de ces outils pour un débutant.

Ce qu’est Reason

Reason n’est ni plus ni moins qu’une option dans le compilateur. Nous parlons ici de l’option -pp qui permet de remplacer la partie frontale du compilateur par un préprocesseur ad hoc. Le préprocesseur Reason prend donc du code Reason en entrée, le transforme en arbre de syntaxe abstrait OCaml et passe cet arbre au compilateur OCaml classique.

Ceci permet entre autres de garder la compatibilité avec l’existant et de profiter à la fois des logiciels et bibliothèques déjà développés en OCaml et de la nouvelle syntaxe Reason, et réciproquement. Il existe d’ailleurs un outil permettant de convertir du code OCaml vers du code Reason !

Partager la partie centrale du compilateur permet également d’utiliser les différents back‐ends disponibles pour OCaml. En particulier, OCaml dispose de deux back‐ends JavaScript : js_of_ocaml et bucklescript. Le premier, js_of_ocaml, est plus ancré dans l’écosystème OCaml, tandis que le second, bucklescript, est plus tourné vers l’écosystème JavaScript et dispose d’une intégration avec npm, un gestionnaire de paquets JavaScript.

Grâce à ces back‐ends, l’équipe ReasonML a pu convertir environ 25 % du code de FaceBook Messenger en code Reason.

Un avenir imprévisible

On peut cependant s’interroger sur l’interaction de la communauté OCaml existante et de cette nouvelle communauté Reason, bien plus centrée sur le Web, l’écosphère JavaScript et npm. Les atomes crochus n’abondent pas forcément entre ces deux communautés.

Le bon point reste tout de même l’ouverture de l’écosystème d’OCaml à des développeurs qui ne faisaient pas de l’OCaml. Cela permet notamment d’apporter des perspectives neuves et de revitaliser des problématiques de développement parfois oubliées dans l’écosystème OCaml.

Le succès n’est peut‐être pas au rendez‐vous et le projet a encore besoin de faire ses preuves auprès d’un large public (problématique qu’on peut corréler avec Hack auprès de ceux qui font du PHP d’ailleurs). Mais le retour ne semble être que bénéfique au final pour l’ensemble des communautés !

  1. elle a été extérieure puisqu’elle a été initiée par Facebook alors que ce dernier ne faisait pas encore partie du consortium OCaml. ↩

Télécharger ce contenu au format Epub

Lire les commentaires

Fedora 26 est sortie !

11 juillet, 2017 - 16:57

En ce mardi 11 juillet 2017, le projet Fedora est fier d’annoncer la sortie de la distribution GNU/Linux Fedora 26.

Fedora est une distribution communautaire développée par le projet éponyme et sponsorisée par Red Hat, qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora peut se voir comme une sorte de vitrine technologique pour le monde du logiciel libre, c’est pourquoi elle est prompte à inclure des nouveautés.

Sommaire Environnement bureautique

L’environnement bureautique par défaut, GNOME, évolue à la version 3.24. Cette version propose entre autres :

  • les icônes du projet GNOME ont été redessinées, pour être plus grandes et modernes ;
  • la mise à disposition du mode nuit, pour que les couleurs de l’interface passent progressivement au rouge durant la nuit pour prévenir la fatigue oculaire ;
  • un rafraîchissement de l’interface du centre de configuration, pour la simplifier et la rendre plus cohérente avec le reste : par exemple, vous pourrez voir le niveau d’encre de vos imprimantes sans avoir à les sélectionner ;
  • la nouvelle application Recettes, pour lire, rédiger ou évaluer des recettes de cuisine ;
  • les tablettes Wacom sont prises en charge sous Wayland et leur configuration a été raffinée ;
  • la zone de notification a été améliorée et propose en plus les informations météorologiques ;
  • des corrections et des nouvelles fonctionnalités dans les applications Photos, Web, Polari, Builder, etc.

Utilisation de l’interface graphique de blivet pour le partitionnement dans l’installateur Anaconda, en plus de l’interface traditionnelle. L’objectif est de fournir une autre approche pour cette étape cruciale afin de satisfaire les besoins du plus grand nombre, c’est pourquoi l’interface traditionnelle reste disponible. L’approche d’Anaconda était top‐down, à savoir que l’utilisateur définissait ses points de montage et ses propriétés afin qu’Anaconda définisse les partitions correspondantes et leur agencement. Avec blivet, c’est plutôt l’inverse car les disques et leurs états sont affichés pour que l’utilisateur puisse concevoir les partitions et volumes logiques avant de définir à la fin les points de montage. Cette interface est donc plus proche de ce que propose GParted.

Le pilote Synaptics pour les pavés tactiles, dans les sessions Xorg, est remplacé par libinput. Le paquet xorg-x11-drv-synaptics est donc supprimé par défaut, mais reste disponible dans les dépôts pour ceux qui le souhaitent. L’objectif est de mutualiser cette partie avec Wayland (qui repose sur libinput également) et de bénéficier de ses options de configuration et autres fonctionnalités comme la gestion des gestes (comme zoomer en pinçant) et du multi‐point.

Création d’une image dédiée (dite spin) avec l’environnement LXQt par défaut. Cet environnement de bureau repose sur la bibliothèque Qt, tout comme KDE par exemple, et était disponible depuis Fedora 22 dans les dépôts. Cet environnement se veut cependant plus léger que KDE en restant plus simple. Il est donc possible pour ses utilisateurs d’installer Fedora avec uniquement cet environnement, sans recourir à un environnement intermédiaire ou à une installation textuelle.

Fedora Media Writer prend en charge les images ARM. L’installateur officiel et recommandé pour générer et écrire vos images de Fedora sur vos médias d’installation gère donc plus d’architectures. Pour rendre cela possible, FMW gère mieux les cartes SD, qui sont préférées aux clés USB sur cette architecture généralement. Les cartes à base de processeurs ARM officiellement supportées pour le moment sont les Raspberry 2 et 3.

Passage des adresses virtuelles de 42 à 48 bits pour l’architecture AARCH64, ce qui devrait améliorer les performances pour ces processeurs. L’objectif est que les processus puissent bénéficier de plus de mémoire virtuelle. Cela permet dans la foulée de pouvoir mieux exploiter les machines ayant une grande portion de la mémoire vive dans les adresses hautes. Il a fallu corriger entre autres les paquets mozjs et luajit pour activer ce changement.

Mise à jour de libpinyin vers la version 2.0 pour les entrées de saisies en chinois Pinyin. Le Pinyin est la méthode officielle de translittération du chinois en alphabet latin qui repose sur la prononciation des mots. Par exemple, Pékin, en français, s’écrit 北京 en chinois traditionnel et Běijīng en Pinyin. Cette nouvelle version propose plusieurs phrases de suggestions à la volée plutôt qu’une seule, pour améliorer l’efficacité de la saisie.

Administration système

Les utilisateurs locaux identifiés avec le démon sssd bénéficient d’un cache de fichiers locaux plus rapide. En effet, le cache mémoire de sssd entrait en conflit avec nscd qui était donc désactivé, ce qui ruinait les performances pour les accès aux fichiers. Dorénavant, le cache de fichiers provient de sss du projet NSS améliorant à nouveau les performances du système dans ce cas.

La machine virtuelle Java OpenJDK et le projet OpenSSH rejoignent les politiques de sécurité de GnuTLS, NSS et OpenSSL en utilisant la même politique de sécurité de mots de passe qu’eux. En effet, depuis quelques versions de Fedora, les utilitaires pouvant avoir une politique de mots de passe, par exemple de huit caractères avec au moins un chiffre et deux majuscules, bénéficient peu à peu de l’unification de cette politique. En définissant la politique une fois via l’utilitaire update-crypto-policies, elle sera disponible pour l’ensemble des applications compatibles.

systemd-coredump est activé par défaut. coredumpctl était en effet en conflit avec ABRT pour la gestion des fichiers core (vidage mémoire) des applications non officiellement empaquetées dans Fedora, chacun changeant /proc/sys/kernel/core_pattern, et ABRT avait le dernier mot. Maintenant, abrt-ccpp.service est désactivé par défaut pour laisser systemd prendre la main, ce comportement étant réversible. ABRT étant plus utilisée pour l’assurance qualité et systemd par les développeurs, la politique par défaut actuelle convient donc mieux, car ABRT est moins utile pour des crashes d’applications non empaquetées que systemd et vice versa pour les applications empaquetées par Fedora. Cela n’a un impact que pour les applications compilées, les exceptions en Python ou Java sont toujours du ressort d’ABRT.

Mise à disposition d’une image Docker minimale pour réduire au maximum la taille des conteneurs. Il est possible de l’étendre via dnf ensuite, et prochainement de la personnaliser et de la générer via kickstart. L’objectif est de les rendre plus légères en cas d’utilisation intensive tout en laissant le choix à son utilisateur de la personnaliser pour que l’image Docker n’ait que le strict nécessaire.

L’image Docker utilise maintenant OverlayFS 2 par défaut afin d’améliorer les performances. Cela permet à l’image Docker de partager en partie les ressources présentes dans votre installation principale ; en mutualisant les fichiers et les accès nous disposons donc mécaniquement de plus d’espace disque et de meilleures performances. Attention cependant, ce système de fichiers n’est pas totalement conforme au standard POSIX, ce qui peut causer des bogues dans certains programmes exécutés dans les conteneurs. Il est toujours possible de retourner au mode DeviceMapper utilisé jusqu’à présent.

Toujours à propos de Docker et de Python, son SDK exploitable par Python est disponible en version 2, conformément aux décisions du projet officiel qui est mis à disposition dans le paquet python3-docker. L’ancienne version reste disponible grâce au paquet python-docker-py, mais il devrait être supprimé dès Fedora 27.

Le répertoire de cache de Fontconfig passe de /var/cache/fontconfig à /usr/lib/fontconfig/cache pour mieux fonctionner sur le système à base d’OSTree, à savoir Fedora Atomic.

Authconfig a été nettoyé, supprimant la gestion de Hesiod, mais aussi l’interface utilisateur, que ce soit l’interface graphique ou l’interface en mode texte (TUI). En effet, cet outil d’aide à la configuration des utilisateurs PAM, Kerberos ou LDAP avait de nombreuses portions de code non maintenu, notamment les interfaces utilisateur, car plus nécessaires, remplacées entre autres par des outils d’auto‐configuration tels que SSSD ou Realmd qui font ce travail convenablement. Authconfig est donc conservé pour des opérations plus manuelles, nécessaires dans certains cas (comme PAM ou NSSWITCH), et ne conserve de fait que le strict minimum pour remplir son rôle avec une certaine valeur ajoutée. Le code sera également plus simple à maintenir à l’avenir.

La bibliothèque de gestion des cartes cryptographiques PKCS#11 Coolkey est remplacée par OpenSC par défaut, pour une suppression prévue lors de la sortie de Fedora 27. Les deux étaient jusque‐là utilisées conjointement à cause notamment de la bibliothèque NSS qui employait encore Coolkey. Cependant, ce dernier n’est plus vraiment maintenu, alors qu’OpenSC bénéfice, entre autres, de nouveaux pilotes pour les cartes les plus récentes. La présence des deux, en plus d’être redondante, créait de la confusion lors de la configuration des systèmes.

L’interpréteur de Python 3 passe la gestion de la locale par défaut C à C.UTF-8, sauf si la variable d’environnement PYTHONCOERCECLOCALE vaut 0. Cela est particulièrement important pour les environnements cloisonnés tels que Docker, Flatpak, OpenShift ou lors de la création des paquets dans rpmbuild et mock, car les erreurs d’encodage du texte y sont fréquentes faute de paramétrage correcte de la locale du système qui se rabattait dès lors sur la locale C qui utilise le codage ASCII. Le passage à l’UTF-8 permettra donc la gestion correcte des chaînes de caractères dans la majorité des cas dans ce contexte, la variable d’environnement proposée permettant de régler les éventuels problèmes générés par ce changement.

Le serveur DNS BIND a une mise à jour vers la version 9.11. Cette version comporte de nombreuses nouvelles fonctionnalités et des comportements ont changé, n’hésitez donc pas à lire les notes de versions complètes pour éviter les surprises. Nous pouvons noter entre autres : l’ajout d’un module Python pour effectuer des commandes rndc, un nouveau gestionnaire de clés DNSSEC dnssec-keymgr, l’interrogation des serveurs par nslookup par défaut, aussi bien en IPv4 qu’en IPv6, le nombre d’écouteurs de requêtes UDP est maintenant lié au nombre de processeurs de la machine, et bien plus encore.

Mise à jour d’OpenSSL à la version 1.1.0. Cette version est la nouvelle branche bénéficiant de nouvelles fonctionnalités tout en ayant un grand nettoyage de ses API et ABI. Les algorithmes SSL v2 et 3DES ne sont plus activés par défaut, pour des raisons de sécurité, de nombreuses structures deviennent opaques pour faciliter l’évolution de l’API, de nombreuses options et portions de codes mortes ont été supprimées. La compatibilité avec la version précédente est maintenu via le paquet compat-openssl10

Le gestionnaire de paquets par défaut, DNF, passe à la version 2.0. Une rupture d’API a eu lieu, supprimant la compatibilité avec quelques extensions. Elle ajoute l’option --with-optional pour l’installation des groupes, afin d’installer aussi les paquets recommandés par le groupe. Des options de YUM (son prédécesseur) font leur retour : includepkgs et excludepkgs, pour établir des règles de sélections des paquets pour cette commande.

Développement

Fedora 26 dispose de la suite de compilateurs GCC dans sa version 7. Cette version propose des suggestions de noms en cas d’erreurs pour des macros, fonctions ou types dans les langages C et C++. Pour ces mêmes langages, les opérations arithmétiques peuvent être contrôlées pour détecter des dépassements. Le C++17 est géré à titre expérimental. Le Go est pris en charge dans sa version 1.8, alors que Java n’est plus proposé via GCJ. Enfin, Fortran dispose de la gestion d’OpenMP 4.5.

La bibliothèque standard Glibc progresse à la version 2.25. Au menu, principalement une implémentation de la norme ISO TS 18661-1:2014 concernant la partie mathématique. Cette norme ajoutant, par exemple, des macros pour identifier les valeurs NaN, de nouvelles fonctions d’arrondis, la transformation des flottants en chaînes de caractères ou des fonctions de classification, comme dire si un nombre est bien un zéro.

La bibliothèque majeure du C++ Boost donne un coup de boost à la version 1.63. Depuis la dernière version embarquée, la 1.60, Boost bénéficie du module QVM pour manipuler les quaternions, les vecteurs et matrices à tailles fixes. Un module Compute apparaît aussi pour la prise en charge du calcul parallèle, notamment sur processeur graphique à travers OpenCL. Un dernier module, Fiber, apporte un complément à la gestion des fils d’exécution.

Le langage Python rampe à la version 3.6. Parmi les nouveautés, les arguments donnés à une fonction sont ordonnés, tout comme l’ordre des attributs dans une classe, et la possibilité d’utiliser directement le nom des variables dans une chaîne de caractères pour gagner en lisibilité. Les classes disposant d’une implémentation de la fonction ''fspath'' peuvent bénéficier du protocole de manipulation des chemins de fichiers. Une classe mère peut forcer l’exécution de fonctions particulières à ses classes filles. Et, tout comme désormais le C++, Python propose d’améliorer la lisibilité des grands nombres en autorisant des séparations de blocs de chiffres par '''' comme _100000 devient 100_000.

Mise à disposition d’une nouvelle variante Fedora Lab centrée sur le développement autour de Python, disponible également par Docker et Vagrant. Cette initiative vise à aider les professeurs ou animateurs d’ateliers en leur mettant à disposition une image de Fedora prête à l’emploi pour ce genre d’activité.

Le compilateur de Haskell GHC passe à la version 8.0. Cette version s’est concentrée sur la possibilité de personnaliser les messages d’erreurs de type, l’interpréteur peut être exécuté dans un processus externe, offrant la possibilité d’étudier les performances du programme, la gestion de plus d’architectures matérielles dont une amélioration à propos d’ARM. Le format de données de débogage DWARF est plus fiable. Et une nouvelle documentation !

Le compilateur Go officiel fonce à la version 1.8. Cette nouvelle amélioration dans la chaîne de compilation propose des performances améliorées du binaire de 15 à 30 %, le ramasse‐miettes est lui aussi plus rapide et des changements assez mineurs sont apportés aux bibliothèques.

Le compilateur du langage D, LDC, donne la réponse 1.1.0 concernant sa version. Les amateurs du langage pourront bénéficier de l’ajout de l’optimiseur, lors de l’édition de liens provenant de LLVM, de fonctions mathématiques plus optimisées. L’ajout également des optimisations par profil, ce qui permet de gagner en performances. Ce dernier point analyse en fait le flux du programme (le nombre de fois qu’une fonction est appelée, le lien entre les classes, etc.) pour optimiser les chemins les plus souvent exécutés au détriment des autres. Cela aboutit à environ 5 à 10 % de gain. Là encore, au détriment du temps de compilation.

Le langage Ruby brille dans sa version 2.4. Comme pour beaucoup de langages cités précédemment, les performances sont la source de toutes les attentions. Tout d’abord, les tables de hachage via un changement de structure interne. Mais aussi les minimums et maximums des tableaux, les accès à des variables d’instance ou les correspondances des expressions rationnelles sont aussi plus rapides. Conformément à la norme ISO/IEC 30170:2012 sur les nombres entiers, Ruby s’est autorisé à fusionner les classes BigNum et Fixnum en Integer pour la gestion des entiers. Enfin, les fonctions de gestion des caractères, comme définir la minuscule d’un caractère, prennent en charge l’Unicode et non uniquement l’ASCII.

Le langage PHP s’impose avec la version 7.1. Les arguments ou retours de fonctions peuvent prendre pour valeur NULL pour signifier une erreur, de même que les fonctions qui ne retournent rien. Les membres constants d’une classe peuvent bénéficier d’une définition de leur visibilité (privé, protégé ou public). L’ajout des itérateurs pour parcourir un objet implémentant l’interface traversable. Les blocs try {} catch() {}_ peuvent gérer plusieurs exceptions parcatch()`. Et comme d’autres langages tel que Python, l’index des chaînes de caractères peut être négatif. Enfin, ajout des gestionnaires de signaux asynchrones.

Mais la patrouille des éléphants bénéficie aussi d’une mise à jour du cadriciel Zend à la version 3. Au menu, de meilleures performances, de l’ordre d’un facteur 4. La compatibilité avec PHP 7. Un meilleur découpage des modules et une documentation plus complète sont aussi disponibles. Cela permet, entre autres, de développer les modules séparément et donc de proposer des améliorations plus souvent. Pour finir, il propose la possibilité d’utiliser Zend comme un micro-cadriciel et non plus uniquement l’architecture complète en MVC, si besoin.

pkgconf est maintenant l’implémentation de référence pour le système pkgconfig, qui était géré par pkg-config jusqu’ici. Ce programme qui interprète les fichiers .pc pour retrouver les bibliothèques installées sur le système de manière standard et multi‐plate‐forme. Cette nouvelle implémentation possède un meilleur gestionnaire de performances, n’a pas de dépendance avec la glib2, qui entraînait une dépendance circulaire, et gère plus de fonctionnalités offertes par ces fichiers, comme les provides et CFLAGS.private. Vous pouvez consulter ce tableau comparatif entre les deux solutions pour en savoir plus.

Autour de Fedora

Les CFLAGS par défaut des paquets ont changé pour les programmes C et C++ pour supprimer l’optimisation concernant les processeurs Atom, afin d’accélérer le fonctionnement des programmes pour les autres processeurs i686. D’autant plus que non seulement l’Atom n’est plus commercialisé, mais aussi que Fedora ne prend pas en charge leur UEFI 32 bits.

Les paquets reposant sur le langage Go bénéficieront par défaut de l’option Position Independent Executables, pour plus de sécurité. Cette option, déjà activée pour les programmes C et C++ depuis un moment, permet de complexifier la tâche des attaquants qui essayeraient d’exploiter des failles de sécurité à des adresses précises du programme, les adresses variant à chaque fois pour chaque machine.

Mise à disposition comme expérimentale de la modularité dans une déclinaison de Fedora Server nommée Boltron. L’objectif de la modularité est d’implémenter les résolutions prises du projet Fedora.NEXT, dont le but est de pouvoir utiliser des logiciels, ou plus exactement des piles applicatives, en dehors des cycles de développement de Fedora.

Par exemple, Fedora 26 propose par défaut Node.js en version 6.10. Sauf que la version 8 est disponible et que faute d’applications compatibles et de support assez long de Node.js, Fedora ne l’utilise pas encore. Vous pouvez donc installer la version 8 en utilisant la commande :

dnf install nodejs-8

Pour revenir à la version par défaut de Node.js pour Fedora 26, il suffit de faire :

dnf install nodejs-f26

Pour l’instant, ce sont surtout des piles applicatives qui sont prises en charge : PHP, Apache, MariaDB, PostgreSQL, DHCP, Perl, etc. Notons que c’est encore en expérimental et que les possibilités offertes restent pour l’instant limitées. Vous pouvez suivre sur YouTube leurs progrès hebdomadaires.

La communauté francophone Rencontres Fedora 26

L’association Borsalinux-fr, qui gère la promotion de Fedora dans l’espace francophone, a organisé les Rencontres de Fedora 26 le 1er juillet à Paris pour présenter Fedora et la (future) Fedora 26 qui est sortie plus tard que prévu.

Outre l’aide apportée à quelques visiteurs, cela a été l’occasion de dispenser trois présentations dont les supports sont disponibles ci‐dessous :

Pour assurer la continuité de ce genre d’initiatives et poursuivre notre présence à des évènements tels que les RMLL, nous sommes toujours à la recherche de nouveaux membres.

La traduction

D’après le dernier état des lieux de début juillet 2017, la traduction française est dans l’état suivant :

  • sites Web : 100 % ;
  • documentation : 38 % ;
  • logiciels liés à Fedora : 100 % ;
  • paquets prioritaires : 99,3 % ;
  • autres paquets : 47,7 %.

La langue française est donc parmi les meilleures traductions de Fedora en termes de couverture, la documentation est en retrait car l’équipe de la documentation entreprend depuis un an un véritable changement de son infrastructure, complexifiant sa production dans les temps pour une traduction pertinente.

Si vous souhaitez donner un coup de main, n’hésitez pas à rejoindre l’équipe, il y a toujours du travail pour avoir une distribution bien traduite !

La documentation francophone

Fedora-fr dispose de son propre wiki, pour écrire sa documentation indépendante, pour guider les nouveaux venus, résoudre des problèmes courants ou autres.

Cependant, depuis 2011-2012, la documentation n’était plus vraiment maintenue et cela commençait à se ressentir sur la qualité des documents qui devenaient obsolètes.
C’est pourquoi, depuis début juin 2017, des ateliers hebdomadaires ont lieu chaque lundi soir à partir de 21 h sur IRC pour remédier au problème.

Depuis de nombreuses pages ont été corrigées et le travail continue. N’hésitez pas aussi à contribuer également !

De manière générale, vous pouvez également participer au projet Fedora.

Fedora 27

La prochaine version de Fedora est prévue pour fin octobre 2017.

À ce stade, outre les mises à jour habituelles, nous aurons normalement le droit à :

  • la disparition des versions alpha, au profit d’une meilleure stabilité de la branche en développement Rawhide ;
  • une intégration par défaut des pilotes invités de VirtualBox ;
  • une clarification de ce qui est configuré lors de l’installation via Anaconda et en post‐installation sur chaque environnement de bureau (en particulier GNOME) ;
  • un recours plus important et mieux intégré aux applications disponibles par Flatpak.

Bien sûr, nous vous donnons rendez‐vous à sa date de sortie pour faire un point plus complet.

Télécharger ce contenu au format Epub

Lire les commentaires

Meilleures contributions LinuxFr.org : les primées de juin 2017

10 juillet, 2017 - 18:30

Nous continuons sur notre lancée de récompenser ceux qui chaque mois contribuent au site LinuxFr.org (dépêches, commentaires, logos, journaux, correctifs, etc.). Vous n’êtes pas sans risquer de gagner un abonnement à GNU/Linux Magazine France ou encore un livre des éditions Eyrolles ou ENI. Voici les gagnants du mois de juin 2017 :

Abonnement d’un an à GNU/Linux Magazine France (éditions Diamond)

Livres des éditions Eyrolles et ENI

Les livres qu’ils ont sélectionnés sont en seconde partie de la dépêche. N’oubliez pas de contribuer, LinuxFr.org vit pour vous et par vous !

Certains gagnants n’ont pas pu être joints ou n’ont pas répondu. Les lots ont été réattribués automatiquement. N’oubliez pas de mettre une adresse de courriel valable dans votre compte ou lors de la proposition d’une dépêche. En effet, c’est notre seul moyen de vous contacter, que ce soit pour les lots ou des questions sur votre dépêche lors de sa modération. Tous nos remerciements aux contributeurs du site ainsi qu’à GNU/Linux Magazine France, aux éditions Eyrolles et ENI.

Les livres sélectionnés par les gagnants :

                        Télécharger ce contenu au format Epub

Lire les commentaires

Agenda du Libre pour la semaine 28 de l’année 2017

8 juillet, 2017 - 19:55

Calendrier Web, regroupant des événements liés au Libre (logiciel, salon, atelier, install party, conférence), annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 13 événements (0 en Belgique, 11 en France, 0 au Luxembourg, 2 au Québec et 0 en Suisse) est en seconde partie de dépêche.

On peut noter que l’Agenda du Libre est désormais disponible pour deux nouveaux pays, le Luxembourg et la Tunisie. Comme ils viennent d’être créés, ils sont vides pour le moment, n’hésitez pas à les remplir.

Sommaire [FR Montpellier] WikiPermanence - Le lundi 10 juillet 2017 de 20h00 à 22h00.

Une WikiPermanence est une rencontre physique entre des wikipédiens chevronnés et de nouveaux ou futurs wikipédiens qui souhaitent acquérir des connaissances et des conseils sur le fonctionnement de Wikipédia. Il ne s’agit pas d’une simple rencontre entre wikipédiens : la WikiPermanence est là pour répondre aux questions, permettre des démonstrations, offrir une aide aux premiers pas et, si cela se fait régulièrement, permettre un suivi.

Elles nous permettront d’aborder les sujets tels que :

  • Un instant est prévu pour l’initiation des débutants
  • Journées contributives Wikipédia à Arles
  • Liberté de panorama
  • Présentation du guide pratique des groupes locaux
  • Le partenariat avec les archives départementales de l’Hérault
  • Préparer les prochains WikiCheeses
  • Planifier la prochaine Opération Libre
  • Impulser une dynamique
  • Promouvoir la diffusion de la connaissance libre
  • Apprendre à contribuer
  • Échanger des expériences
  • Faire un bilan des événements passés
  • Faire des perspectives pour les actions futures
  • Et tout simplement, passer un moment convivial

N’hésitez pas à venir : c’est sans inscription, et vous l’aurez deviné, libre et gratuit !

Wikipédia est une encyclopédie libre rédigée collaborativement par des milliers d’internautes. Mais, saviez-vous que vous pouviez y participer ? En apportant des connaissances, en créant ou améliorant des articles, en prenant des photos, ou simplement en corrigeant des fautes, vous pouvez contribuer à ce grand projet d’encyclopédie collaborative.

Alors, venez participer aux rendez-vous des WikiPermanences de Montpellier qui auront lieu à l’Atelier de Pigistes, le deuxième lundi de chaque mois, de 18h00 à 20h00 :

  • lundi 12 septembre 2016 de 18h00 à 20h00
  • lundi 10 octobre 2016 de 18h00 à 20h00
  • lundi 14 novembre 2016 de 18h00 à 20h00
  • lundi 12 décembre 2016 de 18h00 à 20h00
  • lundi 9 janvier 2017 de 18h00 à 20h00
  • lundi 13 février 2017 de 18h00 à 20h00
  • lundi 13 mars 2017 de 18h00 à 20h00
  • lundi 10 avril 2017 de 18h00 à 20h00
  • lundi 8 mai 2017 de 18h00 à 20h00
  • lundi 12 juin 2017 de 18h00 à 20h00
  • lundi 10 juillet 2017 de 18h00 à 20h00

Cet événement est proposé par le tri-partenariat Club de la Presse, Wikipédia et Montpel’libre.

Atelier des Pigistes au 171, rue Frimaire, 34000 Montpellier

Tramway lignes 1 et 3, arrêts Port-Marianne et Rives du Lez
GPS Latitude : 43.603095 | Longitude : 3.898166
Carte OpenStreetMap

[FR Rennes] Réunion mensuelle OpenStreetMap - Le lundi 10 juillet 2017 de 20h00 à 22h00.

L'association Gulliver propose chaque 2e lundi du mois une réunion autour du projet de cartographie collaborative OpenStreetMap.

L'occasion de découvrir le projet, de venir échanger sur les nouveauté, de partager vos initiatives.

[FR Dijon] Rencontre des utilisateurs et des contributeurs de cartographie libre OpenStreetMap - Le mardi 11 juillet 2017 de 20h30 à 23h30.

OpenStreetMap crée et fournit des données géographiques libres, telles que des cartes routières ou cyclables, à quiconque en aura besoin. Cet outil est né parce que la plupart des cartes que vous pensez libres ont des restrictions légales ou techniques qui nous empêchent de les utiliser de façon créative, productive ou innovante.

Les contributeurs OpenStreetMap (OSM) de Dijon et de sa région se rencontrent régulièrement et chacun peut s'inviter et participer. Ces rencontres permettent d'ajouter des données récoltées sur place ou avant la rencontre. Elles permettent également de partager connaissances et outils.

La prochaine rencontre des contributeurs de la région a pour thème "petites contributions et échanges de bonnes pratiques", elle aura lieu le mardi 11 juillet à partir de 20h30 au bar L'Annexe au 47 rue Devosge à Dijon.

Venez nombreux, enfin pas trop quand même :-)

[FR Montpellier] Install Par Tous ! Install Party ! - Le mercredi 12 juillet 2017 de 12h00 à 17h00.

Reprenez le contrôle de vos machines. Avec un Gnou et un Manchot

Communément appelées "Install Party" ces événements sont dédiés à l'installation, mais aussi et surtout au support, de systèmes GNU/Linux sur vos ordinateurs personnels (ou pro d'ailleurs), dans le but de se passer des méchants systèmes d'exploitation qui rament, espionnent, et vous ont été imposés.

Bref reprendre le contrôle de vos machines pour de vrai !

Déroulement typique de l’installation sur un ordi :

  • Discuter ! Savoir quel sont vos attentes pour ce nouveau système : faut-il des outils spécifiques, aurez-vous tout ce qu'il vous faut pour profiter de votre appareil, supportera-t-il telle ou telle techno, etc.
  • Déterminer la bonne distribution en fonction de l'appareil (capacité, mémoire, cpu, etc), mais aussi en fonction de vos attentes.
  • Essayer ! La plupart des distributions linux peuvent tourner sur votre appareil sans les installer (Live) en utilisant uniquement la mémoire vive, sans toucher au disque dur. Cela permet de vérifier qu'elle marche correctement, et qu'elle réponds aux attentes.
  • Backup ! Il est fortement recommandé de faire des sauvegardes de toutes vos données AVANT DE VENIR. Cette étape peut-être longue, fastidieuse, et surtout ne concerne personne d'autre que vous (aucune raison d'avoir vos données qui se baladent sur des disques ou clef USB dans le hackerspace). Mais le cas échéant nous nous doterons d'un moyen de sauvegarde, ou vous amenez le votre, et on sauve tout ce qui peux être sauvé.
  • INSTALL !!! Cette fois-ci c'est parti on installe le système sur le disque dur, en éliminant le précédent (recommandé ;) ), ou en le conservant sur le coté au cas où (but why ?).
  • On finalise enfin l'installation par l'ajout des logiciels dont vous avez besoin, et on en profite pour vous montrer comment le faire vous même, comment se gèrent les mises à jour, et toutes les astuces propre à GNU/linux pour que vous soyez à l'aise dans votre nouvel environnement.

Une fois rentré à la maison avec votre ordinateur tout propre, il se peut que vous rencontriez encore des difficultés (y'a pas de raisons mais ça arrive), pas de problèmes nous avons conçu cet atelier pour qu'il soit régulier et porté également sur le support, l'aide aux nouveaux utilisateurs. Donc notez vos questions, vos problèmes dans un coin, et repassez nous voir la semaine suivante ! (vous pourrez également nous poser des questions sur IRC (chat) ou sur la mailling liste, si vous ne pouvez pas attendre)

En espérant libérer un maximum de vos machines !

[FR Chartres] OpenAtelier - Le mercredi 12 juillet 2017 de 20h00 à 23h59.

L'OpenAtelier est un moment de rencontre et de partage ou les membres et curieux sont invités à échanger sur leurs idées et leurs projets.

Les espaces techniques sont également ouverts aux réalisations (électronique, informatique, menuiserie, impression 3D, découpe vinyle…).

Pour les curieux, c'est le bon moment pour venir découvrir l'association et ses membres.

[FR Toulouse] Rencontre Tetalab - Le mercredi 12 juillet 2017 de 21h00 à 23h00.

Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

[QC Montréal] Atelier du Libre du Club Linux Atomic - Le jeudi 13 juillet 2017 de 18h00 à 21h30.

Le Club Linux Atomic
Le Club Linux Atomic (CLA) regroupe des utilisateurs, novices comme aguerris, de systèmes d’exploitation GNU/Linux et de logiciels libres. Il a pour principal objet de mieux faire connaître l’informatique libre et d’en favoriser l’utilisation par le plus grand nombre.
Atelier du Libre

[FR Paris] Soirée de Contribution au Libre - Le jeudi 13 juillet 2017 de 19h30 à 22h30.

Parinux propose aux utilisateurs de logiciels libres de se réunir régulièrement afin de contribuer à des projets libres. En effet, un logiciel libre est souvent porté par une communauté de bénévoles et dépend d'eux pour que le logiciel évolue.

Nous nous réunissons donc tous les jeudis soirs dans un environnement propice au travail (pas de facebook, pas de télé, pas de jeux vidéos, pas de zombies).

Vous aurez très probablement besoin d'un ordinateur portable, mais électricité et réseau fournis.

En cas de difficulté, vous pouvez joindre un des responsables de la soirée, Emmanuel Seyman (emmanuel (at) seyman.fr), Paul Marques Mota mota (at) parinux.org, ou Magali Garnero (Bookynette) tresorier (at) parinux.org.

Pour obtenir le code d'entrée de la porte cochère, envoyez un mail au responsable.

On peut amener de quoi se restaurer (Franprix, 8 rue du Chemin Vert, ferme à 22h)

Regazouillez sur Twitter - Wiki des soirées

Programme non exhaustif

  • Fedora (sa traduction)
  • Parinux, ses bugs et son infrastructure
  • April, … y a toujours quelque chose à faire
  • Open Food Facts/ Open Beauty Facts, sa base de données, ses contributeurs, sa roadmap
  • Schema racktables, son code
  • Agenda du Libre, mise à jour et amélioration du code
  • Ubuntu-Fr, son orga, ses événements
  • En vente libre, maintenance et commandes
  • Open street map, une fois par mois
  • Linux-Fr sait faire
  • …

tout nouveau projet est le bienvenu.

[QC Coteau du Lac] Émission #135 de bloguelinux - Le jeudi 13 juillet 2017 de 20h00 à 22h00.

bloguelinux.ca est un blogue québécois offrant la diffusion d'un podcast qui traite des logiciels libres, du système d'exploitation Linux et de la technologie en général ; il y a un processeur, il y a un système d'exploitation, c'est certain que ça nous intéresse!
bloguelinux.ca est enregistré le jeudi à 20 heures toutes les deux semaines.
Vous pouvez nous écouter en direct lors des enregistrements à l'adresse http://live.bloguelinux.ca ou directement sur notre site à http://www.bloguelinux.ca en cliquant sur la radio dans le panneau de gauche du site.

[FR Montpellier] Les logiciels libres, parlons-en ! - Le vendredi 14 juillet 2017 de 17h00 à 19h00.

Le Faubourg Marché, qu’est-ce que c’est ?

Le Faubourg Marché est une permanence partagée qui permet aux associations d’accueillir ensemble, les publics de ces associations une fois par semaine, le vendredi entre 17h00 et 19h00, au 19, rue du Faubourg de Nîmes, 34000 Montpellier.

L’idée est de s’informer et d’informer les adhérents des diverses associations sur le fonctionnement du lieu et des associations, et notamment sur les 5 partenaires qui l’animent et lui permettent ainsi d’exister (autour.com, L’Accorderie, enercoop, modulauto, La Nef). Lors de cette permanence partagée vous pourrez rencontrer les associations La Graine (monnaie locale de Montpellier), éCOhabitons, Montpellier à pied, et bien sûr Montpel’libre.

Alors, si vous avez un peu de temps le vendredi soir, voici une occupation qui me semble très intéressante.
Montpel’libre est une association et un groupe d’utilisateurs (GULL), qui propose une multitude d’activités dans le cadre de la promotion des logiciels libres, et des Communs.
Depuis longtemps déjà, Montpel’libre participe à l’économie sociale et solidaire en organisant tout un éventail d’ateliers et de manifestations, au développement durable et à l’innovation sociale au travers de permanences et ateliers de présentations des logiciels libres et évidement les cartoparties, véritable actions citoyennes, sur le thème de l’accessibilité des personnes en situation de handicap.
L’activité économique, l’intérêt collectif, le fonctionnement démocratique, autant d’éléments que porte Montpel’libre, en proposant un accès entièrement libre et gratuit à une éducation populaire, au travers de ses ateliers à destination de tous les publics.

Les logiciels libres parlons-en ! Ouvrons le dialogue sur l’ouverture des données ! Partageons nos expériences pour une meilleure répartition des connaissances.

Ces permanences sont suivies d’un Apéro « refaire le monde » convivial et partagé, de 18h30 à 21h30. Elles ont lieu au Faubourg marché, tous les vendredis de 17h00 à 19h00 :

  • vendredi 7 juillet 2017 de 17h00 à 19h00
  • vendredi 21 juillet 2017 de 17h00 à 19h00
  • vendredi 28 juillet 2017 de 17h00 à 19h00

Entrée libre et gratuite sur inscription. Une simple adhésion à l’association est possible.

Cet événement est proposé dans le cadre du partenariat qui lie le Faubourg Marché et Montpel’libre.

Vendredis 7, 21 et 28 juillet 2017 de 17h00 à 19h00
Le Faubourg - 15, rue du Faubourg de Nîmes, 34000 Montpellier

Tramway lignes 1, 2 et 4 arrêt Corum
GPS Latitude : 43.614186 | Longitude : 3.881404
Carte OpenStreetMap

[FR Valenciennes] Permanence ValLibre - Le samedi 15 juillet 2017 de 09h30 à 12h00.

Permanence assistance informatique.

Dépannage petits bobos informatiques.

Initiation à l'informatique libre.

Tous les samedis ouvrables sauf les derniers samedis du mois et les samedis en période de vacances scolaires.

Si besoin particulier, la prise de rendez-vous est fortement conseillée.

Téléphone accueil MQCV : 03 27 22 43 90

[FR La Couronne] Permanence - accueil public - Le samedi 15 juillet 2017 de 10h00 à 13h00.

Notre permanence d'accueil avec le sourire, le café et les gâteaux !

Lieu de rencontre et d'échange convivial pour discuter informatique et outils numériques.

Cette association permet à chacun de découvrir également l'univers de Linux et par extension de tous les **logiciels* et matériels libres*.

Entrée Libre. Tout Public.

[FR Nanterre] Lightning talks de l'Electrolab - Le samedi 15 juillet 2017 de 16h00 à 18h00.

Les Lightning-Talks consistent en de courtes présentation (5 mn max + 3 mn de questions) de projets terminés, en cours, ou toujours en réflexion.

Toutes les personnes qui sont prêtes à partager leurs idées les plus folles devant une foule en délire sont invitées

Vous bénéficierez de retours des membres sur vos choix techniques et probablement de conseils bienvenus.

Télécharger ce contenu au format Epub

Lire les commentaires

PyCon-fr du 21 au 24 septembre 2017 à Toulouse : appel à contributions

7 juillet, 2017 - 14:02

La PyCon-fr 2017 se déroulera cette année du 21 au 24 septembre à Toulouse !

Depuis 2007, l’Association Francophone Python (AFPy) organise une rencontre annuelle des utilisateurs francophones du langage Python sur quelques jours pour échanger autour de leurs expériences, apprendre les uns des autres et se présenter leurs dernières trouvailles au cours d’ateliers, de conférences et de rencontres.

La PyCon-fr est le meilleur moyen de découvrir le langage Python, d’aller plus loin dans son utilisation, de rencontrer les auteurs de bibliothèques que vous utilisez peut‐être tous les jours… et tout simplement de se retrouver le temps d’un week‐end.

Cette année, la PyCon-fr pose ses valises à Toulouse, dans les locaux de l’ENSEEIHT, du 21 au 24 septembre 2017.

La PyCon-fr, c’est 400 visiteurs en moyenne chaque jour, et pas moins de 70 conférences et ateliers :

  • les conférences, de tous niveaux, permettent de découvrir différents usages de Python ;
  • les sprints (ateliers auto‐organisés de programmation) permettent de faire avancer des projets libres et open source.

Les sprints auront lieu les jeudi 21 et vendredi 22. Les conférences et ateliers se dérouleront samedi 23 et dimanche 24. À titre d’exemple, l’an dernier, les associations Bibliothèque sans‐frontières et l’OCA ont pu bénéficier de l’aide de codeurs débutants et chevronnés.

Vous avez une expérience autour de Python à partager ? Vous souhaitez présenter votre dernier projet à la communauté ? Demander de l’aide et/ou exposer vos doutes ? C’est le bon moment : l’appel à oratrices et orateurs est dès à présent ouvert, et ce, jusqu’au 31 juillet ! Que vous soyez une utilisatrice chevronnée ou simplement à la découverte de Python, n’hésitez pas à proposer un sujet : PyCon-fr, c’est avant tout vous. :)

Au niveau du format, nous acceptons des présentations longues (50 min) et courtes (20 min) et des ateliers (à vous de nous préciser leur durée en fonction du besoin).

Voici quelques suggestions de thèmes issus des éditions précédentes :

  • Python dans l’éducation : trucs et astuces pour débuter ou enseigner avec Python ;
  • Internet, le Web, la montée en charge et Python ;
  • la crypto : chiffrement et vie privée ;
  • Python scientifique : calcul scientifique et statistique, machine learning ;
  • au cœur de Python : empaquetage, bibliothèques, tests, profilage, liaison (binding) ;
  • autour de Python : approvisionnement, bases de données, cadriciel JavaScript ;
  • Python dans le réel : fabrication numérique (impression 3D, CNC, IoT…) ;
  • Python dans le futur : PyPy, Python 3 et asyncio ;
  • le Libre avec Python : vos créations ;
  • et aussi, mais surtout, toutes les propositions ne rentrant pas dans ces cases ;).

Parce que vous avez maintenant probablement plein d’idées, vous pouvez utiliser le troisième lien en haut de la dépêche pour proposer votre conférence. Attention, la date limite est fixée au 31 juillet !

Vous pouvez également soutenir la PyCon-fr en devenant sponsor ou en étant volontaire pour aider. À cet effet, une rencontre aura lieu le mardi 11 juillet 2017 au Black Lion pub pour discuter de tout ça.

Télécharger ce contenu au format Epub

Lire les commentaires

Bienvenue à la troisième portée de chatons

7 juillet, 2017 - 12:25

Le Collectif des hébergeurs alternatifs, transparents, ouverts, neutres et solidaires est heureux d’annoncer ce 7 juillet 2017 que la troisième portée a donné naissance à neuf nouveaux Chatons.

Cette portée est très hétéroclite, que ce soit dans la forme des chatons (cela va du père de famille au service commercial) et dans le choix des services proposés.

Galilée (Éclaireuses Éclaireurs de France)

La commission communication interrégionale des Éclaireuses Éclaireurs de France (« scouts laïcs ») « éclés » de Bretagne, Rhône‐Alpes, Provence et Midi‐Pyrénées, propose le serveur Galilée qui permet aux adhérent·e·s d’utiliser des services basés sur des logiciels libres et respectueux des utilisateurs. Les services proposés concernent essentiellement le courriel (boîtes, listes et annuaire) et des outils collaboratifs (wiki, pad, partage de fichiers, etc.).

Tila.im

Tila.im est un simple serveur qu’un utilisateur met à la disposition de ses connaissances. Il s’agit d’un projet plutôt personnel, mais qui a bien compris l’idée de s’approprier les services plutôt que de les sous‐traiter à des sociétés centralisatrices.

Outils‐Conviviaux

Outils‐Conviviaux est un jeune hébergeur associatif qui s’inscrit dans une démarche d’appropriation des technologies qui ne devraient pas être abstraites et gérées par des experts lointains mais proches et personnelles.

Le Retzien libre

Le Retzien libre est une association qui est dans la démarche à laquelle se comparent souvent les Chatons, celle d’une « AMAP informatique ». L’association se propose de fournir des services (messagerie, agenda, sondage, stockage) aux habitants du pays de Retz, avec une vraie envie de faire vivre un usage numérique local.

3hg

Le collectif 3hg est un groupe de Libristes qui ont envie de produire des technologies ensemble sans entrer dans des collectifs existants (si ce n’est celui des Chatons, qui est plus un label qu’un directeur technique). Pour le moment, il fournit des services chiffrés (courriel, pastebin, clavardage) et un accès via un service caché Tor à l’ensemble des services.

Boblecodeur

Boblecodeur est une association qui a pour but de proposer des services informatiques libres et ouverts à tous afin d’aider les professionnels et particuliers dans leur développement informatique et Internet. Il s’agit d’un des rares Chatons ayant une activité commerciale et qui tente de trouver un modèle économique dans le service Internet compatible avec les valeurs des Chatons.

Picasoft

Picasoft est une association étudiante de l’Université de technologie de Compiègne qui a une activité libriste consistant à fournir des service gratuits (outils et hébergement) à tous les publics (grand public, administrations et entreprises privées) et à sensibiliser et former les utilisateurs aux enjeux associés.

pbr18

pbr18 est un très sympathique projet qu’un père de famille a lancé avec son fils de 14 ans pour monter une infrastructure technique basée sur du logiciel libre capable de proposer un hébergement de sites Web. Le Chaton est toujours en cours de gestation, mais la candidature a emballé le collectif. Il prévoit déjà trois formules de service selon les compétences techniques des utilisateurs.

Vincent‐Xavier Jumel

Vincent‐Xavier est un particulier auto‐hébergé qui se propose de partager son infrastructure avec sa famille et quelques collègues.

Télécharger ce contenu au format Epub

Lire les commentaires

Nix pour les développeurs

6 juillet, 2017 - 11:32

Nix est un gestionnaire de paquets « fonctionnel » (basé sur des fonctions, sans effet de bord). Cette caractéristique apporte des avantages indéniables, notamment de pouvoir mettre en place des environnements logiciels isolés, reproductibles et composables. Ceci peut être très utile à un administrateur système mais également à un développeur.

On trouve pas mal d’informations sur l’écosystème Nix et son utilisation, ainsi que des retours d’expérience des utilisateurs. En revanche, les documents à destination des développeurs sont moins nombreux et se limitent souvent à l’utilisation ou à la mise en place d’environnements de développement simples.

Cet article a pour objectif d’illustrer l’intérêt de Nix pour un développeur dans des cas simples et « un peu moins simples ». Pour cela, il se base sur un projet d’exemple en C++ et en Python, mais Nix peut également être utilisé pour d’autres langages. Je ne suis pas un expert en Nix, donc n’hésitez pas à proposer vos remarques ou améliorations dans les commentaires ou sur le dépôt GitHub du projet d’exemple.

Sommaire Introduction Exemple 1 : créer un environnement de développement de test Scénario

Vous avez codé un script Python myscript.py et vous voulez le tester dans un environnement vierge.

# myscript.py import numpy x = numpy.ndarray(42, int) x[0::2] = 13 x[1::2] = 37 print(x) Avec les outils classiques (Python, virtualenv, pip) virtualenv -p /usr/bin/python3 --no-site-packages ~/myvenv source ~/myvenv/bin/activate pip install numpy python myscript.py deactivate rm -rf ~/myvenv Avec Nix nix-shell --pure -p python35Packages.numpy --run "python myscript.py" Exemple 2 : reproduire un environnement de développement Scénario

Vous développez un logiciel myprog en C++, compilé avec Cmake et utilisant la bibliothèque Boost. Vous avez récupéré votre projet sur une nouvelle machine et voulez le compiler.

Avec les outils classiques (par exemple sous Arch Linux) sudo pacman -S gcc cmake boost mkdir build cd build cmake .. make Avec Nix

Au cours du projet, un fichier default.nix est tenu à jour (il indique notamment les dépendances à Cmake et à Boost). Il suffit alors de lancer la commande :

nix-build Exemple 3 : empaqueter un projet Scénario

Le projet myprog de l’exemple précédent vient d’aboutir à une version 0.1 dont le code source est disponible en ligne. Vous voulez l’installer proprement sur votre système.

Avec les outils classiques (par exemple sous Arch Linux) sudo pacman -S base-devel mkdir myprog cd myprog # Écrire un fichier PKGBUILD (avec l’adresse URL de la publication, les dépendances, les instructions de compilation, etc.). makepkg sudo pacman -U myprog-0.1-1-any.pkg.tar.xz

Cette solution fonctionne pour Arch Linux uniquement. Si vous voulez une solution pour Debian ou Fedora, il faut créer les paquets Deb ou RPM correspondants.

Avec Nix cp default.nix release.nix # dans le fichier release.nix, changer la valeur de la variable src par l’URL de la publication nix-env -f release.nix -i myprog

Ici, la solution devrait fonctionner automatiquement pour tout système compatible avec Nix (Arch Linux, Debian, Fedora…).

Exemple 4 : personnaliser des dépendances Scénario

Vous développez des logiciels de traitement d’images utilisant la bibliothèque OpenCV. Pour cela, vous utilisez le paquet OpenCV fourni par la logithèque système. Un de vos logiciels doit utiliser GTK ; malheureusement, le paquet OpenCV a été compilé avec l’option -DWITH_GTK=OFF.

Avec les outils classiques

Bienvenue en enfer… Quelques « solutions » classiques :

  • recompiler OpenCV à partir du code source ; vous pourrez ensuite faire une installation système (mais cela peut impacter les autres logiciels) ou une installation locale (mais il faudra configurer les chemins vers votre OpenCV personnalisé quand vous en aurez besoin) ;
  • utiliser un système d’environnement virtualisé (chroot, Flatpak, Docker…). Pour cela, vous devrez mettre en place le système, puis récupérer une image d’OpenCV compilé avec les bonnes options ou créer votre propre image.
Avec Nix

Les paquets Nix sont paramétrables. Ainsi pour activer l’option GTK 2 du paquet OpenCV, il suffit (presque) d’ajouter la ligne suivante dans le fichier default.nix. La recompilation et la gestion des différentes versions est automatique.

opencv3gtk = pkgs.opencv3.override { enableGtk2 = true; }; Quelques rappels sur Nix Présentation

Nix est un gestionnaire de paquets fonctionnel. Le terme « fonctionnel » est à prendre au sens mathématique : une fonction prend des entrées et produit une sortie, sans réaliser d’effets de bord. Ceci permet de créer des environnements logiciels (compilation, installation et configuration) avec les avantages suivants :

  • les environnements sont reproductibles ;
  • ils sont paramétrables et composables ;
  • ils n’ont jamais besoin d’être dupliqués ;
  • ils sont exécutés nativement.

L’écosystème Nix comporte différents éléments :

  • un langage permettant de décrire un environnement logiciel (appelé nix-expression) ;
  • des outils (nix-build, nix-env, nix-shell…) permettant de construire, installer, exécuter, etc., des nix-expressions ;
  • un dépôt officiel (nixpkgs) de nix-expressions…

Il existe une distribution GNU/Linux (NixOS) directement basée sur ces éléments, mais le système Nix peut être installé sur un système d’exploitation quelconque (GNU/Linux, BSD, macOS) pour y servir de logithèque et de système d’environnement virtuel.

Enfin, Nix a inspiré un système concurrent, nommé GNU Guix. Tout comme Nix, Guix peut être utilisé sur un système d’exploitation classique ou via une distribution dédiée, GuixSD. À la différence de Nix, Guix est basé sur un langage existant (Guile Scheme) et accorde une plus grande importance à l’aspect « logiciel libre ».

Quelques commandes Nix
  • voir les paquets installés :
nix-env -q
  • voir les paquets disponibles contenant le motif "firefox" :
nix-env -qa 'firefox'
  • installer le paquet firefox :
nix-env -i firefox
  • désinstaller le paquet firefox :
nix-env -e firefox

Toutes ces commandes sont utilisables avec les droits utilisateurs et dans l’environnement de l’utilisateur. Les paquets sont gérés par un service (nix-daemon) qui les installe dans un répertoire commun /nix/store et les rend disponibles aux différents utilisateurs.

Projet d’exemple (C++/Python)

Pour illustrer l’utilisation de Nix, on considère un projet type (the_checkerboard_project) qui calcule et affiche des images de damier.

Ce projet est composé d’une bibliothèque C++ (checkerboard) et d’une interface Python (pycheckerboard) contenant la liaison proprement dite et un script Python additionnel.

the_checkerboard_project/ ├── checkerboard │ ├── CMakeLists.txt │ ├── checkerboard.cpp │ ├── checkerboard.hpp │ └── test_checkerboard.cpp └── pycheckerboard ├── setup.py └── src ├── checkerboard │ └── binding.cpp └── pycheckerboard ├── __init__.py └── test1.py

Les fonctions pour calculer un damier et pour afficher une image, en utilisant la bibliothèque OpenCV. La compilation est réalisée via Cmake, qui fait le lien avec OpenCV et qui construit la bibliothèque checkerboard et un exécutable de test.

# checkerboard/CMakeLists.txt cmake_minimum_required( VERSION 3.0 ) project( checkerboard ) # lien avec OpenCV find_package( PkgConfig REQUIRED ) pkg_check_modules( MYPKG REQUIRED opencv ) include_directories( ${MYPKG_INCLUDE_DIRS} ) # bibliothèque checkerboard add_library( checkerboard SHARED checkerboard.cpp ) target_link_libraries( checkerboard ${MYPKG_LIBRARIES} ) install( TARGETS checkerboard DESTINATION lib ) install( FILES checkerboard.hpp DESTINATION "include" ) # exécutable de test add_executable( test_checkerboard test_checkerboard.cpp ) target_link_libraries( test_checkerboard checkerboard ${MYPKG_LIBRARIES} ) install( TARGETS test_checkerboard DESTINATION bin )

L’interface Python est faite avec Boost Python. La liaison (binding.cpp) expose simplement les deux fonctions de la bibliothèque checkerboard. Un script additionnel (test1.py) fournit une fonction et un programme de test. Le tout est compilé dans un paquet Python en utilisant un script setuptools/pip très classique.

# pycheckerboard/setup.py from setuptools import setup, Extension checkerboard_module = Extension('checkerboard_binding', sources = ['src/checkerboard/binding.cpp'], libraries = ['checkerboard', 'boost_python', 'opencv_core', 'opencv_highgui']) setup(name = 'pycheckerboard', version = '0.1', package_dir = {'': 'src'}, packages = ['pycheckerboard'], python_requires = '<3', ext_modules = [checkerboard_module]) Configuration Nix basique

Classiquement (sans Nix), on exécuterait les commandes suivantes pour compiler et installer la bibliothèque checkerboard :

mkdir checkerboard/build cd checkerboard/build cmake .. make sudo make install

Nix permet d’exécuter ces commandes automatiquement. Pour cela, il suffit d’écrire un fichier de configuration default.nix indiquant le nom du paquet, le chemin vers le code source et les dépendances (voir cette dépêche sur l’anatomie d’une dérivation Nix).

# checkerboard/default.nix with import <nixpkgs> {}; with pkgs; stdenv.mkDerivation { name = "checkerboard"; src = ./.; buildInputs = [ cmake pkgconfig opencv3 ]; }

Les dépendances spécifiées ici seront installées automatiquement par Nix, si besoin. Ici la dépendance à Cmake implique que la compilation sera réalisée avec Cmake (cf. les commandes précédentes). La compilation et l‘installation de la bibliothèque checkerboard peuvent alors être lancées avec la commande :

nix-env -f . -i checkerboard

La bibliothèque ainsi que l’exécutable de test sont alors disponibles dans les chemins système, ou plus exactement dans les chemins système vus par l’utilisateur. Cependant, il n’est pas obligatoire d’installer le paquet checkerboard. On peut simplement lancer un shell dans un environnement virtuel contenant le paquet :

nix-shell

Ce mécanisme de shell virtuel propose des fonctionnalités très utiles. Par exemple, partir d’un environnement vierge et exécuter juste une commande dans cet environnement :

nix-shell --pure --run test_checkerboard Configuration Nix modulaire

Au lieu de proposer un paquet complet, on peut découper notre nix-expression (default.nix) en plusieurs modules, appelés dérivations, qui pourront alors être réutilisés ou reparamétrés. Par exemple, pour créer une dérivation opencv3gtk et une dérivation checkerboard :

# checkerboard/default.nix { system ? builtins.currentSystem }: let pkgs = import <nixpkgs> { inherit system; }; in with pkgs; stdenv.mkDerivation rec { opencv3gtk = import ./opencv3gtk.nix { inherit (pkgs) opencv3; }; checkerboard = import ./checkerboard.nix { inherit opencv3gtk; inherit (pkgs) cmake pkgconfig stdenv; }; }

Ces deux dérivations sont implémentées dans des fichiers spécifiques, pour faciliter leur réutilisation. Par exemple, pour checkerboard :

# checkerboard/checkerboard.nix { cmake, opencv3gtk, pkgconfig, stdenv }: stdenv.mkDerivation { name = "checkerboard"; src = ./.; buildInputs = [ cmake opencv3gtk pkgconfig ]; }

Ici, la deuxième ligne indique les paramètres du paquet (c’est‐à‐dire les dépendances à utiliser pour Cmake, pkgconfig, etc.). Ce mécanisme permet de composer les paquets de façon très puissante. Par exemple, on peut reparamétrer le paquet OpenCV en activant la prise en charge de GTK (qui n’est pas activée par défaut) et composer ce nouveau paquet à notre paquet checkerboard, qui disposera alors des fonctionnalités GTK. On peut même modifier finement les options de compilation du paquet OpenCV (par exemple, désactiver les en‐têtes pré‐compilés qui consomment beaucoup de mémoire vive) :

# checkerboard/opencv3gtk.nix { opencv3 }: let opencv3gtk = opencv3.override { enableGtk2 = true; }; in opencv3gtk.overrideDerivation ( attrs: { cmakeFlags = [attrs.cmakeFlags "-DENABLE_PRECOMPILED_HEADERS=OFF"]; } )

Bien entendu, reparamétrer un paquet nécessite une recompilation si le paquet n’a pas déjà été compilé pour ce jeu de paramètres.

Notez que le nouveau default.nix ne contient pas de dérivation par défaut. Il faut donc préciser la dérivation à utiliser ou à installer :

nix-shell -A checkerboard nix-env -f . -iA checkerboard Configuration Nix pour un paquet Python

De nombreux langages proposent leur propre système de gestion de paquets (pip pour Python, gem pour Ruby, npm pour JavaScript, etc.). Nix fournit des fonctionnalités pour créer ce genre de paquets.

Par exemple, pour créer un paquet Python de notre projet, on peut écrire un fichier default.nix, qui va réutiliser les dérivations opencv3gtk et checkerboard précédentes. Nix fournit une fonction buildPythonPackage qui permet de créer simplement un paquet Python en utilisant le script setuptools/pip :

# pycheckerboard/default.nix { system ? builtins.currentSystem }: let pkgs = import <nixpkgs> { inherit system; }; opencv3gtk = import ../checkerboard/opencv3gtk.nix { inherit (pkgs) opencv3; }; checkerboard = import ../checkerboard/checkerboard.nix { inherit opencv3gtk; inherit (pkgs) cmake pkgconfig stdenv; }; in with pkgs; pythonPackages.buildPythonPackage { name = "pycheckerboard"; src = ./.; buildInputs = [ checkerboard python27Packages.boost opencv3gtk ]; }

Comme pour la bibliothèque, on peut alors installer la dérivation ou la tester interactivement dans un shell virtuel. Les dépendances opencv3gtk et checkerboard correspondent aux dérivations de la section précédente et ne seront pas recompilées ni dupliquées.

$ cd pycheckerboard $ nix-shell --pure --run python Obtaining file:///home/nokomprendo/the_checkerboard_project/pycheckerboard Installing collected packages: pycheckerboard ... Python 2.7.13 (default, Dec 17 2016, 20:05:07) >>> import pycheckerboard.test1 as pt >>> pt.test1() running test1.py... Conclusion

Nix permet de définir des environnements logiciels reproductibles, paramétrables et composables. Il suffit d’écrire quelques fichiers .nix qui viennent compléter les outils de compilation classiques du projet. Les paquets ainsi créés peuvent ensuite être installés ou exécutés, éventuellement dans un environnement isolé. Nix gère automatiquement la compilation, les dépendances et les différentes versions de paquets. Ces fonctionnalités sont intéressantes pour un développeur, car elles permettent non seulement de simplifier le déploiement, mais également d’offrir un environnement de développement multi‐langage léger et reproductible.

Télécharger ce contenu au format Epub

Lire les commentaires

Qui est le coupable ? Le processeur ! Retour sur un bogue important des SkyLake & Kaby Lake Intel

6 juillet, 2017 - 11:29

Certains d’entre vous ont peut‐être vu passer l’information : les derniers processeurs Intel des familles Skylake et Kaby Lake sont victimes d’un bogue lorsque l’hyper‐threading est activé. On trouve par exemple un article sur Ars Technica, et Debian propose des instructions détaillées pour corriger le problème en mettant à jour le microcode (firmware) du processeur.

Cette dépêche propose revenir sur les événements qui ont mené à la découverte du problème. Xavier Leroy le décrit en détail dans un article sur le blog de l’équipe Gallium, dont je proposerai un résumé pour les lecteurs francophones.

Tout commence en avril 2016 lorsqu’un SIOU (Serious Industrial OCaml User), comme il les appelle, le contacte en privé pour lui signaler un bogue dans un de leur logiciel : ce dernier subit des erreurs de segmentation de manière aléatoire après un certain temps. Il n’arrive pas à reproduire le bogue sur sa propre machine et le côté aléatoire du bogue lui fait soupçonner un problème matériel chez le client (mémoire vive défectueuse, surchauffe…). Il leur propose de tester leur mémoire et de désactiver l’hyper‐threading. La mémoire était bonne, mais il ne teste pas la désactivation (ce qui aurait résolu le problème).

De son côté, le client fait ses tests et aboutit aux résultats suivants : le bogue est présent avec la version 4.03 mais pas la 4.02.3 du compilateur OCaml, avec GCC mais pas Clang (l’environnement d’exécution d’OCaml est en C), sur GNU/Linux et Windows mais pas macOS (ce qui se comprend, ce dernier utilisant Clang). Les coupables semblent identifiés : OCaml 4.03 et GCC, et le client suppose qu’il y a une erreur dans le code C de l’environnement d’exécution d’OCaml.

Début mai 2016, le client offre un accès à sa machine à Xavier Leroy pour qu’il puisse identifier le problème. Il analyse des vidages mémoire (dumps) post‐plantage, voit bien des problèmes avec le ramasse‐miettes, mais ne comprend pas ce qui peut causer un tel comportement dans son code. Il fait alors des tests en lançant le programme en parallèle (1, 2, 4, 8 ou 16 instances) et, là, tout devient clair : pas de bogue quand l’hyper‐threading n’est pas utilisé. Ils font des tests en le désactivant dans le BIOS et le problème ne se manifeste plus.

Cela aurait pu en rester là : le client était satisfait de pouvoir utiliser une version de l’environnement d’exécution avec Clang, et Xavier Leroy ne sachant pas comment signaler le problème à Intel en reste là. Mais, début 2017, un autre SIOU fait un rapport de bogue sur le système de suivi d’OCaml. Les symptômes étaient similaires et la discussion sur le ticket fut la suivante :

  • douze heures après l’ouverture, une des ingénieurs précise que tous les ordinateurs qui ont pu reproduire le bogue ont un processeur de la famille Skylake ;
  • le lendemain, Xavier Leroy signale son expérience passée et propose de désactiver l’hyper‐threading ;
  • le jour suivant, un autre ingénieur du SIOU rapporte qu’en désactivant l’hyper‐threading le problème disparaît ;
  • en parallèle, il constate que si l’environnement d’exécution est compilé avec gcc -O1 et non gcc -O2 alors le bogue disparaît. Ce qui permet de comprendre pourquoi cela apparaît avec la version 4.03, qui est celle inaugurant l’option -O2 par défaut pour l’environnement d’exécution ;
  • Mark Shinwell contacte des collègues chez Intel et s’occupe de rapporter le problème au support client d’Intel.

Enfin, cinq mois plus tard, Debian publie une mise à jour du microcode des processeurs Intel et Intel publie, en avril, une mise à jour des spécifications de la 6e génération de ses processeurs. On trouve à la page 65 de ce document une mention du problème SKL150 qui était à l’origine de tous ces bogues, présenté en ces termes chez Debian :

SKL150 - Short loops using both the AH/BH/CH/DH registers and
the corresponding wide register may result in unpredictable
system behavior. Requires both logical processors of the same
core (i.e. sibling hyperthreads) to be active to trigger, as
well as a “complex set of micro‐architectural conditions”.

Pour ceux que cela intéresse et qui comprennent l’assembleur (ce qui n’est pas mon cas), le problème venait de ce bout de code du ramasse‐miettes d’OCaml :

hd = Hd_hp (hp); /*...*/ Hd_hp (hp) = Whitehd_hd (hd);

Qui après expansion des macros donne :

hd = *hp; /*...*/ *hp = hd & ~0x300;

Avec Clang, cela donnait :

movq (%rbx), %rax [...] andq $-769, %rax # imm = 0xFFFFFFFFFFFFFCFF movq %rax, (%rbx)

Tandis que le code optimisé de GCC donnait :

movq (%rdi), %rax [...] andb $252, %ah movq %rax, (%rdi)

Qui pouvait lever le bogue du processeur s’il se trouvait dans une petite boucle ?

Ce bogue sur ces processeurs impacte tous les systèmes d’exploitation. Le correctif du microcode pour la génération Skylake existe donc depuis avril, car Intel distribue ses mises à jour à toutes et tous, permettant aux mainteneurs des distributions de réaliser l’empaquetage afin de les rendre disponibles.

Cependant, il n’en va pas de même pour la génération Kaby Lake, pour laquelle Intel ne distribue ses correctifs de microcodes qu’aux seuls constructeurs ou assembleurs. Il résulte de cette situation une grande disparité des disponibilités pour cette mise à jour : certains constructeurs l’ont déjà proposée, d’autres ne le font pas.

Au final, il semblerait que Skylake se soit transformé en Skyfall et que la légendaire crainte gauloise que le ciel leur tombe sur la tête était fondée ! :-D

Télécharger ce contenu au format Epub

Lire les commentaires

La bière libre, ColiBibine, est de retour pour les RMLL !

5 juillet, 2017 - 13:57

La bière libre des étudiants de la licence CoLibre de l’Université Lyon 2 est de retour à l’occasion des Rencontres mondiales du logiciel libre 2017 (RMLL) à Saint‐Étienne.

Projet brassé et porté par l’association des étudiants du diplôme, la nouvelle CoLiBibine « tout grain » garde les mêmes principes à savoir :

  • approfondir la culture des logiciels libres et leurs quatre libertés fondamentales : exécuter, étudier, modifier, diffuser ;
  • permettre aux étudiants à apprendre à construire et porter un projet ;
  • soutenir les initiatives étudiantes ;
  • faire quelque chose de sympa et ensuite en faire profiter les autres (et non, non, nous n’allons pas tout boire !).

Soutenue par l’ALDIL, cette campagne permettra de financer les projets des étudiants de la licence Colibre en vous donnant l’occasion de goûter à leur bière libre !

Une première distribution a lieu aux RMLL dans le village associatif sur le stand CoLibre. D’autres points de retrait « Retire ta bière » sont à disposition sur Lyon afin de pouvoir récupérer sa CoLiBibine après les RMLL.

Les ingrédients de la CoLibibine « tout grain » ?
  • malt (cara blond 20ebc & cara ruby 50ebc), houblon pacific jade, extrait de malt (pale & ambré), levure, eau, sucre, jus de créativité, passion, bonne humeur, beaucoup d’amour, joie, quelques plumes de colibris, et puis c’est tout… (Forkez notre recette)
  • et votre participation à ce projet permettant de soutenir et de développer l’association CoLibreAsso.
Prochain brassage : la cuvée spéciale RMLL 2017 : bière camp

Nous avons prévu de brasser une nouvelle cuvée, à la rentrée. Vous aurez l’occasion donc de pouvoir choisir ses ingrédients pour créer la cuvée RMLL 2017. Vous serez prochainement invités à participer à notre bière Camp via notre sondage.

Alors, à vos décapsuleurs !

NdM : l’abus d’alcool est dangereux pour la santé. À consommer avec modération (et avec la modération aussi si possible).

Télécharger ce contenu au format Epub

Lire les commentaires

Multiseat avec des pilotes libres, non libres et systemd

5 juillet, 2017 - 13:17

Ou comment avoir deux utilisateurs simultanés sur un seul PC, avec deux écrans, deux clavier, deux souris et deux cartes graphiques (et deux chaises !), facilement et pour pas cher.

    Sommaire

    J’ai deux cartes graphiques : une NVIDIA GTX 750 Ti et une Radeon FirePro V3700. Problème : je veux utiliser les pilotes non libres NVIDIA (pour des meilleures performances). C‘était impossible jusqu’à la sortie (et mise à jour) de Fedora 25.
    Cette nouvelle version utilise la fonctionnalité GLVND qui permet de faire cohabiter deux pilotes OpenGL. Mes deux cartes graphiques peuvent désormais cohabiter sans avoir à utiliser uniquement les pilotes Mesa 3D (nouveau et radeon) pour les deux processeurs graphiques.

    Prérequis

    Au fil de vos essais, vous vous retrouverez peut‐être avec un système incapable de lancer une session graphique, ou même l’accès à la console sera impossible (peu probable). Je vous conseille d’installer un accès à distance SSH avant de vous lancer. Testez‐le avant et, si vous n’avez pas de deuxième ordinateur, des clients SSH sont disponibles pour les appareils mobiles sous Android et iOS.

    Fedora 25 utilise systemd comme système d’initialisation et implémente logind. Ce composant permet de gérer les sessions, les utilisateur connectés et les sièges (seat). Pour configurer plusieurs « sièges » sur un seul système, on peut utiliser logind qui automatise tout au lieu d’avoir à éditer à la main un fichier Xorg.conf !
    J’ai un système multi‐seat fonctionnel sous Fedora 25, cependant Debian 9 Stretch est peut‐être compilé avec GLVND. Si vous avez deux cartes graphiques identiques, vous pouvez utiliser n’importe quelles distributions pour peu qu’elle fonctionne avec systemd.

    Matériel requis

    Vous pouvez utiliser n’importe quel périphérique USB ou PS/2, mais essayez d’avoir une configuration logique (brancher l’écran avec la plus grande définition sur la carte graphique la plus puissante si vous souhaitez faire du jeu vidéo).
    Pour une expérience optimale, il est préférable d’avoir une carte son par utilisateur (et un ou deux casques audio pour éviter la cacophonie), sinon il est possible de configurer pulseaudio pour deux utilisateurs (non testé). Vous pouvez utiliser les sorties son HDMI de votre écran, ce, même si cet écran est utilisé pour un autre poste.
    Il est conseillé d’utiliser des périphériques USB de marques et modèles différents, comme ça leurs identificateurs USB seront différents (apparemment les périphériques USB ont tendance à s’échanger leur place).

    Configuration

    C’est très facile, mais après, bonne chance pour vous y retrouver avec tous les câbles ! Je vous conseille aussi de brancher les écrans aux cartes graphiques dès le début.

    Logiciels

    Tout d’abord, trouvez quel gestionnaire de sessions (desktop manager) vous utilisez (c’est ce qui crée l’écran de connexion). Si c’est GDM (pour GNOME), SDDM (pour Plasma 5), il va falloir changer, car ceux‐ci n’afficheront un écran de connexion que sur le premier siège. Je conseille LightDM, bien que XDM soit compatible multi‐seat :

    • installez LightDM : # dnf install lightdm ;
    • installez le thème de votre choix (greeter) : # dnf install slick-greeter (ou lightdm-gtk, lightdm-kde…) ;
    • désinstallez votre gestionnaire de sessions : # dnf remove gdm ;
    • redémarrez ou passez en console (Ctrl + Alt + F2) et relancez les services : # systemctl stop gdm, puis # systemclt start lightdm.
    Matériel Identifiez

    Ensuite, listez votre matériel, qui est par défaut entièrement alloué au siège initial seat0 : loginctl seat-status. Exemple (je liste deux sièges, car j’ai déjà assigné mon matériel ; si vous commencez vous n'aurez que seat0) :

    $ loginctl seat-status seat0 seat1--no-pager
    seat0
    Sessions: *2
    Devices:
    ├─/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
    │ input:input2 "Power Button"
    ├─/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input8
    │ input:input8 "Video Bus"
    ├─/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
    │ input:input0 "Power Button"
    ├─/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1
    │ input:input1 "Sleep Button"
    ├─/sys/devices/pci0000:00/0000:00:02.0/drm/card0
    │ [MASTER] drm:card0
    │ ├─/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1
    │ │ [MASTER] drm:card0-HDMI-A-1
    │ └─/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-VGA-1
    │ [MASTER] drm:card0-VGA-1
    ├─/sys/devices/pci0000:00/0000:00:02.0/drm/renderD128
    │ drm:renderD128
    ├─/sys/devices/pci0000:00/0000:00:02.0/graphics/fb2
    │ [MASTER] graphics:fb2 "inteldrmfb"
    ├─/sys/devices/pci0000:00/0000:00:03.0/sound/card0
    │ sound:card0 "HDMI"
    │ ├─/sys/devices/pci0000:00/0000:00:03.0/sound/card0/input14
    │ │ input:input14 "HDA Intel HDMI HDMI/DP,pcm=3"
    │ ├─/sys/devices/pci0000:00/0000:00:03.0/sound/card0/input15
    │ │ input:input15 "HDA Intel HDMI HDMI/DP,pcm=7"
    │ ├─/sys/devices/pci0000:00/0000:00:03.0/sound/card0/input16
    │ │ input:input16 "HDA Intel HDMI HDMI/DP,pcm=8"
    │ ├─/sys/devices/pci0000:00/0000:00:03.0/sound/card0/input17
    │ │ input:input17 "HDA Intel HDMI HDMI/DP,pcm=9"
    │ └─/sys/devices/pci0000:00/0000:00:03.0/sound/card0/input18
    │ input:input18 "HDA Intel HDMI HDMI/DP,pcm=10"
    ├─/sys/devices/pci0000:00/0000:00:14.0/usb3
    │ usb:usb3
    │ ├─/sys/devices/pci0000:00/0000:00:14.0/usb3/3-3/3-3:1.0/0003:046D:C05A.0002/input/input5
    │ │ input:input5 "Logitech USB Optical Mouse"
    │ └─/sys/devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.1/0003:0603:00F2.0004/input/input7
    │ input:input7 "NOVATEK USB Keyboard"
    ├─/sys/devices/pci0000:00/0000:00:14.0/usb4
    │ usb:usb4
    ├─/sys/devices/pci0000:00/0000:00:1a.0/usb1
    │ usb:usb1
    │ └─/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1
    │ usb:1-1
    ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card1
    │ sound:card1 "PCH"
    │ ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card1/input10
    │ │ input:input10 "HDA Intel PCH Rear Mic"
    │ ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card1/input11
    │ │ input:input11 "HDA Intel PCH Line"
    │ ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card1/input12
    │ │ input:input12 "HDA Intel PCH Line Out"
    │ ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card1/input13
    │ │ input:input13 "HDA Intel PCH Front Headphone"
    │ └─/sys/devices/pci0000:00/0000:00:1b.0/sound/card1/input9
    │ input:input9 "HDA Intel PCH Front Mic"
    ├─/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/drm/card2
    │ [MASTER] drm:card2
    ├─/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/drm/renderD130
    │ drm:renderD130
    ├─/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.1/sound/card2
    │ sound:card2 "NVidia"
    │ ├─/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.1/sound/card2/input19
    │ │ input:input19 "HDA NVidia HDMI/DP,pcm=3"
    │ ├─/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.1/sound/card2/input20
    │ │ input:input20 "HDA NVidia HDMI/DP,pcm=7"
    │ ├─/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.1/sound/card2/input21
    │ │ input:input21 "HDA NVidia HDMI/DP,pcm=8"
    │ └─/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.1/sound/card2/input22
    │ input:input22 "HDA NVidia HDMI/DP,pcm=9"
    ├─/sys/devices/pci0000:00/0000:00:1d.0/usb2
    │ usb:usb2
    │ └─/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1
    │ usb:2-1
    ├─/sys/devices/platform/efi-framebuffer.0/graphics/fb0
    │ [MASTER] graphics:fb0 "EFI VGA"
    ├─/sys/devices/platform/i8042/serio0/input/input3
    │ input:input3 "AT Translated Set 2 keyboard"
    └─/sys/devices/virtual/misc/rfkill
    misc:rfkill

    seat1
    Sessions: *c1
    Devices:
    ├─/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1
    │ [MASTER] drm:card1
    │ ├─/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-DVI-I-1
    │ │ [MASTER] drm:card1-DVI-I-1
    │ └─/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-DVI-I-2
    │ [MASTER] drm:card1-DVI-I-2
    ├─/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/renderD129
    │ drm:renderD129
    ├─/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/graphics/fb1
    │ [MASTER] graphics:fb1 "radeondrmfb"
    ├─/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/0003:413C:3200.0001/input/input4
    │ input:input4 "Dell Dell USB Mouse"
    └─/sys/devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/0003:0603:00F2.0003/input/input6
    input:input6 "NOVATEK USB Keyboard"

    Il y a trois catégories qui vous intéressent : drm (carte graphique), graphics (framebuffer et écran) et input (clavier et souris). Notez ici que j’ai un iGPU Intel non utilisé, et que, faute aux pilotes NVIDIA, mon système utilise les framebuffers au lieu de l’interface moderne DRM (donc, pas de Wayland ici).
    Il vous faut donner à un siège :

    • un entrée clavier input:inputX ;
    • une entrée souris input:inputX ;
    • une carte graphique drm:cardX ;
    • un processeur graphique drm:renderXXX ;
    • un framebuffer (graphics:fbX _nom_du_pilote_).

    Pour identifier vos périphériques, référez‐vous à leur marque (Logitech USB Optical Mouse est une souris Dell par exemple…).

    Assignez

    Sélectionnez le chemin d’accès entier du périphérique (attention, ça peut dépasser de votre terminal), et collez‐le dans la commande suivante : # loginctl attach seatX chemin_du_matériel où X représente l’identifiant du siège (vous pouvez mettre 1, 2, A, B…).
    Par exemple, pour assigner mon clavier USB au siège 2, je tape
    sudo loginctl attach seat1 /sys/devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/0003:0603:00F2.0003/input/input6.
    Si certaines touches de votre clavier ne fonctionnent pas (touches multimédias ou Windows, pavé numérique…), regardez si votre clavier n’est pas listé deux fois (deux lignes input:inputX avec le même nom), et rajoutez le second input au siège concerné.

    Utilisez

    Si un écran de connexion n’est pas apparu sur le(s) nouveau(x) siège(s), redémarrez votre gestionnaire de sessions ou votre système si vous êtes flemmard.
    systemctl restart lightdm (notez que cette commande fermera instantanément toute session graphique, donc sauvegardez vos documents ouverts).

    Post‐scriptum:

    Les ressources de votre système seront partagées entre les utilisateurs, donc il est préférable d’avoir un processeur multicœur, un disque dur rapide et suffisamment de mémoire vive (les environnements de bureau seront chargés plusieurs fois…). Si votre machine dispose de peu de ressources, envisagez de passer à XFCE au lieu de GNOME ou KDE. Vous pouvez aussi mettre le /home de chaque utilisateur sur un disque différent, ou encore mettre en place un RAID logiciel ou matériel si vous avez le matériel nécessaire. Pour le réseau, comme d’habitude, votre interface sera partagée entre les utilisateurs, alors attention aux téléchargements volumineux (comme dans le cas de plusieurs ordinateurs se partageant la connexion Internet d’une box).
    Pour la vie privée, l’autre utilisateur peut probablement regarder votre écran, donc débrouillez‐vous.
    Si vous utilisez GNOME, sachez qu’il refusera de se verrouiller s’il est lancé par un autre gestionnaire de sessions que GDM. Cependant, s’il est lancé avec startx -- -seat seatX le verrouillage fonctionne, mais vous perdrez la possibilité de connecter n’importe quel utilisateur sur n’importe quel siège.

    Soyez fiers de GNU/Linux

    Les solutions pour Windows sont toutes payantes, et toutes ne permettent pas d’avoir des performances graphiques natives. Ne parlons pas de macOS/OSX, Apple serait trop triste de ne pas vous vendre une seconde machine. :)
    Je sais qu’on peut acheter des dongles USB sur lesquels on branche écran, clavier et souris, et qui affichent automatiquement sous GNU/Linux un deuxième écran de connexion ; mais ça ne permet surement pas d’avoir de l’accélération 3D si utilisée dans les navigateurs et les effets de KDE.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Sortie de Proxmox VE 5.0

    5 juillet, 2017 - 11:29

    Proxmox Server Solutions GmbH vient de publier la nouvelle version 5.0 de la plate‐forme libre de virtualisation Proxmox Virtual Environment. Parmi les principales nouvelles fonctionnalités, un gestionnaire de la réplication de stockage et un nouvel outil en ligne de commande pour importer des machines virtuelles en provenance d’autres hyperviseurs. Proxmox VE 5.0 est basée sur Debian Stretch 9.0 avec un noyau Linux 4.10.

    Réplication de stockage avec Proxmox VE

    Proxmox VE 5.0 introduit un nouveau mode de réplication de stockage, permettant de mettre à jour de façon asynchrone deux stockages locaux via le réseau, configurables depuis l’interface graphique. Cette fonctionnalité est particulièrement étudiée pour les petites structures désirant une synchronisation de leurs machines virtuelles sans avoir recours à un NAS/SAN externe.

    L’ordonnanceur de réplication est basé sur le format de calendrier de systemd, permettant de définir des intervalles de réplication très fins, au minimum d’une minute. Enfin le système de réplication permet de réduire le temps de migration d’une machine virtuelle d’un serveur à un autre, l’essentiel des données étant mises à jour en tâche de fond avant le début de la migration.

    Ceph – prêt pour la montée en charge

    Avec la version 5.0 de Proxmox VE, Ceph Rados Block Device (RBD) devient le standard de stockage distribué pour Proxmox VE. Ceph est une solution « Software‐defined », incluse dans Proxmox VE depuis 2013. En combinant Ceph et Proxmox VE, il devient possible de créer une infrastructure « hyperconvergente », où chaque nœud de la grappe de serveurs (cluster) fournit à la fois des ressources processeur pour l’hébergement de machines virtuelles, ainsi que de l’espace disque à l’ensemble de la grappe de serveurs.
    Les paquets Ceph pour Proxmox VE sont maintenant directement fournis par l’équipe de développement de Proxmox, ce qui permettra des correctifs de bogues plus rapides.

    Autres nouveautés de cette version

    Promox VE 5.0 apporte les nouveautés suivantes :

    • un outil en ligne de commande pour importer facilement des images disques provenant d’autres hyperviseurs (VMware, Hyper-V, etc.) est désormais inclus dans Proxmox VE ;
    • il est maintenant également possible de migrer des machines virtuelles même sans stockage partagé ;
    • la console virtuelle NoVNC a été mise à jour et est à présent bien mieux intégrée à l’interface graphique ;
    • enfin, il est possible de faire des actions de masse sur un groupe de conteneurs ou de machines virtuelles, et de voir directement depuis l’interface Web les périphériques affectés en mode passthrough (accès direct) aux conteneurs et machines virtuelles.
    Disponibilité

    Proxmox VE 5.0 est disponible en téléchargement. Il est possible de mettre à jour depuis les versions 4.4 et 5.0 bêta en utilisant apt-get. Proxmox VE est un produit libre distribué sous licence GNU Affero GPL v3.

    La société Proxmox Server Solution propose en outre un support Entreprise à partir de 69,90 € par processeur et par an.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Recalage d’images, PIV et corrélation d’images — Les bases théoriques

    4 juillet, 2017 - 18:18

    Le recalage d’images est utilisé dans la communauté de l’analyse d’images médicales depuis très longtemps (Barnea & Silverman, 1972, Ledbetter et al. 1979), on peut même remonter plus loin dans le temps avec les travaux de Sidney Bertram, 1963 en fournissant tous les outils via des descriptions de circuits analogiques (vraiment impressionnant pour l’époque).
    En commençant à travailler sur des images issues d’IRM, j’ai été amené à faire une bibliographie sur les outils utilisés dans l’analyse d’images médicales. J’ai constaté que leurs techniques de recalage d’images étaient très similaires à celles utilisées dans les différents domaines de la mécanique. Après beaucoup de bibliographie, je suis parvenu à situer ce qui est fait en mécanique dans les cadres proposés en analyse d’images médicales.

    Cette dépêche est l’occasion pour moi de présenter ces techniques dans le détail.

    La prochaine dépêche présentera les logiciels utilisés dans les différentes communautés scientifiques.

    Sommaire Introduction

    Dans la recherche que nous conduisons, il y a beaucoup de techniques, et la méthode qui coordonne ces techniques est tout sauf agnostique. Ce qui nous motive tous est l’extraction de la physique de nos mesures.
    Le problème qui unit l’ingénieur et le chercheur réside dans cette image du monde que nous transmettent nos mesures car elle n’est jamais exempte de biais qui peuvent jusqu’à empêcher parfois l’extraction de la moindre information physique. Les moyens permettant de diminuer les biais des observations diffèrent en général en fonction des objectifs :

    • lorsque l’on connaît précisément les phénomènes physiques en jeu, il est possible d’introduire la physique en tant que régularisation de l’identification de la transformation ; cette technique est très utilisée en mécanique des solides ;
    • lorsque l’on cherche à comprendre les mécanismes régissant les phénomènes, il est plus délicat de régulariser en se servant de la physique régissant les phénomènes, car celle‐ci n’est pas toujours connue ; de plus, la notion de matériau peut laisser place à une structure mécanique en fonction de l’échelle avec laquelle on regarde (en mécanique, la notion de structure est relative à des matériaux de type hétérogène, ou d’un ensemble de matériaux assemblés).

    Le Laboratoire de mécanique de Lille, comme beaucoup d’autres, s’intéresse particulièrement aux mécanismes, que ce soit en tribologie, turbulence de paroi ou en mécanique des matériaux, le fil rouge de ce qui est présenté ici est cette volonté de se plier aux exigences des mécanismes.

    Platon a défini dans le livre VII de La République, une distinction entre le monde du sensible et le monde des idées : le monde du sensible ne serait que la projection du monde des idées, qui nous apparaîtrait déformé par notre propre nature ; ce monde du sensible est par essence ce que nous pouvons imager, sentir.
    Je considère que le travail premier d’un scientifique qui met en œuvre de l’expérimental est de savoir analyser les images des phénomènes observés pour ensuite essayer d’accéder au monde des idées. Ce point se heurte toujours au problème de la fidélité de ce que l’on observe par rapport à l’idée qui gouverne le phénomène. Le lecteur pourra se référer à l’allégorie de la caverne afin de bien illustrer ce propos.
    Tout l’enjeu du scientifique est donc d’être capable d’avoir des images du monde sensible en connaissant les inexactitudes qui y sont attachées afin de pouvoir se faire une idée de ce qui en est la cause la plus probable.
    Le monde de l’imagerie numérique nous donne accès à l’observation de l’hétérogénéité des phénomènes et nous permet de remettre en cause ce qui n’était observable jadis que par la variation durant le temps d’une ou plusieurs quantités ponctuelles. En tant que mécanicien, je me limiterai à l’étude des conséquences de la mise en mouvement de la matière, nous verrons dans une prochaine dépêche que, malgré cette limitation, le champ d’application de l’utilisation de l’imagerie avec le miroir de la mécanique permet d’étudier une grande diversité de sujets et d’accéder à une meilleure compréhension des phénomènes en jeu.

    Nous traiterons ici de données qui ne sont pas toutes directement associables à des lois a priori, de part la complexité des systèmes observés. Les outils que nous développons s’inscrivent donc dans une logique kantisée, mais elle se heurte malheureusement à également l’opposition des conatus des scientifiques.
    Pour faire simple, les méthodes numériques généralistes présentées ici peuvent être utilisées pour appuyer les idées de scientifiques plutôt d’obédience rationaliste mais peuvent tout aussi bien être utilisées par des expérimentateurs plus portés sur l’empirisme. Cette unité de méthode n’empêche pas que les choix techniques (bien qu’appartenant tous au cadre présenté dans cet article) conduiraient à une épistémologie radicalement différente des analyses scientifiques menées par ces deux groupes sur un même objet d’étude.

    Il convient donc de mettre en place une dialectique expérimentale propre à chaque problème traité.

    Comment approcher ou établir une loi ou idée le plus justement possible ?

    Au‐delà des problèmes de biais associés à toute mesure physique, se pose la question du but même de la mesure. Il y a, d’une part, les rationalistes, qui considèrent que toute idée doit être cause ou conséquence d’un enchaînement d’idées rationnelles ; ils chercheront donc à se servir de l’expérimental pour s’approcher de leur loi au travers d’une paramétrisation ad hoc ; et, d’autre part, les empiristes, qui considèrent que toute connaissance prend source dans une expérience sensible, qui chercheront eux à construire des lois au travers de ces observations. À ce titre, je trouve intéressante la citation de Pierre Duhem : « Une loi de physique n’est, à proprement parler, ni vraie ni fausse, mais approchée. » (Traité d’énergétique, 1911), car elle nous permet de discriminer ces courants de pensée expérimentale.
    L’analyse d’image en mécanique ne fait pas exception à cette dualité : il nous arrivera de mettre beaucoup d’_a priori     dans la mesure elle‐même, la contraignant ainsi à se plier à notre vue, mais il sera aussi utile de trouver comment ne pas mettre du tout de physique dans la mesure, pour pouvoir construire nos idées. Ainsi, je présenterai dans cet article des approches que nous avons mises au point permettant d’utiliser la mécanique pour extraire au mieux une physique inaccessible sans cette dernière, telle que la corrélation d’images numériques (Digital Image Correlation, DIC) et la Particule Image Velocimetry (PIV), mais également des méthodes innovantes permettant la réjection de solutions aberrantes, telles que la régularisation par filtre médian dans le processus de DIC.

    Recalage d’images et flot optique

    Que ce soit en analyse d’image ou en mécanique, les techniques se réclamant du flot optique (ou flux optique) sont légion. Le flot optique recouvre énormément de techniques différentes. Beaucoup d’auteurs ont déjà fait des états des lieux de ces techniques (Galvin et al., 1998_, Corpetti et al., 2006_, Baker & Matthews, 2004_), cet article ne sera donc pas une nouvelle revue des techniques déterminant le flot optique. Il n’est cependant pas possible de comprendre les idées qui ont été développées sans situer le flot optique dans ce qui se fait dans la communauté.
    Il me semble cependant plus intéressant d’aborder la présentation de ces démarches au travers du concept de recalage d’images qui est un canevas plus général que celui du flot optique.
    Il existe plusieurs méthodes utilisées pour recaler des images, certaines se basent sur l’intensité lumineuse de l’image, d’autres cherchent à détecter l’écart informations de type géométrique (c.‐à‐d. la distance), d’autres encore se situent à mi‐chemin et sont appelées « iconiques ». Une classification a été donnée par Cachier et al., 2003, elle sera utilisée.

    Principes théoriques du recalage d’images, PIV et corrélation d’images numériques

    Le recalage d’images basé sur l’intensité des niveaux de gris est une technique permettant d’apparier des images entre elles au travers d’une transformation. Cette technique est indispensable dans deux domaines : la création de vues panoramiques à partir de plusieurs prises d’images et l’analyse d’images médicales. Nous allons aborder le second point, plus complexe, car il entraîne une description plus générale. Le recalage d’images médicales a pour but de pouvoir comparer deux images de modalités différentes entre elles ou de comparer plusieurs patients entre eux.

    La DIC (Digital Image Correlation) consiste à placer une caméra devant un essai (traction, compression, flexion, multi‐axial) où l’on ajoute une texture aléatoire.
    La PIV (Particule Image Velocimetry, vélocimétrie par image de particules) consiste à rajouter des particules dans un écoulement (soufflerie, cavité entraînée…) et à les éclairer avec une nappe laser afin de les filmer.
    Ces deux techniques ont pour objectif exclusif d’identifier les transformations.

    Comme ces méthodes sont basées sur la comparaison de deux images, il convient tout d’abord de savoir comment effectuer une telle comparaison.

    Prenons par exemple le cas d’une image d’un patient prise par un IRM et par un scanner. L’IRM repose sur le contraste de résonance magnétique nucléaire alors que le scanner repose sur un contraste d’atténuation des matériaux que traversent les rayons X. Il y a donc peu de chances que les constituants du corps du patient réagissent de la même manière avec ces deux modalités différentes. Ces images ne peuvent donc pas être recalées via le flot optique, il faudra pour garder l’heuristique du recalage trouver un moyen de comparer ces images, ce qui sera introduit par la suite par la notion de métriques.
    Là encore, beaucoup a déjà été écrit à ce sujet mais un point d’entrée intéressant se trouve dans l’article de Wachinger et Navab (2010) qui illustre de manière très pédagogique pourquoi une métrique telle que celle utilisée dans le milieu de la mécanique ne peut pas fonctionner dans ce cas précis. Nous allons nous placer dans un canevas développé par Insight Tool Kit (ITK) introduit dans (Yoo et al., 2002), détaillé dans le manuel d’utilisation (Ibanez et al., 2005), et utilisé dans le logiciel de recalage ElastiX (Klein et al., 2010). Cette démarche est présentée en figure 1 :

     Figure 1 : Principe du recalage d’image ITK et Elastix

    Par convention, on appellera l’image fixe, l’image de référence, et l’image mobile, l’image que l’on souhaite recaler par rapport à cette référence. Le principe est donc le suivant :
    L’image mobile est recalée par rapport à l’image fixe au travers d’une transformation. Pour identifier au mieux cette transformation, plusieurs étapes sont nécessaires. Il faut tout d’abord définir une métrique qui permettra de comparer les deux images. Cette métrique a comme variables d’entrée un type de transformation (Transformation) (rigide, affine similitude, B‐Spline…), l’image fixe et l’image mobile. Il faut ensuite choisir une stratégie d’optimisation (Optimiseur) dans l’algorithme du gradient (Cauchy, 1847), comme la Méthode du point col, Newton, gradient conjugué… Il est également possible de ne pas évaluer la fonctionnelle (métrique) sur toute l’image mais sur un certain nombre de points (échantillonnage) aléatoire, sur une grille ou total. Enfin, il faut appliquer la transformation à l’image mobile et ce à chaque itération, ce qui nécessite un interpolateur.
    Les techniques de type Besnard et al., 2006, Réthoré et al., 2007a, reposent également sur ce schéma mais ne sont qu’un cas particulier, ce qui sera détaillé par la suite.
    Le problème à résoudre se met en équation comme présenté :

    Dans cette équation : est la métrique, la transformation paramétrée par , l’image fixe et l’image mobile.

    Rappelons que :

    où est le vecteur des transformations comme elles seront détaillées par la suite.

    Ces méthodes étant basées sur un algorithme d’optimisation de descente suivant le gradient, elles peuvent converger vers un résultat faux car le résultat est un minimum local de la fonction objectif (métrique). Pour régler ce problème, une technique de résolution pyramidale est employée, comme l’illustre la figure 2 :

     Figure 2 : Principe de l’approche pyramidale, une transformation sur une image très moyennée est trouvée, puis interpolée pour être appliquée en initialisation de l’échelle plus résolue suivante, et ce, jusqu’à la dernière échelle.

    Nous allons détailler quelques points importants du cadre utilisé ici.

    Métrique C

    Ce qui est appelé ici « métrique », ne correspond pas à la définition mathématique, car il ne satisfait pas les critères imposés pour la définition d’une distance. Il serait plus exacte de l’appeler fonction objectif, mais la communauté du recalage d’image a choisi ce terme, aussi il sera conservé ici. La littérature en compte tellement qu’il est impossible d’en faire une liste exhaustive. Celles‐ci se classent dans deux catégories distinctes, les méthodes statistiques basées sur des probabilités jointes et les méthodes directes. Dans les méthodes directes il faut être en mesure de postuler d’un lien entre les évolutions des niveaux de gris de l’image fixe et ceux de l’image mobile. Par exemple, si le flot optique est conservé entre deux images alors la métrique naturelle est l’erreur quadratique moyenne. S’il y a une relation affine entre l’évolution des niveaux de gris des deux images, alors la métrique naturelle est l’inter‐corrélation normalisée. S’il n’y a pas de relation triviale entre les évolutions de niveaux de gris, alors il faut construire une relation propre à la paire d’images étudiée au travers d’une métrique de type statistique comme l’information mutuelle. Les paragraphes suivants présentent quelques‐unes des métriques utilisées en recalage d’images médicales et applicables dans tous les domaines.

    Erreur quadratique moyenne (C=SSD)

    L’erreur quadratique moyenne (ou Sum of Squared Differences, SSD aussi appelée mean squared error) correspond à un problème au moindre carré présenté par l’équation suivante :

    où est le domaine d’intégration, le nombre de pi(vo)xels (cardinal) pour une transformation donnée.

    Inter‐corrélation normalisée (C=NCC)

    L’inter‐corrélation normalisée (ou Normalized Cross Corrélation, NCC) est une technique utilisée dans beaucoup de codes de PIV ou DIC de type blockmatching (Limb et Murphy, 1975). Elle n’est pas sensible au changement de luminosité affine et permet donc de travailler sur des images dont l’éclairement de l’image change fortement entre deux positions. C’est notamment le cas de la PIV, où la nappe laser peut ne pas être parfaitement constante, il peut y avoir de forts reflets et des particules peuvent sortir du plan du laser. C’est également le cas en imagerie médicale où les organes peuvent sortir du plan d’observation. Il est donc impossible dans de telles conditions de respecter le flot optique. Il est de plus intéressant de rappeler qu’usuellement les chercheurs utilisant ces moyens pour la turbulence règlent le temps entre les deux lasers de manière à avoir 10 pixels de déplacement moyen, ce qui peut changer fortement l’illumination des particules. La métrique d’inter‐corrélation normalisée présentée par l’équation suivante est donc théoriquement un bon moyen de résoudre ces contraintes expérimentales :

    avec

    et

    On pourrait également parler de l’information mutuelle, mais je pense que cela nuirait à la concision de l’article.

    Échantillonnage

    L’échantillonnage est défini comme le domaine (c.‐à.‐d. l’ensemble de pixels) sur lesquels la fonction objectif sera évaluée : toute l’image, un masque, une grille, ou tirée aléatoirement. Likar et Pernuš, 2001, ont démontré que le ré‐échantillonnage d’une fonction objectif, telle que l’information mutuelle, lors de l’application de la transformation pouvait conduire à un bruitage important de . Beaucoup de solutions existaient avant ce travail mais elles passaient par l’utilisation de bases d’interpolation d’ordre élevé ce qui entraînait un surcoût en temps de calcul. L’idée de Likar et Pernuš, 2001, a été de n’évaluer la fonctionnelle que sur un nombre réduit de points définis par l’utilisateur et tirés aléatoirement à chaque itération de l’algorithme de descente. Dans la pratique cette stratégie se comporte assez bien sur les deux métriques présentées précédemment mais pas avec tous les optimiseurs. Il est également souvent utilisé une sous‐intégration sur une grille ou une intégration totale. La stratégie à choisir dépend beaucoup de l’objectif que l’on se fixe : si le but est d’avoir une mesure la plus fine possible, alors la sous‐intégration pose problème ; en revanche, si l’objectif est d’obtenir une évaluation rapide des paramètres pour, par exemple, envisager une rétroaction à partir de la transformation mesurée (cas du pilotage d’un essai en déformation homogène), alors l’échantillonnage est certainement un point à ne pas négliger.

    Transformation

    Le modèle de transformation est un autre point clef de la méthode, pour une quantité donnée d’information, nous souhaitons extraire les paramètres d’une transformation. On peut énoncer plusieurs types de transformations :

    Transformations globales

     Figure 3 : Illustration de déformation globale d’une image (rotation, translations, déformations homogènes)

    Elle sont souvent linéaires, telles que le mouvement de corps rigide, la transformation affine (figure 3), la similitude, la transformation projective, qui sont souvent utilisées dans l’analyse d’images médicales. Il existe aussi des transformations globales utilisées dans la communauté de la mécanique des matériaux, telles que celles associées à la fissuration (Hamam et al., 2007, Hild et Roux, 2006) ou celles associées aux poutres (Hild et al., 2011).

    Transformations élastiques (non rigides)

     Figure 4 : Illustration des transformations élastiques d’une image (utilisation d’une base quadrangle bilinéaire)

    Il existe également une gamme de transformations appelée « élastique » dans la communauté de l’analyse d’images médicales. Elle comprend toutes les transformations qui assurent la partition de l’unité, comme les transformations basées sur les polynômes de Lagrange souvent appelées éléments finis (Besnard et al., 2006, figure 4), mais aussi les grilles de type B-Splines (Klein et al., 2010, Réthoré et al., 2010) et les méthodes étendues de type X-FEM (Réthoré et al., 2007b). Il est important de noter que ce terme « élastique » n’est pas accepté dans la communauté de la mécanique car une déformation élastique a une signification en mécanique : ainsi, il est possible d’avoir une déformation qui respecte la partition unité, mais qui n’est pas élastique (endommagement, plasticité, viscosité, etc.). Les mécaniciens du solide ne distinguent pas cette catégorie et rangent ces méthodes de transformation dans les méthodes globales (car il faut une résolution globale pour accéder à la transformation). On pourra utiliser de manière moins ambiguë la notion de « transformation non rigide ».

    Transformations locales

     Figure 5 : Illustration des transformations locales d’une image (seules les translations sont ici identifiées)

    Ces transformations, présentées en figure 5 s’appliquent à une sous‐partie de l’image et ne cherchent pas à résoudre un problème global comme les deux autres. Elles n’ont pas la nécessité de respecter la partition de l’unité. La plus connue et ancienne (Barnea et Silverman, 1972) est la recherche des translations sur chaque imagette par inter‐corrélation. Il est à noter que la méthode la plus rapide est incontestablement la technique d’inter‐corrélation, qui n’est pas un problème itératif et peut être accélérée en utilisant la FFT. Une amélioration présentée par Sutton et al., 1983, est de calculer la translation ainsi que les déformations de l’imagette. Elle est utilisée dans la plupart des logiciels commerciaux de PIV et DIC. Les transformations locales diffèrent des autres transformations de part le fait que chaque zone d’intérêt (Zone of Interest, ZOI) est traitée indépendamment. Dans la communauté de l’analyse d’images, ce problème a été résolu très tôt par Lucas et Kanade, en 1981, qui détermine le flot optique sur des ZOI. Cette méthode est de loin la plus intéressante car elle permet d’utiliser les transformations définies précédemment, mais à l’échelle locale. C’est de plus la seule méthode de blockmatching qui trouve sa place dans le canevas présenté.

    Interpolateur

    L’interpolateur sert à évaluer la valeur de et lors de l’évaluation de la métrique. En effet, les déplacements sont recherchés à une précision inférieure au pixel, il faut donc aller interpoler les valeurs au voisinage de la position définie. Beaucoup d’interpolateurs sont utilisés dans la littérature mais les B‐splines prédominent fortement. Une excellente revue de l’impact d’un interpolateur sur l’image est faite par Getreuer, 2011.

     Figure 6 : Impact des étapes successives d’interpolation d’une rotation en fonction de l’interpolateur choisi (Getreuer, 2011).

    La figure 6 illustre le fait que si l’on cumule des successions de transformations (ici une rotation), alors le choix de l’interpolateur devient fondamental. Sur cette figure, seule une B‐spline d’ordre 11 parvient à ne pas modifier fortement la structure de l’image. Cela montre aussi qu’il est fondamental de ne pas cumuler les interpolations, aussi la stratégie utilisée ici est de toujours travailler avec (la transformation totale est appliquée à l’image mobile initiale) et non avec des successions d’images interpolées de manière cumulative (comme présenté figure 6).

    Optimiseur Dérivation de C

    Il convient de rappeler que les méthodes d’optimisation utilisées ici sont toutes des méthodes basées sur le calcul du gradient de . Le procédé est détaillé sur un exemple en calculant le gradient de l’erreur quadratique moyenne définie précédemment en utilisant la composition des dérivées.

    Pour chaque métrique utilisée il faut calculer le gradient de la fonctionnelle.

    Algorithme du gradient Formalisation mathématique

    Une fois le calcul du gradient de la fonction objectif effectué, il faut trouver une stratégie pour converger vers son minimum.

    Le principe de la minimisation de la fonctionnelle est défini par l’équation suivante :

    La taille du pas de l’algorithme de gradient est pilotée par la valeur de qui peut être constante ou remise à jour à chaque itération suivant différentes méthodes.

    Soit :

    Un point fondamental dans une descente suivant le gradient est de déterminer quelle direction de recherche utiliser. Ce choix se fait au travers de ou itérativement par choix des (gradient conjugué et stochastique), nous présenterons ici les principales méthodes utilisées en optimisation.

    • descente suivant le gradient :
    • Newton avec la matrice hessienne, telle que  :
    • Gauß‐Newton :
    • Levenberg‐Marquardt :
    • quasi‐Newton (BFGS) :
    • gradient conjugué :
    • gradient stochastique :

    Pour les transformations de type élastique, ces relations sont vraies mais doivent être appliquées au niveau de l’élément (FEM, X-FEM) ou à l’échelle du patch (B‐splines).

    Discussion des méthodes d’optimisation

    Il est possible de construire l’opérateur :

    en se servant de la moyenne des gradients de l’image fixe et mobile ce qui permet d’accélérer la procédure d’optimisation. Lorsque cette moyenne est appliquée à la méthode de Gauß‐Newton la méthode s’appelle ESM pour Efficient Second order Minimization, elle a été inventée par Benhimane et Malis, 2004, qui prouvèrent qu’elle avait une excellente convergence pour la , et validée sur d’autres métriques par Wachinger et Navab, 2009. Cette méthode a également été utilisée dans notre communauté par Réthoré et al., 2007a. Il est important de noter que certains auteurs choisissent de ne pas mettre à jour ce terme en le calculant à partir de l’image fixe, dans ce cas on identifie la transformation opposée. Cette technique a l’avantage de ne calculer qu’une seule fois la dérivée de l’image et la matrice Hessienne (pour ), ce qui permet un gain de calcul important dans le cas de la méthode de (quasi ou Gauß) Newton. Ceci peut être très avantageux pour le gradient conjugué, s’il stocke les vecteurs construits au fur et à mesure jusqu’à ce que la base approchée soit stationnaire. Cette base pourrait être utilisée sur l’image suivante d’une séquence comme initialisation, ce qui crée un gain de temps notable et, à partir d’un certain nombre d’itérations, il ne rajoute plus de vecteurs à la base à chaque nouvelle itération du processus d’optimisation. Le principal problème des méthodes de type Newton ou quasi‐Newton est la sensibilité au choix des paramètres initiaux. Si les paramètres sont éloignés, alors il est probable que l’algorithme converge vers un minimum local. S’il est vrai que la technique pyramidale présentée ici permet d’estimer des paramètres à des échelles plus grossières évitant ainsi le piège local, il arrive que cette approche ne suffise pas. D’un autre côté, les méthodes de descente suivant le gradient permettent un écart plus grand par rapport aux paramètres initiaux mais convergent plus lentement. La méthode de Marquardt, 1963, permet de profiter des avantages des deux méthodes mais le choix du et son évolution au cours du temps peut entraîner une convergence faible au niveau de l’optimum.

    Une des méthodes les plus performantes pour résoudre ce système est la méthode quasi‐Newton de type Broyden‐Fletcher‐Goldfarb‐Shanno où les vecteurs et sont des vecteurs de rang 1 de base différente. Les détails de la création des vecteurs et sont disponibles sur Wikipédia. Un point important est qu’il est possible de déterminer explicitement l’inverse de l’approximation de la Hessienne (Sherman et Morrison, 1950). De ce fait, cette méthode peut également être utilisée efficacement conjointement avec l’ESM.
    Une attention toute particulière doit être apportée à la méthode de type gradient stochastique. Cette technique d’optimisation a été développée pour résoudre des problèmes de grande taille dans le domaine de l’apprentissage automatique. Lorsque les systèmes deviennent très gros, il est délicat de calculer l’inverse de la hessienne du problème, voire parfois impossible. Il reste alors comme possibilité de l’approximer (Gauß‐Newton, quasi‐Newton). Le coût numérique étant alors assez élevé, il est alors possible de faire une simple descente suivant le gradient, mais les propriétés de convergence sont alors beaucoup moins bonnes qu’avec une méthode de Newton, car la direction de recherche n’étant pas bonne, il faut beaucoup plus d’itérations. L’idée du gradient stochastique est de ne pas évaluer la fonctionnelle sur toutes les données mais seulement sur un échantillonnage tiré aléatoirement. Bottou et Bousquet, en 2008, ont montré que dans ce cas, l’utilisation de la Hessienne n’améliorait pas la vitesse de convergence et que cette méthode converge plus vite (en termes de temps et non d’itérations) pour les problèmes de grande taille que les méthodes qui approximent la matrice Hessienne. Cette méthode permet donc de s’affranchir du calcul de la matrice hessienne, assure une convergence vers un minimum global dans le cas d’une fonctionnelle convexe et vers un minimum local pour une fonctionnelle non convexe. Klein et al., en 2005, présente une accélération d’un facteur 500 par rapport à un échantillonnage complet. Il a de plus été montré dans la sous‐section échantillonnage que le sous‐échantillonnage permet de lisser la fonction objectif. Nous rappelons que l’obtention d’une fonctionnelle convexe est assurée par le processus pyramidal.

    Stratégie de régularisation

    La stratégie la plus utilisée en ce qui concerne la régularisation est celle mise en œuvre par Tikhonov et Glasko, en 1965, et présentée dans l’équation suivante ; elle consiste à favoriser les solutions dont les normes des inconnues sont petites :

    Dans notre cas :
    en fonction de la stratégie d’optimisation choisie et est égal à la dérivée de la dérivée de . La matrice peut quand à elle être l’identité ou n’importe quel opérateur linéaire tel que, par exemple, la matrice de raideur d’un système à élément finis ou alors une matrice représentant un filtre passe‐bas peut être utilisée pour éliminer les variations rapides qui sont non différentiables du bruit de mesure.

    Après de longues réflexions, nous avons décidé de ne pas implémenter ce canevas pour la régularisation dans nos outils. Bien qu’apparemment séduisantes, les régularisations de Tikonov ne permettent que d’utiliser des normes , car les méthodes d’optimisations implémentées nécessitent une fonctionnelle convexe. Cela entraîne, par exemple, que les régularisations de type (qui conservent les discontinuités) ne nous sont pas accessibles. Il est possible de formuler le problème différemment, Cachier et al, 2003 ont montré qu’il est possible de formuler le problème de recalage d’image iconique de type démon en tant que problème de flot optique au travers d’une minimisation alternée.
    Ainsi, ils formulent le problème de recalage de la manière suivante :

    Les termes et sont les transformations, c’est‐à‐dire des translations pixel à pixel, il n’y a donc pas de base de transformation ici, la cohérence spatiale étant assurée par les énergies de pénalisation pondérées par les coefficients et  ; représente une énergie de pénalisation telle que le laplacien du déplacement en mécanique des fluides ou en mécanique du solide.

    La méthode itérative de résolution est la suivante :

    • d’abord résoudre l’équation suivante en utilisant un algorithme de descente au gradient en version ESM :
    • puis, résoudre l’équation suivante :

    Cette équation pourrait se résoudre également via un algorithme de descente au gradient, mais il existe un moyen de la résoudre par convolution comme démontré en annexe de Cachier et al., 2003_.

    Nous nous sommes inspirés de cette idée, mis à part le fait que nous ayons généralisé cette méthode de régularisation à n’importe quelle méthode de filtrage et non plus à une simple convolution. Après différents tests, nous avons constaté que le filtre médian était l’outil de régularisation le plus efficace dans la plupart des cas.

    La prochaine dépêche présentera les logiciels utilisés dans les différentes communautés scientifiques.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Revue de presse de l’April pour la semaine 26 de l’année 2017

    4 juillet, 2017 - 17:35

    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

    Dernière revue de presse avant la pause estivale. À bientôt en septembre !

    [Next INpact] Vie privée et sécurité de nos données : comment mieux soutenir, informer et protéger ?
    Par David Legrand, le jeudi 29 juin 2017. Extrait :

    « De nombreux outils qui assurent le fonctionnement du Web et la sécurité de nos échanges, ou même la protection de notre vie privée, dépendent d’un mode de financement assez particulier : le don. Mais voilà, les efforts en la matière sont assez éclatés, ce qui mène parfois à une efficacité limitée. Et si l’on pensait les choses autrement ? »

    [LaTeleLibre.fr] La Guerre des Civic Tech
    Par la rédaction, le mardi 27 juin 2017. Extrait :

    « S’impliquer, voter, cliquer. Voilà la recette de la démocratie version 2.0. Simon est parti à la rencontre des Civic-tech, ces acteurs qui permettent à cette démocratie d’éclore. Mais, entre start-up, associations, partisans du logiciel libre et défenseurs du Fermé, le monde des Civic Tech ne rime pas forcément avec participation citoyenne. »

    [ZDNet France] Microsoft / Éducation Nationale : la CNIL émet des réserves
    Par Louis Adam, le mardi 27 juin 2017. Extrait :

    « Dans une lettre obtenue et publiée aujourd’hui par NextInpact, la CNIL revient sur le projet de charte en cours de préparation entre l’Éducation nationale et Microsoft. La Commission y pointe plusieurs manques en matière de protection des données personnelles. »

    [Numerama] L’inventeur du Web livre un plaidoyer en faveur de la neutralité du Net
    Par Julien Lausson, le lundi 26 juin 2017. Extrait :

    « Tim Berners‐Lee, le principal inventeur du Web, signe une tribune pour appeler à la défense de la neutralité du Net, dont le principe est gravement remis en cause aux États‐Unis. »

    Télécharger ce contenu au format Epub

    Lire les commentaires