Aller au contenu | Aller au menu | Aller à la recherche

Dans les entrailles du Libre

jeu., 22/02/2018

Participez à la journée de test consacrée au noyau Linux 4.15

Aujourd'hui, ce jeudi 22 février, est une journée dédiée à un test précis : sur le noyau Linux 4.15. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.

Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

En quoi consiste ce test ?

Le noyau Linux est le cœur du système Fedora (et des autres distributions GNU/Linux). C'est le composant qui fait le lien entre les logiciels et le matériel. C'est lui qui permet aux processus de travailler ensemble sur un même ordinateur et de pouvoir utiliser les périphériques (à travers des pilotes) disponibles sur chaque machine.

C'est donc un composant critique et il est nécessaire de s'assurer qu'il fonctionne.

Les tests du jour couvrent :

  • L'exécution des tests automatisés par défaut et ceux de performances ;
  • Vérifier que la machine démarre correctement ;
  • Vérifier que le matériel est bien exploité (affichage, claviers, souris, imprimantes, scanners, USB, carte graphique, carte son, webcam, réseau filaire et wifi, etc.)

Comment y participer ?

Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.

Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de faire un tour sur IRC pour recevoir un coup de main sur les canaux #fedora-test-day et #fedora-fr (respectivement en anglais et en français) sur le serveur Freenode.

En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

mar., 13/02/2018

Votez pour les fonds d'écran supplémentaires de Fedora 28 !

nuancier-f24-voted.png

Depuis Fedora 20, la livrée du système par défaut contient quelques fonds d'écrans additionnels. Et comme d'habitude, les contributeurs pouvaient soumettre leurs propres dessins ou photographies pour décorer cette nouvelle version.

Maintenant que la période de soumission s'est achevée, nous passons à la phase de vote. Tout possesseur d'un compte FAS peut en sélectionner 16 parmi les dizaines qui sont disponibles. Les plus populaires seront bien évidemment choisis et disponibles dans la Fedora 28 à sa sortie.

Le vote se déroule dans l'application Nuancier jusqu'au 26 février !

Pour ceux que cela intéresse, le badge associé à cette action nécessite une action manuelle. Il suffit de cliquer sur un lien, proposé sur la page après le vote.

ven., 02/02/2018

Appel à tests de l'autonomie des ordinateurs portables, partie 2

Le développeur de Red Hat, Hans de Goede, travaille pour Fedora 28 afin d'améliorer l'autonomie des ordinateurs portables avec notre système préféré. J'en avais déjà parlé dans un article précédent mais ici un nouveau test est requis pour activer une nouvelle fonctionnalité.

Notons que ce test ne concerne pas uniquement Fedora, tout test avec un noyau récent est la bienvenue.

L'un des travaux pour cela est d'activer l'économie d'énergie (Panel Self Refresh) de la communication entre l'écran de l'ordinateur portable et de la carte graphique (à priori ceux d'Intel uniquement) ce qui permettrait de sauver environ 0.5W (ce qui peut représenter entre 1 et 10% de la consommation d'un ordinateur portable).

Si vous souhaitez donner un coup de main, ce serait apprécié. Il faut bien entendu d'un ordinateur portable disposant d'un écran eDP ce que Linux peut vous faire savoir via la commande :

ls /sys/class/drm | grep "-eDP-1"

Un résulat doit apparaître suite à cette commande.

Procédure de tests

Le test est plutôt simple. À partir d'une Fedora la plus fraîche possible (désactivez toutes les optimisations que vous avez fait avec powertop éventuellement). Lancez powertop pendant 5-10 minutes, sans aucun autre logiciel de lancé, uniquement powertop dans le terminal.

Récupérez la plus basse valeur de consommation durant cette période, qui doit être entre 5-30W environ.

Ensuite, répétez la procédure en ajoutant l'option de démarrage i915.enable_psr=1.

Au redémarrage, vérifiez que tout est OK ainsi :

cat /sys/kernel/debug/dri/0/i915_edp_psr_status

existe et est OK.

Après la mesure, vérifiez que l'éteinte reprise de l'écran fonctionne, de même que la mise en veille.

À la fin du test, vous pouvez contacter hdegoede@redhat.com directement en précisant :

  • Si cela a été un succès, sinon quels problèmes il y a eu ;
  • La différence de consommation entre avant et après le correctif ;
  • La marque et modèle de votre ordinateur ;
  • La sortie des commandes
cat /proc/cpuinfo | grep "model name"
cat /sys/class/dmi/id/modalias

Suivant les résultats de ces analyses, l'option sera activée nativement, ou alors sous forme de liste noire ou blanche pour en faire bénéficier que ceux dont cela est efficace et ne pose pas de régressions. Plus de modèles sont testés, mieux c'est.

dim., 28/01/2018

Résultats des élections de Fedora 01/18

Comme je vous le rapportais il y a peu, Fedora a organisé des élections pour renouveler partiellement le collège de ses organes.

Le scrutin est comme toujours un vote par valeurs. Nous pouvons attribuer à chaque candidat un certain nombre de points, dont la valeur maximale est celui du nombre de candidat, et le minimum 0. Cela permet de montrer l'approbation à un candidat et la désapprobation d'un autre sans ambiguïté. Rien n'empêchant de voter pour deux candidats avec la même valeur.

Les résultats pour le Conseil sont (seul les deux premiers sont élus) :

  # votes |  name
- --------+----------------------
     459  | Dennis Gilmore (dgilmore / ausil)
     350  | Nick Bebout (nb)
- --------+----------------------
     334  | Langdon White (langdon)
     309  | Jona Azizaj (jonatoni)
     239  | Russ Herrold (herrold / orc_fedo)

À titre indicatif le score maximal possible était de 5 * 142 (pour 142 votants) soit 710.

Les résultats pour le FESCo sont (seuls les cinq premiers sont élus) :


  # votes |  name
- --------+----------------------
     703  | Kevin Fenzi (nirik)
     579  | Adam Miller (maxamillion)
     512  | Jared Smith (jsmith)
     503  |  Josh Boyer ( jwboyer/jwb )
     483  | Zbigniew Jędrzejewski-Szmek (zbyszek)
- --------+----------------------
     469  | Justin Forbes (jforbes)
     420  | Dominik Mierzejewski (rathann)

À titre indicatif le score maximal possible était de 7 * 143 (pour 143 votants) soit 1001.

Les résultats pour le Mindshare sont donc (seuls les deux premiers sont élus) :

  # votes |  name
- --------+----------------------
     344  | Jared Smith (jsmith)
     325  | Nick Bebout (nb)
- --------+----------------------
     302  | Jona Azizaj (jonatoni)
     280  |  Gabriele Trombini (mailga)
     235  |  Radka Janek (rhea)

À titre d'indication, la valeur maximale possible est de 5 * 124 (car il y a eu 124 votants) soit 620.

Nous pouvons noter que globalement le nombre de votants pour chaque scrutin était proche aux alentours de 175-150 votants.. Les scores sont aussi plutôt éparpillés, avec souvent quelques membres assez largement en tête de chaque scrutin.

Bravo aux participants et aux élus, que le projet Fedora avance. :-)

ven., 19/01/2018

Élections pour le Conseil, FESCo et Mindshare cette semaine

Comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council, FESCo et Mindshare. Et ce sont les contributeurs qui décident. Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.

J'ai voté

Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au mercredi 25 janvier à 1h heure française pour le faire. Donc n'attendez pas trop.

Je vais profiter de l'occasion pour résumer le rôle de chacun de ces comités afin de clarifier l'aspect décisionnel du projet Fedora mais aussi visualiser le caractère communautaire de celui-ci.

Council

Le Council est ce qu'on pourrait qualifier le grand conseil du projet. C'est donc l'organe décisionnaire le plus élevé de Fedora. Le conseil définit les objectifs à long terme du projet Fedora et participe à l'organisation de celui-ci pour y parvenir. Cela se fait notamment par le biais de discussions ouvertes et transparentes vis à vis de la communauté.

Mais il gère également l'aspect financier. Cela concerne notamment les budgets alloués pour organiser les évènements, produire les goodies, ou des initiatives permettant de remplir les dits objectifs. Ils ont enfin la charge de régler les conflits personnels importants au sein du projet, tout comme les aspects légaux liés à la marque Fedora.

Les rôles au sein du conseil sont complexes.

Ceux avec droit de vote complet

Tout d'abord il y a le FPL (Fedora Project Leader) qui est le dirigeant du conseil et de facto le représentant du projet. Son rôle est lié à la tenue de l'agenda et des discussions du conseil, mais aussi de représenter le projet Fedora dans son ensemble. Il doit également servir à dégager un consensus au cours des débats. Ce rôle est tenu par un employé de Red Hat et est choisi avec le consentement du conseil en question.

Il y a aussi le FCAIC (Fedora Community Action and Impact Coordinator) qui fait le lien entre la communauté et l'entreprise Red Hat pour faciliter et encourager la coopération. Comme pour le FPL, c'est un employé de Red Hat qui occupe cette position avec l'approbation du conseil.

Il y a deux places destinées à la représentation technique et à la représentation plus marketing / ambassadrice du projet. Ces deux places découlent d'une nomination décidée au sein des organes dédiées à ces activités : le FESCo et le Mindshare. Ces places sont communautaires mais ce sont uniquement ces comités qui décident des attributions.

Il reste deux places communautaires totalement ouvertes et dont tout le monde peut soumettre sa candidature ou voter. Cela permet de représenter les autres secteurs d'activité comme la traduction ou la documentation mais aussi la voix communautaire au sens la plus large possible. C'est pour ces places que le vote est ouvert cette semaine !

Ceux avec le droit de vote partiel

Un conseiller en diversité est nommé par le FPL avec le soutien du conseil pour favoriser l'intégration au sein du projet des populations le plus souvent discriminées. Son objectif est donc de déterminer les programmes pour régler cette problématique et résoudre les conflits associés qui peuvent se présenter.

Un gestionnaire du programme Fedora qui s'occupe du planning des différentes versions de Fedora. Il s'assure du bon respect des délais, du suivi des fonctionnalités et des cycles de tests. Il fait également office de secrétaire du conseil. C'est un employé de Red Hat qui occupe ce rôle toujours avec l'approbation du conseil.

FESCo

Le FESCo (Fedora Engineering Steering Committee) est un conseil entièrement composé de membres élus et totalement dévoués à l'aspect technique du projet Fedora.

Ils vont donc traiter en particulier les points suivants :

  • Les nouvelles fonctionnalités de la distribution ;
  • Les sponsors pour le rôle d'empaqueteur (ceux qui pourront donc superviser un débutant) ;
  • La création et la gestion des SIGs (Special Interest Group) pour organiser des équipes autour de certaines thématiques ;
  • La procédure d'empaquetage des paquets.

Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un an, sachant que chaque élection renouvelle la moitié du collège.

Mindshare

