Syndiquer le contenu
Mis à jour : il y a 14 heures 28 min

Visual novel : Le Petit Chaperon Mauve

24 avril, 2015 - 23:09

Le Petit Chaperon Mauve est un visual novel libre sorti fin mars 2015.

Comme son nom le laisse penser, l'histoire est inspirée du conte du petit chaperon rouge. Contrairement à la plupart des versions du conte, l'histoire se déroule dans un cadre moderne.

Le jeu est disponible sous licence CC-BY-SA. Il a été fait avec Ren'Py, un moteur libre de visual novel. L'ensemble des ressources est donc libre et la quasi-totalité a été faite avec des logiciels libres. Les illustrations ont été dessinées avec Gimp, MyPaint, Krita, Inkscape et Blender et les musiques composées pour le jeu avec LMMS. Les fichiers sources sont disponibles dans le dépôt git et sont livrés avec le jeu.

Le développement du jeu est terminé. En effet, le jeu est entièrement jouable et son équipe de développement souhaite se lancer dans d'autres visual novels avec, si possible, de nouveaux participants.

Visual novel

Les visual novels, ou romans multimédias, sont des jeux d'aventure mêlant textes, illustrations et choix. Le genre est très populaire au Japon et très représenté par les jeux de dragues et/où à caractère érotiques. Mais dans le Petit Chaperon Mauve, tous les dessins sont tout public. Certains jeux offrent peu d'interactions, d'autres proposent des scénarios plus complexes dont l'issue dépend des choix du joueurs.

Ren'Py

Ren'Py est un moteur libre de visual novel. Il permet de se concentrer sur le scénario, les illustrations, les sons et la musique.
Le script est écrit dans un langage maison accessible aux débutants.

Utiliser Ren'Py permet de ne pas avoir à réinventer la roue. Il fournit entre autres des effets de transitions, il gère la sauvegarde et les préférences. En outre, il permet de créer facilement des binaires pour Linux, Windows, Android et OS X.

Télécharger ce contenu au format Epub

Lire les commentaires

2 mai 2015 : Premier samedi du libre PSL mensuel à La Villette

24 avril, 2015 - 22:55

Date : samedi 2 mai 2015 de 11 heures à 18 heures
Lieu : Cité des Sciences et de l'Industrie 75019 Paris porte de La Villette, Carrefour Numérique² niveau -1

Chaque premier samedi de chaque mois, de 14h à 18h, les bénévoles de plusieurs associations du Libre organisent le Premier Samedi du Libre (PSL) à la Cité des Sciences et de l'Industrie (CSI) de La Villette. L'entrée est libre et gratuite, pour tous publics. Nous avons besoin de volontaires pour l'accueil et les installations.

  • aide à l'installation de toute distribution GNU/Linux
  • deux conférences
  • atelier Blender 3D du BUG Paris
  • wikipermanence Wikimedia
  • bidouille au Living Lab
Télécharger ce contenu au format Epub

Lire les commentaires

ASRI Edu : des environnements libres pour les PC de fond de classe

24 avril, 2015 - 16:53

ASRI Edu est une distribution GNU/Linux ludo-éducative pour les enfants de 3 à 12 ans, développée par des enseignants passionnés.

François AUDIRAC, maître animateur TICE, publie le 4 mars 2015 sur le site de TICE 14 Académie de Caen, des documents et une vidéo, pour présenter les nombreuses applications possibles de cette solution, pour les classes, sur des ordinateurs qui ne peuvent plus fonctionner sous Windows XP, dotés de seulement 256 Mio de RAM.

Les documents publiés au format pdf par François AUDIRAC présentent l'objectif principal de chacune des activités disponibles dans les logiciels GCompris, Omnitux, Childsplay, en relation avec les instructions officielles à l'école primaire.

Une école de Looberghe, dans le Nord, utilise ASRI Edu dans ses classes depuis quatre ans.

  • Dans la salle informatique, 11 postes sous ASRI Edu Kids
  • Dans chaque classe, 2 ordinateurs avec ASRI Edu kids connectés à Internet
  • Dans la salle vidéo, 1 tableau blanc avec Ubuntu 12.04

Voici la liste non exhaustive des logiciels utilisés en classe :

  • Writer pour le traitement de textes,
  • Impress pour l'élaboration de diaporama,
  • Calc pour créer des tableaux en utilisant des formules de calculs
  • GCompris
  • TuxType
  • TuxMath
  • Kolour paint,
  • K.lettres,
  • Association,
  • GeoGebra
  • SketchUp
ASRI Edu 2.1a est distribuée sur le FRAMADVD école depuis octobre 2010

Cette version est basée sur Toutou Linux 4.3.1. La version Light a été choisie par l'école Paul Langevin à Moyeuvre-Grande pour équiper une salle informatique avec de vieux ordinateurs.

Une nouvelle version ASRIedu310 est en préparation.

Cette nouvelle version est basée sur Puppy Precise 5.7.1 (32bits) et woof-ce-0.3.
ASRI Edu 310 est compatible avec les paquets de Ubuntu Precise Pangolin 12.04 (LTS).

Ce sera une version basique de 150 Mio environ, à laquelle les utilisateurs pourront ajouter des paquets logiciels en fonction de leurs besoins, un peu comme Toutou Linux Slaxen 6.0.

Les utilisateurs pourront ainsi créer des environnements spécifiques comme ASRI Edu orientation dys.

Télécharger ce contenu au format Epub

Lire les commentaires

GNU Hurd 0.6

24 avril, 2015 - 15:25

Ce 10 avril 2015 était publiée la version 0.6 de GNU Hurd — le projet historique de noyau pour le système GNU (démarré avant le projet Linux), en remplacement du noyau UNIX —, ce que Thomas Schwinge (un des mainteneurs du projet) relayait sur les listes de discussion officielles le 15 avril 2015. Cette nouvelle version arrive à peine plus d'un an et demi après la précédente version (0.5), qui était sortie à l'occasion du 30e anniversaire du projet GNU, 12 ans après la dernière version en amont, étiquetée 0.2. C'est dire que le rythme de progression s'accélère :)

Sommaire Présentation de GNU Hurd

GNU Hurd est le projet GNU de remplacement pour le noyau UNIX. Il est constitué d’une collection de serveurs — exécutés en surcouche du micro-noyau Mach — implémentant les services de système de fichiers, de protocoles réseau, de contrôle d’accès sur les fichiers et de toutes les autres fonctionnalités implémentées par le noyau UNIX ou des noyaux apparentés (comme Linux). Pour plus de détails (en anglais), Thomas Schwinge propose ces deux pages : "documentation" et "What is the GNU Hurd".

Plateformes cibles

GNU Hurd peut s’exécuter sur les processeurs 32 bits de la famille x86. Une version 64 bits (x86_64) est en cours de développement. Les volontaires pour des portages sur d’autres architectures sont les bienvenus ; contactez les mainteneurs du projet si vous avez envie d’aider (cf. "Adresses de contact" plus bas).

Contexte pour réaliser une compilation

Pour réaliser une compilation de GNU Hurd, vous aurez besoin d'une chaîne de compilation ciblant i?86-gnu ; une chaîne de compilation ciblant GNU/Linux n'est pas utilisable. Notez bien que vous ne pouvez pas lancer GNU Hurd isolément, vous aurez besoin de composants supplémentaires comme le micro noyau Mach et la bibliothèque GNU C (glibc) afin d'obtenir un système exécutable.

À propos, ce même 10 avril 2015 étaient d'ailleurs publiés GNU Mach version 1.5 (annoncé par Thomas Schwinge le 15 avril) ainsi que GNU MIG version 1.5 (annoncé par Thomas S.). GNU MIG (pour "Mach Interface Generator") traduit des fichiers de définition d'appel de procédure distante ("Remote Procedure Call" ou RPC en anglais) en code C. GNU MIG est nécessaire pour compiler tout paquet qui reçoit ou invoque un "RPC", tel que GNU Mach, GNU Hurd et la bibliothèque GNU C (glibc) lorsqu'elle est compilée pour le Hurd.

Vous trouverez des informations complémentaires pour mettre en place un environnement de développement à partir de cette page d'information pour contribuer (en anglais).

Corrections et améliorations de la version 0.6

Cette nouvelle version 0.6 regroupe les corrections et améliorations apportées depuis la version précédente, annoncées par Thomas S. et traduites ci-dessous (enrichies de deux liens) :

  • De nombreux nettoyages et corrections stylistique du code. Plusieurs problèmes ont été identifiés grâce à des outils d'analyse statique et par conséquent corrigés.

  • Le code de diffusion des messages dans les serveurs Hurd a été amélioré. Entre autres choses, il est désormais fait usage d'un mécanisme dit des "données utiles protégées" introduit dans GNU Mach 1.5 (cf. ces extraits d'IRC en anglais, s'étalant de sept. 2013 à mars 2014 et traitant notamment des "protected payloads" : "gsoc/project ideas/Improved System Object Lookups").

  • Le code du décompresseur embarqué pour gz et bz2 a été supprimé au profit de libz et libbz2.

  • L'outil natif fakeroot a été grandement amélioré et peut maintenant produire de nombreux paquets. Les outils portinfo et rpctrace permettent désormais une meilleure expérience de débogage.

  • La performance de la bibliothèque de hachage d'entiers a été améliorée.

  • Le serveur init a été divisé en deux : le serveur startup (traitant tôt l'amorçage du système et son arrêt) et un programme d'initialisation du style SysVinit (judicieusement nommé init).

  • Les traducteurs procfs et random ont été fusionnés. Cf. la page "Debian GNU/Hurd - Traducteurs" pour des explications (traduites) sur les traducteurs ("translators" en anglais) dans le contexte du Hurd.

Téléchargement

Les versions publiées peuvent être téléchargées depuis ftp://ftp.gnu.org/gnu/hurd/ ou tirées de Git : http://git.savannah.gnu.org/cgit/hurd/hurd.git/

Pour cette livraison, les empreintes MD5 et SHA1 sont :

7d69c5e1bb47c9d5636054c57fbc0304 hurd-0.6.tar.bz2
0ac9af94761e5b59a3f19756c6f8d059 hurd-0.6.tar.bz2.sig
0b5130fffe640edc8e60fea3ce7b3d68 hurd-0.6.tar.gz
6c1ad02e1bfe8219341fae218612abc4 hurd-0.6.tar.gz.sig

08ef505f425db3a15d2ecee5f35897d1b7ef7755 hurd-0.6.tar.bz2
9049c1bbcc71fafc459f07a582575804cfd48ebb hurd-0.6.tar.bz2.sig
a5d90c51d2b778c1a79895e11c1699ac98796020 hurd-0.6.tar.gz
bff54932420a7e290a096a8582acf69c7b2bafec hurd-0.6.tar.gz.sig

Adresses de contact

Vous êtes invités à lire la FAQ avant de prendre contact.

N'hésitez pas à poser toute question que vous pourriez avoir sur les listes de diffusion, sur l'IRC (en résumé : réseau IRC Freenode, canal #hurd et canal #hurdfr pour le chapitre français), par exemple à l'une des réunions IRC régulières. De façon générale, c'est une bonne idée de prendre contact avec les membres du projet dès que vous commencez à passer du temps sur un projet.

Les rapports de bug devraient être envoyés à bug-hurd [at] gnu.org ou postés sur <http://savannah.gnu.org/bugs/?group=hurd>.

Les requêtes pour de l'assistance devraient être envoyées à help-hurd [at] gnu.org ou postées sur <http://savannah.gnu.org/support/?group=hurd>.

Participation au "Google Summer of Code" 2015

Le 20 mars 2015 était annoncée (en anglais) la participation au Google Summer of Code ("GSoC") 2015 pour le projet GNU Hurd, sous les auspices du projet GNU (comme chaque année depuis 2006 — hormis en 2008 où le projet GNU Hurd a participé avec succès en son nom, avec cinq étudiants).

La période pour proposer des sujets pour 2015 est terminée. Une fois que Google aura annoncé le nombre de participants affectés au projet GNU, une discussion entre pairs des sous-projets GNU aura lieu pour déterminer la répartition pour chacun. Par contrainte en ressources, une sous-sélection des idées de projets GNU Hurd devra avoir lieu.

À partir de la liste détaillée des idées de projets, voici les titres traduits en français (avec pour chacun, un lien vers la page détaillée le concernant, en anglais) :

  • Gestion de la mémoire physique (détails)
  • Liaisons vers d'autres langages de programmation (détails)
  • Virtualisation utilisant les mécanisme du Hurd (détails)
  • Corriger et compléter la gestion du verrouillage de fichier (détails)
  • Améliorer le portage de GDB pour GNU Hurd (détails)
  • Adapter la pile TCP/IP à Hurd (détails)
  • Implémentation de NFS améliorée (détails)
  • Gestion du son (détails)
  • Améliorer la performance des entrées/sorties disque (détails)
  • Nettoyage du code de GNU Mach (détails)
  • Xmlfs (détails)
  • Permettre d'utiliser unionfs tôt au démarrage (détails)
  • Résolution… lexicale (détails)
  • Sécuriser l'implémentation de chroot (détails)
  • Améliorer l'adaptation à Hurd du gestionnaire de paquets GNU Guix (détails)
  • Utiliser des traducteurs de protocole Internet (ftpfs, etc.) en tant que processus d'arrière plan pour d'autres programmes (détails)
  • Corriger les programmes utilisant PATH_MAX et autres inconditionnellement (détails)
  • Porter GNAT (GCC) (détails)
  • Porter Google Go (GCC: gccgo) (détails)
  • Squelette d'implémentation de bibliothèques spécifiques au matériel (détails)
  • Implémenter l'extraction de CD audio (détails)
  • Améliorer la prise en charge de Perl ou Python (détails)
  • Corriger les problèmes de compatibilité exposés par des suites de tests, implémenter les interfaces manquantes dans glibc pour GNU Hurd (détails)
  • Cadriciel de tests automatisés (détails)
  • Implémenter libcap (détails)
  • Implémenter la gestion de xattr (détails)
  • Porter Valgrind sur le Hurd (détails)
  • Nouveau cadriciel de pilotes de périphériques (détails)
  • instrumentation du noyau (détails)
  • Corriger les problèmes de verrouillage de libdiskfs (détails)
Conseils pour contribuer au Hurd

Travailler sur l'un des projets du GSoC est généralement une bonne opportunité pour démarrer avec le développement du Hurd, même en dehors du contexte du GSoC. S'il vous plait, n'hésitez pas à contacter l'équipe projet pour un accompagnement (un mentorat) même si ce n'est pas dans le cadre du GSoC ou si vous n'êtes pas étudiant.

Si vous envisagez de contribuer, considérez la section "Contexte pour réaliser une compilation" pour obtenir un environnement de développement.

Notez que faire des contributions substantielles à un projet aussi grand et englobant que le GNU Hurd n'est pas une tâche triviale. Pour travailler sur les boyaux du Hurd et obtenir un résultat utile, vous devez prévoir une expérience d'apprentissage de nombreux mois qui nécessitera suffisamment d'auto-motivation. Travailler sur un noyau de système d'exploitation avancé n'est pas quelque chose que vous pouvez faire en quelques minutes, d'autant moins sans expérience préalable de bidouillage sur un noyau.

De même, les mainteneurs du noyau Linux constatent exactement les mêmes difficultés, ce qui est bien présenté par Jonathan Corbet dans son rapport sur le "Linux Kernel Summit" 2010 à l'occasion des sessions d'ouverture au sujet de l'accueil de nouveaux participants (en anglais).

Cependant, bien sûr, ces propos ne se veulent pas dédaigneux et il ne s'agit pas de vous effrayer, au contraire : démarrez simplement en utilisant le GNU Hurd et notez ce qui pour vous ne fonctionne pas comme attendu, ou jetez un œil à l'une des questions ouvertes (sur le suivi des bugs) et l'équipe du projet verra si vous évoluerez jusqu'à être le prochain "core hacker" du Hurd !

Feuille de route XKCD :)

La sortie de GNU/Hurd 1.0 est prévue, selon les progrès actuels, en 2059. Néamoins, d'autres facteurs externes sont en jeu et il n'est pas certain que la feuille de route actuelle soit respectée.

Télécharger ce contenu au format Epub

Lire les commentaires

Samedi 13 juin 2015 cinquième Journée du Libre à Vincennes

23 avril, 2015 - 22:27

Proposez vos animations à la cinquième Journée du Libre à Vincennes

Date : samedi 13 juin 2015 de 11 heures à 18 heures

Lieu : EFM Espace de Formation au Multimédia de Vincennes
Premier étage de la Médiathèque Cœur de Ville
98 rue de Fontenay 94300 Vincennes, en face de la Mairie
RER ligne A station Vincennes, métro ligne 1 station Château de Vincennes

Événement grand public, entrée libre et gratuite.

  • logiciels libres
  • aide à l'installation de toute distro GNU/Linux
  • matériel libre : cartes Arduino, Raspberry…
  • imprimantes 3D, électronique, robotique
  • exposants
  • conférences
  • ateliers

Pour participer, merci de contacter l'EFM et Parinux et de compléter le bloc-notes

  • responsable de l'EFM : M. Gilles Carnelez gcarnelez at vincennes.fr
  • animateur de l'EFM : M. Grégoire Babiaud gbabiaud at vincennes.fr

À bientôt !

Télécharger ce contenu au format Epub

Lire les commentaires

OcLaunch, launch automagically

22 avril, 2015 - 23:10

J'ai commencé à écrire il y a un an déjà une petit programme en ligne de commande qui répond au besoin suivant : lancer progressivement (tout au long d'une session) des programmes, avec un ajout/retrait de la liste aussi aidé et rapide que possible.

Génèse du projet

L’idée de base était d’afficher régulièrement une liste de tâches avec Taskwarrior.

Après coup, on se rend compte que ça peut servir à programmer des tâches pour un prochain démarrage (finir de télécharger la dernière distribution à la mode, compresser un dossier, planifier une mise à jour…) ou à utiliser aisément un client en ligne de commande (par exemple profanity ou irssi).
L’avantage par rapport au simple ajout de la commande dans le bashrc, c’est qu’on ouvre son terminal une première fois, le client de clavardage (par exemple) s’affiche et au deuxième lancement, pas de nouvel affichage, on peut travailler.

Fonctionnalités actuelles
  • Ajout aisé de programmes (graphiques ou en ligne de commande) par envoi sur l’entrée standard de la commande ou édition du fichier de configuration
  • Liste des programmes actuels
  • Suppression très facile
  • Fichier de configuration alternatif
  • Installation facile avec 0install & simple ajout de la commande oclaunch au bashrc
S’approprier le programme

J'attends vos retours avec impatience ! Je serai ravi d’ajouter des fonctionnalités (il y a déjà une bonne TODO list, si vous voulez participer). Contactez-moi par courriel par exemple leowzukw CHEZ vmail POINT me

Le logiciel est bien entendu libre (licence CeCILL) et hébergé chez Tuxfamily. Merci à eux !

Télécharger ce contenu au format Epub

Lire les commentaires

SuperTuxKart 0.9 est sorti

22 avril, 2015 - 20:03

SuperTuxKart est un jeu de course de kart avec Tux comme héros et d'autre mascottes de logiciels open source (Gnu, Gimp, Suzanne de blender, Xue la souris d'XFCE, etc).

La bande annonce est disponible sur youtube

Après plus d'un an de développement, la 0.9 qui est sortie il y a quelques jours embarque pour la première fois le nouveau moteur de rendu nommé Antarctica commencé durant la participation du projet au Google Summer of Code 2013. Ce changement important permet d'avoir une meilleure qualité visuelle avec notamment des ombres et lumières entièrement dynamiques, le ciel qui illumine la piste et des réflexions sur les surfaces métalliques.
La seconde partie de l'article vous en dira beaucoup plus…

Un nouveau moteur de rendu

Vlj a amélioré de manière significative notre moteur de rendu. Celui-ci, bien qu’utilisant toujours irrlicht, possède maintenant un backend de rendu OpenGL moderne à base de shader. Pour éviter toute confusion avec le moteur irrlicht de base, les développeurs de SuperTuxKart lui ont donné son propre nom : Antarctica.
En plus du travail de vlj sur le moteur de rendu, le travail de refonte du moteur a été entamé par Cand durant le Google Summer of Code 2013 (GSOC). SuperTuxKart a participé par 2 fois à ce programme, en 2013 et 2014.

Les nouveautés
  • nouveau moteur graphique à base de shader
  • deux nouvelles pistes ont été créées afin de démontrer les possibilité du nouveau moteur.
  • le Temple cacao, une piste au Val Verde, pays fictif d’Amérique du Sud avec des pyramides anciennes et de jungles luxuriantes
  • l'île de Gran Paradiso, une superbe île tropicale réputée pour ses plages sablonneuses et l’aéroport international Princesse Sara avec ses atterrissages spectaculaires.
  • les anciennes pistes ont été mises à jour pour être compatibles avec le nouveau moteur et utiliser les nouvelles fonctionnalités.
  • nouveaux karts Amanda, Gavroche, Sara
  • amélioration des karts tux, adiumy, Suzanne et Xue.
  • connexion en ligne qui permet d'entrer en contact avec des amis et de voir quand ils jouent, voter pour les addons, partager des accomplissements
  • un éditeur de Grand Prix intégré au jeu
  • un Grand Prix aléatoire
  • un système d’accomplissements

L'arrivée d'un nouveau moteur demande également un PC plus puissant avec au minimum OpenGL 3.1 afin de pouvoir jouer correctement au jeu. Basé sur les tests faits par l'équipe de développement voici les spécifications minimales officielles.

  • GPU: ATI / AMD Radeon HD 3650 | Intel HD 3000 | NVIDIA GeForce 8600
  • 600 Mo d’espace libre sur le disque dur
  • 1 Go de mémoire libre
  • Processeur de 1,2 GHz

Il se peut que malgré tout votre PC puisse faire tourner SuperTuxKart avec du matériel plus ancien, le plus simple étant de tester et d'ajuster les options.

Futur développement

Malgré toutes ces bonnes nouvelles, notez bien que la course en ligne n’est pas prête pour cette version. Cette version établit les bases qui permettront le jeu en ligne dans le futur (par exemple création de compte, authentification, etc.) mais le support pour le jeu en ligne en tant que tel est prévu pour une version future dans la série 0.9.

Depuis peu, des comptes en ligne gratuits pour tous les joueurs sont proposés (en vue du multijoueur). Le coût des serveurs n'étant pas nul, les développeurs font appel à vos dons pour payer les coûts de fonctionnement et de développement (par exemple, les coûts matériels).
Beaucoup de personnes ont déjà donné dans le passé. Nous avons décidé d’offrir un paquet de remerciements pour tous les donateurs (nouveaux ou ayant donné par le passé).
Le paquet contient plusieurs choses dont une piste nommée Antediluvian Abyss. Cette piste est encore en développement mais est entièrement jouable. Vous pouvez faire des courses, et l'utiliser avec l'éditeur de grand prix.

Cette piste sera incluse dans la version 0.9.1 de SuperTuxKart (et davantage de travail sera fait sur cette piste d’ici-là). Le paquet comprend également Carnival del cocoa, une version spéciale de cocoa temple de nuit qui a été utilisée dans le trailer, et certains concepts art. Il est distribué sous licence CC-BY-SA-NC 4.0.

Télécharger ce contenu au format Epub

Lire les commentaires

Apéro PHP à Lyon mercredi 29 avril 2015

22 avril, 2015 - 18:04

Un apéro PHP aura lieu à Lyon le jeudi 29 avril 2015 à partir de 19h à l'Antre-Autre (11 rue Terme, Lyon 1er). Cet apéro permettra aux aficionados de PHP de se rencontrer et de partager autour de ce langage de programmation.
Au cours de cette soirée, Thomas Jarrand et Emeric Kasbarian de l’agence web élao nous feront une présentation intitulée « Patate vs Pomme de terre : ça va se friter ! (Beauté vs Efficacité : l’affrontement !) »

De manière un peu plus détaillée :

Bien développer, c’est savoir mixer intelligemment la qualité à l’efficacité.

Entre les dates limite que l’on doit respecter, les patrons de conception (design patterns) que l’on veut mettre en place et le budget disponible, l’équation est complexe. On nous donne plein de solutions toutes faites… Est-ce qu’il ne faudrait pas juste apprendre à bien doser ?

On vous propose de se poser 30 minutes ensemble pour y réfléchir, à travers l’exemple du CQRS (Command Query Responsibility Seggregation).

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie du noyau Linux 4.0

22 avril, 2015 - 14:10

La sortie de la version stable 4.0 du noyau Linux a été annoncée le 12 avril 2015 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 se trouve dans la seconde partie de la dépêche.

Sommaire En bref

Après de longues discussions, ce noyau n’est pas le 3.20, mais le 4.0. Rétroactivement, on pourrait justifier cela grâce à l’arrivée de la modification à chaud du noyau, ou que compter au‐delà de vingt n’est pas une sinécure : c’est selon.

La nouveauté principale du noyau est la mise à jour du noyau à la volée. Du coté des pilotes graphiques, la gestion atomique du mode graphique a été introduite en mode expérimentale. Pour finir, le drapeau lazytime a été introduit dans la couche d'abstraction VFS afin de booster les performances de atime.

Annonces des versions candidates par Linus Torvalds RC-1

La version RC1 est sortie le dimanche 22 février 2015 :

Voyons quelle proportion, le cas échéant, va être cassée par ce changement de version.
Probablement moins que pendant la période du 3.0, mais j’imagine bien quelqu’un cherchant des versions significatives.

Parce que le peuple a parlé, et même si la plupart des interventions n’étaient qu’un charabia complet, les nombres ne mentent pas. Le peuple a préféré 4.0, et ce sera 4.0. À moins que quelqu’un ne surgisse avec un bon argument contre.

Jusque là, les arguments contre semblent avoir été « un numéro majeur devrait aller avec une fonctionnalité majeure ou une rupture de compatibilité », ce qui montre le peu que les gens connaissent. Nous ne cassons pas la compatibilité, et nous n’avons pas fait de sorties basées sur une fonctionnalité depuis, en fait, le début.

D’un autre côté, l’argument le plus fort pour certains des partisans d’une version 4.0 semble avoir été le souhait de voir une 4.1.15 — parce que « c’était la version de Linux que Skynet utilisait pour le T-800 ».

Donc, au final, je ne voudrais pas trop lire [le destin] dans ce numéro.

Sur le plan réellement technique, c’était plutôt une petite version. En considérant les normes actuelles. Elle est assurément notablement plus petite que certains noyaux récents, même si nous parlons de ~9k de modifs hors fusion plutôt que de 10-11k, donc ce n’est pas comme s’il y avait une énorme différence.

L’infrastructure de mise à jour à chaud a fait la une, mais mes fonctionnalités favorites sont personnellement les quelques nettoyages de mémoire virtuelle, par lesquels cette sortie nous débarrasse du code de correspondance non linéaire largement inutilisé (remplacé par une émulation avec beaucoup de mises en correspondance plus petites) et unifie la prise charge des tables de pages pour NUMA et PROTNONE.

Mais personne ne devrait le remarquer. Parce que passer en 4.0 ne veut pas dire que nous avons changé de quelque manière que ce soit ce que voient les gens. Ça n’est que la continuité, avec seulement des plus petits chiffres, de manière à ce que je puisse faire des sorties sans avoir à retirer à nouveau mes chaussettes.

Allez‐y, testez. Les arborescences Git sont déjà là, l’archive tar et les correctifs vont sortir au moment où j’écris. Bien sûr, avec le changement de version, je suppute qu’il y aura quelques hoquets avec les miroirs de kernel.org, même si Konstantin pense que tous les scripts sont déjà prêts. Donc, si vous ne trouvez pas les archives tar et les correctifs, soit j’ai déconné, soit c’est Konstantin. :)

Linus

RC-2

La version RC2 est sortie le mardi 3 mars 2015 :

Ainsi la RC2 a loupé le créneau habituel du dimanche après‐midi, parce que j’ai passé la plupart du week‐end à déboguer un problème qui apparaissait sur un vieux Mac Mini que j’avais dans le coin, et que je déteste faire des sorties, même en début de RC, avec des problèmes sur des machines auxquelles j’ai directement accès. Même si cela a seulement affecté de vieilles machines que les vrais développeurs ont peu de chance d’avoir ou du moins d’utiliser.

Aujourd’hui, j’ai le correctif de Daniel Vetter le corrigeant, donc, plutôt que de faire une RC2 du dimanche soir, c’est une du mardi matin. Allez la récupérer. Elle fonctionne mieux grâce à ce retard.

À part ce petit correctif d’une ligne pour i915 ? Pas grand chose en fait. Ce fut une semaine très calme, pour un début de processus de sortie. Bien sûr, la 3.19-rc2 était encore plus petite, donc cela poursuit une tendance, mais c’était la semaine de Noël. J’espère que ce faible volume est juste dû au fait que la fenêtre de fusion du 4.0 elle‐même était quelque peu plus calme que pour les toutes dernières sorties. Mais je suppute que la vraie raison est la mise en attente des arborescences des pilotes et du réseau de GregKH et davem, qui n’ont pas eu le temps d’être prêtes pour la RC2.

On verra.

En tout cas, la version courte du journal des modifications est en annexe, et les tests sont grandement appréciés.

Linus

RC-3

La version RC3 est sortie le dimanche 8 mars 2015 :

De nouveau en phase avec le calendrier des sorties du dimanche après‐midi, puisqu’il n’y a rien eu de particulièrement étrange cette semaine, et aucun bogue de dernière minute dont j’aurais eu connaissance ou que j’aurais voulu résoudre qui aurait repoussé l’échéance.

En termes de taille, on est aussi dans la normale, pas aussi petit que la RC2. Cela s’explique facilement par la récupération des correctifs de David et Greg (puisque le réseau et les pilotes ont tendance à être les deux plus grosses parties).

Et la répartition des correctifs est plutôt classique également : à peu près deux tiers de pilotes (processeurs graphiques, réseau, USB, staging, son, divers), le reste concernant les systèmes de fichiers (principalement NFS et Btrfs), des mises à jour d’architectures (ARC, x86, ARM, PowerPC), du réseau et de la documentation.

En d’autres termes, tout semble complètement normal à cette étape du processus de sortie.

S’il vous plaît, testez‐moi tout ça,

Linus

RC-4

La version RC4 est sortie dimanche 15 mars 2015 :

Hmm. Rien de particulièrement étrange cette semaine non plus, avec peut‐être juste une mise à jour légèrement plus grosse que prévue d’un système monopuce ARM. Donc, « seule » la moitié du correctif est composée de mises à jour de pilotes, la moitié restante étant des changements dans ARM.

Le reste est l’habituel mélange de divers correctifs — quelques autres architectures (S/390, Nios II), du réseau, du cœur de noyau et de la mémoire virtuelle, quelques mises à jour de la documentation. Rien ne se détache particulièrement ici. Le journal court est en annexe, je pense qu’on se débrouille bien à cette étape du cycle de sortie.

Linus

RC-5

La version RC5 est sortie dimanche 22 mars 2015 :

Alors, la RC5 est presque exactement de la même taille que la RC4. Je serais plus heureux si les RC rétrécissaient, mais je suppose que je devrais être reconnaissant qu’au moins elles ne semblent pas grossir.

Il n’y a rien de particulièrement inquiétant, bien que j’essaie toujours de penser à la régression de performance de l’équilibrage NUMA. Ça ne devrait pas être bloquant, mais c’est ennuyeux, et je veux que ce soit corrigé.
On y arrivera, j’en suis certain.

En attendant, la rc5 est principalement constituée de mises à jour de pilotes (à travers toute l’arborescence des pilotes : pilotes graphiques, USB, son, réseau, HID, entrées, contrôleurs de broches [pinctrl], etc.) avec quelques mises à jour d’architectures (x86, ARM, ARM64, SPARC) et quelques corrections de systèmes de fichiers (principalement Btrfs). Et, également, un soupçon de corrections du code réseau, hors pilotes.

Le journal court des modifications est en annexe, bien qu’il ne soit pas particulièrement intéressant. La plupart des gros correctifs étaient des retours en arrière, comme il se doit à cette étape.

Linus

RC-6

La version RC6 est sortie dimanche 29 mars 2015 :

Ça se calme gentiment, et il y a des corrections un peu partout. La régression de performance de l’équilibrage NUMA est corrigée, et les choses s’améliorent à nouveau de manière générale. Il y a eu un certain nombre de problèmes avec i915 et une double faute KVM qui a fait que pendant un bon moment j’étais quasi certain que ce serait un cycle qui irait jusqu’à une RC8, mais cela pourrait ne pas s’avérer nécessaire.

À part les problèmes susmentionnés, le gros de cette sortie est constitué principalement de petites correction de divers pilotes et de mises à jour d’architectures. Le journal court donne un meilleur aperçu de ce qu’il s’est passé.

Mais, s’il vous plaît, testez bien cette RC, et braillez s’il y a des régressions que nous aurions ratées.

Linus

RC-7

La version RC7 est sortie le lundi 6 avril 2015 :

Bon, la RC7 a un jour de retard, pour cause de dîner de Pâques. Pour compenser, elle inclut quelques corrections supplémentaires.

Mais elle est encore assez petite, et on est en bonne voie pour la 4.0 le week‐end prochain. Il y a une minuscule probabilité que je décide de repousser la 4.0 d’une semaine, simplement parce que je voyage la semaine d’après, et je pourrais vouloir éviter d’ouvrir la fenêtre d’intégration. Nous verrons comment je le sens le week‐end prochain.

En tout cas, rien de particulièrement étrange dans cette RC7. Elle contient à peu près trois quarts de mises à jour de pilotes (la plupart étant des pilotes réseau, mais il y a des trucs un peu partout : pilotes graphiques, IIO, entrées, USB…). Le reste est composé de quelques petites corrections sur x86, un peu de réseau, une correction concernant lazytime et de la documentation.
Et tout ça est assez petit.

Linus

Version finale

La version finale est sortie le dimanche 12 avril 2015 :

Alors, j’ai décidé de sortir le 4.0 selon le calendrier habituel, parce qu’il n’y avait vraiment aucun problème connu et, bien que je voyagerai à la fin de la semaine à venir en raison de la visite d’une université, j’espère que cela n’affectera pas trop la fenêtre de fusion.
On verra.

Linux 4.0 était une version assez petite, à la fois dans linux-next et par sa taille finale, bien qu’évidemment, « petit » est tout relatif. Elle fait tout de même plus de 10 000 commits non fusionnés. Mais, nous avons clairement eu de plus grosses versions (et, à en juger par linux-next, la 4.1 va être l’une des plus grosses).

Ce qui est une bonne chose. Cela colle parfaitement à « la v4.0 est supposée être une version stable », et absolument pas l’objet de nouvelles fonctionnalités expérimentales, etc. Je suis personnellement bien plus satisfait par les sorties planifiées que par la mauvaise époque où nous avions des sorties basées sur les fonctionnalités.

Ceci dit, il y a quelques éléments de numérologie intéressants amenés par la 4.0. En ne regardant que les statistiques dans git, cette version n’est pas juste celle faisant passer la barre du demi‐million de commits au total, mais également la limite des 4 millions d’objets git. De manière intéressante (si l’on regarde les modèles numériques), Linux 3.0 était le moment où nous nous avons dépassé le quart de million de commits et 2 millions d’objets git, donc il y a là un joli (et complètement non intentionnel) modèle concernant le dépôt git du noyau.

[Une autre rapide note historique de numérologie de bas de page : l’ancien historique de l’arbre BK approchait la limite de commits des 16 bits que BK avait à l’origine. Donc, ce « quart de million de commits » est vraiment pas mal du tout. Pendant toutes les années sous BK nous n’avons eu que 65 000 commits. Bien sûr, nous n’avons utilisé BK que pendant trois ans, et nous sommes maintenant avec Git depuis presque dix ans, mais tout de même — cela montre à quel point le processus global de développement s’est énormément accéléré].

En termes de fonctionnalités, le 4.0 n’a rien de vraiement spécial. On a beaucoup parlé de la nouvelle infrastructure de correction du nouveau noyau, mais en réalité, ce n’était pas la seule raison du changement de version, on a eu de bien plus gros changements dans d’autres versions. Donc, c’est davantage une version de « solide amélioration du code ».

Ramenez‐le et amusez‐vous,

Linus « nous sommes tous des moutons » Torvalds

N. D. T . : La version 4.0 a été nommée « Hurr durr I’m a sheep », soit « [onomatopées de votre choix] je suis un mouton » par Linus.

Les nouveautés Architecture ACPI

Les portables de marque Toshiba seront beaucoup mieux gérés : le pilote toshiba_acpi gère maintenant l’activation du mode « éco », de l’USB 3, de la charge rapide USB en veille, etc.

Pour avoir eu le plaisir d’utiliser une machine concernée depuis neuf mois, j’ajoute que ce n’est pas rien : au départ, le pavé tactile n’était pas géré (arrivé avec le noyau 3.18), l’écran ne se rallumait pas après une mise en veille, et la machine consommait deux fois plus de batterie.

Mise à jour du noyau à la volée Intérêt et champ d’application

Un nouveau système de mise à jour du noyau à la volée — c’est‐à‐dire sans redémarrer l’ordinateur, et donc sans interrompre (complètement) les services — a fait son apparition, sous le modeste nom de livepatch. La fonctionnalité est particulièrement intéressante pour les serveurs et probablement pour un grand nombre d’autres ordinateurs.
Comme on le verra plus bas, ce système de mise à jour n’est pas universel et ne permettra pas de mettre à jour l’ensemble du noyau, mais permettra notamment, on peut l’espérer, de mettre en œuvre des correctifs de sécurité sans redémarrer les systèmes, donc sans fenêtre de maintenance.

Historique

Au commencement, était kSplice, une solution de mise à jour à chaud du noyau révolutionnaire, ultérieurement rachetée par Oracle pour utilisation exclusive avec sa distribution, fermant la porte à Red Hat, SUSE, etc. S’ensuivirent des violations de GPL (temporaires), et d’autres piques à Red Hat.

L’année dernière, Red Hat et SUSE ont annoncé quasiment en même temps, respectivement kpatch et kGraft, toutes deux des solutions de mise à jour à chaud. Étant données les politiques respectives des deux entreprises, on pouvait espérer qu’une des solutions au moins se retrouve dans la branche principale du noyau.

Et ça n’a pas tardé, Red Hat et SUSE ont travaillé de concert en prenant les meilleurs élements de kpatch et kGraft.

Red Hat a eu l’idée d’utiliser une implémentation plus simple, qui utilise stop_machine(), c’est‐à‐dire qui arrête l’ensemble du système pendant quelques millisecondes, regarde la pile, et change le code de la fonction, si c’est sans danger, puis enlève le code de l’ancienne fonction, devenu inutile.

De son côté, SUSE décida de travailler au niveau des tâches elles‐mêmes : plutôt que d’arrêter le système, les tâches sont arrêtées une par une, et si une tâche doit appeler la fonction à mettre à jour, alors il est fait en sorte que ce soit la nouvelle qui soit appelée. Dès que chaque tâche a été traitée, l’ancienne fonction est enlevée, et le système tourne effectivement avec le nouveau code. L’avantage est que le système n’est arrêté à aucun moment, mais que la mise à jour peut prendre plusieurs minutes avant de se propager, car il faut également envoyer un signal de réveil aux tâches endormies pour garantir qu’elles ont été mises à jour. Regardez cette excellente présentation de kGraft à Kernel Recipes 2014 (en anglais) pour plus de détails.

Red Hat et SUSE ont tous deux accepté de migrer leurs solutions vers livepatch dès que celui‐ci sera suffisamment complet.

Implémentation

Les deux solutions sont basées sur ftrace, l’outil de traçage interne au noyau qui permet déjà de mettre à jour à chaud l’incipit des fonctions du noyau, pour tracer leurs appels à la demande. livepatch utilise une des toutes dernières évolutions de ftrace qui permet à plusieurs sous‐systèmes du noyau d’utiliser en même temps la mise à jour à chaud dynamique.

L’implémentation de livepatch qui vient d’arriver dans le noyau a pour but de combiner l’avantage des deux méthodes de kGraft et kpatch. Dans un premier temps, cela ne fonctionne que sur l’architecture x86, mais du travail est en cours pour PowerPC, S390 et ARM.

Concrètement, que voit l’utilisateur ?

Vous payez un abonnement à Oracle, Red Hat ou SUSE et votre serveur se met à jour tout seul.
Chaque mise à jour est en fait un nouveau module noyau à insérer (donc visible avec lsmod). Ce module utilise les API du sous‐système livepatch pour aller remplacer l’implémentation d’une fonction à mettre à jour, par une nouvelle fonction présente dans le module. Cela veut donc dire qu’on ne peut pas, par exemple, mettre à jour une structure (avec un nouveau champ), ou appliquer la totalité des mises à jour ainsi. C’est une opération coûteuse, car le module correctif est fait manuellement à chaque fois. À terme, cela devrait néanmoins permettre de corriger une partie des failles de sécurité découvertes dans le noyau sans devoir redémarrer la machine.

Voir l’exemple dans ce correctif et le message de ce correctif de fusion.

Développeurs KASan : Kernel Adress Sanitizer

KASan est l’équivalent pour le noyau d’ASan (Address Sanitizer). Il permet de détecter lorsque le noyau accède à des zones mémoire qu’il n’a pas explicitement alloué auparavant. Il a déjà été utilisé avec succès pour trouver des bogues dans le noyau (parfois en combinaison avec Trinity).

Tout ceci est réalisé à l’aide d’une combinaison de nouvelles fonctionnalités ajoutées au compilateur C de GCC pour suivre les accès à la mémoire. Lorsqu’un accès invalide est effectué, un message complet de la situation est affiché dans le journal système du noyau.

Pour cela, le noyau établit une « carte » représentant à l’échelle un huitième la mémoire adressable. Pour l’instant, seule l’architecture x86_64 est gérée. Chaque octet de la carte code la validité de l’accès à la zone de mémoire auquel il correspond. Cette carte est mise à jour par le noyau lors des allocations et désallocations mémoire et est consultée avant chaque accès à la mémoire.

KASan bénéficie du fait qu’une partie importante de ses fonctionnalités est implémentée directement dans le compilateur et ajoutée à la compilation dans le noyau. Il est donc plus rapide que kmemcheck, mais il ne peut pas détecter l’accès à des zones de mémoire non initialisées. D’autre part, DEBUG_PAGEALLOC et SLUB_DEBUG sont plus rapides que KASan, mais ils sont moins précis que celui‐ci.

Plus de détails dans l’article sur LWN.net : _The kernel address sanitizer.

Suppression de l’appel système remap_file_pages()

Comme annoncé l’an dernier, la mise en œuvre de l’appel système remap_file_pages() a été supprimée. À sa place, on a une fonction qui émule la même fonctionnalité utilisant de multiples zones de la mémoire virtuelle, de sorte que les (rares) applications utilisant cet appel devraient continuer à fonctionner. À noter qu’il n’y a pas de ruptures d’API ou d’ABI.

[article de LWN.net]

Nouvelles fonctionnalités pour l’outil perf

L’outil perf a bénéficié d’une nouvelle série d’améliorations diverses recensées dans le message du correctif de fusion.

Read-Copy-Update (RCU) pour fils d’exécution à priorité temps réel

Le noyau peut être compilé pour que le méchanisme de synchronisation des fils d’exécution (threads) appelé read-copy-update (RCU) à délai de grâce (grace-period-handling) fonctionnent avec des priorités temps réel. La plupart des systèmes n’en ont pas besoin, mais certaines charges de travail élevées peuvent tirer profit de cette fonctionnalité.

Tinyfication : suppression possible d’une version du sous‐système RCU

Le sous‐système read-copy-update gérant la mise en veille peut être compilé hors du noyau pour libérer de la place sur les systèmes allégés où il peut ne pas être nécessaire.

Voir l’article de LWN.net pour plus de détails.

Vérifications supplémentaire lors d’un appel à might_sleep()

La fonction de débogage might_sleep() va maintenant vérifier le débordement de pile. En effet, il semble que souvent, ce qui ressemble à un appel inapproprié à une fonction de mise en veille est en fait un artefact causé par un débordement de pile.

Méchanisme devfreq_event

Le nouveau mécanisme devfreq_event fournit un moyen pour les dispositifs en charge de la gestion d’énergie d’obtenir des données brutes sur les performances et l’utilisation de ces dispositifs.

Périphériques d’entrée Pavé tactile FocalTech

Une bonne nouvelle pour les possesseurs de portables Asus récents, la gestion des pavés tactiles FocalTech arrive enfin dans cette version du noyau. Auparavant, le périphérique était utilisable au travers de son émulation qui le faisait passer pour une souris USB générique. Cette prise en charge basique était déjà activée depuis le noyau 3.18, mais ne permettait que la reconnaissance d’un seul point de contact et des boutons physiques, le reste n’étant accessible qu’au travers d’un protocole propriétaire. C’est Mathias Gottschlag qui s’est attelé à la tâche de la rétro‐ingénierie et, alors que tout le monde s’attendait à un travail de longue haleine, il a déchiffré le protocole dans la journée. L’intégration a été plus longue, le temps de tester le pilote sur le plus de configurations possibles, les dernières modifications sont même arrivées dans la RC4.

Le pilote noyau étant compatible Synaptics, c’est donc un pavé tactile entièrement fonctionnel et réglable à souhait au travers de synclient qui nous arrive.

Pilotes graphique libres

Divulgation complète : cette partie a été écrite par le contributeur habituel, mais celui‐ci travaille maintenant pour Intel. Son discours peut donc être biaisé. Ce contributeur a cependant affirmé sur son blog qu’il resterait factuel et juste envers tous les pilotes, comme il s’est efforcé de le faire depuis le début de ses contributions. Cette partie reflète uniquement son opinion et pas celle de son employeur.

DRM (Direct Rendering Manager)

Les travaux sur la gestion atomique du mode graphique (introduite partiellement dans Linux 3.19) s’achèvent dans cette nouvelle version grâce à l’arrivée d’un nouveau IOCTL qui permet enfin d’effectuer un changement atomique. Couplés aux changements proposés par Rob Clark, qui rendent l’état entièrement stocké sous forme de propriété, il devient possible d’utiliser cette gestion atomique depuis l’espace utilisateur ! Cette fonctionnalité reste cependant encore masquée derrière le paramètre drm.atomic=1, probablement en attendant que plus de tests soient faits sur l’interface avant que celle‐ci ne devienne publique. Pour plus d’informations sur l’intérêt d’une gestion atomique du mode graphique, vous pouvez consulter la dépêche précédente sur le noyau 3.19. Pour plus d’informations sur les changements apportés spécialement dans cette version du noyau 4.0, vous pouvez consulter l’article de Daniel Vetter sur le sujet.

Comme d’habitude, cette nouvelle version du noyau apporte la gestion de nouveaux panneaux et écrans. Pour plus d’informations, vous pouvez consulter la demande d’integration.

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

AMD/ATI (pilote radeon)

La nouveauté principale de ce noyau pour le pilote Radeon est l’amélioration du code de gestion du son via HDMI et l’activation de la sortie audio Display Port pour toutes les générations de cartes qui le gèrent [commits].

Une autre nouveauté importante est l’intégration des modifications nécessaires pour faire fonctionner l’extension OpenGL 4.0 ARB_draw_indirect. Le code pour cette extension est déjà présent dans Mesa 3D.

La vitesse des ventilateurs pour les familles Southern Islands et Canary Islands (voir les désignations commerciales) peut maintenant être gérée manuellement par l’utilisateur, grâce à l’interface HWMON. La gestion automatique du ventilateur est, quant à elle, présente, mais désactivée par défaut, car elle est encore instable.

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

Intel (pilote i915)

La conversion du pilote i915 vers la gestion atomique du mode graphique continue. Dans cette nouvelle version, le pilote permet la mise à jour des plans graphiques de façon atomique. Il manque cependant encore la gestion asynchrone de cette mise à jour (qui sera disponible dans Linux 4.1) ainsi que la mise à jour des paramètres du filigrane (watermark).

Du côté de la gestion du mode graphique, un gros travail de réorganisation du code a été fait. Il reste cependant encore à retravailler la gestion des boucles à phase asservie (PLL) du bloc d’affichage, afin d’obtenir la gestion atomique des contrôleurs d’affichage vidéo CRTC. Ce travail a créé une régression dans le cycle RC5 qui a même pu être reproduite par Linus, sans pour autant que celui‐ci ne se mette en colère sur la fragilité de l’étape intermédiaire d’atomisation du mode graphique.

Une autre nouveauté est la gestion des listes d’exécution Execlists. Celles‐ci sont un nouveau mode d’envoi de commandes au processeur graphique introduit dans le matériel, en parallèle de l’ancien mode dans les processeurs Broadwell, et unique moyen d’envoyer des commandes aux processeurs graphiques Skylake et suivants. Ce nouveau mode est activé par défaut pour les processeurs qui le gérent.

La gestion du PPGTT (Per‐Process Graphics Translation Table), carte de correspondance mémoire vidéo par processus, est maintenant activée par défaut sur les processeurs gérant les Execlists. Il reste encore des bogues à corriger sur les processeurs plus anciens.

Si vous voulez en savoir plus, vous pouvez consulter l’habituel compte‐rendu détaillé des modifications de Daniel Vetter (mainteneur i915).

NVIDIA (pilote nouveau)

Peu de nouveautés majeures dans cette nouvelle version, à cause du travail nécessaire pour la gestion des nouveaux processeurs graphique Maxwell. Cependant, Ben Skeggs a profité du calme pour unifier les noms des différents composants avec les noms utilisés par NVIDIA. Cela va permettre une communication plus simple avec les ingénieurs de chez NVIDIA.

Ben Skeggs a également commencé le travail de séparation entre DRM et NVKM. À terme, cela permettra à plusieurs instances de Nouveau-DRM s’exécutant dans différentes machines virtuelles de pouvoir fonctionner en parallèle, et ainsi fournir une accélération complète dans chaque machine virtuelle. Pour l’instant, ce travail a uniquement consisté en le renommage des différents fichiers et structures.

Pour finir, les ingénieurs de NVIDIA ont ajouté la gestion manuelle du recadencement (reclocking) pour les processeurs graphiques monopuces GK20A. Ils ont également décidé de fusionner le module de détection de plate‐forme (nouveau_platform.ko) avec nouveau.ko afin, entre autres, de simplifier la gestion des symboles.

Pilotes grahiques pour systèmes monopuces Qualcomm (pilote msm)

Le pilote Linux pour les processeurs graphiques Adreno de Qualcomm s’améliore avec la gestion du eDP et des curseurs matériels mdp5. Ces derniers, ainsi que les curseurs matériels mdp4, se voient également dotés de la gestion du format YUV.

Pour plus d’information, vous pouvez consulter la demande d’intégration msm. Pour avoir un compte‐rendu de l’état du pilote msm + freedreno, vous pouvez consulter l’article récapitulatif de LWN.net sur la présentation de Rob Clark, le créateur initial et principal du projet.

NVIDIA (pilote tegra)

Du côté des processeurs graphiques Tegra de NVIDIA, la nouveauté principale est la conversion (semble‐t‐il complète) vers la gestion atomique du mode graphique. Bravo à Thierry Reding pour son travail !

Le pilote de blocs host1x a également été amélioré afin de gérer la mise en veille et le réveil des différents blocs qu’il contrôle.

Pour plus d’information, vous pouvez consulter la demande d’intégration tegra.

Renesas (pilote rcar-du)

Le pilote du processeur graphique de Renesas a reçu quelques améliorations liées à l’affichage, telles que la gestion des modes entrelacés ou la possibilité d’utiliser une horloge externe. Il est également maintenant possible de chaîner un encodeur HDMI après un encodeur LVDS.

Pour plus d’information, vous pouvez consulter la demande d’intégration rcar-du.

Samsung (pilote exynos)

La nouveauté principale du pilote pour les processeurs graphiques des systèmes monopuces de Samsung est la gestion du contrôleur d’affichage DECON qui est introduit dans les Exynos7. Ce contrôleur est apparemment très différent du contrôleur précédent qui avait été introduit dans les Exynos4.

La gestion atomique du mode graphique devait faire partie de cette nouvelle version, mais trop de bogues étaient encore présents pour rendre ce code disponible.

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

Réseau Algorithmes TCP d’évitement de congestion

Il est maintenant possible de choisir un algorithme d’évitement en fonction du destinataire, simplement via la table de routage. Par exemple :

ip route add 10.0.42.0/16 dev eth0 congctl hybla

Gestion des espaces de noms pour TIPC

L’implémentation du protocole de communication transparente interprocessus — Transparent Inter‐Process Communication protocol — gère désormais correctement les espaces de noms.

Identifiants de flux pour Open vSwitch

Le sous‐système Open vSwitch peut maintenant générer ses propres identifiants de flux (flow IDs) pour identifier les échanges réseau dans le trafic de commandes en mode utilisateur. Les performances de certaines opérations peuvent être améliorées jusqu’à 40 % grâce à cette amélioration.

Gestion des filtres eBPF pour le contrôle du trafic réseau

Le sous-système de contrôle du trafic prend désormais en charge l’utilisation de filtres écrits dans le langage de la machine virtuelle eBPF.

Sécurité Prise en compte des puces TPM 2.0

Les puces Trusted Platform Module 2.0 sont prises en charge [correctifs : 1, 2, 3].

Version 2.2.0 de la bibliothèque seccomp

Cette version de seccomp ajoute [annonce] :

  • la prise en charge des architectures [AArch64, MIPS, MIPS64, MIPS64 N32 ;
  • la gestion du nouvel appel système seccomp() et de la synchronisation des filtres pour les programmes à multiples fils d’exécution (multithreads) [Cf. dépêche 3.17] ;
  • l’inclusion des bibliothèques de liaison (bindings) pour Python ;
  • la mise à jour de la liste des appels système disponibles (noyau 3.19).
LSM

David Howells a corrigé la façon dont les différents modules LSM effectuaient certaines vérifications sur les nœuds d’index (inodes) pour améliorer la prise en compte du système de fichiers OverlayFS [correctifs : 1, 2, 3, 4, 5 et 6].

SELinux Gestion de Binder

Le mécanisme de communication interprocessus Binder, propre à Android, est maintenant contrôlable à l’aide des « crochets » LSM et la prise en charge de SELinux a été ajoutée dans cette version [correctif].

SMACK

La gestion du marquage de paquets réseau à l’aide de secmark de Netfilter a été ajoutée pour les paquets locaux en IPv4 et IPv6 [correctif]. Les étiquettes CIPSO sont utilisées dans les autres cas [correctif].

Les opérations sur les fichiers et les accès bidirectionnels à un socket UNIX sont désormais contrôlées et auditées correctement [correctifs : 1, 2 et 3].

Un autre cas particulier où une zone de mémoire partagée liée à un fichier situé sur un tmpfs pouvait se retrouver avec la mauvaise étiquette a été corrigé [correctif].

L’utilisation de KASan a permis de corriger un cas potentiel d’utilisation d’une zone mémoire après qu’elle a été libérée [correctif].

Liste non exhaustive des vulnérabilités corrigées Systèmes de fichiers Lazytime

Sur les systèmes de fichiers POSIX, trois dates sont associées à chaque fichier (en réalité à chaque nœud d’index) : mtime correspond à la date de dernière modification du contenu, ctime correspond à la date de dernière modification des métadonnées (propriétaire, groupe, droits…) et enfin atime correspond à la date du dernier accès.

Le champ atime a été l’objet de nombreuses critiques au cours du temps, chaque lecture du fichier entraînant une opération d’écriture afin de mettre à jour le champ. Pour éviter de multiplier les écritures inutiles, plusieurs stratégies successives ont été développées sous forme d’options de montage des systèmes de fichiers.
Voici un résumé des anciennes solutions (consultez la page de manuel de mount pour avoir des détails) :

  • atime et diratime pour le fonctionnement historique ;
  • noatime et nodiratime sont les plus simples, le champ atime n’est plus mis à jour en cas d’accès en lecture ;
  • relatime pour ne faire les mises à jour de atime que dans le cas où il n’y avait pas eu de lecture depuis la dernière écriture, l’option inverse étant norelatime ;
  • strictatime pour forcer le mode atime.

Une nouvelle option de montage des systèmes de fichiers a été intégrée au noyau : lazytime. Cette dernière maintient la date de dernier accès dans atime, mais la conserve uniquement en mémoire. Tout le système voit donc des champs atime mis à jour conformément à la norme. Ces modifications sont reportées sur le disque dans les cas suivants :

  • le nœud d’index doit être modifié pour toute autre raison ;
  • l’application force une synchronisation (fsync, syncfs ou sync) ;
  • en cas de manque de mémoire ;
  • toutes les 24 heures (ext4 uniquement pour le moment, c’est le comportement récent de relatime sur ce système de fichiers).

L’objectif est de réduire les écritures disque liées à atime de manière plus efficace que relatime, en profitant des écritures obligatoires, et de gagner en précision et fonctionnalités, en rétablissant le comportement historique de atime.

Cette option, initialement développée pour ext4 a finalement été remontée au niveau de la couche [VFS] pour permettre à tous les types de systèmes de fichiers d’en profiter. Pour ceux qui sont intéressés, LWN.net y a dédié un article (en anglais).

Btrfs

Entre autres, grâce au déploiement de Btrfs au sein de grosses grappes de serveurs chez Facebook, Josef Bacik a corrigé un problème dans lequel le système de fichiers retournait à tort des erreurs de type « manque de place » (ENOSPC).

Le code de gestion des niveaux RAID 5 et 6 a été nettoyé. Un bogue a cependant été introduit et a retardé la demande de fusion. Le correctif a, quant à lui, été édité le lendemain même.

Ceph

RBD (la version « périphérique de type bloc » du client Ceph) exploite maintenant le composant « multi‐queue » du noyau, ce qui devrait en améliorer les performances. De plus, l’option tcp_nodelay est maintenant prise en compte, afin de réduire la latence.

De son côté, CephFS reçoit de nombreux correctifs.

Pour plus d’informations, veuillez consulter la demande d’intégration.

F2FS

F2FS, le système de fichiers spécialisé pour les mémoires Flash n’a subi que des modifications mineures, nettoyage de code et correction de bogues [demande d’intégration].

OverlayFS

OverlayFS a été intégré dans le noyau 3.18. Ce système de fichiers, principalement utilisé par les distributions sur support autonome (live), s’est vu ajouter la gestion du multicouche en 3.19. Dans ce nouveau noyau est ajoutée la possibilité d’avoir de multiples couches en lecture seule. La couche supérieure accessible en écriture est désormais optionnelle [demande d’intégration].

pNFS

Le sous‐système parallel NFS (pNFS) a obtenu la prise en compte de la disposition FlexFile en cours de développement. Cette disposition permet aux métadonnées de fichiers d’être stockées à un endroit différent du contenu des fichiers.

Virtualisation VirtIO

Rusty Russel a annoncé l’implémentation de la version 1.0 du standard VirtIO selon les spécifications OASIS.

Ces périphériques dédiés aux environnements virtuels, permettent aux invités d’utiliser des pilotes et mécanismes de découverte standards et documentés, plutôt que des variantes par type de systèmes d’exploitation ou d’environnements.

L’intérêt pour un standard (plutôt qu’un billet de blog et le code) s’est montré avec l’adoption massive de VirtIO. On ne le retrouve pas que dans KVM, il est aussi utilisé dans Xen, VirtualBox, BHyVe (l’hyperviseur de FreeBSD) et même dans les ordiphones, pour communiquer avec les accélérateurs matériels.

Plus de détails dans l’article Standardizing virtio de LWN.net.

KVM

Une amélioration est commune à toutes les architectures, il s’agit d’introduire une scrutation (polling) lorsqu’une instruction d’arrêt HLT (ou équivalent sur d’autres architectures) est exécutée sur l’invité. Cela peut diminuer la latence jusqu’à 50 %. Actuellement, il faut l’activer manuellement, mais le but à terme est d’avoir une activation automatique.

  • ARM : émulation du contrôleur d’interruptions GICv3 ;
  • S390 (ordinateurs centraux IBM) : une petite victoire pour le développement du noyau Linux, il est maintenant possible d’avoir les identifiants uniques UUID et les noms longs d’invités dans /proc/sysinfo avant que cette fonctionnalité soit disponible dans l’hyperviseur d’IBM ;
  • x86 : prise en charge de la journalisation des modifications des pages mémoire (page modification logging), une nouvelle fonctionnalité des processeurs Xeon Broadwell qui accélère le suivi des dirty pages. La virtualisation imbriquée gère l’APICv (des instructions processeur qui accélèrent l’émulation des contrôleurs d’interruptions programmables — APIC — dans les machines virtuelles). Enfin, la latence des minuteurs (timers) d’interruption de type TSC deadline peut être réduite avec une nouvelle option (ces minuteurs permettent de soulager le processeur en demandant au contrôleur d’interruptions de générer une interruption quand le temps est écoulé, au lieu de laisser ce calcul au processeur).

Toutes les architectures ont, bien sûr, reçu des correctifs de bogues.

Xen

Pas de nouveauté pour cette version.

Pages de manuel

Les pages des manuels continuent d’être mises à jour régulièrement. Les dernières nouveautés depuis la dernière mention dans ces colonnes sont listées dans le journal des modifications.

Le bilan en chiffres

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

En nombre de modifications, on se situe à un peu plus que 10 000, soit environ 2 400 modifications de moins que la version précédente du noyau, ce qui en fait le cycle le plus calme depuis quelques années. Cependant, ce « calme » est relatif puisque 403 000 lignes de code ont été ajoutées alors que 222 000 lignes ont été supprimées, ce qui a conduit à une augmentation nette de 181 000 lignes. Le nombre de contributeurs reste, quant à lui, relativement constant avec 1 403 auteurs.

Pour une fois, le développeur ayant apporté le plus de modifications n’est pas H. Hartley Sweeten, pour son travail de nettoyage des pilotes Comedi, mais Lars‐Peter Clausen, pour son travail de nettoyage et d’amélioration des pilotes audio. Du côté des développeurs ayant le plus modifié de lignes, Ben Skeggs remporte la palme par son travail de renommage des puces et la séparation de NVKM et DRM (voir la sous‐section sur le pilote Nouveau).

Environ 200 entreprises ont participé à l’élaboration de ce noyau. En tête, on retrouve Intel, qui a effectué 11,6 % des changements que l’on peut trouver dans cette nouvelle version. En deuxième place, Red Hat a contribué pour 7,0 % des changements. Il est cependant important de noter que les développeurs sans affiliation ont effectué 8,6 % des modifications, soit juste un peu moins qu’Intel, alors que les personnes non identifiées ont écrit 7,1 % des modifications. On peut donc dire, bien que le noyau soit majoritairement écrit par des employés d’entreprises, que les contributeurs indépendants sont toujours les bienvenus et sont même une majorité !

Appel à volontaires

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

Mainteneur Contributeur(s) La phase de test Aucun Pierre Mazière et Davy Defaud Arch Romain Perier Jiehong Développeurs Aucun Pilotes graphiques libres Martin Peres Réseau Aucun Systèmes de fichiers Aucun Kioob, Mali Sécurité Timothée Ravier Virtualisation Xavier Claude Édition générale Aucun Martin Peres et 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 et de volontaires.

Nous sommes particulièrement à la recherche de mainteneurs pour les sections Systèmes de fichiers et Réseau, les précédents n’ayant pas donné de signes de vie pendant la rédaction des dernières dépêches.

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. La page wiki Rédiger des dépêches noyau signale quelques possibilités pour aider à la rédaction et s’y impliquer (ce que tout inscrit peut faire, ne serait‐ce que traduire^Wsynthétiser les annonces de RC). Essayons d’augmenter la couverture sur les modifications du noyau !

Télécharger ce contenu au format Epub

Lire les commentaires

Ultracopier 1.2

22 avril, 2015 - 14:02

Ultracopier est un logiciel de copie de fichiers. Il remplace la copie de fichiers de votre gestionnaire de fichiers. Il permet la limitation de la vitesse, la pause/reprise, la gestion de la liste de copie et la gestion des erreurs et collisions.

Au menu :

  • optimisation apprise dans CatchChallenger, passage vers Qt 5.4 pour toutes les platformes, nouveau algorithme de calcul du temps restant et choix de ce dernier ;
  • divers changements et correction de divers bugs mineurs ;
  • mise à jour complète de la plateforme de compilation et publication ;
  • Supercopier et Ultracopier ont maintenant le même numéro de version ;
  • l'utilisation clef pour l'achat de la version ultimate est en place comme pour CatchChallenger (la dernière version 1.0 a duré plus de 4 ans avec mise à jour gratuite) et changements de boutique.
  • et le plus important sur LinuxFr.org : meilleur support de Linux car la dépendance à Qt System qui posait des problèmes avec un certain nombre de distributions a été supprimée lors du passage à Qt 5.4.

L'avancement est plus lent pour avancer sur le projet CatchChallenger qui est un MMORPG libre.

Télécharger ce contenu au format Epub

Lire les commentaires

Grammalecte, correcteur grammatical

22 avril, 2015 - 01:16

Grammalecte est un correcteur grammatical récent (né en janvier 2011), écrit en Python, dédié à la langue française, et, pour l’instant, uniquement disponible pour LibreOffice et OpenOffice. Une campagne de financement participatif est lancée pour porter Grammalecte sur Firefox et Thunderbird et en faire par ailleurs un serveur indépendant (voir plus bas). Cette dépêche peut donc intéresser tous ceux qui s’intéressent à la grammaire.

Sommaire

Grammalecte est un dérivé de Lightproof, un correcteur écrit initialement pour le hongrois. Le logiciel s’est peu à peu éloigné de Lightproof avec les années. Même si Lightproof a été conçu pour gérer diverses langues, j’ai eu besoin de modifier nombre de choses dans le moteur interne pour le rendre efficace pour le français. Sans cela, pas grand-chose n’aurait été possible.

Ce correcteur est né un peu par hasard. En 2010, j’avais décidé de m’occuper de la partie française de LanguageTool, avec réticence, car je n’aime ni le Java et ni le XML dans lequel sont écrites les règles de grammaire. Par ailleurs, je voulais contrôler le processus de création des règles de contrôle. Or, à l’époque, LanguageTool possédait de nombreuses règles que je n’aimais pas, qui généraient beaucoup de faux positifs, mais il eût été indélicat d’envoyer à la benne tout ce qui me déplaisait. Enfin, comme je ne pouvais pas non plus ajuster certaines règles typographiques comme je l’aurais voulu (le développement étant centralisé, il fallait convaincre), j’ai finalement laissé tomber et je me suis penché sur Lightproof, qui avait l’avantage de fournir un kit minimal à partir duquel je pouvais faire comme je l’entendais. Je voulais me concentrer sur l’essentiel, éviter autant que possible les faux positifs, et être assez strict sur les questions typographiques. J’ai d’abord travaillé pour moi, surtout par curiosité, afin de voir ce qui était possible.

Après pas mal de déboires divers, la première version alpha paraît en janvier 2011 et connaît un petit succès d’estime. Du coup, bien que je n’avais pas vraiment l’intention de me consacrer à ça, j’ai mis le doigt dans l’engrenage.

Principes de fonctionnement

D’une manière générale, Grammalecte est un correcteur utilisant les motifs de correspondance (“pattern matching”) pour détecter les erreurs. Il examine le texte qu’on lui passe en se basant sur une liste de règles de contrôle, qu’il faut bien sûr écrire à l’avance parce que le correcteur ne peut pas deviner ce qui est une erreur, il ne fait pas de suppositions. Pour savoir à quoi correspondent les mots, il se base sur un lexique qui lui indique leur nature grammaticale. Les règles de contrôle sont décrites par un motif de détection d’erreur, des conditions d’applications, un message informatif et si possible des suggestions. (Détecter une erreur et suggérer une correction sont deux choses plus distinctes qu’il n’y paraît. Suggérer peut s’avérer plus difficile que détecter une erreur, je reviendrai sur ce point plus tard.)

Un motif de détection est une expression régulière plus ou moins complexe. Une fois un motif détecté, il est en général nécessaire de faire une analyse plus poussée des éléments, notamment en examinant la nature grammaticale des mots du motif repéré, ce qui se fait par d’autres expressions régulières. Bref, on lance des expressions rationnelles tous azimuts, tout le temps. Les conditions d’application et l’analyse des motifs trouvés se font avec du code ad hoc en Python, simple ou complexe, c’est selon.

La difficulté de fonctionner avec des motifs de correspondance, c’est que les règles à écrire sont innombrables, tant l’écriture d’une langue humaine recèle de possibilités, tant le nombre d’erreurs possibles est grand. Par ailleurs, les faux positifs (ou fausses alertes) sont très difficiles à éviter. Car, s’il est facile d’écrire une règle pour détecter une erreur dans un contexte donné, il est difficile d’écrire une règle valable pour tous les cas de figure possibles.

L’atout de Grammalecte pour faire face à l’explosion combinatoire des possibilités, c’est son préprocesseur de texte.

Le préprocesseur de texte est un outil qui transforme en interne le texte à corriger. Il le modifie pour simplifier le travail des règles de contrôle. Pour ce faire, il dispose de règles de transformation qui sont décrites par un motif de détection, des conditions d’application et une chaîne ou une fonction de remplacement.

Néanmoins, toutes les transformations ne peuvent être mises en œuvre en une seule fois. C’est pourquoi le correcteur va effectuer plusieurs passes sur le texte. Chaque passe s’effectue en deux temps : d’abord l’application des transformations du préprocesseur de texte, puis les règles de contrôle. Ceci permet de simplifier le texte au fur et mesure des analyses et de supprimer les éléments qui ont été vérifiés ou qui n’ont pas besoin de l’être, puis de se concentrer lors de la passe suivante sur d’autres points.

Le correcteur effectue à l'heure actuelle six passes sur le texte. (Théoriquement, il peut en faire un nombre infini, il suffit de spécifier dans le fichier des règles qu’on veut une nouvelle passe et d’écrire de nouvelles instructions.)

  • La première passe contrôle les paragraphes entiers et sert notamment à vérifier tous les aspects typographiques, les espaces insécables, les guillemets, les espaces surnuméraires.
  • Après cette première passe, le paragraphe est scindé en phrases.
  • La seconde et la troisième passe servent à contrôler notamment les accords entre les noms et les adjectifs, les pluriels, le genre, etc.
  • Les trois passes suivantes vérifient principalement les accords des verbes avec leur sujet, les participes passés, les formes interrogatives ou impératives.

Il n’est pas du tout exclu d’ajouter de nouvelles passes.

Historique des fonctionnalités

Grammalecte n’a pas toujours fonctionné ainsi. Dans la version 0.1, comme Lightproof, il faisait tout le travail en une seule passe, paragraphe par paragraphe. Il m’est vite apparu qu’il serait pratique d’effectuer le contrôle en deux temps, paragraphe par paragraphe, puis phrase par phrase. Et il m’a semblé judicieux de simplifier le texte entre les deux passes. Ainsi naquit la version 0.2, qui prenait déjà pas mal de distance avec Lightproof. Le préprocesseur de texte, qui n’était au commencement qu’une commodité, m’est apparu peu à peu comme un élément essentiel, un outil susceptible de résoudre des problèmes quasi insurmontables sans lui. C’est pourquoi, à partir de la version 0.3, le préprocesseur est devenu la baguette magique avec laquelle une quantité gigantesque de difficultés ont été résolues. À ce stade, le correcteur effectuait déjà cinq passes, et il a fallu plus tard en rajouter une sixième.

Avec la version 0.3 sont apparus les outils annexes : le lexicographe, le formateur de texte, puis le conjugueur.

Le lexicographe et le conjugueur sont deux outils dont le rôle est pédagogique : informer et aider l’utilisateur en cas de doute. Le lexicographe, avec un clic droit, donne de la nature grammaticale de n’importe quel mot. Le conjugueur permet de connaître, là encore en quelques clics, la conjugaison de n’importe quel verbe. Par exemple, un clic droit sur le mot “suis” vous permet d’accéder immédiatement à la conjugaison d’être et de suivre, ce qui évite la peine d’avoir à chercher sur le Net ou dans son dictionnaire. Comme un correcteur grammatical ne saurait corriger toutes erreurs possibles, il m’a toujours paru utile de fournir une aide pédagogique à l’utilisateur, car lui seul peut vraiment décider.


Le formateur de texte est un outil de correction typographique automatisé, qui propose de corriger la plupart des erreurs en un seul clic, même s’il en y a des milliers. Il propose aussi quelques fonctions de nettoyage et de restructuration d’un texte. Cet outil, que je jugeais anecdotique au commencement, est celui qui a suscité le plus d’engouement et que les utilisateurs ont le plus sollicité. Les outils qui bossent tout seul, ça semble beaucoup plaire. ;)

La version 0.4 apporte beaucoup d’améliorations internes, mais surtout des mécanismes de suggestion qui permettent enfin d’offrir dans la plupart des cas autre chose qu’un simple message d’erreur (parfois mystérieux pour ceux qui ne savent plus ce qu’est un COD ou un participe passé).

Comparaison avec LanguageTool

LanguageTool, comme Grammalecte, fonctionne avec des motifs de correspondance (“pattern matching”) chargés de déceler les erreurs. Et les similitudes s’arrêtent là. Dans le détail technique, tout est différent, et ces différences font que le potentiel qu’on peut tirer de ces deux logiciels n’est pas le même.

LanguageTool est très formaliste, il faut écrire des règles en XML. C’est descriptif, rigide et assez contraignant, mais il n’est pas difficile de rentrer dans le code des règles. Tout est assez intelligible, même si c’est verbeux.

Grammalecte, en revanche, est beaucoup moins formaliste, c’est plutôt un vaste chantier en cours de construction, avec pas mal de bizarreries, mais c’est plutôt souple, et on peut se permettre bien plus de fantaisies. En revanche, concernant la lisibilité des règles, disons que ce n’est pas son point fort, car les règles appellent directement du code en Python et il faut toujours garder à l’esprit qu’on analyse un texte qui va être modifié par le préprocesseur de texte. De plus, il faut se plonger dans le code du moteur pour comprendre ce que font certaines fonctions. Par ailleurs, l’ordonnancement des règles est primordial. Si vous déplacez quelque chose sans comprendre comment ça fonctionne et les principes généraux, il est fort probable que vous cassiez quelque chose. Même quand on connaît bien l’ensemble, c’est assez difficile, attendu que les effets de bord ne sont pas toujours évidents à estimer.

LanguageTool ne possède pas de préprocesseur de texte, il lui faut plus de règles de détection que Grammalecte pour faire des choses similaires. Il en faut tellement plus qu’il est peu probable qu’en l’état actuel, LanguageTool puisse faire bien des choses que fait Grammalecte aujourd’hui relativement aisément, car il faudrait écrire énormément de règles.

Mais LanguageTool dispose d’un outil que Grammalecte ne possède pas : un désambiguïsateur. LanguageTool n’effectue qu’une seule passe sur le texte, phrase par phrase. En premier lieu, il découpe les phrases en “tokens” (mots, ponctuations, guillemets, etc.). Puis, grâce à son désambiguïsateur, il fait de la désambiguïsation sur les “tokens” ambigus, c’est-à-dire qu’il détermine la nature grammaticale d’un mot quand il en a plusieurs (par exemple : “est” peut être un nom masculin, une conjugaison du verbe être, un élément d’une locution adverbiale “id est”). En somme, grâce à cet outil, LanguageTool pose des étiquettes explicatives sur les tokens. Puis, il analyse la succession des tokens selon les règles écrites. Il renvoie les erreurs et c’est fini. Ce qu’il faut retenir, c’est que la désambiguïsation permet d’avoir plus de certitudes dans l’analyse du texte.

De son côté, Grammalecte ne découpe pas les phrases en tokens. Dans Grammalecte, il n’y a pas de tokens ni même de mots à proprement parler, il n’y a que des zones de texte définies par des expressions régulières qui servent de déclencheurs pour une analyse spécifique des passages correspondant aux motifs trouvés. On ne travaille pas sur des éléments déterminés à l’avance, mais sur des zones, souvent des mots bien sûr, mais aussi des bouts de phrases ou des motifs de caractères sans nécessairement se soucier des délimitations des mots et de leur position dans le texte (même si on s’en soucie assez souvent comme vous pouvez l’imaginer). Je peux par exemple chercher un motif “ni… ni…” sans me soucier du nombre de “tokens” qu’il pourrait y avoir entre les deux “ni”, sans me soucier où c’est précisément. C’est souple, mais cette souplesse se paye par une plus grande complexité et c’est régulièrement l’occasion de faire des nœuds mentaux pour comprendre ce qui se passe, surtout pour gérer toutes les questions d’apostrophes, de majuscules, de traits d’union, de délimitations des mots (plus problématique que ce que vous pouvez supposer) et divers détails subtils qui n’ont l’air de rien, mais qui compliquent souvent la tâche de manière imprévue. Certains problèmes, on ne les auraient pas, ou seulement à moindre degré, avec des phrases découpées de manière prédictible et uniforme en “tokens”. Cela dit, la tokenisation ne semble pas la solution miracle non plus, si j’en crois ce que j’ai lu parfois sur la liste de discussion de LanguageTool, car il ne semble pas évident de gérer la question des apostrophes et des traits d’union.
Par ailleurs, dans Grammalecte, comme à chaque passe le texte est transformé, un même motif de correspondance ne renverra pas forcément la même chose selon la passe dans lequel il est lancé. Il faut toujours garder à l’esprit où on est dans le flux des règles de transformation et estimer ce qui se passe globalement.
Et, comme il n’y a pas de “tokens” dans Grammalecte, il n’y a pas non plus de désambiguïsateur qui pose des étiquettes sur les mots. Le correcteur fait quand même de la désambiguïsation, mais à la volée, c’est-à-dire que chaque règle se charge elle-même de s’y retrouver parmi les ambiguïtés du texte. C’est un désavantage par rapport à LanguageTool. Ce dernier permet d’écrire des règles dans un environnement plus “sûr” que dans Grammalecte où règnent l’incertitude et le flou. Cela dit, le préprocesseur de texte, encore lui, va nous épargner bien des peines et solutionner nombre de cas difficiles, en faisant faire de la “désambiguïsation” à sa manière, c’est-à-dire en supprimant tout simplement des zones de texte.
Les règles de transformation du préprocesseur de texte consistent pour la très grande majorité à faire du nettoyage, c’est-à-dire à effacer le superflu, ce qui, de fait, nous évite de faire un gros travail d’analyse. Certaines règles de transformation introduisent aussi dans le texte des caractères signalétiques que certaines règles de contrôle savent reconnaître. Et quelques règles servent réellement à modifier ce qui est écrit, là encore pour simplifier. Cette manière de faire apporte beaucoup d’avantages par rapport à LanguageTool, mais dans certains cas s’avère moins efficace que l’étiquetage. Le problème de Grammalecte, c’est une certaine forme d’amnésie, le préprocesseur nettoie et fait parfois du signalement, mais après ça chaque règle se débrouille seule.

