Accueil › Agrégateur de nouvelles › Sources ›

Linuxfr.org

Version imprimableVersion imprimable
Syndiquer le contenu
URL: https://linuxfr.org/news
Mis à jour : il y a 32 min 2 sec

Dark Moon : une distribution GNU/Cygwin portable pour Windows

16 août, 2018 - 22:42

Dark-Moon est un émulateur de terminal Open Source développé par Mehdi Boutayeb Ferkatou et édité par MBK logiciel dans sa version UWP sur le Microsoft Store.

Dark Moon est à ce jour la seule distribution GNU/Cygwin disponible sur le Microsoft Store et sur le site de l'éditeur.

Sommaire Présentation

Dark Moon est un ensemble de logiciels libres basé sur Cygwin rendu portable permettant l'exécution de commandes POSIX dans le but d'émuler un environnement Unix sur plateforme Windows X64.

Dark-Moon permet de créer des scripts et des programmes utilisant les commandes grâce à une grande collection d'outils GNU et Open Source intégrée dans le terminal.

Embarquer une collection d'API POSIX sous la forme d'un exécutable nous permet d'envisager une informatique hyper-transportable pour les émulateurs et distributions GNU/Cygwin, il suffit alors de trouver du courant et un processeur hôte pour exécuter l'application, ce qui aurait était auparavant impossible avant la naissance de Dark Moon.

L'objectif technique recherché est de fournir un environnement de développement ainsi qu'un émulateur Unix cloisonnés dans un exécutable apportant une mobilité au logiciel, permettant d'exécuter l'application sur n'importe quel système Windows.

Idée générale

Dark Moon est autonome, ce qui le distingue d'autres distributions équivalentes.

Il est possible d'exécuter des commandes Shell et Bash ainsi que de créer et exécuter des scripts sur la console.

L'application est également un outil de développement notamment en offrant aux utilisateurs un environnement de développement libre tel que GCC.

Cette distribution est également un outil Unix complet, personnalisable et offrant une mobilité ne demandant pas d'installation préalable. Elle est née en vue de fournir aux utilisateurs des possibilités étendues en complément de l'interpréteur de commande Windows.

Il est possible de manipuler des fichiers ainsi que la ruche de registre sans déposer aucune empreinte sur l'ordinateur hôte afin d’éviter d'apporter des modifications durables à un poste utilisé temporairement.

L'émulateur a fait l’objet d’une ouverture au public du code source, le logiciel libre est sous licence GNU GPL, il n’y a donc pas de restriction d’utilisation et de modification du logiciel tant que les conditions de la licence sont respectées.

En comparaison d'autres distributions Cygwin et Linux, l'application ne requiert aucun composant externe, les fichiers étant cloisonnés dans l'exécutable même, permettant un emploi à partir d'un stockage amovible comme une clé USB.

Différentes bibliothèques ont été incluses notamment MinGW qui travaille avec des composants Windows comme la bibliothèque MSVCRT liée à Microsoft Visual C++.

Busybox est intégré pour l'implémentation d'un grand nombre des commandes par ailleurs, il est également possible d'utiliser un agent d'authentification OpenSSH.

Le code source ainsi que les fichiers compilés ont été emballés dans l'exécutable pour respecter le concept de portabilité (il suffit de l'extraire avec 7zip pour avoir accès aux fichiers sources).