Mindshare est une évolution du FAmSCo (Fedora Ambassadors Steering Committee) qu'il remplace. Il est l'équivalent du FESCo sur l'aspect plus humain du projet. Pendant que le FESCo se préoccupera beaucoup plus des empaqueteurs, la préoccupation de ce conseil est plutôt l'ambassadeur et les nouveaux contributeurs.

Voici un exemple des thèmes dont il a compétence qui viennent du FAmSCo :

  • Gérer l'accroissement des ambassadeurs à travers le mentoring ;
  • Pousser à la création et au développement des communautés plus locales comme la communauté française par exemple ;
  • Réaliser le suivi des évènements auxquels participent les ambassadeurs ;
  • Accorder les ressources aux différentes communautés ou activités, en fonction des besoin et de l'intérêt ;
  • S'occuper des conflits entre ambassadeurs.

Et ses nouvelles compétences :

  • La communication entre les équipes, notamment entre la technique et le marketing ;
  • Motiver les contributeurs à s'impliquer dans différents groupes de travail ;
  • Gérer l'arrivé de nouveaux contributeurs pour les guider, essayer de favoriser l'inclusion de personnes souvent peu représentées dans Fedora (femmes, personnes non américaines et non européennes, étudiants, etc.) ;
  • Gestion de l'équipe marketing.

Il y a 9 membres pour gérer ce nouveau comité. Un gérant, 2 proviennent des ambassadeurs, un du design et web, un de la documentation, un du marketing, un de la commops et les deux derniers sont élus. C'est pour ces deux derniers sièges que les scrutins sont ouverts.

mar., 12/12/2017

Fin de vie de Fedora 25

C'est en ce mardi 12 décembre 2017 que Fedora 25 a été déclaré comme en fin de vie.

Qu'est-ce que c'est ?

Un mois après la sortie d'une version de Fedora n, ici Fedora 27, la version n-2 (donc Fedora 25) est déclarée comme en fin de vie. Ce mois sert à donner du temps aux utilisateurs pour faire la mise à niveau. Ce qui fait qu'en moyenne une version est officiellement maintenue pendant 13 mois.

En effet, la fin de vie d'une version signifie qu'elle n'aura plus de mises à jour et plus aucun bogue ne sera corrigé. Pour des questions de sécurité, avec des failles non corrigées, il est vivement conseillé aux utilisateurs de Fedora 25 et antérieurs d'effectuer la mise à niveau vers Fedora 27 ou 26.

Que faire ?

Si vous êtes concernés, il est nécessaire de faire la mise à niveau de vos systèmes. Vous pouvez télécharger des images CD ou USB plus récentes.

Il est également possible de faire la mise à niveau sans réinstaller via DNF ou GNOME Logiciels.

GNOME Logiciels a également dû vous prévenir par une pop-up de la disponibilité de Fedora 26 ou 27. N'hésitez pas à lancer la mise à niveau par ce biais.

dim., 10/12/2017

Compte rendu des JM2L 2017

Le samedi 25 novembre dernier, j'ai représenté avec Nicolas Chauvet l'association Borsalinux-fr dans le cadre de la Journée Méditerranéenne du Logiciel Libre.

JM2L-Stand.jpg

Bien qu'il y avait moins de visiteurs que lors de la précédente édition en 2015, nous avons pu discuter ou aider avec une quinzaine de personnes à propos de Fedora. Que ce soit des utilisateurs de longue date, ou de simples curieux.

Le matin nous avons été interrogé par France 3 Côte d'Azur (dont la diffusion a été le dimanche 26 au soir au JT local) à propos des Logiciels Libres en général. Je précise que contrairement à ce qui est indiqué sur l'image, je ne suis pas un employé de Red Hat. C'est une erreur de la journaliste en question. De même, l'équipe de Nice-Matin a couvert l'évènement avec une belle photo de groupe des participants.

L'après-midi nous avons continué le stand et j'ai présenté ma conférence à 15h sur Les apports de Fedora Workstation à l'écosystème du Logiciel Libre. Elle a été suivie par une quinzaine de personnes. L'ensemble du contenu sera disponible bientôt sur quelques sites web francophones dont mon blog.

C'était une chouette journée, bravo aux organisateurs et à dans deux ans pour une prochaine édition !

Les élections au sein du projet Fedora en cours sont retardées

J'avais annoncé cette semaine l'ouverture des votes pour différents organes du projet Fedora : le conseil, FESCo et FAmSCo..

Tout d'abord j'ai oublié en effet qu'il a été décidé de remplacer le FAmSCo par Mindshare, qui n'est pas un simple changement de nom car cette organe a des représentants de plus d'équipes sociales du projet que seulement les ambassadeurs. Mais cela n'est pas l'objet de ce billet.

Le scrutin mentionné plus haut a été reporté depuis le 8 décembre à une date ultérieure, apparemment début janvier 2018. L'objet de ce report vient en fait de la décision de réformer un peu l'organisation des élections afin notamment de publier des entretiens de chaque candidat à la date d'ouverture des élections. Seulement, certains candidats n'ont pas pu poster à temps leur réponse pour des raisons de temps ou des difficultés techniques côté infrastructure de Fedora.

Par soucis d'équité et de cohérence, tous les scrutins ont été décalés par décision du conseil de Fedora.

Bon courage aux candidats et aux organisateurs, en espérant que la prochaine élection se déroule sans accroc !

mar., 05/12/2017

Élections pour le Conseil, FESCo et FAmSCo cette semaine

Comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council, FESCo et FAmSCo. Et ce sont les contributeurs qui décident. Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.

J'ai voté

Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au mardi 13 décembre à 1h heure française pour le faire. Donc n'attendez pas trop.

Je vais profiter de l'occasion pour résumer le rôle de chacun de ces comités afin de clarifier l'aspect décisionnel du projet Fedora mais aussi visualiser le caractère communautaire de celui-ci.

Council

Le Council est ce qu'on pourrait qualifier le grand conseil du projet. C'est donc l'organe décisionnaire le plus élevé de Fedora. Le conseil définit les objectifs à long terme du projet Fedora et participe à l'organisation de celui-ci pour y parvenir. Cela se fait notamment par le biais de discussions ouvertes et transparentes vis à vis de la communauté.

Mais il gère également l'aspect financier. Cela concerne notamment les budgets alloués pour organiser les évènements, produire les goodies, ou des initiatives permettant de remplir les dits objectifs. Ils ont enfin la charge de régler les conflits personnels importants au sein du projet, tout comme les aspects légaux liés à la marque Fedora.

Les rôles au sein du conseil sont complexes.

Ceux avec droit de vote complet

Tout d'abord il y a le FPL (Fedora Project Leader) qui est le dirigeant du conseil et de facto le représentant du projet. Son rôle est lié à la tenue de l'agenda et des discussions du conseil, mais aussi de représenter le projet Fedora dans son ensemble. Il doit également servir à dégager un consensus au cours des débats. Ce rôle est tenu par un employé de Red Hat et est choisi avec le consentement du conseil en question.

Il y a aussi le FCAIC (Fedora Community Action and Impact Coordinator) qui fait le lien entre la communauté et l'entreprise Red Hat pour faciliter et encourager la coopération. Comme pour le FPL, c'est un employé de Red Hat qui occupe cette position avec l'approbation du conseil.

Il y a deux places destinées à la représentation technique et à la représentation plus marketing / ambassadrice du projet. Ces deux places découlent d'une nomination décidée au sein des organes dédiées à ces activités : le FESCo et le FAmSCo. Ces places sont communautaires mais ce sont uniquement ces comités qui décident des attributions.

Il reste deux places communautaires totalement ouvertes et dont tout le monde peut soumettre sa candidature ou voter. Cela permet de représenter les autres secteurs d'activité comme la traduction ou la documentation mais aussi la voix communautaire au sens la plus large possible. C'est pour l'une de ces places que le vote est ouvert cette semaine !

Ceux avec le droit de vote partiel

Un conseiller en diversité est nommé par le FPL avec le soutien du conseil pour favoriser l'intégration au sein du projet des populations le plus souvent discriminées. Son objectif est donc de déterminer les programmes pour régler cette problématique et résoudre les conflits associés qui peuvent se présenter.

Un gestionnaire du programme Fedora qui s'occupe du planning des différentes versions de Fedora. Il s'assure du bon respect des délais, du suivi des fonctionnalités et des cycles de tests. Il fait également office de secrétaire du conseil. C'est un employé de Red Hat qui occupe ce rôle toujours avec l'approbation du conseil.

FESCo

Le FESCo (Fedora Engineering Steering Committee) est un conseil entièrement composé de membres élus et totalement dévoués à l'aspect technique du projet Fedora.

Ils vont donc traiter en particulier les points suivants :

  • Les nouvelles fonctionnalités de la distribution ;
  • Les sponsors pour le rôle d'empaqueteur (ceux qui pourront donc superviser un débutant) ;
  • La création et la gestion des SIGs (Special Interest Group) pour organiser des équipes autour de certaines thématiques ;
  • La procédure d'empaquetage des paquets.

Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un an, sachant que chaque élection renouvelle la moitié du collège.

FAmSCo

Le FAmSCo (Fedora Ambassadors Steering Committee) est l'équivalent du FESCo sur l'aspect plus humain du projet. Pendant que le FESCo se préoccupera beaucoup plus des empaqueteurs, la préoccupation de ce conseil est plutôt l'ambassadeur.

Voici un exemple des thèmes dont il a compétence :

  • Gérer l'accroissement des ambassadeurs à travers le mentoring ;
  • Pousser à la création et au développement des communautés plus locales comme la communauté française par exemple ;
  • Réaliser le suivi des évènements auxquels participent les ambassadeurs ;
  • Accorder les ressources aux différentes communautés ou activités, en fonction des besoin et de l'intérêt ;
  • S'occuper des conflits entre ambassadeurs.

Les 7 membres de cette équipe sont également entièrement élus avec une durée de mandat d'un an. Chaque élection renouvelle le collège par moitié.

jeu., 30/11/2017

Participez à la journée de test consacrée au noyau Linux 4.14

Aujourd'hui, ce jeudi 30 novembre, est une journée dédiée à un test précis : sur le noyau Linux 4.14. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.

Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

En quoi consiste ce test ?

Le noyau Linux est le cœur du système Fedora (et des autres distributions GNU/Linux). C'est le composant qui fait le lien entre les logiciels et le matériel. C'est lui qui permet aux processus de travailler ensemble sur un même ordinateur et de pouvoir utiliser les périphériques (à travers des pilotes) disponibles sur chaque machine.

C'est donc un composant critique et il est nécessaire de s'assurer qu'il fonctionne.

Les tests du jour couvrent :

  • L'exécution des tests automatisés par défaut et ceux de performances ;
  • Vérifier que la machine démarre correctement ;
  • Vérifier que le matériel est bien exploité (affichage, claviers, souris, imprimantes, scanners, USB, carte graphique, carte son, webcam, réseau filaire et wifi, etc.)

Comment y participer ?

Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.

Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de faire un tour sur IRC pour recevoir un coup de main sur les canaux #fedora-test-day et #fedora-fr (respectivement en anglais et en français) sur le serveur Freenode.

En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

mar., 28/11/2017

Revue de presse de Fedora 27

Cela fait depuis Fedora 19 que je publie sur la liste de diffusion de Fedora-fr une revue de presse de chaque sortie d'une nouvelle version. Récapituler quels sites en parle et comment. Je le fais toujours deux semaines après la publication (pour que tout le monde ait le temps d'en parler). Maintenant, place à Fedora 27 !

Bien entendu je passe sous silence mon blog et le forum de fedora-fr.

Sites web d'actualité

Soit 7 sites sur les 25 contactés.

Blogs, sites persos ou sites non contactés

Soit 4 sites.

Bilan

Le nombre de sites parlant de Fedora 27 est stable depuis Fedora 19. Beaucoup d'articles se fondent sur ce que j'ai moi même rédigé (que ce soit la version courte ou longue). La semaine de sa sortie, nous avons eu entre 300 et 400 visiteurs uniques en plus sur le site fedora-fr.org ce qui représente un pic de 30%. Augmentation similaire que pour l'annonce de Fedora 26 (mais comme c'était l'été, Fedora 26 a attiré moins de personnes sur notre site).

Si vous avez connaissance d'un autre lien, n'hésitez pas à partager ! Rendez-vous pour Fedora 28.

sam., 25/11/2017

Compte rendu mensuel de la documentation francophone, numéro 3

Pour rappel, vous pouvez consulter l'état du travail en cours sur la documentation.

Les sujets traités ont changé quelque peu depuis la dernière fois. C'est plus centré autours des thématiques :

  • Le noyau et composantes basses ;
  • La sécurité et autres utilitaires ;
  • L'usage serveur de courrier.

Personnellement je me suis occupé plutôt des deux premiers thèmes. En effet même si le noyau Linux ne change pas fondamentalement, ses correctifs majeurs et sa procédure de compilation ont un peu changé. Ils ont nécessité un petit rafraîchissement. De plus, avec Fedora 25 qui a inauguré avec Wayland par défaut, il a fallu lui dédier un nouvel article pour familiariser les utilisateurs avec cette technologie.

Concernant le deuxième point, il était nécessaire de revoir la liste des logiciels pour chaque usage sur notre système préféré. Si les éditeurs d'images ou suites bureautique n'ont pas beaucoup changé en 5 ans, on ne peut pas en dire autant des clients de messagerie ou des navigateurs Web. Ces secteurs ont été très dynamiques avec beaucoup de projets obsolètes et de nouveaux venus. Pour la sécurité, deux outils majeurs que sont gnupg et ssh ont évolué. Surtout le premier avec sa version 2. Maintenant c'est corrigé. Nicolas a amélioré la sécurité des connexions VNC à travers SSH.

Enfin, la FAQ a été modernisée un petit peu les effets 3D de bureau sont passés de mode et systemd a remplacé le concept des niveaux d’exécution.

Le dernier point a été particulièrement étudié par Nicolas comme d'habitude, car Fedora a bien entendu un usage serveur important dont le paysage a changé. Cela commence par bien sûr parler de sendmail ou d'effectuer les redirections des courriels.

Mais son apport le plus important a bien sûr été la refonte de l'énorme article sur les serveurs de messagerie. Un article tout en un très complet qui a bénéficié d'un grand ravalement de façade. Bravo !

Je remercie également les autres contributeurs, relecteurs ou toute autres personnes qui se sont impliquées dans ce processus comme Édouard et d'autres.

Aujourd'hui donc, nous sommes à 55 articles traités, contre 42 au précédent bilan. Je suis satisfait des progrès réalisés sur la documentation. Il y a beaucoup de travail à mener encore, mais il semble possible que la documentation soit dans un état très acceptable bientôt. Ensuite il faudra veiller à maintenir la documentation à jour continuellement et ajouter des articles suivant les besoins du moment.

Je vous invite en tout cas à nous donner un coup de main, pour cela je vous conseille de suivre la procédure pour contribuer à la documentation et si possible de participer à nos ateliers hebdomadaires tous les lundi soir à partir de 21h (heure de Paris) sur le canal IRC #fedora-doc-fr du serveur Freenode. Rien ne vous empêche de contribuer en dehors du cadre des ateliers, toute l'aide est la bienvenue. Alors, n'hésitez pas !

jeu., 23/11/2017

Appel à tests de l'autonomie des ordinateurs portables

Le développeur de Red Hat, Hans de Goede, travaille pour Fedora 28 afin d'améliorer l'autonomie des ordinateurs portables avec notre système préféré.

L'un des travaux pour parvenir à cet objectif est d'activer SATA Link Power Management. Ce dispositif existait depuis longtemps, mais certains modèles de disques durs et de SSD subissaient des craches et même des pertes de données. Matthew Garret a travaillé sur le sujet par le passé, ce que Hans a complété en se basant sur les travaux d'Intel et de son implémentation dans Windows.

Donc il propose au noyau Linux un nouveau mode LPM nommé med_power_with_dipm qui est proche en résultats de min_power setting proposé par Matthew. Il espère que de s'inspirer de Windows puisse résoudre les difficultés rencontrées à l'époque.

Si vous souhaitez donner un coup de main, ce serait apprécié. Il faut bien entendu d'un ordinateur portable disposant d'un disque dur ou d'un SSD accessible par SATA (donc pas de NVME). Il est également indispensable de sauvegarder vos données avant la manipulation.

Procédure de tests

Le test est plutôt simple. À partir d'une Fedora la plus fraîche possible (désactivez toutes les optimisations que vous avez fait avec powertop éventuellement). Lancez powertop pendant 5 minutes, sans aucun autre logiciel de lancé, uniquement powertop dans le terminal.

Récupérez la valeur de consommation durant cette période, qui doit être entre 5-10W environ.

Ensuite, répétez la procédure en installant et bootant sur le noyau disponible à cette adresse qui contient le correctif en question. Téléchargez également le fichier rc.local dans le dossier /etc/rc.d/rc.local en le rendant exécutable bien évidemment.

Au redémarrage, vérifiez que tout est OK ainsi :

cat /sys/class/scsi_host/host0/link_power_management_policy"

Vous devez avoir la valeur med_power_with_dipm s'afficher, sinon quelque chose a raté.

Ensuite refaites la procédure avec powertop à l'identique. Et testez ce noyau pendant 2 semaines idéalement.

À la fin du test, vous pouvez contacter hdegoede@redhat.com directement en précisant :

  • Si cela a été un succès, sinon quels problèmes il y a eu ;
  • La différence de consommation entre avant et après le correctif ;
  • La marque et modèle de votre ordinateur ;
  • La sortie des commandes
cat /proc/cpuinfo | grep "model name"
cat /sys/class/scsi_device/*/device/model

Cette nouveauté est actuellement en cours de discussion pour Fedora 28. N'hésitez pas à donner un coup de main pour que cela soit possible d'en bénéficier en mai 2018. :-)

mar., 21/11/2017

La sécurité, l'obsolescence et la maintenance des systèmes embarqués

Il est assez banal de dire que de plus en plus d'équipements modernes sont connectés au réseau. Cela apporte de nouvelles fonctionnalités, la possibilité d'améliorer le produit même une fois vendu par des mises à jour mais aussi des problèmes de confidentialité et de sécurité.

Les systèmes embarqués sont particulièrement concernés par ces problématiques, que les industriels traitent parfois mal et dont les consommateurs sont rarement dans le vrai également.

C'est de cette problématique dont on va parler.

Obsolescence programmée ?

Ce terme revient souvent dans ce genre de discussions. Que l'abandon du support d'un produit, comme par exemple l'absence d'une mise à jour Android, ou que justement la mise à jour de trop rend le système trop lent (cas de certains iPhone) serait une pratique digne de l'obsolescence programmée.

Globalement c'est faux. L'obsolescence programmée est une pratique supposée où un constructeur fragilise **volontairement** son produit afin de nécessiter un remplacement régulier pour augmenter ses ventes.

Le mot clé est donc l'aspect volontaire. Qui est difficile en réalité à constater. Et certains oublient aussi l'aspect de l'équilibre entre le prix et la qualité. Un produit bas de gamme va minimiser la qualité des matériaux par exemple pour que cela coûte moins cher au client. Il est donc normal que le produit dure moins longtemps. Cette question du compromis dans la réalisation du produit est l'essence même du travail d'un ingénieur et de la création de différentes gammes de produits, on ne peut assimiler cela à de l'obsolescence programmée qui consiste en un sabotage.

Je ne vais pas m'étendre beaucoup sur le sujet, il y a trois articles de blog (ici, et là-bas) qui traitent bien de la question de l'obsolescence programmée qui reste une pratique à priori confidentielle. Mais le célèbre reportage d'Arte sur le sujet a mis en lumière cette pratique avec de mauvais exemples et certains le voient du coup... partout.

En tout cas on ne m'a jamais demandé de saboter mon propre produit, et aucun de mes collègues ou connaissances non plus. ;-) Par contre il arrive que certains bogues ne soient jamais corrigés, faute de temps ou de ressources financières pour les traiter.

De la question du progrès logiciel

Certains produits, comme nos ordinateurs ou téléphones portables, peuvent vivre des années sans problèmes. Et ces outils à usage assez génériques peuvent exécuter du logiciel conçu bien après la réalisation du produit.

Mon ordinateur portable personnel actuel date de 2011, il est passé de Fedora 16 à 27, de Windows 7 à 10, de Firefox 7 à Firefox 56, de GNOME 3.0 à GNOME 3.26, de Linux 3.1 à Linux 4.14, etc.

Ce sont des millions de lignes de code ajoutées depuis, le Web a beaucoup grossi entre temps avec du JavaScript devenu omniprésent et des sites devenant de plus en plus des applications complètes. Le contenu multimédia s’alourdit, passant du 720p à 4K pour les vidéos ou les photos. Le chiffrement s'est généralisé également dans les communications ou le stockage.

J'ai constaté peu à peu un ralentissement de ma machine, la consommation de la mémoire a monté (j'ai du rajouter 4 Gio récemment) alors que mon usage, fondamentalement n'a pas changé.

Ce phénomène n'a rien de nouveau, cela suit la loi de Wirth.

C'est un phénomène naturel. Les logiciels évoluent pour ajouter des fonctionnalités (pour répondre à des besoins des utilisateurs). Il est impossible de proposer du logiciel plus moderne tout en espérant une consommation en ressource identique indéfiniment. Soit il faut utiliser un produit qui n'évoluera plus fonctionnellement (cas de beaucoup d'outils simples et légers), ou alors il faudrait beaucoup de ressources financières et humaines pour maintenir plusieurs déclinaisons du logiciel dans le temps. Ce que l'on abordera plus tard.

Ce que la loi de Wirth n'explique pas ou mal, c'est que l'évolution du matériel se produit de manière globale, mais localement un produit a un matériel plutôt figé. Si le matériel évolue mais que les logiciels n'exploitent pas cette puissance supplémentaire, ce serait du gâchis. Donc la consommation des programmes évoluent pour bénéficier de ces ressources disponibles. Et forcément cela se fait au détriment des machines qui accusent d'un certain âge. Cela est encore plus visible sur les téléphones qui ont fait un saut de performances spectaculaire en très peu d'années.

Certains veulent exploiter la machine le plus longtemps possible (donc disons 10-15 ans) tout en bénéficiant de ces évolutions. Ce n'est pas possible sans concession. Il faut faire des choix, en payant cher des produits pour les maintenir longtemps, en renonçant partiellement à ce progrès, en changeant de machine ou renoncer à des usages. Typiquement, aller sur le Web avec une machine de 2002 doit être possible, mais cela ne doit pas être une expérience très agréable en dehors de quelques sites très légers.

Et pour un téléphone bas de gamme, conçu pour être tout juste capable de lancer les applications populaires de l'époque, ne peut pas soutenir la charge d'une mise à jour des dites applications sur le long terme.

Et après toute cette explication, comment associer cela à de l'obsolescence programmée alors que cette lourdeur progressive provient de logiciels extérieurs à la conception du matériel ? Ce n'est pas Intel qui a rendu Firefox plus lourd avec le temps. :-)

La sécurité

La sécurité est devenue depuis quelques années un sujet de premier plan pour tout un nouveau panel de produits. Avec une connexion accessible depuis Internet, il devient possible d'essayer d'infiltrer ces produits qui peuvent être accessibles non stop pendant des années et sans maintenance active (il n'y a pas un administrateur système pour surveiller le réseau domestique d'un particulier).

Du coup, pour combler les failles, il devient nécessaire de mettre à jour le produit. Parfois changer l'outil interne, ou le protocole employé (le MD5 n'est plus un moyen fiable pour vérifier l'intégrité d'un fichier ou d'un certificat).

Du coup pour améliorer la sécurité, on doit les faire évoluer. Ce qui peut nous faire revenir sur le point précédent où le logiciel devient trop lourd pour le matériel considéré ce qui rend compliqué la conciliation des deux.

L'autre problème est... le coût. Quand on achète un produit type téléphone, un réfrigérateur connecté, un modem ou autre, nous achetons le produit à un prix fixe, parfois très dérisoire car très bas de gamme. Sauf que d'assurer une maintenance sur 10-15 ans, cela coûte très cher. Car il devient nécessaire de maintenir plusieurs versions du logiciel (suivant l'âge du matériel et de ses successeurs à maintenir), de tester chaque mise à jour sur chaque produit, tester son déploiement, corriger les éventuels ratés auprès des clients, communiquer auprès d'eux (manuels explicatifs, mise à jour d'un site Web possiblement en plusieurs langues, courriers / courriels envoyés en nombre).

Admettons que pour maintenir un modèle d'un téléphone portable pendant 15 ans il faut une équipe de 10 personnes à temps plein (ce qui n'est pas irréaliste car cela demande beaucoup de travail pour corriger la moindre faille ou les bogues découverts, sachant que le logiciel dépend également du lieu vendu pour des raisons de contraintes légales). En admettant qu'ils ne sont pas mal payés (et qu'il leur faut du matériel adéquat), cela peut revenir par employé à un coût annuel pour l'employeur d'environ 100 000€. Donc 1 million d'euros par an. Sachant qu'un modèle lambda d'un téléphone peut être vendu auprès du million d'unités au total, cela reviendrait a un coût de 10-15 millions d'euros rien que pour la maintenance une fois le produit vendu. Pour des téléphones à 100€, cela représente 10% du budget global du produit ! Ce n'est clairement pas négligeable. Et je ne parle pas des cas de produits moins vendus qui méritent pourtant la même maintenance.

Le Libre comme solution ?

Certains pensent qu'un produit embarqué, s'il est fait avec du logiciel libre, il est aisé de le maintenir pour proposer des mises à jour du produit pendant des années après l'abandon par son constructeur. La réalité est plus complexe.

Pour les projets assez puissants pour accueillir un système d'exploitation Linux (cas des téléphones par exemple), le système est rarement compilé de zéro à la main. Pour gagner du temps, il existe des solutions comme Yocto ou buildroot (et ses déclinaisons OpenWRT ou ptxdist) pour compiler l'ensemble des logiciels (dont le noyau) pour notre système afin d'obtenir une image qu'on pourra installer sur la cible. Je les présenterais dans un autre article.

Seulement, chaque processeur ou plateforme a ses spécificités. C'est pourquoi, les concepteurs des puces (Qualcomm, Texas Instrument, Broadcom, Freescale / NXP et autres) fournissent les solutions citées plus haut avec les changements nécessaires pour exploiter la plateforme. Très souvent le noyau Linux et le chargeur de démarrage U-Boot accueillent une grande liste de correctifs maison (plusieurs centaines).

Cela est bien, car nous n'avons pas à développer nous même les pilotes pour exploiter les fonctions du processeur (notamment pour la couche graphique) et dans l'essentiel cela reste du code libre. Cependant ces correctifs sont gros et souvent… mal réalisés. Faute de temps et de ressources, les constructeurs ne cherchent pas à concevoir des correctifs qui finiront dans le projet officiel. Leur but est que cela fonctionne avec le noyau fourni aux développeurs / intégrateurs. Du coup nous nous retrouvons avec un noyau et un chargeur de démarrage figé, car Linux évolue très vite et il est très difficile de porter ces correctifs pour une autre version. Et comme cela est trop souvent trop mal fait (utilisation d'une pile logicielle différente que celle du noyau pour une fonction donnée, comme le SPI ou le réseau par exemple, code spaghetti avec lien fort entre le tronc commun et leur pilote, etc.) il est difficilement imaginable de porter cela sur le noyau officiel directement.

Pas mal de personnes essayent pourtant de porter le nécessaire sur le noyau officiel. Mais cela demande beaucoup de temps (aujourd'hui le support du téléphone N900 est quasiment complet, mais il aura fallu 8 ans après sa sortie !) et c'est souvent au prix de fonctionnalités partielles (performances graphiques ou réseaux plus faibles, gestion de l'énergie douteuse). Sans collaboration du fondeur, c'est une tâche globalement vouée à l'échec étant donné le rythme de sortie des composants. Puis le fabricant de la puce bosse déjà sur la plateforme suivante. Ils n'ont pas le temps, ni l'envie, de s'attarder sur un produit qui n'a plus d'avenir.

Et même dans le cas où ce serait possible, il y a des sacs de nœuds dans l'architecture du système. Si vous souhaitez profiter par exemple des dernières tablettes Wacom sur votre machine, il faudra un noyau récent. En admettant que vous avez un noyau LTS un peu ancien comme la 3.4, il faudra rétro-porter cette fonctionnalité. Cela signifie récupérer le pilote mais souvent d'autres commits sur le sous-systèmes des périphériques entrées. Mais le noyau ne fait pas tout, il faut également que l'interface graphique propose de quoi configurer et exploiter le matériel. Donc par exemple en récupérant du travail effectué sur les versions récentes de GTK+ et de GNOME. Cela peut donc représenter beaucoup de travail, sur beaucoup de composants, et il faudra tester bien sûr du bon fonctionnement, de la sécurité et de la maintenance de tout ceci.

Bref, l'aspect libre peut aider bien sûr à maintenir un produit plus longtemps. D'ailleurs les initiatives du genre OpenWRT, CyanogenMod / LineageOS permettent de maintenir à jour certains produits embarqués plus longtemps que le support officiel du constructeur. Mais cela se fait souvent au détriment de certaines fonctionnalités matérielles.

Solutions ?

Je pense que la solution ne peut se passer de l'aide des industriels, qui eux-mêmes ne peuvent pas se permettre à un coût fixe d'une maintenance complexe sur une très longue durée. Imposer légalement une durée minimale de support conduirait à une hausse de prix d'achat inévitable de tous ces biens.

Une autre solution serait d'évoluer vers une tarification en tant que service. À savoir payer pour une durée de maintenance souhaitée. Si l'utilisateur souhaite 10 ans de maintenance, il le pourra, au prix d'un abonnement ajusté en conséquence. Je pense que c'est la seule solution, notamment pour les produits vendus à un volume moyen ou faible, d'avoir une maintenance dans le temps à la hauteur, sans rendre le produits inutilisable ou trop cher à l'achat.

La solution libre et gratuite me semble difficilement possible. Il suffit de voir qu'aucune distribution purement communautaire gratuite pour x86 n'arrive à gérer une maintenance de plus de 5 ans. Pourtant la plateforme est plus simple et plus standard. Donc aller au delà me paraît difficile. Car ce n'est pas une tâche aisée, ni très passionnante. Il faut en effet du savoir faire du matériel et beaucoup de temps.

Après bien entendu, les constructeurs ont leur part à jouer, en s'impliquant d'avantage dans le noyau officiel (qui pourrait lui également avoir une politique plus adaptée à ces besoins, en ayant une API interne plus stable). Il faut également réduire la surface d'attaque au maximum, n'offrir l'accès au réseau que lorsque la plus valu est réelle. Ce genre de décisions aideraient à avoir une meilleure sécurité dans le temps de ces plateformes.

mar., 14/11/2017

Publication de Fedora 27 !

En ce mardi 14 novembre 2017, le projet Fedora est fier d’annoncer la sortie de la distribution GNU/Linux Fedora 27.

Cette version de Fedora s'est surtout concentrée sur trois axes : couche graphique, gestion du matériel et Fedora.next.

À noter que pour gagner du temps et des ressources, c'est la première version de Fedora n'ayant pas eu de version Alpha. Cela a été rendu possible grâce à l'amélioration des procédures de qualité pour les versions en développements.

GNOME-Bureau.png

Couche graphique

GNOME est toujours à l'honneur avec sa version 3.26. C'est une version essentiellement de polissage et de stabilité avec :

  • La barre principale qui devient transparente, si aucune fenêtre n'est maximisée ;
  • De nouvelles animations, plus fluides, en cas de redimensionnement ou de mouvement des fenêtres ;
  • La recherche globale fonctionne sur des actions du système (comme Éteindre) et affiche plus de résultats à la fois ;
  • Les paramètres du système bénéficient d'une refonte complète de l'interface ;
  • Le logiciel Disques peut enfin redimensionner les partitions, Agenda prenant en charge les évènements récurrents et Web acceptant la synchronisation depuis Firefox Sync ;
  • Le logiciel de virtualisation Machines peut télécharger et lancer automatiquement une RHEL gratuite ;
  • Amélioration des performances pour quelques applications ou GNOME en général.

Remplacement de l'interface graphique de gestion de paquets Yumex par dnfdragora qui propose une interface Qt, GTK+ et ncurses. Le développement de Yumex s'est arrêté il y a un an, qui met fin à une application ayant accompli dix ans de bons et loyaux services et a même su migrer de yum vers dnf. dnfdragora présente la particularité de reposer sur rpmdragora, qui vient de Mageia.

dnfdragora.png

Gestion du matériel

Fedora propose une image unique pour l'architecture AARCH64 (ARM 64 bits) ce qui rejoint la solution proposée pour les cartes disposant d'un ARMv7. Pour l'instant cette image prendra en charge les cartes suivantes :

  • Pine64 (et ses variantes)
  • Raspberry Pi 3 (64 bit mode)
  • 96boards HiKey
  • 96boards Dragonboard 410c
  • ARM Juno

L'offre des cartes prises en charge s'étoffera dans le temps, de même que la mise à disposition des versions personnalisées de Fedora.

Toujours à propos du matériel, Fedora a travaillé pour avoir une meilleure gestion des SoC Intel Bay Trail et Cherry Trail (essentiellement des puces Pentium, Celeron et Atom sur portables et tablettes). Le travail a consisté en l'amélioration de la surveillance de la batterie (consommation actuelle, temps restant sur batterie, savoir si la machine est en charge ou non) et de la gestion de l'audio. Les écrans tactiles et les accéléromètres seront également mieux détectés et donc exploitables par le système et les applications.

Fedora 27 peut enfin tourner sur les ordinateurs ayant un UEFI 32 bits tout en ayant un CPU 64 bits. Cela consiste en l'installation d'un GRUB 32 bits (chargé par l'UEFI lui même) qui lui même charge un noyau et l'espace utilisateur en 64 bits. Cette configuration, assez atypique, a nécessité un travail sur GRUB, Anaconda et les utilitaires EFI pour les prendre en charge. Fedora sera ainsi installable sur ces configurations comme l'Asus Transformer T100TA, le HP Stream 7, le Dell Venue 8 Pro 5830 et les premiers Macintosh Intel d'Apple.

GNOME-Paametres.png

Fedora.next

Séparation du Base Runtime en Plateforme et Hôte, le premier prenant en charge l'espace utilisateur et la base du système quand le second s'occupe uniquement de la gestion du matériel. En somme, la seconde partie contient le noyau, le chargeur de démarrage, les firmwares et quelques pilotes. Dans le cadre de la modularité, le but de ce changement est de découpler la gestion du matériel du reste du système pour proposer des cycles de vie différents et autonomes. L'utilisateur pourra ainsi bénéficier de plus de souplesse, comme avoir la dernière version du support du matériel avec le reste de Fedora un peu plus ancien et inversement. À terme, on pourrait avoir une sorte de gestion de matériel fournie par Fedora 27 avec un espace utilisateur fourni par Fedora 28. Ou inversement selon le cas d'usage.

L'édition Fedora Server reçoit les premiers travaux officiels pour gérer la modularité, alors qu'elle a été testée par l'édition spéciale Boltron lors de Fedora 26. L'objectif est de mettre en place la modularité dans une image officielle de Fedora et non annexe comme l'a été Boltron. Cela permettra aux administrateurs systèmes de prendre en main le projet de manière plus large pour bénéficier d'un maximum de retours. Il sera également possible de voir le comportement de la modularité durant le cycle de vie complet de Fedora 27.

Comme pour Fedora 26, je vous invite à consulter la documentation de la modularité et leur chaine Youtube pour en apprendre plus à ce sujet. À cause de ce changement important, l'édition Server sera disponible un mois après les autres éditions.

Et comme d'habitude, Fedora 27 réserve bien d'autres surprises à découvrir.

La communauté francophone

L'association

Logo.png

Borsalinux-fr est l'association qui gère la promotion de Fedora dans l'espace francophone. Nous constatons depuis quelques années une baisse progressive des membres à jour de cotisation et de volontaires pour prendre en main les activités dévolues à l'association.

Nous lançons donc un appel à nous rejoindre afin de nous aider.

L'association est en effet propriétaire du site officiel de la communauté francophone de Fedora, organise des évènements promotionnels comme les Rencontres Fedora régulièrement et participe à l'ensemble des évènements majeurs concernant le libre à travers la France principalement.

Si vous aimez Fedora, et que vous souhaitez que notre action perdure, vous pouvez :

  • Adhérer à l'association : les cotisations nous aident à produire des goodies, à nous déplacer pour les évènements, à payer le matériel ;
  • Participer sur le forum, les listes de diffusion, à la réfection de la documentation, représenter l'association sur différents évènements francophones ;
  • Concevoir des goodies ;
  • Organiser des évènements type Rencontres Fedora dans votre ville.

Nous serions ravis de vous accueillir et de vous aider dans vos démarches. Toute contribution, même minime, est appréciée.

Si vous souhaitez avoir un aperçu de notre activité, vous pouvez participer à nos réunions hebdomadaires chaque lundi soir à 20h30 (heure de Paris) sur IRC (canal #fedora-meeting-1 sur Freenode).

La documentation

Depuis juin 2017, un grand travail de nettoyage a été entrepris sur la documentation francophone de Fedora, pour rattraper les 5 années de retard accumulées sur le sujet.

Le moindre que l'on puisse dire, c'est que le travail abattu est important : près d'une cinquantaine d'articles corrigés et remis au goût du jour. Un grand merci à Charles-Antoine Couret, Nicolas Berrehouc, Édouard Duliège et les autres contributeurs et relecteurs pour leurs contributions.

L'équipe se réunit tous les lundis soir après 21h (heure de Paris) sur IRC (canal #fedora-doc-fr sur Freenode) pour faire progresser la documentation par un travail collaboratif. Le reste de la semaine cela se passe sur les listes de diffusion.

Si vous avez des idées d'articles ou de corrections à effectuer, que vous avez une compétence technique à retransmettre, n'hésitez pas à participer.

Liens

dim., 22/10/2017

Changement de pâte thermique sur mon ordinateur portable

Il y a parfois des tâches d'entretien d'un ordinateur qu'on oublie de faire et qui pourtant sont essentielles.

Le changement de pâte thermique en fait parti. La pâte thermique est ce qui permet d'améliorer la conductivité thermique entre le processeur (ou le GPU) et le radiateur dédié à évacuer cette chaleur. Il permet de gommer les aspérités des deux surfaces pour augmenter la surface de contact et éviter la présence d'air qui est un bon isolant.

Mais la pâte thermique n'est efficace que quelques années, ensuite il commence à se fissurer, à se décoller et donc à ne plus remplir correctement sa fonction. Il est nécessaire de le remplacer.

Mon ordinateur est un HP Elitebook 8560w qui vient de fêter ses 6 ans d'utilisation. Depuis quelques semaines / mois, la température était constamment entre 80 et 100°C, même si je ne faisais rien de particulier. C'est bien trop chaud. Du coup le processeur se mettait en économie d'énergie pour éviter la surchauffe ce qui dégradait les performances.

Je me suis décidé à régler le problème, ne prévoyant pas de changer de machine avant quelques mois.

Matériel

Coût total, moins de 30€.

En effet, ma machine possède beaucoup de vis Torx, puis pour éviter d'abimer la machine j'ai préféré avoir un outil très fin pour séparer les éléments et avoir de quoi gratter la pâte thermique. D'où l'achat des deux sets qui permettent globalement de démonter pas mal de machines en théorie.

Une petite pince est assez appréciable pour manipuler les petits connecteurs.

Opérations

Avant de commencer, pour éviter de faire des erreurs, j'ai préféré consulter une vidéo du démontage avant.

Comme beaucoup d'ordinateurs portables, accéder à la carte graphique et au processeur n'est pas évident. Il faut pratiquement tout retirer de la partie basse de la machine : clavier, touchpad, disque dur, lecteur CD... En fait il ne reste qu'une partie du châssis et la carte mère.

On retire donc l'ensemble du module de refroidissement qui est commun pour le processeur et la carte graphique. En effet, chacun a son radiateur qui communique la chaleur à un ventilateur et à un radiateur externe commun. Cela rend l'opération un peu plus pénible.

Vous pouvez voir le module démonté :

IMG-20171020-WA0001.jpg

Et la carte mère, avec le CPU sur la gauche, la carte graphique sur la droite :

IMG-20171020-WA0000.jpg

Bien entendu il faut ensuite tout remonter, sans se planter sur les vis. Essayer de bien réintégrer les éléments (ce dont j'ai échoué la première fois, notamment le connecteur pour les touches de la souris qui n'a pas été bien enfiché). Allumer la bête et tester que tout va bien. Et ouf tout fonctionne.

Résultats

Maintenant mon ordinateur au repos fonctionne entre 60 et 80°C. Les 100°C ne sont atteints que lors d'une activité intensive. C'est quand même bien plus sympa, à l'usage j'ai moins de ralentissements, l'utiliser sur les genoux est possible sans se brûler.

Pour un peu moins de 30€ et près de 3h à s'en occuper le résultat est très appréciable. N'hésitez pas à le faire si votre machine chauffe trop (et si bricoller un peu ne vous fait pas peur). ;-)

mar., 17/10/2017

Un processeur qui perd le nord

Retour trois années en arrière quand je me penchais sur la gestion du stockage de masse d'un projet professionnel. C'est toujours avec le fameux processeur 8148 de Texas Instrument, le même projet que pour l'épisode 1.

Le stockage de masse est assuré par une mémoire flash NOR. En réalité l'implémentation n'était pas le principal problème, je vais raconter à nouveau un bogue assez délicat à identifier.

Mais d'abord, contexte !

Contexte

Choix de la mémoire

Donc sur ce projet, comme tout projet avec un système embarqué, se pose la question du stockage du système d'exploitation, des données et de comment charger le tout.

Il y a en général plusieurs possibilités pour un tel système : une mémoire NAND, NOR, une carte SD, une mémoire eMMC (une carte SD soudée), une clé USB voire via Internet. Bien entendu, chaque support a son lot d'avantages et inconvénients, voici pourquoi le NOR a été choisi :

  • Il est très fiable sur la durée (bien plus que les flashs NAND ou les mémoires SD/eMMC) ;
  • Sa lenteur n'était pas impactant pour notre système (c'est en effet de tous la méthode d'accès la plus lente) ;
  • Son espace de stockage (256 Mio) pour son prix était suffisant, sachant que la NOR est plus cher au Gio que les autres dispositifs ;
  • Il est possible d'exécuter le système en place (c'est le mécanisme XIP pour eXecute In Place) ce qui économise de la RAM et simplifie la conception.

Le dernier point est une propriété intéressante. En fait le processeur est capable d'adresser directement dans la mémoire NOR, les instructions machine du genre exécuter la fonction de cette adresse n'a pas besoin d'être chargé en RAM, le processeur peut accéder à cette adresse depuis la NOR et exécuter la dite fonction sans charger le code au préalable.

Préparation

Cependant, la dite technique XIP nécessite d'être précautionneux. Tout d'abord, le processeur au départ n'a pas accès à tout l'espace de stockage que propose notre mémoire.

Car dans le monde ARM (ce qui suit reste plus ou moins valable avec d'autres architectures, potentiellement avec d'autres noms), quand nous appuyons sur le bouton d'alimentation de la carte, l'alimentation démarre le processeur qui lance un petit chargeur de démarrage située dans sa ROM et qui a été conçu par le fabricant de la puce, ici Texas Instrument. Il va initialiser le minimum nécessaire dans le SoC et essayer de charger du code depuis un espace de stockage (notre mémoire NOR bien entendu ici, mais cela peut être par Ethernet, USB, mémoire NAND, carte SD ou autre). Dans notre cas, nous avons configuré (matériellement, en mettant des pins du processeur à 1 et d'autres à 0) de sorte que ce chargeur de démarrage cherche notre système sur la carte SD (car durant le développement, nous avons une carte SD), et si rien n'est trouvé, charger depuis la NOR.

Ce sont des mécanismes assez simples derrière. Pour le démarrage SD, le processeur détecte si une carte est présente, essaye de trouver un fichier nommé MLO dans un système de fichier FAT de la première partition pour le charger. Pour la NOR, il vérifie si les 4 premiers octets (situés à l'adresse 0x08000000) sont non nuls (donc différents de 0xFFFFFFFF ou 0x00000000). Si le chargement est effectué mais que cela n'aboutit sur rien, le processeur sera bloqué. Donc il faut veiller à charger quelque chose de correct.

Et pour charger le code initial (dans notre cas notre propre chargeur de démarrage U-boot, qui chargera Linux, qui chargera le reste des applications), le chargeur de démarrage de Texas Instrument n'a pas besoin de tout charger. Essentiellement car c'est plus simple, mais aussi parce que c'est plus générique, toute mémoire NOR pourra être chargée à priori quelque soit sa taille réelle.

Donc il ne charge que les 4 premiers kiloctets disponibles. Ces premières instructions de U-boot vont servir principalement à initialiser le nécessaire pour accéder au reste de la mémoire NOR, initialiser également la pile, la vitesse du processeur, etc.

C'est pour cela que nous avons le code suivant situé dans les 4 premiers kiloctets. Puis il y a une subtilité technique à prendre en compte. Nous allons changer les paramètres d'accès à la mémoire NOR. Cela se fait par l'écriture sur 7 registres différents dans le processeur. Non seulement nous allons dire au processeur d'activer des lignes d'adresses supplémentaires (permettant l'accès à toute la mémoire disponible), mais en plus nous allons modifier la vitesse d'accès pour améliorer les performances globales.

Les paramètres d'accès à la NOR sont situés dans les registres GPMC (adresses 0x51000060 à 0x51000078). Nous pouvons indiquer au processeur, pour chaque caractéristique du signal pour dialoguer avec la NOR, le nombre de cycles d'horloge nécessaires. Ces valeurs dépendent donc de la vitesse d'un cycle d'horloge et des caractéristiques de la mémoire NOR.

Attention, quand je parle de la vitesse d'un cycle d'horloge, ce n'est pas directement celui du processeur lui même. En général au sein d'un circuit, il y a une chaîne d'horloge qui se met en place pour alimenter chaque sous-système avec une vitesse qui lui convient. Ainsi le réseau, le multimédia, l'USB, le PCIe ou le processeur lui même ont des horloges propres. Ces horloges sont construits à partir de quartz qui générèrent un signal entre 15 et 25 MHz. Ensuite une PLL va amplifier ce signal pour moduler sa vitesse afin d'atteindre parfois plusieurs GHz. Dans notre cas, le quartz OSC0 (à 20 MHz) alimente la DPLL L3 (jusqu'à 220 MHz) qui alimente l'horloge GPMC qui divise par quatre le signal précédent (jusqu'à 55 MHz donc). Je ferais sans doute un article complet sur le sujet des horloges. :-)

Et comme nous allons changer la vitesse d'accès à la mémoire, alors que nous exécutons le code depuis la NOR elle même, vous pouvez deviner un problème. Entre le changement du premier et du dernier registre, les temps d'accès à la NOR ne seront plus cohérents, le système va se bloquer faute de pouvoir lire les instructions suivantes. Du coup il est nécessaire de copier le bout de code qui fait ce changement dans la SRAM (une petite zone de mémoire interne au processeur à l'adresse 0x40400000, qui n'est pas impactée par nos changements) afin de l'exécuter depuis celle-ci avant de revenir exécuter le code dans la NOR une fois l'opération faite.

Cela est fait via les lignes suivantes (l'essentiel du code employé provient du code de Texas Instrument qu'il a fallu adapter à notre cas) :

 /**************************************************************************
  * cpy_nor_gpmc_code: relocates nor gpmc init code into ocmc0 where its
  * safer to execute
  * R2 is loaded wtih size of data to be copied, this should be calculated
  * if we are modifying nor_gpmc_init()
  *************************************************************************/
 .global cpy_nor_gpmc_code
 cpy_nor_gpmc_code:
         stmfd sp!, {r0 - r10}
         /* Copy NOR GPMC init code into SRAM */
         adr r0, nor_gpmc_init     /* get addr of nor gpmc init code */
         mov r2, #640    /* r2 <- copy size(% by 32 bytes:r3-r10 (8) regs used) */
         ldr r1, sram_pc_start     /* r1 <- dest address (passed in) */
         add r2, r2, r0      /* r2 <- source end address */
 next2:
         ldmia   r0!, {r3 - r10}     /* copy from source address r0 */
         stmia   r1!, {r3 - r10}     /* copy to   target address r1 */
         cmp r0, r2          /* until source end address r2 */
         bne next2
         ldmfd sp!, {r0 - r10}
         mov pc, lr          /* back to caller */

Ce code fonctionne comme attendu, les premières cartes venant de la série A fonctionnent tous sans encombres.

Les problèmes arrivent

Quelques mois plus tard, un second jeu de cartes électroniques arrive avec une révision matérielle pour corriger les premiers défauts relevés. Et au bout de quelques heures, nous détectons un problème fondamental : sur certaines de ces cartes, le démarrage depuis la NOR ne fonctionne pas du tout, sur d'autres c'est aléatoire (de 1 fois sur 2 à 1 fois sur 100) et sur un exemplaire, aucun problème.

C'est pourtant, à ce stade, le même code qui est exécuté que sur les premières cartes qui ne bronchent toujours pas dans cet exercice. Notons également que sur ces nouvelles cartes, le démarrage depuis une carte SD ne pose aucun problème. D'ailleurs charger U-boot depuis la carte SD et le reste depuis la NOR ne présente aucun problème non plus.

La première piste est évidemment de vérifier tous mes calculs pour les registres d'accès à la NOR. Nous tombons tous d'accord sur le fait que ces valeurs sont correctes. Nous vérifions également l'ensemble des changements matériels autour du processeur et de la NOR et il n'y a rien. Tout au mieux, le responsable du routage de la carte (celui qui est responsable de transformer les liaisons logiques entre les composants en un circuit avec les pistes dessinées sur le plan final) note une différence de quelques micro/millimètres sur la longueur de ces fils entre les deux versions.

Mais rien de très intéressant, le module n'a pas beaucoup bougé sur ces fonctions et pourtant, le comportement est aléatoire. Nous prenons donc la JTAG pour en savoir plus afin de voir à quel endroit le démarrage échoue. Sur la plupart des modèles, cela tourne autour des registres du Watchdog. Mais si on supprime cette section du code, cela apparaît plus loin. Il semble donc que les échecs se produisent autour d'un certain nombre d'instructions constant depuis le démarrage plutôt que sur une instruction particulière. La JTAG nous montre que à l'instruction de trop, il va charger l'instruction suivante à une adresse délirante avant de retomber sur le vecteur d'exceptions du processeur pour avoir accédé dans une zone mémoire invalide.

Pour essayer d'identifier la cause de l'échec, le concepteur de la carte prend son oscilloscope à bras le corps et fait les mesures pendant que j'exécute le logiciel avec la JTAG pas à pas. Il semble que par moment le processeur fasse des signaux d'accès à la NOR d'environ 10 nanosecondes (oui, nanosecondes) trop courts. Pourtant les valeurs des registres que nous avons indiqué sont bons.

La solution

Une première solution est d'abaisser significativement les performances d'accès à la NOR et cela semble fonctionner. Mais si la NOR n'était pas un soucis niveau performances, nous avons une exigence contractuelle de démarrer l'ensemble du système en moins d'une minute. Et avec ces réglages, ce n'était plus possible. Puis nous ne comprenons toujours pas la cause du problème ce qui est gênant.

Il me faudra près d'une semaine de recherche dans la documentation de Texas Instrument pour comprendre la cause du problème et ainsi comment le résoudre. Je tombe en effet sur l'information suivante (page 1027 du document technique de référence) :

Horloge-boot-NOR.png

Or, si on prend le document de référence condensé page 183, on a :

Horloge-OPP.png

Vous ne voyez pas ? Il y a pourtant une incohérence pour une source d'horloge : la DPLL L3 qui est pour l'OPP 100 de 220 MHz et de l'autre de 200 MHz.

Or, tous mes calculs ont été conçus pour un signal d'entrée de 50 MHz et non de 55 MHz, ce qui donne un temps d'accès par cycle respectivement de 18 à 20 nanosecondes, soit bien sûr 2 nanosecondes d'écart. Quand on sait que la quasi-totalité de la configuration du signal d'accès tourne autour de 4 à 6 cycles par élément du signal, on retombe sur les 10 nanosecondes environ plus court constatés plus haut.

En quoi la documentation / implémentation de Texas Instrument est étrange ? En fait il faut expliquer brièvement ce qu'est un OPP. Un OPP pour OPerating Point est une méthode pour gérer l'énergie. Il consiste à fixer les fréquences maximales des différentes horloges du système par rapport à la tension d'alimentation du processeur. Plus le processeur consomme d'énergie (avec une tension élevée), plus les fréquences peuvent être élevées, mais plus la température peut monter également. En général on utilise le terme Dynamic Voltage Frequency Scaling pour décrire ce mécanisme.

Ce qui est curieux est que lors du démarrage NOR, par défaut, la ROM de Texas Instrument utilise l'OPP100 (celui de base) pour toutes les fréquences... sauf la L3 dont on se sert où c'est un OPP120 qui est employé. Cela n'est pas très cohérent comme choix et c'est ce qui nous a induit en erreur dans les calculs. Dans notre cas, pour éviter d'avoir besoin d'une ventilation active de la chaleur, nous souhaitons avoir une OPP100 durant le fonctionnement de l'appareil.

Pourquoi ce caractère aléatoire ?

Jusqu'ici j'ai expliqué le cadre général, l'origine du bogue a été trouvée, mais je n'ai pas expliqué pourquoi sur certaines cartes cela fonctionne, d'autres pas. Pourtant le code et le problème devrait se manifester partout.

Tout d'abord le démarrage SD fonctionne car dans U-boot, je changeais manuellement la fréquence des différentes horloges pour fixer le tout à l'OPP100 (et pour démarrer certaines horloges pour le processeur multimédia dont j'ai parlé dans le précédent article, chose qui n'est pas fait par le chargeur de démarrage de Texas Instrument). Du coup je supprimais le problème dans ce cas.

Le caractère aléatoire vient des différences minimes entre les différentes cartes. Comme je l'ai dit plus haut, les nouveaux modèles étaient plus sensibles à cause de la longueur des pistes qui avait changé, mais aussi parce que les composants ne sont pas identiques (numéros de série différentes, modèles différents pour les quartz, etc.). Étant donné la différence minime dans les temps d'accès, ces variations mineurs en temps normal peuvent avoir des impacts importants sur la longue.

D'autant que je changeais les fréquences d'horloge peu après la configuration du GPMC. Du coup, certains modèles avaient parfois la possibilité de régler le problème en abaissant la fréquence d'horloge finale en accédant à ces instructions à temps et sans encombre, d'autres pas.

Conclusion

Nous avons pu voir un problème qui survient parfois dans le domaine, des cartes qui se comportent différemment. Cela montre la nécessité de tester chaque modèle même si à priori c'est le même code, le même circuit. Chaque carte est unique. Il est nécessaire de documenter au maximum les petits changements qui peuvent être opérés. une collaboration forte entre l'équipe matérielle et logicielle est également fondamentale, il est probable que la cause n'aurait pas été retrouvée si vite sans cela. Chaque équipe ayant pu apporter des informations cruciales dans la résolution du problème.

Ensuite, bien entendu, la lecture de la documentation est importante, il faut tout vérifier, tout contrôler. Même ce qui paraît évident / logique. Il aurait été aussi appréciable que Texas Instrument choisisse une voie de moindre surprise en adoptant un choix cohérent dans les valeurs initiales de ses fréquences.

Et j'espère que vous aurez appris au sujet du démarrage sur les plateformes ARM et de la gestion des horloges. :)

mer., 11/10/2017

Participez à la journée de test consacrée à la mise à niveau vers F27

Aujourd'hui, ce mercredi 11 octobre, est une journée dédiée à un test précis : sur la mise à niveau de Fedora vers le futur Fedora 27. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.

Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

En quoi consiste ce test ?

Nous sommes proches de la diffusion de Fedora 27 final (prévu pour début novembre). Et pour que ce lancement soit un succès, il est nécessaire de s'assurer que le mécanisme de mise à niveau fonctionne correctement. C'est-à-dire que votre Fedora 25 ou 26 devienne Fedora 27 sans réinstallation, en conservant vos documents, vos paramètres et vos programmes. Une très grosse mise à jour en somme.

Les tests du jour couvrent :

  • Mise à niveau depuis Fedora 25 ou 26, avec un système chiffré ou non ;
  • Même que précédemment mais avec KDE comme environnement ;
  • De même avec la version Server ou Minimal au lieu de Workstation ;
  • En utilisant GNOME Logiciels plutôt que dnf.

En effet, Fedora propose depuis quelques temps déjà la possibilité de faire la mise à niveau graphiquement avec GNOME Logiciels et en ligne de commande avec dnf. Dans les deux cas le téléchargement se fait en utilisation normale de votre ordinateur, une fois que ce sera prêt l'installation se déroulera lors du redémarrage.

Pour ceux qui veulent bénéficier de F27 avant sa sortie officielle, profitez-en pour réaliser ce test, que cette expérience bénéficie à tout le monde. :-)

Personnellement j'ai déjà testé un peu en avance sur ma machine professionnelle et j'ai rapporté mon premier bogue bloquant pour Fedora. En effet, dnf plantait lors du redémarrage pour procéder à l'installation des nouveaux paquets. Mais ayant eu lieu en début de procédure, cela n'a pas d'effet négatif. Bogue très courant apparemment pour l'instant mais dont un correctif est en test.

Comment y participer ?

Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.

Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de faire un tour sur IRC pour recevoir un coup de main sur les canaux #fedora-test-day et #fedora-fr (respectivement en anglais et en français) sur le serveur Freenode.

En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

mar., 10/10/2017

Une erreur… bien cachée

J'avais dit que je parlerais un peu des systèmes embarqués et de mes aventures dans le milieu. Aujourd'hui je voudrais relater un problème que j'avais dû résoudre au travail et qui n'était pas évident. Le prochain article sera plus générique (et celui d'après à propos d'un autre problème au boulot). Je vais essayer de varier un peu. ;-)

Ce sera sûrement un peu long, et je vais donner mon cheminement intellectuel autour de ce problème. Je respecte la chronologie des éléments dont j'avais connaissance à chaque étape.

Présentation du matériel et contexte

Pour situer un peu, je travaillais sur une plateforme Texas Instrument 8148 qui est un processeur ARM Cortex-A8 couplé avec un processeur M3 et des accélérateurs vidéos / DSP en son sein. Cette plateforme exploitait un noyau Linux 2.6.37 patchée à mort par Texas Instrument pour son processeur.

Le but du jour était d'exploiter le composant TVP5158 de… Texas Instrument encore (ce module a été conçu pour ce processeur en même temps). Pour décrire rapidement, ce composant permet de fusionner jusqu'à 4 flux vidéo analogiques (PAL / NTSC principalement) dans un seul numérisé que le processeur peut exploiter.

En soit le composant avait déjà un pilote fonctionnel pour Linux. Mais cela ne nous convenait pas. En effet, nous utilisons le TVP dans une chaîne de traitement vidéo où on faisait des décodages, redimensionnements, des remplacements d'images ou encore des encodages. Pour faire cela, non seulement il faut de la performance mais il faut aussi utiliser une API plutôt unifiée.

La performance est offerte par les accélérateurs vidéos qui sont dans les co-processeurs du système. On peut les exploiter via un firmware (dont le code source est confidentiel, désolé) et on peut communiquer avec ces accélérateurs via le noyau Linux et l'API OpenMax (OMX). Cette API est standard, éditée par le même groupe et dans les mêmes conditions qu'OpenGL, mais plutôt que de s'occuper de la 3D, il s'occupe des codecs vidéos. C'est souvent la référence libre dans ce domaine, avec GStreamer couplé avec libav.

Cette API est disponible dans le firmware de TI, cela tombe bien. Mais là où cela ce corse c'est pour récupérer des informations. En effet, il faut que durant notre traitement vidéo que nous sachions la résolution détectée par TVP du flux vidéo, et s'il existe (sur les 4 flux, des caméras peuvent être en pannes ou absentes pour diverses raisons).

Et TVP se configure via un bus assez standard et typique I2C qui est assez simple à mettre en place et largement suffisant pour lire / écrire des registres sur un composant. Il est par exemple souvent utilisé dans les cartes mères / graphiques de nos ordinateurs pour les capteurs de températures. Le soucis est que ce bus ne peut être géré par le firmware de TI (pour configurer le flux) et par le noyau Linux (pour récupérer les infos sur le flux pour l'application). Si on fait cela, il y aura conflit et le bus sera inutilisable. Modifier le firmware pour renvoyer les informations à l'espace utilisateur ou que le noyau gère la configuration du flux vidéo est plutôt complexe. Le mieux est d'utiliser un canal de communication existant entre le noyau et le firmware pour faire ceci, le firmware a donc la main sur le bus I2C et le noyau fera ses requêtes a travers lui.

On code

Partie intéressant du travail, coder. Et réfléchir à comment faire aller / revenir les informations voulues. Le noyau et le firmware, comme dans la quasi-totalité des systèmes à processeurs asymétriques, communiquent entre eux par mémoire partagée. Une partie de la RAM est allouée pour les messages, une autre pour les buffers vidéos, etc. Ceci est configurable (avec des limites) dans le code des deux côtés. Bien évidemment, les deux doivent être d'accord sur les adresses de base de chaque fonction, sinon ils ne retrouveront plus leurs petits. Cela est plutôt bien pris en charge par l'environnement de compilation fourni par TI. Vous pouvez consulter l'adressage mémoire entre les deux ici.

Dm8148-ezsdk-sw-arch.png

Bon, et le code alors ? La communication entre ces deux modules se faisant par mémoire partagée, il y a un certain protocole qui a été conçu par TI et qui s'exploite à travers une API maison nommée FVID2. Elle est déjà partiellement implémentée mais pas celle concernant le fameux TVP (qui est pourtant décrite dans l'API en question). J'ai donc écrit un pilote Linux pour combler cela. Aspect amusant, TI à la pointe de la technologie fournissait la doc de cette API dans un document .chm, un vieux format propriétaire dont le seul lecteur sous Linux potable est une application de l'ère de KDE3 : Kchmviewer. Quand je vous dis que l'embarqué c'est moderne !

Mais cela reste un peu moche, l'application en espace utilisateur demande au firmware HDVPSS de configurer le TVP. Mais, pour faire cela, il instancie le pilote interne de TVP du firmware qui ne doit pas être instancié deux fois et dont on ne peut récupérer la référence pour notre API FVID2… J'utilise donc une référence d'un autre composant dont le noyau a la référence (car il l'instancie) et j'envoie mes messages avec, le firmware a été modifié pour comprendre la situation et rediriger le message ensuite à bon port. Je n'avais pas trouvé mieux dans le délai imparti.

Et le bogue arrive… parfois

Et après le code, on teste. Après plusieurs essais difficiles, cela fini par passer. Youhou. Champomy dans les bureaux.

Mais, quand mes collègues vont tester leur application avec mon travail, cela ne fonctionne pas toujours. Le module noyau qui fait les échanges avec le coprocesseur nous signifie que certaines requêtes, en quantité variables, mettent trop de temps à revenir. On était à une moyenne de 1 à 10 échecs par minute (pour 24 requêtes). Mais il arrivait malgré tout que sur 30 minutes / 1 heure cela n'arrive pas, avant de revenir. C'est beaucoup trop problématique, et ce qui est étonnant c'est que mes tests ne présentaient aucune erreur.

Du coup, comme pour toute chaine de communication, on va déboguer étape par étape pour identifier où cela coince. Je précise que la seule section dont je pouvais difficilement déboguer c'est l'échange des messages entre Linux et le firmware qui est assez mal documenté et le code assez obscur en plus d'être gros.

Matériel

Le plus simple à tester, c'est le matériel (recompiler le firmware vidéo pour y ajouter du débogue c'est 40 minutes de compilation, c'est pénible et long, on évite au maximum de le faire). Je vérifie donc que le TVP reçoit les bonnes requêtes et y répond. Le bus I2C étant très simple, un petit oscilloscope sur un fil et on peut rapidement conclure que les signaux sont bons dans les deux sens que la requête échoue ou non à la fin.

Mais je me dis que le temps d'attente côté Linux pour recevoir ce message est trop court, je l'allonge volontairement à un délai absurde comme 30 secondes, cela ne change rien. Soit ça réussi vite, soit au bout des 30 secondes j'ai l'erreur. Pas d'entre deux, pas de hausse ou baisse de ces erreurs.

Du coup on sait que la chaîne d'envoi est bonne, et le matériel aussi, le soucis se situe bien au retour.

Firmware vidéo

Donc forcément je remonte un peu la chaîne côté firmware vidéo et à chaque étape en son sein, l'information est correcte à tous les coups. Comme le soucis n'est pas côté Linux après l'API FVID2, le soucis se situe forcément dans le transfert des messages entre les deux mondes comme on dit. Côté retour uniquement.

Plongeons au cœur de la mémoire

À ce stade là, cela devient assez étrange. Comment cela peut planter de cette manière là ? J’émets quelques hypothèses, manque de place pour l'échange de messages (il y a d'autres messages que ceux du TVP là dedans) ou éventuellement un conflit de lecture / écriture simultanée par les deux sur un même message.

Pendant que je cherchais comment l'ensemble fonctionnait, des collègues m'ont rapporté des informations pertinentes (bah oui, ils continuent de testeur leur travail de leur côté et disent ce qui est pertinent quand ils constatent le problème). Il y a une corrélation entre le nombre de caméras branchées au TVP (et exploitées par notre programme) et la fréquence du bogue. Plus il y a avait de caméras, moins cela plantait. Cela paraît contre intuitif.

J'ai maintenant une idée plus claire de ce qui semble être le cas, mais je dois vérifier. J'essaye de voir donc comment l'échange de message fonctionne, et la fonction que j'appelle a quelques lignes intrigantes dont je copie la boucle intéressante :

while (fctrl->fctrlprms->returnvalue == VPS_FVID2_M3_INIT_VALUE) {
       usleep_range(100, 300);
       if (vps_timeout) {
              do_gettimeofday(&etime);
              td = time_diff(stime, etime);
              if (vps_timeout < td) {
                    VPSSERR("contrl event 0x%x timeout\n",  cmd);
                     return -ETIMEDOUT;
               }
        }
}

En gros, Linux initialise une valeur précise à une adresse précise dans la RAM. Quand le firmware a fini son boulot et renvoie les infos demandés, il signifie au noyau qu'il a fini en changeant la valeur initialisée précédemment. Le noyau regarde sa valeur régulièrement par tranches de 100 à 300 microsecondes pendant 2 secondes maximum.

Et comme par hasard, si je mets dans la boucle un printk de débogue (l'équivalent de printf pour le noyau, pour afficher des chaînes de caractères visibles en espace utilisateur, cette fonction est plutôt grosse), le bogue disparaît. Quelques soient les conditions.

Cela me renforce dans mon hypothèse : nous sommes face à un soucis d'accès à la valeur de cette variable. Le noyau Linux relit la variable depuis le cache ou le registre du processeur qui bien sûr ne change pas (car le processeur n'a pas changé cette valeur, c'est au coprocesseur de le faire !), du coup il voit éternellement la variable comme au départ et il croit que le firmware vidéo ne fout rien. Le printk ou l'activité du système (plus il y a de caméras, moins cela arrive, n'oublions pas) permettant à Linux de bien voir la véritable valeur en la rechargeant depuis la RAM.

Le problème vient du fait que ce genre de vérification ne doit pas se faire directement, surtout que la zone mémoire concernée a été allouée avec "ioremap()".

Il suffit donc de remplacer la ligne

 while (fctrl->fctrlprms->returnvalue == VPS_FVID2_M3_INIT_VALUE) {

Par

 while (ioread32(&fctrl->fctrlprms->returnvalue) == VPS_FVID2_M3_INIT_VALUE) {

Les accès par "ioread*()" mettent des barrières mémoires et indiquent que la variable peut être modifiée de l'extérieur. Obligeant donc une nouvelle lecture de la valeur en toute circonstance.

Conclusion

Je suis tombé sur ce bogue après quelques mois dans la vie active seulement. C'était un défi intéressant, je n'avais pas trouvé cela évident. C'est vraiment le genre de choses que l'on a tendance à oublier, on accorde trop de confiances aux couches d'en dessous (matériel / noyau / compilateur / bibliothèque / langage) qu'on en oublie qu'ils peuvent présenter des problèmes et qu'on doit faire attention en les utilisant.

Après, cela met en évidence un énième bogue / oubli stupide de la part de Texas Instrument (ils en font du code horrible, je vous le dis) qui aurait pu être évité s'ils travaillaient un peu plus avec le noyau officiel. Nul doute qu'avec plus de relecteurs de leur code, quelqu'un l'aurait vu. Mais bon, tant pis, je me suis bien amusé. :-)

mar., 03/10/2017

Fedora 27 Beta est disponible !

C'est ce mardi 3 octobre que les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Beta du futur Fedora 27.

Malgré les risques concernant la stabilité d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora 27 et réduisez du même coup le risque de retard. Les versions en développements manquent de testeurs et de retours pour mener à bien leurs buts.

Cette version se distingue par l'absence de version Alpha préalable. Un grand effort sur la qualité a été entrepris pour essayer de se dispenser de cette étape intermédiaire. Et la qualité est en effet au rendez-vous.

Bureautique

  • Mise à jour vers GNOME 3.26.
  • Suppression du script 256term.sh qui changeait la valeur de la variable $TERM pour activer les couleurs dans les terminaux. Maintenant ce sont les émulateurs de terminal qui s'en chargent directement.
  • Fedora propose une image unique pour l'architecture AARCH64 (ARM 64 bits) qui prendra en charge les cartes suivantes : Pine64, Raspberry Pi 3 et 96boards.
  • Une meilleure gestion des SoC Intel Bay Trail et Cherry Trail (essentiellement des Pentium, Celeron et Atom sur portables et tablettes) : meilleure surveillance de la batterie, gestion de l'audio, de l'écran tactile et des accéléromètres.
  • La gestion des ordinateurs ayant un UEFI 32 bits mais un CPU 64 bits. Fedora sera ainsi installable sur ces configurations comme Asus Transformer T100TA, HP Stream 7, Dell Venue 8 Pro 5830 et les premiers Macintosh Intel.
  • Mise à jour de libpinyin vers la version 2.1 pour les entrées de saisi en chinois.
  • La mise à disposition de polices de caractères Serif pour le chinois par défaut.

Administration système

  • Activation de l'option TRIM pour les nouvelles partitions chiffrées avec LUKS1, pour accroître les performances des SSD dans le temps.
  • Nouveau système de cache pour les identifiants Kerberos nommé KCM qui améliore l'expérience utilisateur notamment pour les environnements dans un conteneur applicatif.
  • libcurl réutilise OpenSSL pour la cryptographie et le protocole TLS au lieu de NSS.
  • OpenVPN utilise un nouvel algorithme de cryptographie par défaut qui est AES-256-GCM au lieu de BF-128-CBC améliorant la sécurité des connexions.
  • Le serveur OpenSSH rejoint la politique centralisée des mots de passe, comme le client OpenSSH, GnuTLS, NSS et OpenJDK avant lui.
  • Suppression du protocole SSH-1 dans OpenSSH qui n'était plus sécurisée, ni même supportée officiellement par le projet depuis quelques temps.
  • Installer le paquet perl installera l'ensemble des modules core du projet officiel, ce qui est plus conforme vis à vis des autres distributions.
  • Les paquets officiels ayant besoin de Java n'utiliseront plus le $PATH pour retrouver la JVM mais directement la JVM fournie par défaut par Fedora (OpenJDK). Ainsi, les utilisateurs souhaitant exécuter leurs propres applications avec une autre JVM pourront le faire via la variable $JAVA_HOME.
  • Suppression des paquets krb5-appl-clients et krb5-appl-servers qui ne seront bientôt plus maintenus et ne sont plus assez sécurisés aujourd'hui.
  • Remplacement de l'interface graphique de gestion de paquets Yumex par dnfdragora qui propose une interface Qt, GTK+ et ncurses.
  • Ajout de Samba AD pour la gestion des Active Directory.
  • Mise à jour de RPM à la version 4.14.

Développement

  • La bibliothèque standard Glibc progresse à la version 2.26.
  • La bibliothèque majeure du C++ Boost donne un coup de boost à la version 1.64.
  • Le serveur de rendu de JavaScript Node.js s'exécute à la version 8.6 LTS.
  • La boîte à outils Web Ruby on Rails 5.1 est sur les rails.
  • Le langage Go fonce à la version 1.9.
  • Le langage Perl a été poli à la version 5.26.
  • La nouvelle version de la machine virtuelle OpenJDK danse la Java une 9e fois.
  • Make sudo pip safe again! qui propose enfin un meilleur nettoyage lors de la désinstallation d'un module installé via pip. Les modules sont également installés dans /usr/local.
  • Il est possible d'installer les paquets de débogue (les debuginfo) 32 et 64 bits pour une même application en même temps.
  • Les paquets debuginfos sont scindés en debuginfos et debugsources. Le premier contient les binaires et autres bibliothèques avec les symboles de débogage tandis que les seconds contiennent uniquement le code source du paquet.

La modularité

  • Création des outils dans le cadre de la Factory 2.0 pour permettre le découplage entre la version d'un paquet, la version de rattachement dans Fedora et sa fin de vie.
  • Séparation du Base runtime en Plateforme et Hôte, le premier prenant en charge l'espace utilisateur et la base du système quand le second s'occupe uniquement de la gestion du matériel.
  • L'édition Fedora serveur reçoit les premiers travaux officiels pour gérer la modularité, alors qu'elle a été testée par l'édition spéciale Boltron lors de Fedora 26.
  • Le concept du Python système est revisité et devient le Plateforme Python. L'objectif est de fournir un Python pour les applications systèmes de base comme dnf et rpm (/usr/libexec/platform-python) qui puisse différer de celui des autres applications (/usr/bin/python).

Autour de Fedora

  • Comme annoncé, Fedora n'utilisera plus de version Alpha durant son développement grâce à l'amélioration des outils et des procédure de qualité. Cela bénéficie également à la branche Rawhide.
  • L'utilitaire Bodhi, qui sert notamment au déploiement et aux retours (commentaires + bogues) des mises à jours et des ISO de Fedora, peut prendre en charge les applications Flatpak, OStrees, les images Docker, etc. Ce qui peut faciliter l'amélioration de la qualité de ce genre d'images.

La version finale est pour le moment prévue pour le 9 novembre.

Si l'aventure vous intéresse, les images sont disponibles par Torrent.

Vous pouvez également procéder à une mise à niveau depuis votre Fedora existant, ou télécharger l'ISO depuis un site officiel.

En cas de bogue, n'oubliez pas de relire la documentation pour signaler les anomalies sur le Bugzilla ou de contribuer à la traduction sur Zanata.

Bons tests à tous !

- page 1 de 6