Syndiquer le contenu
Mis à jour : il y a 7 heures 54 min

Logiciel ERP Apache-OFBiz - Nouvelles versions de maintenance 12.04.04 & 11.04.05

21 août, 2014 - 12:46

La fondation Apache vient de publier les versions 12.04.04 et 11.04.05 du logiciel Apache-OFBiz. Apache-OFBiz est un logiciel de gestion d'entreprise (ERP ou PGI en français) Libre sous licence Apache 2.0 disponible sur système Linux, Windows et Mac.

Il s'agit de versions correctives permettant d'améliorer la stabilité et la sécurité du logiciel.
Elles corrigent notamment une importante faille de sécurité.

Elles deviennent maintenant les dernières versions stables officielles et les utilisateurs des versions 12.04.03 et 11.04.04 sont invités à migrer vers leurs nouvelles versions respectives.

Vous pouvez éditer cette partie en cliquant sur le crayon !

Télécharger ce contenu au format Epub

Lire les commentaires

Je crée mon jeu vidéo E12 : interfaces physiques et graphiques

20 août, 2014 - 20:06

«Je crée mon jeu vidéo» est une série d'articles sur la création d'un jeu vidéo, depuis la feuille blanche jusqu'au résultat final. On y parlera de tout : de la technique, du contenu, de la joie de voir bouger des sprites, de la lassitude du développement solitaire, etc. Vous pourrez suivre cette série grâce au tag gamedev.

Dans l'épisode 11, on a décoré notre carte, et même si elle n'est pas encore dans un état jouable, elle constitue une bonne base pour la suite. Pour ce retour de vacances, on va s'intéresser aux interfaces physiques et graphiques du jeu.

Sommaire Introduction

Contrairement à ce que j'avais espéré, les vacances n'ont pas été très productives pour mon jeu. Je comptais passer du temps dessus de manière à avoir des avancées significatives, mais il n'en a rien été. J'ai seulement pu faire quelques tests dont je parlerai sans doute dans un prochain épisode. C'est très frustrant ce genre de situation.

Ça ne m'empêche pas de continuer mes réflexions (et mes bouts de code) et de les partager. Aujourd'hui on va discuter des interfaces :

  • les interfaces physiques, celles qui permettent de commander les actions dans le jeu (input),
  • et les interfaces graphiques, celles qui rendent compte d'élements du jeu (output).

Et comme d'autres y ont réfléchi avant moi, je me suis largement inspiré de jnuit, créé par devnewton pour ses jeux en Java.

Les interfaces physiques

À la base, je ne savais pas trop quoi utiliser pour l'interface physique. Quand on pense RPG, on imagine que ça se manipule à la souris et/ou au clavier. Mais avec les RPG sortis sur console, ce n'est plus le cas. Et puis bon, il y a devnewton qui veut jouer à la manette. Du coup, allons-y, essayons de contenter tout le monde.

SFML gère les principales interfaces physiques rencontrées dans la nature : clavier, souris, manettes. Donc, de ce côté là, on n'aura pas trop de problème. Le seul problème est de trouver un moyen de gérer tous ces périphériques de manière à peu près commune et de s'éviter de longs switch redondants et désagréables, c'est-à-dire trouver le bon niveau d'abstraction.

Pour les interfaces physiques, on trouve deux notions dans jnuit que j'ai reprises. Celle de contrôleur et celle d'action.

Contrôleur

Un contrôleur, c'est juste l'abstraction d'une interface physique. Dans jnuit, le contrôleur fournit une valeur qui indique son état. Le contrôleur est alors couplé à un détecteur qui va superviser cet état et dire si le contrôleur est actif ou pas.

L'inconvénient (à mon sens) dans jnuit est qu'on est en mode polling, c'est-à-dire qu'on va demander l'état du contrôleur à chaque tour (par exemple : « est-ce que le bouton droit de la souris est appuyé ? »). L'autre mode, c'est le mode événement, c'est-à-dire qu'on regarde les événements qui se sont produits (comme par exemple un appui sur un bouton de souris) et on enregistre le nouvel état à ce moment là. J'ai une nette préférence pour le mode événement que je trouve plus naturel, mais c'est une question de goût. SFML n'est pas casse-pied et propose les deux modes de toute façon.