Liste des commandes actuellement disponibles Voi job_spec [&] history [-c] [-d offset] [n] or hist> (( expression )) if COMMANDS; then COMMANDS; [ elif C> . filename [arguments] jobs [-lnprs] [jobspec ...] or jobs > : kill [-s sigspec | -n signum | -sigs> [ arg... ] let arg [arg ...] [[ expression ]] local [option] name[=value] ... alias [-p] [name[=value] ... ] logout [n] bg [job_spec ...] mapfile [-d delim] [-n count] [-O or> bind [-lpsvPSVX] [-m keymap] [-f file> popd [-n] [+N | -N] break [n] printf [-v var] format [arguments] builtin [shell-builtin [arg ...]] pushd [-n] [+N | -N | dir] caller [expr] pwd [-LP] case WORD in [PATTERN [| PATTERN]...)> read [-ers] [-a array] [-d delim] [-> cd [-L|[-P [-e]] [-@]] [dir] readarray [-n count] [-O origin] [-s> command [-pVv] command [arg ...] readonly [-aAf] [name[=value] ...] o> compgen [-abcdefgjksuv] [-o option] [> return [n] complete [-abcdefgjksuv] [-pr] [-DE] > select NAME [in WORDS ... ;] do COMM> compopt [-o|+o option] [-DE] [name ..> set [-abefhkmnptuvxBCHP] [-o option-> continue [n] shift [n] coproc [NAME] command [redirections] shopt [-pqsu] [-o] [optname ...] declare [-aAfFgilnrtux] [-p] [name[=v> source filename [arguments] dirs [-clpv] [+N] [-N] suspend [-f] disown [-h] [-ar] [jobspec ... | pid > test [expr] echo [-neE] [arg ...] time [-p] pipeline enable [-a] [-dnps] [-f filename] [na> times eval [arg ...] trap [-lp] [[arg] signal_spec ...] exec [-cl] [-a name] [command [argume> true exit [n] type [-afptP] name [name ...] export [-fn] [name[=value] ...] or ex> typeset [-aAfFgilnrtux] [-p] name[=v> false ulimit [-SHabcdefiklmnpqrstuvxPT] [l> fc [-e ename] [-lnr] [first] [last] o> umask [-p] [-S] [mode] fg [job_spec] unalias [-a] name [name ...] for NAME [in WORDS ... ] ; do COMMAND> unset [-f] [-v] [-n] [name ...] for (( exp1; exp2; exp3 )); do COMMAN> until COMMANDS; do COMMANDS; done function name { COMMANDS ; } or name > variables - Names and meanings of so> getopts optstring name [arg] wait [-n] [id ...] hash [-lr] [-p pathname] [-dt] [name > while COMMANDS; do COMMANDS; done help [-dms] [pattern ...] { COMMANDS ; } Voi job_spec [&] history [-c] [-d offset] [n] or hist> (( expression )) if COMMANDS; then COMMANDS; [ elif C> . filename [arguments] jobs [-lnprs] [jobspec ...] or jobs > : kill [-s sigspec | -n signum | -sigs> [ arg... ] let arg [arg ...] [[ expression ]] local [option] name[=value] ... alias [-p] [name[=value] ... ] logout [n] bg [job_spec ...] mapfile [-d delim] [-n count] [-O or> bind [-lpsvPSVX] [-m keymap] [-f file> popd [-n] [+N | -N] break [n] printf [-v var] format [arguments] builtin [shell-builtin [arg ...]] pushd [-n] [+N | -N | dir] caller [expr] pwd [-LP] case WORD in [PATTERN [| PATTERN]...)> read [-ers] [-a array] [-d delim] [-> cd [-L|[-P [-e]] [-@]] [dir] readarray [-n count] [-O origin] [-s> command [-pVv] command [arg ...] readonly [-aAf] [name[=value] ...] o> compgen [-abcdefgjksuv] [-o option] [> return [n] complete [-abcdefgjksuv] [-pr] [-DE] > select NAME [in WORDS ... ;] do COMM> compopt [-o|+o option] [-DE] [name ..> set [-abefhkmnptuvxBCHP] [-o option-> continue [n] shift [n] coproc [NAME] command [redirections] shopt [-pqsu] [-o] [optname ...] declare [-aAfFgilnrtux] [-p] [name[=v> source filename [arguments] dirs [-clpv] [+N] [-N] suspend [-f] disown [-h] [-ar] [jobspec ... | pid > test [expr] echo [-neE] [arg ...] time [-p] pipeline enable [-a] [-dnps] [-f filename] [na> times eval [arg ...] trap [-lp] [[arg] signal_spec ...] exec [-cl] [-a name] [command [argume> true exit [n] type [-afptP] name [name ...] export [-fn] [name[=value] ...] or ex> typeset [-aAfFgilnrtux] [-p] name[=v> false ulimit [-SHabcdefiklmnpqrstuvxPT] [l> fc [-e ename] [-lnr] [first] [last] o> umask [-p] [-S] [mode] fg [job_spec] unalias [-a] name [name ...] for NAME [in WORDS ... ] ; do COMMAND> unset [-f] [-v] [-n] [name ...] for (( exp1; exp2; exp3 )); do COMMAN> until COMMANDS; do COMMANDS; done function name { COMMANDS ; } or name > variables - Names and meanings of so> getopts optstring name [arg] wait [-n] [id ...] hash [-lr] [-p pathname] [-dt] [name > while COMMANDS; do COMMANDS; done help [-dms] [pattern ...] { COMMANDS ; } Voi job_spec [&] history [-c] [-d offset] [n] or hist> (( expression )) if COMMANDS; then COMMANDS; [ elif C> . filename [arguments] jobs [-lnprs] [jobspec ...] or jobs > : kill [-s sigspec | -n signum | -sigs> [ arg... ] let arg [arg ...] [[ expression ]] local [option] name[=value] ... alias [-p] [name[=value] ... ] logout [n] bg [job_spec ...] mapfile [-d delim] [-n count] [-O or> bind [-lpsvPSVX] [-m keymap] [-f file> popd [-n] [+N | -N] break [n] printf [-v var] format [arguments] builtin [shell-builtin [arg ...]] pushd [-n] [+N | -N | dir] caller [expr] pwd [-LP] case WORD in [PATTERN [| PATTERN]...)> read [-ers] [-a array] [-d delim] [-> cd [-L|[-P [-e]] [-@]] [dir] readarray [-n count] [-O origin] [-s> command [-pVv] command [arg ...] readonly [-aAf] [name[=value] ...] o> compgen [-abcdefgjksuv] [-o option] [> return [n] complete [-abcdefgjksuv] [-pr] [-DE] > select NAME [in WORDS ... ;] do COMM> compopt [-o|+o option] [-DE] [name ..> set [-abefhkmnptuvxBCHP] [-o option-> continue [n] shift [n] coproc [NAME] command [redirections] shopt [-pqsu] [-o] [optname ...] declare [-aAfFgilnrtux] [-p] [name[=v> source filename [arguments] dirs [-clpv] [+N] [-N] suspend [-f] disown [-h] [-ar] [jobspec ... | pid > test [expr] echo [-neE] [arg ...] time [-p] pipeline enable [-a] [-dnps] [-f filename] [na> times eval [arg ...] trap [-lp] [[arg] signal_spec ...] exec [-cl] [-a name] [command [argume> true exit [n] type [-afptP] name [name ...] export [-fn] [name[=value] ...] or ex> typeset [-aAfFgilnrtux] [-p] name[=v> false ulimit [-SHabcdefiklmnpqrstuvxPT] [l> fc [-e ename] [-lnr] [first] [last] o> umask [-p] [-S] [mode] fg [job_spec] unalias [-a] name [name ...] for NAME [in WORDS ... ] ; do COMMAND> unset [-f] [-v] [-n] [name ...] for (( exp1; exp2; exp3 )); do COMMAN> until COMMANDS; do COMMANDS; done function name { COMMANDS ; } or name > variables - Names and meanings of so> getopts optstring name [arg] wait [-n] [id ...] hash [-lr] [-p pathname] [-dt] [name > while COMMANDS; do COMMANDS; done help [-dms] [pattern ...] { COMMANDS ; } Syntaxe

Avec les applets de commandes mis à disposition, il est possible de créer des scripts aisément comme présenté ci-dessous :

#Mon premier script function() { local variableLocal="function 1" echo "$variableLocal" echo "Nombres de paramètres : $#" echo $1 echo $2 } function "Hello" "World"

Pour lancer le script, placez vous dans le dossier contenant le script (obligatoire) :

cd C:\Users\[Userprofile]\Documents\script-Shell

faites un chmod :

chmod 700 MonPremierScript

Exécutez le:
shell
Nombres de paramètres : 2
Hello
World

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

FlOpEDT : un nouveau logiciel libre de gestion des emplois du temps !

14 août, 2018 - 07:27

Toutes celles et ceux qui ont travaillé dans un lycée ou une université savent à quel point la gestion des emplois du temps est un sac de nœuds. La personne responsable s’arrache les cheveux pour tenter de fabriquer quelque chose qui satisfasse tout le monde… et ne réussit jamais !

Alors, avec quelques enseignants de l’IUT de Blagnac, on a développé FlOpEDT. C’est un logiciel libre qui génère les emplois du temps tout seul et permet aux utilisateurs de saisir leurs disponibilités et d’apporter des modifications en ligne et en toute autonomie.
Toutes les briques de FlOpEDT sont libres, et lui‐même est en licence AGPL v3.

Facile à utiliser et plein de liberté !

Les utilisateurs se connectent et saisissent leurs préférences à l’aide d’une interface intuitive : un « sens interdit » pour les indisponibilités, une couleur explicite pour les préférences.

Ensuite, l’emploi du temps est généré automatiquement en quelques minutes en respectant contraintes et préférences. L’emploi du temps est alors accessible à tous, et il est possible pour tout utilisateur de le modifier.

Cette partie est celle qui étonne : on nous dit souvent que si tout le monde peut faire des modifications ce sera la pagaille. Notre expérience confirme l’inverse : cela génère du confort pour tout le monde, et tout le monde a à cœur de prendre soin de cette liberté nouvelle (pas de coups de fils à passer, pas de courriels gênés…). Évidemment, l’application empêche toute modification qui ne respecterait pas les règles fixées collectivement.

FlOpEDT est aussi doté d’un outil de synchronisation avec iCal (pour les agendas en ligne), ainsi que d’un outil de synchronisation avec des bases de données extérieures.

Plus précisément, FlOpEDT se divise en deux parties essentielles :

  • une application web, développée dans le cadriciel Django (Python 3), s’appuyant sur une base de données PostgreSQL ;
  • un outil de création de l’emploi du temps, qui passe par la définition d’un système d’équations linéaires (à l’aide de PuLP) et sa résolution.

FlOpEDT n’en est qu’à sa version 0, et il n’est pour l’instant pas extrêmement générique : l’adaptation aux contours précis de votre établissement demanderait pour l’instant du travail. Mais ce temps investi permettrait d’en gagner ensuite beaucoup, et vous participeriez au développement d’un logiciel à terme utile à toutes et tous. Alors n’hésitez pas à nous contacter si vous voulez le tenter, votre proposition ne fera pas flop…

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Movim, mode d’emploi — Première partie : l’architecture

13 août, 2018 - 22:03

Je travaille maintenant depuis presque dix ans sur Movim et je n’ai jamais réellement eu l’opportunité d’expliquer comment le projet fonctionne. Prenons un peu le temps de mettre tout ça par écrit !

Cette présentation sera divisée en plusieurs articles. Je vais commencer par présenter le projet de façon globale avant d’aller progressivement vers son fonctionnement interne et ses détails techniques.

Sommaire

J’utilise les plates‐formes sociales depuis pas mal d’années maintenant et je suis toujours surpris de voir que malgré les milliards de dollars investis par les géants du Web elles fonctionnent toutes plus ou moins selon la même architecture.

Même avec toutes les technologies qui sont apparues ces dernières années les choses se présentent toujours plus ou moins de la même façon : vous publiez du contenu via des requêtes AJAX (ou au travers d’un Websocket), c’est sauvegardé dans une base de données et vos contacts vont périodiquement envoyer une requête au serveur pour voir si il y a quelque chose de nouveau à afficher.

C’est au final assez facile à construire et si vous souhaitez le faire vous‐même il existe de nombreux cadriciels qui offrent tous les outils nécessaires pour réaliser cette architecture aisément (typiquement Laravel, Ruby on Rails, Django, Symfony ou Zend, connectés à une base de données SQL, une API REST, une jolie interface et hop vous avez un réseau social).

Mais pourquoi donc devoir attendre pour récupérer les publications des autres contacts ?

Nous avons depuis des décennies maintenant des technologies de messagerie instantanée qui nous permettent d’envoyer, en temps réel, tout autour du globe, du contenu sans le moindre souci. Pourquoi ne pouvons‐nous pas faire de même avec les réseaux sociaux ?

Et c’est ici que réside l’idée de base du projet Movim.

Créons un réseau social temps réel

Donc, l’une des erreurs à éviter quand le projet a démarré, c’était de réinventer la roue. Vous verrez que Movim est principalement composé de technologies basiques et déjà éprouvées.

Pour fabriquer un réseau social fonctionnant en temps réel, il me fallait transférer du contenu instantanément sur le réseau. Il devait donc être transporté au sein d’un système « connecté » et donc construit sur des sockets (contrairement aux systèmes construits sur des requêtes).

Cela exclut déjà toutes les récentes technologies sociales standardisées par le W3C (bye bye ActivityPub et WebSub), ces dernières étant construites sur HTTP. Loin de moi l’idée de remettre en question ces standards, ce sont des solutions sérieuses et parfaitement valides, mais pas pour les besoins de Movim.

Je cherchais donc un protocole qui soit :

  • temps réel ;
  • standard (avec des RFC sérieuses) ;
  • et si possible déjà éprouvé et largement déployé.

Cela nous amène donc à XMPP (je ne vais pas expliquer en détail comment le protocole est construit, vous pouvez trouver plus d’informations sur la page Wikipedia et sur le site officiel de la fondation).

Dans la pratique, XMPP nous offre quelques précieux avantages :

  • c’est un protocole temps réel (super !), les données sont échangées dans le format XML (oui, je vous vois déjà venir, vous les défenseurs du JSON ! Mais gardons de côté ce différend pour plus tard ;)) sous forme de paquets (appelés « stanzas » dans le cas présent) envoyés en TCP et chiffrés avec TLS ;
  • XMPP offre un cadriciel très simple et générique qui comprend de (très !) nombreuses extensions que l’on peut combiner afin de développer la solution désirée (voici pour l’exemple celles utilisées pour construire Movim) ; et parce que XMPP est basé sur XML, il est très facile de l’étendre au moyen d’espaces de noms (namespaces) existants : prenez Atom, ajoutez‐y Pubsub et voilà, vous obtenez un système de publication de contenu complet, temps réel, pour vos articles avec pièces jointes, bien défini et tout à fait spécifié ;
  • vous pouvez faire bien plus que de simples choses « sociales » avec XMPP ; pas besoin de composer avec dix autres protocoles, XMPP offre déjà tout pour faire du clavardage et des salons de discussion, de la vidéoconférence, des solutions de publication-abonnement et beaucoup d’autres choses. Et cela offre l’avantage de conserver un code assez concis puisqu’il n’y a qu’un unique protocole dans le back‐end ;
  • XMPP est fédéré et utilise un réseau un peu similaire à celui du courrier électronique ; les comptes sont créés sur les serveurs (c’est pourquoi les identifiants sont également similaires : nomutilisateur@serveur.tld), les clients se connectent ensuite à ces serveurs XMPP ; en plus de ça, vous pouvez avoir plusieurs clients connectés, en même temps, à votre compte et ils seront tous synchronisés en temps réel :) ;
  • il y a déjà une grande communauté, avec des serveurs sérieux qui peuvent gérer des millions de connexions simultanément sans aucun problème (ejabberd <3).

C’est aussi un gros avantage pour Movim. Je n’ai pas à m’occuper de tous les problèmes de réseau. C’est « juste » un client simple et stupide qui se connecte aux serveurs XMPP, en obtient du contenu et leur en envoie.

Si vous comparez cette solution avec d’autres solutions de réseau fédéré telles que Mastodon ou Diaspora, il y a là une grande différence : pour Movim, les comptes sont sur un serveur distinct. Je n’ai donc pas besoin de créer une autre API pour communiquer avec Movim. Tout le monde peut échanger avec Movim en implémentant simplement XMPP (et il y a déjà beaucoup de bibliothèques et de solutions dans la nature pour le faire).

OK, nous avons choisi le protocole, maintenant nous devons construire le back‐end.

Un peu d’histoire

J’ai créé Movim en 2008 afin d’apprendre à programmer et essayer de construire par la même occasion une plate‐forme sociale sur laquelle j’aimerais échanger avec mes proches. Ayant choisi d’apprendre le langage PHP par la même occasion j’ai tout naturellement choisi celui‐ci pour commencer les travaux.

Avec les connaissances acquises au cours de mes études, l’aide d’un ami (Etenil, si tu me lis…) et de ce que j’ai pu apprendre de façon autodidacte j’ai progressivement amélioré Movim et rajouté les nombreuses fonctionnalités qui me paraissaient intéressantes pour construire une plate‐forme sociale digne de ce nom.

Puis au cours de l’été 2014 j’ai décidé d’entièrement réécrire le cœur de Movim afin d’en faire une plate‐forme entièrement temps réel. En effet, jusqu’ici le projet était construit sur une « émulation » de temps réel construite au dessus de HTTP via les connections XMPP (en utilisant l’extension BOSH).

Ces changements apportèrent également une importante réécriture de l’architecture interne et d’une refonte de l’interface utilisateur.

À cette période un nouveau cadriciel commençait à faire parler de lui au sein de la communauté. ReactPHP permettait en effet de construire très facilement des architectures entièrement en temps réel en PHP et offrait tout ce que je recherchais pour cette réécriture.

Un démon, quelques tuyaux et voilà !

ReactPHP est un ensemble d’outils s’interconnectant entre eux et permettant de créer toutes sortes d’architectures fonctionnant entièrement en temps réel.

J’utilise à ce jour les modules suivants :

  • react/event-loop, le cœur de React, s’occupant de la gestion de toutes les entrées‐sorties ;
  • react/dns, un résolveur DNS asynchrone ;
  • react/promise-timer, pour exécuter périodiquement des évènements ;
  • react/socket, pour se connecter à XMPP en utilisant des sockets TCP (avec une couche de chiffrement TLS par dessus) ;
  • react/child-process, pour lancer et gérer des sous‐processus ;
  • react/stream, afin de connecter toutes ces choses ensemble ;
  • react/zmq, une bibliothèque ZeroMQ pour pouvoir gérer efficacement les communications au sein de Movim.

Il m’a fallu ensuite quelques mois de recherche avant de trouver une architecture stable, qui n’a que peu changé par la suite.

Rentrons un peu dans les détails.

Toute la structure de Movim est prise en charge par un démon central (qui s’appelle daemon.php, c’est fou !). Ce démon s’occupe de tous les WebSockets des navigateurs des utilisateurs (mobiles et bureau) et lance un sous‐processus pour chaque utilisateur connecté. Finalement, il se comporte comme un routeur tout bête qui transfère les messages entre les WebSockets des utilisateurs et leurs processus respectifs

Cette architecture offre plusieurs avantages :

  • les sessions utilisateur sont isolées et n’influent pas sur les performances les unes des autres ;
  • elles peuvent être contrôlées plus facilement (tuer une session ne supprimera pas les autres) ;
  • le démon principal est minimal (il agit comme un simple routeur).

Cela présente néanmoins un inconvénient : la consommation de mémoire est supérieure. Le code est chargé plusieurs fois entre les différents sous‐processus. Il faut compter environ 10 à 20 Mio par utilisateur connecté. La situation s’est bien améliorée depuis les dernières versions puisque la consommation mémoire de Movim lui‐même a été réduite en retirant des dépendances et en mettant à jour PHP (PHP 7.0+). La consommation mémoire reste un point d’amélioration pour les versions à venir puisqu’elle pourrait devenir un goulot d’étranglement. Le cadriciel peut facilement supporter des milliers de connexions simultanées mais la mémoire vive manquera bien avant d’y arriver.

Chacun des ces sous processus se connecte au serveur XMPP de l’utilisateur puis prend en charge toutes ses communications. Il se connecte aussi à la base de données SQL commune qui fait office de cache pour chaque compte et permet l’échange de données entre eux (via la découverte de ressources publiques par exemple)

Pour finir, ces processus gèrent aussi tout ce qui est relatif au frontal, mais cette partie sera expliquée plus en détail dans un article à venir.

Optimisations

Certaines optimisations ont été faites pour améliorer les performances globales de cette architecture. En voici les trois principales, celles qui je pense, ont eu le plus grand impact sur le projet.

Analyseur de flux XML

Une connexion XMPP peut être ramenée à un flux XML bidirectionnel. Le client envoie des requêtes XML (appelées stanzas) et analyse (d’un point de vue lexical) les requêtes entrantes. Le point important ici est que les requêtes entrantes font partie d’un seul et même « document » XML. À l’origine, Movim détectait chacune de ces stanzas et les analysait séparément.

L’analyseur a donc été remanié pour travailler en flux (voir analyseur syntaxique XML). Cela permet à Movim de préparer les stanzas entrantes et de lancer les événements qui leur sont relatifs dès que les premières balises XML sont reçus dans le socket. Le petit changement a vraiment amélioré les performances XMPP globales du projet. En particulier pendant la phase de connexion puisque Movim peut maintenant traiter plusieurs milliers de stanzas en quelques secondes.

Hello ZeroMQ !

Les communications entre le démon principal et les sous‐processus (qu’on appelle « linkers » dans Movim) sont à l’origine de simples stdin/stout. Cela a créé des problèmes de tampons et de performance et j’ai finalement choisi d’utiliser un outil spécifique à la tâche : ZeroMQ.

À chaque fois que le démon principal invoque un linker pour un utilisateur, il crée deux flux IPC dédiés (un pour les messages entrants et un pour les messages sortants) puis gère tout ce qui les traverse.

Cela m’a permis d’éviter la création de certains tampons dédiés au transit de messages et ainsi d’améliorer les performances globales, en particulier pour la partie interface utilisateur.

ZeroMQ est aussi très léger et est déjà disponible et empaqueté sur la majeure partie des distributions GNU/Linux.

De Modl à Eloquent

Movim dépendait au début d’un ORM spécifiquement créé pour le projet (Modl). La version qui arrive (0.14) utilisera la bibliothèque reconnue Eloquent (utilisée par le cadriciel Laravel).

Ce changement m’a permis d’utiliser des fonctionnalités comme le eager loading et le lazy loading, mais aussi d’écrire des migrations proprement et d’optimiser certaines requêtes.

Plus d’informations dans l’article dédié.

Ce que j’ai appris

Après toutes ces années à travailler sur ce project temps réel, je peux maintenant tirer certaines conclusions sur les choix et changements que j’ai réalisés :

  • PHP n’est pas un problème la plupart du temps : PHP est rapide, vraiment rapide ; la plupart des optimisations que j’ai obtenues étaient liées à la façon dont je gérais les flux et leur contenu ainsi qu’aux requêtes dans la BDD ; passer à PHP 7 puis aux versions suivantes a un peu amélioré les performances, mais le gain a été négligeable par rapport à ce qui a découlé des autres changements réalisés dans le code ;
  • chercher le goulot d’étranglement : quand on travaille en temps réel, même si certaines parties sont gérées par des promesses et autres systèmes asynchrones, il y a toujours du code synchrone et donc bloquant ; il faut s’assurer que ce code n’est pas « trop lent ». Dans Movim, par exemple, les requêtes BDD sont toujours considérées comme bloquantes (c’est une autre optimisation qui pourrait être apportée…) ce qui fait qu’une requête qui prend 200 ms à être déclenchée va retarder l’exécution du reste du code de 200 ms ;
  • tester en « conditions réelles » : je pensais que Movim était rapide jusqu’au moment où j’ai vu des utilisateurs galérer avec (Nik, si tu me lis…) ; certains utilisateurs de Movim avaient beaucoup plus de salons de discussion et avaient souscrit à beaucoup plus de flux que prévu, ce qui a créé de gros ralentissements, en particulier pendant la phase de connexion ; grâce à quelques optimisations bien pensées (et parfois très simples), les choses sont revenues à la normale ;
  • et peut‐être la plus importante de toutes : Keep It Simple!

J’ai l’impression que beaucoup de projets accordent trop d’importance au principe DRY — Don’t Repeat Yourself). Parfois il n’est pas nécessaire d’importer une bibliothèque entière, écrire une fonction qui correspond exactement à la situation peut faire l’affaire. Il est préférable de garder aussi peu de dépendances que possible.

Questionnez‐vous sur ce dont votre projet a besoin pour fonctionner. Est‐ce que tout est vraiment indispensable ?

Et pour finir, n’ayez pas peur d’un grand ménage de printemps de temps en temps (j’ai passé 50 heures à remplacer Modl par Eloquent) pour simplifier et nettoyer votre code si nécessaire.

Du coup, Movim est rapide ?

Movim est rapide. Dans certains cas, Movim est même plus rapide que certains clients XMPP natifs comme Pidgin ou Gajim. Movim est aussi plus rapide que certaines autres plates‐formes de discussion en ligne, de par son back‐end, mais aussi grâce à la façon dont son frontal est mis en œuvre. J’en reparlerai dans un prochain article.

Sur mon compte (400 contacts, 50 salons de discussion) s’authentifier et obtenir une interface réactive ne prend qu’une poignée de secondes, surtout sachant que les données viennent d’un serveur tiers (votre serveur XMPP) et sont re‐synchronisées pour certaines lorsque vous vous connectez.
Si vous voulez voir le résultat par vous‐même, faites un tour sur le site officiel. ;)

That’s all folks!

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Agenda du Libre pour la semaine 33 de l’année 2018

12 août, 2018 - 20:39

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

Sommaire [FR Toulouse] Rencontres Tetalab - Le mercredi 15 août 2018 de 20h30 à 23h30.

Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

Ouvert au public tous les mercredi soir.

Venez nombreux.

[FR Montpellier] Aprilapéro - Le jeudi 16 août 2018 de 18h45 à 19h30.

Un apéro April consiste à se réunir physiquement afin de se rencontrer, de faire plus ample connaissance, d’échanger, de partager un verre et de quoi manger mais aussi de discuter sur l’actualité et les actions de l’April.

Un apéro April est ouvert à toute personne qui souhaite venir, membre de l’April ou pas. N’hésitez pas à venir nous rencontrer.

Régulièrement Montpel’libre relaie et soutient les actions de L’April. De nombreux Apriliens ont par ailleurs rejoints les rangs de Montpel’libre, sans doute lors d’Apéro April, d’AprilCamp ou des Rencontres Mondiales du Logiciel Libre qui ont eu lieu à Montpellier.

Nous vous invitons donc à venir nous rejoindre dans une ambiance conviviale, à partager cet apéro, chacun porte quelque chose, boissons, grignotages… et on partage.

Au programme des discussions

  • démarche et étapes pour la mise en conformité au RGPD des outils de l’April
  • discussions libres
  • échanges d’idées
  • faire un bilan des événements passés
  • faire des perspectives pour les actions futures
  • tout simplement, passer un moment convivial

Entrée libre et gratuite sur inscription.

Les Aprilapéro Montpellier ont lieu le 3e jeudi de chaque mois

  • Jeudi 21 septembre 2017 de 18h18 à 20h20
  • Jeudi 19 octobre 2017 de 18h18 à 20h20
  • Jeudi 16 novembre 2017 de 18h18 à 20h20
  • Jeudi 21 décembre 2017 de 18h18 à 20h20
  • Jeudi 18 janvier 2018 de 18h18 à 20h20
  • Jeudi 15 février 2018 de 18h18 à 20h20
  • Jeudi 15 mars 2018 de 18h18 à 20h20
  • Jeudi 19 avril 2018 de 18h18 à 20h20
  • Jeudi 17 mai 2018 de 18h30 à 19h30
  • Jeudi 21 juin 2018 de 18h30 à 19h30
  • Jeudi 19 juillet 2018 de 18h30 à 19h30
  • Jeudi 16 août 2018 de 18h30 à 19h30

Cet événement vous est proposé dans le cadre du partenariat qui lie le Club de la Presse, l’April et Montpel’libre.

Jeudi 16 août 2018 de 18h45 à 19h30 (3e jeudi de chaque mois)
Do Tank au 2, rue du Pavillon, 34000 Montpellier

[FR Montpellier] FSFEapéro - Le jeudi 16 août 2018 de 19h30 à 20h15.

Afin de se rencontrer, d’échanger et de faire plus ample connaissance, lance de nouvelles rencontres surnommées les FSFEapéros. C’est l’occasion pour les neurones de toute part de se réunir physiquement pour discuter, échanger et partager un verre et de quoi grignoter.

Les FSFEapéros auront lieu tous les 3e jeudis de chaque mois. Ils sont l’occasion de discussions informelles d’une part et de discussions plus sérieuses sur les différents thèmes d’importance et les différentes actions et campagnes en cours.

Tout le monde est invité et peut venir aux FSFEapéros, qu’on soit contributeur de longue date, simple intéressé-e par les sujets que défend la Free Software Foundation Europe, ou nouvel-le arrivant-e cherchant à participer davantage. N’hésitez pas à amener vos amis et à leur faire découvrir La FSFE et Montpel’libre.

Peuvent être aussi abordées des questions sur Les exégètes amateurs ou Open Law.

Cet événement vous est proposé dans le cadre du partenariat qui lie le Club de la Presse, la FSFE et Montpel’libre.

Jeudi 16 août 2018 de 19h30 à 20h15 (3e jeudi de chaque mois)
Do Tank au 2, rue du Pavillon, 34000 Montpellier

[FR Montpellier] Quadrapéro - Le jeudi 16 août 2018 de 20h15 à 21h00.

Afin de se rencontrer, d’échanger et de faire plus ample connaissance, lance de nouvelles rencontres surnommées les Quadrapéros. C’est l’occasion pour les neurones de toute part de se réunir physiquement pour discuter, échanger et partager un verre et de quoi grignoter.

Les Quadrapéros auront lieu tous les 3e jeudis de chaque mois. Ils sont l’occasion de discussions informelles d’une part et de discussions plus sérieuses sur les différents thèmes d’importance et les différentes actions et campagnes en cours.

Tout le monde est invité aux Quadrapéros, qu’on soit contributeur de longue date, simple intéressé-e par les sujets que défend la Quadrature, ou nouvel-le arrivant-e cherchant à participer davantage. N’hésitez pas à amener vos amis et à leur faire découvrir La Quadrature et Montpel’libre.

Peuvent être aussi abordées des questions sur Les exégètes amateurs ou Open Law.

  • Action de groupe contre les GAFAM

Cet événement vous est proposé dans le cadre du partenariat qui lie le Club de la Presse, la Quadrature et Montpel’libre.

Jeudi 16 août 2018 de 20h15 à 21h00 (3e jeudi de chaque mois)
Do Tank au 2, rue du Pavillon, 34000 Montpellier

[FR Metz] Permanence été 2018 - Le samedi 18 août 2018 de 14h00 à 18h00.

Il s'agit d'une permanence de l'association Graoulug Groupe d'Utilisateurs Linux et Logiciels libres de Metz et environs.

[FR Metz] Install-Party GNU/Linux - Le samedi 18 août 2018 de 14h00 à 18h00.

L'association Graoulug organise une Install-Party GNU/Linux.

Si vous voulez installer GNU/Linux sur votre ordinateur, amenez-le.

Les membres de l'association vous aiderons à y installer la distribution GNU/Linux de votre choix (Ubuntu, Linux Mint…).

Vous pourrez aussi apprendre à installer des application libres sur votre smartphone, avec F-Droid.

[CA-QC Montréal] Vidéo Femmes journée Wiki à la Cinémathèque québécoise - Le samedi 18 août 2018 de 13h00 à 18h00.

Activité gratuite et ouverte à tous

HORAIRE DE L'ÉVÉNEMENT
13 h à 15 h (Salle Fernand Seguin) : L'aventure Vidéo Femmes (discussions et projections)
15 h à 18 h (Bar Salon) : 4 à 6 Wiki (partage de connaissance)

**L'aventure Vidéo Femmes
**Cette séance contribuera à enrichir l’histoire d’un collectif de réalisatrices féministes encore méconnues. Il s’agit du centre d’artistes, Vidéo Femmes, fondé en 1973 à Québec, par trois pionnières de la vidéo d’intervention sociale Hélène Roy, Helen Doyle et Nicole Giguère. Vidéo Femmes est à l’initiative d’une production d’environ 400 films et d’un grand réseau de distribution d’œuvres vidéographiques.

Nous commencerons cet atelier par une présentation du collectif, en présence de plusieurs cinéastes. À travers différents témoignages et extraits de films, nous vous inviterons à découvrir la richesse de ce corpus protéiforme. Autour de thématiques liées au Mouvement de libération des femmes dans les années 1970, Vidéo Femmes est aujourd’hui une ressource incontournable pour documenter et compléter l’histoire du cinéma québécois.

4 à 6 Wiki
Après un après-midi de projections et discussions autour de Vidéo Femmes, nous vous invitons à un 4 à 6 complètement Wiki au bar-salon
Ce mois-ci, nous troquons notre traditionnelle soirée Wiki mensuelle pour un 4 à 6 collaboratif et informel durant lequel nous nous concentrerons sur le partage des connaissances autour de Vidéo Femmes et des réalisatrices qui y sont associées. Ces petits moments Wiki vous permettent de participer au partage des connaissances et à la création d’un commun de savoir. Rejoignez cette communauté grandissante et partagez votre savoir avec le monde

Formation et contribution libre aux projets Wikipédia, Wikidata et Wikimédia Commons.
Tout le monde est bienvenu, que vous soyez simplement curieux d'en savoir plus sur les projets Wikimédia ou sur le cinéma, débutant ou contributeur averti, professionnel, étudiant ou amateur, passionné ou non de cinéma

*Des ordinateurs seront disponibles sur place, mais il est conseillé d'apporter votre propre ordinateur

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Les journaux LinuxFr.org les mieux notés du mois de juillet 2018

6 août, 2018 - 23:25

LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l’équipe de modération avant publication. C’est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.

Ce que l’on sait moins, c’est que LinuxFr.org vous propose également à tous de tenir vos propres articles directement publiables, sans validation a priori des modérateurs. Ceux‐ci s’appellent des journaux. Voici un florilège d’une dizaine de ces journaux parmi les mieux notés par les utilisateurs… qui notent. Lumière sur ceux du mois de de juillet passé :

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Le Jet Propulsion Laboratory de la NASA publie les plans du rover Curiosity sur GitHub

5 août, 2018 - 21:09

Le Jet Propulsion Laboratory de la NASA (avec CalTech), qui a construit l’astromobile / le rover Curiosity pour explorer la planète Mars, a publié sur GitHub les plans d’une version réduite et abordable de ce véhicule sous licence Apache v2.

Vous pouvez donc l’étudier, le construire ou l’améliorer !

Le cerveau utilisé est un RaspBerry Pi. Vous pouvez le contrôler via une application Android.

N. D. M. : Ce rover est une version réduite (36 cm, 11 kg, 17 cm/s) de Curiosity (2,7 m, 899 kg et 4 cm/s sur Mars). Il est conçu pour pouvoir être réalisé avec des composants du commerce. La publication a été réalisée pour « inspirer la future génération des scientifiques, ingénieurs et roboticiens pour nous aider à explorer et découvrir notre système solaire (et au‐delà !) ». L’utilisation de la licence Apache v2 semble contredite par les critères supplémentaires suivants : être âgé de plus de 18 ans, décharge de responsabilité et pas d’utilisation commerciale. Le JPL explique par ailleurs avoir produit précédemment une version réduite de Curiosity à des fins éducatives (un mini‐rover baptisé ROV-E), pour les classes, musées et événements scolaires. Et face au succès, ils ont décidé de produire un modèle inspirant et réalisable pour moins de 2 500 US$ (environ 2 160 €).

   Crédit NASA/JPL-Caltech

   Crédit NASA/JPL-Caltech

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

20 ans de LinuxFr.org : entretiens avec les visiteurs (6)

5 août, 2018 - 12:52

Le 28 juin 2018, le site LinuxFr.org fêtait ses vingt ans. L’équipe du site a réalisé des entretiens par courriel avec des visiteurs (et contributeurs) réguliers du site. Les réponses sont publiées par lot de cinq répondants, et dans ce dernier lot (Adrien Dorsaz, JPEC, Christophe Chapuis, Anthony Jaguenaud et dzecniv), les répondants sont interviewés pour la première fois.

Les questions de chaque entretien sont les suivantes :

  • Quand et comment avez‐vous connu LinuxFr.org ?
  • Quelle est votre utilisation du site, en termes de fréquence, de méthode de consultation (navigateur, flux Atom/RSS, mobile, etc.) ? Quels sont les contenus (dépêches, journaux, sondages, forums, wiki, liens) que vous lisez ? Ceux que vous préférez ?
  • Quel est votre meilleur souvenir sur LinuxFr.org (avec un lien, si possible) ? Pensez‐vous que c’était mieux avant ?
  • Qu’aimeriez‐vous trouver sur LinuxFr.org qui n’y figure pas ? Quel type de contenu ou de fonctionnalités rêveriez‐vous de voir arriver ?
  • Contribuez‐vous à des projets libres, et si oui, lesquels ?
  • Si vous deviez mettre un coup de projecteur sur un ou plusieurs projets libres, lesquels citeriez‐vous ?
  • À votre avis, à quoi ressemblera LinuxFr.org dans vingt ans ? Le Libre dans vingt ans ?
  • Quel serait l’environnement / la configuration de vos rêves ?
  • Autre chose à rajouter ?

Quand et comment avez‐vous connu LinuxFr.org ?

Adrien Dorsaz (compte créé en 2010) : Je pense que j’ai connu LinuxFr.org vers 2008-2009, sous mon pseudo Trim, lorsque j’ai commencé à côtoyer l’association Swisslinux.org et, en particulier, eggman, qui m’a fait découvrir l’ambiance du site. :)

JPEC (compte créé en 2010) : Je ne me rappelle plus comment j’ai découvert ce site (sûrement Google ou un lien sur un forum) ni en quelle année j’ai créé mon compte sur DLFP, mais ma première dépêche date de 2010… Je me souviens qu’à l’époque je lisais attentivement des épisodes sur le noyau par patrick_g.

Christophe Chapuis (compte créé en 2001) : C’était il y a bien longtemps, vers 2000-2001, peut‐être via Google Altavista. Depuis, LinuxFr.org m’a permis de découvrir et d’apprendre énormément autour du logiciel libre.

Anthony Jaguenaud (compte créé en 2002) : Vers 1999, quand j’ai commencé à travailler. En cherchant de l’information sur GNU/Linux.

dzecniv (compte créé en 2013) : Ouh, je ne sais plus, probablement vers la fin de mes études, donc il y a 4/5 ans (allez, 6), car je crois avoir déjà regretté de ne pas avoir lu LinuxFr.org plus tôt. Pendant un moment je ne comprenais pas grand‐chose à ce qu’il s’y disait, puis j’ai dû programmer, puis j’y ai pris goût, et je suis devenu un régulier… et un contributeur.

Quelle est votre utilisation du site, en termes de fréquence, de méthode de consultation (navigateur, flux Atom/RSS, mobile, etc.) ? Quels sont les contenus (dépêches, journaux, sondages, forums, wiki, liens) que vous lisez ? Ceux que vous préférez ?

Adrien Dorsaz : Je suis les flux RSS des liens, forums, journaux et dépêches. J’utilise mon FreshRSS, donc via mon mobile ou d’autres périphériques et je l’ai programmé pour récupérer les nouvelles trois fois par jour pour les transports et me laisser en paix le week‐end. Je lis surtout les journaux et dépêches sur un peu tous les sujets (exceptés ceux liés à la politique française, étant Suisse). Ceux qui me plaisent le plus sont ceux qui sont un peu techniques et me font découvrir de nouveaux domaines, surtout sur les sujets du développement logiciel, de Mozilla et de GNOME.

JPEC : Je consulte le site quotidiennement principalement lors des « pauses » au boulot ou sur mon mobile. Je lis principalement les dépêches et les journaux et lorsque que le titre m’interpelle les forums. Je commente rarement.

Christophe Chapuis : J’utilise un navigateur, quotidiennement, pour regarder les nouveaux contenus ou les nouveaux commentaires sur un sujet qui m’intéresse. Je lis principalement les dépêches et les journaux, et je commence à m’habituer aux liens. J’aime parcourir les commentaires, qui sont (malgré les quelques trolls) d’une qualité au‐dessus du lot sur Internet 2.0. J’utilise aussi la tribune — je n’ai jamais réussi à m’en détacher.

Anthony Jaguenaud : Mon utilisation n’a pas vraiment changé. Juste qu’aujourd’hui, je suis les flux RSS. J’ouvre tous les journaux et toutes les dépêches. Je recharge chaque article tous les jours, une à deux fois, pour voir les commentaires. Sur certains sujets polémiques, je peux prendre cent commentaires d’un coup, ce que je ne peux pas traiter. ;-) Concernant les liens, je ne les lis pas vraiment. Des fois, je vois un titre accrocheur, je l’ouvre. S’il y a des commentaires, je les lis et, en fonction, j’ouvre le lien. Sans commentaires, j’ai une chance sur deux d’ouvrir le lien.
Je ne sais pas si ça apporte quelque chose par rapport aux journaux bookmark. Peut‐être moins de commentaires.

dzecniv : Je suis abonné au flux RSS des dépêches et des journaux. Je contribue à certains wikis et forums, mais plus spécialisés ou plus tournés vers les Linuxiens débutants que ceux de LinuxFr.org. J’adore les articles qui présentent des technos (langages de programmation, logiciels, protocoles…) peu usitées et qui te font ouvrir des yeux ébahis. Et ça arrive toujours !

Quel est votre meilleur souvenir sur LinuxFr.org (avec un lien, si possible) ? Pensez‐vous que c’était mieux avant ?

Adrien Dorsaz : L’écriture de la dépêche « Protéger sa vie privée avec l’IPv6 » est un très bon souvenir : d’une nouvelle des développeurs de NetworkManager, j’ai découvert des détails sur l’IPv6 par rapport à IPv4, j’ai pu partager mes découvertes et quelques commentaires.

JPEC : Je n’ai pas d’exemple précis à donner, mais il y a régulièrement des dépêches intéressantes (sur des sujets techniques ou pas).

Christophe Chapuis : J’ai toujours apprécié les dépêches sur les noyaux Linux : c’est une mine d’or ! Et, non, ce n’était pas mieux avant : la qualité de LinuxFr.org a su rester d’une belle constance au fil des ans.

(pas de réponse d’Anthony Jaguenaud à cette question)

dzecniv : L’article « Le bitcoin va‐t‐il détruire la planète ? », contrepoint à un article ridicule, a été jubilatoire. Bravo encore à l’auteur. Je m’étais fendu d’un commentaire sur Le journal du hacker, j’ai agi quoi :p. Mais, là, chapeau. Et puis, j’ai eu une période intense où j’ai voulu parler de plusieurs projets qui n’étaient pas ou peu relayés ici (Emacs, Guix, GitLab, projets qui décentralisent Internet©, j’oublie). Donc, forcément, plus tard, je demande à untel s’il connaît telle techno, et comme il répond « Je l’ai lu sur LinuxFr.org », je suis satisfait :].

Qu’aimeriez‐vous trouver sur LinuxFr.org qui n’y figure pas ? Quel type de contenu ou de fonctionnalités rêveriez‐vous de voir arriver ?

Adrien Dorsaz : Il faudrait moderniser l’infrastructure, avec un accès depuis l’Internet « moderne » IPv6 ! J’aimerais bien que les utilisateurs ne se gênent pas d’utiliser les journaux pour nous faire découvrir leurs intérêts. N’hésitez pas à faire des journaux courts, le sujet pourra intéresser quelqu’un ou ouvrir un débat :).

JPEC : Je suis d’accord avec reynum sur la pertinence de l’ajout d’une section dédiée aux tutoriels.

Christophe Chapuis : Difficile à dire, je suis assez content de l’aspect actuel du site : léger, fonctionnel, clair. L’essentiel (le contenu) est bien mis en avant. Alors, peut‐être rajouter un « +/- » en plus de « pertinent/inutile », pour voir, mais c’est un détail, je pense.

(pas de réponse de Anthony Jaguenaud à cette question)

dzecniv : J’aimerais un suivi plus facile des commentaires, pouvoir être notifié de réponses à son commentaire notamment. Je compare avec Reddit. Dans la même veine, un tableau de bord plus complet, me permettant de voir tout mon contenu, voire d’en garder en marque‐pages et de me créer une liste de liens. Une prévisualisation de ses écrits, plus pratique lorsqu’elle existe. Revoir et mettre en avant le wiki ?

Contribuez‐vous à des projets libres, et si oui, lesquels ?

Adrien Dorsaz : Actuellement, je m’amuse à faire un client XMPP PubSub, et je suis les RFC de Let’s Encrypt pour maintenir à jour mon client ACME. J’aimerais retrouver du temps pour réinstaller LinuxFr.org sur mon PC et participer aux futures transformations prévues.

JPEC : En ce moment, non, par manque de temps… En revanche, je bricole un prototype de gCoin qui pourrait être publié à terme.

Christophe Chapuis : Je contribue au projet LuneOS depuis quelques années : c’est vaste, varié, et j’apprends beaucoup en m’amusant.

Anthony Jaguenaud : Le temps me manque toujours pour contribuer vraiment. Je forme mes enfants à la problématique, les initie quand ils le souhaitent, les guide vers le Libre sans les forcer. C’est ma contribution pour le Libre du futur.

dzecniv : Oui, surtout les miens :) : GitLab, GitHub, notamment Abelujo, un logiciel libre de gestion de librairies (recherche bibliographique de livres avec code‐barres, de DVD, etc.), et plein de trucs dans Common Lisp depuis un an (car c’est génial et ça va me résoudre plein de limitations de Python et Django), notamment de la doc dans le CL Cookbook.

Si vous deviez mettre un coup de projecteur sur un ou plusieurs projets libres, lesquels citeriez‐vous ?

Adrien Dorsaz : Les projets qui me motivent le plus pour l’instant sont le serveur XMPP ejabberd et le client Movim. Je trouve franchement très intéressant le standard XMPP, il est plutôt simple (oui, XML est verbeux, mais il est facile à utiliser), souple et se modernise en continu (merci aux WebSockets et à PubSub !).

(pas de réponse de JPEC à cette question)

Christophe Chapuis : Je trouve le projet Anbox très intéressant, j’espère qu’il aura un bel avenir !

(pas de réponse d’Anthony Jaguenaud à cette question)

dzecniv : Sans hésitation, le travail en cours sur Weblocks, un cadriciel Web pour écrire des applications dynamiques sans une ligne de JavaScript, dans un bon environnement, avec un langage stable et un REPL excellent. Weblocks est basé sur des widgets mis à jour côté serveur et rafraîchis côté client. Disons React, mais server‐side, pour employer un gros mot. Voyez donc le nouveau Quickstart.

À votre avis, à quoi ressemblera LinuxFr.org dans vingt ans ? Le Libre dans vingt ans ?

Adrien Dorsaz : Wow, je ne suis pas sûr que LinuxFr.org va survivre au bogue de l’an 2038, comme à l’époque où mon entourage avait peur du « bogue de l’an 2000 » :D. LinuxFr.org continuera à être un point de rencontre des utilisateurs francophones de logiciels libres. Le Libre continuera toujours d’exister : il y a aura toujours des utilisateurs heureux de pouvoir utiliser leurs logiciels comme bon leur semble et quelques‐uns qui seront eux‐mêmes développeurs, artiste, traducteur, documentaliste, etc., avec du talent :).

JPEC : Je pense que dans vingt ans LinuxFr.org aura le look d’un site des années 2020 :). Blague à part, je pense que le matériel va se complexifier et qu’il sera difficile de le faire fonctionner avec du logiciel libre (par exemple, si l’on regarde les ordiphones ou les tablettes actuelles, c’est quasi impossible à faire fonctionner avec du Libre). En revanche, il restera toujours des gens passionnés qui s’investiront afin de proposer des solutions ouvertes.

Christophe Chapuis : Peut‐être y accèdera‐t‐on via IPv6 ;-) ? Je ne sais pas… Mais LinuxFr.org répond à un besoin, et y répond de manière élégante. Pour le Libre, je pense qu’un virage à ne pas manquer est le domaine de l’embarqué : on va vers plus d’objets connectés, mais ces objets sont actuellement très fermés. Leur cycle de vie et leur interopérabilité dépendent du bon vouloir du constructeur. J’espère que le Libre saura convaincre, à la fois en entreprise et chez les particuliers.

(pas de réponse d’Anthony Jaguenaud à cette question)

dzecniv : Vu la tendance, il y aura beaucoup de Libre d’entreprise, pour des solutions complexes ou dans les nuages, qui nous feront quand même perdre en autonomie. Le discours critique sera similaire (« certes, une puce intra‐cutanée est pratique, mais… »). La monnaie libre G1 aura 300 millions d’utilisateurs, sortant des millions de personnes de la pauvreté et permettant aux plus motivé·e·s de vivre facilement sans salariat et de se consacrer à leurs projets.

Quel serait l’environnement / la configuration de vos rêves ?

Adrien Dorsaz : Retrouver une mini‐machine à la taille du Eee PC 900, toujours aussi évolutif et réparable (batterie non soudée, disque SSD remplaçable, mémoire vive accessible…), mais avec du matériel assez récent pour faire tourner un navigateur Web et un EDI correctement ! Tout ceci avec un GNOME 3 sous Debian évidemment :D.

JPEC : Un écran, un clavier BÉPO, un trackball, un dock et un ordiphone < 5" qui tourne sous Debian stable pour le socle et la dernière version de GNOME pour la couche utilisateur.

Christophe Chapuis : Le meilleur environnement, pour moi, est celui qui se fait oublier. C’est un subtil équilibre entre flexibilité, efficacité, ergonomie et stabilité. Pour l’instant XFCE me convient bien !

(pas de réponse de _Anthony Jaguenaud à cette question)

dzecniv : Un environnement modifiable à la volée et totalement scriptable. Donc il y aura du Lisp forcément, avec ou sans Emacs, mais avec GNU Guix.

Autre chose à rajouter ?

Christophe Chapuis : \_o< !

Anthony Jaguenaud : Un grand merci à l’équipe qui prend le temps de faire vivre ce site.

dzecniv : Merci aux bénévoles de LinuxFr.org !

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Agenda du Libre pour la semaine 32 de l’année 2018

4 août, 2018 - 22:56

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

Sommaire [CA-QC Montréal] Linux-Meetup Montréal - Le mardi 7 août 2018 de 19h00 à 22h00.

Local de la rencontre à confirmer

Programmation de la rencontre

ATTENTION Le conférencier invité n'a pas encore été choisi. Si vous connaissez des compagnies œuvrant dans le logiciel libre, n'hésitez pas à m'envoyez un message.

Ce mois-ci, nous aurons plusieurs petites présentations éclairs ("lightning talks") reliées à Linux et aux logiciels libres.

Avis aux intéressés, envoyez-moi un courriel si vous voulez présenter quelques choses. Sinon, ce sera des présentations éclairs improvisées avec les gens présents.

Par la suite, si le temps le permet, on fera une discussion de groupe sur un thème déterminé par les gens présents … discussions libres et ouvertes

Lieu
Le Linux-Meetup aura lieu à l'École de Technologie Supérieure de 19:00 à 22:00.

Extras

Pour ceux voulant réseauter avec les autres avant, il y aura un souper de 17:30 à18:45 (Resto-pub Le 100 génies de l'ÉTS au pavillon B).

Nous invitons tous les amateurs de logiciels libres (peu importe la plate-forme) à venir discuter. C'est vraiment une excellente occasion de socialiser et de faire connaissance avec d'autres qui partagent les mêmes intérêts.

La rencontre est gratuite et ouverte à tous (de débutants à experts) et rassemble des gens de diverses professions gestionnaires, professeurs, administrateurs de systèmes, ingénieurs, programmeurs, retraités, étudiants, etc.

Les Linux-Meetup se déroulent simultanément à travers le monde tous les premiers mardis du mois ainsi que dans plusieurs régions du Québec.

Vous pouvez confirmer votre présence sur un ou plusieurs réseaux sociaux afin de promouvoir l'événement Google+, Linkedin, Facebook, Twitter et Meetup

Au plaisir de vous rencontrer

Martial

P.S.: Pour le transport en commun Station de métro Bonaventure

[FR Caen] Atelier Inkscape, niveau avancé - Le mercredi 8 août 2018 de 17h00 à 19h00.

L'association Artifaille organise un atelier de dessin vectoriel avec Inkscape – Avancé.

Une approche plus avancée du dessin vectoriel pour des utilisateurs déjà initiés. Il s’agira ici d’aborder des techniques avancées sur des exemples concrets. Notamment reconstruire ou s’inspirer de logos existants (graphiques ou textes), détourer ou styliser à partir d’une référence photo, créer des objets en 2D ou un décor.

Les sujets suivants seront abordés et mis en pratique par les participants

  • Copie et clone
  • Chemins (conversions, opérations booléennes, édition des nœuds)
  • Outils main libre et Bézier
  • Découpe et masque
  • Texte
  • Assistance (guides, grille, magnétisme…)

Pré-requis connaître et avoir utilisé les techniques de base du logiciel (navigation, sélection, déplacement et déformation d’objets, création de formes simples, couleurs de fond et contour, empilement des objets…). Venir avec son PC et Inkscape pré-installé (www.inkscape.org), une souris avec molette vivement conseillée.

Réservé aux adhérents Artifaille.
Sauf "Ateliers prix libres" et permanences Artifaille (bien sûr), le premier atelier est gratuit avec une nouvelle adhésion anuelle.
Lieu Maison des Solidarités, 51 Quai de Juillet, à Caen
Pour toute question contact@artifaille.fr ou sur laissez-nous votre message sur le répondeur du

[FR Nantes] Apéro Monnaie Libre - Le mercredi 8 août 2018 de 19h00 à 21h30.

Tous les deuxièmes mercredi du mois, venez la découvrir la Monnaie Libre, durant lesquelles des membres vous présenterons les différentes facettes de cette belle innovation.

Les Apéros Monnaie Libre sont l’occasion de nous rencontrer entre membres et futurs membres de la monnaie libre Ğ1.

Que vous soyez totalement débutant ou utilisateur confirmé, tout le monde est bienvenue aux apéros monnaie libre

• Présentation en Question/Réponse, de ce qu’est la Monnaie Libre Ḡ1 (pour ceux qui ne connaissent pas ou peu) &

• Assistance création/utilisation de porte-feuille Ğ1 sous Césium.

Mais c’est quoi la Ğ1 C’est le nom de la 1ère et seule monnaie libre existante à ce jour, une monnaie co-créée par tous les humains qui l’utilisent, c’est un revenu de base par création monétaire. Plus de détail ici http://nayya.org/ Si vous souhaitez de l’assistance pour créer ou utiliser votre compte Ğ1, nous vous recommandons d’apporter votre appareil (téléphone, tablette, pc portable).

Ǧmarché Ces apéros sont aussi un moment privilégié pour demander ou proposer des biens et services en Ğ1

[FR Toulouse] Université de Nuit d'été - Du mercredi 8 août 2018 à 19h00 au dimanche 12 août 2018 à 17h00.

8-12 août 2018{::}  * La châleur et l'ennui vous accable Vous n'avez nulle part ou aller ce mois d'aoüt Ou vous êtes tout simplement curieux
* Vous êtes invité à venir participer a la première édition de l'Université de Nuit d'Été du Tetalab, du mecredi 8 au dimanche 12 août 2018.
* Les activités débuteront chaque soir vers 20h quand la température commence à devenir supportable, et se dérouleront jusqu'à entre 00h00 et 02h00.

 * Au programme
*  Ateliers/cours d'initiation ou plus avancés

 *  langages informatiques, logiciels, électronique, soudure…
*  moteurs de jeux videos 
*  graphisme et création 3D

 *  Une "Game Jam"
* conception d'un jeu vidéo en 48h, de A a Z, en solo ou en équipe.

  Restitution le dimanche en fin d'après-midi. *  Soutien à des projets DIY

  - les participants sont invités à venir échanger autour de problématiques rencontrées dans leurs projets DIY.  * la bienveillance, le sourire et faire des trucs qui font briller les yeux

  Mix'Art Myrys, 12 rue Ferdinand Lassalle, 31200 Toulouse

[FR Toulouse] Rencontres Tetalab - Le mercredi 8 août 2018 de 20h30 à 23h30.

Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

Ouvert au public tous les mercredi soir.

Venez nombreux.

[CA-QC Coteau du Lac] Émission #157 de bloguelinux - Le jeudi 9 août 2018 de 20h00 à 21h00.

bloguelinux.ca est un blogue québécois offrant la diffusion d'un podcast qui traite des logiciels libres, du système d'exploitation Linux et de la technologie en général il y a un processeur, il y a un système d'exploitation, c'est certain que ça nous intéresse

bloguelinux.ca est enregistré le jeudi à 20h00 toutes les deux semaines.

Vous pouvez nous écouter en direct lors des enregistrements à l'adresse http://live.bloguelinux.ca ou directement sur notre site à http://www.bloguelinux.ca en cliquant sur la radio dans le panneau de gauche du site.

Vous pouvez rejoindre nos conversations avec Telegram en vous abonnant au groupe BlogueLinux en suivant le lien suivant https://t.me/joinchat/ArPfnBHCcui2t_CY6qAPAg et dans notre salle de chat en vous connectant sur les serveurs de freenode.net dans la salle #bloguelinux.

Si vous n'avez pas de client IRC, vous pouvez utiliser l'adresse http://webchat.freenode.net

AVERTISSEMENT Ce podcast peut contenir du langage inapproprié ou vulgaire et peut ne pas convenir à tout le monde.

Animateurs Patrick et Sandrine

[FR Orbey] Café informatique - Le samedi 11 août 2018 de 10h00 à 11h00.

Venez partager moment d’échange et de pratique autour des outils numériques animé par Ma Vallée Numérique au salon de thé Chocolat'thé.

  • Apprendre à s’en servir et s’en protéger
  • Découvrir les logiciels libres
  • Échanger nos connaissances

Tous les deux premiers samedis du mois, permanence de 10h00 à 11h00.

Pour un meilleur accueil, inscrivez-vous en ligne.
Dates et inscription sur le site.

[FR Rennes] Permanence Gulliver - Le samedi 11 août 2018 de 14h00 à 18h00.

Venez vous renseigner pour diffuser largement vous œuvres.

Sinon venez installer Linux ou des logiciels libres.

Venez nombreux.

[CA-QC Montréal] WordCamp Montréal 2018 - Du samedi 11 août 2018 à 08h00 au dimanche 12 août 2018 à 17h00.

WordCamp Montréal est une conférence de deux jours à propos de WordPress, la plateforme de blogue et le système de gestion de contenu le plus populaire au monde. Développeurs, designers, professionnels du Web et blogueurs se rassembleront pour assister à des présentations et des ateliers au sujet de WordPress et pour réseauter.

Pour notre 10 anniversaire, l’événement aura lieu à l’école de gestion John Molson School of Business au centre-ville de Montréal les 11 et 12 août, 2018.

Pour consulter la programmation complète de l'événement

https://2018-fr.montreal.wordcamp.org/programme/

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Sortie d’OpenMW 0.44

3 août, 2018 - 11:00

L’équipe d’OpenMW est très fière d’annoncer la sortie de la version 0.44.0 de son moteur libre permettant de jouer à Morrowind, avec quelques fonctionnalités en plus et beaucoup de bogues en moins.

Sommaire

Déjà évoqué sur LinuxFr.org, OpenMW est non seulement une ré‐implémentation libre du moteur du jeu de rôle The Elder Scrolls III: Morrowind, un des meilleurs JDR (jeu de rôle, RPG) au monde, mais aussi un éditeur permettant de créer du contenu pour ce nouveau moteur. Pour jouer à Morrowind, il vous faudra une version originale du jeu, de laquelle on extraira les données, disponible à un prix complètement raisonnable sur Good Old Games par exemple.

La version 0.44.0, sortie le week‐end dernier corrige une petite centaine de bogues, et ajoute quelques améliorations en termes d’accessibilité. La précédente dépêche sur LinuxFr.org au sujet d’OpenMW datant de près de trois ans, celle‐ci va déborder un peu du cadre de la nouvelle mouture, et s’étaler sur quelques changements et nouveautés intéressantes de ces dernières années.

Friandises pour les yeux

Depuis le basculement, il y a trois ans (déjà) vers OpenSceneGraph comme moteur 3D, les ombres en temps réel ne sont plus prises en charge, mais ne devraient pas tarder à revenir, vraisemblablement dans la prochaine version. La bonne nouvelle, c’est que les ombres ne sont pas les seules fonctionnalités graphiques ajoutées par le projet : la prise en charge de l’affichage des terrains distants, permettant d’afficher la carte du jeu à perte de vue ou presque, des particules plus belles ou encore, la pluie et la neige troublant la surface de l’eau :

Ou encore, la possibilité de jouer avec des nuanceurs (shaders), pour ajouter un brouillard :


Ou, comme dans les jeux modernes, la prise en charge du placage de relief (bump mapping) :


Objectifs et directions

Suite au rachat de GitHub par Microsoft, le projet en a profité pour se chamailler en interne déplacer une partie de son infrastructure sur GitLab : le Redmine vieillissant qui servait de système de suivi de bogues a également migré là‐bas, et le wiki est en train de l’être. Pour celles et ceux qui préfèrent utiliser GitHub, pas de panique, il est synchronisé avec GitLab.

Au sujet de ce qu’il va arriver après la sacro‐sainte 1.0, notre BDLF a passé une quantité de temps faramineuse à écrire un document de 80 pages sur la direction envisagée pour le futur, à moyen et long terme du projet : doit‐on améliorer le langage de script existant, ou proposer du Lua et implémenter un transpileur ? Comment étendre le format des sauvegardes afin de pouvoir y fourrer plus de choses ? Comment remplacer les valeurs codées en dur dans le code, afin de rendre le moteur plus flexible ? Une chouette lecture pour un dimanche pluvieux donc.

Bien que les modifications apportées par OpenMW par rapport à l’original soient mineures, il y aura toujours des puristes pour râler que c’était mieux avant™. C’est pourquoi le lanceur possède maintenant un onglet dédié aux préférences avancées, pour permettre à tout le monde de choisir :

Comme dans tout projet (et plus particulièrement, en matière de jeux vidéo), OpenMW compte son nombre de bogues idiots et amusants, qui sont petit à petit corrigés, ne laissant que le souvenir d’avoir connu tel ou tel bogue, et de pouvoir passer pour un vieux con sur IRC. Par exemple, avant la version 0.43.0, les PNJ oubliaient de remonter à la surface pour respirer quand ils étaient sous l’eau. Ou encore, la pluie qui parfois tombait à l’envers, de bas en haut ; les PNJ qui oubliaient d’attaquer le joueur, les statistiques qui passaient dans les négatifs, les créatures volantes soumises au pathgrid, etc.

Nouvelles fonctionnalités

Le but de la version 1.0 est une compatibilité totale avec Morrowind (sauf pour les bogues aberrants, évidemment), les nouveautés significatives arriveront après, mais ça n’empêche pas des fonctionnalités mineures de se glisser dans OpenMW de temps à autre !

Accessibilité

Parmi les ajouts de fonctionnalités mineures, comme évoqué plus haut dans la dépêche, on peut citer pas mal de corrections ou d’améliorations en matière d’accessibilité et d’ergonomie : les menus du jeu peuvent maintenant être entièrement parcourus au clavier, les ingrédients s’entassent mieux dans l’inventaire, un tas d’infobulles (optionnelles) ont été ajoutées, que ce soit pour savoir si ce set d’alchimie qui vous fait de l’œil appartient à quelqu’un, ou si vous pouvez le faire tomber dans votre poche sans risque, l’affichage des dégâts des projectiles, le taux de succès des enchantements… Il est possible d’utiliser à la fois un clavier et une souris, ainsi qu’une manette.

L’interface n’est pas en reste, puisqu’elle est maintenant d’une densité adaptable : plus besoin de s’user les yeux quand on joue sur un écran avec une grosse résolution pour trier ses potions.

Ces changements peuvent sembler mineurs, mais ils changent complétement la donne pour les personnes handicapées. Imaginez jouer à un jeu à la souris quand vous avez les mains qui tremblent…

Ces petites choses en plus, et d’autres en moins…

Avec l’émergence de grosses modifications du jeu original, comme Sword of Perithia ou Arktwend, il a été nécessaire de changer pas mal de suppositions codées en dur dans le moteur de Morrowind, comme la taille de la carte ou de la mini‐carte, qui étaient invariablement boguées par ces mastodontes.

Les sauvegardes, auparavant limitée à 255, ne le sont plus et sont maintenant triées par personnage, au lieu d’être entassées dans une gigantesque liste horrible à faire défiler, et présentent des miniatures, qui permettent plus facilement de retrouver la sauvegarde que l’on cherche.

La partie audio du jeu a été améliorée, prenant en charge l’ensemble des formats acceptés par FFmpeg, et les filtres d’effet, comme l’écho dans les grottes, ou quand notre personnage est sous l’eau, sont maintenant bien moins ratés plus immersifs.

Il est courant d’amasser un tas de sortilèges dans le jeu, et c’est la pagaille pour s’y retrouver. C’est pourquoi une barre de recherche a été ajoutée ; fini de devoir passer trois heures à chercher sa boule de feu en plein combat dans un donjon

Ajouts massifs

Ça n’est pas parce que les modifications importantes ne seront pas intégrées avant la version 1.0 que des contributeurs ne s’amusent pas à en implémenter, comme la possibilité de récupération de projectiles plantés dans des surfaces, ce qui n’existe absolument pas dans le jeu original :

Ou encore des carquois (avec le bon nombre de flèches) qui, eux aussi, à la base, ne sont pas présents :

Il y a également une demande d’intégration Git massive ajoutant plusieurs milliers de lignes de code et des dépendances, afin d’améliorer drastiquement la recherche de chemin (pathfinding), à coup d’auto‐génération, produisant au passage de belles visualisations :

Une des choses que j’aime beaucoup dans Morrowind, c’est qu’il s’agit d’un formidable jeu de rôle qui se joue tout seul : pas d’autres joueurs (si ce n’est les PNJ) pour faire n’importe quoi et casser l’immersion, ou me voler mon trésor. Il était donc évident que quelqu’un allait investir son temps libre dans le seul et unique (si !) but de me gâcher mon plaisir, en créant un divergence du projet et en implémentant une version multijoueur de Morrowind, qui fonctionne !

Prise en charges des « mods »

Mais redevenons sérieux et oublions cette magie noire pour évoquer avec nostalgie le support des mods dans Morrowind, dont la communauté est loin d’être morte, avec des sites comme Wiwiland et ses centaines de mods francophones ou encore Nexus mods et ses plus de 5 000 mods disponibles. Évidemment, OpenMW a vocation à être compatible avec l’ensemble d’entre eux, et les bogues de ce côté‐ci se font plutôt rares.

Une des améliorations hautement appréciées d’OpenMW est qu’il permet d’installer chaque mod dans un dossier séparé, permettant de facilement le supprimer au besoin. Auparavant, il fallait consciencieusement noter quel mod installait quel fichier, et garder des copies des fichiers qui pouvaient être écrasés lors de l’installation, pour les restaurer lors de la suppression. Comme il est courant de jouer avec une bonne centaine de mods, leur gestion était une question épineuse qui est maintenant résolue.

Pour l’anecdote, les versions traduites du jeu le sont un peu trop, les traducteurs ayant fait du zèle, ils ne se sont pas contentés de traduire dialogues et sous‐titres, mais également certains identifiants de lieux, objets, personnages, etc., rendant parfois les mods incompatibles entre les différentes traductions.

Originellement, la création de mods s’effectuait via le construction set, le même outil qui a servi à créer Morrowind, qui est livré avec le jeu. Il est donc normal qu’OpenMW le réimplémente également, surtout que le BDFL précédemment évoqué était également contributeur à l’ambitieux projet Ultima IX: Redemption, une suite spirituelle à Ultima, sur le moteur de Morrowind, malheureusement abandonné aujourd’hui.

L’OpenCS n’est pas encore capable de remplacer complètement le construction set, mais les choses avancent, et la communauté des « moddeurs » s’y intéresse de plus en plus. Comme les fous furieux personnes derrière le titanesque projet Tamriel Rebuilt ont fait un tas de retours sur son utilisabilité, les fonctionnalités manquantes et les corrections ou améliorations à lui apporter, pour corriger certaines tares du construction set original.

Par exemple, l’application de textures était une opération pénible, qui est maintenant simplissime, vu qu’il est possible de les appliquer sous forme de brosses : imaginez pouvoir ajouter du sable sur la plage fraîchement créée, simplement en baladant le curseur de la souris dessus, comme si vous étiez en train de la peigner.

La compilation des scripts est plus stricte et détecte un plus grand nombre de soucis et mauvaises pratiques que la version originale laissait passer sans rien dire.

Conclusion

OpenMW est un projet qui poursuit son bonhomme de chemin vers une comptabilité totale de Morrowind et une réimplémentation de son éditeur, depuis près de dix ans, et tend de plus en plus vers sa version 1.0.

Disponible et empaqueté pour de multiples systèmes d’exploitation, avec une communauté accueillante et active derrière lui, il permet déjà aux joueurs et joueuses de profiter confortablement de ce formidable jeu vidéo, et compte bien continuer sur cette voie !

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Présentation de The Log File Navigator

2 août, 2018 - 09:17

The Log File Navigator, ou lnav en plus court, est un outil en ligne de commande pour afficher des journaux, sous licence BSD. Par rapport aux classiques cat, grep ou less, il propose quelques fonctionnalités supplémentaires :

  • il offre de la coloration syntaxique ;
  • il permet d’afficher plusieurs journaux en même temps, les lignes étant triées en fonction de la date et de l’heure à laquelle l’événement est survenu (c’est pratique pour corréler des informations entre plusieurs processus) ;
  • il offre différents modes d’affichage.

Lnav est un outil en ligne de commande qui permet de consulter des fichiers de journaux et de naviguer dedans, le tout dans un terminal. Il sait reconnaître différents formats de journaux (syslog, Common Web Access Log, qui est utilisé par Apache et nginx, strace, Java Logs, etc.). Cela lui permet de proposer de la coloration syntaxique sur les éléments reconnus et de trier par date d’événement les différentes lignes des journaux.

Il sait ouvrir des fichiers compressés (gzip et bzip2 notamment) et suivre un journal actif (à la façon d’un tail -f). Il est également possible d’utiliser des filtres (pour ignorer certains messages, à la grep -v) et de réaliser des recherches pour mettre en avant une expression. À noter : il est possible d’utiliser <Tab> lorsque l’on saisit une expression, pour avoir une auto‐complétion en fonction du contenu des journaux. Les raccourcis clavier sont classiques (par exemple, g pour aller au début du fichier et G pour aller à la fin, ou encore / pour lancer une recherche, comme dans less, notamment).

A priori, il serait aussi possible de jouer avec les journaux via des requêtes SQL. Un système de sessions permet également de conserver certaines informations d’une exécution à l’autre (les filtres par exemple). Enfin, petit plus, la barre à droite permet de voir rapidement à quels endroits du ou des fichiers il y a eu des lignes d’erreurs ou des lignes qui correspondent à la recherche en cours.

Au final, il est appréciable de pouvoir utiliser lnav en retrouvant la plupart des réflexes issus des outils classiques, mais avec la coloration syntaxique en plus. Pouvoir corréler simplement des informations provenant de plusieurs fichiers est également très pratique. Pour les fonctionnalités plus avancées, ça viendra peut‐être plus tard.

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Quelques petits changements sur le site

2 août, 2018 - 09:00

Si vous êtes un lecteur régulier et attentif, vous avez peut‐être remarqué quelques petits changements sur le site ces dernières semaines. J’ai touché à la CSS principale du site et, comme je suis plutôt un développeur back‐end, il est possible qu’il y ait quelques effets de bord non voulus. L’idée était de reprendre en main la feuille de style principale (qui n’avait pas été écrite par moi mais par 2PetitsVerres, dans le cadre d’un concours pour créer un nouveau style au site fin 2010 / début 2011) et de commencer à mettre en place le travail de mjourdan.

Travail technique
  • découpage de la feuille de style en plusieurs fichiers pour mieux s’y retrouver ;
  • ajout de la bibliothèque normalize.css qui permet d’effacer certaines différences dans les feuilles de style par défaut des différents navigateurs ;
  • utilisation de box-sizing: border-box; par défaut ;
  • suppression de tous les anciens préfixes CSS et utilisation d’une bibliothèque pour ajouter automatiquement des préfixes CSS pour les propriétés qui le nécessitent ;
  • utilisation de prettier pour formater les fichiers de la feuille de style principale, et de stylelint pour détecter des erreurs.
Nouvelles icônes pour les boutons

Nous utilisons maintenant de jolies icônes vectorielles au format SVG pour agrémenter les boutons sur le site. Elles proviennent de la collection Feather, sous licence MIT. L’avantage d’utiliser du SVG par rapport aux anciennes icônes au format PNG est double : ça pèse moins lourd et permet donc de charger la page plus rapidement, mais surtout, le rendu est plus propre pour les utilisateurs qui ont un niveau de zoom différent de celui par défaut.

Page « À propos »

La page « À propos » a été ajoutée selon une proposition de mjourdan. Elle permet de présenter le site aux nouveaux visiteurs et les encourager à s’inscrire. Elle met également à l’honneur des vrais gens qui font vivre le site.

Changements sur la page d’accueil

En haut de la page d’accueil, la première dépêche est un contenu sélectionné par l’équipe de modération qui reste pendant quelques jours en une du site. Il est ressorti de l’enquête que cette dépêche qui ne change pas souvent pouvait être vue comme une absence de nouveaux contenus sur le site et prêter à confusion. Nous adoptons un nouveau style pour cette dépêche, ce qui devrait permettre de mieux la distinguer des autres contenus.

Nous avons également ajouté en bas de page un texte court pour encourager tout le monde à participer. Nul besoin d’être un expert pour ça, tout le monde peut apporter sa pierre à l’édifice !

Et d’autres choses Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

GIMP 2.10.4 : on garde le rythme !

1 août, 2018 - 18:28

La troisième version de GIMP 2.10 est sortie début juillet et, conformément à notre nouvelle politique de sortie, non seulement elle contient énormément de corrections de bogues (trop pour que nous puissions les compter !), mais aussi de nouvelles fonctionnalités, telles qu’une rotation par rapport à une ligne d’horizon, ou l’étiquetage des polices de caractères !

Sommaire Rotation par rapport à une ligne d’horizon

Un besoin commun est celui de rendre une ligne bien horizontale dans une photographie. Typiquement, vous prenez une photo avec un horizon bien visible et souhaitez vous assurer que cet horizon soit horizontal.

Cela est désormais possible dans GIMP grâce à un bouton dans les options de l’outil de mesure, lequel réaligne la photo par rapport à la ligne en cours.
Pour la petite histoire : cette fonctionnalité a été intégrée suite à la demande répétée de Luk, libriste de toujours, pour lequel j’ai finalement donné un peu de temps. :-)

Chargement asynchrone des polices de caractères

Alors que GIMP sous GNU/Linux se lance aussi vite que l’éclair (ou presque !), il s’agissait en particulier d’un problème pour GIMP sous Windows et macOS : le chargement des polices de caractères par fontconfig rendait le démarrage de GIMP lent comme un escargot asthmatique lors du premier lancement ou lorsque de nouvelles polices étaient installées. Dans les cas les plus extrêmes, on recevait des rapports de plusieurs minutes d’attente pour les personnes installant des centaines de polices (ce qui n’est pas forcément si exceptionnel dans le monde des designers graphiques, une des cibles du logiciel).

Les polices ne bloquent donc plus le chargement du démarrage ! En revanche, on ne peut pas utiliser toute fonction nécessitant des polices (comme l’outil texte) tant que le chargement n’est pas terminé en arrière‐plan.

Étiquetage des polices de caractères

Il est désormais possible d’étiqueter (« taguer ») les polices de caractères, de la même manière que les brosses, motifs et dégradés. Cela fait partie de nos améliorations en cours pour rendre la gestion des ressources plus agréable (même si on a encore beaucoup de boulot !).

Mise à jour du tableau de bord

Le tableau de bord introduit dans GIMP 2.10.0 a connu quelques améliorations, notamment en affichant des données sur la mémoire physique utilisée et disponible.

Amélioration de la prise en charge du format PSD

Même si la prise en charge du format PSD d’Adobe a énormément progressé avec GIMP 2.10.0, GIMP ne le prend toujours pas encore en charge à 100 %, notamment à cause de certaines fonctionnalités manquantes.

Néanmoins, le format PSD peut aussi contenir une version pré‐composée du rendu final si le fichier a été sauvegardé avec l’option « Maximize Compatibility ». Il est désormais possible de charger dans GIMP cette version pré‐composée, ce qui permet de pouvoir charger l’image exactement comme attendue.
Cela n’améliore pas le cas d’usage d’échange de fichiers de travail si vous souhaitez continuer un travail commencé dans Photoshop (en récupérant tous les calques, etc.). En revanche, c’est une grande avancée pour le cas d’usage où vous souhaitez seulement ouvrir et utiliser directement la version finale (au cas où un designer peu doué vous envoie un PSD comme version finale unique).
Pour cela, choisissez le nouveau format « Image Photoshop (fusionnée) ».

Autour du développement Nouvelles des paquets

Cela ne concerne pas vraiment les systèmes GNU/Linux de prédilection sur ce site, mais parlons un peu de macOS ! Nous n’avions plus de paquet pour ce système d’exploitation depuis GIMP 2.10.0. Certains semblaient même croire que GIMP ne prenait plus en charge ces systèmes (comme je l’ai découvert lorsqu’on m’a interviewé sur le podcast Late Night Linux). Ce n’est pas le cas ! GIMP compile encore bien pour macOS, et d’ailleurs plusieurs personnes fournissaient déjà un paquet tiers.

La raison pour laquelle nous n’en avions pas était simplement l’absence de nos contributeurs macOS habituels (et le faible nombre de ceux‐ci, puisque c’était plus ou moins un nombre unitaire !).
Heureusement, un nouveau contributeur a fait son apparition et, contrairement aux autres propositions, il s’agit de quelqu’un qui accepte de travailler en équipe (ceci étant un problème, car comme je le disais, d’autres font déjà des paquets tiers, mais peu sont ceux qui essaient de s’adapter au travail en équipe).

Je profite de cette nouvelle pour rappeler que GIMP pour Windows et macOS n’a quasiment aucun contributeur ! Si — malgré le fait que nous soyons sur LinuxFr.org — vous souhaitez voir GIMP s’améliorer sur ces plates‐formes, nous apprécierions vraiment que les intéressés contribuent du code.

Nous rappelons qu’aucun des contributeurs récurrents actuels n’utilise ces systèmes d’exploitation, et si nous corrigeons parfois des bogues pour lesdites plates‐formes, ce n’est que par gentillesse ou parfois par ennui. Par exemple, je suis celui qui a finalement pris de mon temps pour implémenter le chargement asynchrone des polices au démarrage (puis Ell a pris la relève et a énormément amélioré au‐dessus de mon travail), alors même que je n’ai jamais vécu ce problème moi‐même ! Cela restait pourtant un des plus vieux sujets de plainte pour Windows (et même macOS dans une moindre mesure) avec probablement des dizaines de rapports, et ce depuis des années (peut‐être depuis toujours). C’était cependant assez simple à implémenter ; pourtant à part des plaintes, personne n’a jamais essayé de corriger. Je trouve cela triste. Des bogues simples (mais clairement très embêtants, voire bloquants !) comme cela, il y en a des dizaines dans GIMP sur ces systèmes propriétaires. Il serait extrêmement facile pour un programmeur avec un minimum d’expérience de rendre GIMP plus agréable dessus. À bon entendeur !

Activité florissante et retour d’expérience des gens !

L’activité de GIMP est vraiment saine et prospère, avec en moyenne (depuis la dernière version GIMP 2.10.2) : 22 commits par jour sur la branche principale (master) de développement et 7 commits par jour sur la branche gimp-2-10 (série GIMP 2.10.x, qui reçoit toutes les corrections de bogues et des fonctionnalités diverses en rétro‐portage).

De manière intéressante, nous avons des retours (sur les réseaux sociaux) de gens qui croient en un renouveau de GIMP. Or, cela fait des années que l’activité de développement est si intense (ce n’était cependant pas le cas, effectivement, il y a six ans, quand j’ai commencé à contribuer) ! Clairement, la sortie de GIMP 2.10, mais surtout les sorties successives avec notre nouvelle politique de fonctionnalités, font des merveilles. :-)

Une autre conséquence agréable que j’ai remarquée est l’attitude positive des gens. Pendant des années, on recevait énormément de critiques très virulentes et mauvaises. Et je dois dire que personnellement ce fut très dur de faire face à la méchanceté de certains. Ce n’est pas étonnant que la dépression guette beaucoup de développeurs de logiciels libres. Il m’est arrivé à plusieurs reprises de ne plus avoir la force de contribuer pendant plusieurs jours (et de me poser des questions sur pourquoi je faisais du Libre) après trop d’insultes reçues.
Dorénavant je remarque que la tendance s’est inversée. Je vois moins de remarques méchantes (ou peut‐être sont‐elles dorénavant totalement noyées derrière les louanges !) et beaucoup de gens qui nous remercient.

Cela devient à nouveau agréable de contribuer au logiciel libre et nous met de bonne humeur ! :-)

Retour de « gimp-data-extras » et « Alpha-to-Logo »

GIMP est déjà livré par défaut avec énormément de greffons, brosses, scripts et autres données. Parfois, il nous arrive d’en supprimer certains car nous estimons leur qualité insuffisante, ou bien parce qu’ils dupliquent une fonction faite par un autre script plus moderne, etc.

Néanmoins, nous sommes conscients que certaines personnes souhaitent continuer à utiliser telle ou telle donnée pour une raison ou une autre (ne serait‐ce que pour garder exactement le même rendu d’une utilisation à l’autre ou pour la compatibilité de vieux scripts, etc.). C’était par exemple le cas du vieux script Alpha-to-Logo qui avait été retiré de GIMP 2.10 à cause de sa qualité médiocre. Or, il avait clairement son public puisqu’il nous a été beaucoup demandé depuis. Plutôt que réintégrer un script dont nous ne sommes pas satisfait, ce script fait donc son retour dans le paquet gimp-data-extras 2.0.4, que vous pouvez télécharger.

Le futur de GIMP et notre financement participatif

Le développement de GIMP bat vraiment son plein et nous annonçons régulièrement les nouveautés ou améliorations à venir sur les réseaux sociaux (par exemple ZeMarmot ou GIMP sur Twitter ; oui je sais, ce n’est pas du réseau libre !).

Entre la prise en charge des calques de texte vertical, divers filtres de plus en plus évolués, des améliorations conséquentes de réactivité de GIMP (plus de calculs asynchrones, du MIP mapping, des discussions sur du cache plus intelligent de rendu, etc.) et bien plus, on est extrêmement heureux à l’association LILA, studio d’animation à but non lucratif qui produit le film libre ZeMarmot, d’être partie intégrante, et même moteur, de ce renouveau.
Pour que cela puisse continuer, notre association finance ce projet collaborativement. Voici un petit aperçu de nos projets à moyen terme :

Financement collaboratif de la gestion des extensions dans GIMP

Récemment, nous avons un peu fait la promotion de mon développement en cours pour de la gestion avancée d’extension : chercher, installer, mettre à jour et désinstaller des extensions de développeurs tiers en quelques clics.

Rien de révolutionnaire techniquement, on connaît tous cela, par exemple, dans tout navigateur Web moderne ou beaucoup d’autres logiciels. GIMP, de son côté, avait des extensions mais aucun serveur de dépôt pour développeurs tiers, ni aucun système de gestion. Je travaille à changer cela. Cela pourra faire son apparition, si possible, dès une sortie de GIMP 2.10.x.

Vous pouvez lire mon article détaillé pour en savoir plus.

GIMP pour l’animation

Bien sûr, je continue à travailler sur notre greffon d’animation, même si malheureusement le temps a énormément manqué ces derniers mois.

Mais pour l’animation, il n’y a pas que cela qui nous pose problème. Améliorer GIMP avec des fichiers très gros, de dizaines voire centaines de calques est un enjeu important pour nous. Les rendus doivent aussi être le plus rapide possible pour un travail efficace. Permettre la multi‐sélection de calques pour une gestion efficace de fichiers complexes est aussi un projet sur lequel je travaille.

Et ainsi de suite. Ce que nous développons dans GIMP est en fait bien moins spécifique que ce que certains semblent penser, et est extrêmement utile, voire primordial, pour la plupart des professionnels ou amateurs éclairés.

GIMP 3 : un nouveau monde

En parallèle, je travaille beaucoup sur GIMP 3, dont les possibilités sont excitantes. Déjà, je suis celui qui travaille sur la prise en charge des écrans haute densité (j’étais déjà celui qui avait apporté une prise en charge « minimale » dans GIMP 2.10, même s’il faut bien comprendre que celle‐ci n’est qu’une succession de bidouilles, puisque GTK+ 2 n’a pas de prise en charge native).

Je travaille aussi sur l’amélioration de la peinture numérique, une meilleure prise en charge des tablettes graphiques et de certaines de leurs fonctionnalités plus avancées, ainsi que de meilleures configurations par défaut.

Je prévois aussi de travailler sur la prise en charge du « toucher » dans GIMP, par exemple pour la rotation du canevas, le zoom ou le panning avec la gestuelle.

Du code maintenu

J’ai une liste de choses que je souhaite faire si grande que je ne vais pas continuer à vous la lister. Mais, surtout, ce que nous apportons est la professionnalisation de GIMP. Nous avons commencé à contribuer car il était instable et inadéquat pour du travail professionnel. De nos jours, il est extrêmement stable et adéquat. Nous l’utilisons donc maintenant quotidiennement dans un contexte professionnel et surtout nous le maintenons. Ce n’est pas du lâcher de fonctionnalité pour ensuite laisser des bénévoles avec peu de temps gérer les bogues et les plantages. À l’inverse même, la maintenance, la correction de bogues, la gestion des tickets et les revues de code me prennent plus de temps que le développement de nouveau code.

En fait, mon rêve à moyen terme serait que notre financement puisse grandir suffisamment pour engager davantage d’artistes ainsi que d’autres développeurs (pour non seulement travailler sur GIMP, mais aussi Blender, Inkscape, KDEnlive, Synfig, ou qu’importe le logiciel libre que nous utilisions à un moment donné).

Vous souhaitez financer notre travail pour améliorer le logiciel libre en créant des films libres ? Nous vous attendons sur ces plates‐formes :

  • Tipeee, pour financer en euros ;
  • Patreon, pour financer en dollars des États‐Unis.

Alternativement, notre page de donation indique comment donner sur Paypal, ou par donation en virement bancaire à l’association LILA (en revanche, Liberapay est en pause et il vaut donc mieux l’éviter pour le moment, même s’il est toujours dans la liste).

Merci !

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

20 ans de LinuxFr.org : entretiens avec les visiteurs (5)

1 août, 2018 - 10:53

Le 28 juin 2018, le site LinuxFr.org fêtait ses vingt ans. L’équipe du site a réalisé des entretiens par courriel avec des visiteurs (et contributeurs) réguliers du site. Les réponses sont publiées par lot de cinq répondants et, dans ce nouveau lot (reynum, M4rotte, devnewton, serge-ss-paille et vejmarie), les répondants sont interviewés pour la première fois.

Les questions de chaque entretien sont les suivantes :

  • Quand et comment avez‐vous connu LinuxFr.org ?
  • Quelle est votre utilisation du site, en termes de fréquence, de méthode de consultation (navigateur, flux Atom/RSS, mobile, etc.) ? Quels sont les contenus (dépêches, journaux, sondages, forums, wiki, liens) que vous lisez ? Ceux que vous préférez ?
  • Quel est votre meilleur souvenir sur LinuxFr.org (avec un lien, si possible) ? Pensez‐vous que c’était mieux avant ?
  • Qu’aimeriez‐vous trouver sur LinuxFr.org qui n’y figure pas ? Quel type de contenu ou de fonctionnalités rêveriez‐vous de voir arriver ?
  • Contribuez‐vous à des projets libres, et si oui, lesquels ?
  • Si vous deviez mettre un coup de projecteur sur un ou plusieurs projets libres, lesquels citeriez‐vous ?
  • À votre avis, à quoi ressemblera LinuxFr.org dans vingt ans ? Le Libre dans vingt ans ?
  • Quel serait l’environnement / la configuration de vos rêves ?
  • Autre chose à rajouter ?

Quand et comment avez‐vous connu LinuxFr.org ?

reynum (compte créé en 2010) : Je ne sais plus quand exactement j’ai découvert LinuxFr.org ; je crois que le nom était DLFP mais, en tout cas, j’ai commencé à y aller régulièrement vers 2010 en lisant les dépêches noyau de patrick_g<.

M4rotte (compte créé en 2002) : Comment, ça je ne m’en rappelle plus, peut‐être via un moteur de recherche… Premier journal fin 2002 : quinze ans plus tard, je travaille dans une entreprise qui utilise une majorité de logiciels libres.

devnewton (compte créé en 2010) : J’ai connu LinuxFr.org au début des années 2000, je cherchais de l’aide pour installer je ne sais plus quelle distribution, peut‐être Debian ou Slackware je ne me souviens plus.
À l’époque je n’avais pas de connexion Internet à la maison, je téléchargeais les articles depuis un poste de mon école pour pouvoir les lire le soir. Je privilégiais les sites avec peu d’images et beaucoup de texte pour que ça tienne sur une disquette !
J’ai mis environ dix ans avant d’arrêter le mode lecture seule, créer un compte et publier mon premier nourjal pour annoncer la démo de Newton Adventure.

serge-ss-paille (compte créé en 2008) : Aucune idée ! Premier journal posté il y a six ans, ça c’est sûr, donc… avant ? Probablement lors de ma découverte tardive de GNU/Linux, en école d’ingé, grâce à un sympathique membre du Resel.

vejmarie (compte créé en 2009) : Oula, bonne question. Il y a probablement longtemps, j’utilise GNU/Linux depuis 1996, je dirais (oups, me voilà vieux), et suis son actualité sur divers sites, dont LinuxFr.org !

Quelle est votre utilisation du site, en termes de fréquence, de méthode de consultation (navigateur, flux Atom/RSS, mobile, etc.) ? Quels sont les contenus (dépêches, journaux, sondages, forums, wiki, liens) que vous lisez ? Ceux que vous préférez ?

reynum : Dans toutes mes sessions Firefox sur les différents ordis que j’utilise j’ai au moins un onglet « journaux » et un « dépêches », j’y vais quasi quotidiennement en semaine, c’est ma veille techno en somme. À une époque, je le lisais par RSS, mais être privé des commentaires qui sont souvent très intéressants (parfois même plus que le contenu) m’a fait revenir sur le site.

M4rotte : Les journaux et les forums. Je lis les dépêches, mais j’y commente moins, je ne souhaite pas forcément y mettre des commentaires peu pertinents ou hors sujet, vu que c’est la partie la plus visible du site, la vitrine en quelque sorte. Dans les journaux je peux me permettre d’être plus libre et, disons‐le, de dire des conneries parfois.

devnewton : J’utilise tous les jours l’incubateur d’excellence de LinuxFr.org via mon coincoin jb3 pour suivre l’actualité ou demander l’aide des méta‐experts. Je regarde aussi les journaux, les dépêches et depuis peu les liens quotidiennement. Je participe aux sondages de temps en temps. Je contribue un tout petit peu au wiki sur tout ce qui touche à la moulosphère. Je n’utilise presque jamais les forums.
La tribune est vraiment ma section préférée : je trouve l’expression le site à côté de la tribune plus pertinente que jamais.

serge-ss-paille : J’ai tenté un temps le flux RSS, mais j’aime venir picorer en manuel. Donc, dès qu’il y a une petite envie de moule, hop, je sais que sur LinuxFr.org la marée est souvent basse. Je lis principalement les journaux, il y règne une bonne humeur potache et le niveau technique est chouette. Celui des blagues aussi d’ailleurs. Je dirais : journaux > dépêches > liens > forums.

vejmarie : Je suis assez occupé, nous dirons (chef d’entreprise, c’est assez chronophage), je dirais que je visite le site une fois par mois, en consultant principalement les journaux via navigateur. Je ne participe que très très rarement aux commentaires, mais apprécie lire leur contenu et le partage d’opinion qui en découlent. Je voyage beaucoup et il m’arrive de « grabber » le site avant un long vol…

Quel est votre meilleur souvenir sur LinuxFr.org (avec un lien, si possible) ? Pensez‐vous que c’était mieux avant ?

reynum : Je n’ai pas de particulièrement bon souvenir si ce n’est mon premier journal bien noté et ma récente première dépêche (qui m’a valu un cadeau).
Je ne sais pas si c’était mieux avant car, sur LinuxFr.org, « c’était mieux à vent ».

M4rotte : Pas de souvenir de ce genre, mais LinuxFr.org c’est toujours aussi bien.

devnewton : Mes meilleurs souvenirs datent de la période où je développais Newton Adventure : je faisais des journaux voire des dépêches régulièrement pour avoir des retours. Les échanges, même trollesques, étaient toujours intéressants.
Je ne trouve pas que c’était mieux avant : la refonte en Ruby a fait du bien au site et il y a toujours ce mélange de techniques, de cinéma, de recettes de cuisine et de nécrologies qui est l’âme du site. Le plus important est que le meilleur est à venir. Grâce à IPOT, je sais que j’aurai d’excellents souvenirs de la refonte en Java, de la sortie de gcoincoin et de la mort de Charles Bronson.

serge-ss-paille : Je suis plutôt jeune sur le site, je ne tiens pas de calendrier de l’Avent. Meilleurs moments : le concours de jeux de mots informatiques, j’étais tout fou ! Dans un autre registre, quand j’ai vu mon thème beamer pacman (celui du premier journal) utilisé dans une conf. Je me suis dit, ah oui, c’est ça LinuxFr.org, une communauté de joyeux drilles dispersée dans la francophonie.

vejmarie : Même opinion que M4rotte : LinuxFr.org, c’est toujours super !

Qu’aimeriez‐vous trouver sur LinuxFr.org qui n’y figure pas ? Quel type de contenu ou de fonctionnalités rêveriez‐vous de voir arriver ?

reynum : Souvent je me dis qu’une section dédiée tutoriels (pas le wiki que je trouve peu adapté) serait un plus, compte tenu de la forte technicité de nombreux lecteurs et contributeurs. L’hébergement local des images serait pas mal, cela éviterait qu’elles soient supprimées des sites sur lesquels on les dépose, créant du coup des pages amputées d’une partie de leur contenu.

(pas de réponse de M4rotte à cette question)

devnewton : J’aimerais lire plus de contenu dédié aux arts numériques sur LinuxFr.org : graphisme 2D/3D, musique assistée par ordinateur, montage vidéo… Pas seulement sur les logiciels, mais aussi sur les techniques ou les projets d’art libre, peut‐être en lien avec OpenGameArt.org ?

serge-ss-paille : J’aime bien les journaux techniques, je suis sûr que plus de gens pourraient se lancer et partager leurs découvertes et leurs expériences.

(pas de réponse de vejmarie à cette question)

Contribuez‐vous à des projets libres, et si oui, lesquels ?

(pas de réponse de reynum à cette question)

M4rotte : Non, plus depuis un moment. Mais les quelques scripts que je développe dans le cadre de mon travail, ainsi que mes « bricolages à visée didactique » (quelques projets personnels encore au stade alpha) sont libres.

devnewton : Oui, les miens. :-)

serge-ss-paille : Principalement aux miens, et des rapports de bogues, parfois avec un correctif, de temps en temps. Au taf, j’ai la chance de pouvoir contribuer à LLVM.

vejmarie : Principalement FreeCAD et LinuxBoot.

Si vous deviez mettre un coup de projecteur sur un ou plusieurs projets libres, lesquels citeriez‐vous ?

(pas de réponse de reynum à cette question)

(pas de réponse de M4rotte à cette question)

devnewton : Ça n’est pas très gentil, ça doit faire mal ! Quoi qu’un bon coup sur la Mofo serait utile pour lui rappeler que si Firefox est formidable, il ne faut pas le pourrir avec des DRM et des publicités.
Plus sérieusement, celui qui mérite de l’attention, c’est Delta Chat : l’idée de faire une messagerie instantanée réellement interopérable en se basant sur le courriel, même si techniquement c’est moins propre qu’un nouveau protocole, permettrait d’avoir tout le monde et pas seulement un énième sous‐sous‐sous‐ensemble des gens. Vivement une implémentation dans Roundcube ou Thunderbird !

serge-ss-paille : (la blague de devnewton m’a fait rire) Pour les amateurs de combinaison moulante, je suis fan du peu connu latex-make. Et pour la vie de tous les jours, deux projets pas ultra révolutionnaires ni particulièrement récents mais qui font juste le taf et bien leur taf : pal et devtodo.

vejmarie : Aussi bizarre que cela puisse paraître je prendrais le projet Open Compute, même si ce n’est pas un projet logiciel, l’Open Hardware est le parfait complément des logiciels libres qui peuvent lui apporter beaucoup.

À votre avis, à quoi ressemblera LinuxFr.org dans vingt ans ? Le Libre dans vingt ans ?

(pas de réponse de reynum à cette question)

(pas de réponse de M4rotte à cette question)

devnewton : Dans vingt ans LinuxFr.org sera un site de rencontres alternatif, suite au rachat par Microsoft. Ce dernier aura aussi profondément changé le Libre en releasant Windows sous GPL et en adoptant GNOME 3 comme GUI.

serge-ss-paille : Dans vingt ans j’aurai la peau toute fripée et LinuxFr.org sera toujours consultable depuis lynx, c’est beau. Et comme beaucoup de belles idées, le Libre se sera professionnalisé pour devenir une industrie. Mais l’esprit du Libre vivra dans des petits groupes dont LinuxFr.org fera partie. :-)

vejmarie : Ouh là, dans 20 ans j’espère être à la retraite et pourquoi pas être un gros contributeur au site. Le Libre va perdurer et probablement rentrer dans des domaines insoupçonnés avec une bonne association avec du hardwarematériel.

Quel serait l’environnement / la configuration de vos rêves ?

(pas de réponse de reynum à cette question)

(pas de réponse de M4rotte à cette question)

devnewton : XFCE / un PC, un clavier, une souris.

serge-ss-paille : Un croisement entre Enlightenment et awesome. Ce serait éblouissant et génial.

(pas de réponse de vejmarie à cette question)

Autre chose à rajouter ?

devnewton : 

serge-ss-paille :

v = i = e = lambda coin : coin @v @i @v @e def LinuxFr(): return 'Eviv gro.rFxuniL' Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

De la lecture offerte par le groupe Transcriptions de l’April pour vos vacances

31 juillet, 2018 - 15:03

Le groupe Transcriptions de l’association April s’est fixé comme mission de transformer en version texte des enregistrements audio et vidéo concernant le logiciel libre et les libertés numériques en général.

La version texte de ces fichiers audio et vidéo permet :

  • d’augmenter leur indexation sur les moteurs de recherche ;
  • d’améliorer leur accessibilité aux personnes porteuses de handicaps ;
  • de retrouver les propos exacts des intervenants, les utiliser sans trahir leur pensée, en citant fidèlement la source ;
  • enfin, de permettre à chacun et chacune de « lire » ces conférences, émissions de radio, etc.

Pour cette période de vacances ce sont environ 40 heures d’enregistrements divers qui ont été transcrites et publiées depuis le mois de janvier 2018, qui vous sont offertes et qui, nous le souhaitons, feront partie de vos lectures d’été.

Et puis, n’hésitez pas à rejoindre notre groupe et à participer !

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Revue de presse de l’April pour la semaine 30 de l’année 2018

31 juillet, 2018 - 09:36

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

[ZDNet France] De Linux à Windows : une partie de l’Allemagne bascule
Par David Meyer, le jeudi 26 juillet 2018. Extrait :

« Après être passé en 2006 de Solaris à [GNU/]Linux, le land allemand de Basse‐Saxe veut à présent migrer 13 000 postes de travail d’OpenSuse vers Windows, vraisemblablement Windows 10. Justification avancée : la standardisation des OS. »

Et aussi :

[Next INpact] Le gouvernement lance des « états généraux des nouvelles régulations numériques »
Par Xavier Berne, le jeudi 26 juillet 2018. Extrait :

« Le gouvernement vient d’annoncer le lancement d’une série de consultations destinées à mûrir la position de la France en matière de régulation du Numérique (sous les angles économiques, sociétaux, etc.). Ces “états généraux” sont censés aboutir “début 2019”. »

[Podcast Journal] Contre le monopole des GAFAM, le logiciel libre
Par la rédaction, le mardi 24 juillet 2018. Extrait :

« Google, Apple, Facebook, Amazon, Microsoft sont souvent épinglés pour leur utilisation de nos données personnelles ou encore sur les bénéfices énormes qu’ils font dans les pays sans y reverser d’impôts. Difficile pourtant de lutter contre leur omniprésence sur le Web et dans le monde de l’informatique. L’utilisation de logiciels libres apparaît peu à peu comme leur meilleure alternative. »

[ZDNet France] LibreOffice sur le Microsoft Store : The Document Foundation dénonce
Par la rédaction, le mardi 24 juillet 2018. Extrait :

« La suite bureautique libre sur la plate‐forme logicielle de Windows 10 ? Pendant quelques jours un tiers à utilisé ce stratagème pour faire payer les internautes. Sans que The Document Foundation n’approuve l’initiative. »

[Developpez.com] Explosion des prix de Google Maps : le département de Maine‐et‐Loire abandonne Google
Par Michael Guilloux, le lundi 23 juillet 2018. Extrait :

« Début mai, Google a annoncé une refonte complète de son offre cartographique à destination des professionnels. Ces changements, qui impliquent de renseigner obligatoirement un code de carte bleue, se traduisent par une explosion des prix pour les usages professionnels avec une réduction drastique du volume d’affichages gratuits autorisés. »

Et aussi :

[ZDNet France] PeerTube : l’hébergement libre de vidéos est sur les rails
Par Thierry Noisette, le lundi 23 juillet 2018. Extrait :

« Soutenu par Framasoft, PeerTube a réussi haut la main son appel à crowdfunding. Cet hébergement de vidéo décentralisé devrait se doter dans quelques mois de fonctionnalités améliorées. »

[Miroir Mag] Six clichés qui vous empêchent de vous mettre au logiciel libre
Par la rédaction, le lundi 23 juillet 2018. Extrait :

« Encore mal connus, les logiciels libres continuent de faire peur aux utilisateurs. Doutes sur la fiabilité, nécessité de compétences techniques, habitude des autres systèmes… Autant de freins à leur généralisation. Pourtant, ces logiciels que chacun est libre d’utiliser, modifier ou partager pourraient amener de nombreux bienfaits, s’ils étaient utilisés de manière globale. »

[zonebourse] Le DevOps – la prise de pouvoir de l’Open Source
Par Jan Gabriel, le lundi 23 juillet 2018. Extrait :

« S’il y a un débat public sur le fait qu’un outil puisse ou ne puisse pas être un “outil DevOps”, nous pouvons néanmoins constater que les thèmes phares du DevOps — Agilité, Automatisation, Collaboration — se recoupent fort bien avec ceux du mouvement Open Source. »

[Libération] Contre Google, cherchez encore
Par Christophe Alix, le dimanche 22 juillet 2018. Extrait :

« Au regard de la surface financière acquise par Google, l’amende que vient de lui infliger l’Union européenne, pour record qu’elle soit, a tout d’une goutte d’eau dans un océan de dollars. Que représentent en effet 4,3 milliards d’euros au regard d’une capitalisation boursière qui dépasse les 700 milliards d’euros et d’une trésorerie qui avoisine les 100 milliards ? »

Et aussi :

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Elixir, Phoenix et Membrane

30 juillet, 2018 - 10:05

Elixir est un langage de programmation dont la version 1.7 vient de sortir. Il est notamment utilisé par deux cadriciels : Phoenix pour le Web et Membrane Framework pour la diffusion multimédia. Ces trois projets sont présentés dans la seconde partie de la dépêche.

Elixir

Elixir est un langage de programmation fonctionnelle et dynamique. Il s’appuie sur la machine virtuelle d’Erlang, avec une syntaxe inspirée de Ruby et pas mal de bonnes idées prises d’autres langages (les docstrings de Python par exemple).

Elixir profite de la machine virtuelle d’Erlang, connue pour ses aspects distribués, sa résistance aux erreurs et sa faible latence. En particulier, il reprend les processus légers (l’équivalent des goroutines de Go) :

current_process = self() # Crée un nouveau processus léger d’Elixir spawn_link(fn -> send current_process, {:msg, "Hello world!"} end) # Attend jusqu’à la réception d’un message receive do {:msg, contents} -> IO.puts contents end

Un autre point fort d’Elixir est son outillage, avec notamment mix, l’outil de construction, hex, le gestionnaire de paquets, et iex, la console interactive. ExUnit, le cadriciel de test, profite des macros d’Elixir, qui permettent d’écrire des DSL, pour avoir des tests concis avec des rapports d’erreur compréhensibles :

defmodule SampleTest do use ExUnit.Case, async: true test "test the truth" do assert "fox jumps over the lazy dog" == "brown fox jumps over the dog" end end

Phoenix

Phoenix est un cadriciel Web, l’équivalent de Ruby on Rails pour Elixir. Par rapport à Rails, il a abandonné le côté magique tout en ayant quand même réussi à garder le sentiment de productivité que l’on peut avoir en développant avec. En particulier, Ecto, la bibliothèque de persistance des données, est souvent vue comme plus solide qu’ActiveRecord. Enfin, Phoenix bénéficie d’Elixir et de la plate‐forme Erlang : ses temps de réponse pour des pages avec peu d’interactions avec la base de données sont généralement sous la milliseconde, là où on est plutôt à quelques dizaines de millisecondes avec Rails.

Membrane Framework

Membrane Framework sert à construire des applications côté serveur pour les flux multimédias. Il met l’accent sur la fiabilité et la concurrence, et ce n’est donc pas très étonnant qu’il soit développé en Elixir (avec un peu de C, toutefois).

Membrane Framework se compare à GStreamer. D’après les dires de leurs développeurs, ils ne cherchent pas à couvrir tous les cas et formats que GStreamer peut couvrir et préfèrent se concentrer sur la qualité.

N. D. A. : J’ai déjà utilisé un peu Elixir et Phoenix, mais je ne fais que relayer des informations lues sur le site officiel de Membrane Framework car le projet me semble intéressant. Si des lecteurs ont un avis plus éclairé, je les encourage à le faire partager dans les commentaires.

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Agenda du Libre pour la semaine 31 de l’année 2018

28 juillet, 2018 - 20:09

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

Sommaire [FR Le Rest] Summ(ak)ercamp - Du lundi 16 juillet 2018 à 08h00 au dimanche 5 août 2018 à 18h00.

Le Summ(ak)rCamp 2018 est une rencontre de hackers, makers, codeurs, bio-hackers, biologistes, transitionneurs, agriculteurs, designers, ferronnier, forgeron à l'Atelier Z dans le hameau de Kervic sur la commune de Névez dans le Finistère du sud.

Il se déroule du 16 juillet au 5 aout 2018 et fait suite à l'Indie Camp 2017 organisé dans le même lieu.

Cette rencontre se fait sur le format d'un Summer Camp : un Tiers-Lieux éphémère où chacun est libre de se reposer ou travailler selon ses envies et son rythme.

L'échange et la transmission de compétences, de savoirs, et de méthodologies est au cœur du processus. Il s'agit d'apprendre ensemble.

L'évènement Facebook : https://www.facebook.com/events/1823215014391834/ .

Le pad d'inscription : https://bimestriel.framapad.org/p/SC2018 .

La page movilab http://movilab.org/index.php?title=Summ%28ak%29ercamp\_2018

[FR Toulouse] Rencontres Tetalab - Le mercredi 1 août 2018 de 20h30 à 23h30.

Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

Ouvert au public tous les mercredi soir.

Venez nombreux.

[FR Poitiers] Jeudi du Libre - Le jeudi 2 août 2018 de 17h30 à 20h30.

Chaque premier jeudi du mois, les membres de l’APP3L se réunissent au Centre Régional d’Information Jeunesse (CRIJ).

Ils vous invitent à les rejoindre, de 17h30 à 20h30, afin d’échanger et d’en apprendre plus à propos des logiciels libres.

Si vous le désirez, vous pouvez venir avec votre ordinateur portable ou fixe (nous prêterons écrans, claviers et souris).

Cette permanence est l’occasion pour chacun de

  • rencontrer d'autres utilisateurs
  • de discuter ou de s’informer
  • de trouver de l’aide (vous pouvez amener votre machine);
  • ou tout simplement de découvrir des alternatives aux logiciels et services privateurs.

Vous pourrez aussi échanger et vous faire aider dans votre contribution aux communs numériques (Wikipédia, OpenStreetMap), la protection de votre vie privée et les services en ligne respectueux de votre intimité.

Entrée Libre. Tout Public.

Accès 64 rue Léon Gambetta 86000 Poitiers

[FR Caen] Le First-jeudi Échange dînatoire canneais - Le jeudi 2 août 2018 de 19h00 à 21h00.

Tous les premiers jeudis du mois, les membres (et non-membres sont également les bienvenues) se rencontrent pour discuter de l'univers des logiciels libres, tout en dînant (ou juste pour prendre un café). [N.B. le repas n'est pas offert].

Dans un esprit totalement libre, les sujets vont et viennent en fonction de chacun.

Venez nombreux.

[BE Liège] Linux Meeting Party - Le jeudi 2 août 2018 de 19h30 à 22h30.

Notre "Linux Meeting Party" (table de conversation informelle) a lieu tous les.

Elle se tiendra comme d'habitude dans la salle du rez-de-chaussée de la "Fédé ULg", 24 Place du XX Août, à Liège. Cela se trouve en face de l'Université de Liège, à hauteur de l'arrêt de bus carte interactive d'accès.

Venez quand vous voulez entre 19h30 et 22h30 papoter Linux et Logiciels Libres dans la bonne humeur.
Un projecteur est normalement disponible mais l'accès WiFi est incertain.

[FR Paris] Soirée de Contribution au Libre - Le jeudi 2 août 2018 de 19h30 à 22h30.

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

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

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

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

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

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

Regazouillez sur Twitter - Wiki des soirées

Programme non exhaustif

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

tout nouveau projet est le bienvenu.

[FR Paris] Premier Samedi du Libre - Le samedi 4 août 2018 de 14h00 à 18h00.

Chaque premier samedi de chaque mois, de 14h00 à 18h00, des bénévoles passionnés de logiciels libres se retrouvent au Carrefour Numérique² de la Cité des Sciences, pour une install-party de distributions ou, ainsi que des ateliers et (parfois) des conférences.

Venez aider ou vous faire aider à installer et paramétrer des logiciels libres et toute distribution GNU/Linux ou Android avec les associations d'utilisateurs de Fedora, Mageia, Ubuntu, Debian, Trisquel… (pour GNU/Linux) ; Replicant, LineageOS, f-droid (pour Android), sur netbook, portable, tour, PC/Mac (pour GNU/Linux), smartphone ou tablette (pour Android), éventuellement à côté de votre système actuel (pour GNU/Linux).

N'hésitez pas non plus à passer si vous rencontrez des difficultés avec des périphériques, matériels, logiciels libres sous ou Android.

  • 12h30-13h45 déjeuner à la pizzeria Le Verona, 25 avenue Corentin Cariou
  • 14h00-18h00 salle Classe Numérique install party GNU/Linux et Android, toutes distros
  • 14h00-18h00 salle Atelier atelier Blender3D du BUG (Blender3D Users Group)
  • 14h00-18h00 salle LivingLab atelier Brique Internet/auto-hébergement avec franciliens.net + atelier accessibilité avec des membres de Liberté 0
  • 14h00-18h00 salle Studio wikipermanence de l'association Wikimedia
  • et après 18h,  on continue à échanger et discuter (généralement dans un bar avenue Corentin Cariou)

Pour les salles, voir le plan du Carrefour Numérique.

Nous avons besoin de volontaires pour l'accueil et les installations. Il est utile, mais pas obligatoire, de vous inscrire comme parrainé, parrain, ou visiteur sur le site premier-samedi.org en décrivant votre matériel et vos attentes.

Parrainé·e·s

  • Pour l'installation d'une distribution :

    • venez de préférence dès le début (vers 14h-14h30)
    • sauvegardez sur disque externe, clé usb ou DVD vos fichiers importants
    • supprimez les fichiers et logiciels superflus
    • faites un nettoyage de disque et une défragmentation (utilitaires Windows)
    • n'oubliez pas votre chargeur, vos câbles etc.
    • prenez connaissance de la présentation, du code de conduite, du document présentant les liens et infos utiles et de la décharge
    • apportez un disque dur externe ou une clé usb ou un dvd

  • Pour l'installation d'une distribution Android

    • venez de préférence dès le début (vers 14h-14h30)
    • sauvegardez les données des applications (SMS, contacts, etc) car elles seront effacées durant l'installation, et si possible les fichiers/dossiers personnels (musique, films, pdf, etc) afin de ne pas risquer de les perdre en cas d'erreur technique
    • Si possible, essayez de vérifier s'il y a des distributions compatibles avec votre appareil
    • https://wiki.lineageos.org/devices/: liste des appareils compatibles avec LineageOS
    • https://redmine.replicant.us/projects/replicant/wiki/ReplicantStatus#Replicant-60: liste des appareils compatibles avec Replicant, ainsi que la liste des fonctionnalités (GPS, camera, etc) prises en charge

  • Dans tous les cas:

    • demandez l'autorisation de prendre des photos si vous souhaitez en prendre
    • n'oubliez pas que nous sommes des bénévoles, pas un S.A.V.  ;-)

Parrains et marraines

  • ISOs de nombreuses distros installables par serveur local Parinux et Raspberry-Pi 3
  • apportez une clé usb 3 ou un dvd, des ISOs, de vos distros favorites
  • demandez si l'installé·e a bien sauvegardé ses fichiers
  • demandez si l'installé·e a bien nettoyé, défragmenté, CHKDSKé
  • si possible, autonomisez l'installé-e, expliquez, laissez-lui le clavier
  • prenez connaissance de la présentation, du code de conduite, du document présentant les liens et infos utiles et de la décharge
  • évitez de commencer une installation complète après 16h00
  • préférez une réinstallation propre à une longue mise à jour
  • terminez ce que vous avez commencé ou passez le relais
  • incitez l'installé·e à se rapprocher de l'association dédiée à sa distribution
  • si possible, installez et lancez l'utilitaire Bleachbit.

Entrée libre et gratuite, pour tout public.

Transports

[FR Strasbourg] Libérons nous du pistage - Le samedi 4 août 2018 de 14h00 à 18h00.

Lors de cet atelier, des bénévoles d’Alsace Réseau Neutre et d’autres associations, vous proposent de reprendre le contrôle sur vos données numériques en vous accompagnant dans l’adoption de solutions alternatives à vos usages numériques courants.

Concrètement, il s’agit de vous aider à

  • Configurer votre navigateur pour limiter les données transmises à votre insu
  • Découvrir des services numériques éthiques
  • Installer Linux ou LineageOS (Install Party)
  • Prendre en main une solution d’auto-hébergement qui vous permet d’avoir votre propre cloud de fichier, d’héberger votre site web ou encore vos mails (La brique Internet / YunoHost)

Tout public
Gratuit (dons acceptés)
*Inscriptions , *

[FR Montpellier] Les logiciels libres, parlons-en - Le dimanche 5 août 2018 de 17h00 à 19h00.

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

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

Proposition de programme

  • discussions autour de l’organisation d’événements
  • gestion des groupes de travail
  • propositions diverses
  • présentation de l’asso

Alors, si vous avez un peu de temps le vendredi soir, voici une occupation qui me semble très intéressante.

Montpel’libre est une association et un groupe d’utilisateurs (GULL), qui propose une multitude d’activités dans le cadre de la promotion des logiciels libres, et des Communs.

Depuis longtemps déjà, Montpel’libre participe à l’économie sociale et solidaire en organisant tout un éventail d’ateliers et de manifestations, au développement durable et à l’innovation sociale au travers de permanences et ateliers de présentations des logiciels libres et évidement les cartoparties, véritable actions citoyennes, sur le thème de l’accessibilité des personnes en situation de handicap.

L’activité économique, l’intérêt collectif, le fonctionnement démocratique, autant d’éléments que porte Montpel’libre, en proposant un accès entièrement libre et gratuit à une éducation populaire, au travers de ses ateliers à destination de tous les publics.

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

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

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

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

Le Faubourg - 15, rue du Faubourg de Nîmes, 34000 Montpellier

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Faut‐il continuer à apprendre le C++ ?

27 juillet, 2018 - 13:13

Le C++ est un langage qui a vu ses spécifications s’amonceler et se stratifier au cours des années. Il est encore très utilisé. Mais face à des concurrents comme Rust ou Go, quelle est sa place dans un environnement qui évolue ?

Cette dépêche qui a nécessité beaucoup de discussions, aura, vous le verrez, une forme un peu particulière.

    Sommaire Origine de cette dépêche

    La dépêche C++17, genèse d’une version mineure a reçu 227 commentaires représentant un volume dix fois supérieur à la dépêche elle‐même. Et ces commentaires, très souvent bien écrits, nourrissent des trolls bien velus !

    L’idée de créer cette dépêche vient de deux constats :

    1. l’énergie dépensée et les nombreuses heures consacrées à rédiger ces 227 commentaires est phénoménale ;
    2. en revanche, la lecture de tous ces commentaires est laborieuse.

    Avec le recul, nous aurions pu concentrer tout cet investissement dans une dépêche collaborative du style « Aujourd’hui, est‐il pertinent de choisir le C++ pour une nouvelle application ? », afin de structurer et consolider tous les arguments dispersés au fil des commentaires.

    Objectif de cette dépêche

    Cette dépêche propose un sujet bien plus large : « Faut‐il continuer à apprendre le C++ ? ». Et de nombreux commentaires de qualité de la dépêche C++17, genèse d’une version mineure méritent d’être copiés, améliorés ou fusionnés ici. Malheureusement, ceux‐ci sont rarement sous licence compatible CC-BY-SA 4.0.

    gbdivers proposition

    Faire un article synthétique sur cette question n’est pas simple. En effet, le choix d’un langage pour un projet dépend énormément du contexte, en particulier le domaine d’application et l’environnement technique existant. Dans les discussions sur le choix d’un langage, certains avanceront des critères, mais ceux‐ci seront considérés par d’autres comme non pertinents.

    Même des critères « historiques » du C++ ne sont plus des arguments suffisants dans de nombreux projets. Par exemple, le C++ est souvent évoqué pour ses performances lorsque l’on veut créer un jeu vidéo. Mais de nos jours, avec la puissance disponible sur le moindre appareil et la qualité des moteurs de jeux, il n’est plus pertinent que tous ceux qui veulent travailler dans les jeux vidéo apprennent le C++.

    De même, si l’on prend un domaine dans lequel le C++ est généralement déconseillé, comme le développement Web. Et, cependant, de très grosses entreprises Web comme Google ou Facebook utilisent le C++.

    Il convient donc de revenir dans un premier temps sur les critères à prendre en compte dans le choix d’un langage, puis de voir les qualités et défauts du C++ sur ces critères.

    Dialogue sur divers aspects des enjeux brulants de C++ en 2018

    La normalisation, un processus trop lent ? Et quid de la nouvelle norme ISO vs mise à jour d’un logiciel (compilo, VM, etc.).

    Nicolas Boulay : Vu la base de code existante et vu le nombre de parties prenantes, une prise de décision est forcément lente, vu les enjeux par chacune des parties. De toute façon, ce n’est pas vraiment la rapidité des changements de la norme qui sont impactants, c’est la vitesse de conformité des compilateurs.
    Si c’est lent, les fonctionnalités vont prendre du retard avec les langages comme C#, Rust, etc., surtout s’ils continuent à avancer. Si c’est rapide, il faut accompagner le changement, pour ne pas dérouter les codeurs. Il y a risque de ne pas utiliser les nouveautés par peur d’instabilité, d’immaturité du code, ou de méconnaissance.

    gbdivers : Oui, je suis d’accord. À mon avis, c’est avec ce type d’arguments que l’article sera intéressant. Les lecteurs ne connaissent pas forcément le contexte et les contraintes du C++, donc c’est bien de donner le contexte, puis les avantages et défauts des choix possibles. Libre à eux ensuite de se faire leur propre opinion.

    Anthony J. : Les industriels. Je pense que pour de nombreux industriels utilisant le C++ depuis plus de vingt ans, les besoins de rétrocompatibilité restent très importants.

    gbdivers : Bonne question. Ont‐ils besoin de rétrocompatibilité sur les évolutions du C++, ou ont‐ils simplement besoin de ne pas suivre les évolutions ? On a au moins deux choix possibles : le choix entre suivre les évolutions du langage et mettre à jour son code, ou ne pas mettre à jour son code et ne pas suivre les évolutions du langage. Faut‐il avoir un troisième choix : suivre les évolutions et ne pas mettre à jour son code ? Est‐ce que ce troisième choix est intéressant ou pertinent pour les industriels ? Pour le C++ ?
    Un exemple concret : dans ma boîte, ils ont choisi il y a trois ou quatre ans de mettre à jour le code et de ne plus assurer la rétrocompatibilité. Et, depuis, on est sur le C++11 (il n’est pas prévu que l’on passe au C++14 ou 17 pour le moment). Et l’on garantit la compatibilité du code sur une liste définie de compilateurs et de versions de compilateurs. C’était un choix stratégique à faire entre obliger nos clients à mettre à jour leur code (et donc potentiellement perdre des clients) ou continuer à assurer la compatibilité (avec les coûts de développement que cela implique).

    gbdivers : Standard vs lib ? Pourquoi ne pas mettre toutes les fonctionnalités dans le standard. Exemple de regex, network, Unicode.

    Nicolas Boulay : Une uniformisation serait souhaitable .

    gbdivers : Idem. Quels sont les avantages et défauts d’une uniformisation ? D’une standardisation ? D’une standardisation ISO ? Vaut‐il mieux une fonctionnalité dans le standard ou dans une lib ? Quelles sont les conséquences de l’un ou l’autre choix ?

    Nicolas Boulay : L’uniformisation permet tous les avantages de la standardisation. Si l’on parle de la lib standard, d’un point de vue utilisateur cela ne change rien.

    gbdivers : L’antithèse est que l’uniformisation peut figer (dans le sens péjoratif, c.‐à‐d. bloquer les évolutions futures) une API ou des fonctionnalités. Prenons par exemple le protocole HTTP. Si le standard C++ fournit une API pour cela, il faut que l’API puisse suivre les évolutions. Sinon, s’il y a une mise à jour de HTTP, soit on continue à utiliser l’API pas à jour du C++, soit on utilise une API à jour fournie par une bibliothèque. Dans les deux cas, c’est problématique de fournir une API figée dans le standard. Il faut que l’API soit indépendante de la version du protocole, de façon à ce que les compilateurs puissent fournir des mises à jour du protocole sans que le standard ne change.

    freem : Il y a aussi le problème de la rétro‐compatibilité. Par exemple, admettons que l’on intègre (reproche régulièrement lu et entendu) une section pour créer des IHM graphiques. Ce que le développeur voudra, c’est un truc qui soit stable au niveau UX et intégré dans les systèmes d’exploitation (Windows, macOS, GTK+, Qt…). Vu que celles‐ci évoluent au fil du temps, tant dans leurs API que dans leurs architectures, le risque d’avoir une partie du standard qui soit instable (au niveau API du moins) serait élevé.

    gbdivers : Les nouveaux langages sont‐ils meilleurs que les anciens langages ? De grands débats apparaissent : const vs mutable, ref vs copie, explicit vs implicit.

    Nicolas Boulay : Il ne faut pas oublier l’apport de la recherche dans le domaine : le temps de dev directement lié aux nombres de lignes de code (o(L1.2 ), cf. Cocomo). La liste des bogues les plus fréquents en C et C++ qui sont toujours les mêmes (NULL, off by one, débordement de tampon, allocation et désallocation mémoire, mauvaise gestion d’erreur, etc.), et qui n’existe pas dans les langages plus récents.
    gbdivers :
    L’argument sur les avantages que peut apporter un nouveau langage est à rapprocher du coup au problème de rétro‐compatibilité.
    Je ne connais pas Cocomo.
    freem : Cocomo est une méthode qui consiste à chiffrer le coût d’un projet en fonction de son nombre de lignes de code. C’est, euh, pas très moderne (né en 1970) et, de ce que j’en sais, totalement bancal : en C++, il est possible d’utiliser de l’objet, l’encapsulation est très encouragée par les mécanismes (RAII, move semantic, généricité) et donc, pour contribuer à un code C++ « idéal », le coût peut être très faible malgré un grand nombre de lignes de code, tant que l’on sait dans quelle couche on se situe. Par exemple, pour un bogue de mémoire (erreur de segmentation, débordement de tampon) il est peu pertinent d’attaquer le code haut niveau, qui peut représenter le plus gros (avec plein de règles métier ajoutées au fil du temps). Personnellement, de ce que je sais, la complexité cyclomatique de McCabe, dont j’ai personnellement tirée pas mal de leçons, me semble plus pertinente que le nombre de lignes pour estimer la complexité d’un code (je vous renvoie à l’outil cccc, présent dans toutes les bonnes distros). Le problème des underflows et overflows pourrait être contrecarré en encapsulant les types natifs dans des classes. Le problème, c’est que le coût à l’exécution serait non négligeable. Pour la constance, je rappelle que, par défaut, les paramètres d’une fonction en C++ sont invisibles par l’appelant : passage par copie, sauf si l’on passe une référence. Du coup, on choisit volontairement un type mutable (dont c’est le rôle). Quand on a besoin d’une référence constante, c’est en fait un contournement dû au fait que la copie est lente. Ce qui est, d’ailleurs, bien moins vrai depuis 2011. Ici encore, comme pour les flow errors, il serait possible d’implémenter une solution plus propre à base de pointeurs intelligents (weak_ptr dédié à unique_ptr, qui pourrait interdire l’altération de la variable cible).
    Ici, je dirais que les erreurs les plus communes du « C/C++ » sont dues au fait que, en C++, on a tendance à programmer comme en C, comme le montre si bien la fusion de tant de gens : « C/C++ »…

    gbdivers : Peut‐on envisager de casser la rétrocompatibilité ? L’exemple du Python 2 vs Python 3 montre l’étendue des problèmes que cela implique…

    Nicolas Boulay : À ne surtout pas faire, cela revient à créer un nouveau langage (sauf à être compatible binaire, avec un drapeau dans le fichier, comme hhack de Facebook).
    gbdivers : Idem, prise de position. Si on le fait, il y aura telles conséquences. Si on le fait pas, il y aura telles autres conséquences.
    Nicolas Boulay: Avec un drapeau, vous gardez la rétrocompatibilité, et vous nettoyez en même temps le langage pour le futur. Si vous cassez la compatibilité, vous inventez un nouveau langage, il faut donc convaincre à migrer. Ce qui ne se fera pas. Pour migrer à un nouveau langage, il faut de sacrée bonnes raisons. C++ n-1 sera toujours « good enough » pour beaucoup.
    gbdivers : Pour le drapeau, je sais pas trop. Toujours est‐il que je suis d’accord. Je pense que l’exemple de Python 2 vs Python 3 (et, plus précisément, la lenteur d’adoption de Python 3) est un bon exemple concret que ne pas assurer la rétro‐compatibilité du code peut ralentir l’adoption de la mise à jour.
    freem : Compte tenu de la vitesse d’évolution du C++, si l’on commence à casser la compatibilité, les compétences et le code accumulés entre deux versions seront potentiellement perdus. Le coût de formation pour avoir un développeur C++ compétent est déjà élevé, si en plus il faut le réinvestir régulièrement juste sur une « lubie » du comité, on risque surtout de voir un retour du C, ce qui serait à mon humble avis une terrible régression (le C a bien moins de fonctionnalités, tout en offrant des performances comparables et moins de sécurité).
    Pour parenthèses, l’obsolescence d’auto_ptr a dû être faite dans la douleur et dans le constat que c’était de toute façon peu utilisé (il serait intéressant de « grepper » auto_ptr dans la base de code des paquets Debian, par rapport au nombre de projets écrits en C++, je suis certain que c’est ultra‐minoritaire. Personnellement, je n’ai souvenir que d’un seul projet qui l’ait utilisé, et je ne me souviens même plus du nom…). J’ai un peu plus de doutes sur l’obsolescence des bind1st/2nd qui, bien qu’horribles à utiliser, ne me semblent pas avoir de raisons liées à des bogues.

    gbdivers : Complexe ? Oh oui ! Multiplication des syntaxes, syntaxes pas forcément intuitives.

    Nicolas Boulay : Nécessité d’une vérification des bonnes pratiques.
    gbdivers : C’est un point auquel je n’avais pas pensé et qui serait intéressant d’aborder. Le C++ n’est pas simplement un langage, c’est un écosystème, qui doit être considéré dans son ensemble : compilateurs, bibliothèques, outils de vérifications, bonnes pratiques, apprentissage.
    freem : La compatibilité avec le C est l’un des arguments forts pour pousser le C++ et la prise en charge des syntaxes du C est nécessaire pour cela (je pense surtout aux casts). Ceci dit, les bons compilateurs sont capables de prévenir de ce genre de choses. Il est possible de convertir partiellement en C++ un code C qui, par défaut, n’offre strictement aucun contrôle automatique de la bonne gestion d’une ressource, ce qui réduit les temps et les coûts de migration de C vers C++ de façon drastique. Mais il est vrai qu’il n’existe que trop peu d’outils et de documentations claires (leur étant liés) favorisant la vérification automatique des bonnes pratiques, ou même d’un simple coding style.
    On peut cependant regretter qu’il soit difficile de s’assurer que son code n’utilise pas par erreur une fonctionnalité que l’on a voulu bannir pour différentes raisons (les exceptions, les templates, la RTTI, etc.).

    gbdivers : Passage complexe entre langages.

    freem : Si l’on parle d’utiliser plusieurs langages dans un projet, justement, c’est bien plus simple en C++ qu’en C# ou Java : le langage commun utilisé étant le C, a priori, et le C++ étant compatible avec une grande partie du C, il n’y a pas besoin de définir des points d’entrée comme en Java. J’ai un très mauvais souvenir également de l’usage de C en C#, où il faut concrètement lutter pour que le compilateur accepte de compiler du code « unsafe ».
    En C++, il suffit d’encapsuler la ressource, ce qui est très simple grâce à, je me répète, la RAII.
    En revanche, si l’on parle d’apprendre le C++ en venant d’un autre langage, c’est vrai que ce n’est pas trivial, surtout si l’on veut jouer avec les couches basses.

    gbdivers : L’apprentissage du C++ est réputé difficile…

    lmghs : J’imagine qu’on liste ici les trois niveaux : historique (mémoire à la main, pays magique où les erreurs n’existent pas), 98-RAII (que je continue à appeler moderne, si si), 11-RAII (où l’on introduit les trucs orientés utilisateur et « pythonisants » dès le début : auto, for-range-loop, lambdas pour algorithmes standards…).
    Là, on rejoint la problématique de ce que l’industrie attend. Je suis encore en train de donner une formation cette semaine, et savoir si les formés vont travailler sur une CentOS 6, ou pire 5, plutôt qu’une 7, guide ce que je peux leur enseigner pour répondre à leurs besoins immédiats. Ce qui ne m’empêche pas de faire du teasing en revanche. Dans un cas, je vais parler d’auto_ptr et des boost::ptr_vector, tandis que dans l’autre, vector<unique_ptr<>> me suffit. Même problématique avec les projets en maintenance.
    Il y a aussi la question des publics entre un dev futur informaticien, un gars en embarqué, un scientifique ou des gars en formation interne dans une SSII, les choix et possibilités ne sont pas toujours les mêmes.

    gbdivers : Conclusion : est‐ce que le C++ est fini ? Non !

    gbdivers : En fait, on peut même répondre à cette question (et à la question du titre) dès l’introduction. Pour directement mettre au clair les trolls : est‐ce que quelqu’un pense que le C++ aura disparu dans dix ans ? La réponse est non (même les trolls pourraient difficilement répondre oui a cette question. Même le COBOL est encore utilisé).

    Le C++ en bref

    Le C++ est un vieux langage (bientôt 40 ans) hérité du langage C avec lequel il entretient une compatibilité.

    gbdivers : Compatibilité de syntaxe, mais divergence dans la façon de concevoir les choses. Cela rejoint un des points donnés plus haut : le passage entre plusieurs langages. Quand un dev connaît et utilise plusieurs langages, il ne maîtrise pas les spécificités de chaque concept dans chaque langage (un même concept peut avoir plusieurs interprétations proches, mais pas exactement identique).
    Par exemple, pour le C vs C++, il y a des syntaxes communes, mais la façon de penser un code est complètement différente (gestion des ressources, des erreurs, etc.). Cela a donc un coût de passer d’un langage à un autre.
    Anthony J. : La compatibilité de syntaxe n’est plus possible depuis déjà pas mal de temps : conversion pointeur → void* OK (c/c++) ; mais void* → type* OK(c)/KO(c++), les tableaux de taille dynamique à l’exécution (C99).
    La fonction foo() => foo(…) en C, mais foo(void) en C++.
    Un article sur le sujet ici.
    gbdivers : Je n’ai pas suivi le C11, si ces syntaxes sont encore valides ? A priori, le C++11 (ou 14 ?) est censé se baser sur le C11, donc il est possible que ce ne soit pas compatible avec le C99. Mais, dans ce cas, le C actuel n’est pas non plus compatible avec le C99.
    Du coup, au lieu de dire « il entretient une compatibilité », il faut préciser que la compatibilité syntaxique est limitée et la compatibilité « conceptuelle » diverge complètement.
    freem : La compatibilité est limitée de facto par le fait que le C++ réserve plus de mots que le C. Un code en C peut, par exemple, très bien utiliser this, mais un tel code ne pourra pas compiler en C++ (mot réservé pour désigner l’instance de l’objet dont on appelle la méthode, le cas échéant). Il me semble qu’il existait d’autres points, mais je ne m’en souviens pas.

    De tout ce long historique, le C++ a évolué du mieux possible entre paradigmes de programmation et nouveaux besoins. Au final, sa syntaxe évolue lentement, est complexe, bourrée de subtilités et lente à compiler.

    gbdivers : Aborder le problème de l’enseignement du C++ ? Le C++ est permissif, il y a de multiples syntaxes pour faire la même chose. Beaucoup de cours essaient d’apprendre plusieurs syntaxes — en commençant par les plus obsolètes, en général — sans donner de hiérarchie d’importance à l’apprenant. Résultat : complexité à comprendre et moins bonne maîtrise en profondeur).
    freem : Au sujet de la lenteur de compilation, le problème est‐il vraiment lié au langage, ou à l’implémentation de la STL et du compilateur ? Je me rappelle très bien le jour ou j’ai découvert Clang : la mémoire consommée par une compilation a été divisée par deux et les temps de compilation du projet sur lequel je travaillais par trois. Je n’ai pas fait de tests de vitesse (moins besoin, meilleur matos) entre la STL de GCC et celle de Clang, mais il est clair que ces derniers incluent beaucoup moins de fichiers, l’arborescence et les chaînes d’héritages sont bien moins complexes. J’ai vu au fil des années pas mal de messages sur le Net indiquant que GCC compilait également plus lentement que Visual C++. Alors ce problème de lenteur, ne serait‐il pas dû, au final, à un problème de qualité de GCC (passage à enlever, sauf si publication un trolldi, hi hi) ? Concrètement, GCC utilisait un ramasse‐miettes en C et, il y a quelques années (après ma découverte de Clang en tout cas), on a parlé de réimplémenter certains passages en C++, justement pour réduire la nécessité de ce ramasse‐miettes.

    Mais c’est aussi un langage permettant des optimisations de folie (costless abstraction). Le C++ est utilisé au quotidien, ne serait‐ce que la plupart des environnements graphiques et des navigateurs Web (pour flâner sur LinuxFr.org). Et le C++ continuera pour encore de nombreuses années à être utilisé en production, notamment pour les applications critiques.

    Le C++ n’est pas mourant. Au contraire, le C++ connait un vif intérêt depuis C++11.
    De plus en plus de personnes s’investissent à améliorer davantage ce langage, comme sur la vitesse de compilation qui devrait être grandement améliorée avec C++20.

    Alors, faut‐il tout effacer et recommencer un nouveau langage qui, par design, prend en compte les contraintes de concurrence (multicœur, NUMA) et de montée en charge (scalability) ? Des langages de programmation tentent d’obtenir des performances similaires avec une syntaxe expressive et concise.

    freem : Inventer un nouveau langage from scratch, ne serait‐ce pas un peu comme reprendre un projet from scratch ? On perd l’historique, ce qui peut être bien (plus simple de faire une meilleure architecture) et mal (on perd les correctifs de bogues).

    La puissance du C++

    Les points positifs qui démarquent le C++ sont sa programmation générique et sa méta‐programmation qui permettent d’avoir des abstractions sans pénalité de performance. Mais aussi les possibilités de libération déterministe et implicite de n’importe quel type de ressource au travers du RAII, si on le compare au C — les autres langages à exceptions disposent d’un ramasse‐miettes (garbage collector) et suivent le dispose pattern pour les autres ressources, voire offrent des facilités équivalentes au RAII (try‐with‐resources en Java 7, using en C#, etc.). Certains estiment que si l’on ne profite pas de ces fonctionnalités, mieux vaut utiliser un autre langage.

    freem : Mais justement : les ramasse‐miettes, ça pose des problèmes de performance que la RAII n’a pas. Par exemple, une connexion à une base de données en Java, si l’on ne la ferme pas manuellement, on risque de faire exploser la charge du SGBD tant qu’il ne passe pas pendant trop longtemps. On s’expose aussi à des ralentissements conséquents quand le ramasse‐miettes passe s’il a beaucoup de travail à faire. Choses qui auraient pu être faites à des moments moins critiques. Certaines ressources peuvent aussi se retrouver à manquer si l’on en alloue trop vite pour que le ramasse‐miettes nettoie tout… Bref, le ramasse‐miettes à ses avantages (pas besoin de s’occuper de gérer les choses) mais implique de maîtriser l’outil, sans quoi des problèmes différents arrivent.

    Les alternatives
    • C ;
    • Rust ;
    • Go ;
    • Dart ;
    • Elixir ;
    • Phoenix ;
    • Pony ;
    • D ;
    • OCaml ;
    • Haskell ;
    • Ada ;
    • etc.

    Parmi ces langages, en excluant ceux qui ne sont qu’interprétés et ceux qui utilisent un ramasse‐miettes, les seuls qui pourraient remplacer C++ à performances égales sont donc : C, Rust et D.

    gbdivers : Pourquoi exclure les interprétés et les ramasse‐miettes ? Ça serait l’occasion de tordre le cou a un mauvais argument sur le C++ : les performances. On entend souvent « Je veux faire des jeux vidéo, on m’a dit qu’il fallait les faire en C++ pour les perfs ». Alors qu’en pratique, les perfs ne sont pas critiques pour beaucoup d’applis et que les perfs dépendent aussi beaucoup de l’algorithme et des structures de données. Il vaut mieux n’importe quel langage correctement utilisé que le C++ mal utilisé.

    wilk : Peut‐être préciser ce que l’on entend par performance. Ce n’est pas la même chose au niveau d’une interface graphique, d’un serveur, d’un mobile, etc.
    khivapia : « Il vaut mieux n’importe quel langage correctement utilisé que le C++ mal utilisé » : argument valable pour tous les langages. Pour tirer le maximum de perfs de la machine physique, il ne faut pas de ramasse‐miettes (il n’y en a pas de temps réel et parallèle ; donc, s’il se réveille au milieu du jeu d’action, paf, grosse latence ! ) ni, bien sûr, de langage interprété (perte de perfs liées à la machine virtuelle).
    gbdivers : Je dis que « les performances du C++ ne sont pas forcement un critère pertinent », vous me répondiez « le C++ est plus performant ». OK, mais cela ne change rien à mon argument.

    Pour détailler : écrire du code performant a un coût. Beaucoup n’ont pas le temps et les compétences pour mettre en place les méthodes permettant d’optimiser correctement le code. On peut écrire en C++ un code qui sera plus performant qu’un ramasse‐miettes, mais on peut également écrire pire.
    Un exemple concret : http://0x80.pl/articles/simd-strfind.html. Indéniablement, on peut avoir de meilleures performances si l’on sait tirer le meilleur de la machine. Mais combien sont capables de faire cela ? Et a‐t‐on le temps de faire cela sur un vrai projet ? C’est dans ce sens là que je dis que les performances ne sont pas toujours un bon critère.
    Nicolas Boulay : Pour prendre un exemple, je saurais faire ce genre d’optimisation, mais seul C/C++ me donne accès aux fonctionnalités pour faire le travail. Avec les autres langages, c’est simplement hors de portée, ou beaucoup plus complexe (assembleur ou appels de fonctions externes).
    gbdivers : Oui, mais tu reconnaîtras sans problème, je pense, que tous ceux qui veulent faire du C++ n’ont pas forcement ces compétences ou le temps de faire correctement les choses pour un projet donné (deadlines).
    L’argument « faire du C++ pour les performances » n’est donc pas valide seul. Il faut regarder le contexte du projet, les moyens disponibles, les compétences, etc. C’est un problème que l’on voit souvent sur les forums, où les débutants arrivent et disent « je veux faire un jeu, on m’a conseillé le C++ parce que c’est le plus performant ». Alors qu’en pratique, avec un autre langage, ça ne sera pas moins performant (parce qu’ils ne sont pas capables d’aller chercher les performances du C++).
    freem : Je suis d’accord avec gbdivers (je n’arrête pas de lire gdbivers, grrr) : je ne compte plus les push_back dans un vector dans une boucle de taille définie sans appel à réserver au préalable, et c’est bien moins complexe que le lien donné plus haut (pas encore lu, mais il est probable que je ne sache pas tout faire dedans). Je passerai également sur les vectors multiples de même nombre d’éléments utilisés ensemble (cache miss et appels à malloc inutiles). Et ce sont les bases pour écrire un code rapide en C++.
    Nicolas Boulay : Tous les moteurs de jeux (Unity3D, etc.) sont écrits en C++, en revanche la logique des jeux elle‐même est en JavaScript, en C#, en Lua… En gros, cela demande moins d’efforts de faire propre avec n’importe quoi d’autre que C++, sauf si les performances sont une absolue nécessité.

    Critères pour adopter un nouveau langage

    Mais pour qu’un langage soit adopté plusieurs ingrédients sont nécessaires :

    • un gage de pérennité ;
    • la facilité de débogage (déverminage) ;
    • la facilité d’augmenter un programme ;
    • une communauté, des meet‐ups, des entreprises ;
    • une galaxie de sites Web, d’outils divers, des bibliothèques, des tutoriels, de la documentation, etc. ;
    • des performances raisonnables.

    Sur ce terrain, le C++ est bien doté avec de très nombreux outils, bibliothèques et communautés.

    Popularité du C++

    Et toi, chère lectrice, cher lecteur, penses‐tu que les nouvelles fonctionnalités du C++ ne font que compliquer inutilement le langage le plus complexe que l’humanité ait inventé ?
    Ou, au contraire, es‐tu persuadé·e que, grâce à ces évolutions, le C++ va progresser dans le classement du TIOBE Index et garder loin derrière des prétendants comme D, Dart, Nim, Rust ou Pony ?

    Autres sources :

    lmghs : Autre indicateur : celui d’ohloh qui ne compte pas les recherches sur les moteurs de recherche, mais qui observe l’activité sur les projets FOSS → https://www.openhub.net/languages/compare?language_name%5B%5D=c&language_name%5B%5D=cpp&language_name%5B%5D=python&language_name%5B%5D=java&language_name%5B%5D=rust&language_name%5B%5D=-1&measure=commits.

    Questions
    • Faut‐il considérer le C++ comme langage potentiel au développement d’une nouvelle application ?
    • Est‐il pertinent d’apprendre le C++ aujourd’hui ?
    Go

    Go a été créé par Google parce que la compilation C++ devenait rédhibitoire pour ses applications serveur.

    C++ a été initialement créé comme une extension du C, gardant la compatibilité avec lui, et non un pur langage objet. Il y a donc un mélange entre objets et types primitifs (comme dans java). Toutefois, contrairement à Java ou C#, C++ ne fait pas de différences fondamentales entre les types primitifs et les objets définis par l’utilisateur : c’est au programmeur de décider si les types sont copiables, l’usage des références est explicite, l’allocation sur la pile est possible.

    Certaines briques « de base », telles que les conteneurs ou les string, sont toutefois arrivées tardivement dans la spécification, ou de manière incomplète. Ainsi, beaucoup de bibliothèques réinventent la roue, ce qui peut mener à des difficultés ou un surcoût (conversions multiples) dans l’interopérabilité entre bibliothèques.

    Le compilateur permet de faire de la vraie métaprogrammation. Et c’est réellement utilisé. La métaprogrammation en C++ repose sur un modèle de typage structurel.

    En revanche, il n’y a pratiquement aucune aide à la gestion d’erreurs, bien que C++11 ait introduit static_assert. Les messages d’erreurs liés à la métaprogrammation sont souvent particulièrement cryptiques et demandent un certain degré d’habitude ou d’expertise pour être compris, et un degré encore supérieur pour savoir écrire des bibliothèques fortement génériques provoquant des messages d’erreurs intelligibles. Voir à ce sujet la présentation de Roland Block donnée lors de la CppCon 2015 : Pruning Error Messages From Your C++ Template Code [diapos]. À noter toutefois que les progrès récents du côté des compilateurs, tels que g++ ou Clang++, font que les messages d’erreurs sont un peu moins longs qu’avant.

    La gestion de la mémoire, et des ressources en général, en C++ est laissée à la charge du développeur. Cela a pendant longtemps abouti à la multiplication des problèmes tels que les fuites mémoires ou l’utilisation après libération, qui se manifestent aujourd’hui en autant de failles de sécurité. Toutefois, C++ fournit maintenant des outils intégrés à la bibliothèque standard, qui suivent le principe de RAII (Ressource Acquisition Is Initialization) pour gérer finement l’utilisation des ressources. Ce principe a été repris et généralisé dans le langage Rust (créé par Mozilla), qui veut se poser en alternative, mais reste aujourd’hui inférieur en termes d’écosystème (SIMD, multicœur / OpenMP, toolkit graphique façon Qt).

    D’un autre côté, si C++ trouve un moyen de détecter les vieilles constructions à éviter, que les types somme et le filtrage de type par motif (type pattern matching) est ajouté, que les pointeurs soient vus comme des types somme avec détection des « appels sur NULL » à la compilation, si des conteneurs sont introduits avec des interfaces fold/map/reduce pour réduire les erreurs off‐by‐one lors des parcours, si la compilation est plus rapide (peut‐être avec une gestion multi‐fichier du compilateur), si le modèle mémoire devient plus précis pour gérer les alignements mémoire, l’appartenance des objets en mémoire pour chaque fil d’exécution, et pour un éventuel ramasse‐miettes, C++ est là pour longtemps.

    Les spécifications

    Tiré du commentaire : https://linuxfr.org/news/c-17-genese-d-une-version-mineure#comment-1676200.

    La volonté de compatibilité des différentes versions de la norme pousse le comité de standardisation à ajouter des parties plutôt qu’à les remplacer. Cela pose plusieurs problèmes :

    • il est possible de voir différentes strates d’un mécanisme dans la spec et il n’existe pas vraiment d’outils pour savoir ce qui est bien ou pas ;
    • le maintien des programmes existant peut être compliqué pour se conformer à la nouvelle bonne pratique ;
    • les différentes bibliothèques utilisées ne sont pas forcément toutes homogènes et peuvent contraindre à utiliser toutes les parties de la spec.

    En outre, le comité de normalisation est fermé. Même si le langage est ouvert (son implémentation), les spécifications sont payantes et soumises à des droits. Une aberration qui entraîne parfois des soupçons de corruption ou du moins une volonté d’entretenir une complexité spéciale pour justifier des experts. Ces critiques sont toutefois largement injustifiées, les brouillons des spécifications (quasiment identiques à la version finale) étant en accès libre, et le comité de normalisation s’étant énormément ouvert à la communauté C++ depuis le début des années 2010.

    La bibliothèque standard pas homogène

    Tiré du commentaire : https://linuxfr.org/news/c-17-genese-d-une-version-mineure#comment-1676200.

    La bibliothèque standard est très poussée pour des domaines assez pointus (comme les mathématiques), mais ne propose rien pour des usages très courants comme le multitâche qui est, lui, géré nativement par Rust.

    lmghs [Réponse au commentaire — brouillon à retravailler] : La situation a évolué depuis le C++11 qui a introduit les mutex et autre verrous, des fils d’exécution (threads) et des mécanismes pour l’asynchrone. L’asynchrone était assez imparfait et des efforts continus ont été investis dessus au point que les évolutions les plus visibles pour le C++17 concernent les aspects de la concurrence et du parallélisme. On observe une synergie importante avec la bibliothèque open source HPX.

    Nicolas Boulay : La méthode lock/thread est une méthode qui engendre un paquet d’erreurs (situation de concurrence [race condition], inversion de priorité, interblocage…), un cerveau humain normal a trop de mal avec ces paradigmes. Ce qui semble marcher est le passage de messages (Erlang, Qt…), surtout si l’on sait faire du « zéro copie » (programmation linéaire).

    Des problèmes quotidiens semblent compliqués

    Tiré du commentaire : https://linuxfr.org/news/c-17-genese-d-une-version-mineure#comment-1676523.

    Des problèmes tout à fait quotidiens (comme le fait de n’inclure qu’une seule fois chaque fichier à la compilation) n’ont pas de solution triviale. Chaque développeur ou chaque projet gère donc cela à sa façon avec potentiellement des erreurs et sans capitalisation au sein de la communauté C++.

    La gestion de dépendance, la portabilité, le construction et la reproductibilité

    N. D. M. : Paragraphe à travailler, je jette des idées en vrac

    La gestion de dépendances en C++ est complexe. il faut pouvoir compiler un logiciel dans un contexte reproductible, qui, dans le meilleur des cas :

    • est indépendant de la machine de compilation et de la machine cible ;
    • garantie que les bibliothèques utilisées seront toujours les mêmes (mêmes numéros de version, mêmes paramètres de compilation) ;
    • que le compilateur utilisé est le même ;
    • que tout cela est portable sur plusieurs systèmes ;
    • que le programme (binaire, répertoire de code source…) peut être livré facilement sur une machine cible non maîtrisée. En gros, qu’il vienne avec ses dépendances.

    Ce type de problème est souvent géré dans d’autre langages par des outils de gestion de dépendances, comme en Python avec pip, Haskell avec Stack, etc. Ces outils permettent de construire son programme dans un environnement restreint en fournissant tout ou partie des garanties listées au‐dessus.

    À ma connaissance, il n’existe pas d’outil multi‐plate‐forme de ce type en C++. Ainsi, chaque bibliothèque vient avec sa propre méthode de compilation et d’installation non générique et l’empaquetage d’un programme revient souvent à faire soi‐même, à la main, la construction de toutes les dépendances dans un répertoire dédié du projet, ce qui devient fastidieux quand on cherche aussi à s’assurer des numéros de version des outils de compilation utilisées.

    lmghs : Il existe conan.io qui veut fédérer les choses, et Nuget sous Windows. À voir où cela va nous mener.

    Sous Windows, il n’y a rien de vraiment solide, chaque année voit son lot de gestionnaire de paquets, comme Chocolatey, mais rien de suffisamment robuste ou exhaustif permettant de choisir les versions exactes des bibliothèques et outils.

    Sous GNU/Linux, chaque distribution propose son gestionnaire de paquets, garantissant que les dépendances fonctionnent au sein du système. Cependant, si la version de bibliothèque fournie ne correspond pas à celle nécessaire au programme, on en revient à une gestion à la main.

    On peut aussi utiliser une technologie de conteneur léger comme Docker et installer une distribution GNU/Linux spécifique avec un ensemble de paquets choisis. Mais cette méthode pose le problème des performances. Or, une des raisons de l’utilisation de C++ étant les performances, on peut se retrouver bloqué [citation/link needed].

    freem : Je ne comprends plus là… On parle de construire l’application (build, compilation, linking ?) ou de l’exécuter ? Qu’il n’existe pas de gestionnaire de dépendances binaires est au contraire une bonne chose pour moi : c’est le boulot du système d’exploitation ça. Enfin, de la distribution autour du système d’exploitation.
    Si le problème c’est de détecter les dépendances et de compiler en fonction, alors je trouve que cmake est un très bon candidat, malgré un certain nombre de défauts (il semblerait que ce ne soit pas nickel niveau portabilité, bien que les textes que j’ai lu dans ce sens n’ont pas vraiment argumenté. Il y a aussi le fait que le système de construction ne puisse être promené d’un dossier à l’autre [usage de chemins absolus dans le Makefile généré]).

    Avantages du C++ sur les autres langages

    Le C++ a malgré tout des avantages que l’on ne retrouve dans aucun autre ou pratiquement :

    • une manipulation bas niveau voire très bas niveau (du fait de sa proximité avec le langage C, aujourd’hui majoritairement utilisé dans les microcontrôleurs à la place de l’assembleur) qui permet des optimisations très fines (on peut même y intégrer de l’assembleur) ; il tient cette puissance de sa très forte proximité dans son fonctionnement avec l’ordinateur (au moins son architecture de von Neumann, les machines actuelles ont seulement l’apparence de machines de von Neumann, mais si l’on veut des performances, il faut aller plus loin) ;
    • il a évolué plus que tout autre langage en restant extrêmement rétro‐compatible, cela lui apporte :
      • un gage de stabilité (le code a de forte chance de compiler avec la prochaine version de C++) qui rassure les responsables des logiciels,
      • une capacité haut niveau tout en restant extrêmement performant qui n’a pas d’équivalent ; c’est ce que lui envient, entre autres, le Go ou le Rust ;
    • les systèmes d’exploitation étant écrits en C/C++, il est le langage pour parler nativement au système et donc efficacement, profitant de ces avantages, de nombreuses bibliothèques système ou bas niveau sont aussi en C ou C++ ;
    • l’écosystème C++ est riche de nombreuses bibliothèques inévitables dans certains domaines ; par exemple, de nombreux formats de fichiers et utilitaires de l’industrie du cinéma, tel que OpenEXR, OpenFX, OpenColorIO, OpenImageIO, Alembic, OpenVDB, OpenEXRID, etc., sont fournis sous la forme de bibliothèques C++. Bien que des bibliothèques de liaison (bindings) vers d’autres langages existent, celles‐ci ne garantissent pas forcement une compatibilité parfaite, aussi bien en termes de fonctionnalités que de performances. Par exemple, un tableau dynamique C++ (std::vector) n’est pas forcement compatible au niveau binaire avec son équivalent Rust, imposant la création d’une interface.
    Note aux lecteurs‐commentateurs

    Je donne des exemples de bibliothèques de cette industrie parce que c’est celle que je connais et c’est actuellement la seule raison qui justifie notre utilisation du C++. D’autre personnes sont invitées à ajouter des exemples venant d’autres industries. De façon amusante, on dit souvent que des langages comme Python servent à faire la glu sur les entrées d’un programme et que le cœur est écrit dans un langage plus « sérieux » type C++. Nous, nous aurions plutôt tendance à vouloir utiliser du Rust ou du Haskell pour le cœur et à utiliser C++ pour la glu et les entrées‐sorties. C’est un point de vue assez amusant et à contre‐courant des idées habituelles.

    Et c’est ce point sur les performances tout en étant relativement haut niveau qui fait du C++ un langage que l’on ne peut remplacer dans beaucoup de projets. Les seuls candidats sont des langages aussi très anciens et qui finalement ont moins évolué (Pascal, Fortran…).
    Bien souvent, on développe une application dans un langage de haut niveau (Python, PHP, Ruby ou autres). Puis vient un moment où, pour des raisons de performance, on doit réécrire les parties les plus sollicitées. Par exemple, dans notre société, on développe en PHP et awk. Et quand les charges serveurs augmentent, on réimplémente le cœur en C/C++ et on garde une couche Bash ou PHP au‐dessus. La raison pour laquelle on ne développe pas directement en C/C++, est que son développement et sa maintenance sont plus longs. En C/C++, un bogue peut survenir sur un détail difficile à identifier, là où le PHP, très tolérant, accepte les problèmes. Il y a aussi en C/C++ le risque de ne plus savoir quelle version exacte du code avait servi à compiler la précédente version et donc une difficulté à savoir si lors d’une mise à jour les dernières évolutions du code ne vont pas perturber le fonctionnement en place. Autrement dit, il est difficile de savoir entre deux exécutables quelles sont les modifications apportées.

    Le C++ fait aussi son apparition dans l’embarqué. Là où il n’y avait qu’assembleur et C, la suite logique pour des composants toujours plus complexes est le C++. D’abord à travers l’utilisation simple de classes, permettant une meilleure architecture soit par encapsulation, soit par héritage. Mais de plus en plus, on voit arriver des morceaux de la bibliothèque standard, au fur et à mesure que l’embarqué accepte l’allocation dynamique de mémoire.

    Une autre force du C++ est la base d’utilisateurs le connaissant, du fait de sa longévité — il date de 1983.

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Forges logicielles et hébergement de projets libres

    26 juillet, 2018 - 23:02

    Une forge logicielle est un outil qui permet de travailler et collaborer autour d’un projet logiciel.

    Elle comporte généralement un gestionnaire de code source, un visualiseur de code source, une gestion des droits d’accès, un gestionnaire de tickets, un espace de rédaction (wiki…) et des fonctionnalités de gestion de projet.

    Panorama des solutions libres de forge logicielle

    Les infos ci‐dessous ne sont probablement pas exhaustives et pourront être complétées grâce à vos commentaires. Elles montrent néanmoins assez clairement plusieurs éléments :

    • la profusion de solutions techniques, utilisant des langages différents et des technologies variées ;
    • les différents niveaux de services rendus ;
    • la notoriété de quelques gros acteurs et néanmoins la présence de nombreux plus petits acteurs (historique ou marché de niche) ;
    • la profusion des solutions disparues : être adossé à une grande boîte ne rend pas une forge immortelle ;
    • l’évolution dans le temps : vieillissement des choix techniques, nouveaux langages ou nouvelles technologies apparues depuis, importance du choix des communautés, importance du choix de la masse des projets.
    Forges logicielles d’actualité Nom Technologie utilisée Exemple d’utilisateur(s) et dernière version stable Allura Python SourceForge, fournit une page de comparaison des forges, v1.0.0 (août 2013) → v1.8.1 (mars 2018) Gogs Go ULCO connue pour son Master Ingénierie du Logiciel Libre et NotABug.org qui a créé une divergence ; 0.11.53 le 5 juin 2018 Gitea - Divergence de Gogs car le développeur et créateur du projet fut à plusieurs reprises inactif plusieurs mois sur le projet et semblait peu ouvert aux contributions externes ; 1.4.3 le 26 juin 2018 GitLab Community Ruby Framagit et Unixcorn ; 11.1 le 22 juillet 2018 Phabricator PHP Wikipédia, Enlightenment ; rolling out depuis le dépôt Git Redmine Ruby Rudder, v3.4.6 le 10 juin 2018 Savane PHP Savannah (FSF) ; plutôt moribond Trac Python LIP6, v1.2 en nov. 2016 Tuleap PHP GNU Ring, v4.0.9 (juillet 2010) → v10.0 (avril 2018) FusionForge PHP Forge Alioth de Debian, SourceSup de Renater ; 6.0.5 en décembre 2016 VHFFS PHP / C / Perl TuxFamily et Toile-Libre, v4.6.0 en octobre 2016 et 4.7-dev-fbf4cb479d Launchpad - Forge de Canonical (Ubuntu), devenue libre (AGPL) en 2009 ; rolling out depuis le dépôt Bzr Fossil C SQLite et Chiselapp ; 2.6 depuis le 5 mai 2018 Pagure Python+Git 4.0.4 le 19 juillet 2018 GitPrep Perl rolling out depuis le dépôt Git

    Note : GitHub n’est pas libre (ni même open source), on peut à ce sujet relire les critiques de Carl Chenet.

    Celles qui ont disparu

    Note : Google Code a fermé en 2015 (voir ce journal sur la fermeture) mais n’était pas sous licence libre.

    Logiciels proches mais qui ne disposent pas de toutes les fonctionnalités

    Il existe aussi des logiciels n’offrant pas toutes les fonctionnalités habituellement attendues d’une forge. Par exemple :

    • gestion des dépôts et du code source (contributions, revues, accès) :
      • RhodeCode Community Edition, la base en logiciel libre de RhodeCode Entreprise Edition ; développé en Python, les contributions doivent être sous licence MIT, ce qui permet à la société de les inclure aussi dans la version non libre ; 4.12.4 le 16 juillet 2018,
      • Kallithea, divergence de RhodeCode car la licence n’était pas claire ; développé en Python ; utilisé par exemple par le Software Freedom Conservancy ; historique des versions : 0.1 (août 2014) → 0.3.5 (juin 2018) ;
      • etc.
    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Le client de courriel Eudora est devenu libre

    26 juillet, 2018 - 11:28

    Pour ceux qui ne le connaissaient pas encore, Eudora est un client de courriel pour Windows et macOS. Il est apparu en 1988 et a donc été l’un des premiers clients modernes et graphiques, contribuant à populariser le courrier électronique dans sa forme actuelle.

    Note : cette dépêche est largement inspirée de l’annonce du Computer History Museum du 22 mai 2018, sans en être une traduction fidèle (oui, il aurait été possible de juste poster un lien, mais cela serait dommage).

    Pour comprendre l’histoire d’Eudora, il faut d’abord comprendre le contexte de l’époque. Pour lire ses courriels, il fallait se connecter d’une façon ou d’une autre à un serveur (avec rlogin, l’ancêtre de ssh) et, ensuite, lancer diverses commandes pour récupérer ou composer les messages. Avec l’arrivée du Macintosh et des interfaces graphiques sur des machines à un prix accessible, il était grand temps de rendre le courriel facile et accessible à tous.

    Développé par Steve Dorner, alors employé de l’université d’Illinois, il était publié en graticiel (freeware : gratuit, mais sans les sources).

    En 1991, le développeur a été embauché par Qualcomm pour poursuivre à plein temps le développement d’Eudora. En effet, Qualcomm voulait déployer l’informatique pour tous ses employés, et il avait pour cela besoin d’un client de courriel approprié, convivial et facile à prendre en main. Cependant, Qualcomm voulait utiliser Eudora également sur des ordinateurs fonctionnant sous MS-DOS, puis sous Windows. Une deuxième version d’Eudora a donc été écrite pour ces systèmes (il ne s’agit pas d’un partage du code source de la version Macintosh, mais bien d’un logiciel entièrement différent, écrit en C++).

    Comme le logiciel marchait bien dans cette utilisation interne, Qualcomm a décidé de continuer à le diffuser, d’abord sous forme d’un postcard ware (les utilisateurs étaient invités à envoyer une carte postale s’ils appréciaient le logiciel). Plusieurs milliers de cartes postales plus tard, et devant le nombre d’utilisateurs intéressés, Eudora est devenu un partagiciel (shareware) : une version gratuite mais avec un bandeau publicitaire et une version payante, au départ une vingtaine de dollars, mais plus tard le prix augmentera jusqu’à 75 dollars, avec une équipe de cinquante personnes travaillant sur le développement du logiciel.

    Mais en 2006, Eudora avait de plus en plus de mal à trouver sa place. Deux raisons expliquent probablement cela. D’une part, l’adoption grandissante de Microsoft Outlook comme client de courriel dans les entreprises. Et, d’autre part, la version Macintosh d’Eudora n’a jamais été adaptée pour Mac OS X et ne fonctionnait que sous Mac OS 9 ou via l’émulateur « classic » fourni avec les versions suivantes. Malgré des utilisateurs fidèles et heureux de l’utiliser, il ne représentait pas de grands bénéfices pour Qualcomm, qui a finalement choisi de se recentrer sur ses activités principales (les circuits intégrés).

    Une tentative de faire une version d’Eudora basée sur Thunderbird a été lancée, sans grand succès. Le logiciel est ensuite tombé dans l’oubli.

    Mais c’était sans compter sur le Computer History Museum qui, depuis cinq ans, est en discussion avec Qualcomm pour pouvoir archiver les sources d’Eudora. Ils n’en sont pas à leur premier essai, puisque le musée propose aujourd’hui de télécharger (sous licence non libre) le code de MS-DOS, de son ancêtre CP/M, ou encore des premières versions de Microsoft Word ou d’Adobe Photoshop.

    Cependant, Qualcomm a fait un choix différent. Plutôt que de publier les sources avec une licence restrictive, il a choisi de transférer le copyright au Computer History Museum et d’appliquer la licence BSD.

    Comme souvent dans ce genre de cas, les sources publiées ne sont pas directement utilisables, car les parties de bibliothèques propriétaires utilisées ont été retirées. Il faudra donc remplacer les morceaux manquants.

    La version pour Windows comporte presque 9 000 fichiers C++ pour un total de 458 Mio. La version Macintosh, elle, est écrite en C et comporte environ 1 500 fichiers, pour un total de 70 Mio.

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur