Linux France

S'abonner à flux Linux France
Mis à jour : il y a 7 min 19 sec

Agenda du Libre pour la semaine 34 de l'année 2018

Dimanche 19 Août

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 (2 en Belgique, 5 en France, 0 au Luxembourg, 2 au Québec, 0 en Suisse et 0 en Tunisie) est en seconde partie de dépêche.

Sommaire [CA-QC Montréal] (3L)-Logiciels Libres en liberté groupe d’utilisateurs de Logiciels Libres deMontréal - Le lundi 20 août 2018 de 14h00 à 17h00.

(3L)-Logiciels Libres en liberté groupe d’utilisateurs de Logiciels Libres, de niveau débutant qui tiendra sa rencontre régulière mensuelle tout les 3ième lundi de chaque mois.

Amener vos portables,téléphone intelligent et tablette et votre bonne humeur. Venez jaser sur les logiciels libres, Nous montrer vos découvertes, poser vos questions

[FR Paris] Certification PGP et CAcert - Le mercredi 22 août 2018 de 19h00 à 20h00.

Vous souhaitez renouveler votre certificat CAcert Augmenter son niveau de confiance Augmenter le niveau de confiance de votre clé publique PGP

Venez rencontrer des certificateurs autour d'un verre

En pratique

Pour votre clef PGP, préparez

  • deux documents d'identité français parmi la carte nationale d'identité, le passeport, la carte d'identité militaire, le permis de conduire, …
  • un petit papier imprimé avec l'identifiant et l'empreinte de votre clef, en autant d'exemplaires que vous espérez rencontrer de gentils autres porteurs de clefs.

Pour votre certificat CAcert, préparez

  • deux documents d'identité français parmi la carte nationale d'identité, le passeport, la carte d'identité militaire, le permis de conduire
  • des formulaires d'accréditation imprimés, pré-remplis avec vos coordonnées en cliquant ici, ou vierges en cliquant là. Deux exemplaires pour chaque accréditation un pour vous, un pour le gentil accréditeur.

Tous les détails sur le wiki de CAcert et Meetup

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

Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

Ouvert au public tous les mercredi soir.

Venez nombreux.

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

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.

[CA-QC Coteau du Lac] Émission #158 de bloguelinux - Le jeudi 23 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 Cognac] Initiation à la programmation et à la robotique - Du vendredi 24 août 2018 à 09h00 au dimanche 26 août 2018 à 16h00. Atelier sur inscription en nous envoyant un message à contact@logicielslibrescognac.org

Programme

Initiation à la programmation structurée Faire un programme bash ( téléchargement automatique de fichiers sur un site internet ) Cette journée est très intéressante pour commencer simplement la programmation.

Courte initiation à la programmation fonctionnelle et orientée Objet Faire un programme en C et C++ ( créer une liste de mots du dictionnaire … et comprendre pourquoi il faut avoir des mots de passes fort…).

Initiation à arduino (programmation et cablage) pour la création d'un petit robothttp://logicielslibrescognac.org/contact.php

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

Venez vous renseigner pour diffuser largement vos œuvres.

Sinon venez installer Linux ou des logiciels libres.

Venez nombreux.

[BE Saint Gilles] Gnu/Linux Install party - Le dimanche 26 août 2018 de 10h00 à 18h00.

L’une des grandes qualités des logiciels libres, c’est qu’on peut librement les copier, les installer, les tester

Une Linux Install Party est une réunion où tout un chacun peut

  • venir copier, échanger, se faire assister dans l'installation de logiciels libres
  • partager des connaissances, des configurations, faire circuler des informations…
  • faire connaissance avec une culture du Libre.

Chaque quatrième dimanche du mois, nous organisons une Install Party à l’atelier multimedia de l’asbl fij

Le comité asbl BxLUG 2018

[BE Bruxelles] Educode.be 2018 - Du dimanche 26 août 2018 à 18h00 au mercredi 29 août 2018 à 20h00.

 Educode.be est une conférence internationale educode sur l'enseignement et le numérique.

L'idée est que si nous voulons que nos concitoyens soient demain capables de gérer leurs environnements numériques, il faut aujourd'hui informer, former et faire réfléchir les enseignants, les directions et les décideurs politiques qui le plus souvent sont autodidactes. 

Les présidents d'honneur sont Bernard Rentier, ancien recteur de l'université de liège et Yves Poullet, ancien recteur de l'université de Namur.

La conférence commence par un cocktail d'accueil dimanche 26 août à 18h00 dans la salle de marbre de l'académie royale.

Elle commence réellement lundi 27 à 9h00 dans la salle Henri Le Bœuf de Bozar.

le programme est quasi fait.

Il sera visible sur http://educode.be/programme.

La dernière conférence de la journée sera de Thomas Pesquet, astronaute français qui a emporté des expériences de sciences utilisant des ordinateurs préparées par des lycéens français et sélectionnées par ESA.  

Toute la journée, il y aura une exposition de groupes d'enfants et de moins jeunes qui font des choses amusantes et intéressantes avec du numérique en classe ou en dehors des classes.

Puis nous profitons de la plus belle salle de concert bruxelloise pour faire un concert symphonique d'amateurs avertis avec des chœurs d'enfants et d'adultes pour célébrer la paix et marquer le 90e anniversaire du pacte de Paris ou pacte Brian-Kellog signé le 27 août 1928 et trop vite oublié.

Quel meilleur symbole pour marquer la paix que d'associer la musique et les langages de programmation, toutes langues universelles.

Mardi 28, de 9h00 à 17h00, nous organisons 60 à 80 ateliers pratiques sur des sujets très variés, depuis des usages de logiciels de composition musicale ou d'aide à la version latine jusqu'à la mise en forme d'enregistrements vidéo avec smartphone ou l'apprentissage de la programmation avec ou sans ordinateur en passant par des ateliers sur les méthodes agile et scrum adaptées à l'enseignement ou des ateliers expérimentaux de physique et chimie avec ordinateurs et smartphones.

En fin de journée, la fin du congrès pour la majorité des enseignants, nous allons prendre un buffet convivial autour des iguanodons de l'institut d'histoire naturelle.

Mercredi 29 de 9h00 à 18h00 à l'académie royale à nouveau, nous réfléchissons durant la journée aux expériences positives partout, échangeons sur celles-ci en mode congrès scientifique. 

Nous avons le soutien de nombreux partenaires, toutes les universités francophones, deux flamandes, de nombreuses associations, l'unesco, l'institut de formation en cours de carrière qui permet que les professeurs viennent en formation officielle, IBM, cap gemini, la plupart des ministres mais pas encore de garantie pour celui de l'enseignement obligatoire bizarrement. 

Bien sûr, pour faire la conférence comme nous en rêvons, votre soutien tant moral que financier serait très important.

Il manque encore des sous (nous sommes aussi occupés à essayer d'obtenir la possibilité que les dons soient défiscalisés si cela vous intéresse) 

L'affiche actuelle dans http://esi.link/educode-affiche-fr-02

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Dark Moon : une distribution GNU/Cygwin portable pour Windows

Jeudi 16 Août

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!

Mardi 14 Août

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 noeuds. 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èreles 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 OpenSource, 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 mails 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 agenda 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 framework Django (Python3), 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

Lundi 13 Août

Je travaille maintenant depuis presque 10 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 plateformes 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 frameworks 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 framework 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 qu'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 chat et des chatrooms, 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 backend.

  • 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 backend.

Un peu d'histoire

J'ai créé Movim en 2008 afin d'apprendre à programmer et essayer de construire par la même occasion une plateforme 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 plateforme 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 plateforme 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 framework 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 websocket 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 controlé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 à 20Mb 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 backend 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 resources publiques par exemple)

Pour finir, ces processus gèrent aussi tout ce qui est relatif au frontend, 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.

Parseur 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 parse (analyse lexicalement) 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 parsait séparément.

Le parseur 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.

Ce 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 buffer 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 buffers 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 packagé 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 framework 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 à PHP7 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 200ms à être déclenchée va retarder l'exécution du reste du code de 200ms ;
  • 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 plateformes de chat, de par son backend, mais aussi grâce à la façon dont son frontend 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

Dimanche 12 Août

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

Lundi 6 Août

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

Haiku a 17 ans

Lundi 6 Août

Les années passent, et Haiku est toujours là !

Le projet, inspiré du système d'exploitation BeOS, a démarré le 18 août 2001, avec le fameux message "So, let's start." (« bon, allons-y ») sur sa liste de discussion. Alors nommé OpenBeOS, le projet avait été créé peu après l'annonce du retrait de Be du marché des ordinateurs de bureau.

Cet anniversaire est l'occasion de faire le point sur les progrès de Haiku cette année (en l'absence de nouvelle version publiée depuis la version alpha 4 en 2012, il faut bien trouver un prétexte pour donner des nouvelles de temps en temps).

Sommaire Présentation de Haiku

Pour ceux qui n'auraient jamais entendu parler de Haiku, il s'agit d'un système d'exploitation pour les ordinateurs personnels (par opposition, d'une part aux serveurs, d'autre part aux smartphones, tablettes, et autres systèmes embarqués). Il est une réécriture de BeOS, un système propriétaire abandonné en 2001.

D'un point de vue technique, ses particularités sont une base de code presque intégralement en C++ (oui, même le noyau) et généralement reconnue pour sa clarté et sa lisibilité (oui, même si c'est du C++), son approche de la programmation très multi-thread (chaque fenêtre ouverte par une application a son propre thread, par exemple), et la présence d'une API complète et cohérente pour faciliter le travail des développeurs d'applications.

D'un point de vue utilisateur, l'objectif est d'avoir un système facile à utiliser et à appréhender (pas de surprise ou de comportements inattendus), réactif, tout en restant flexible et capable de faire ce qu'on attend de lui.

Pourquoi un clone de BeOS ?

À l'origine, Haiku est pensé pour fournir une continuité aux utilisateurs de BeOS et aux développeurs d'applications qui ne souhaitaient pas migrer vers un autre système.

Cependant, 17 ans plus tard, BeOS est mort et enterré, et Haiku n'a pas réussi à fournir une version stable dans les temps. La plupart des développeurs d'applications sont passés à autre chose depuis. Cet objectif initial n'a donc pas été atteint en temps utile.

Cependant, Haiku reste un projet pertinent aujourd'hui, car aucun système libre n'a vraiment pris la place que BeOS a libéré (dit autrement, non, ce n'est toujours pas l'année de Linux sur le Desktop).

Le maintien de la compatibilité avec BeOS garde également un intérêt, pas pour les utilisateurs mais pour l'organisation du projet :

  • elle permet de garder un objectif à peu près raisonnable en vue, c'est-à-dire qu'on peut rejeter les propositions de nouvelles fonctionnalités en disant « ce n'était pas dans BeOS  » ;
  • elle permet de comparer l'implémentation des API avec celle de BeOS, pour décider si un problème vient d'une application ou d'un problème d'implémentation côté Haiku ;
  • elle permet enfin d'expérimenter les difficultés à maintenir pendant plus de 15 ans la compatibilité de l'ABI, et à réfléchir à la meilleure façon de procéder pour assurer la compatibilité entre les futures versions de Haiku.

Cependant les désavantages (utilisation de gcc2, impossibilité d'implémenter certaines choses ou de résoudre certains problèmes de sécurité qui nécessiteraient de changer l'API) se font de plus en plus pressants, c'est pourquoi il existe maintenant une version 64 bits de Haiku qui peut s'affranchir de certaines de ces contraintes.

Toujours pas de version bêta

La dernière version publiée par Haiku est la version R1 alpha 4.1, qui date de novembre 2012. De très nombreux progrès ont été faits depuis, et en particulier un gros chantier sur l'infrastructure d'hébergement du projet permettant de mettre en place un dépôt de paquets pour tous les utilisateurs (ce sera l'une des grosses nouveautés de la prochaine version R1 bêta 1).

Si on avait su que cela prendrait autant de temps, on se serait probablement organisé autrement, afin de pouvoir publier quelques versions alphas supplémentaires et faire patienter les gens. Pour l'instant, il vaut vraiment mieux télécharger un « nightly build » pour essayer Haiku.

Nouveautés de l'année Corrections de bugs

Il y en a beaucoup trop pour les détailler. Haiku est de plus en plus stable. Le portage d'applications venues d'autres systèmes, et la mise en place de machines fonctionnant sous Haiku pour la compilation des paquets présents dans les dépôts a permis (même si ce n'était pas le but initial) de tester le système de façon beaucoup plus intense. De nombreux problèmes difficiles à reproduire ont ainsi pu être plus facilement identifiés, puis résolus.

La compatibilité POSIX s'améliore, le noyau fait de plus en plus de vérifications pour éviter les "panics" lors d'appels systèmes avec des paramètres invalides.

Un bug mérite une mention spéciale, la méthode Split() permettant de découper une chaîne de caractères à l'endroit où elle contient un séparateur ne fonctionnait pas correctement. Il est surprenant que ce problème n'ait jamais été détecté auparavant.

Nous avons également corrigé plusieurs problèmes d'alignement de la pile (dans le thread principal, les handlers de signaux, et dans le noyau) qui empêchaient l'utilisation fiable d'instructions SSE2. Le problème a été mis en évidence au départ dans le navigateur web, il a donc fallu creuser assez loin dans le système pour le corriger!

Infrastructure

Le vénérable serveur "baron", qui hébergeait l'ensemble des services de Haiku (bugtracker, dépôts git, site web…) depuis fin 2009 est en train d'être mis à la retraite.

Il est remplacé par "maui", un serveur plus récent, qui utilise des conteneurs docker plutôt que des machines virtuelles pour isoler les différents services.

C'est une opportunité pour revoir entièrement la façon de gérer le serveur. Baron était administré principalement par une personne qui faisait les changements directement. Mais avec le temps, de plus en plus de services ont été mis en place et il devenait trop difficile pour une seule personne de tout suivre. Le nouveau serveur est configuré à partir de dockerfiles qui peuvent donc être relus et modifiés par plusieurs personnes.

D'autre part, un gros changement est le déploiement de Gerrit pour la revue de code. Précédemment, les contributeurs attachaient des correctifs dans leurs rapports de bugs et la revue était faite à partir de ces fichiers, ce qui est assez peu pratique. Gerrit permet de faire une revue plus facilement, et il est donc également utilisé par les développeurs (qui pourraient directement envoyer leurs changements sur la branche principale du dépôt Git) pour obtenir une relecture de leurs changements.

En ce qui concerne l'hébergement des dépôts de logiciels, nous avons enfin tout mis en place pour compiler automatiquement les logiciels à partir de recettes fournies par le projet haikuports. Un système de miroirs est en train de se mettre en place, avec pour l'instant deux serveurs situés aux États-Unis et en Nouvelle-Zélande (en plus du serveur principal situé en Allemagne).

Les paquets binaires sont donc rapidement disponibles dans HaikuDepot (le gestionnaire de paquets de Haiku) dès la publication des recettes permettant de les construire.

Pilotes de périphériques

Comme pour n'importe quel système d'exploitation, un point délicat est de pouvoir fonctionner correctement sur le plus d'ordinateurs possibles. Cela passe par l'écriture de pilotes pour tous les périphériques.

C'est donc une partie de Haiku qui est assez active et il serait difficile de recenser précisément tous les changements intervenus dans l'année. Mentionnons quand même le support des boutons « étendus » pour les touchpads Synaptics et un début de support de leur « clickpad »; la possibilité d'utiliser une imprimante connectée sur un port série; des évolutions sur les pilotes graphiques Intel et Radeon pour prendre en charge plus de versions du matériel; et de petites améliorations sur le pilote de cartes son hda (qui est utilisé sur tous les ordinateurs à base de chipset Intel).

Mise à jour des pilotes réseau

Pour gagner du temps, Haiku réutilise les pilotes développés pour FreeBSD via une couche de compatibilité.

Jusqu'à l'année dernière, les pilotes de FreeBSD 9 étaient utilisés, mais aujourd'hui nous utilisons ceux de FreeBSD 11. Cela augmente le nombre de cartes réseau prises en charge et corrige de nombreux problèmes d'instabilité de la connexion.

D'autre part, un gros travail a été fait sur la pile TCP pour compléter l'implémentation de diverses RFCs permettant d'obtenir de meilleures performances.

Support de l'USB3

Le pilot xHCI est maintenant fonctionnel sur la plupart des machines, même s'il ne fonctionne pas encore parfaitement. Cela devenait nécessaire, car de plus en plus d'ordinateurs ne proposent plus du tout de ports USB2.

Pilotes virtio

Les pilotes virtio sont maintenant pleinement fonctionnels. Virtio est un bus utilisé par des machines virtuelles pour remplacer certains périphériques et éviter d'émuler un matériel réel. En utilisant une interface simplifiée, l'écriture des drivers est facilitée et les performances sont meilleures.

Haiku peut maintenant utiliser les cartes réseaux, la mémoire "ballon" (RAM qui peut être redimensionnée en fonction des besoins de l'hôte et des machines émulées), et le stockage de masse sur virtio.

Mise à jour du navigateur web

Le navigateur fourni avec Haiku est basé sur un port de WebKit. Nous avions l'an dernier un an et demi de retard sur la version upstream de WebKit. Nous avons rattrapé une partie de ce retard puisque nous utilisons aujourd'hui une version datant de janvier 2018.

Ceci permet d'accéder à des sites web modernes, même si de nombreux problèmes subsistent au niveau du rendu ainsi que de l'implémentation du protocole HTTP (moins simple qu'il n'y paraît à mettre en œuvre correctement).

En attendant, les navigateurs Qupzilla et Otter browser, en Qt, permettent de visiter certains sites que WebPositive, le navigateur natif, ne parvient pas encore à traiter.

Media kit

Le Media Kit prend en charge tous les aspects multimédia (audio et vidéo, principalement) dans Haiku. Il permet aux applications d'exposer des nœuds qui sont connectés dans un graphe, un peu à la façon de Jack ou GStreamer sous Linux.

Ajout du BMediaClient

L'écriture de nœuds média demande beaucoup de travail répétitif et inutilement complexe. Une nouvelle classe BMediaClient a donc été introduite qui propose de prendre en charge la plupart de cet effort et donc de proposer une interface plus simple à aborder aux développeurs.

Passage à ffmpeg 4

Haiku utilisait encore pour sa version gcc2 une version 0.10 de ffmpeg, car il était impossible de compiler des versions plus récentes. Cela empêchait l'utilisation des API modernes de ffmpeg et commençait à poser problème pour le support de formats de fichiers récents.

La solution mise en place consiste à compiler ffmpeg avec gcc7, mais à faire l'édition de lien de façon compatible avec gcc2. Pour l'instant, cela semble fonctionner dans ce cas précis. Nous allons donc pouvoir moderniser le plugin de décodage audio et vidéo basé sur ffmpeg, qui traite dans Haiku la plupart des formats de fichiers.

Gestion du mode hybride 32/64 bits

La version 64 bits de Haiku ne peut actuellement pas exécuter d'applications 32 bits. Il est probable que la version 32 bits soit un jour complètement abandonnée, mais pour cela il faudra proposer une solution pour que les utilisateurs puissent migrer vers la version 64 bits en conservant leurs applications.

La gestion de l'exécution des applications 32 bits sur un noyau 64 bits est donc un des chantiers en cours. Cela pose un certain nombre de problèmes au niveau de l'interface entre le noyau et l'espace utilisateur, les appels systèmes devant traiter les données dans le bon format selon l'application utilisée.

La première étape déjà franchie est l'intégration de SMAP et SMEP, qui permettent de s'assurer que le noyau n'accède pas par erreur aux données en espace utilisateur (la protection dans l'autre sens étant déjà assurée par la MMU). On a pu grâce à cette vérification clairement identifier tous les endroits ou de tels accès sont effectués, ce qui permettra de repérer facilement s'il est nécessaire ou pas de faire une conversion 32 <=> 64 bits. De plus, on gagne en sécurité puisqu'il sera plus compliqué pour une application d'utiliser un appel système de façon détournée pour lire ou écrire dans la mémoire du noyau.

Passage à GCC 7

Haiku dans sa version 32-bit est fourni avec deux compilateurs, une version 2.95.3 de gcc qui permet d'assurer la compatibilité binaire avec BeOS, et un gcc plus récent permettant de compiler les applications modernes (la version 64-bit de Haiku n'assure pas pour l'instant de compatibilité, et donc fournit uniquement une version moderne de gcc).

L'année dernière, la version « moderne » utilisée était gcc 5.4. Nous utilisons maintenant la version 7.3. La migration a été l'occasion de corriger quelques bugs dans Haiku qui l'empêchaient de démarrer avec les nouvelles optimisations proposées par gcc.

Le travail est déjà en cours pour le passage à gcc8, qui lève de nouveaux warnings (une grande partie de Haiku est bien entendu compilée avec le flag -Werror, donc les warnings ne sont pas admis).

Le retour de Cosmoe

Cosmoe est un projet consistant à porter l'userland de Haiku sur un noyau Linux ou BSD. Il n'a jamais abouti à quelque chose de fonctionnel, mais plusieurs développeurs (impliqués dans Haiku ou pas) ont repris le projet de temps en temps pour y faire quelques mises à jour.

Cette fois, le projet a été repris par Dario Casuolinovo alias Barrett, qui a travaillé sur Caya (notre client de messagerie instantanée) et sur le Media Kit de Haiku. Son travail sur le Media Kit l'a convaincu que le noyau utilisé dans Haiku n'était plus pertinent aujourd'hui et qu'il valait mieux l'abandonner pour quelque chose d'autre. Nous verrons si Cosmoe arrive à percer cette fois-ci.

Les membres du projet Haiku pensent que leur noyau reste pertinent (pour diverses raisons, en particulier le fait qu'il est écrit en C++ et qu'il offre une ABI stable pour les pilotes de périphériques) mais sont heureux de voir émerger d'autres projets inspirés par BeOS.

LibreOffice pour Haiku

Ça y est ! après plusieurs tentatives (quand on a commencé, le projet s'appelait encore OpenOffice…), nous avons enfin une version de LibreOffice pour Haiku.

Cela a été rendu possible par le gros travail chez LibreOffice pour simplifier leur système de compilation, et également par le système de paquets de Haiku qui a permis de capitaliser et de mutualiser le portage des dépendances de LibreOffice.

Bien qu'une grande partie des efforts a été faite pour avoir une version native, c'est finalement l'apparition d'un backend Qt dans LibreOffice qui a permis d'avoir une version fonctionnelle le plus rapidement.

La disponibilité d'une suite bureautique moderne est un point important, d'une part parce qu'on peut maintenant présenter Haiku sérieusement comme un système utilisable pour faire un peu de bureautique et de navigation web, et d'autre part parce que LibreOffice remplace GoBe Productive, l'une des dernières applications BeOS non libres et encore utilisées (la prochaine sur la liste est Sync Modular - avis aux volontaires). On peut donc commencer à envisager plus sereinement l'abandon de la compatibilité binaire avec BeOS.

D'autres langages de programmation

Le langage Rust est à la mode, il était donc indispensable d'avoir une version pour Haiku et c'est maintenant chose faite. Rust 1.28 contient tous les correctifs nécessaires pour compiler directement sur Haiku, sans modifications.

Mentionnons aussi une version de Swift qui est arrivée cette année, le support de Fortran disponible par défaut dans gcc, et des progrès pour avoir une version de freepascal complètement opérationnelle. Ceci bien sûr en plus de tous les langages qui fonctionnaient déjà très bien auparavant: Python 2 et 3, Lua, Perl, C, C++, et de nombreux autres.

Java et Go ont été disponibles quelque temps, mais ont disparu des dépôts lors de l'automatisation des builds. L'ancien paquet pour Java 7 fonctionne, la version de Java 8 disponible plante au démarrage, et il n'y a pas encore eu de tentative pour les versions suivantes. Du côté de Go, une version assez ancienne était fonctionnelle, mais il est maintenant impossible de la compiler, car les sources référencent des dépôts hébergés par code.google.com, maintenant fermé. Avis aux volontaires pour remettre tout ça en route.

Enfin, il semble utile de présenter yab, un fork de yabasic qui permet de développer des applications graphiques pour Haiku. Il n'était plus vraiment maintenu, mais quelques développeurs l'utilisant se sont un peu mis au C++ pour faire les évolutions nécessaires. Il est maintenant disponible dans les dépôts, l'interpréteur étant distribué sous forme d'une bibliothèque partagée qui peut être utilisée par tous les programmes écrits en yab.

Support de l'UEFI

Il est maintenant possible d'installer Haiku sur une machine UEFI. Actuellement ce n'est pas intégré dans les « nightly builds » générés par nos buildbots, il s'agit d'une image séparée contenant uniquement un chargeur de démarrage UEFI. Plus tard, ce sera intégré aux images « anyboot » (qui disposent également d'un MBR pour démarrer depuis une clé USB, et d'un chargeur « el torrito » pour démarrer quand elles sont gravées sur un CD).

Améliorations de l'interface utilisateur

Là encore, beaucoup trop de changements pour tous les lister, mais les applications fournies avec Haiku ont vu de nombreux petits changements. Cela va du comportement des menus ouverts trop près du bord de l'écran, à une meilleure prise en charge des écrans haute définition (il suffit de choisir une taille de police de caractères appropriée, le reste de l'interface doit s'adapter en fonction).

Launch Daemon

Le Launch Daemon est chargé de l'exécution des services, et du séquençage du démarrage et de l'arrêt du système.

Les évolutions cette année portent sur la gestion des logs, une réécriture de la procédure d'arrêt pour éviter d'éteindre la machine avant que l'utilisateur ait pu enregistrer tous les changements dans des applications ouvertes (dans certains cas tordus). Il reste néanmoins bien plus léger que systemd.

Évènements et conférences

Comme chaque année, Haiku était présent au FOSDEM, au Capitole du Libre, aux JDLL et aux RMLL. L'occasion de donner plusieurs conférences, de rencontrer les développeurs d'autres projets et d'en profiter pour porter quelques logiciels vers Haiku avec l'aide des contributeurs principaux (mentionnons cette année Poezio, Dead Ascend, ou encore le Godot Engine, qui avait déjà un portage mais non maintenu). Nous avons également pu constater l'incompatibilité de Haiku avec les machines Purism Librem, sans avoir le temps de se pencher de plus près sur la question, malheureusement.

La conférence BeGeistert, qui regroupe depuis très longtemps les utilisateurs et développeurs de Haiku (et de BeOS et Zeta), a pris une pause cette année, l'équipe organisatrice n'ayant plus la motivation pour s'en occuper étant donné le peu de personnes présentes.

Le projet Haiku mettait à profit cette conférence pour organiser un « coding sprint », qui consiste à mettre le plus grand nombre possible de développeurs dans une salle de réunion pendant 5 jours avec un stock approprié de sodas, et une cantine et des lits à disposition. Le coding sprint étant un moyen étonnamment efficace de faire avancer les choses, nous avons décidé de le maintenir, et de l'organiser cette année juste après le Capitole du Libre, à Toulouse. Le changement de lieu a été plutôt apprécié par les développeurs présents, qui ont pu en particulier travailler sur le portage de LibreOffice, des corrections de bugs dans le navigateur web, l'amélioration de l'application HaikuDepot (le gestionnaire de paquets graphique) pour régler divers problèmes de performance et faire quelques améliorations cosmétiques, ou encore ajouter le réglage de la luminosité de l'écran sur les PC portables utilisant un chipset vidéo Intel.

Bonne nouvelle, après cette année sans BeGeistert, l'évènement sera de retour en octobre prochain. Nous retournerons en Allemagne mais nous quitterons Düsseldorf, dont l'auberge de jeunesse qui nous a souvent accueilli n'offre plus des tarifs accessibles pour le budget de HSA (l'association qui finance l'évènement). Le format retenu est un évènement sur 4 jours, le détail sera décidé par la suite, sans doute un intermédiaire entre une conférence (avec quelques présentations) et un coding sprint.

GCI et GSoC

Haiku candidate tous les ans au Google Code-In et au Google Summer of code.

Google Summer of Code

Il s'agit d'un programme organisé par Google dont le principe est de payer des étudiants pour qu'ils puissent travailler à plein temps sur des projets libres. Les membres de chaque projet s'occupent de l'encadrement, et ont toute liberté dans les sujets proposés.

Haiku a accueilli 3 étudiants cette année, travaillant sur le système de fichiers XFS (mais cela n'a pas donné grand-chose), un pilote pour les périphériques SDHCI (lecteurs de cartes SD sur de nombreuses plateformes ARM et certains laptops x86), et un client graphique pour Git intégré dans le Tracker (largement inspiré de TortoiseGit sous Windows). Les deux derniers projets sont en bonne voie.

Google Code-In

Code-In, quant à lui, cible les enfants de 13 à 17 ans, le but étant de leur faire découvrir le logiciel libre et plus généralement le développement de logiciels.

Il s'agit d'un concours où les participants doivent compléter différentes tâches assez simples proposées par un projet libre. Chaque projet choisit ensuite deux gagnants qui pourront passer une semaine à San Francisco, assister à des conférences de personnes travaillant chez Google, et obtenir de nombreux stickers, T-Shirts, et autres goodies.

Haiku participe tous les ans depuis la création du Google Code-In en 2010. Cela nécessite un investissement important de toute la communauté autour du projet, en effet il n'est pas facile de gérer l'arrivée massive des participants sur les canaux IRC et listes de diffusion du projet. Cependant, l'habitude est prise et l'organisation est un peu meilleure chaque année.

Les tâches proposées sont diverses, on trouve des choses techniques (par exemple porter et packager un logiciel pour Haiku), graphiques (concevoir un autocollant à distribuer lors des conférences ou un poster présentant Haiku), de la documentation, ou encore du test (trouver des bugs dans un logiciel, écrire un plan de test, vérifier si des bugs reportés dans le passé sont toujours présents), et enfin une catégorie « outreach » (par exemple, préparer une présentation sur Haiku et la présenter à d'autres élèves, ou encore faire une vidéo présentant une fonctionnalité particulière).

L'intérêt principal de ces deux programmes est l'accueil de nouveaux contributeurs et l'amélioration de la diversité de notre équipe, en effet la communication de Google et des différents projets participants permet de faire découvrir Haiku à des personnes qui ne seraient pas autrement venues contribuer.

On ne compte plus vraiment sur ces projets pour faire avancer les choses directement : le temps nécessaire pour l'encadrement dépasse largement le temps qu'un développeur expérimenté aurait utilisé pour faire le travail directement. Cependant l'expérience est intéressante et nous permet aussi d'améliorer notre documentation et notre façon de travailler pour être plus accueillants aux nouveaux contributeurs.

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

Dimanche 5 Août

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.

NdM. : ce rover est une version réduite (36cm, 11kg, 17cm/s) de Curiosity (2,7m, 899kg 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 suivant : ê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 2500 USD (environ 2160 EUR).

(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)

Dimanche 5 Août

Le 28 juin 2018, le site LinuxFr.org fêtait ses 20 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 5 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 20 ans ? Le Libre dans 20 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 (surement google ou un lien sur un forum) 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 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 3 fois par jour pour les transports et me laisser en paix le weekend. 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 - j'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 100 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. 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 Network Manager, 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 de 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 à un tel s'il connaît telle techno et comme il répond « je l'ai lu sur linuxfr » 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 à 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 marques page 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… Par contre, 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-barre, de DVDs, 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 continue (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 de Anthony Jaguenaud à cette question)

dzecniv: Sans hésitation, le travail en cours sur Weblocks, un framework 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 à jours 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 20 ans ? Le Libre dans 20 ans ?

Adrien Dorsaz : Wow, je ne suis pas sûr que LinuxFr.org va survivre au bug de l'an 2038, comme à l'époque où mon entourage avait peur du « bug 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 ses logiciels comme bon lui semble et quelques-uns qui seront eux-mêmes développeurs/artiste/traducteur/documentaliste/… avec du talent :)

JPEC : Je pense que dans 20 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 on regarde les ordiphones ou les tablettes actuelles, c'est quasi impossible à faire fonctionner avec du libre). Par contre, 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 de 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 intracutané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é.es 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 IDE 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é, ergnonomie 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

Samedi 4 Août

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

Vendredi 3 Août

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 bugs 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 bugs, et ajoute quelques améliorations en terme d’accessibilité. La précédente dépêche sur LinuxFr.org au sujet d'OpenMW datant de près de 3 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 supportées, 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 : le support 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 shaders, pour ajouter un brouillard :


Ou, comme dans les jeux modernes, le support du 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 bug tracker a également migré là-bas, et le wiki est en train de l'être. Pour ceux et celles 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 bugs idiots et amusants, qui sont petit à petit corrigés, ne laissant que le souvenir d'avoir connu tel ou tel bug, 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, …

Nouvelles fonctionalités

Le but de la version 1.0 est une compatibilité totale avec Morrowind (sauf pour les bugs aberrants évidement), 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és 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'emergence 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-map, 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 qu'on cherche.

La partie audio du jeu a été améliorée, supportant l'ensemble des formats acceptés par FFmpeg, et les filtres d'effets, 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, est 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 pull-request massive ajoutant plusieurs milliers de lignes de code et des dépendances, afin d'améliorer drastiquement le pathfinding, à coup d'autogénération, produisant au passage de belles visualisations:

Une des choses que j'aime beaucoup dans Morrowind, c'est qu'il s'agit un formidable RPG 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 forkant le projet, et en implémentant une version multijoueur de Morrowind, qui fonctionne !

Support 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 nexusmod et ses plus de 5000 mods disponibles. Évidement, OpenMW a vocation à être compatible avec l'ensemble d'entre eux, et les bugs de ce coté-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 restorer 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'annecdote, 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, … rendant parfois les mods incompatibles entre les différentes traductions.

Originellement, la création de mods s'effectue 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/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 brosse : 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 laisse 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 10 ans, et tend de plus en plus vers sa version 1.0.

Disponible et empaqueté pour de multiples OS, 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

Jeudi 2 Août

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, 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 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 reconnaitre 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énements 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 que issus des outils plus 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

Jeudi 2 Août

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, c'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 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é 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 et 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 !

Mercredi 1 Août

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 le 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)

Mercredi 1 Août

Le 28 juin 2018, le site LinuxFr.org fêtait ses 20 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 5 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 20 ans ? Le Libre dans 20 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 : 15 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 10 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 6 ans, ça c'est sûr, donc… avant ? Probablement lors de ma découverte tardive de Linux, en école d'ingé, grâce à un sympatique 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 ordi 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-sujets, 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 meta-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 leurs contenus 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/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és d'une partie de leur contenu.

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

devnewton : J'aimerais lire plus de contenus dédiés 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 ?

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 bugs, parfois avec un patch, 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 les emails, 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 paraitre je prendrai 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 20 ans ? Le Libre dans 20 ans ?

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

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

devnewton : Dans 20 ans LinuxFr.org sera un site rencontre 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 20 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 ce sera professionnalisé pour devenir une industrie, mais l'esprit du libre vivra dans des petits groupes dont LinuxFr.org fera partie :-)

vejmarie : oula 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

Mardi 31 Juillet

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

Mardi 31 Juillet

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

Lien vers l'article original: https://www.zdnet.fr/actualites/de-linux-a-windows-une-partie-de-l-allemagne-bascule-39871733.htm

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».

Lien vers l'article original: https://www.nextinpact.com/news/106898-le-gouvernement-lance-etats-generaux-nouvelles-regulations-numeriques.htm

[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.

Lien vers l'article original: https://www.podcastjournal.net/Contre-le-monopole-des-GAFAM-le-logiciel-libre_a25566.html

[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.

Lien vers l'article original: https://www.zdnet.fr/actualites/libreoffice-sur-le-microsoft-store-the-document-foundation-denonce-39871641.htm

[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.

Lien vers l'article original: https://www.developpez.com/actu/215961/Explosion-des-prix-de-Google-Maps-le-departement-de-Maine-et-Loire-abandonne-Google-pour-OpenStreetMaps-un-service-de-cartographie-open-source

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.

Lien vers l'article original: https://www.zdnet.fr/blogs/l-esprit-libre/peertube-l-hebergement-libre-de-videos-est-sur-les-rails-39871579.htm

[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.

Lien vers l'article original: https://www.miroir-mag.fr/technologie/six-cliches-qui-vous-empechent-de-vous-mettre-au-logiciel-libre

[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.

Lien vers l'article original: https://www.zonebourse.com/ITS-GROUP-5096/actualite/ITS-Le-DevOps-ndash-la-prise-de-pouvoir-de-l-rsquo-Open-Source--26978275/

[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 ?

Lien vers l'article original: http://www.liberation.fr/france/2018/07/22/contre-google-cherchez-encore_1668138

Et aussi:

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Elixir, Phoenix et Membrane

Lundi 30 Juillet

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

Elixir

Elixir est un langage de programmation fonctionnel 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, résistants 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 build, hex, le gestionnaire de packages, et iex, la console interactive. ExUnit, le framework 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 framework 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 plateforme Erlang : ses temps de réponses 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édia. 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é.

NdA : 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

Samedi 28 Juillet

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 FedoraMageiaUbuntu, 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++ ?

Vendredi 27 Juillet

Le C++ est 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, quel 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. Par contre, 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/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 pertinent.

    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 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 soft (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 toutes façons, ce n'est pas vraiment la rapidité des changements de la norme qui sont impactant, c'est la vitesse de conformance des compilateurs.
    Si c'est lent, les fonctionnalités vont prendre du retard avec les langages comme C#, Rust,… 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 20 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/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 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 toutes les avantages de la standardisation. Si 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 = 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 a jour du C++, soit on utilise une API a jour fournie par une lib. Dans les 2 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 a ce que les compilateurs puissent fournir des mises a jour du protocole sans que le standard 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 OS (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 meilleur 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 ligne de code (o(L1.2 ), cf Cocomo). La liste des bugs les plus fréquents en C / C++ qui sont toujours les mêmes (NULL, off by one, buffer overflow, allocation/désallocation mémoire, mauvaise gestion d'erreur, etc.), et qui n'existent pas dans les langages plus récents.
    gbdivers:
    L'argument sur les avantages que peuvent 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… heu… 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 bug de mémoire (segfault, overflow) il est peu pertinent d'attaquer le code haut niveau, qui peut représenter le plus gros (avec pleins de règles métier ajoutées au fil du temps). Personnellement, de ce que je sais, la complexité cyclomatique de Mc. Cabe 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) dont j'ai personnellement tiré pas mal de leçons. Le problème des under/overflow 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 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 workaround 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 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é ? Exemple du python2 vs python3 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 flag 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 flag, 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 sacrer bonne raison. C++n-1 sera toujours « good enough » pour beaucoup.
    gbdivers: pour le flg, je sais pas trop. Toujours est-il que je suis d'accord. Je pense que l'exemple de Python2 vs Python3 (et plus précisément la lenteur d'adoption de Python3) est un bon exemple concret que ne pas assurer la rétro-compatibilité du code peut ralentir l'adoption de la mise a jour.
    freem: compte tenu de la vitesse d'évolution du C++, si 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 à bien moins de fonctionnalités tout en offrant des performances comparables et moins de sécurité).
    Pour parenthèse, l'obsolescence de auto_ptr à dû être faite dans la douleur et dans le constat que c'était de toute façon peu utilisé (il suffit 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 raison liées à des bugs?

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

    Nicolas Boulay: nécessité d'un check 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, libs, outils de vérifications, bonnes pratiques, apprentissage.
    freem: la compatibilité avec le C est l'un des arguments forts pour pousser le C++, et le support 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 migrer un code C, qui par défaut n'offre strictement aucun contrôle automatique de la bonne gestion d'une ressource partiellement au C++, 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 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, à 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ées comme en Java. J'ai un très mauvais souvenir également de l'usage de C en C#, ou 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 dû à, je me répète, la RAII.
    en revanche, si on parle d'apprendre le C++ en venant d'un autre langage, c'est vrai que ce n'est pas trivial, surtout si on veut jouer avec les couches basses.

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

    lmghs: J'imagine qu'on liste ici les 3 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 utilisateurs et pythonisants dès le début: auto, for-range-loop, lambdas pour algo 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 de savoir si les formés vont travailler sur un centos6, ou pire 5, ou un 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, par contre 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 a 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 10 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 connait/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.X
    gbdivers: je n'ai pas suivi le C11, si ces syntaxes sont encore valides ? A priori, le C++11 (ou 14?) est sense se base 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, beaucoup de syntaxe 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 a l'apprenant. Résultat : complexité à comprendre et moins bonne maitrise 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 2, et les temps de compilation du projet sur lequel je travaillais par 3. 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 plus lentement que visual c++ aussi. Alors ce problème de lenteur, ne serait-il pas du, au final, à un problème de qualité de gcc (passage à enlever sauf si publication un trolldi hihi)? Concrètement, gcc utilisait un GC en C, et il y a quelques années (après ma découverte de clang en tout cas) ils ont parlé de réimplémenter certains passages en C++ justement pour réduire la nécessité de ce GC.

    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 pour C++20.

    Alors, faut-il tout effacer et recommencer un nouveau langage qui par design prend en compte les contraintes de concurrence (multi-core, 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 bugs).

    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 Garbage Collector et suivent le dispose pattern pour les autres ressources, voire ils offrent des facilités équivalentes au RAII (try-with-resources en Java 7, using en C#, etc). Certains estiment que si on ne profite pas de ces fonctionnalités, mieux vaut utiliser un autre langage.

    freem: mais justement: les GC, ç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 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 GC 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 GC nettoie tout… bref, le GC à 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 ;

    Parmi ces langages, en excluant ceux qui ne sont qu'interprétés et ceux qui utilisent un garbage collector, les seuls qui pourraient remplacer C++ à performances égales sont donc C, Rust et D.

    gbdivers: pourquoi exclure les interprétés et les GC? Ça serait l'occasion de tordre le cou a un mauvais argument sur le C++ : les performances. On attend souvent "je veux faire des jeux vidéo, on m'a dit qu'il fallait 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 structures de données. Il vaut mieux n'importe quel langage correctement utilise que le C++ mal utilisé)

    wilk Peut-être préciser ce qu'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 utilise que le C++ mal utilise" : argument valable pour tous les langages. Pour tirer le maximum de perfs de la machine physique, il ne faut pas de GC (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, gros lag ! ) ni, bien sûr, de langage interprété (perte de perfs liées à la VM)
    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 a 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 GC, 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 on sait tirer le meilleur de la machine. Mais combien sont capables de faire cela ? Et on a le temps de faire cela sur un vrai projet ? C'est dans ce sens la que je dis que les performances ne sont pas toujours un bon critère.
    Nicolas Boulay: Pour prendre un exemple, je serais 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 (ASM ou appel de fonction externe).
    gbdivers: oui, mais tu reconnaitras 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 dans 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, ou 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 à mallocs inutiles). Et ce sont les bases pour écrire un code rapide en C++.

    Nicolas Boulay -> tous les moteurs de jeux (unity3D, …) sont écrits en C++, par contre la logique des jeux eux-mêmes sont en javascript, en C#, en lua… En gros, cela demande moins d'effort 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é ;
    • Facile à débogage (déverminage) ;
    • Facile d'augmenter un programme ;
    • Une communauté, des meetups, des entreprises ;
    • Une galaxie de sites webs, d'outils divers, des bibliothèques, des tutoriels, de la documentation…
    • 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 :

    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 objet 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.

    Par contre, il n'y a pratiquement aucune aide à la gestion d'erreur, bien que C++11 ait introduit static_assert. Les messages d’erreur 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. Voire à ce sujet la présentation de Roland Block donnée lors des CppCon 2015 : Pruning Error Messages From Your C++ Template Code (slides). À 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 fuites mémoires, use after free, 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 aujourd’hui reste inférieur en termes d’écosystème (SIMD, multicore / 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 sommes et le pattern matching de type est ajouté, que les pointeurs soient vu comme des types sommes avec détection des "call 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 thread, et pour un éventuel garbage collector, 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 pour être compliqué pour se conformer à la nouvelle bonne pratique ;
    • les différentes bibliothèques utilisées ne sont pas forcément toutes homogène 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 courant 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 mutex et autre locks, des 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> la méthode lock/thread est une méthode qui engendre un paquet d'erreur (race condition, priority inversion, dead lock, …) , un cerveau humain normal a trop de mal avec ces paradigmes. Ce qui semble marcher est le message passing (Erlang, Qt, …), surtout si on sait faire du "zéro copy" (linear programming).

    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'a pas de solution triviale. Chaque développeur/ou chaque projet gère du coup cela à sa façon avec potentiellement des erreurs et sans capitalisation au sein de la communauté C++.

    La gestion de dépendance / portabilité / build / reproductibilité

    Note de modération : paragraphe à travailler, je jette des idées en vrac

    La gestion de dépendance 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ême numéros de version, même paramètre 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 source, …) livrée peut être livré facilement sur une machine cible non maîtrisé. En gros, qu'ils viennent 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_(package_manager), Haskell avec Stack_(software), etc. Ces outils permettent de construire son programme dans un environnement restreint en fournissant toute ou parties des garanties listées au-dessus.

    À ma connaissance, il n'existe pas d'outil multi-plateforme de ce type en C++, ainsi chaque bibliothèque vient avec sa propre méthode de compilation / installation non générique et le packaging d'un programme revient souvent à faire soi-même, à la main, le build de toutes les dépendances dans un répertoire dédié du projet, ce qui devient fastidieux quand on cherche aussi à s'assurer du numéro de version des outils de compilation utilisées.

    lmghs -> Il existe conan.io qui veut fédérer les choses, et Nuget sous windows. A 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 packet, comme Chocolatey, mais rien de suffisamment robuste / exhaustif permettant de choisir les versions exactes des bibliothèques / outils.

    Sous linux, chaque distribution propose son gestionnaire de packet, 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égers comme Docker et installer une distribution linux spécifique avec un ensemble de packets 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 la… 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 de l'OS ça. Enfin, de la distribution autour de l'OS.
    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 build 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 autres ou pratiquement :

    • Une manipulation bas niveau voir très bas niveau (du fait de sa proximité avec le langage C aujourd'hui majoritairement utilisée 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 machine de von Neumann, mais si on veut des performances, il faut aller plus loin).
    • Il a évolué plus que tout autres langages 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 logiciels.
      • Une capacité haut niveau tout en restant extrêmement performant qui n'a pas d'équivalent. C'est ce que lui envient entre autre le Go ou le Rust.
    • Les Système_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:/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] https://github.com/MercenariesEngineering/openexrid), etc., sont fournis sous la forme de bibliothèques C++. Bien que des Bindings vers d'autres langages existent, ceux-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 industrie. De façon amusante, on dit souvent que des langages comme python servent à faire la glue sur les entrées d'un programme et que le cœur est écris dans un langage plus "sérieux" type C++. Nous on aurait plutôt tendance à vouloir utiliser du Rust / Haskell pour le cœur et à utiliser C++ pour la glue 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 font 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 haut niveau (Python, PHP, Ruby ou autre). Puis viens un moment ou 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 / 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 longues. En C/C++ un bug peut survenir sur un détail difficile à identifier là ou 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 a jour les dernières évolutions du code ne vont pas perturber le fonctionnement en place. Autrement dit, il est difficile de savoir entre 2 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 complexe 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'utilisateur 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

    Pages