L'autre chose qui me chagrinait dans l'approche de jnuit, c'est cette distinction entre le contrôleur et son détecteur. La différence est très subtile mais trop subtile pour moi, alors j'ai fusionné les deux notions dans une seule : un contrôleur dit s'il est actif ou pas. Et il met à jour son état en scrutant les événements renvoyés par SFML.

Action

Une action est une abstraction d'une… action qui peut être déclenchée par le joueur — par exemple « sauter ». Une action est provoquée par un ou plusieurs contrôleurs (comme le bouton droit de la souris ou la lettre J du clavier). Comme pour les contrôleurs, il existe aussi un détecteur qui va se charger de vérifier si l'action est active ou pas, suivant l'état des contrôleurs associés. La règle est simple, il suffit d'un seul contrôleur activé pour activer l'action.

Outre le fait que la différence entre l'action et son détecteur soit une fois de plus trop subtile pour moi, j'ai trouvé qu'il manquait un élément important dans cette abstraction. En effet, une action peut être continue ou pas. Prenons deux exemples pour voir la différence. Quand j'appuie sur une flèche, je souhaite que mon personnage avance tant que j'appuie sur la flèche : c'est ce que j'appelle une action continue. En revanche, quand j'appuie sur J, je veux que mon personnage saute une fois, même si je continue d'appuyer sur la touche : c'est ce que j'appelle une action instantanée (non-continue). C'est le même contrôleur (une touche de clavier), mais la manière de le gérer est différente. Dans un cas, je veux que l'action soit active tant que le contrôleur est actif, et dans l'autre cas, je veux que l'action soit active une seule fois même si le contrôleur reste actif.

Et avec tout ça…

Une fois qu'on a des contrôleurs pour tous les périphériques, on peut alors définir des ensembles d'action, dont certains qu'on va retrouver à peu près partout. L'exemple le plus classique est l'ensemble d'actions qui permet de naviguer dans une interface graphique : haut, bas, gauche, droite, accepter.

En tout cas, cette double notion contrôleur/action est très pratique et offre le niveau d'abstraction suffisant pour définir l'interaction entre le joueur et le jeu. Du coup, ajouter la gestion de la manette, c'est juste ajouter un contrôleur à une action existante et rien d'autre ne change. C'est simple et ça répond au besoin initial.

Les interfaces graphiques

Pourquoi les interfaces graphiques de jeux vidéos sont-elles particulières ? Il y a deux raisons :

  1. Premièrement, à cause du mode de fonctionnement de l'affichage. Dans une interface graphique de bureau, l'affichage est mis à jour de temps en temps en fonction d'événements. Dans un jeu vidéo, on affiche une frame tous les soixantièmes de seconde et on la redessine à chaque fois, on doit donc redessiner notre interface complètement.
  2. Deuxièmement, à cause des interfaces physiques. Une interface graphique de bureau classique est prévue pour être utilisée avec une souris. Dans un jeu vidéo, la souris n'est pas obligatoire, il faut donc pouvoir piloter l'interface graphique avec toutes les interfaces physiques possibles — essentiellement le clavier et la manette.

Évidemment, je ne suis pas le premier à avoir réfléchi à tout ça ; il existe donc déjà une tétrachiée de bibliothèques d'interfaces graphiques pour SFML (de qualités inégales, d'ailleurs) :

J'ai décidé de réaliser ma propre bibliothèque d'interface graphique. Pour deux raisons. La première raison, c'est que les bibliothèques existantes intègrent complètement la gestion des événements. Or, sachant que j'ai déjà mes contrôleurs et mes actions, je veux les utiliser comme bon me semble et ne pas dépendre des choix faits par la bibliothèque. La deuxième raison, qui se rapproche de la première, c'est que ces bibliothèques intègrent complètement le dessin des widgets, parfois à l'aide d'un langage du genre CSS. Vous devez vous dire que je suis un peu idiot de refuser qu'une bibliothèque de widgets dessine ses widgets. En fait, le fait de découpler les widgets de leur affichage n'est pas si idiot : il permet de customiser l'affichage pour chaque jeu. Avoir un interpréteur de CSS juste pour afficher quelques widgets, ça fait un peu trop usine à gaz à mon goût.

L'intérêt d'avoir sa propre bibliothèque, c'est qu'on peut piquer une excellente idée de jnuit, à savoir offrir les widgets standard des jeux, et notamment celui qui gère la résolution de l'écran. Ça permet aussi de voir comment on programme ce genre de logiciel assez particulier qu'est une interface graphique. On en vient à se poser les mêmes questions que ses prédécesseurs et au final y apporter les mêmes réponses. Bref, c'est un exercice assez sympathique que tout le monde devrait avoir fait au moins une fois dans sa vie (comme écrire un compilateur), même si ça s'éloigne beaucoup du jeu vidéo au final.

lisuit, SFML User Interface Toolkit

Je vous présente donc SUIT (SFML User Interface Toolkit) (ou lisuit suivant mon humeur) qui est le résultat de toutes ces réflexions. SUIT vient avec la documentation de l'API, une micro documentation générale et quelques exemples (nommés respectivement spade, heart, diamond et club, hahaha) et qui permettent de voir quelques fonctionnalités de la bibliothèque. club notamment montre le widget de configuration de la vidéo.

Autres nouvelles en vrac La documentation des API de mes bouts de code

Comme vous avez pu le voir plus haut, j'ai mis en ligne la documentation des API des bibliothèques que j'ai écrites pour ce jeu, sur l'espace mis à ma disposition par github. Ça concerne libes (la bibliothèque pour faire de l'entités-composants-systèmes), libtmx (la bibliothèque pour lire les fichiers TMX produit par Tiled), et libsuit donc.

Un canal IRC pour parler de jeux libres

J'ai rejoint il y a peu le canal IRC #jeuxlibres sur Freenode. Ce canal doit exister depuis un moment mais il n'était pas très connu. Après avoir reçu une invitation, j'ai rejoint ce canal avec quelques autres personnes et au final, ce canal est maintenant assez animé. Nous sommes une grosse dizaine et il y a de temps en temps des débats assez intéressants. Si vous aimez les jeux libres, n'hésitez pas à venir nous rejoindre !

Message personnel

Enfin, je profite de cette nouvelle pour passer un petit message personnel, une fois n'est pas coutume. En fait, cet été, quelqu'un s'est aperçu que j'étais « le rewind de linuxfr ». Il me connaissait depuis des années via ce biais, et IRL depuis moins longtemps par les hasards de la vie, et il a fait le lien cet été avec des yeux ébahis. C'était très drôle à voir. Donc, coucou à Gérald (qui n'a pas voulu me révéler son compte linuxfr) ;)

Télécharger ce contenu au format Epub

Lire les commentaires

iStoa 14.08

20 août, 2014 - 19:16

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 : Hilaire Fernandes 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

19 août, 2014 - 18:21

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

18 août, 2014 - 22:27

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

18 août, 2014 - 18:01

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

18 août, 2014 - 01:07

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

15 août, 2014 - 00:35

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

14 août, 2014 - 08:44

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

13 août, 2014 - 16:22

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 maintenue pendant deux ans et remplace ainsi la version 9.1, expirant en décembre 2014. Par ailleurs, l'équipe FreeBSD a étendu la maintenance de la version 9.2 à décembre dans un souci de cohérence. En effet, la maintenance pour cette version devait se terminer en septembre 2014 c'est-à-dire avant la fin de la 9.1.

Mises à jour Pilotes
  • Les pavés tactiles 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 la gestion 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: gestion de l'Ethernet en mode RNDIS (partage de connexion USB notamment).
Systèmes de fichiers ZFS
  • Ajout de la fonctionnalité de marque-pages. 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 fichiers EXT4 est désormais géré 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 empaqueté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 la gestion du 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

13 août, 2014 - 10:54

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

12 août, 2014 - 23:20

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

12 août, 2014 - 12:01

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

12 août, 2014 - 08:19

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

10 août, 2014 - 01:08

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 à Marseille

    9 août, 2014 - 21:20

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

    « 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

    9 août, 2014 - 11:49

    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

    7 août, 2014 - 14:11

    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

    Glamor, le 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 logicielles de secours.

    XWayland

    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.

    systemd

    L’intégration de la prise en charge de systemd permet à ce dernier de lancer et gérer X.Org, améliorant la vitesse de démarrage et la fiabilité.

    Sécurité : exécution sans les droits du super utilisateur

    Le serveur X.Org est maintenant exécutable sans les droits du super utilisateur 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 la sortie erreur standard stderr casse également la connexion sans droits root. L’ancien comportement d’exécution avec les droits du super utilisateur peut être restauré par le fichier de configuration Xorg.wrap (man xorg.wrap). Notez que le lancement du serveur X par un gestionnaire de connexion (GDM, KDM…) ne fournit pas encore l’accès sans les droits du super utilisateur.

    Amélioration du code

    Des milliers d’avertissements du compilateur ont été supprimés. Nous ajoutons lentement de plus en plus d’options au compilateur pour que la compilation du serveur X.org 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

    Xephyr est une implémentation de X s’exécutant sur un autre serveur X. Xephyr sert d’environnement de développement principal pour Glamor, 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 matériels 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.

    Conclusion

    Pour la première fois depuis plusieurs versions, il y a eu des ajouts de code considérables à X.Org, parmi lesquels deux tiers concernent le code de Glamor.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    GOG.com distribue maintenant des jeux pour GNU/Linux

    7 août, 2014 - 10:12

    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

    7 août, 2014 - 09:05

    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 : changements de fréquence expérimental pour les processeurs graphiques Kepler.
     Réseau
    • 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 quelque chose à 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).

    Mises à 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çage) 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 le 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 nécessairement les honneurs dus aux personnes qui ont é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.

    En avant, 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 de 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é les fichiers générés. Les vrais changements sont peu importants.

    Si l’on ignore ces deux grosses modifications inhabituelles (en termes 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 un peu partout : rtmutex, Btrfs, bla bla bla.

    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 plaît, testez‐le donc,

    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 en staging cette semaine, donc les changements de pilotes sont principalement ceux des processeurs graphiques, du réseau et du son).

    De fait, les diverses mises à jour d’architectures (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èmes de fichiers (AIO, NFS et OCFS2), un petit lot de corrections d’Andrew sur la gestion mémoire, 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 des périphériques à accès bloc sur les cibles 32 bits, et quelques corrections de régressions sur vDSO x86 qui posaient problème. Le reste n’affecte probablement, au final, que peu de personnes, mais ce sont des corrections appropriées…

    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 États‐Unis) la semaine du 4 juillet, mais quelle qu’en soit la raison, à la fois les journaux et les statistiques sur les modifications des fichiers semblent sympathiques et raisonnablement petits.

    La plupart des modifications concernent les pilotes (pilotes graphiques, USB, SCSI et son), les systèmes de fichiers (Btrfs, ext4) et les mises à jour d’architectures (principalement ARM). Avec une poignée de divers trucs épars. Mais cela reste relativement limité.

    Allez le tester,

    Linus

    RC-5

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

    Les choses ont l’air normales et, comme d’habitude, j’aurais aimé qu’il y ait un peu moins d’agitation, puisqu’il commence à être assez tard dans le cycle des versions candidates. Mais, honnêtement, ce n’est pas comme s’il y avait quelque chose qui fasse réellement froncer les sourcils.

    La plupart des modifications concernent les pilotes — avec ACPI et pilotes graphiques qui ressortent du lot. C’est vraiment assez varié (HID, moniteurs matériels, sous‐système IIO, capteurs de température, pilotes d’horloge, libata, pinctrl, etc.). Il y a les mises à jour d’architectures habituelles (principalement ARM et un peu de PowerPC), un peu de corrections pour la documentation DocBook et quelques corrections de systèmes de fichiers (F2FS, kernfs et ext4). Avec aussi une poignée de petites corrections du cœur (principalement les cgroups).

    En avant, 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, 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 elle est plus grosse que la RC5, et 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 j’en arrive 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 des gens l’ont fait : bien que la RC6 soit plus grosse que je le souhaitais, je ne pense pas qu’il y ait trop de choses manifestement frivoles dedans. Mais je vais continuer de garder un œil dessus, et je vais commencer à être grincheux (ou PLUS grincheux) si je remarque que les gens ne sont pas sérieux concernant le fait d’essayer de calmer les choses.

    Malgré tout, 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 du processeur graphique, il y a InfiniBand, nommez‐le comme vous voulez), les systèmes de fichiers (corrections NFS tardives, XFS, FUSE, GFS2, Btrfs), du code réseau de base, etc, etc. Ci‐joint le rapport résumé pour ceux qui sont intéressés par (un aperçu) des détails.

    Donc, allez récupérer la dernière RC et donnez un coup de pied dans les pneus, pour voir si rien ne passe entre les fissures. 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 les choses semblent être sur la bonne voie.

    Ce qui n’était, en fait, pas du tout le cas au début de cette semaine — nous avions ce qui semblait être des bogues au cœur du code vraiment vicieux et, en plus du fait que la RC6 était plus grosse que les précédentes RC, je ne sentais vraiment pas bien cette publication pendant un moment.

    Mais les bogues les plus « méchants » n’étaient, au final, pas du tout des bogues 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éboguer et très ennuyeux), et qui avait même une solution de contournement assez simple ce qui fait que nous n’avons pas eu à mettre des compilateurs sur listes noires. 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 la RC7 est finalement sensiblement 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 se passera.

    En chiffres, la RC7 se compose d’environ un tiers d’architectures (Xtensa, PowerPC, x86, s390, Blackfin), un tiers de pilotes (pilotes graphiques, média, réseau) et un tiers de divers (réseau, gestion mémoire). Mais c’est assez petit. Journal résumé en pièce jointe.

    Linus

    Version finale

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

    Alors, rien de spécialement intéressant ne s’est passé cette semaine, et la version 3.16 est arrivée.

    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 évidemment ouverte. Pour la troisième fois consécutive, le calendrier craint, car j’ai un voyage à venir 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.

    Donc nous verrons comment se passera la prochaine fenêtre d’intégration, mais je ne vais pas m’en préoccuper outre mesure. Si finalement je n’arrive pas à venir à bout des intégrations, je pourrai retarder dans la semaine du Kernel Summit, mais j’espère terminer la pluplart des grosses intégrations la semaine prochaine, avant tout départ en voyage, alors peut‐être qu’on n’en arrivera pas là. Il s’agit juste d’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 : ce sont vraiment d’assez petits changements épars, avec un tiers de modifications d’architectures, un tiers de pilotes et un tiers de « divers » (principalement gestion mémoire et réseau). Les trucs d’architecture sont de petites mises à jour d’ARM (surtout DT), quelques corrections de Xen pour x86, et diverses petites choses pour PowerPC. Le journal résumé des changements donne une bonne idée de genre de truc que c’est, mais ça ne représente en réalité que 83 commits (plus les fusions et le commit de publication), et dont environ un tiers d’entre eux marqués comme stables.

    Bien que la version 3.16 ait semblé un peu incertaine pendant un moment, les choses se sont gentiment clarifiées, et il n’y avait aucune raison pour faire une version candidate supplémentaire comme je le craignais il y a quelques semaines.

    Linus

    Les nouveautés Architecture Problèmes avec GCC 4.9

    Un bogue assez pénalisant a été repéré au sein de l’ordonnanceur par des développeurs du noyau. Lorsque ce dernier était compilé en mode débogage, 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 fichiers :

    $ 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 processeur…

    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 l’architecture même de cette hiérarchie toutes les opérations que systemd fait actuellement afin d’é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 fichiers 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 à 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), ainsi que dans la documentation officielle (Cgroup unified hierarchy) qui décrit notamment comment se servir de cette nouvelle hiérarchie.

    Système mono‐puce ARM (SoC ARM)

    Cette version intègre pas mal de nouveautés sur les plates‐formes 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 processeur graphique NVIDIA Kepler avec 192 cœurs CUDA, un processeur quadruple‐cœur basé sur l’ARM Cortex A15, 2 Gio de mémoire vive, USB 3, mini‐PCIe. Bref, une véritable machine de guerre. Les cartes NVIDIA Tegra Note 7 et Shield sont intégrées à l’arborescence matérielle Device Tree (DT) et disposent également d’une prise en charge initiale pour cette version.

    La gestion multi‐plate‐forme des cartes Samsung Exynos est désormais en place. Il s’agit d’une spécificité des plates‐formes ARM au sein du noyau Linux qui permet à une même image noyau de pouvoir s’exécuter sur différents systèmes mono‐puces (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 Device Tree. 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, Texas Instruments OMAP ou encore ceux de 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 Allwinner A31, ainsi que l’arrivée de la prise en charge de nouveaux systèmes mono‐puces : Freescale i.MX6SX, LSI Axxia AXM55xx et Samsung Exynos 3250, 5260, 5410, 5420 et 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 processeurs 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 à la carte).

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

    Pour plus de renseignements, lire la demande d’intégration.

    ARM64 big.LITTLE dans cpufreq

    Une nouveauté assez intéressante est l’ajout du mode big.LITTLE de la dernière famille de processeurs 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 système mono‐puce est doté de plusieurs cœurs destinés au calcul intensif (BIG) et d’autres qui consomment moins d’énergie qui sont destinés à faire tourner les tâches moins gourmandes en ressources (LITTLE). Le système mono‐puce fait connaître ses cœurs de 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, ce qui permet à l’ordonnanceur de pouvoir anticiper ses décisions.

    Il ne s’agit là que d’une gestion au sein de CPUFreq lui permettant ainsi de décider quel cœur doit être activé et quel cœur doit être éteint, et ainsi gérer les « niveaux de puissance » (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. L’EFI stub de Linux permet à un système disposant d’un micrologiciel (U)EFI de démarrer l’image du noyau directement sans avoir à passer par un chargeur d’amorçage (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 micrologiciel (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, voir la demande d’intégration.

    AMD Seattle

    Le nouveau système mono‐puce ARM 64 bits Opteron A1100 d’AMD, baptisé Seattle, se voit pris en charge par cette nouvelle version du noyau. Il s’agit du premier système mono‐puce ARM de chez AMD, destiné à équiper les serveurs à basse consommation d’énergie dédiés à la gestion de données massives (ce qu’on appelle communément le « big data »). Cette puce comprend huit cœurs ARM Cortex A57 cadencés à plus de 2 GHz chacun, gère jusqu’à 128 Gio de mémoire vive, intègre la technologie ARM TrustZone, un bus PCIe doté de huit voies, deux ports Ethernet 10 Gbit/s, de co‐processeurs cryptographiques et de compression‐décompression. Selon AMD, La série A de Opteron irait jusqu’à deux à quatre fois plus vite que la série X et disposerait d’un bien meilleur rendement énergétique (rapport performance / consommation). 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 prise en charge dans le pilote P-State.

    Pour rappel, P-State est le nouveau pilote Intel au sein du noyau Linux qui permet de contrôler plus finement les tensions électriques et les fréquences des éléments du processeur, afin gérer plus efficacement la consommation énergétique (notamment comparé au pilote de CPUFreq).

    Pilotes graphiques 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 au 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 d’affichage graphique.

    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 processeur graphique, ALUACTIVE et ALUFULL.

    Toujours dans debugfs, il est maintenant possible de récupérer les commandes envoyées avec les numéros de barrières (fences) associées. Il est aussi possible de connaître l’état des registres, afin de pouvoir retrouver quel groupe de commandes a planté le processeur graphique.

    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 mémoire virtuelle pour la gestion des tampons graphiques situés dans le tableau de réadressage de la mémoire graphique (Graphics Address Remapping Table — GART) a été également été ajoutée à cette version pour les familles Southern Islands et Sea Islands. Le programme d’évaluation Unigine Tropics a mesuré un gain de performances jusqu’à 34 %.

    Des corrections de bogues ont imposé l’activation permanente du BAPM (Bidirectional Application Power Management) pour certaines puces graphiques d’AMD. Le BAPM est une gestion de la consommation énergétique plus fine (plus granulaire) remplaçant l’ancienne DPM (Dynamic Power Management) aux seuils de déclenchement plus larges. BAPM est désormais activée 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 des seuils plus fins qu’avec DPM. 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 accru significativement leur performance.

    Pour plus d’informations, vous pouvez consulter les demandes 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 ou depuis le processeur graphique, et donc d’améliorer les performances en réduisant les latences. Jérôme Glisse a réagi et exprimé son mécontentement, car ce correctif 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 correctif a quand même été accepté. Celui‐ci devrait améliorer les performances des compositeurs graphiques en évitant la recopie des fenêtres exposées par mémoire partagée au compositeur.

    Le pilote i915 continue sa transformation progressive vers la commutation atomique de page mémoire (atomic page flipping) et l’exposition de ses plans d’affichage graphique, sans que ce soit pour l’instant utilisable par les utilisateurs. Cependant, il est maintenant possible d’utiliser des curseurs de 256 × 256 pixels au lieu de 64 × 64, ce que les possesseurs d’écrans à haute densité de pixels, tels que le Retina d’Apple, devraient apprécier. Pour l’exploiter, il vous faudra utiliser une version Git de xf86-video-intel et l’architecture SNA.

    Une première version de la gestion du Connected Standby (alias 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 à la fois un micro‐logiciel UEFI et une carte réseau compatibles. 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 systèmes mono‐puces 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 3D a déjà été modifié afin de gérer ces nouveaux systèmes mono‐puces.

    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 bidouille !

    Les processeurs de la famille Broadwell gèrent maintenant l’eDRAM, qui sert à fournir 128 Mio de cache de niveau 4 pour les processeurs Iris Graphics basés sur Broadwell, la technologie 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/NVAC (ION) et NVE0 (Kepler). Cette gestion est expérimentale et est à utiliser à des fins de test uniquement [commit]. Phoronix a fait quelques bancs de test utilisant cette nouvelle capacité. Toutes les cartes n’ont pas réussi à être re‐cadencées à leur vitesse maximale, mais quand elles l’étaient, les performances étaient améliorées la plupart du temps d’un facteur 4, et jusqu’à 5,8 pour OpenArena. Ce n’est cependant pas suffisant pour atteindre la vitesse du pilote propriétaire, puisque sur les puces de la famille Kepler, Nouveau n’atteint à fréquences égales que de 59 % à 80 % des performances du pilote NVIDIA.

    La gestion du GK20A (processeur graphique intégré aux Tegra K1 basé sur Kepler) fait enfin son entrée dans Nouveau grâce au travail d’Alexandre Courbot de 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 que 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. Côté espace utilisateur, il vous faudra attendre la sortie de la prochaine version de Mesa 3D qui devrait arriver aux alentours de la conférence des développeurs de X.Org XDC 2014, qui aura lieu à Bordeaux du 8 au 10 octobre 2014. D’après Alexandre, ce processeur graphique devrait être utilisable dès Linux 3.18.

    En parlant de microcode de gestion des contextes graphiques, celui du jeu de puces GK208 a été corrigé afin de pouvoir gérer les unités (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 contributeur externe à Nouveau. Celui‐ci a également activé le décodage vidéo matériel sur les puces GK110, GK110B et GK208 [noms de code].

    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 processeurs graphiques Freescale i.MX IPUv3, quitte la branche staging et intégre la branche /drivers/gpu/. Ce pilote ne respecte cependant pas le standard DRM, probablement parce qu’il ne propose pas d’affichage, comme Tegra.

    • Tegra (pilotes host1x et tegra) : Ajout de la gestion des curseurs et du 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, le 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 du TCP Segmentation Offload (TSO), c’est‐à‐dire du délestage de la segmentation TCP, a été ajoutée au noyau et permet à des systèmes mono‐puces d’augmenter leur débit maximal de 16 % à 54 %, tout en réduisant l’utilisation processeur de 40 % dans un test de performance basé sur HTTP (commits : 1 et 2). En principe, le TSO consiste à 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 processeur sans perdre de performance.

    AMD a ajouté la gestion d’une nouvelle carte Ethernet permettant d’atteindre 10 Gbit/s. Le pilote de cette carte s’appelle "amd-xgbe" et celle‐ci fera partie du système mono‐puce Seattle (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émoire 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 du bit NX présente dans les processeurs 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 analysé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 analysant les arguments passés à un module.

    Compilation à la volée des filtres seccomp

    Les filtres seccomp peuvent maintenant profiter du compilateur à la volée (JIT — Just In Time) qui a été ajouté pour le langage BPF [correctif]. Ce langage ne servait au départ que pour le filtrage des paquets réseau, 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 — Integrity Measurement Architecture — 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 de sécurité 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 — Extended Verification Module — 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 bogue pouvant provoquer des « kernel oops » lorsqu’IMA était utilisé avec AppArmor a été corrigé [correctif].

    LSM SELinux

    Les informations présentes dans les messages d’erreur d’accès SELinux les AVC — Access Vector Cache — ne permettaient pas de savoir si l’accès avait été réellement bloqué ou s’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 fichiers 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 étiquettes SMACK, je vous conseille de vous référer à la documentation.

    Pour rappel, SMACK — Simplified Mandatory Access Control Kernel — 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 noms 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 étiquetés par défaut avec l’étiquette « * », 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ème fstat() et lseek(), par exemple, permettent d’obtenir des informations sur l’état du fichier ouvert et peuvent donc être considérés comme des opérations de lecture. SMACK autorisait ces appels système si le descripteur de fichier était ouvert en écriture seule et que les étiquettes 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 au paragraphe 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 communication inter‐processus (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 le socket vers le processus ayant créé le 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 panique du noyau [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].

    Une entrée ptrace() a été ajoutée au pseudo‐système de fichiers 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 bogue inversant la vérification lors d’un appel à ptrace() a été corrigé [correctif].

    Les vérifications effectuées lors de l’accès au trousseau de clefs stocké dans le noyau ont subi une correction. Elles étaient incorrectes car une clé avec une étiquette « _ » ne pouvait être lue alors qu’elle aurait dû ê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 bloc de 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 en mémoire 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 debogage, 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 Tio 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 (mise au rebut), aussi connu sous le nom de TRIM. Celui-ci permet d’informer un SSD que des blocs mémoire sont inutilisés et 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 de grosses listes de contrôle d’accès (Access Control Lists) faisant plus de 4 Kio. De même, la fonction readdir() renvoie aussi des résultats pouvant faire plus de 4 Kio, 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 informations PSCI (Power State Coordination Interface) en version 0.2 est disponible avec les instructions ARMv8. Dans les noyaux précédents, seule la version 0.1 de PSCI était disponible. Ces instructions permettent d’améliorer la gestion de l’énergie, particulièrement quand plusieurs systèmes d’exploitation tournent sur un même système mono‐puce et qu’il faut qu’ils se coordonnent, par exemple pour savoir quand un processeur peut être éteint.

    Dans le cas des processeurs POWER, la prise en charge de u-boot est disponible pour les systèmes embarqués, pour la version 8, la prise en charge des hôtes configurés en petit‐boutiste (Little Endian).

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

    Pour la prochaine version, on attend un gros lot de commits 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.

    C’est à nouveau Intel qui occupe la tête du classement des entreprises avec 10,52 % des correctifs, suivi de très près par Red Hat (10,37 %). Red Hat est, en revanche, l’entreprise qui signe le plus de correctifs, avec 11,85 % contre 10,25 % pour Intel.

    Les hobbyistes occupent comme d’habitude la troisiè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 Architectures 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, Davy Defaud

    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