Linux France

S'abonner à flux Linux France
Mis à jour : il y a 13 min 17 sec

iStoa 14.08

Mercredi 20 Août

iStoa est un logiciel pour GNU/Linux proposant des activités mathématiques, le niveau scolaire visé est pour l'instant celui de CP. Le projet est en phase active de développement et propose actuellement une vingtaine de séries d'exercices, le corpus s'étoffe petit à petit pour couvrir à terme toute l'année de CP, puis les suivantes.

Le projet reprend un travail de 2008. Toute la partie modélisation et suivi de l'apprenant est pour le moment mise en veille pour se focaliser sur l'aspect graphique et l'interactivité des activités.

Toutes les activités suivent un même modus operandi : l'apprenant a droit à 3 essais pour résoudre un exercice, iStoa montre les erreurs puis l'utilisateur peut les corriger. En dernier recours, le logiciel corrige l'exercice pour l'apprenant.

Le score de l'utilisateur se construit en regard de son taux de réussite aux activités, il lui est présenté graphiquement sous la forme de médailles, coupes et couronnes, à l'image des performances des sportifs aux jeux olympiques. Enfin le logiciel est multi-utilisateur : nom, avatar, historique des activités et score sont sauvegardés.

 

NdM : Fernandes Hilaires n'en est pas à son coup d'essai, puisqu'il a déjà écrit l'excellent Dr Geo, logiciel pour l'apprentissage interactif de la géométrie.

Télécharger ce contenu au format Epub

Lire les commentaires

CentOS 7 fait son entrée au CERN

Mardi 19 Août

Suite au rapprochement de Red Hat et CentOS en janvier 2014, le CERN a annoncé que CentOS 7 remplacera Scientific Linux 7 comme base de leur distribution maison, qui s’appellera désormais CERN CentOS 7. Scientific Linux est une distribution Linux, principalement maintenue par le CERN et le Fermilab. C'est un clone de Red Hat Enterprise Linux, qui existe depuis 2004.

Les utilisateurs de Scientific Linux 5 et 6 continueront de recevoir les mises à jours comme prévu jusqu'en 2020, mais l'avenir de Scientific Linux 7 est plus incertain : bien que déjà publiée en version Beta, Scientific Linux 7 pourrait finalement être publiée sous une autre forme, à savoir une variante de CentOS, tout comme il existe de nombreuses variantes d'Ubuntu. Mais pour l'instant, aucun communiqué officiel n'a été publié sur le site web de Scientific Linux.

Le CERN utilise RedHat Linux depuis de très nombreuses années pour ses installations. À tel point que lors de la séparation de Red Hat Linux en deux entités (Fedora et Red Hat Enterprise Linux) en 2004, le CERN et ses partenaires créèrent un clone de RHEL, baptisé Scientific Linux, pour continuer à bénéficier d'une distribution stable et maintenue pendant de nombreuses années, sans avoir à payer une licence pour chaque installation.

Dix ans plus tard, avec le rapprochement de CentOS et Red Hat, la raison d'être de Scientific Linux a disparu, et il est très certainement plus productif pour le CERN de contribuer à CentOS plutôt que de continuer à maintenir sa propre distribution Linux.

Télécharger ce contenu au format Epub

Lire les commentaires

Revue de presse de l'April pour la semaine 33 de l'année 2014

Lundi 18 Août

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

[Developpez.com] L'essor de l'open source, une menace pour les logiciels propriétaires?

Par Francis Walter, le vendredi 15 août 2014. Extrait:

Ces derniers temps, beaucoup d'administrations optent pour les solutions open source. Elles ont compris qu'elles peuvent dépenser moins pour les technologies open source et avoir moins de difficulté pour la maintenance et les mises à jour, moins de risque d'espionnage et moins de menaces de cyberattaque. La fin du support de Windows XP par Microsoft serait l'une des sources de motivation des entreprises à pencher vers les solutions libres. Rappelons que la plupart des entreprises, jusqu'à l'abandon de l'OS, utilisaient Windows XP comme système d'exploitation.

Lien vers l'article original: http://www.developpez.com/actu/74136/L-essor-de-l-open-source-une-menace-pour-les-logiciels-proprietaires

[Next INpact] Le ministère du Travail va basculer vers des logiciels de bureautique libres

Par Xavier Berne, le jeudi 14 août 2014. Extrait:

Utilisant depuis 2009 des logiciels de bureautique et de messagerie propriétaires, le ministère du Travail se prépare à basculer vers des logiciels libres de type LibreOffice ou Thunderbird. Ce mouvement va cependant prendre du temps: quatre à six ans selon l’exécutif.

Lien vers l'article original: http://www.nextinpact.com/news/89239-le-ministere-travail-va-basculer-vers-logiciels-bureautique-libres.htm

Et aussi:

Voir aussi:

[The True North Times] Text of Canada-EU Trade Agreement (CETA) Leaked

Par Maxwell Stockton, le jeudi 14 août 2014. Extrait:

(Deux semaines après que l'Allemagne ait laissé entendre son rejet de dispositions au coeur de l'Accord Commercial Canada-Union européenne, ses défenseurs ont probablement pensé que le terrain sur lequel ils avançaient devenait de plus en plus incertain. Hier, il s'est dérobé de sous leurs pieds) Two weeks after Germany hinted at rejecting core provisions of the Canada-EU Trade Agreement (CETA), trade advocates probably thought that the ground they were breaking was shifting uneasily. Yesterday, it fell out from under them.

Lien vers l'article original: http://www.truenorthtimes.ca/2014/08/14/text-canada-eu-trade-agreement-ceta-leaked/

[Village de la Justice] Brevet logiciel: USA = Europe?

Par Laëtitia Le Metayer, le mardi 12 août 2014. Extrait:

Le sujet de la brevetabilité du logiciel n’est pas appréhendé de la même façon en Europe et aux États-Unis. Si le champ de brevetabilité est plus étendu (en principe) aux États-Unis, une décision récente de la Cour suprême US vient restreindre l’admissibilité au brevet pour les procédés informatiques (Alice Corp. V. CLS Bank International).

Lien vers l'article original: http://www.village-justice.com/articles/Brevet-logiciel-USA-Europe,17536.html

[Numerama] Windows XP devrait passer open source, suggère un expert informatique

Par Julien L., le lundi 11 août 2014. Extrait:

Un expert informatique a suggéré lors du Black Hat 2014 que Windows XP devrait devenir open source, puisque Microsoft a renoncé à poursuivre le support de son système d'exploitation. Il propose même que cette règle soit appliquée à l'ensemble des logiciels dont le code source est fermé, ce qui serait positif du point de vue de la sécurité.

Lien vers l'article original: http://www.numerama.com/magazine/30232-windows-xp-devrait-passer-open-source-suggere-un-expert-informatique.html

Télécharger ce contenu au format Epub

Lire les commentaires

Crypto-party estivale au L@Bx (Bègles, Gironde), 22 août 2014

Lundi 18 Août

Vendredi 22 août, c'est cryptoparty toute la soirée / nuit au L@Bx.

Entrée libre et gratuite. Amenez à manger, à boire, sac de couchage pour les plus courageux.

Quelques idées d'ateliers proposés :

  • Créations / échanges de clés GPG
  • Chiffrement de disque dur avec LVM+LUKS, encfs, etc.
  • Mise en place d'un serveur de courriel
  • Traduction du handbook cryptoparty en se basant sur le travail du Tetalab
  • TrollDébat sur la sécurisation des locaux du L@Bx (RFID, caméra, poulet-tueur, etc.)

Pour rappel, le L@Bx est un Hackerspace à Bègles (Communauté Urbaine de Bordeaux). Il ouvre ses portes tous les mardis et vendredis soir.

Au plaisir de vous y croiser !

Télécharger ce contenu au format Epub

Lire les commentaires

m23 rock 14.2 est sorti

Lundi 18 Août

Le projet m23 a publié une nouvelle version du système de déploiement et d'administration de Linux. Ce logiciel libre est disponible sous licence GPL.

m23 vous permet d'installer des machines Linux avec Debian, (X/K)Ubuntu, LinuxMint, Fedora et openSUSE par le réseau, de les mettre à jour, d'y installer du logiciel additionnel, de sauvegarder les clients et le serveur, de grouper les clients, de réaliser des installations de masse, d'intégrer des clients existants et il offre beaucoup de possibilités de configuration. m23 dispose d'une interface web.

La dernière version de m23 étend le spectre des distributions de clients pris en charge par l'ajout du support pour Ubuntu 14.04 LTS et Linux Mint 17 Qiana. Pour Linux Mint, les environnements de bureau Mate, Cinnamon, Xfce et KDE sont disponibles — pour Ubuntu, il y a un bureau minimal de KDE / Kubuntu Desktop, Unity (3D), Xfce, le bureau Lubuntu et Gnome.

Bien que l'ajout du support pour les deux nouvelles distributions — et en particulier des bureaux — soit la principale nouveauté de cette nouvelle version, d'autres améliorations ont également été apportées à m23. Parmi celles-ci, vous trouverez l'amélioration de l'authentification de l'utilisateur par LDAP ou le nouveau framework de test "AutoTest" qui vérifie automatiquement les ISO d'installation du serveur m23.

Pour en savoir plus, visitez le site web du projet m23.

Télécharger ce contenu au format Epub

Lire les commentaires

Rencontre PostgreSQL à Lyon le mercredi 17 septembre

Vendredi 15 Août

Le mercredi 17 septembre de 19h à 22h aura lieu une rencontre autour de PostgreSQL, à l'Antre Autre, au 11 rue Terme à Lyon. Ce sera l'occasion de parler des nouveautés de la version 9.4 du système de gestion de bases de données PostgreSQL, et de son déploiement en environnement à forte charge.

Le reste de la soirée donnera lieu à des discussions informelles sur des sujets divers et variés autour de quelques verres.

Que vous découvriez PostgreSQL ou que vous cherchiez des retours d'expérience sur des utilisations avancés du moteur, vous êtes les bienvenu(e)s.

Pour indiquer votre venue, merci de vous inscrire ou de me faire un retour à cette dépêche.

Télécharger ce contenu au format Epub

Lire les commentaires

scdrand: alimenter le pool d’entropie du noyau à partir d’une carte à puce

Jeudi 14 Août

Possesseur d’une carte OpenPGP, je cherchais un moyen d’exploiter le générateur de nombres aléatoires dont elle est équipée.

Une rapide recherche m’a immédiatement emmené vers TokenTools, qui semble faire exactement ce que je veux. Malheureusement, ce programme ne peut pas cohabiter harmonieusement avec Scdaemon, le démon de GnuPG chargé d’interagir avec les cartes à puce : TokenTools ne peut pas accéder à la carte tant que scdaemon tourne — or j’ai besoin de scdaemon pour l’utilisation routinière de ma carte OpenPGP (signer, déchiffrer, m’authentifier).

La deuxième partie décrit le programme que l'auteur a écrit pour remplacer Token Tools.

Plutôt que d’envisager une alternance fastidieuse entre scdaemon et TokenTools, j’ai donc entrepris d’écrire un petit programme similaire à TokenTools, mais qui accède à la carte par l’intermédiaire de scdaemon plutôt qu’en concurrence de ce dernier.

Voici donc scdrand, un programme qui obtient quelques octets aléatoires (de 1 à 256) à partir d’une carte à puce compatible¹, et qui les utilise pour approvisionner le pool d’entropie du noyau (le pool qui alimente à son tour /dev/random et /dev/urandom).

L’utilisation est supposée être simple, dès l’instant où un agent GPG et scdaemon sont disponibles et en cours d’utilisation (ce qui devrait probablement être le cas si vous êtes déjà utilisateur d’une carte OpenPGP). Par exemple :

$ scdrand 64

Demande 64 octets aléatoires à la carte, les fournit au noyau et se termine.

Une utilisation un peu plus poussée est la suivante :

$ scdrand -l -i 2 -t 512 256

Ici, scdrand va vérifier toutes les deux secondes s’il y a au moins 512 bits d’entropie disponible dans le pool du noyau, et dans le cas contraire, approvisionner celui-ci avec 256 octets aléatoires en provenance de la carte.

Pour visualiser l’effet de scdrand, j’ai suivi l’état du pool d’entropie du noyau (nombre de bits d’entropie disponibles, consultable dans /proc/sys/kernel/random/entropy_avail) pendant la génération d’une paire de clefs RSA par GnuPG, d’abord sans, puis avec scdrand.

Comme on peut le voir sur le graphe ci-dessus, la génération d’une paire de clefs vide instantanément le pool d’entropie et le maintient à un niveau très bas tant que la paire n’est pas générée. Sans sources d’entropie supplémentaire (GnuPG conseille à ce moment-là de bouger la souris, de saisir n’importe quoi sur le clavier ou de solliciter les disques durs — ce que je n’ai pas fait pour cet exemple), cela a pris ici une quarantaine de secondes, après quoi le noyau a encore besoin d’une trentaine de secondes pour ramener le pool d’entropie au niveau basal.

La deuxième paire de clefs, générée avec scdrand tournant dans un autre terminal, vide tout aussi le pool d’entropie. Mais cette fois-ci, au bout de deux secondes le pool est réapprovisionné par scdrand. En conséquence, trois secondes suffisent à GnuPG pour générer la paire de clefs, et le pool d’entropie revient à son niveau de base en moins de vingt secondes.

Évidemment, si vous ne passez pas votre temps à créer de nouvelles clefs toutes les cinq minutes, l’intérêt de tout celà est sans doute assez limité… Mais si ça vous intéresse tout de même, le code est là :

¹ La commande GET CHALLENGE permettant la génération de données aléatoires est spécifiée dans le standard ISO 7816-6 et n’est pas spécifique à l’application OpenPGP, donc scdrand devrait pouvoir utiliser d’autres types de carte. Mais je n’ai pu tester qu’avec une carte OpenPGP 2.0.

Télécharger ce contenu au format Epub

Lire les commentaires

FreeBSD 9.3 sort des cartons

Mercredi 13 Août

FreeBSD 9.3 est sorti, mêlant correctifs et nouveautés. La version 9.3 est estampillée Long Term Support (LTS). Elle sera donc supportée pendant deux ans et remplace ainsi la version 9.1, expirant en décembre 2014. Par ailleurs, l'équipe FreeBSD a étendu le support de la version 9.2 à décembre dans un souci de cohérence. En effet, le support pour cette version devait se terminer en septembre 2014 c'est à dire avant la fin de la 9.1.

Mises à jour Pilotes
  • Les trackpads des Macbooks Apple sont désormais gérés.
  • Le pilote KMS pour les cartes Radeon AMD a été ajouté.
  • Les cartes RAID Megaraid Fury sont désormais prises en charge.
Réseau

Quelques améliorations sur les pilotes réseaux ont permis d'ajouter le support de nouvelles puces réseau et de la pile RNDIS au sein de FreeBSD :

  • re: RTL8168G, RTL8168GU et RTL8411B ;
  • bge: BCM5725, BCM57764, BCM57767, BCM57782, BCM57786 et BCM57787 ;
  • bxe: Broadcom NetXtreme II 10Gb PCIe ;
  • run: MediaTek/Ralink RT3593 et DLINK DWA-127 ;
  • qlxgbe: QLogic 8300 series ;
  • urndis: support d'Ethernet en mode RNDIS (partage de connexion USB notamment).
Systèmes de fichiers ZFS
  • Ajout du support de la fonctionnalité de bookmarks. Cette fonctionnalité permet d'ajouter un point de départ dans un instantané ZFS. Ce point de départ sert de référentiel dans l'utilisation d'une commande de type zfs send.
  • Correction de deux kernel panics
  • Correction d'une fuite de mémoire
  • Il est désormais possible de changer la limite des métadonnées du cache ARC à chaud (sysctl vfs.zfs.arc_meta_limit)
EXT4
  • Le système de fichier EXT4 est désormais supporté en lecture.
Sécurité
  • L'équipe de FreeBSD a décidé de ne plus faire confiance aux générateurs de nombres aléatoires matériels. Ils sont désactivés à partir de cette version
  • Plusieurs correctifs de sécurité sur bind, pam et openssl
Logiciels packagés dans cette version

Vous trouverez quelques logiciels intégrés de base dans la distribution:

  • OpenSSH 6.6-p1
  • OpenSSL 0.9.8za
  • Bind 9.9.5
  • Sendmail 8.14.9
Processus de mise à jour

Si vous utilisez actuellement une version plus ancienne de FreeBSD, voici le processus de mise à niveau :

freebsd-update fetch freebsd-update -r 9.3-RELEASE upgrade freebsd-update install reboot freebsd-update install # Si vous utilisez un repository pkg pkg upgrade # Si vous utilisez les ports portmaster -af freebsd-update install Conclusion

FreeBSD nous fournit donc une version LTS qui continue dans la lignée de cette 9e mouture de l'OS. Troisième version de FreeBSD 9, elle poursuit la stabilisation de la branche tout en ajoutant le support matériel que l'on peut attendre après deux ans.

Télécharger ce contenu au format Epub

Lire les commentaires

Livre libre sur la création de jeu avec Blender

Mercredi 13 Août

Flossmanual francophone, qui produit de la documentation libre pour apprendre les logiciels, a sorti vendredi un nouveau livre.

Cette fois, il s'agit d'un manuel sur le moteur de jeu de Blender. Le livre traite de nombreux aspects du logiciel dans la création du jeu avec ce logiciel, aborde systématiquement les options graphiques conjointement aux options offertes par l'API Python. S'il commence par une découverte du moteur de jeu, il n'est cependant pas fait pour de complets débutants, ni avec Blender, ni en programmation. Il a néanmoins un plan progressif qui ne place pas la barre trop haut dès le début.

Ce manuel a été écrit lors d'un libérathon de 5 jours qui s'est déroulé chez F/Lat à Bruxelles. Il a regroupé 14 personnes dont, entre autres, 2 membres de FlossManuals et d'Activdesign, des membres du BlenderClan et graphistes, un développeur du BGE belge qui en a profité pour débugger certains détails importants qui seront portés dans la prochaine version de Blender (liste des auteurs).

Ce manuel, le second sur Blender de Fmfr, a été rendu possible grâce à la participation financière de l'Organisation Internationale de la Francophonie. Une version papier en sera certainement produite à l'avenir s'il y a des demandes expresses.
Les idées ayant été nombreuses et le sujet étant vaste, le livre est encore en train d'évoluer rapidement. Des versions PDF et epub sont cependant déjà téléchargeables, avec la version actuelle, sur le site. Une documentation secondaire serait à l'étude.

Télécharger ce contenu au format Epub

Lire les commentaires

Meetup Python #4 à Nantes le mardi 26 août

Mardi 12 Août

Lors de ce quatrième meetup, nous vous proposerons deux présentations :

  • « Introduction à Django, le framework de développement web pour les perfectionnistes sous pression. »
  • « Écrire du code python selon les règles de l’art. »

Nous aurons le reste de la soirée pour discuter des sujets divers et variés qui vous passionnent et profiter de l’ambiance conviviale qui anime ces premiers meetups.

Que vous soyez expert Python, amateur ou que vous ayez juste envie de découvrir ce langage, vous êtes les bienvenus !

PS : nous avons maintenant un blog http://nantes.afpy.org/

PPS : pour participer à l'organisation, inscrivez-vous à la liste de diffusion

Télécharger ce contenu au format Epub

Lire les commentaires

digiKam 4.2 est disponible

Mardi 12 Août

DigiKam 4.2 est sortie le 5 août dernier. Un an après la dernière dépêche sur digiKam, cette nouvelle version est l'occasion de faire un récapitulatif des nouveautés des versions de ce logiciel sorties dans cette période. Pour rappel, digiKam est un logiciel de gestion d'images qui utilise, entre autres, les bibliothèques KDE. Il est principalement développé par le Français Gilles Caulier.

digiKam 3.4

La version 3.4 est sortie le 6 septembre 2013.

Cette version inclut l'implémentation d'un nouveau cœur pour gérer les outils de maintenance, en particulier pour mieux prendre en charge le multiprocesseur et les CPU multi-cœurs pour accélérer l'exécution.
Quelques bogues ont également été corrigés dans cette version.

digiKam 3.5

La version 3.5 est sortie le 10 octobre 2013. Ce fut une version de maintenance avec la correction de 6 bogues. On pourra néanmoins noter la possibilité de préciser à digiKam que l'on ne veut pas reconnaitre ni taguer les visages lors d'une procédure de reconnaissance faciale.

  • Un nouvel outil dédié à l'organisation hiérarchique des étiquettes. Cette fonctionnalité a été introduite par Veaceslav Munteanu. Il a également travaillé sur les sélections multiples et les multiples glisser-déposer du gestionnaire d'étiquettes et de la vue des étiquettes des barres latérales. Enfin, il a également ajouté la gestion des méta-données des enregistrement des rectangles de visage dans le format Windows Live Photo.
  • Gowtham Ashok a développé un nouvel outil de maintenance dédié à l'analyse de la qualité des images et à l'étiquetage automatique des éléments en utilisant Pick Labels.
  • La barre de miniatures de Showfoto a été portée vers l'architecture modèle/vue de Qt4 dans l'objectif de basculer plus tard vers un code entièrement en Qt5. Ce travail a été réalisé par Mohamed Anwer.
  • L'outil d'import a reçu de nombreuses corrections sur des dysfonctionnements rapportés pour certains depuis 3 ans. Par exemple, le statut indiquant quel élément a déjà été téléchargé depuis l'appareil est de retour. Merci à Teemu Rytilahti et Islam Wazery pour leurs contributions.
  • DigiKam est maintenant entièrement porté vers l'architecture modèle/vue de Qt4 ; les dernières trace des classes Q3Support ont disparu. La dernière partie restante était le Image Editor Canvas qui a été porté par Yiou Wang dans le cadre du GSoC-2013. Dans le futur, le port vers Qt5 sera facile et rapidement fait, lorsque l'API de KDE 5 sera stabilisée et publiée.
  • Prise en charge des CPU multi-cœurs pour plusieurs outils qui requièrent beaucoup de calcul, tels que Sharpen, LocalContrast, Noise Reduction ainsi que tous les outils d'effets visuels.

Les différentes versions bêta ont permis de fermer 181 rapports de bogues avant la sortie de cette version majeure. L'un des bogues soulevé par ʭ☯ semble avoir été corrigé à l'occasion de cette sortie.

digiKam 4.1

La version 4.1 est sortie le 30 juin 2014.

C'est la première version de maintenance depuis la sortie de la version 4.0 ; elle corrige donc beaucoup de bogues : 48 rapports de bogues ont été fermés.
Les corrections et améliorations concernent principalement

  • La gestion des visages a reçu d'énormes améliorations et des corrections pour des problèmes introduits dans la dernière version majeure.
  • La détection et la reconnaissance des visages est maintenant plus robuste et utilisable « en production ».
  • Les icônes pour les vues ont maintenant une nouvelle apparence pour identifier les photos qui ont des informations de géolocalisation, rendant plus facile la recherche d'images possédant des coordonnées GPS.
  • La taille maximum des miniatures de visualisation est maintenant de 512 pixels, contre 256 précédemment, améliorant ainsi leur apparence pour les affichages haute définition.
digiKam 4.2

La version 4.2 est sortie le 5 août 2014. Cette version voit apparaitre une nouvelle vue dans la barre latérale de gauche permettant une recherche rapide des éléments avec les labels assignés. Par ailleurs, la vue en arbre des étiquettes se voit ajouter une nouvelle option lui permettant d'afficher les éléments sans étiquette. Ces améliorations ont été ajoutées par Mohamed Anwer dans le cadre du Google Summer of Code 2014.

19 rapports de bogues ont été fermés pour cette version 4.2. Parmi ceux-ci, plusieurs concernent une stabilisation de la reconnaissance faciale et de l'étiquetage (tag) des visages. L'export vers Flickr a par ailleurs été rétabli. Ce greffon de Kipi ne fonctionnait plus du fait du passage de l'API de Flickr à une version https uniquement.

Télécharger ce contenu au format Epub

Lire les commentaires

Revue de presse de l'April pour la semaine 32 de l'année 2014

Mardi 12 Août

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

[01net.] Black Hat 2014: peut-on encore sauver le cyberespace de ses innombrables failles?

Par Gilbert Kallenborn, le vendredi 8 août 2014. Extrait:

Face à la croissance rapide des vulnérabilités, il faut trouver de nouvelles solutions. Parmi les idées nouvelles qui émergent: le rachat et la publication de toutes les failles ou encore la dépossession des éditeurs de leurs codes source.

Lien vers l'article original: http://www.01net.com/editorial/624902/black-hat-2014-peut-on-encore-sauver-le-cyberespace-de-ses-innombrables-failles

[Next INpact] 687 000 euros de logiciels libres pour le ministère de l’Agriculture en 2013

Par Xavier Berne, le jeudi 7 août 2014. Extrait:

Contrairement à l’idée reçue, logiciel libre n’est pas forcément synonyme de gratuité. Le ministère de l’Agriculture a par exemple dépensé 687 000 euros l’année dernière pour des programmes non privateurs. Pour autant, il a davantage ouvert son portefeuille pour des solutions propriétaires. Explications.

Lien vers l'article original: http://www.nextinpact.com/news/89108-687-000-euros-logiciels-libres-pour-ministere-l-agriculture-en-2013.htm

Et aussi:

Voir aussi:

[Silicon.fr] Skype lâche les utilisateurs de Mac PowerPC

Par David Feugey, le jeudi 7 août 2014. Extrait:

Toutefois, nous pourrions nous attendre à mieux de la part d’un éditeur de logiciels propriétaires. En particulier quand ce dernier n’a pas manqué de souligner mainte et mainte fois son professionnalisme face à la communauté des logiciels libres. Une communauté qui arrive à faire ce que la firme de Redmond ne peut réaliser: maintenir une continuité dans le monde du logiciel.

Lien vers l'article original: http://www.silicon.fr/lobsolescence-programmee-frappe-encore-skype-abandonne-les-utilisateurs-mac-powerpc-96025.html

[Developpez.com] Open source: nouvelle migration en Europe, Turin en Italie adopte Ubuntu et OpenOffice

Par imikado, le jeudi 7 août 2014. Extrait:

Encore une victoire pour l'Open source avec cette nouvelle d'Italie: Turin a décidé de faire un pas vers l’open source en abandonnant l’utilisation des logiciels propriétaires. La localité se donne 1 an et demi pour migrer 8 300 postes sous Ubuntu, avec l’adoption d’Open Office ou LibreOffice comme suite bureautique en lieu et place de Microsoft Office.

Lien vers l'article original: http://www.developpez.com/actu/73972/Open-source-nouvelle-migration-en-Europe-Turin-en-Italie-adopte-Ubuntu-et-OpenOffice

[ouest-france.fr] À Vannes, on sécurise la voiture de demain

Par Patrick Croguennec, le mercredi 6 août 2014. Extrait:

Assistance à la navigation, à la gestion automatique du freinage… Les véhicules ont toujours plus d'informatique. Qu'il faut sécuriser.

Lien vers l'article original: http://www.ouest-france.fr/vannes-securise-la-voiture-de-demain-2747973

[Next INpact] Un début de détente dans la guerre acharnée entre Apple et Samsung

Par Vincent Hermann, le lundi 6 août 2014. Extrait:

Après des années de guerre acharnée, Apple et Samsung ont décidé de déposer partiellement les armes. Les deux entreprises se sont en effet mises d’accord sur l’abandon de l’ensemble des plaintes en cours ailleurs qu’aux États-Unis.

Lien vers l'article original: http://www.nextinpact.com/news/89092-un-debut-detente-dans-guerre-acharnee-entre-apple-et-samsung.htm

[Numerama] Ne dites plus "crowdsourcing" mais "production participative"

Par Julien L., le mardi 5 août 2014. Extrait:

Vous voulez décrire votre activité au sein de Wikipédia ou dans le cadre du développement d'un logiciel libre? Ne dites plus "crowdsourcing" pour expliquer la manière dont ces projets fonctionnent, mais "production participative".

Lien vers l'article original: http://www.numerama.com/magazine/30189-ne-dites-plus-crowdsourcing-mais-production-participative.html

[Les Echos] Chine: après Microsoft, Pékin bannit les logiciels Symantec et Kaspersky de son administration

Par Claude Fouquet, le lundi 4 août 2014. Extrait:

Les deux logiciels de sécurité informatique ne pourront plus être utilisés sur les ordinateurs de l'administration chinoise. Seuls cinq logiciels chinois composent la liste des logiciels officiellement autorisés par les autorités de Pékin.

Lien vers l'article original: http://www.lesechos.fr/tech-medias/hightech/0203683643229-chine-apres-microsoft-pekin-bannit-symantec-et-kaspery-de-son-administration-1030239.php

Et aussi:

Télécharger ce contenu au format Epub

Lire les commentaires

Turin et la Corée du Sud passent au libre

Dimanche 10 Août

Depuis la récente dépêche indiquant l'ouverture de la ville de Toulouse au libre et également des intentions du Royaume-Uni d'utiliser des formats ouverts, c'est au tour de la ville de Turin (en italien) et de la Corée du Sud (en anglais) d'annoncer leur intention de faire migrer leurs ordinateurs sous des logiciels libres.

    Turin

    La ville italienne indique qu'elle a utilisé 22 millions d'euros en dépense informatique durant les 5 dernières années. Cela inclut les licences logiciels, l'achat de nouveau matériel, l'assistance technique et les installations. En utilisant des logiciels libres, la ville espère économiser 6 millions d'euros sur la même période.

    Les employés de la ville auront ainsi l'immense bonheur d'utiliser Mozilla Firefox et Open Office en lieu et place d'Internet Explorer et Microsoft Office. Windows est également remplacé par Ubuntu.

    Le début de la transition est prévu pour cet automne et devrait s'achever un an et demi plus tard.

    Corée du Sud

    Le gouvernement coréen a annoncé fin juin son intention d'utiliser des systèmes d'exploitation libres dans toute son administration d'ici 2020. La date coïncide avec la fin du support de Windows 7. Le gouvernement espère ainsi faire disparaitre sa dépendance vis-à-vis des solutions propriétaires.

    Le plan « Open Source Software Invigoration », établi par des experts du milieu de l'industrie, de l'université et de la recherche, prévoit les points suivants :

    • la possibilité de se connecter à Internet à partir de n'importe quel système d'exploitation et navigateurs Web. Pour cela, la technologie Active X disparaitra de tous les sites internet de l'administration publique au profit de technologie HTML5.
    • les documents publiés par l'administration publique seront distribués en différents formats, dont le PDF mais aussi dans le format propriétaire local, le hwp.

    Pour mener à bien ce projet, 10 institutions publiques et privées testeront ces dispositions. Un point sera fait en 2018 pour savoir si les logiciels libres et les formats ouverts permettent de réduire les dépenses.

    Enfin, un point notable vient du fait que Lee Hyeok-jae, chef du National IT Industry Promotion Agency, annonce que la transition sera accompagnée d'une main d’œuvre en développement logiciel qui aura pour but de prendre en charge le développement de logiciels libres tandis que l'enseignement universitaire sera renforcé sur ce point.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Atelier du Samedi Libre à Marseilles

    Samedi 9 Août

    L'association CercLL vous invite à l'atelier du Samedi Libre le 30 août 2014 de 14h30 à 17h30, à La Fabulerie à Marseilles.

    « Découverte des Logiciels Libres »

    Cet atelier s’adresse plus particulièrement aux débutants soucieux d’utiliser de manière plus rationnelle leur ordinateur. Comme le mot atelier le laisse présumer, nous proposons dans ce cadre une approche pratique des outils libres. Nous avons décidé de nous adresser à un public débutant qui cherche à mieux connaître son ordinateur et les applications les plus courantes que tout un chacun utilise.

    • Les participants devront s’inscrire.
    • L'atelier n'aura lieu que si 4 personnes au moins sont inscrites.
    • L'inscription équivaut à un engagement moral de participation.
    • L'atelier se déroule à La Fabulerie, 4 rue de la Bibliothèque, 13001 Marseille.
    • Entrée Libre. Tout Public.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    CatchChallenger 0.5

    Samedi 9 Août

    CatchChallenger est un jeu de rôle en ligne massivement multijoueur (MMORPG) « à l'ancienne » La base du jeu est un mélange de gameplay : combat, farming, exploration, fabrication, commerce, gestion, compétition. Le travail est concentré sur le gameplay, les performances et la créativité. CatchChallenger est entièrement libre (GPLv3): code, données (artwork), et site.

    Cette version totalise plus de 4Mo de code, plus de 1700 commits sur 3 ans de vie (sur les différentes parties du projet). Client/Serveur sont développés sous Linux, et automatiquement empaquetés pour OS X et Windows.

    Les derniers gros changements ont été réalisés en background (version Qt ou epoll, ajout de PostgreSQL), et ont pris plus de temps de prévu. Un gros focus a été fait sur les performances, la sécurité, et un coût d'exploitation minimum.

    La bande passante a été soignée pour consommer moins. Les attaques DDOS sont mieux gérées. Le SSL n'est plus obligatoire (SSL inutile sur I2P) mais token et double hash ont été ajoutés.
    Des FastPaths ont été ajoutés pour optimiser les performances, et des contrôles supplémentaires en mode debug. L'empreinte mémoire a encore diminué.

    De nombreuses retouches utiles de l'interface ont été apportées. Les messages d'erreurs ont encore été améliorés, et sont enregistrés dans un fichier de log. Le calendrier d'événements est actif par défaut (cycle nuit/jour).
    Le datapack a été complété, il propose plus de monstres, d'objets, de recipes pour le crafting, et de quêtes.

    Pour ne pas utiliser PF_RING ZC, le besoin de changements de l'API et du noyau Linux a été formulé dans le wiki (d'autre OS, voire en exo-kernel sont envisagés).

    CatchChallenger est un MMORPG professionnel, se devant donc être compétitif face aux MMORPG commerciaux. Il doit avoir à la fois une bonne montée en charge (égale ou supérieure aux MMORPG mondiaux, donc des centaines de milliers de joueurs), donc être prévu et testé comme tel (cluster, base redondée, haute disponibilité, …)

    Pour les prochaines versions, il faut rattraper le retard de cette version, et corriger quelques grosses lenteurs, puis se concentrer sur la jouabilité, l'interface et le gameplay.

    Le projet est toujours à la recherche d'aide, par exemple :

    • un développeur QtQuick2 (portage QtQuick1 d'un code, et adaptation des binding c++), payé si besoin.
    Télécharger ce contenu au format Epub

    Lire les commentaires

    Sortie de X.org 1.16

    Jeudi 7 Août

    Si Wayland est sur la bonne voie pour arriver sur nos ordinateurs, l’équipe s’occupant de X.org n’a pas chômé pour nous livrer, le 17 juillet dernier, cette version 1.16 qui apporte pas mal de nouveautés intéressantes !

    La suite de la dépêche propose une traduction française des notes de version (Glamor, XWayland, systemd, compilation plus propre, appareils non-PCI, etc.).

    • Intégration de Glamor : ce sous-système d’accélération graphique 2D fondé sur OpenGL offre des performances raisonnables, ce qui permet d’éviter, la plupart du temps, les solutions de secours logicielles.

    • XWayland est maintenant livré avec X.org. Il fournit un serveur X intégré dans un système de fenêtrage Wayland. Il utilise Glamor pour le rendu, et évite ainsi la plupart des problèmes de performance inhérents à la superposition de surfaces (layering) des systèmes de fenêtrage.

    • l’intégration de systemd : cela permet à systemd de lancer et gérer X.org, améliorant la vitesse de démarrage et la fiabilité.

    • X est maintenant exécutable sans droits root avec l’aide de systemd-logind, cela signifie aussi qu’il doit être lancé à partir du même terminal virtuel que celui utilisé pour s’identifier. La redirection sur stderr casse également la connexion sans droits root. L’ancien comportement d’exécution sous root peut être restauré par le fichier de configuration Xorg.wrap (man xorg.wrap). Veuillez noter que le lancement de X par un gestionnaire de connexion (gdm, kdm…) ne fournit pas encore l’accès sans root.

    • Suppression de milliers d’avertissements du compilateur. Nous ajoutons lentement de plus en plus d’options au compilateur pour que la compilation de X nous indique les pratiques dangereuses dans le code. La version 1.16 s’occupe enfin de l’énorme liste de ces avertissements.

    • Glamor pour Xephyr. Cette implémentation de X-sur-X sert d’environnement de développement principal pour notre nouveau sous-système d’accélération 2D, permettant un cycle de développement et de test rapide sur une seule machine.

    • Gestion des appareils non-PCI. De nombreux périphériques d’affichage ne sont pas listés avec les API PCI standards ; désormais le serveur X peut les auto-détecter et les configurer comme il le fait pour des systèmes plus conventionnels.

    Pour la première fois depuis plusieurs versions, il y a eu des ajouts de code considérables au serveur, parmi lesquels 2/3 au code de Glamor.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    GOG.com distribue maintenant des jeux pour GNU/Linux

    Jeudi 7 Août

    Le service de distribution et de vente de jeux vidéo en ligne sans DRM GOG.com annonce l’ajout de GNU/Linux aux plateformes pris en charge.

    Pour rappel, « le service vend des vieux classiques sur PC mis à jour pour tourner sans encombre sous les dernières versions de Windows. » et depuis mars 2012 propose des titres plus récents comme The Witcher 2, Alan Wake, et Assassin's Creed entre autres. Merci Wikipédia francophone et anglophone.

    Outre l’ajout d’une nouvelle plateforme prenant en charge GNU/Linux, on apprend que 50 jeux sont déjà disponibles pour GNU/Linux, dont 23 (et un en préparation) pour la première fois disponibles sous GNU/linux.

    La prise en charge de GNU/Linux était l’un des souhaits les plus populaires sur la liste de souhaits de la communauté, ce qui a donc poussé GOG.com à la concrétiser.

    Le 18 mars 2014, GOG.com annonce qu’il commence à y travailler, et que cela arrivera quand 100 jeux seront disponibles pour GNU/Linux. Finalement, le 24 juillet 2014, GOG.com annonce qu’il ne sert à rien d’attendre plus et que 50 jeux sont déjà disponibles pour cette nouvelle plateforme !

    À cette occasion, plus de la moitié de ces jeux ont été mis en promotion avec 75% de remise sur leur achat pendant une semaine.

    GOG.com distribue un .tar.gz indépendant de la distribution (reste à voir si effectivement cela fonctionne sans problème sur toutes les distributions), ainsi que des paquets DEB pour les versions LTS actuelles et futures d’Ubuntu et de Linux Mint.

    GNU/Linux (ou en tout cas Ubuntu) devient une alternative de plus en plus crédible à Windows pour le jeu, et cette annonce ne fait que confirmer la tendance.

    Et peut-être un jour, GNU/Linux première plateforme pour le jeu vidéo ?

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Sortie de Linux 3.16

    Jeudi 7 Août

    La sortie de la version stable 3.16 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org. Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche.

    Sommaire En Bref
    • architecture :
      • unification de la hiérarchie des Cgroups ;
    • pilotes graphiques libres :
      • AMD : meilleure performance et consommation plus basse grâce à BAPM ;
      • Intel : gestion des tampons graphiques alloués par malloc ;
      • Nouveau : changement de fréquence expérimental pour les GPU Kepler ;
    • réseau :
      • le TCP Fast Open est maintenant disponible pour IPv6 ;
    • sécurité :
      • le bit NX est maintenant utilisé plus tôt dans le chargement des modules ;
    • virtualisation :
      • KVM permet de gérer Xen en virtualisation imbriquée.
    La phase de test RC-1

    La version RC-1 est sortie le 15 juin 2014.

    Cela fait deux semaines que la phase d'intégration a commencé et que la rc1 est prête. Par conséquent, la phase d'intégration est finie.

    Cette phase a été un peu inhabituelle, car cela fait seulement une semaine que la version 3.15 est sortie, et la première semaine a chevauché la dernière -rc de la version précédente ; mais cela ne semble pas avoir eu beaucoup de conséquences sur le développement. Tout semble normal et, s'il y a quelques choses à noter, c'est que cette phase a été plus grosse que d'habitude. Ce n'était tout de même pas une phase d'intégration aussi grosse que la 3.15, mais cela n'en était pas loin.

    Tout cela semble habituel du point de vue des statistiques : deux tiers des changements concernent les pilotes (et un tiers de ceux-ci concernent staging), la moitié restante correspond à des mises à jour d'architectures (avec ARM en tête, principalement les fichiers dts — mais il y a aussi du mips, powerpc, x86 et arm64).

    Mis à part les mises à jour de pilotes et d'architectures, un mélange habituel de changements : systèmes de fichiers (principalement reiserfs, xfs, btrfs, nfs), réseau, parties du cœur (mm, verrous, ordonanceur, traçacge), et outils (performance et alimentation, mais aussi quelques tests).

    Comme d'habitude, le résumé court des changements est beaucoup trop long pour être utile et inclus dans cette annonce, mais naturellement vous pouvez regarder en détail dans git. Je poste les « changements fusionnés » comme d'habitude, ce qui donne, je pense, une meilleure vision générale. Et comme d'habitude, cela ne reflète pas les honneurs dûes aux personnes qui ont nécessairement écrit le code, mais aux mainteneurs des sous-systèmes qui me les ont envoyés. Pour les vrais honneurs, allez voir dans l'arbre de git.

    Allez-y et testez,

    Linus

    RC-2

    La version RC-2 est sortie le 21 juin 2014.

    C'est un jour plus tôt que d'habitude, mais demain cela risque de ne pas être possible pour moi, car je serai sur la route une bonne partie de la journée, donc allons-y. Ces temps-ci, la plupart des personnes envoient leurs demandes d'intégration et leurs correctifs pendant la semaine, donc ne pas publier un dimanche ne fera pas beaucoup de différence. De plus, ce n’est pas comme si je n’avais pas assez de modifications pour publier la rc2.

    Bon, assez d’excuses. La 3.16-rc2 a été publiée et contient l'assortiment habituel de correctifs répartis sur l’ensemble du code. Ce qui est inhabituel à ce stade est de constater à quel point les changements concernant l'architecture SPARC sortent du lot (presque 40 % des correctifs en vrac), mais ce ne sont que des nettoyages d’avertissements.

    De manière similaire, quelques modifications du DRM Nouveau ressortent du côté taille, mais encore une fois, c'est principalement dû à des petites corrections de bogues de micro-logiciels qui ont changés les fichiers générés. Les vrais changements sont peu importants.

    Si on ignore ces deux grosses modifications inhabituelles (en terme de lignes de code) le reste semble normal. Il y a des modifications de pilotes, des mises à jour d'outils (particulièrement perf) et diverses autres mises à jour d'architecture (arm, s390, unicore32, x86, …). Et juste des trucs divers aléatoires un peu partout : rtmutex, btrfs, « yadda yadda ».

    Le résumé de publication n'est pas minuscule, mais suffisamment petit pour être inclus ici, donc vous pouvez voir les détails si vous êtes intéressés.

    S'il vous plait, allez-y et testez,

    Linus

    RC-3

    La version RC-3 est sortie le 29 juin 2014.

    Nous sommes de retour à un emploi du temps dominical de publication, et les choses semblent raisonnablement normales.

    Il y a peut-être relativement moins de mises à jour de pilotes que d'habitude, dont la plupart sont assez petites, mais c'est probablement juste dû à la planification (par exemple, Greg n'a pas envoyé ses changements USB/staging cette semaine, donc les changements de pilotes sont principalement ceux des GPU, réseau et son).

    De fait, les diverses mises à jour d'architecture (MIPS, PowerPC, x86, ARM) dominent dans les différences, et il y a quelques autres mises à jour diverses. Nous avons des mises à jour de système de fichier (AIO, NFS et Ocfs2), un petit lot de correction sur mm d'Andrew, quelques trucs réseau, etc.

    Le résumé de publication donne une bonne idée des changements. Les plus visibles pour les utilisateurs sont probablement le « dé-cassage » des accès en lecture de périphérique à accès bloc sur les cibles 32 bits, et quelques corrections de régressions sur vDSO x86 qui posaient problèmes. Le reste n'affecte probablement, au final, que peu de personnes, mais ce sont des corrections propres…

    Linus

    RC-4

    La version RC-4 est sortie le 6 juillet 2014.

    Les choses se sont gentiment calmées et tout semble parfaitement normal. Peut-être que ce calme a été dû, en partie, aux gens qui commencent à décoller pour l'été et (aux É.U.) la semaine du 4 juillet, mais quelle qu'en soit la raison, à la fois le diffstat et les rapports semblent sympathiques et raisonnablement petits.

    La plupart des modifications concernent les pilotes (gpu, usb, scsi, son), les systèmes de fichiers (Btrfs, ext4) et les mises à jour d'architecture (principalement ARM). Avec une poignée de divers trucs épars. Mais cela reste relativement limité.

    Sortez et testez ça,

    Linus

    RC-5

    La version RC-5 est sortie le 13 juillet 2014.

    Les choses ont l'air normales et, comme d'habitude, j'aimerais qu'il y ait un peu moins de trucs en cours, puisque ça commence à arriver vraiment tardivement dans le cycle des RC, mais honnêtement, ce n'est pas comme s'il y avait quelque chose qui fasse réellement froncer des sourcils.

    La plupart des modifications concernent les pilotes — avec acpi et gpu qui ressortent du lot. C'est vraiment assez varié (hid, hwmon, iio, thermal, clk pilotes, libata, pinctrl, etc.). Il y a les mises à jour d'architecture habituelles (principalement ARM et un peu de PowerPC), il y a un peu de correction de docbook et il y a quelques corrections de système de fichiers (F2FS, kernfs et ext4). Avec aussi une poignée de petites corrections du noyau (principalement les Cgroups).

    Allez-y et testez,
    Linus

    RC-6

    La version RC-6 est sortie le 20 juillet 2014.

    Semaine après semaine, nous nous dirigeons vers ce qui est supposé être la dernière RC mais, assez franchement, les modifications ne se calment pas comme elles le devraient.

    C'était déjà vrai pour la RC5 — plus grosse que la RC4. Cela ne m'avait pas inquiété outre mesure parce que la RC4 était plutôt petite. Mais maintenant la RC6 est sortie et, non seulement elle est plus grosse que la RC5, mais aussi elle ne contient pas que des modifications triviales.

    Ce n'est pas comme cela que c'est supposé se passer.

    Quoi qu'il en soit, la RC6 n'est pas si grosse, donc je ne suis pas vraiment inquiet, mais je suis en train d'arriver au point où je vais commencer à insulter les gens et vous crier dessus si vous m'envoyez des choses qui ne sont pas adéquates pour les dernières publications de RC. Ça ne veut pas dire que cela a été le cas : bien que la RC6 soit plus grosse que je le souhaitais, je ne pense pas qu'il y ait trop de choses frivoles dedans. Mais je vais continuer de surveiller et je vais commencer à être râleur (ou PLUS râleur) si je remarque que les gesn [NdT : Linus a écrit « peopel » au lieu de « people »] ne sont pas sérieux sur le fait d'essayer de calmer les choses.

    De toute façons, la RC6 elle-même finit par avoir des changements à peu près partout : pilotes (le principal étant du réseau mais il y a gpu, il y a infiniband, ce que vous voulez), systèmes de fichiers (corrections NFS tardives, XFS, FUSE, GFS2, Btrfs), code du cœur du réseau, etc, etc. Ci-joint le rapport résumé pour ceux qui sont intéressés par (un aperçu) des détails.

    Allez donc récupérer la dernière RC et donnez un coup de pied dans les pneus, pour voir si rien n'est passé entre les mailles du filet, ok ?

    Linus

    RC-7

    La version RC-7 est sortie le 27 juillet 2014.

    Je suis content de dire que les choses se sont un peu calmées et que ça semble être dans la bonne voie.

    Ce qui n'était pas du tout le cas au début de cette semaine - nous avions ce qui est apparu être des bugs du noyau vraiment vicieux et, en plus du fait que la RC6 était plus grosse que les RC précédentes, je ne sentais vraiment pas bien cette publication pendant un moment.

    Mais les bugs les plus vicieux n'étaient au final pas du tout des bugs du noyau. L'un venait en réalité d'une erreur de compilateur NdT : la version de GCC de Debian était en cause (ce qui est toujours très effrayant, difficile à débugger et très ennuyeux) et il y a en plus une solution de contournement très triviale, donc nous n'avons pas eu à blacklister des compilateurs. Un autre s'est avéré n'être qu'un faux positif, car lockdep était un peu trop agressif.

    Nous avons évidemment effectué diverses vraies corrections là-dedans mais aucune n'a l'air spéciale ou inquiétante. Et RC7 est finalement plus petite que les RC précédentes, donc nous sommes clairement en train de nous calmer. Donc contrairement à mes précédentes inquiétudes ce pourrait être la dernière RC ; nous verrons comment la semaine prochaine sera.

    En chiffres, RC7 se compose d'environ un tiers d'architecture (xtensa, PowerPC, x86, S/390, Blackfin), un tiers de pilotes (gpu, media, networking) et un tiers de divers (networking, mm). Mais c'est dans l'ensemble petit. Résumé en pièce jointe.

    Linus.

    Version finale

    La version finale est sortie le 2 août 2014.

    Rien de spécialement intéressant n'étant arrivé pendant cette semaine, voici la version 3.16.

    Et comme d'habitude (la version précédente faisant figure d'exception), cela signifie que la fenêtre d'intégration de la version 3.17 est désormais ouverte. Pour la troisième fois consécutive, le calendrier n'est pas favorable, car je dois voyager pendant la seconde semaine de la fenêtre. De nombreux autres développeurs principaux seront aussi en déplacement, car c'est juste avant le "kernel summit" de Chicago.

    Par conséquent, nous verrons comment se passera la prochaine fenêtre d'intégration, mais je ne me fais pas trop de souci à son sujet. Si finalement je n'arrive pas à venir à bout des intégrations, je pourrai déborder sur la semaine du kernel summit, mais j'espère terminer les gros morceaux cette semaine avant le début des voyages, mais peut-être que cela ne se déroulera pas ainsi. Donc, c'est juste une information sur le fait que la fenêtre d'intégration pourrait être allongée.

    Quoi qu'il en soit, revenons aux changements depuis la -rc7: il y a de petits changements un peu partout, avec un tiers de modifications d'architecture, un tiers de pilotes, et un tiers de "divers" (principalement gestion de mémoire et réseau). Les changements propres aux architectures concernent ARM (principalement DT), x86 (quelques corrections pour Xen), et PowerPC (divers). Le journal des changements abrégé donne une bonne idée de tout ça, mais en réalité cela ne correspond qu'à 83 commits (plus les fusions et le commit de release), dont environ un tiers marqués comme stables.

    Bien que la version 3.16 ait semblé un peu douteuse pendant un moment, les choses se sont décantées de façon satisfaisante, et il n'y a aucune raison pour faire une candidate à la sortie supplémentaire comme je le redoutais il y a tout juste 2 semaines.

    Linus

    Les nouveautés Architecture Problèmes avec GCC 4.9

    Un bug assez pénalisant a été repéré au sein de l'ordonnanceur par des développeurs du noyau. Lorsque ce dernier était compilé en debug le compilateur gcc ne compilait pas correctement la fonction load_balance() au sein de l'ordonnanceur, ce qui entraînait des comportements complètement inexplicables. Il s'agit d'un problème datant de gcc 4.5 et qui se serait manifesté avec la sortie de gcc 4.9 et 4.9.1 suite à l'activation de certaines optimisations. Le problème est maintenant corrigé dans la version de développement de gcc. En attendant, une solution de repli a été trouvée, il s'agit de compiler le noyau avec l'option -fno-var-tracking-assignments ce qui cache l'existence du bogue.

    Pour plus de détails, consultez le commit.

    Unification de la hiérarchie des Cgroups

    L'architecture actuelle des cgroups permet de créer plusieurs hiérarchies dans lesquelles on va pouvoir regrouper les processus et leur appliquer des restrictions lorsque ces hiérarchies sont spéciales, c'est à dire associées à des contrôleurs (options passées lors du montage). En pratique, cette hiérarchie est visible sous la forme d'un pseudo système de fichier :

    $ ls -l /sys/fs/cgroup total 0 dr-xr-xr-x 2 root root 0 Aug 7 01:52 blkio lrwxrwxrwx 1 root root 11 Aug 6 12:03 cpu -> cpu,cpuacct lrwxrwxrwx 1 root root 11 Aug 6 12:03 cpuacct -> cpu,cpuacct dr-xr-xr-x 2 root root 0 Aug 7 01:52 cpu,cpuacct dr-xr-xr-x 2 root root 0 Aug 7 01:52 cpuset dr-xr-xr-x 2 root root 0 Aug 7 01:52 devices dr-xr-xr-x 2 root root 0 Aug 7 01:52 freezer dr-xr-xr-x 2 root root 0 Aug 7 01:52 memory dr-xr-xr-x 2 root root 0 Aug 7 01:52 net_cls dr-xr-xr-x 4 root root 0 Aug 7 01:52 systemd $ tree /sys/fs/cgroup/systemd /sys/fs/cgroup/systemd ├── cgroup.clone_children ├── cgroup.procs ├── cgroup.sane_behavior ├── notify_on_release ├── release_agent ├── system.slice │   ├── cgroup.clone_children │   ├── cgroup.procs │   ├── dbus.service │   │   ├── cgroup.clone_children │   │   ├── cgroup.procs │   │   ├── notify_on_release │   │   └── tasks ... │   ├── home.mount │   │   ├── cgroup.clone_children │   │   ├── cgroup.procs │   │   ├── notify_on_release │   │   └── tasks ... ├── tasks └── user.slice ├── cgroup.clone_children ├── cgroup.procs ├── notify_on_release ├── tasks └── user-1000.slice ├── cgroup.clone_children ├── cgroup.procs ├── notify_on_release ├── session-1.scope │   ├── cgroup.clone_children │   ├── cgroup.procs │   ├── notify_on_release │   └── tasks ├── tasks └── user@1000.service ├── cgroup.clone_children ├── cgroup.procs ├── notify_on_release └── tasks ...

    Ici la hiérarchie systemd n'est associée à aucun contrôleur alors que les autres imposent des contraintes sur l'utilisation de la mémoire, du CPU…

    Tout ceci est donc très flexible mais difficile à gérer lorsque l'on veut modifier de façon cohérente les restrictions appliquées à un groupe de processus ou ajouter des restrictions à un groupe qui n'en avait pas auparavant. Cette complexité est avantageusement masquée par systemd qui se charge actuellement de la gestion des cgroups en proposant des options plus accessibles dans les fichiers d'unit pour les services (systemd.resource-control — Resource control unit settings).

    Ainsi, il a été décidé de se débarrasser de cette séparation en plusieurs hiérarchies pour regrouper tous les contrôleurs dans une seule hiérarchie. Cela permet d'inclure dans le design même de cette hiérarchie toutes les opérations que systemd fait actuellement pour éviter cette complexité.

    Cette hiérarchie unifiée est disponible dans le noyau 3.16 mais elle n'est pas activée par défaut. Il faut monter le pseudo système de fichier contrôlant les cgroups avec les options :

    $ mount -t cgroup -o __DEVEL__sane_behavior cgroup <mount-point>

    Il est pour l'instant possible d'utiliser les deux hiérarchies simultanément pour tester le comportement de la nouvelle version, mais cela ne sera bien entendu plus possible dans les prochaines versions.

    Cette unification introduit aussi la notion de délégation : un processus privilégié (systemd) pourra déléguer le contrôle d'une partie de la hiérarchie à un autre processus, par exemple à un processus systemd dans un conteneur (LXC / Docker / systemd-nspawn) voire même à un processus systemd pour la session d'un utilisateur.

    Plus d'informations sont disponibles dans l'article de LWN (The unified control group hierarchy in 3.16) ansi que dans la documentation officielle (Cgroup unified hierarchy) qui décrit notamment comment se servir de cette nouvelle hiérarchie.

    Système-sur-une-puce ARM (SoC ARM)

    Cette version intègre pas mal de nouveautés sur les plateformes ARM.

    La carte de développement NVIDIA Jetson TK1 dispose désormais d'un début de prise en charge. Il s'agit d'une carte embarquée dotée d'un GPU Nvidia Kepler avec 192 cœurs CUDA, un processeur quad-core basé sur le processeur ARM Cortex A15, 2Go de RAM, USB 3, mini-PCIe, Bref une véritable machine de guerre. Les cartes NVIDIA Tegra Note 7 et NVIDIA Shield sont intégrées au Device Tree (DT) et disposent également d'une prise en charge initiale pour cette version.

    La gestion multiplate-forme des cartes Samsung Exynos est désormais en place. Il s'agit d'une spécificité des plateformes ARM au sein du noyau Linux qui permet à une même image noyau de pouvoir s'exécuter sur différents SoC d'une même famille de processeurs, ou à un même pilote de périphérique de pouvoir fonctionner sur différents matériels tout en gardant un cœur générique et indépendant de la machine ou de la carte embarquée sur laquelle il tourne. Cela évite de devoir mettre en dur dans le code des informations spécifiques au matériel. C'est notamment possible grâce à l'utilisation du devicetree. Les familles de processeurs ARM qui disposent de cette fonctionnalité sont de plus en plus nombreuses, on peut notamment citer : Samsung Exynos, Freescale i.MX, NVIDIA Tegra, TI OMAP ou encore Rockchip.

    Parmi les nouveautés les plus marquantes, nous pouvons également noter la gestion du Symmetric MultiProcessing (SMP) pour les Marvell Armada 375/38x et les SoC Allwinner A31, ainsi que l'arrivée de la prise en charge de nouveaux systèmes-sur-puce : Freescale i.MX6SX, LSI Axxia AXM55xx et Samsung EXYNOS 3250/5260/5410/5420/5800. Pour plus de renseignements concernant les nouvelles fonctionnalités ARM pour cette version, je vous invite à regarder le commit plus en détail.

    MIPS

    Pas mal de nouveautés sont au rendez-vous pour l'architecture MIPS. La Para-virtualisation fait son apparition au sein de Linux 3.16. Le nombre maximum de CPU se voit augmenté de 64 à 256.
    Il est maintenant possible d'éteindre la carte d'évaluation Malta, qui dispose d'un mode d'extinction logiciel (c'est à dire générique et non propre au micro de la carte).

    Un début de gestion de l'Octeon 3 a également été ajouté. Octeon 3 est le nouveau processeur de Cavium annoncé en fin d'année 2013. Il s'agit d'un processeur multi-coeurs basé sur les processeurs MIPS 64bits, gravé en 28nm et orienté calcul haute performance.

    Pour plus de renseignements, voici la demande de fusion.

    ARM64 big.LITTLE dans cpufreq

    Une nouveauté assez intéressante est l'ajout du mode big.LITTLE de la dernière famille de processeur armv8 au sein du pilote CPUFreq. Le mode big.LITTLE est une nouvelle technologie dite "d'optimisation de gestion de l'énergie" qui permet au processeur ARM de disposer d'un maximum de performances lorsqu'il en a besoin, tout en préservant au maximum son énergie lorsque cette puissance n'est pas nécessaire. Pour ce faire, le SoC est doté de plusieurs cœurs destinés au calcul intensif (BIG) et d'autre qui consomment moins d'énergie qui sont destinés à faire tourner les tâches moins gourmandes en ressources (LITTLE). Le SoC fait connaître ses processeurs BIG et LITTLE au système d'exploitation afin que les tâches puissent migrer à chaud d'un cœur de calcul à l'autre en fonction de la charge du cœur sur lequel il se trouve mais aussi en fonction de son "historique" logiciel d'exécution passé ce qui permet à l'ordonnanceur de parfois prendre des anticipations.

    Il ne s'agit là que d'une gestion au sein de CPUFreq, lui permettant ainsi de décider quel cœur est actif et quel cœur est éteint et ainsi gérer les power states en conséquence. Les futurs changements concernant l'ordonnanceur devraient voir le jour dans les prochaines versions.

    EFI Stub

    L'architecture ARM 64 bits dispose désormais de la gestion d'EFI stub. Linux EFI stub permet à un système disposant d'un firmware (U)EFI de démarrer l'image du noyau directement sans avoir à passer par un bootloader (tel que Grub ou elilo). Ceci est notamment possible en ajoutant du code au début de l'image du noyau afin de faire croire au firmware (U)EFI qu'il s'agit d'une image de type PE/COFF, de cette façon le noyau se fait passer pour un exécutable (U)EFI. Pour plus de renseignements, voici la demande de fusion.

    AMD Seattle

    Le nouveau Système-sur-puce (SoC) AMD Opteron A1100 ARM 64 bits, baptisé "Seattle" voit le jour dans cette nouvelle version. Il s'agit du premier SoC ARM de chez AMD, destiné à équiper les serveurs big data à basse consommation énergétique. Cette puce comprend 8 coeurs ARM Cortex A57 cadencés à plus de 2 Ghz chacun, gère jusqu'à 128 Go de mémoire, intègre la technologie ARM TrustZone, un bus PCIe doté de 8 voies, 2 ports Ethernet 10 Gb/s, de co-processeurs cryptographiques ainsi que de décompression/compression. Selon AMD, La série A de Opteron irait jusqu'à 2 à 4 fois plus vite que la série X et disposerait d'un bien meilleur rendement (rapport performance / consommation énergétique). Le meilleur étant bien entendu pour la fin, le prix !

    x86 : Intel Broadwell dans P-State

    La future génération de processeurs de chez Intel, baptisée Broadwell est maintenant supportée dans le pilote P-State.

    Pour rappel, P-State est le nouveau pilote Intel au sein du noyau Linux afin de contrôler plus finement les power states du processeur et ainsi gérer plus efficacement la gestion de l'énergie (notamment comparé au pilote de CPUFreq).

    Pilotes graphique libres DRM (Direct Rendering Manager)

    Contrairement à Linux 3.15, le code commun aux pilotes graphiques libres (DRM) a reçu peu d'attention dans cette version. Les modifications les plus intéressantes dans l'immédiat sont une mise à jour de la documentation et la correction d'une situation de concurrence (race condition) dans le nommage des connecteurs et des encodeurs. Pour finir, la gestion des verrous a été revue en préparation du travail sur la gestion atomique du mode graphique.

    Cette gestion atomique du mode graphique est un saint Graal en discussion depuis au moins 2012. Une présentation claire a été donnée à la FOSDEM 2013 qui explique l’intérêt d'avoir une interface transactionnelle pour la gestion du mode graphique afin de respecter le mantra de Wayland qui est que toute image doit être parfaite, même lorsque l'on modifie des plans graphiques.

    Pour plus d'informations, vous pouvez consulter la demande d'intégration DRM.

    Adreno (pilote msm)

    Peu de nouveautés pour Adreno dans cette nouvelle version si ce n'est l'ajout d'outils de débogage à destination des développeurs.

    La nouveauté majeure est l'ajout d'une gestion très partielle des compteurs de performance, exposés dans debugfs. Les compteurs exposés sont le temps d'activité du GPU, ALUACTIVE et ALUFULL.

    Toujours dans debugfs, il est maintenant possible de récupérer les commandes envoyées avec les numéros de fence associées. Il est aussi possible de connaitre l'état des registres afin de pouvoir retrouver quel groupe de commandes a planté le GPU.

    Pour plus d’informations, vous pouvez consulter la demande d’intégration msm.

    AMD/ATI (pilote radeon)

    La nouveauté principale du pilote Radeon est l'ajout de la gestion du deep color. Au lieu d'utiliser 8 bits par composante (rouge, verte ou bleu), il est maintenant possible d'utiliser 10 ou 12 bits par composante pour les écrans qui le gèrent. Comme certains écrans disent à tort gérer cette fonctionnalité, celle-ci a été désactivée par défaut jusqu'à ce que tous les bogues aient été corrigés. Si vous voulez tester cette fonctionnalité pour vérifier qu'elle n'ajoute pas de régression ou qu'elle fait ce qui est attendu, vous devez rajouter le paramètre noyau deep_color=1 pour le module Radeon.

    Une optimisation de la VM pour la gestion des tampons graphiques situés dans la Graphics Address Remapping Table (GART) a été également été ajoutée à cette version pour les familles Southern Islands et Sea Islands. Cela a permis d'améliorer les performances jusqu'à 34% dans le benchmark Unigine Tropics.

    Des corrections de bogues ont imposé l'activation permanente du BAPM (Bidirectional Application Power Management) pour certaines puces vidéo d'AMD. Le BAPM est une gestion de la consommation énergétique plus fine (plus granulaire). Elle remplace l'ancienne DPM (Dynamic Power management) aux seuils de déclenchement plus larges, qui est désormais activée aussi implicitement. Ce système agit sur la fréquence de fonctionnement de la puce qui peut passer rapidement par exemple de 3,4 GHz à 1,4 GHz par seuils plus fins pour le BAPM.
    Plus la fréquence est basse moins on consomme. Malgré son caractère expérimental, cette fonction indispensable pour les portables et mobiles est désormais activée en permanence sur les puces de type Trinity car ces systèmes plantaient souvent lorsque le DPM était activé.
    De même, le DPM classique activé (radeon.dpm=1) empêchait le démarrage des systèmes à base de puces compatibles ARUBA même avec l'alimentation secteur et principalement dans les APU. Non seulement, le BAPM a permis une meilleure gestion de l'énergie des puces ARUBA mais il a également boosté significativement leur performance.

    Pour plus d'informations, vous pouvez consulter la demande d'intégration Radeon 1 et 2.

    Intel (i915)

    La nouveauté principale du pilote Intel dans cette version est la possibilité pour une application de créer un tampon graphique à partir d'un tampon alloué avec malloc(). Cela permet d'éviter de faire des copies lors de transferts vers/depuis le GPU et donc d'améliorer les performances et réduire les latences. Jérôme Glisse a réagi et exprimé son mécontentement car ce patch change radicalement la gestion de la mémoire et est probablement peu sûr. Il a proposé une explication de comment une erreur pourrait se produire mais le patch a quand même été accepté. Celui-ci devrait améliorer les performances des compositeurs en évitant la re-copie des fenêtres exposées par mémoire partagée au compositeur.

    Le pilote i915 continue sa transformation progressive vers le pageflip atomique et l'exposition de ses plans graphiques sans que ce soit pour l'instant utilisable par les utilisateurs. Cependant, il est maintenant possible d'utiliser des curseurs de 256x256 pixels au lieu de 64x64, ce que les possesseurs d'écrans à haute densité de pixel tels que le Retina d'Apple devraient apprécier. Pour l'exploiter, il vous faudra utiliser une version git de xf86-video-intel et d'utiliser le backend SNA.

    Une première version de la gestion du "Connected Standby" (InstaGo) est maintenant disponible. Celle-ci est équivalente à une mise en veille de la machine mais les applications peuvent réveiller la machine sans intervention de l'utilisateur. Sous Windows, cette fonctionnalité désactive la possibilité de faire une mise en veille en mémoire ou sur le disque et nécessite un firmware UEFI compatible ainsi qu'une carte réseau compatible. Les pré-requis pour Linux ne sont pas encore connus.

    Le pilote i915 a maintenant plus de chance de survivre à une situation où il manquerait de mémoire. Dans le cas où il survivrait, plus d'informations seront disponibles pour diagnostiquer la raison.

    Une gestion préliminaire de la 3D pour les nouveaux SoCs Atom Cherryview qui devrait sortir en septembre 2014 a été ajoutée. Son unité de rendu est basée sur les processeurs Broadwell (sortie prévue fin 2014) alors que le bloc d'affichage est une version améliorée de celui de la génération précédente, Valleyview. Mesa a déjà été modifié afin de gérer ces nouveaux SoCs.

    En parlant de Valleyview, celui-ci a reçu beaucoup d'attention pour corriger de multiples bogues. Cependant, l'amélioration la plus importante est la gestion des écrans MIPI DSI. Cela permettra de faire fonctionner l'Asus T100 correctement, sans hacks!

    Les processeurs de la famille Broadwell gèrent maintenant l'eDRAM qui sert à fournir 128 Mo de cache L4 pour les processeurs Iris Graphics basés sur Broadwell, la fonctionalité boost ainsi que le décodage vidéo matériel grâce au moteur VEBOX2.

    Comme à son habitude, Daniel Vetter (mainteneur i915) a publié un compte rendu des modifications sur son blog que vous pouvez lire pour plus d'informations. Vous pouvez aussi consulter la demande d'intégration i915.

    NVIDIA (pilote nouveau)

    La nouveauté principale de Nouveau dans cette version est la ré-écriture de la gestion du DisplayPort ce qui a permis de corriger énormément de bogues et permet enfin aux moniteurs de se mettre en veille et de pouvoir en sortir.

    Le changement de fréquence manuel est maintenant activé par défaut pour les cartes des familles nv40 (Geforce 7), nvaa/ac (ION) et nve0 (Kepler). Cette gestion est expérimentale et est à utiliser à fins de test uniquement (commit). Phoronix a fait quelques benchmarks utilisant cette nouvelle capacité. Toutes les cartes n'ont pas réussi à être reclockées à leur vitesse maximale, mais quand elles l'étaient, les performances étaient améliorées d'un facteur 4 en général et jusqu'à 5.8 pour OpenArena. Ce n'est cependant pas suffisant pour atteindre la vitesse du pilote propriétaire puisque Nouveau atteint de 59 à 80% des performances d'NVIDIA à fréquences égales sur la famille des Keplers.

    La gestion du GK20A (GPU intégré aux Tegra K1 basé sur Kepler) fait enfin son entrée dans Nouveau grâce au travail d'Alexandre Courbot d'NVIDIA. Cette gestion est conditionnelle à l'utilisation des microcodes de NVIDIA pour la gestion des contextes graphiques jusqu'à ce qu'un contributeur fasse le travail de rétro-ingénierie ou jusqu'à ce qu'NVIDIA donne le droit à Nouveau de redistribuer le microcode.
    En l'état actuel, il devrait donc être possible de créer un contexte graphique et faire du rendu dans une texture. Cette texture pourra ensuite être envoyée via prime (dma-buf) au pilote host1x qui gère l'affichage, mais pas avant Linux 3.18. La gestion de la mémoire est actuellement expérimentale et est en train d'être améliorée par Alexandre. Coté espace utilisateur, il vous faudra attendre la sortie de la prochaine version de mesa qui devrait arriver aux alentours de l'XDC2014. D'après Alexandre, ce GPU devrait être utilisable dès Linux 3.18.

    En parlant de microcode de gestion des contextes graphiques, celui du chipset GK208 a été corrigé afin de pouvoir gérer les shaders de géométrie.

    Pour finir, les cartes GeForce GTX 780 Ti et Tesla K40 (GK110B) sont maintenant gérées par Nouveau grâce au travail d'un test d'un contributeur externe à Nouveau. Celui-ci a également activé le décodage vidéo matériel sur les chipsets GK110, GK110B et GK208 (CodeNames).

    Samsung (pilote exynos)

    Plusieurs corrections de bogues liés à la gestion de l'horloge et de la synchronisation verticale. Pour une liste plus détaillée des changements, vous pouvez consulter la demande d’intégration exynos.

    Pour continuer sur la gestion des pointeurs utilisateur, Jérôme a proposé de désactiver complètement sa gestion car son implémentation actuelle n'était pas sûre. Le mainteneur du pilote DRM Intel a approuvé. Espérons que cette gestion sera ré-écrite dans Linux 3.17 ou désactivée.

    En vrac
    • Aspeed (Ast) : Ajout de la gestion de l'AST2400.

    • Freescale (ipuv3) : Le pilote ipuv3, pour les GPU Freescale i.MX IPUv3, quitte staging et intégre la branche /drivers/gpu/. Ce pilote ne respecte cependant pas le standard DRM, probablement car il ne propose pas d'affichage, comme Tegra.

    • Tegra (pilotes host1x et tegra) : Ajout de la gestion des curseurs et de l'HDMI pour les Tegra 124 (K1).

    Réseau

    Le TCP Fast Open, ajouté dans Linux 3.13 pour l'IPv4, est maintenant disponible pour l'IPv6 (commit).
    Pour mémoire, TCP Fast Open permet de diminuer le temps de connexion à un service lorsque plusieurs connexions vers celui-ci sont ouvertes. Avec TCP Fast Open, le serveur n'attend plus que le client émette l'acquittement final avant d'envoyer des données à l'utilisateur. D'un point de vue latence, cela permet d'ouvrir la connexion avec un seul aller, au lieu d'un aller, un retour et un nouvel aller. Cela peut être très efficace pour réduire drastiquement le temps des chargements des pages web lorsque le réseau d'accès à Internet a une grosse latence.

    Une émulation logicielle de la TCP Segmentation Offload (TSO) a été ajoutée au noyau et permet à des SoCs d'augmenter leur débit maximal de 16% à 54% tout en réduisant l'utilisation CPU de 40% dans un test de performance basé sur HTTP (commits : 1, 2). La TSO consiste normalement à envoyer l'ensemble des données à transmettre à la carte réseau et laisser celle-ci découper les paquets. Cela permet de limiter la consommation CPU sans perdre de performance.

    AMD a ajouté la gestion d'une nouvelle carte Ethernet permettant d'atteindre 10 GB/s. Le pilote de cette carte s'appelle "amd-xgbe" et celle-ci fera partie d'un SoC encore inconnu (commits : 1, 2, 3 et 4).

    Sécurité Liste non exhaustive des vulnérabilités corrigées Bit NX et chargement des modules

    Les zones mémoires utilisées pour stocker le code et les données d'un module sont protégées respectivement en lecture seule (RO) et en non-exécution (NX) à l'aide de la technologie bit NX présente dans les CPU x86 modernes. Jusqu'à présent, ces protections étaient mises en place assez tard dans le chargement d'un module par le noyau. Elles sont maintenant activées avant que les arguments passés lors du chargement du module soient parsés, c'est à dire juste avant la première exécution de code appartenant au module en cours de chargement [correctif]. Cela améliore légèrement la sécurité en diminuant l'impact d'une erreur dans le code parsant les arguments passés à un module.

    Compilation JIT des filtres seccomp

    Les filtres seccomp peuvent maintenant profiter du compilateur JIT qui a été ajouté pour le langage BPF [correctif]. Ce langage ne servait au départ que pour le filtrage des paquets réseaux mais il a été étendu et est utilisé par plusieurs sous-systèmes du noyau (voir BPF: the universal in-kernel virtual machine et Extending extended BPF).

    IMA et EVM

    L'utilisation du mode O_DIRECT pour accéder aux fichiers contrôlés par une politique IMA pouvait provoquer un interblocage. Ce problème n'est pas encore complètement résolu mais une solution temporaire a été trouvée pour autoriser un administrateur à désactiver dans la politique le contrôle d'IMA pour certains fichiers lorsque le mode O_DIRECT est utilisé [correctif].

    La méthode de calcul des signatures HMAC utilisées par EVM a été modifiée [correctif] pour permettre plus facilement l'ajout de nouveaux attributs étendus (par exemple ceux de SMACK) [correctif]. L'accès à l'attribut étendu qui stocke cette signature est maintenant restreint [correctif].

    Un bug pouvant provoquer des kernel oops lorsque IMA était utilisé avec AppArmor a été corrigé [correctif].

    LSM SELinux

    Les informations présentes dans les messages d'erreur d'accès SELinux (AVC) ne permettaient pas de savoir si l'accès avait été réellement bloqué ou si il avait été autorisé parce que le système ou le type était en mode permissif. Un nouvel élément permissive= permet d'obtenir cette information [correctif].

    Lorsqu'un processus fait appel à exec, le contexte SELinux reste par défaut celui du père, mais il peut être changé si la politique le précise et que le contexte du fichier exécuté correspond (transition de domaine à l'exécution). Une troisième façon de définir le contexte d'exécution SELinux d'un processus à l'avance est d'utiliser l'appel setexeccon(). Dans le cas où un programme tentait un exec d'un fichier dans un système de fichier monté avec l'option nosuid, cette transition n'était pas effectuée mais aucune erreur n'était retournée. Le code d'erreur -EACCES est maintenant retourné dans ce cas [correctif].

    SMACK

    (Note: Si vous avez du mal à faire la correspondance entre les accès autorisés et les labels SMACK, je vous conseille de vous référer à la documentation)

    Pour rappel, SMACK stocke les règles de contrôle d'accès aux objets représentés dans l'arborescence du système dans les attributs étendus (dans l'espace de nom security). Il n'est pour l'instant pas possible d'utiliser les attributs étendus avec les pseudo-fichiers décrivant les cgroups. Ces pseudo-fichiers sont donc labellisés par défaut avec le label *, ce qui signifie qu'aucun contrôle supplémentaire n'est effectué par SMACK (tous les accès sont autorisés par SMACK). Ce contournement est nécessaire pour faire fonctionner systemd avec SMACK (probablement dans le cadre du projet Tizen) [correctif].

    Certaines opérations effectuées sur des descripteurs de fichiers ouverts en écriture seule peuvent être apparentées à des opérations de lecture. En effet, les appels systèmes fstat et lseek par exemple permettent d'obtenir des informations sur l'état du fichier ouvert et peuvent donc être considérées comme des opérations de lecture. SMACK autorisait ces appels systèmes si le descripteur de fichier était ouvert en écriture seule et que les labels SMACK autorisaient l'opération (write). Ce comportement pouvait potentiellement mener à la création d'un canal d’information caché qui n'est pas contrôlé par SMACK. Il n'est donc plus possible d'ouvrir un descripteur de fichier en écriture si l'on ne dispose pas aussi des droits SMACK pour l'ouvrir en lecture (on peut par contre ne pas disposer des droits DAC en lecture) [correctif].

    Une modification du même style avait été ajoutée à SMACK dans le noyau 3.13 (cf Sortie de Linux 3.13: Sécurité, SMACK). Dans le cas précédent, une nouvelle opération avait été ajoutée pour gérer correctement le cas de figure mais ici les appels système fstat et lseek ne sont pas contrôlés par les hooks LSM donc ce n'est pas une solution possible actuellement.

    Pour pouvoir envoyer une information par l'intermédiaire d'une IPC, SMACK vérifie que le processus émetteur dispose du droit d'accès SMACK write sur le destinataire. Dans le cas des sockets Unix (Unix domain socket) la vérification est faite uniquement à la connexion et n'était faite que dans un sens (du processus ouvrant la socket vers le processus ayant créé la socket et pas l'inverse). C'est maintenant corrigé [correctif].

    Le retrait de l'attribut SMACK64TRANSMUTE d'un dossier n'avait pas l'effet désiré. C'est maintenant corrigé [correctif].

    L'affectation d'une chaîne vide comme valeur à un attribut étendu ne provoque plus de kernel panic [correctif].

    Un utilisateur doit avoir la capacité CAP_MAC_ADMIN pour pouvoir enlever les attributs étendus SMACK d'un fichier. Il était possible, par erreur, d'enlever l'attribut étendu SMACK64MMAP. C'est maintenant corrigé [correctif].

    Ajout d'une entrée ptrace au pseudo système de fichier permettant de contrôler le comportement de SMACK. Elle permet de régler le niveau de sécurité requis pour pouvoir utiliser l'appel système ptrace [correctif]. Les vérifications liées à l'appel ptrace ont été regroupées [correctif]. Un bug inversant la vérification lors d'un appel à ptrace a été corrigé [correctif].

    Corrections des vérifications effectuées lors de l'accès au trousseau de clé stocké dans le noyau. Elles étaient incorrectes car une clé avec un label _ ne pouvait être lue alors qu'elle aurait du être accessible par tout le monde [correctif].

    Systèmes de fichiers

    Le nettoyage et la réorganisation de code sont des points importants sur le long terme. Quelques fichiers concernant les couches en mode block du VFS passent ainsi de l'arborescence fs/ et mm/ vers le dossier fédérateur block/.

    XFS

    Du côté de chez XFS, Dave Chinner nous apprend que le code a subi un nettoyage et un peu de ré-usinage.

    Btfrs

    Le plus gros changement dans cette version est la refonte du calcul des quotas que Josef Bacik a effectuée et qui améliore le suivi in-memory des opérations extent en attente.

    Chris Mason a travaillé de son côté sur l'utilisation de la pile Btrfs car il est devenu impossible d'effectuer les longs tests de charge avec slab, lockdep et pagealloc en mode debug sans faire exploser la pile.

    Enfin, il y a les habituelles corrections de bogues, le lot d'optimisation et de nettoyage de code.

    Pour plus de détails, il est possible de consulter le rapport résumé.

    Phoronix nous offre quelques tests de performances (ici et ), et le bilan est assez simple : il n'y a pas de changements statistiquement notables.

    F2FS

    Jaegeuk Kim nous indique que Samsung s'affaire toujours à améliorer ce système de fichiers.

    Il prend en charge des partitions de taille supérieure à 2 TiB correctement, tout en améliorant la gestion du readahead. Pour rappel, cette lecture anticipée permet de pré-charger un fichier dans la mémoire vive pour diminuer les temps de latence par la suite.

    Enfin, le flush des fichiers a été amélioré.

    Reiser4

    Ivan Shapovalov a continué à travailler sur l'implémentation du mécanisme de discard, aussi connu sous le nom de TRIM. Celui-ci permet d'informer le SSD de blocs mémoire inutilisés et qui peuvent être effacés.

    Ce travail devrait permettre d'améliorer les performances de Reiser4 avec les SSD.

    NFS

    Neil Brown a corrigé NFS afin que les montages locaux (sur la même machine) fonctionnent correctement dans tous les cas de figure. Par ailleurs, la gestion XDR (eXternal Data Representation) a été réécrite afin de pouvoir gérer des grosses ACL (Access Control Lists) faisant plus de 4 KiB. De même, la fonction readdir() renvoie aussi des résultats pouvant faire plus de 4KiB, ce qui améliore les performances pour les dossiers ayant un très grand nombre de fichiers.

    Virtualisation KVM

    Plus de 200 commits pour cette version, répartis un peu partout. Commençons avec x86, pour lequel on retrouve la virtualisation imbriquée pour Xen : c'est-à-dire qu'il est possible de faire tourner Xen dans une machine KVM tout en permettant la virtualisation matérielle de Xen. C'est une fonctionnalité principalement utile pour les migrations ou les tests.

    Du côté des processeurs ARM, la publication des information PSCI (Power State Coordination Interface) 0.2 est disponible avec les instructions ARMv8. Dans les versions précédentes, seule la version 0.1 était disponible. Ces instructions permettent d'améliorer la gestion de l'énergie, particulièrement quand plusieurs systèmes d'exploitation tournent sur le même SoC et qu'il faut qu'ils se coordonnent pour savoir quand un CPU peut être éteint par exemple.

    Dans le cas de Power, la prise en charge d'u-boot est disponible pour les systèmes embarqués, pour la version 8, la prise en charge des hôtes configurés en Little Endian.

    Et enfin pour le S/390 (le mainframe IBM), les principaux changements sont la prise en charge des migrations ainsi que de GDB.

    Pour la prochaine version, on attend un gros lot de commit pour le x86 et le retrait de l'architecture IA-64 (les Itanium).

    Xen

    Xen sous ARM gère désormais les deux fonctions suspend et resume. Côté réseau, l'interface virtuelle pour gérer le réseau prend désormais en charge le mode multi-queue, ce qui améliore les performances réseau des machines virtuelles.

    Le bilan en chiffres

    En ce qui concerne les statistiques du cycle de développement de Linux 3.16, on peut se référer à la page dédiée du site remword.com qui compile des statistiques relatives au développement de Linux.

    Le nombre final de correctifs incorporés dans cette version est de 12 802, soit légèrement en‐dessous des 13 720 correctifs de la précédente. Ces ajouts sont le résultat du travail d’environ 1 527 développeurs soit, là encore, une légère baisse par rapport aux 1 547 développeurs du noyau précédent.

    Cette fois encore, c'est Intel qui occupe la tête du classement des entreprises avec 10.52% des patchs, suivis de très près par Red Hat (10.37%). Red Hat est par contre l'entreprise qui signe le plus de patchs avec 11.85% contre 10.25% pour Intel.

    Les hobbyistes occupent comme d'habitude la 3ème place avec 5.73%, si l'on ne comptabilise pas les contributeurs dont l’affiliation est inconnue, qui représentent 18.01% des contributions. Le développement de Linux est donc majoritairement sponsorisé par des entreprises, mais il reste encore de nombreux passionnés qui font ça pour eux.

    Appel à volontaires

    Jiehong, le mainteneur actuel de la partie Systèmes de fichiers va laisser sa place à une personne ayant plus de temps. Cette position est maintenant ouverte.

    Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :

    Mainteneur Contributeur(s) La phase de test Aucun Mali Julien Pecqueur Arch Romain Perier Mali Timothée Ravier Pilotes graphiques libres Martin Peres Réseau Florent F. Martin Peres Systèmes de fichiers Jiehong Mali Julien Pecqueur Sécurité Timothée Ravier Virtualisation Xavier Claude Édition générale Aucun Martin Peres

    Un peu de vocabulaire :

    • le mainteneur d'une section de la dépêche est responsable de l'organisation et du contenu de sa partie, il s'engage également à l'être dans le temps jusqu'à ce qu'il accepte de se faire remplacer ;
    • un contributeur est une personne qui a participé à la rédaction d'une partie d'une section de la dépêche, sans aucune forme d'engagement pour le futur.

    Malgré cette équipe importante, beaucoup de modifications n'ont pas pu être expliquées par manque de temps. Si vous aimez ces dépêches et suivez tout ou partie de l'évolution technique du noyau, veuillez contribuer dans votre domaine d'expertise. C'est un travail important et très gratifiant qui permet aussi de s'améliorer. Il n'est pas nécessaire d'écrire du texte pour aider, simplement lister les commits intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d'augmenter la couverture sur les modifications du noyau !

    Télécharger ce contenu au format Epub

    Lire les commentaires

    LibreOffice 4.3 est sorti

    Mercredi 6 Août

    LibreOffice 4.3 vient d’être publié en ce 30 juillet 2014. Cette nouvelle version est destinée aux utilisateurs expérimentés — les autres, comme les entreprises et les administrations, sont invités à utiliser LibreOffice 4.2.6.


    Michael Meeks est un développeur qui travaille sur la suite bureautique LibreOffice pour l’éditeur Collabora.

    Il vient de publier sur son blog une longue description du travail de refactorisation et de nettoyage qui a eu lieu lors de ce cycle de développement menant à la version 4.3 de LibreOffice. Cette dépêche est une traduction de son article initialement publié dans le domaine public ou licence CC0, comme indiqué au bas de l'article.

    Sommaire

    Aujourd’hui, nous publions LibreOffice 4.3.0, livré avec beaucoup de nouvelles fonctionnalités que vous allez aimer. Vous pouvez lire et apprécier toutes les nouveautés visibles apportées par tant de développeurs. Mais il y a aussi des contributeurs dont le travail se fait principalement en arrière-plan et dont les résultats ne sont pas si faciles à voir. Pourtant ces développements sont aussi vitaux pour le projet. Mais il peut être difficile de les distinguer parmi les quatorze mille commits faits depuis LibreOffice 4.2, alors laissez-moi détailler :

    Interface utilisateur

    La migration de l’interface utilisateur depuis les composants graphiques VCL vers Glade approche finalement de sa fin. Plus de deux cents boîtes de dialogues ont été converties dans cette version, les boîtes restantes étant les plus dures à trouver — de l’aide serait d’ailleurs appréciée. Grands mercis à Caolán McNamara (Red Hat) pour son incroyable travail ici, et également à Szymon Kłos, Michal Siedlaczek, Olivier Hallot (EDX), Andras Timar (Collabora), Jan Holesovsky (Collabora), Katarina Behrens, Thomas Arnhold, Maxim Monastirsky, Manal Alhassoun, Palenik Mihály, et beaucoup d'autres… Merci aussi à nos traducteurs qui ont aidé à la migration des chaines de caractères.

    Si vous souhaitez vous impliquer pour arriver à 100 % de conversion, allez voir le howto de Caolan et son superbe blog : 99 to go update (plus que 54 au 25 juillet), illustré par ceci :

    Améliorations de la compilation

    Libreoffice est beaucoup plus facile à compiler, et cette étape est mieux documentée — cela est important pour les nouveaux contributeurs

    Prise en charge de Visual Studio

    Non seulement Jesus Corrius a ajouté la prise en charge initiale de Visual Studio 2013, mais nous avons fait une avancée majeure grâce à Honza Havlíček qui, utilisant un travail similaire de Bjoern Michaelsen (Canonical)'s sur KDevelop, a implémenté la compilation depuis un fichier projet Visual Studio, permettant une amélioration importante de la compilation/débogage : voyez la vidéo ou tapez juste : make vs2012-ide-integration

    Dépendance à l'exécution sur OpenGL

    Dans le passé nous avions un chemin de code spécifique à OpenGL que l’on compilait dans une bibliothèque partagée liée à OpenGL, puis l’on chargeait dynamiquement ce composant — comme par exemple pour le diaporama en OpenGL. Dans la version 4.3, nous avons unifié tout notre code OpenGL pour utiliser glew, et nous avons maintenant une API VCL centrale pour s’initialiser et se lier à OpenGL, permettant une utilisation beaucoup plus facile dans le futur. Un autre bénéfice à l’utilisation de glew est la possibilité de vérifier dynamiquement les extensions OpenGL en cours d’exécution pour mieux les adapter aux capacités de votre plateforme plutôt que de se limiter aux fonctions de base.

    Entêtes pré-compilées / mises à jour de PCH

    Thomas Arhnold a découvert que nos fichiers pch (utilisés pour accélérer la compilation sous Windows) se sont détériorés, et a fait un bon ménage parmi eux. Cela a accéléré significativement le temps de compilation pour un certain nombre de modules.

    Réduction de la taille de code mobile

    Beaucoup de travail a été effectué dans LibreOffice 4.3 pour nous permettre de diminuer la taille du code et l’adapter à la taille mémoire des plateformes mobiles. Merci à Matus Kukan (Collabora) qui a découpé un grand nombre de composants UNO en différentes fonctions de construction, ce qui permet à l’éditeur de liens de supprimer les composants non utilisés. Matus a également créé un script Python solenv/bin/native-code.py pour partager les listes de compilations de composants liés statiquement dans diverses combinaisons de fonctionnalités. Tor Lillqvist (Collabora) a retravaillé ICU pour empaqueter les tables de données, qui sont globalement assez grandes, dans un fichier plutôt que dans le code. Vincent Saunders (Collabora) a pas mal travaillé pour améliorer dwarfprofile afin d’identifier les plus gros morceaux de fichiers objets et savoir d’où ils venaient. Jan Holesovsky a découplé beaucoup de code concernant l’accessibilité et supprimé beaucoup de variables statiques dans du code non nécessaire. Miklos Vajna a transformé les OOXML custom shape preset definitions (oox::drawingml::CustomShapeProperties::PresetsMap) de code généré à donnée générée : cela a permis la suppression de 50000 lignes de code. Grand merci à Tsahi Glik / CloudOn pour avoir financé ce travail.

    Travail sur la qualité du code

    Il y a eu beaucoup de travail sur la qualité du code, et pour améliorer la maintenabilité et la propreté de ce code. Nous remercions Julien Nabet pour les (à peu près) 75 commits corrigeant les erreurs cppcheck, et pour les commits quotidiens, ce qui a permis d’avoir des builds sans warnings pendant la compilation sur toutes les plate-formes. Merci également à Tor Lillqvist (Collabora), Caolán McNamara (Red Hat), et Thomas Arnhold.

    Utilisation de assert

    Un autre outil que les développeurs utilisent pour s’assurer qu’ils n’introduisent pas de nouveaux bugs sont les assertions (asserts). Historiquement le code OOo a eu un système d’assertions spécifique qu’on peut facilement occulter, ce qu’ont fait la plupart des développeurs. Grâce à Stephan Bergmann (Red Hat), nous avons commencé à utiliser les macros standards assert() dans LibreOffice, ce qui a l’énorme avantage qu’elles arrêtent le programme : si une assertion est fausse, le développeur voit un plantage, ce dont il est plutôt difficile de ne pas se rendre compte, comparé à du texte s’affichant dans le terminal. Grands mercis à tous ceux qui ont rendu efficientes les assertions.

    Coverity

    Nous avons été submergés par l’énorme quantité d’analyses venant de Coverity Scan, et Caolán McNamara (Red Hat) en particulier a fait un travail incroyable ici ; son blog sur ce sujet est comme à l’accoutumée modeste.

    Nous avons maintenant une densité de défauts (nombre de défauts par 1000 lignes de code) de 0,08, ce qui signifie 8 bugs pour 100 000 lignes de code trouvés par l’analyse statique. Ceci se compare favorablement avec les projets open source de cette taille qui contiennent en moyenne 65 bugs pour 100 000 lignes. Peut-être que le plus utile dans les rapports Coverity sont les nouveaux problèmes signalés, car beaucoup d’entre eux sont plus sérieux que les précédents rapports de basse priorité en vrac.

    Ceci a été réalisé avec 2679 commits, 88 % d'entre eux venant de Caolán, puis ensuite Norbert Thiebaud, Miklos Vajna (Collabora), Noel Grandin, Stephan Bergmann (RedHat), Chris Sherlock, David Tardon (RedHat), Thomas Arnhold, Steve Yin (IBM), Kohei Yoshida (Collabora), Jan Holesovsky (Collabora), Eike Rathke (RedHat), Markus Mohrhard (Collabora) et Julien Nabet.

    Test de l'import et maintenant de l'export

    Le grand crash-test de Markus Mohrhard sur l’import/export a été étendu à plus de 55 000 documents contenant des problèmes ou suscitant des bugs, et couvre maintenant l’import PDF. Le nombre de crashs et de problèmes de validation continue a diminué. Markus a également réécrit et simplifié le script de test en Python. Cependant nous avons régulièrement des soucis avec ce test (qui tourne pendant 5 jours en utilisant une machine costaude), ce qui bloque plusieurs Linux sur plusieurs distributions, versions de noyau, à la fois sur du matériel virtuel et réel ; ce qui a un impact négatif sur son utilité.

    Refactorisation des gros objets

    Dans certains cas, LibreOffice a des classes qui semblent faire « un peu tout », y compris le café. Mercis à Valentin Kettner, Michael Stahl (RedHat) and Bjoern Michaelsen (Canonical) pour avoir aidé à retravailler ces classes. Par exemple SwDoc (un document Writer) hérite maintenant de seulement 9 classes au lieu de 19, et l’entête du fichier a diminué de plus de 300 lignes.

    Corrections Valgrind

    Valgrind s’avère toujours être un outil merveilleux pour trouver et isoler les fuites et les mauvais comportements sur différents morceaux du code, même si les chemins de code normaux sont maintenant plutôt propres. Dave Richards, de Largo, a très gentiment donné du temps CPU sur sa nouvelle machine Linux à 80 CPU. Nous utilisons cette machine pour lancer le test d’import/export de Markus sous Valgrind, et trouver et résoudre un certain nombre de problèmes. Les logs de Valgrind sont ici. Nous serions très heureux d’aider les autres pour leurs tests de charge.

    Assainisseur d'adresse/fuite

    Il y a plein de super nouvelles façons de faire de l’assainissement de code (à la compilation) et grâce à Stephan Bergmann (RedHat) nous les utilisons avec enthousiasme. L’option -fsanitize est disponible pour Clang et gcc 4.9. Cela nous permet de faire de la vérification mémoire (comme Valgrind) mais avec une visibilité sur la pile corrompue et de faire ça vraiment beaucoup plus rapidement. Les détails sur -fsanitize pour LibreOffice sont disponibles. Beaucoup de fuites et de mauvais comportements ont été résolus grâce à cet outil, merci également à Markus Mohrhard et Caolan McNamara.

    Test unitaire

    Nous compilons et exécutons plus de tests unitaires avec LibreOffice 4.3 pour éviter les régressions au fur et à mesure du développement. La recherche "grep" sur CPPUNIT_TEST() et CPPUNIT_ASSERT comme la dernière fois montre bien que la tendance à la croissance continue :

    Notre idéal est que tous les bugs corrigés soient accompagnés d’un test unitaire afin qu'ils ne réapparaissent pas. Avec 1100 commits, et plus de 80 participants pour les tests unitaires dans la 4.3, il est difficile de citer toutes les personnes impliquées, je m’excuse pour cela. Ce qui suit est la liste triée de ceux qui ont fait plus de 20 commits sur les répertoires qa/ : Miklos Vajna (Collabora), Kohei Yoshida (Collabora), Caolán McNamara (RedHat), Stephan Bergmann (RedHat), Jacobo Aragunde Pérez (Igalia), Tomaž Vajngerl (Collabora), Markus Mohrhard (Collabora), Zolnai Tamás (Collabora), Tor Lillqvist (Collabora), Michael Stahl (RedHat) et Alexander Wilms.

    SAL_OVERRIDE et plus

    Traditionnellement, C++ autorisait une grosse ambiguïté sur la surcharge des méthodes, permettant l'omission du mot clé “virtual” dans les surcharges et permettant également les surcharges polymorphiques accidentellement. Pour se préparer au nouveau standard C++, nous avons annoté toutes nos méthodes virtuelles qui sont surchargées dans des sous-classes avec la macro SAL_OVERRIDE, pour être sûr que nous compilons nos vtables correctement. Grands mercis à Noel Grandin, et Stephan Bergmann (RedHat) pour avoir écrit un greffon clang qui aide à produire ces annotations et un autre pour vérifier que les résultats restent cohérents. Ceci corrige certains bugs présents de longue date. Et comme bonus, quand vous lisez le code, il est beaucoup plus facile de trouver la déclaration de la méthode virtuelle initiale : c’est celle qui n’est pas annotée avec SAL_OVERRIDE.

    QA / bugzilla

    Dans cette version, l’équipe assurance-qualité a grandi et fait un travail fantastique sur à la fois le tri des bugs et la fermeture de ceux-ci, nous ramenant sous la valeur ô combien symbolique des 1000 bugs non triés. Nous avons actuellement environ 750 bugs non confirmés, ce qui est le nombre le plus bas depuis plus de deux ans. Merci à tous pour ce bon travail, malheureusement c’est assez difficile d’extraire les remerciements pour les bugs confirmés, mais la liste des héros recouvre bien la liste des non-développeurs ayant fermé le plus de bugs (voir plus bas).

    Nous avons aussi eu un de nos meilleurs week-ends de chasse aux bugs pour la 4.3, voir ce qu'a écrit Joel Madero. L’équipe assurance-qualité a également fait un excellent travail en bissectant nos dépôts git pour isoler les régressions à de petits blocs de commits, ce qui améliore grandement la vie des développeurs.

    Un des indicateurs que nous regardons pendant l'ESC call est qui est dans le top dix dans le freedesktop Weekly bug summary. Voici la liste des 20 personnes qui apparaissent le plus fréquemment dans le top 10 des gens fermants le plus de bugs, par ordre de fréquence d'apparition : Jorendc, Kohei Yoshida (Collabora), Maxim Monastirsky, tommy27, Joel Madero, Caolán McNamara (RedHat), Foss, Jay Philips, m.a.riosv, Julien Nabet, Sophie Gautier (TDF), Cor Nouws, Michael Stahl (RedHat), Jean-Baptiste Faure, Andras Timar (Collabora), Adolfo Jayme, ign-christian, Markus Mohrhard (Collabora), Eike Rathke (RedHat) et Urmas. Et merci aux nombreux autres qui ont aidé à fermer tant de bugs pour cette version.

    Bjoern Michaelsen (Canonical) a aussi écrit une belle taxonomie sur nos 25 000 bugs rapportés jusqu'à présent, et a fourni les données pour une belle répartition :

    Nettoyage du code

    Le code sale doit être nettoyé — et une fois encore, nous n’avons pas chômé.

    La mort finale de UniString

    Même si nous avions éliminé dans la version 4.2 la dernière classe “string” de tools/ pour la remplacer par une nouvelle classe uniforme (OUStrings) partout, nous utilisions encore en d’autres endroits des quantifieurs de 16 bits pour décrire des offsets textuels. Merci à Caolán McNamara (Red Hat) pour avoir permis d’avoir des paragraphes de plus de 65535 caractères dans Writer, une fonctionnalité demandée depuis fort longtemps par certains utilisateurs, voir le billet idoine.

    Nettoyage du code et de la structure de VCL

    Le toolkit natif de LibreOffice — Visual Class Libraries — n’a pas reçu toute l’attention qu’il aurait mérité ces dernières années. Mille mercis à Chris Sherlock pour les centaines de patchs inaugurant le nettoyage de ces bibliothèques. Beaucoup de bonnes choses en découlent : une structure de code plus logique de sorte qu’il est aisé de trouver les méthodes ; une écriture systématique d’une documentation (doxygen) pour les méthodes de l’API, assurant que celles-ci possèdent des noms judicieux et descriptifs ; ceci commence à nous désengluer de pauvres choix de conception historiques. Ce travail est très apprécié.

    Suivi des commentaires en allemand

    Nous progressons toujours dans la traduction des derniers commentaires en allemand qui parsèment le code vers un anglais correct, précis et technique. Merci à Luc Castermans, Sven Wehner, Christian M. Heller, Philipp Weissenbacher, Stefan Ring, Philipp Riemer, Tobias Mueller, Chris Sherlock, Alexander Wilms et les autres. Dans ce cycle (NdT: de version), nous avons aussi accéléré l’outil de détection des commentaires allemands et réduit le nombre de faux positifs.

    Refactorisation automatisée de code avec Clang

    Un des héros du nettoyage de code est Noel Grandin qui améliore constamment le code de différentes façons, par exemple en remplaçant le code inutilement dupliqué pour utiliser les wrappers standards comme SimpleReferenceObject. Noel a été lourdement impliqué dans les greffons Clang, qui servent à réécrire notre format de fichier binaire qui est sujet aux erreurs. La surcharge de flux pStream >> nVar a l'air d'être une très bonne idée jusqu'à ce que l'on réalise qu'un changement inattendu du type de nVar loin de là change le format du fichier. Ces opérateurs ont maintenant tous été réécrits pour l'utilisation explicite de ReadFloat, améliorant ainsi la robustesse du code à modifier. Noel a aussi créé des greffons pour mettre à la file automatiquement les membres de fonctions simples, détecter les passages inefficaces de uno::Sequence et OUString. Stephan Bergmann (RedHat) a aussi écrit pas mal d'outils perfectionnés d'analyse statique, de vérification de déréférencement de pointeurs NULL permettant de trouver rapidement des problèmes de mise en file ('inlining') sous Linux qui posent des problèmes essentiellement sous Windows, et a réécrit les utilisations non nécessaires de sal_Bool en bool. Stephan a aussi écrit un greffon pour trouver les fonctions non-utilisées dans les templates ou non, et émet aussi des warnings sur les conversions illicites des littérales vers un bool, par exemple if (n == KIND_FOO || KIND_BAR). Tout cela améliore la lisibilité, la cohérence, la fiabilité et dans certains cas les performances du code.

    Amélioration du cycle de vie

    Takeshi Abe s'est beaucoup investi pour rendre les cycles de vie des objets plus utiles. Se servir de pointeurs intelligents rend le code non seulement plus lisible et court, mais surtout le sécurise du point de vue des exceptions, ce qui est vraiment très utile.

    Suppression de DocTok

    Ce nettoyage nous débarrasse de presque 80 000 lignes de code et rend le code bien plus simple à comprendre. Merci à Miklos Vajna (Collabora). Vous pouvez voir l’avant et l’après dans ce billet.

    Tenir bon sur la performance

    La performance fait partie de ces choses difficiles à conserver. Elle a la fâcheuse manie de partir en sucette dès qu'on a le dos tourné. C'est pourquoi Matus Kukan (Collabora) a construit une machine de test qui compile régulièrement LibreOffice et lance des tests sur le chargement, conversions, etc, de documents sous callgrind. L'utilisation du simulateur de CPU de callgrind a cette magnifique propriété de répétabilité de comportement, ce qui permet de détecter la moindre diminution ou amélioration des performances et de tout de suite résoudre le problème. C'est facile de voir sur le graphique - admirez au passage la superbe platitude des lignes entre les évènements importants. L'axe X représente le temps (annoter les axes avec les hashes git n'est pas photogénique).

    Souvent on regarde les performances juste avant la sortie finale. Ici il est intéressant de voir la grosse bosse orange d'un point de vue fragilité des performances, trouvée et résolue grâce à ces tests. Les données brutes de callgrind sont disponibles pour examination des dernières traces avec le fichier plat ODS (flat ODS) des derniers tests.

    S'investir

    J’espère que vous comprendrez que de plus en plus de développeurs arrivent et se sentent comme chez eux parmi nous. Nous travaillons ensemble pour achever des travaux d’importance à la fois sous le capot et sur la carrosserie. Si vous voulez vous impliquer, il y a plein de merveilleuses personnes à rencontrer et avec qui œuvrer. Comme vous pouvez le constater, les indépendants ont un impact significatif sur la diversité de LibreOffice (la légende de couleurs se lit de gauche à droite, de haut en bas, ce qui représente les couleurs de haut en bas dans le graphique. [NdT: les indépendants, c’est le gros morceau orange au milieu.])

    Et en ce qui concerne la diversité des patchs, nous adorons voir le volume des contributions apportées par les indépendants, même si clairement ce volume et les équilibres changent selon les saisons, les cycles de publication, le temps libre des volontaires et les business-plans.

    Naturellement, nous maintenons une liste de petites ou minuscules tâches sur notre page Easy Hacks dont vous pouvez vous emparer pour vous impliquer dans ce projet, avec des instructions simples d’installation ou de compilation. C’est extrêmement facile de compiler LibreOffice. Chaque “easy hack” indique où aller dans le code et représente une tâche simple à résoudre dans un cadre bien restreint. De plus, certaines de ces tâches sont des fonctionnalités vraiment utiles ou des améliorations de performance. S’il vous plaît, envisagez de vous impliquer sur quelque chose.

    Autre chose qui aide vraiment : lancer les préversions et rapporter les bugs. Il suffit de télécharger et d’installer une préversion et vous êtes prêt pour contribuer avec l’équipe de développement.

    Conclusion

    LibreOffice 4.3 est la suivante d’une série de versions qui vont améliorer progressivement non seulement les fonctionnalités, mais aussi les fondations de la suite bureautique libre. Soyez patient, c’est juste la première version parmi la longue série des cycles mensuels de publication 4.3.x, qui apporteront leurs lots de correctifs et d’améliorations qualitatives pour les mois à venir, tandis que nous commençons à travailler sur LibreOffice 4.4.

    J’espère que LibreOffice 4.3 vous plaira, merci de m’avoir lu, et merci de soutenir LibreOffice.

    Les données brutes de la plupart graphiques ci-dessus sont disponibles.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Sbires! La suite

    Mardi 5 Août

    Sbires! est un roman photo narrant la vie méconnue de ces personnages normalement cantonnés au second plan dont la principale fonction est de mourir sans faire d'histoire pour montrer que l'heure est grave ou que le méchant est vraiment méchant.

    Il s'agit du deuxième épisode, diffusé sous forme de feuilleton tous les lundis. La première fournée a été livrée le 4 août 2014 au soir.

    Sous licence art libre, Sbires! est produit avec Gimp, Inkscape et un peu Blender. Excédant légèrement les impératifs de la licence, les sources seront mises à disposition (celles de l'épisode 1 sont déjà disponibles).

    Sbires! est fait sous l'égide de l'AMMD, coopérative d'artistes libristes qui s'occupaient notamment de la partie sono/concert lors des dernières RMLL.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Pages