Hormis les différences techniques inhérentes aux logiciels, la manière d’écrire les règles peut aussi faire varier grandement leurs capacités de détection. On peut écrire les règles de manière stricte (moins de détection d’erreurs, moins de faux positifs) ou audacieuse (plus de détection, plus de faux positifs). LanguageTool possède des règles de contrôle que je n’ai pas implémentées dans Grammalecte parce que je les trouve trop susceptibles de générer des faux positifs en l’état actuel des choses. Il y a des vérifications que Grammalecte fait que son rival n’essaie pas de faire (trop risqué ou compliqué pour lui). Ensuite, il y a les règles qu’un correcteur peut juger superflues. Par exemple, LanguageTool vérifie si vous écrivez correctement Britney Spears, Warren Buffett et des tas d’autres célébrités, ce que Grammalecte ne prend pas la peine de contrôler.

Le préprocesseur de texte par l’exemple

Mettons que nous tapons dans Writer :

Cette pièces de théâtre-là (http://www.site.fr/blabla) d’Albert Camus² sur «l’absurde» étaient, comme d’habitude, passionnants.

Trois erreurs grammaticales, deux typographiques.

Sachez d’abord que le texte que le correcteur reçoit ne correspond pas toujours au texte que voit l’utilisateur. En effet, les marques de formatage sont effacées. Si vous tapez des passages en italique ou gras, l’italique et le gras vont disparaître. Dans notre exemple, il y a le caractère “²”. Il peut être obtenu en tapant le caractère “²” ou tapant le caractère “2” et en le mettant en exposant. Dans le second cas, la mise en exposant est une marque de formatage. C’est probablement ainsi que l’utilisateur a obtenu ce caractère. Dans ce cas, le correcteur reçoit :

Cette pièces de théâtre-là (http://www.site.fr/blabla) d’Albert Camus2 sur «l’absurde» étaient, comme d’habitude, passionnants.

Autrement dit, même si l’utilisateur voit le caractère “²”, le correcteur reçoit le caractère “2”.

Passe 1. Pour commencer, le préprocesseur de texte va supprimer les URL (entre autres choses).

Cette pièces de théâtre-là (@@@@@@@@@@@@@@@@@@@@@@@@@) d’Albert Camus2 sur «l’absurde» étaient, comme d’habitude, passionnants.

Ensuite, les règles de contrôle vont vérifier les espacements, la ponctuation, les guillemets, etc. C’est lors de la première passe que le correcteur signalera qu’il faut des espaces insécables autour de “l’absurde”.

Passe 2. Les arobases sont supprimées. La note de référence “2” qui suit Camus est supprimée, ainsi que les guillemets. On obtient alors :

Cette pièces de théâtre-là (_________________________) d’Albert Camus_ sur _l’absurde_ étaient, comme d’habitude, passionnants.

Passe 3. C’est dans cette passe qu’on nettoie le plus. On supprime le “-là” qui suit “théâtre”. Le patronyme “Camus” est supprimé. Puis “d’Albert” est supprimé, ainsi que “comme d’habitude”. Puis “pièces de théâtre” est simplifié et réduit à un seul mot : “pièces”. Comme il n’y a plus que du vide entre les parenthèses et les virgules, on les supprime aussi. Ce qui donne :

Cette pièces _________________________________________________________ sur _l’absurde_ étaient __________________ passionnants.

Lors de cette passe, la première erreur d’accord sur “pièces” est repérée.

Passe 4, 5 et 6. Après la 3 ème passe, on considère que les accords dans les groupes nominaux ont été vérifiés. Donc on simplifie les groupes nominaux afin de pouvoir vérifier l’accord avec les verbes. Ce qu’on fera dans les 3 passes suivantes. Ici, “sur l’absurde” est supprimé puisqu’il ne peut être un sujet. Il reste :

Cette pièces _________________________________________________________________________ étaient __________________ passionnants.

À présent, il n’y plus rien à simplifier. Après la correction de “pièce”, le correcteur verra l’erreur sur “étaient” et après la correction de ce dernier, il pourra faire les bonnes suggestions sur “passionnants”.

Ce système n’est pas parfait. Voici un autre exemple.

Les petits étais endormis.

Ici, le correcteur ne détecte rien, car “étais” est aussi un nom masculin pluriel.

D’autres erreurs que le correcteur peut trouver grâce au préprocesseur de texte :

L’homme sur le bateau de Patrick viens de temps en temps mangé chez moi.
Ces marchands passe leur temps à se quereller.
Ils jugeront en toute impartialité de ce cas délirante.
Ils sont de manière si étonnante et si admirable arrivé à ce résultat…
Les tests grand public de Jean-Paul montre des résultats surprenants.
Ils ont à plusieurs reprises perdus leur sang-froid.
Ces attaques à main armée donne la chair de poule.
Réfléchir à tête reposée prends du temps.
Des chambres plus ou moins fortement éclairé.
Ce qui, la plupart du temps, donnes des maux de tête.
La N.S.A. espionneras toujours tout le monde.

Avec le dernier exemple, vous verrez l’une des choses que le préprocesseur réécrit pour faciliter le travail du correcteur. En interne, la graphie “N.S.A.” a été transformée en “NSA” (le message d’erreur trahit cette modification).

Le préprocesseur fait aussi de la simplification de certains syntagmes nominaux. Exemples :

armé jusqu’aux dents --> armé
fille au pair ---------> fille
médecin de garde ------> médecin

Le préprocesseur peut faire énormément de choses, mais il ne peut en l’état actuel résoudre tous les problèmes, car il doit lui-même demeurer prudent quand il fait face à des ambiguïtés. Dans bien des cas, il arrivera à simplifier les groupes nominaux. Dans d’autres cas, il n’y arrivera pas. Il y a encore beaucoup de progrès à faire sur ce chapitre. Concevoir un désambiguïsateur aiderait beaucoup. Un préprocesseur de texte associé à un désambiguïsateur, ce serait une combinaison utile pour accroître notablement la détection des erreurs.

Le dictionnaire

La graphie d’un mot français ne permet pas de déterminer sa nature. Un mot finissant par -ent peut être un nom, un adjectif, un adverbe ou la forme conjuguée d’un verbe. C’est pourquoi un correcteur grammatical ne peut souvent pas grand-chose sans un lexique étiqueté référençant tous les mots d’une langue. Cet étiquetage, c’est la base de la connaissance du correcteur. Le dictionnaire français pour Hunspell, le correcteur orthographique, est actuellement la source directe de Grammalecte.

Quelques données sur le dictionnaire :

  • plus de 77000 entrées,
  • toutes les entrées sont grammaticalement étiquetées,
  • environ 12 % d’entre elles sont sémantiquement étiquetées (médecine, informatique, botanique, etc.), mais cet étiquetage ne sert pas encore. Améliorer la base lexicale et son étiquetage, c’est l’une des tâches les plus importantes de la conception d’un correcteur grammatical.

Ce dictionnaire, vous l’avez probablement tous utilisé, puisqu’il est inclus dans Firefox, Thunderbird, LibreOffice, Chrome, Opera et une multitude de logiciels dont je serais bien en peine de faire la liste si on me la demandait. Cela dit, vous en utilisez peut-être une vieille version, je ne l’intègre qu’à LibreOffice et ne fournit des extensions que pour OpenOffice, Firefox et Thunderbird. L’intégration dans les autres logiciels est faite par d’autres personnes à des rythmes très divers.

Tout le travail sur le dictionnaire se fait sur Dicollecte, où sont collectées les propositions des utilisateurs.

Pourquoi la correction grammaticale est difficile

Commençons par un exemple :

Il est conseiller à la mairie. [Correct]
Il est aller à la mairie. [Incorrect]

Pourtant, l’étiquetage grammatical de ces phrases est strictement identique. Les mots “conseiller” et “aller” sont tous les deux à la fois un verbe à l’infinitif et un nom masculin. Or, un correcteur grammatical ne comprend absolument rien à ce que vous écrivez, même si vous ne faites aucune erreur. Il ne peut se baser que sur une suite d’étiquettes grammaticales.

Il est parfois irritant de s’entendre dire : “il y a une erreur ici, c’est évident”. Car, en fait, il y a rarement quoi que ce soit d’évident pour un correcteur grammatical. Le mot “évident” n’est lui-même pas seulement un adjectif, c’est aussi la conjugaison du verbe “évider” à la 3e personne du pluriel au présent. D’une manière générale, il semble souvent facile d’écrire une règle qui détecte les erreurs dans une phrase ou un contexte spécifique. En revanche, il est souvent difficile, voire impossible, d’écrire une règle qui détecte les erreurs dans tous les contextes sans générer nombre de faux positifs. Du coup, l’écriture des règles, c’est très souvent un compromis entre ce qu’on voudrait détecter et la tolérance pour les fausses alertes (la mienne est assez basse).

Autres exemples :

Des caractéristiques matériels [Incorrect]
Des matériels caractéristiques [Correct]
Des nouvelles caractéristiques [Correct]
Des matérielles caractéristiques [Incorrect]

Vous, humains, savez que “caractéristiques” est dans le premier cas un nom féminin. Mais c’est aussi un adjectif épicène. Le correcteur grammatical ne sait pas décider si ce doit être un nom ou un adjectif. Pour lui, “matériel”, “caractéristique” et “nouvelle” sont dans tous les cas nom et adjectif.

Autrement dit, l’étiquetage grammatical ne suffit pas. Seul le sens permet aux humains de trouver les erreurs. Mais, comme je l’ai dit, le correcteur ne comprend rien du tout. Il faudrait prendre le temps d’étiqueter les entrées avec des informations plus spécifiques, susceptibles de nous aider à contextualiser ce qu’on corrige. Une tâche titanesque. Nous en sommes encore loin.

Et ce ne sont là que des exemples très simples, très loin des phrases complexes qu’on peut écrire.

Parmi les difficultés du français, l’une des principales, c’est qu’il y a énormément de mots dont la nature grammaticale dépend du contexte :

tu ________ pronom personnel sujet épicène singulier // participe passé du verbe taire
lui _______ pronom personnel sujet masculin // pronom personnel objet masculin et féminin // participe passé du verbe luire
sommes ____ forme conjuguée de être // forme conjuguée de sommer // nom féminin ou masculin pluriel
ton _______ déterminant // nom masculin
son _______ déterminant // nom masculin
la ________ déterminant // nom masculin // pronom personnel objet
avoir _____ nom masculin // verbe auxiliaire
été _______ participe passé du verbe être // nom masculin
est _______ forme conjuguée de être // nom masculin // élément d’une locution latine (id est)
a _________ forme conjuguée de avoir // nom masculin invariable
avions ____ forme conjuguée de avoir // nom masculin pluriel
pas _______ adverbe de négation // nom masculin
une _______ déterminant // nom féminin (la une des journaux)
aura ______ forme conjuguée de avoir // nom féminin
as ________ forme conjuguée de avoir // nom masculin
contre ____ préposition // nom masculin singulier // forme conjuguée de contrer
vers ______ préposition // nom masculin singulier ou pluriel
mais ______ conjonction de coordination // adverbe // nom masculin pluriel
si ________ conjonction de subordination // adverbe // nom masculin
évident ___ adjectif masculin // forme conjuguée de évider
dément ____ adjectif masculin // forme conjuguée de démentir
prise _____ nom féminin // participe passé de prendre // forme conjuguée de priser
courant ___ nom masculin // participe présent de courir // préposition
or ________ conjonction de coordination // nom masculin singulier
plus ______ adverbe // adverbe de négation // nom masculin
point _____ adverbe de négation // nom masculin singulier
vis _______ nom féminin // forme conjuguée de voir et de vivre
montre ____ nom féminin // forme conjuguée de montrer
partis ____ forme conjuguée de partir // participe passé pluriel // nom masculin pluriel
vous ______ pronom personnel sujet ou objet.
nous ______ idem
etc.

Il y a de nombreux mots qui ont plusieurs natures grammaticales, et le correcteur doit trouver laquelle s’applique dans le contexte. Il faut constamment faire attention à ça, sinon c’est d’explosion de faux positifs assurée. Pourtant, malgré les règles de prudence, il y a toujours des faux positifs. Parce que si on ne signalait que les erreurs certaines, on ne signalerait pas grand-chose.

L’autre problème, c’est que les homonymes en français sont nombreux et les confusions pas forcément faciles à détecter.

  • a / à / as / ha
  • est / et / es / ai / ait / aie / aies / ais / hé / eh / haie / hais
  • été / étai / était / étais
  • dans / d’en / dent
  • desceller / déceler / desseller
  • faite / faîte / fête
  • la / là / l’a / l’as / las
  • mal / mâle / malle
  • or / hors
  • ou / où
  • on / ont
  • notre / nôtre
  • par / part / pare
  • prêt / près / pré
  • quand / quant / qu’en
  • sans / s’en / sens / c’en / cens / sent / cent / sang
  • serre / serf / sers / cerf
  • sot / seau / sceau
  • soi / soie / soit / sois
  • son / sont
  • soutien / soutiens / soutient
  • suis / suie / sui / suit
  • tort / tore / taure / tord
  • ver / vers / vert / verre

Ajoutons à cela les conjugaisons homophones :

  • manger / mangé / mangez / mangeais / mangeait
  • fus / fut / fût

En bref, la difficulté du français, c’est qu’il est rempli de nombreux mots qui s’écrivent de la même façon avec des natures différentes et de nombreux mots différents qui se prononcent de la même façon et qui engendrent nombre de confusions à l’écrit.

Les manières d’écrire en respectant la grammaire sont extrêmement nombreuses, mais les manières de mal écrire sont illimitées.

Campagne de financement

Pour ceux que ça intéresse, c’est sur Ulule.

Je vais évoquer ici quelques aspects techniques dont je ne parle pas sur Ulule.

Fournir de meilleures suggestions

Détecter les erreurs et suggérer quelle est la bonne graphie sont deux choses bien différentes. Dans certains cas, il est plus facile de détecter les erreurs que de savoir que suggérer. Mais l’inverse est aussi vrai, il existe des erreurs difficiles à détecter où il serait pourtant facile de suggérer la graphie correcte.

Grammalecte parvient à présent à faire des suggestions dans la plupart des cas, mais il reste quand même du travail à faire sur ce point. Prenons un exemple simple, une erreur que j’ai fréquemment vue sur ce site :

Je m’en fou.

Ici, le correcteur voit l’erreur mais est incapable de fournir une suggestion, parce qu’il n’existe aucun lien entre l’entrée “fou” et l’entrée “foutre” d’où dérivent toutes ses conjugaisons. Le correcteur ne sait pas où chercher une conjugaison adéquate. Pour parfaire le système de suggestion, il faudrait établir des passerelles entre tous les mots grammaticalement distincts sur leurs liens phonétiques éventuels.

Évidemment, si on prend la peine d’écrire des règles spécifiques pour gérer les cas particuliers, c’est possible de suggérer correctement, mais ce ne serait guère efficace dans la mesure où les mots homophones sont nombreux. Il faudrait écrire trop de règles.

Améliorer la détection des erreurs

Pour l’instant, si le préprocesseur de texte est déjà très employé, il est encore sous-exploité et on peut aller plus loin, mais cela réclame du temps et beaucoup de tests et de patience. La correction grammaticale est encore grandement améliorable, même si les choses “faciles” à faire sont de moins en moins nombreuses. La simplification des groupes nominaux pourrait être bien meilleure, c’est un vaste chantier qui est entamé depuis environ un an. Le principal obstacle à son renforcement, c’est justement l’absence d’une désambiguïsation efficace.
Il y a encore aussi pas mal de vérifications simples à écrire sur des tas de confusions possibles. Je me suis assez peu occupé de ça jusqu’à présent.

Le développement du correcteur suit depuis le commencement la même logique : une montée en puissance progressive en essayant d’éviter les faux positifs.

Écrire des règles, c’est assez rapide ; détecter les faux positifs, c’est beaucoup plus long ; ceux-ci ont tendance à survenir là où on s’y attend le moins. C’est ce qui est le plus exigeant : maintenir un ensemble de règles, améliorer l’existant, tester, trouver de nouvelles possibilités. Lorsqu’on s’occupe d’un correcteur grammatical, on passe surtout son temps à peaufiner des détails, à ajuster le fonctionnement de l’existant, à arrondir les angles. Oubliez l’idée de concevoir l’algorithme ultime qui saura gérer tous les cas. Même quand on est à peu près sûr d’écrire une petite règle tranquille qui ne générera aucun faux positif, la réalité va très probablement nous rappeler à l’ordre et nous obliger à slalomer sur ce qui paraissait au commencement comme une belle ligne droite. S’occuper de correction grammaticale, c’est marcher sur un chemin pavé d’embûches subtiles.

Désambiguïsation

Bien que le correcteur fasse déjà de la désambiguïsation à sa manière, brutalement, améliorer cet aspect ne serait pas du luxe pour la connaissance du contexte des erreurs. J’hésite encore sur la mise en œuvre. “Tokeniser”, pourquoi pas, mais ce n’est pas ma solution favorite. Utiliser le préprocesseur de texte pour créer un genre de carte signalétique, c’est pas mal, mais ça ressemble à de la bidouille. Employer des trucs et astuces, comme je le fais déjà maintenant, toujours via le préprocesseur de texte, ce n’est pas ce qu’il y a de plus commode, surtout pour l’intelligibilité de l’ensemble des règles. Je n’ai pas encore trouvé une solution simple et efficace. En rédigeant ce billet, une solution plaisante m’est venue. Ce sera un désambiguïsateur multi-passes sans tokenisation. Il fonctionnera en dressant un index de balises grâce des règles de désambiguïsation qui seront exécutées au commencement de chaque passe, avant même le préprocesseur de texte. Il suffira, lors de l’analyse lexicale, que le correcteur interroge en premier lieu cet index. Ce mécanisme devrait accroître grandement la capacité de reconnaissance des erreurs, car le désambiguïsateur diminuera les incertitudes.

Fiabilité des versions (tests unitaires)

Triste à dire, mais il n’y a à l’heure actuelle aucun test unitaire dans Grammalecte. Tout simplement parce que le correcteur est pour l’instant incapable de fonctionner hors de Writer. Les tests faits avant chaque publication se limitent à deux fichiers ODT que j’ouvre dans le traitement de texte : un qui référence les faux positifs éventuels, un autre qui liste des erreurs grammaticales à détecter. J’ouvre encore quelques autres fichiers pour voir si tout va bien. Mais ce n’est pas du tout pratique. Les tests unitaires accéléreraient beaucoup le développement, car les bugs et les régressions seraient détectés aussitôt, ce qui ne serait pas du luxe.

En finir avec la dépendance à Hunspell et à LibreOffice/OpenOffice

La raison pour laquelle Grammalecte est pour l’instant dépendant de LibreOffice/OpenOffice, c’est sa dépendance à Hunspell, le correcteur orthographique, qu’il interroge sans cesse pour connaître la nature grammaticale des mots.

Hunspell remplit sa tâche, mais les informations qu’il fournit sont présentées en vrac. Il faut traiter les données avant de pouvoir les exploiter. Quand vous demandez la nature grammaticale d’un mot, vous récupérez en fait toutes les étiquettes que le dictionnaire contient (et il y en a potentiellement pas mal). Il faut trier. Du coup, pour l’instant, je limite les données incluses dans le dictionnaire aux seules étiquettes grammaticales, afin d’éviter d’alourdir le boulot.

Plutôt que de recréer Hunspell en Python, il est préférable de créer un dictionnaire binaire indexable bâti sous la forme d’un gigantesque graphe de mots, facilement parcourable, ce qu’on peut appeler aussi un automate à états finis.

Un graphe de mots, ça ressemble à ça :

Pour savoir si un mot existe dans un graphe, on part de l’état initial et on suit les arcs représentés par les flèches, et si l’on parvient jusqu’à l’état final, le mot est considéré comme existant. Pour le correcteur, le graphe devra contenir tous les mots du français, et à la suite de chaque mot les informations grammaticales. Cette construction se fait à partir d’un simple fichier texte listant toutes les formes fléchies du français, leur lemme et les étiquettes informatives.

Les principales fonctions de cet automate seront de dire si un mot existe dans le lexique, donner son lemme (“aimer” est le lemme de “aime”), fournir ses étiquettes grammaticales, et éventuellement d’autres. Doté d’un module de suggestion, il peut même servir de correcteur orthographique.

Grammalecte existera bien sûr toujours comme extension pour Writer mais, grâce à cela, il pourra exister comme serveur autonome capable de fournir des corrections grammaticales à tout programme lui passant du texte à analyser, au format JSON. Chaque erreur contiendra les informations suivantes :

  • position de l’erreur,
  • type d’erreur (pour les applications qui auraient l’intelligence de souligner avec différentes couleurs),
  • message explicatif,
  • suggestion(s),
  • [optionnellement] hyperlien vers une page explicative plus complète,
  • identifiant de la règle détectant l’erreur (utile seulement pour le débogage).
Conversion du code en JavaScript pour l’extension Firefox/Thunderbird

Pour rappel, le but est bien d’avoir une extension qui peut fonctionner sans faire appel à un serveur local ou distant. Il faudra tout réimplémenter en JavaScript. Pour Firefox, je voudrais que le correcteur puisse aussi analyser le contenu d’une page web et pas seulement les zones d’édition de texte. Pour l’instant, Firefox, contrairement à LibreOffice et OpenOffice, ne possède pas (encore) d’API pour la grammaire, ce qui complique l’interfaçage avec les utilisateurs, mais ça ne semble pas insurmontable. À part ça, il n’a pas grand-chose à dire si ce n’est qu’il y a des épines et des ronces en perspective.

Autres considérations Les autres langues ?

Bonne nouvelle ! Même si je n’ai pas l’intention de m’occuper des autres langues, ce qui sera fait pour le français sera également possible pour bien d’autres. L’une des raisons pour lesquelles Lightproof est peu employé, c’est l’absence de ressources lexicales. Lightproof utilise les dictionnaires pour Hunspell, dont bien peu peuvent servir à la correction grammaticale puisque seuls les dictionnaires français et hongrois sont grammaticalement étiquetés. Or, le compilateur de lexique en dictionnaire binaire indexable dont j’ai parlé ci-dessus pourra réutiliser tous les lexiques de LanguageTool. Autrement dit, toutes les langues qui disposent d’un lexique chez LanguageTool pourront utiliser le moteur de Grammalecte.

Et la gestion du dictionnaire ?

Le site qui gère le dictionnaire français a fait son temps. Il est encore utile et assez pratique, mais il pourrait être bien mieux, plus simple notamment. Même s’il n’est pas difficile de participer, il faut quand même un peu de temps pour comprendre la logique. Mais comprendre n’est même pas exigé, il suffit de proposer de nouveaux mots. Malheureusement ça rebute apparemment beaucoup de monde. Les utilisateurs veulent aller vite et ne voient les résultats de leur participation que des mois plus tard, quand une nouvelle version est publiée. Le site est pensé sur un mode cathédrale et non sur un mode bazar. Après des années d’utilisation, j’en vois les limites, et je pense qu’il aurait dû être conçu autrement. Le refonte du site ne fait pas partie de la campagne de financement participatif. Idéalement, j’aimerais avoir un jour le temps de tout réécrire en Python (avec un framework comme Flask) en utilisant un autre concept que celui d’aujourd’hui, permettant une plus grande personnalisation, une plus grande modularité, un contrôle plus simple. C’est un vaste chantier.
Pour pallier ce problème, je prévois de créer dans le correcteur de LibreOffice et de Firefox un assistant qui simplifiera toute la procédure.

Les correcteurs grammaticaux servent-ils à quelque chose ?

Certaines personnes, en général avec une forte estime de leurs connaissances en orthographe et en grammaire, pensent que les correcteurs grammaticaux sont tous mauvais et ne servent à rien, et surtout pas à eux. Cette opinion est en partie légitime et en partie fausse.

Les correcteurs informatiques, ne comprenant rien à ce que vous écrivez, ont bien sûr du mal à détecter les erreurs dans les phrases complexes et parfois même dans des contextes simples. Dans bien des cas, les connaissances en grammaire d’un utilisateur bien instruit lui permettront de trouver plus d’erreurs que le correcteur grammatical.

Néanmoins, ceux qui pensent que connaître la langue parfaitement suffit à ne jamais faillir se trompent, car nombre d’erreurs sont dues à l’inattention, à la fatigue, à des copier-coller mal ajustés, à des défauts de reconnaissance optique. Or, l’ordinateur ne relâche jamais son attention, son œil ne fatigue jamais et il examine même ce qui ne vous vient pas à l’esprit.

Par ailleurs, pour les personnes dont les connaissances sont lacunaires, il peut se révéler pédagogue. Si par exemple vous ne connaissez pas le participe passé du verbe “avoir” (“eu”, que beaucoup écrivent erronément “eut”) ou du verbe “lire” (“lu”, et non “lut”), le correcteur finira immanquablement par trouver des occasions de vous signaler vos erreurs, même s’il peut ne pas toujours les repérer dans les contextes complexes, car il les détectera dans les contextes simples (Erreurs détectées dans “j’ai eut”, “ils n’ont pas eut”, etc.).

Le mot de la fin

Merci de m’avoir lu jusqu’ici.

Il semble que l’orthographe et la grammaire françaises soient de plus en plus ignorées, même des personnes les plus instruites. C’est du moins ce que disent souvent des articles alarmistes. J’ignore si cela est vrai, mais ce que je lis sur le Web m’étonne parfois, tant les bases de la grammaire semblent parfois méconnues. Qu’on ne connaisse pas la conjugaison de tous les verbes, c’est compréhensible, mais confondre “ça” et “sa”, “ce” et “se”, “quand”, “quant” et “qu’en” semble signifier qu’il faudrait une remise à niveau pour pas mal de monde. Cela dit, ce n’est peut-être pas si étonnant si l’on songe que le Web a remis à l’écriture des personnes qui n’écrivaient plus rien depuis fort longtemps.

Si vous pensez que Grammalecte mérite de s’étendre hors de LibreOffice, si vous trouvez que la langue française est maltraitée et qu’il faudrait avoir un outil pour dénicher les erreurs sur le Web, si vous voulez voir des mots normalement rejetés intégrés dans le correcteur, c’est sur Ulule que ça se passe.

Télécharger ce contenu au format Epub

Lire les commentaires

Concours de Programmation International CodinGame Samedi 25 Avril 2015

21 avril, 2015 - 20:17

Le 25 Avril prochain à 18h (heure de Paris), CodinGame lancera son prochain challenge de programmation en ligne « There Is No Spoon ».

Gratuite et ouverte aux développeurs du monde entier, la compétition se déroulera sur 3 heures.
Objectif : coder pour le plaisir et tenter de résoudre deux problèmes de programmation le plus vite possible, de la manière la plus optimisée.

Les participants pourront tenter de décrocher les lots offerts aux meilleurs du classement, et candidater pour des emplois ou des stages auprès des sociétés sponsors de l'évènement.

Les modalités de participation sont les suivantes :

  • Participation en ligne et gratuite
  • 20 langages de programmation disponibles (C/C++, C#, Java, Javascript, PHP, Python, Python 3, Perl, Go, Dart, Scala, Haskell, Objective-C, Pascal, Ruby, Bash, Groovy, Clojure, VB.NET)
  • Possibilité d'utiliser l'IDE en ligne de la plate-forme ou de coder dans son environnement de code favori
  • Prix en cash à gagner pour les 3 premiers du classement et tee-shirts pour les meilleurs dans chacun des 20 langages
  • 10 Sponsors proposant des postes en CDI
Télécharger ce contenu au format Epub

Lire les commentaires

Un point d'avancement sur Neovim

21 avril, 2015 - 20:16

Neovim est un éditeur de texte, issu d'un fork de Vim. Il vise à le rendre plus moderne. En particulier, faciliter le développement et l'utilisation de greffons, et permettre de l'intégrer plus facilement dans d'autres outils.

Le fork date d'un peu plus d'un an et le travail commence à payer. En plus d'un gros nettoyage de la base de code, les développeurs de Neovim ont mis en place un système de plugins, de greffons, qui peuvent désormais tourner à l'extérieur du processus principal et communiquer avec lui via msgpack. On peut également apprécier la possibilité de lancer un terminal à l'intérieur de Neovim, grâce à l'inclusion récente de la libvterm.

Mais pour accélérer le développement, Neovim a besoin de vous. Le développeur principal, @tarruda passe une partie de son temps sur Neovim et une autre partie à faire des missions en freelance pour gagner sa vie. Grâce à des dons, il pourrait diminuer le temps passé sur les missions, et ainsi passer plus de temps à faire vivre Neovim.

Personnellement, je suis un utilisateur comblé de Neovim depuis quelques mois. Bien que celui-ci soit toujours en version alpha, il est très stable et le passage de Vim à Neovim s'est fait sans aucun souci. Aussi, j'ai participé à l'appel à dons et vous encourage à faire de même pour promouvoir ce projet qui le mérite bien !

Télécharger ce contenu au format Epub

Lire les commentaires

Revue de presse de l'April pour la semaine 16 de l'année 2015

21 avril, 2015 - 14:53

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

[Next INpact] WikiLeaks: l'intervention des géants du Blu-ray dans le dossier Hadopi VLC

Par Marc Rees, le vendredi 17 avril 2015. Extrait:

WikiLeaks a diffusé ce matin 30 000 documents et 170 000 emails dérobés à Sony Pictures Entertainment par des pirates informatiques. Dans le lot, une cinquantaine de documents concerne la demande VideoLan adressée en 2012 à la Hadopi pour permettre l’interopérabilité du Blu-ray.

Lien vers l'article original: http://www.nextinpact.com/news/93861-wikileaks-l-intervention-geants-blu-ray-dans-dossier-hadopi-vlc.htm

[Breizh Info] On peut tout faire avec GitHub, même suivre l'évolution du Code Civil

Par la rédaction, le jeudi 16 avril 2015. Extrait:

Suivre les changements multiples du Code Civil, ce n’est pas très simple. Même quand on connaît Legifrance qui présentent les versions successives d’une même loi, ou qu’on suit assidument les travaux des parlementaires. Ne serait-ce parce qu’un amendement ou un paragraphe de loi, cela ressemble souvent à ça: À l’article 165 du même code, le mot: «devant» est remplacé par les mots: «lors d’une cérémonie républicaine par». On peut trouver plus ergonomique, n’est-ce pas?

Lien vers l'article original: http://www.breizh-info.com/25322/actualite-societale/on-peut-tout-faire-avec-github-meme-suivre-levolution-du-code-civil

[L'OBS] L’algorithme du gouvernement sera intrusif et inefficace. On vous le prouve

Par Andréa Fradin, le mercredi 15 avril 2015. Extrait:

On a demandé à des spécialistes en informatique s’il était possible de concevoir un programme répondant aux attentes du gouvernement en matière de renseignement. Résultat: techniquement, c’est très foireux.

Lien vers l'article original: http://rue89.nouvelobs.com/2015/04/15/lalgorithme-gouvernement-sera-intrusif-inefficace-prouve-258672

Et aussi:

[Les Echos] Après le logiciel libre, voici le matériel libre

Par Jacques Henno, le mardi 14 avril 2015. Extrait:

L'«open source» arrive dans l'univers des objets: de plus en plus de designers et d'industriels renoncent à une partie de leurs droits sur leurs créations. Un mouvement pas toujours désintéressé…

Lien vers l'article original: http://www.lesechos.fr/idees-debats/sciences-prospective/0204283695263-apres-le-logiciel-libre-voici-le-materiel-libre-1110940.php

Et aussi:

[Nouvelle République] Pour vivre le Web en liberté

Par Laurent Gaudens, le mardi 14 avril 2015. Extrait:

Le logiciel libre, c’est une philosophie. Et l’APP3L est là pour diffuser la bonne parole et aider ceux qui veulent franchir le pas.

Lien vers l'article original: http://www.lanouvellerepublique.fr/Vienne/Communautes-NR/n/Contenus/Articles/2015/04/14/Pour-vivre-le-Web-en-liberte-2294174

Et aussi:

[L'Informaticien] L’Etat va rafraîchir le Référentiel Général d’Interopérabilité

Par Emilien Ercolani, le mardi 14 avril 2015. Extrait:

Le RGI, publié pour la première fois en 2009, devrait évoluer. Une version «en mode provisoire» est disponible en ligne et ouverte aux commentaires publics.

Lien vers l'article original: http://www.linformaticien.com/actualites/id/36347/l-etat-va-rafraichir-le-referentiel-general-d-interoperabilite.aspx

Et aussi:

[Next INpact] La programmation informatique pourrait faire son entrée dans le programme de CE1

Par Xavier Berne, le mardi 14 avril 2015. Extrait:

L’apprentissage de la programmation informatique sera-t-il bientôt obligatoire dès l’école primaire? C’est effectivement ce qui se dessine au travers des projets de programme dévoilés hier par l’Éducation nationale. Des enseignements plus poussés en matière d’algorithmique auraient ensuite lieu au collège, à partir de la cinquième.

Lien vers l'article original: http://www.nextinpact.com/news/93814-la-programmation-informatique-pourrait-faire-son-entree-dans-programme-ce1.htm

Et aussi:

Télécharger ce contenu au format Epub

Lire les commentaires

Podcast francophone dédié à la cybersécurité : No Limit Secu

21 avril, 2015 - 13:23

Un épisode sur NAXSI un WAF — parefeu applicatif pour le web — open-source avec Thibault Koechlin et Sébastien Plot : quoi de mieux comme occasion pour porter à votre connaissance l'existence d'un podcast (ou bala(do)diffusion) dédié à la cybersécurité ?

No Limit Secu est un podcast indépendant, animé par des personnes passionnées qui sont parties prenantes dans le domaine de la cybersécurité à des rôles et dans entreprises diverses.

L'équipe du podcast prend beaucoup de plaisir à réaliser ces épisodes et souhaite partager cela avec la communauté LinuxFr.org. Dans la mesure du possible, un nouvel épisode est publié chaque semaine. C'est donc aussi l'occasion de vous proposer de contribuer à un épisode si vous souhaitez aborder une problématique ou traiter d'un sujet dans lequel vous êtes impliqué(e) (bien entendu, dans le domaine de la cybersécurité). Pour cela, vous pouvez contacter l'équipe via Twitter : @nolimitsecu.

Voici les thèmes traités jusqu'à présent dans le podcast :

Télécharger ce contenu au format Epub

Lire les commentaires

JM2L, c'est reparti \o/

20 avril, 2015 - 17:08

Après une année de mise en jachère, les Journées méditerranéennes du logiciel libre (JM2L), c'est reparti ! Organisée par l'association Linux Azur et l'École Polytech Nice-Sophia, voici venir la 9e édition le samedi 28 novembre 2015, à l'école Polytech'Nice-Sophia (site des templiers) au 930, Route des Colles - 06903 Sophia Antipolis.

L'accès est libre et gratuit. Venez avec votre famille, vos amis et vos relations découvrir ou faire connaître un monde de partage des ressources et des savoirs.

Le thème de cette année sera « Do it yourself », en français « faites-le vous-même ». Réparer votre grille-pain, construire votre imprimante 3D, héberger vos photos chez vous, c'est possible ! La philosophie « Do it yourself » c'est se ré-approprier ses objets, son ordinateur et, c'est lutter contre l'obsolescence programmée.

Les logiciels libres sont ceux que l'on peut copier, étudier, modifier et diffuser librement.

Ces libertés s'appliquent également à des œuvres d'art, du matériel, des ressources pédagogiques, etc. Les JM2L sont l'occasion de rencontrer et de partager avec un grand nombre de passionnés qui défendent ces valeurs.

Vous aussi, venez participez à cette aventure dans une ambiance chaleureuse et une philosophie fondée et consacrée aux valeurs de liberté et d'entraide.

Linux ? C'est le luxe !

Contacter / Participer :

  • mobile : +33 6 52 42 31 37
  • courriel : contact at jm2l.linux-azur dot org
Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de Pharo et de son environnement de développement en version 4.0

20 avril, 2015 - 17:04

Comme promis, un an après Pharo 3.0 nous sommes heureux de vous annoncer la sortie de Pharo 4.0. Entre autres nouvelles fonctionnalités, les outils de l'environnement de développement ont été entièrement revus.

Pharo c'est quoi ?

Pharo consiste à la fois en un langage de programmation purement objet inspiré de Smalltalk (avec compilateur et machine virtuelle) et un environnement dynamique de programmation. Pharo est diffusé sous licence MIT. Le langage Pharo s'appuie sur les bases solides de Smalltalk tout en y ajoutant, entre autres, les concepts modernes de trait (héritage multiple) et de slots (pour attacher du comportement à la lecture/écriture de variables d'instances).

Qui l'utilise ?

Actuellement 23 universités, 13 groupes de recherches et une cinquantaine de sociétés déclarent utiliser Pharo pour leurs développements (et si vous développez avec Pharo, merci de nous le faire savoir :)).

Que font-ils avec ?

Le catalogue de projets référence plus de 300 projets libres. Quelques entreprises partagent leurs success stories. Deux livres gratuits et libres (licence CC-by-sa) permettent d'apprendre les bases et les concepts avancés du langage et de son environnement : Pharo by example (disponible en français) et Deep into Pharo.

Nouveautés

La grande communauté internationale de développeurs Pharo a travaillé d'arrache-pied pour vous offrir le meilleur en matière d'environnement de développement dynamique, tout en vous rappelant que Pharo vous appartient aussi. Vous pouvez retrouver toutes les nouveautés de la version 4.0 de Pharo dans le changelog détaillé et dans l'annonce officielle.
Parmi ces nouveautés, outre les 1697 bugs corrigés depuis Pharo 3.0, on trouve une réécriture de l'outil d'inspection d'objets, de l'outil de recherche et du workspace (les GT tools).

GTools:

Le workspace (ou playground) offre une zone de texte (avec coloration syntaxique et auto-complétion) dans lequel le développeur peut tester son code. Dans l'image ci-dessous, le développeur a tapé FileSystem workingDirectory dans la zone de texte pour étudier à quoi ressemble l'objet résultant (une instance de la classe FileReference). En tapant Alt+Shift+g, un inspecteur s'ouvre à droite pour étudier cet objet en détail : dans le cas de la classe FileReference, l'inspecteur montre le contenu du fichier ou du dossier.

L'inspecteur permet d'étudier et de manipuler les objets du programme. Chaque classe peut définir plusieurs façons d'être représentée dans l'inspecteur. Allez voir la vidéo, ça vaut le détour. Ci-dessus, on peut voir qu'inspecter un dossier affiche son contenu. Ci-dessous, à droite, on peut voir qu'inspecter un dictionnaire (i.e., une table de hachage) affiche toutes les paires clé/valeur.

Le spotter quant à lui aide les développeurs à rechercher rapidement n'importe quel objet du système. Allez voir la vidéo, elle vaut largement son pesant de cacahouètes. L'utilisation du spotter permet, entre autres, de naviguer au travers du code :

  • Explorer une classe, poursuivre dans ses méthodes et variables ;
  • Obtenir les classes implémentant une méthode, obtenir les endroits où cette méthode est appelée.

Et bien d'autres!

Vous pouvez consulter une présentation complète ici

Retrouvez toute l'actualité de l'équipe GT sur leur site.

OSWindow

OSWindow propose une nouvelle manière de gérer les fenêtres et les événements :

  • création de fenêtres natives dans un système d'exploitation ;
  • événements gérés par la bibliothèque SDL2 ;
  • modélisation 3D avancée via Woden.
Dark Theme

Les amateurs d'environnements sombres sauteront de joie !

Et plus encore

D'autres briques majeures évoluent telles que Zinc (la bibliothèque réseau), Fuel (le sérialiseur d'objets ultra-rapide) et Versionner (l'outil de gestion de dépendances et de release).

Côté visuel, Pharo introduit de nouvelles polices par défaut. Morph (la bibliothèque de composants graphiques) prend un coup de jeune grâce à Athens (la bibliothèque de graphiques vectoriels). Cela permet de proposer tout un panel de nouveaux widgets.

Pour les amateurs de Raspberry et de systèmes embarqués, vous pouvez désormais compiler la machine virtuelle sur Raspbian. Pharo tourne maintenant aussi sur FreeBSD.

Télécharger ce contenu au format Epub

Lire les commentaires

Soirée Linux Alpes à Digne le 28 mai 2015

19 avril, 2015 - 23:24

Linux-Alpes vous convie à sa prochaine soirée dignoise le 28 mai 2015 à partir de 20h chez Xsalto.

Au programme, démonstration d'installation de Linux.

Nous présenterons notamment la nouvelle version de Ubuntu 15.04 Vivid Vervet ainsi que Debian Debian 8 Jessie.

Plan d'accès

(voir le plan sur Umap)

Télécharger ce contenu au format Epub

Lire les commentaires

Spacewalk 2.3

19 avril, 2015 - 15:22

Spacewalk est un logiciel de gestion des systèmes et de leurs mises à jour pour les distributions basées sur les paquets RPM. Ce nom ne vous dit peut-être rien, mais ce projet est en fait celui qui sert de base à Red Hat Satellite 5 (RHN), ainsi qu'à SUSE Manager. Malgré la disponibilité de Katello et de Satellite 6, Spacewalk est toujours maintenu.

Le 14 avril dernier est sortie la version 2.3 de ce logiciel, dont les changements principaux sont détaillés en deuxième partie de dépêche.

Les ajouts

Suite à la prise en charge des clients RHEL 7 et CentOS 7 dans Spacewalk 2.2, cette version 2.3 est enfin installable sur ces systèmes. Fedora 21 se voit ajouté à la liste, en tant que serveur et client.

Spacewalk est capable d'être couplé à un système d'authentification externe, ce qui évite de déclarer tous les comptes en local si vous disposez d'un annuaire compatible. L'apparition de la commande spacewalk-setup-ipa-authentication devrait faciliter ce genre de cas de figure.

Bien que Spacewalk soit principalement utilisé avec une base de données PostgreSQL, il est toujours possible d'utiliser Oracle. Des contributions ont vu la possibilité d'utiliser Oracle 12c en tant que base de données externe.

Dans le cadre de l'utilisation en tant que proxy, Spacewalk est maintenant capable de gérer l'en-tête HTTP If-Modified-Since pour les méta-données de yum.

L'interface utilisateur continue sa finition, ainsi que sa standardisation utilisant Patternfly. Elle ne contient d'ailleurs plus de code Perl, et est exclusivement en Java à présent.

Plein d'autres "petites" améliorations sont présentes. Parmi elles, on trouvera l'option --dry-run ainsi qu'une meilleure gestion des dépendances dans la commande spacewalk-clone-by-date, la prise en charge de dépôts compressés au format xz, et l'ajout du fuseau horaire pour la Corée du Sud.

L'API évolue, certains appels apparaissent, d'autres disparaissent. Il est recommandé de lire la documentation dédiée à l'API sur le site du projet.

Pour clore ce chapitre sur les nouveautés, on remarquera que le code source de Spacewalk est maintenant disponible sur le très célèbre Github, et que le projet s'est doté d'un nouveau nom de domaine : spacewalkproject.org

Les suppressions

Comme annoncé lors de la sortie de Spacewalk 2.2, certains éléments ont été supprimés. Tout d'abord, l'installation (ou mise à jour) de la partie serveur n'est plus possible sur RHEL 5 ou CentOS 5. La partie cliente est elle toujours disponible. Adieu aussi à la prise en charge de Solaris.

Cela avait aussi été annoncé lors de Spacewalk 2.2, les fonctionnalités de surveillance elles aussi disparaissent en version 2.3.

Télécharger ce contenu au format Epub

Lire les commentaires

Atélili #3 : «Communiquer de façon confidentielle sur internet» - 24 avril 2015 - Lille

19 avril, 2015 - 11:52

Ce 24 avril, Atélili propose un atelier dont la thématique est «Communiquer de façon confidentielle sur Internet».

Cet atelier s'inscrit dans la lignée de nos ateliers «Chiffrement». Pour rappel, le chiffrement est le procédé informatique par lequel nous pouvons empêcher la lecture de nos données par un tiers.

L'accent sera mis cette fois-ci sur les logiciels qui permettent de dialoguer avec une autre personne sur Internet, et qui assurent la confidentialité des communications. Il s'agira par exemple des logiciels de messagerie instantanée Pidgin et Gajim (pour envoyer/recevoir des messages textuels), et du logiciel de VoIP nommé Jitsi (pour la voix et la video).

Signalons en effet que les logiciels de communication habituels (email non chiffré, Skype, Facebook…) ne proposent aucun chiffrement, et que la confidentialité de nos échanges est donc mise en péril à plusieurs niveaux.

En introduction, on profitera de cet atelier pour discuter du très récent «projet de loi relatif au renseignement», qui instaure en France un régime de surveillance généralisée de la population.

Plan/Déroulement :

  • 18h30 : discussion sur le projet de loi relatif au renseignement ;
  • 19h15 : installation et utilisation des outils de communications chiffrées (jitsi, pidgin, enigmail…).

Cet atelier est tout public, vous pouvez venir quel que soit votre degré de maitrise de l'outil informatique. Pensez à ramener votre ordinateur portable si vous souhaitez pratiquer.

Les atélilis sont des ateliers qui se déroulent mensuellement. Ils sont co-organisés par des individus et plusieurs collectifs promouvant le logiciel libre dans la région tels que Chtinux et CLX. Comme pour tous les ateliers que nous proposons, l'emploi de logiciels libres apparaît comme une nécessité et nous vous y encouragerons.

D'autres infos sur notre site web : http://atelili.tuxfamily.org .

Infos pratiques :

  • date : vendredi 24 avril 2015 à 18h30 (confirmé) ;
  • lieu : M.R.E.S., 23 rue Gosselet, au 1er étage (salle «moulin»), à Lille.
Télécharger ce contenu au format Epub

Lire les commentaires