Syndiquer le contenu
Mis à jour : il y a 12 heures 38 min

CatchChallenger en 2017

8 novembre, 2017 - 16:23

CatchChallenger est un jeu de rôle indépendant en ligne massivement multijoueur (MMORPG) à l’ancienne entièrement libre : licence GPL v3 pour le code, comme les données (artwork), ou le site.

La base du jeu est un mélange de différent styles : combat, farming, exploration, fabrication, commerce, gestion, compétition. Le travail est concentré sur la jouabilité, les performances et la créativité.

Cette version totalise plus de 10 Mio de code, plus de 3 000 commits avec 400 000 lignes sur cinq ans de vie (sur les différentes parties du projet). Le client et le serveur sont développés sous GNU/Linux, puis automatiquement empaquetés pour macOS et Windows.

Le jeu

Les joueurs peuvent interagir comme pour n’importe quel MMORPG : parler, échanger ou vendre des objets, combattre, faire des équipes. Les PNJ servent pour mettre de l’ambiance, faire des quêtes, vendre, acheter, stocker, combattre. Le système de looting est assez simple, à la fin de chaque combat, on a X % de chance de recevoir X à Y objet(s).
Le système de quêtes est basé sur du texte (très proche de lineage), on doit faire des combats, apporter des objets, parler à des PNJ, gagner en réputation ou terminer des quêtes. Cela donne comme récompense : de la réputation, des items, accès à d’autres zones.
Le système d’XP est basé sur les combats gagnés, il y a un système de SP qui permet d’apprendre des compétences ou d’améliorer les niveaux des compétences (skills) déjà acquises. Ce système de SP peut être désactivé côté serveur.
Il y a un système de farming de plante, de crafting, une économie très évoluée, de type X3 (industrie, cycle de fabrication).

Depuis la dernière version

Des outils de contrôle de qualité ont été mis en place sur la grappe de serveurs (temps de fonctionnement « uptime », alerte, test d’accessibilité à divers niveaux, automate pour simuler les joueurs). La haute disponibilité a été améliorée. Auto‐cicatrisation de la grappe de serveurs, auto‐correction des bogues mineurs.
Beaucoup de bogues ont été résolus, car les méthodes de recherche sont plus poussées et il y a plus de cas de tests.
Un générateur de mapsm qui est basique pour l’instant.

Le projet est toujours à la recherche d’aide pour le client :

  • un développeur HTML5/WebSocket/WebGL.
Les projets liés

Le projet de datacenter personnel, diverses recherches sur les protocoles sont en cours.
Nous avons constitué une S. A. R. L. pour travailler comme FAI et datacenter professionnel dans le cas particulier du pays où je réside (la Bolivie), qui ne dispose pas de datacenter public, ni de FAI avec l’IPv6. Nous sommes par exemple en train d’implémenter la fibre via la technologie GPON.

Concours

Nous allons ouvrir ces concours sur une durée d’un an. La somme totale à gagner est de trois bitcoins (mis de côté juste pour cela) :

  • le concours de génération de carte (map) via IA ;
  • le concours de génération de carte (map) via logiciel ;
  • le concours de bot de joueur via IA.
Télécharger ce contenu au format Epub

Lire les commentaires

Revue de presse de l’April pour la semaine 44 de l’année 2017

7 novembre, 2017 - 17:25

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

[L’ADN] Doit‐on se résigner à la surveillance numérique de masse ?
Par Nastasia Hadjadji, le vendredi 3 novembre 2017. Extrait :

« Nous sommes allés voir le documentaire Nothing To Hide de Marc Meillassoux : il évoque la surveillance numérique de masse à travers les témoignages de lanceurs d’alerte, d’activistes et de défenseurs des libertés numériques. »

[Le Monde Informatique] 7 distributions Linux surprenantes
Par Dave Taylor, le vendredi 3 novembre 2017. Extrait :

« En dehors des distributions [GNU/]Linux les plus connues, comme Ubuntu, Red Hat ou Fedora, il en existe d’autres moins renommées mais qui valent quand même le détour. Zoom sur les plus originales voire décalées. »

[Le Monde Informatique] L’Open Source investit les entreprises
Par Jean‐Philippe Levy, le mardi 31 octobre 2017. Extrait :

« Source d’innovation, évolution rapide, fonctionnalités adaptées aux besoins des métiers, l’Open Source entre de plus en plus dans les entreprises. Ces nombreux atouts séduisent non seulement les entreprises mais incitent aussi les grands éditeurs à libérer des parties de leurs codes sources. »

[LeMagIT] Code : McAfee et Symantec refusent de passer l’examen
Par Valéry Marchive, le lundi 30 octobre 2017. Extrait :

« Quitte à échouer à obtenir leur permis d’accès à certains marchés, les deux éditeurs ne souhaitent plus laisser certains gouvernements étudier le code source de produits. »

[Public Sénat] Accord Microsoft/Défense : « une question de souveraineté nationale » selon Joëlle Garriaud‐Maylam
Par la rédaction , le lundi 30 octobre 2017. Extrait :

« La sénatrice LR Joëlle Garriaud‐Maylam a fait part de ses inquiétudes au sujet du renouvellement d’un accord d’exclusivité entre Microsoft et le ministère des Armées. “C’est une question de souveraineté nationale”, “Nous n’avons pas d’informations suffisantes” s’inquiète‐t‐elle. »

Et aussi :

[Le Journal de Québec] L’industrie veut être entendue
Par Martin Lavoie, le dimanche 29 octobre 2017. Extrait :

« Se disant mieux écoutée que par le passé, l’industrie du logiciel libre réclame néanmoins une véritable ouverture du gouvernement du Québec. »

Télécharger ce contenu au format Epub

Lire les commentaires

LinuxMAO — Éditorial de novembre 2017

7 novembre, 2017 - 12:34

Novembre est un nom qui porte mal son nom. Pourquoi ? Vous le saurez dans la deuxième partie de cet article.

Cela n’empêche pas que c’est bien ce bon vieux novembre des brumes et des frimas que nous allons traverser ensemble sur LinuxMAO. Il n’y aura ni brouillard ni froid ici, juste l’habituel noyau magmatique, fait d’entraide et de partage, irradiant sa constante chaleur quels que soient les mois, les saisons et les années. N’en déplaise aux romains, à Charly et aux députés de l’an I !

Sommaire Préambule

Novembre hérite son nom du chiffre 9, novem en latin. Dans l’antique calendrier romain, c’était le neuvième mois de l’année puisque celle‐ci débutait en mars. En 1564, Charles IX promulgua l’édit initialisant l’arithmétique du temps telle que nous la connaissons, avec le 1er janvier 1565 comme point d’origine. Je t’ai ignoré, Charly, et pourtant j’aurai usé de ta trouvaille chaque jour de ma vie. Quelle ingratitude !

Novembre passa ainsi du rang de neuvième mois de l’année à celui de onzième, devenant une absurdité étymologique au même titre que septembre, octobre et décembre (7, 8 et 10). En 1792, les députés de la Convention décidèrent que l’an I de la République débuterait le 22 septembre 1792 et adoptèrent un découpage du temps d’une jolie complexité avec sextiles, bissextiles, décades et les sans‐culottides qui sont les six jours d’ajustement destinés à rattraper les décalages en fin d’année. Chaque mois ne comptait, en effet, que trente jours. Bref, une machinerie infernale, pas mnémotechnique pour deux sous, incapable de faciliter les décomptes du citoyen n’ayant connu que l’ancestral calendrier de Charly. Novembre se trouva ainsi partagé entre Brumaire et Frimaire, mois des brumes et mois des frimas.

Ce calendrier fut aboli par l’Empire, le 22 fructidor de l’an XIII (9 septembre 1805). L’expérience avait produit des résultats médiocres, elle dura à peine treize ans et prit fin le 1er janvier 1806. Charly obtint ainsi sa revanche, car c’est à nouveau son rythme qui régit le tempo universel.

Quoi de neuf ?

Depuis la parution du dernier éditorial, nous ont rejoint : Alodaf, alexchant, dmaxy, Baz, jcelerier, Anastasia.01, technomagniaque, gp4004, FLB44, fdf, oranjezhadu, lordarkrems, Christine Gallot, EIJULES, bobby12, Kuluse, C4-53, leclar, Respire, Fonky62, Gopherlechien, rosjjim, Upal, Burnus_1er, Odysseus Libre, yomboul, Soss, BaguetteAgile72, Oscardici, popayann, Valtena, yannboc, lemaitresantos, fourat, Lysergik et aletheia.

Bienvenue à vous toutes et tous !

Les entretiens sont relancés après plusieurs années de silence radio. Pour inaugurer cette renaissance, sub26nico a soumis des questions à bluedid29, vous pouvez lire ses réponses dans la nouvelle : Les entrevues de LinuxMao-bluedid29.

Musique sur linuxmao

La douzième joute de LinuxMAO se clôt sur la victoire d’olof. Compliments !
Les participants devaient livrer leurs interprétations autour du thème imposé : Cuba.
Ce fut une joute riche et très diverse. Les sept participants nous ont laissé entendre chacun sa sensibilité, chacun sa technique et chacun sa façon singulière d’aborder le thème.
Quand aux styles musicaux, ils couvrent, une fois encore, un vaste territoire qui va du R’n’R à la manipulation conceptuelle de matière sonore audio‐numérique.
Aucun n’a démérité, tous ont travaillé d’arrache‐pied et méritent félicitations et encouragements.
ProgramLyrique a piloté avec brio le vaisseau amiral, collecté les œuvres et dépouillé les votes, nous livrant le résultat final dès son retour de Chine. Un grand merci !

Rappelons ici que chaque participant aux joutes met sa sensibilité et beaucoup de son temps en partage.
Les votes et commentaires n’ont pour seul objet que la mise en évidence de points techniques perfectibles, jamais la mise en cause de styles, de parti‐pris créatifs ou de sources d’inspiration.

Dernière minute : olof ayant remporté deux joutes, ce n’est pas au vainqueur de choisir le thème de la treizième joute mais à l’organisateur. ProgramLyrique vous invite donc à participer autour du thème : Qi Gong sur gratte‐ciel.

Autres productions musicales :

Musique libre en dehors de LinuxMAO

Liste de lecture des nouveautés pour le mois d’octobre 2017 chez les copains de Dogmazic.

Nouvelles du monde

Le manuel d’utilisation des logiciels d’openavproduction (luppp, sorcer, artyfx et fabla) a été traduit en français. Voir à ce propos cet article du blogue de LibraZiK.

La dixième édition des Journées méditerranéennes du logiciel libre (JM2L) se tiendra le samedi 25 novembre 2017 au Technopole Sophia Antipolis à Biot (06). Notez la présence d’une salle entière consacrée à la MAO sous GNU/Linux avec des ateliers d’utilisation, une conférence autour la programmation d’applications MIDI sous GNU/Linux, une conférence autour de l’utilisation de MuseScore, et une autre conférence sur l’improvisation musicale avec GNU/Linux sur le film d’animation ZeMarmot. Toutes les informations sur le site de linux-azur.org.

Nouveautés sur LinuxMAO

Des chiffres :
Le nombre de visiteurs uniques du mois d’octobre 2017 est de 39 807 ce qui constitue le nouveau record de fréquentation du site avec une moyenne de 2 279 visiteurs uniques par jour. linuxmao.org, c’est à ce jour, 6 203 utilisateurs inscrits, 2 259 pages de documentation, les plus de 82 300 messages dans les « forums », et d’autres fioritures.

D’autre part, nous avons eu 36 nouvelles inscriptions depuis la rédaction du dernier éditorial du site, c’est à dire en 33 jours.

Nouvelles pages :

Côté administration :

  • nettoyage et amélioration de l’intégration des pages du portail développeur ;
  • il y a eu un problème avec les membres inscrits avec une adresse en yahoo.fr vers le 14 ou 15 octobre. Les notifications envoyées par le site semblent avoir été interprétées comme du pourriel et ont donc été refusées par Yahoo. Ça semble avoir été rétabli à présent. Voir le fil de discussion : comptes avec adresse yahoo.fr.
Côté logiciel sur LinuxMAO Côté logiciel en dehors de LinuxMAO

Depuis la publication du dernier éditorial, olinuxx, sub26nico, r1 et Nolwen ont relevé les mises à jour suivantes pour ce mois‐ci :

  • après 12 ans de silence (oui, douze ans !), Gnuitar sort en version 0.4.0alpha ;
  • nouvelle version 3.2.2 de DRC ;
  • Aubio passe en version 0.4.6 ;
  • Guitarix2 mis à jour en version 0.36.0 ;
  • Bitwig Studio passe en version 2.2 ;
  • Rivendell passe en version 2.17.0 ;
  • UbuntuStudio 17.10 est disponible ;
  • nouvelle mise à jour pour la Vee One Suite en version 0.8.5 ;
  • Fluidsynth passe en version 1.1.8, ajoutant entre autres le support pour la lecture des banques de son au format SF3 ;
  • zam-plugins passe en version 3.9 ;
  • praxis live passe en version 3.3.0 ;
  • VCV rack passe en version 0.4.0 ;
  • OcenAudio passe en version 3.3.1 ;
  • LMMS voit une nouvelle version « release candidate » 1.2-rc4 poindre le bout de son nez .
  • Audacity passe en version 2.2.0. Nouveau logo, quatre thèmes pour l’interface (dont un pour les malvoyants), une refonte des menus et des préférences. À noter que la liste de discussion Audacity-French hébergée par Yahoo! va disparaître, remplacée par la liste hébergée par Framalistes ;
  • Open Stage Control est maintenant en version 0.21.1 ;
  • abGate passe en version 1.1.9.
Post‐scriptum

Merci à sub26nico, olinuxx, allany et r1 pour l’écriture de cet édito, et on se retrouve le mois prochain pour une revue de l’actualité du mois écoulé !

Bonne musique à toutes et tous !

Télécharger ce contenu au format Epub

Lire les commentaires

Conférence GStreamer 2017 : Oxydation de GStreamer

7 novembre, 2017 - 00:43

Rustifiez votre multimédia !
Voici une traduction de la présentation Oxidising GStreamer — Rust out your multimedia!, qui a eu lieu le 22 octobre 2017 à Prague dans le cadre de la Conférence GStreamer 2017.

Merci à Sebastian Dröge pour cette présentation et pour son autorisation de traduction.

  

Sommaire Résumé

Dans la suite logique de ma présentation de l’année dernière, je vais vous tenir au courant de ce qu’il s’est passé depuis autour de GStreamer pour le développement d’applications et d’extensions en Rust.

C’est maintenant le bon moment pour utiliser Rust dans le cadre de vos développements GStreamer au lieu du C ou du C++ et même à la place de Python ou de C#. Vous bénéficierez ainsi de plus de sûreté, d’une meilleure productivité et pourquoi pas d’un certain plaisir à développer, tout en conservant un haut niveau de performance et un faible surcoût qui ne se rencontrent généralement qu’en utilisant le C ou le C++ et avec en plus la possibilité d’exécuter votre application sur des équipements embarqués.

Alors que l’apprentissage d’un nouveau langage peut sembler superflu et qu’il y a trop de langages de nos jours, je vais vous montrer pourquoi vous devriez vous en préoccuper et pourquoi le langage en question semble être un candidat parfait pour les applications multimédias et pour plein d’autres cas d’utilisations sur environnements embarqués. Je vais vous indiquer comment vous mettre le pied à l’étrier et vous présenter quelques courts exemples de code.

Sebastian Dröge est un développeur de logiciels libres et l’un des mainteneurs et développeurs principaux de GStreamer. Il est impliqué dans le projet depuis plus de dix ans. Il contribue également à plusieurs autres projets tels que Debian, GNOME et WebKit. Après son _master en sciences des Systèmes d’Information à l’Université de Paderborn en Allemagne, il commence à travailler en tant qu’entrepreneur autour de GStreamer et des technologies connexes. Sebastian est l’un des fondateurs de Centricular, une société proposant des services de conseil. Depuis son nouveau domicile en Grèce, il travaille à l’amélioration de GStreamer et de l’écosystème du logiciel libre en général._

En plus des sujets relatifs au multimédia, Sebastian s’intéresse au traitement numérique du signal, aux langages de programmation, à l’apprentissage automatique, aux protocoles réseau et aux systèmes distribués.

Introduction, Qui ?

Aujourd’hui, nous allons parler de l’oxydation de GStreamer ou comment « rustifier » votre multimédia. Je suis Sebastian Dröge, je participe au développement de GStreamer depuis 2006 environ. Actuellement, je suis en charge de la préparation des versions. J’ai touché à pratiquement tout dans GStreamer. Je suis aussi l’un des cofondateurs de Centricular. Nous proposons du conseil autour de GStreamer et des logiciels libres de cette catégorie. C’est tout ce que j’ai à dire à mon sujet, passons au contenu.

Quoi ?

Je vais vous parler de Rust et de GStreamer. Je suppose que certains d’entre vous ne connaissent pas Rust, je vais donc commencer par une courte introduction. Si vous souhaitez approfondir, rendez‐vous sur le site Web, la documentation est de très bonne qualité. Je ne vais pas vous expliquer ce qu’est GStreamer, je pense que vous le savez déjà.

J’ai déjà eu l’occasion de vous parler de ce sujet l’année dernière, je vais donc évoquer ce qu’il s’est passé depuis, puis entrer un peu plus dans les détails sur la manière de développer des applications et des extensions GStreamer avec Rust. Je vous montrerai aussi quelques exemples de code. Enfin, je vous parlerai de ce à quoi on peut s’attendre pour l’avenir.

Qu’est‐ce que Rust ? Définition

C’est « un langage de programmation système qui vise à garantir un typage sûr et une gestion sûre de la mémoire ». Les développements ont commencé chez Mozilla. Tout est open source. De nos jours, le langage bénéficie d’une large communauté et une bonne proportion des développeurs n’est plus employée par Mozilla. C’est une communauté assez diversifiée. La conception du langage suit les pratiques du développement open source. Ils utilisent un processus d’appel à commentaires (Request For Comments) pour toutes les modifications du langage. Chaque membre de la communauté peut apporter des éléments à la discussion, c’est très transparent… ça me plaît bien !

Qu’est‐ce que ces mots signifient au juste et plus particulièrement « gestion sûre de la mémoire » ? En fait, c’est un peu l’argument de vente de Rust. On sait tous ce qui peut arriver en C, si on déréférence le mauvais pointeur ou si l’on dépasse les limites d’un tableau : le truc part à veau‐l’eau. Rust empêche cela. Le typage est aussi beaucoup plus sûr qu’en C. Le C apporte un peu de sécurité pour le typage, mais bon… passons !

Selon moi, la caractéristique la plus importante est qu’il s’agit d’un langage de programmation système. Il travaille vraiment près du matériel, il n’y a pas de gros environnement d’exécution. Tout ce que vous écrivez tourne vraiment sur le processeur. Toutes les abstractions que le langage propose sont sans surcoût, du moins c’est la manière dont ils en font la pub, et je le crois aussi. Mais je dirais que c’est à vous de le vérifier par vous‐même.

Une autre caractéristique importante est l’existence d’un système très puissant permettant l’interopérabilité avec des bibliothèques écrites en C. Quel que soit l’existant écrit en C dont vous disposez, vous pouvez l’utiliser depuis votre code écrit en Rust.

De la programmation bas niveau avec un air de programmation haut niveau

Si vous regardez le code, cela ressemble parfois à ce que vous écririez en JavaScript ou en Python ou avec un autre langage d’orchestration (scripting). Ça peut sembler de plus haut niveau que ce que vous obtiendriez en C++. Néanmoins, on parle bien de programmation bas niveau : vous conservez le contrôle sur tout si vous le souhaitez. Vous pouvez décider d’où allouer la mémoire — doit‐on utiliser le tas ou la pile — de quand allouer, de quand désallouer. Mais l’important, c’est que vous n’avez pas à vous en soucier. Vous pouvez le faire… vous pouvez aussi, dans une certaine mesure, l’ignorer. Ça n’implique pas une gestion manuelle de la mémoire, c’est le compilateur qui s’assure que vous n’êtes pas en train de faire quelque chose de stupide.

Comme je l’ai dit, Rust ressemble un peu à Python ou à d’autres langages d’orchestration. L’une de ses caractéristiques importantes est l’inférence de type : vous n’êtes pas obligés de préciser systématiquement le type des variables. Généralement, le compilateur se débrouille tout seul, tout en vous garantissant un typage sûr. C’est quelque chose dont le C++ dispose aussi aujourd’hui. Vous avez également d’autres caractéristiques que l’on trouve plutôt dans les langages d’orchestration ou les langages fonctionnels, mais qui sont disponibles pour de la programmation système.

Domaines

Rust est actuellement utilisé pour :

  • du développement d’applications Web. Qui essaierait de développer des applications Web en C aujourd’hui ? Personne ? En revanche, vous pouvez en écrire en Rust ;
  • on l’utilise aussi pour le développement de jeux, la programmation de serveurs, etc ; en gros, tous les domaines pour lesquels vous utiliseriez le C++ ;
  • des gens écrivent aussi des systèmes d’exploitation en Rust, il y en a actuellement deux ou trois en cours d’écriture ;
  • certains l’utilisent pour des développements vraiment très proches du matériel, comme de la programmation de micro‐contrôleurs.

Rust couvre tout le spectre des cas d’utilisation pour lesquels vous utiliseriez un langage de programmation système.

Par ailleurs, Rust est désormais utilisé et poussé par des acteurs de l’industrie. Vous pouvez consulter cette page pour découvrir les sociétés qui déclarent publiquement utiliser Rust. Il y a des noms tels que Dropbox, npm, Atlassian, Coursera, Canonical et bien d’autres.

Rust est ce que le C++ aurait dû être

Selon moi, Rust est ce que le C++ aurait dû être. Bon, un certain nombre d’années se sont écoulées, les gens ont appris de l’histoire. Aujourd’hui, je l’utiliserais pour n’importe quel projet pour lequel j’aurais utilisé le C++ ou même le C auparavant.

Pourquoi Rust ? De la difficulté d’écrire du code sûr en C et en C++

Il est difficile d’écrire du code sûr en C et en C++. Toute personne pouvant dire qu’elle n’a pas subi d’erreur de segmentation durant l’année écoulée n’a probablement programmé ni en C, ni en C++. Vous pouvez facilement faire quelque chose qui fera planter votre système et permettra à un attaquant de prendre le contrôle de la machine de l’utilisateur, sans même vous rendre compte que ce que vous avez écrit n’est pas sûr.

La gestion des erreurs est plutôt compliquée avec ces deux langages. En C, on s’arrange généralement avec les valeurs de retour, vous pouvez facilement les ignorer et personne ne s’en offusquera ! Ça va juste échouer à l’exécution avec des symptômes bizarres. En C++, vous avez bien les exceptions, qui bénéficient de leur propre lot de problèmes. En général, ça entraîne une certaine verbosité qui finit par masquer ce que le programme fait vraiment et rend la tâche encore plus difficile pour faire en sorte que le code soit sûr.

Laissez le compilateur vous aider à écrire du code correct et rapide

Il y a un inconvénient à cela : le compilateur risque de beaucoup se plaindre ! Il vous dira des choses comme : « non, tu ne peux pas faire ça, ce n’est pas sûr ». Ça va vous prendre plus de temps avant de pouvoir exécuter votre code. Mais une fois qu’il s’exécute, vous savez qu’un gros paquet de problèmes ne vont pas se présenter parce que le compilateur vous aura déjà prévenu : « ici, ici et là, tu ne peux pas faire ça, tu devrais faire ça autrement ». Avec le C ou le C++, en général, on fait cela à l’exécution et on sait tous combien il est pénible de déboguer des trucs à l’exécution.

Rust utilise un modèle très puissant de possession et de mutabilité. Il identifie en permanence le possesseur d’une variable et trace si celle‐ci est accessible en lecture seule ou en lecture et en écriture. Par défaut, toute variable est accessible en lecture seule. C’est le contraire de ce que font les C et C++. Avec ces langages, vous pouvez préciser qu’une variable est constante, mais par défaut elle est visible en lecture et en écriture. Rien qu’avec cette approche (chaque variable en lecture seule par défaut) le code est déjà plus sûr et il est plus difficile d’introduire des bogues.

Par défaut avec Rust, le code doit respecter les contraintes de sûreté. Ce qui veut dire que si vous ne sortez pas du bac à sable, votre programme ne plantera pas… Du moins, il ne produira pas d’erreur de segmentation. Vous pouvez toujours introduire des erreurs de logique qui feront que votre programme ne fera pas ce qu’il était censé faire, mais au moins il ne plantera pas.

On bénéficie aussi d’une certaine sécurité pour les fils d’exécution. Vous indiquez si votre type de donnée est sûr pour le partage entre fils d’exécution et/ou s’il peut être transféré d’un fil d’exécution à l’autre. Le compilateur se chargera ensuite de vérifier que ces contraintes sont bien respectées.

Comme je le disais dans la section relative aux erreurs, Rust vérifie la bonne prise en compte des erreurs. Vous ne pouvez pas ignorer les erreurs, vous devez les gérer. Mais la mécanique qui permet de le faire est telle que ça en devient sympa. Ça n’a rien à voir avec ce que l’on doit faire en C : « si ceci échoue, nettoie ceci et sors, si ceci échoue, nettoie cela et sors »… Dans le cas de Rust, c’est vraiment pratique à utiliser.

L’issue de secours : unsafe

Il y a une issue de secours : le mot clé unsafe. Dès qu’il introduit une section de code, vous pouvez faire ce que vous voulez dans cette section, comme vous le feriez en C. Vous pouvez déréférencer des pointeurs, vous pouvez créer des pointeurs à partir de nombres, tout ce qui vous passe par la tête. L’idée principale est que c’est déclaratif. Vous savez alors que vous avez une petite partie de votre code qui n’est pas sûre. Si ensuite votre programme plante, ça viendra de là ! Et si vous voulez relire votre code, vous saurez que ce sera par là qu’il faudra commencer.

Un langage de haut niveau qui n’est pas juste une glorification de l’assembleur

… comme c’est le cas pour le C.

Une autre différence notable par rapport au C est que Rust dispose d’une bonne bibliothèque standard. Elle contient tout un tas de structures de données. On sait tous qu’en C, la bibliothèque standard ne comporte aucune structure de données. Chacun développe ses propres listes chaînées, ses propres tableaux associatifs. La bibliothèque standard de Rust fournit des implémentations très efficaces de toutes les structures de données, d’algorithmes, etc.

Avec tous les langages d’orchestration récents, on trouve des petits outils pour récupérer les dépendances. Pour Nodes.js vous avez npm, pour Python il y a pip. Rust propose la même chose, vous pouvez facilement dire : « je veux telle et telle bibliothèques » et l’outil ira chercher les versions dont vous avez besoin, les compilera et les inclura lors de la construction de votre propre logiciel. Cet outil facilite vraiment l’utilisation des dépendances externes. Ça ne tourne pas au cauchemar comme en C ou en C++ où chaque chose fonctionne à sa manière et où il est très difficile de dépendre de quoi que ce soit. En fin de comptes, ça a poussé pas mal de bibliothèques en C et en C++ à réimplémenter plein d’algorithmes qui existaient déjà partout ailleurs… Mais bon, c’est tellement compliqué de tirer ces dépendances que l’on réimplémente les fonctions nous‐mêmes.

Pourquoi devrait‐on s’en préoccuper ? L’analyse syntaxique de formats de médias

… venant de sources non sûres.

Je passerai assez vite sur le sujet, nous sommes déjà tous au courant des problèmes. L’analyse syntaxique (parsing) des formats multimédias n’est pas chose facile, particulièrement en C ou en C++. Par ailleurs, les données en entrée viennent rarement de sources de confiance. Certaines sources peuvent même proposer des médias qui contiennent intentionnellement quelque chose qui peut nuire à votre machine en exploitant des problèmes dans les logiciels que vous utilisez. C’est pour cela que je pense que, pour nous, Rust serait un bon langage. Il permet d’éviter beaucoup de problèmes de sécurité courants. Tous les problèmes de sécurité que nous avons rencontrés dans GStreamer les années passées auraient pu être évités en utilisant Rust. Je pense que c’est déjà assez éloquent.

Et donc, l’analyse syntaxique est compliquée en C. Il n’y a pas beaucoup de moyens d’abstraction, alors qu’avec Rust on dispose de tout un tas de possibilités pour représenter des abstractions. Il est même possible d’écrire des grammaires formelles. Du moins, quelque chose qui ressemble à de la grammaire formelle. Le code correspondant est ensuite généré automatiquement, ce qui rend la compréhension de ce que fait ce code vraiment aisée en comparaison à du code écrit à la main.

La maîtrise des fils d’exécution concurrents est difficile

… surtout en C !

Rust dispose de tout un tas de fonctionnalités pour nous aider lorsque l’on développe dans un environnement à plusieurs fils d’exécution. GStreamer exploite massivement les fils d’exécution concurrents, ça pourrait donc être une bonne idée…

Programmer comme si on était en 2017

Et par‐dessus tout, nous programmerions comme si nous étions en 2017 et non dans les années 60 du siècle dernier :

  • les langages modernes offrent toute une variété de fonctionnalités et d’outils ;
  • nous ne sommes plus obligés de réinventer des ustensiles de base comme GObject ;
  • nous pourrions attirer de nouveaux développeurs. Plus personne n’a vraiment envie d’apprendre le C de nos jours et encore moins des choses comme GObject, qui entraîne plein de copier‐coller partout. C’est plutôt difficile à prendre en main pour les nouveaux contributeurs.
Cependant, ce n’est pas la panacée

Tout code non trivial comporte des bogues. Mais au moins, une importante classe de bogues peut être évitée.

État, il y a un an Les bindings GStreamer

L’année dernière, nous disposions d’un ensemble de bindings Rust pour GStreamer. Cet ensemble était écrit à la main et ne s’intégrait pas très bien avec le reste du code Rust. Par ailleurs, il imposait aux utilisateurs d’utiliser des sections avec le mot clé unsafe, ce qui est tout simplement rédhibitoire. Il divergeait aussi vis‐à‐vis de certains concepts de GStreamer, ce qui le rendait difficile à appréhender et il était incomplet. Pas mal de gens utilisaient ces bindings, mais ce n’était vraiment pas idéal.

Nous avions aussi ce dont je vous parlais la dernière fois : une manière expérimentale d’écrire des extensions GStreamer. Ce projet était également écrit à la main, il était très incomplet et difficile à faire évoluer. Oublions tout cela, nous sommes en 2017 maintenant !

Écrire des applications GStreamer avec Rust Les nouveaux bindings GStreamer Comparaison par rapport aux anciens bindings

Les nouveaux bindings Rust pour GStreamer sont en grande partie générés à partir des informations d’introspection de GObject. Malheureusement, certaines choses ne peuvent pas être générées automatiquement. Mais, globalement, ça facilite bien l’évolutivité. Ils remplacent complètement les anciens bindings. Ils ne sont pas compatibles au niveau interface de programmation, mais ça ne devrait pas être difficile de modifier un projet basé sur les anciens bindings pour qu’il utilise les nouveaux.

Une évolution importante du point de vue des applications est qu’il n’est plus nécessaire de passer par du code marqué unsafe… Sauf si le développeur le veut, bien sûr, ou s’il veut s’intégrer avec X11, qui n’est pas sûr par conception, mais c’est un autre problème !

Les nouveaux bindings couvrent pratiquement tous les composants du cœur de GStreamer, ainsi que ceux des autres bibliothèques. Ils s’intègrent bien avec les bibliothèques des infrastructures GLib et GTK, ce qui les rend sympas à utiliser ensemble.

Un style idiomatique rustien (en grande partie)

Les bindings sont écrits dans un style idiomatique rustien. Ils devraient être faciles à prendre en main par des développeurs habitués à Rust. Ils auront l’impression qu’il s’agit d’une vraie interface de programmation Rust. Et à la fois, les concepts des bindings correspondent pratiquement trait pour trait aux concepts de GStreamer. Ce qui signifie que vous, en tant que développeurs GStreamer, aurez seulement à apprendre un nouveau langage. En revanche, tous les concepts de GStreamer, c’est‐à‐dire comment l’interface de programmation fonctionne, restent les mêmes.

Les objets

Regardons rapidement quelques‐uns des points d’entrée des bindings. Dans GStreamer, nous avons tout un tas d’objets : les Elements, les Pads, le Pipeline, l’objet Clock, etc. La manière dont ils sont représentés dans les bindings est telle que vous retrouvez précisément les mêmes objets. Ils disposent d’une sorte de mécanisme semi‐automatique et sûr de comptage de références. Vous contrôlez toujours quand le compteur d’une référence est incrémenté, mais le compilateur se charge de vérifier que vous l’incrémentez bien quand c’est nécessaire. Ceci vous permet d’être alertés si vous faites des choses bizarres que vous n’auriez pas voulu faire. Donc, ce n’est pas complètement automatique, mais d’un autre côté, vous ne pouvez pas oublier de déréférencer quoi que ce soit. Quand un objet n’est plus dans la portée courante, quand il n’est plus nécessaire, il est automatiquement déréférencé et détruit au moment voulu.

Dans GStreamer, nous utilisons l’héritage. Rust ne gère pas l’héritage : il n’y a pas de classes, ni de vraie notion d’héritage. À la place, on peut utiliser des traits. Cela peut sembler un peu compliqué, un peu bizarre, mais si vous utilisez l’interface Rust, vous allez vous rendre compte qu’elle fonctionne de la même façon que si vous utilisiez, par exemple, les bindings C++ de GStreamer. Ça donne une sensation de quelque chose de naturel.

Comme je l’ai déjà dit, il y a une sorte de sûreté des fils d’exécution (thread safety) et elle est contrôlée à la compilation. Par exemple, on sait tous que les Elements de GStreamer sont censés être thread safe, on peut donc les échanger entre fils d’exécution et on peut les partager entre plusieurs fils d’exécution. Le compilateur n’ira pas se plaindre de tels agissements. En revanche, quelque chose comme GstAdapter n’est pas thread safe. Donc, si vous tentez de l’utiliser dans d’autres fils d’exécution, vous allez devoir le migrer, car vous ne pouvez pas en disposer depuis deux fils d’exécution différents. Si vous faites cela, le compilateur vous dira : « non, tu ne peux pas faire ça ». C’est une caractéristique plutôt sympa.

Vous disposez également de toute l’interface standard GObject de GStreamer. Vous retrouverez : les propriétés, les signaux, toutes les méthodes… Tout ce dont vous avez besoin.

J’aurais dû mentionner ceci auparavant : tout est garanti contre l’utilisation inappropriée de pointeurs NULL. Il n’y a aucun pointeur NULL caché. Vous devez gérer explicitement tout ce qui peut être NULL, vous ne pouvez pas ignorer ce genre de problèmes. Donc, dans toute l’interface, lorsque quelque chose renvoie un Element, il y aura bien un Element derrière. Il est impossible qu’il ne soit pas disponible. Ça ne peut pas planter ensuite, vous ne pouvez pas vous retrouver face à un pointeur NULL. Et, bien sûr, si l’appel est susceptible d’échouer, vous devez gérer ce cas. Le compilateur ne vous laissera pas utiliser la valeur retournée sans avoir vérifié au préalable qu’elle est bien valide.

Les MiniObjects

Les MiniObjects sont probablement le recoin le plus obscur de GStreamer. Ils sont générés automatiquement dans la plupart des autres bindings, ce qui les rend un peu inhabituels vis‐à‐vis du langage cible. Avec Rust c’est différent : la plupart des concepts autour des MiniObjects correspondent à ce que l’on fait déjà en Rust. Par exemple, le concept de mutabilité des MiniObjects est tel que vous ne pouvez modifier un MiniObject que s’il n’est utilisé qu’à un seul endroit à un instant donné, sinon vous devez le copier. C’est quelque chose qui trouve un équivalent direct en Rust. Le compilateur vous empêchera de modifier des MiniObjects qui ne sont pas en mode écriture. À titre de comparaison, en C on a pas mal de code qui modifie des MiniObjects alors qu’ils ne sont pas en mode écriture. L’approche de Rust me semble présenter un avantage significatif.

Les types basés sur les MiniObjects paraissent aussi typiquement rustiens. Ils comprennent les Caps, les Structures, même quelque chose comme GstFraction, qui semblait un peu bizarre à l’utilisation en Python par le passé, ressemble vraiment à quelque chose que vous auriez utilisé en Rust.

Qu’est‐ce qui manque ?

J’ai dit que la plupart du cœur de GStreamer était déjà disponible. Il manque encore :

  • GstMemory, GstAllocator, GstMeta et GstCapsFeatures, non pas parce qu’ils présentent une difficulté, mais plutôt parce que je n’en ai pas encore eu l’utilité et apparemment personne n’en a eu besoin pour le moment ; donc, si quelqu’un rencontre un problème pour lequel le besoin se fait sentir, criez, on pourra les ajouter à ce moment‐là ;
  • il manque aussi des trucs mineurs comme les TypeFinders ; ils sont du même acabit : faciles à ajouter en cas de besoin ;
  • les objets dans la catégorie des GstControlBindings ;
  • à part pour celles du cœur, les bibliothèques des autres modules ne sont pas entièrement couvertes. Mais, par exemple, pour la bibliothèque Audio, GstAudioInfo est disponible, pour la bibliothèque Video, vous avez déjà VideoInfo et VideoFrame. Il y aussi GstAdapter, AppSrc et AppSink.

Tout ce dont vous avez habituellement besoin est donc disponible et, pour le reste, criez et on l’ajoutera !

Est‐ce utilisable ? Oui !

Selon moi, tout est déjà très utilisable. Je l’utilise moi‐même pour pas mal d’applications de test afin de m’assurer que tout fonctionne correctement ou pour écrire des cas de test quand quelque chose ne marche pas. De part mon expérience, je peux dire que c’est facile et généralement plus rapide à écrire que l’équivalent en C. C’est facile à déboguer, ou du moins aussi facile à déboguer que le C. Vous pouvez toujours utiliser gdb, obtenir la pile d’appels, scruter les variables, etc. Ça marche de la même manière qu’avec du C. Et généralement, ça donne plus ou moins le même code machine que ce que vous obtiendriez avec du C. Si vous lisez ce que le compilateur produit, il est assez facile de savoir ce qui se passe, comment les correspondances avec le C se concrétisent. Donc c’est prêt à être utilisé !

Quelques exemples de code Création d’Elements

Voici un exemple de création d’Elements. Ça ne devrait pas être trop difficile à lire :

let pipeline = gst::Pipeline::new(None); // 1 let src = gst::ElementFactory::make("filesrc", None) .ok_or(MyError::ElementNotFound("filesrc"))?; // 2 let dbin = gst::ElementFactory::make("decodebin", None) .ok_or(MyError::ElementNotFound("decodebin"))?;
  • En 1, on génère un nouveau Pipeline. Ici, on ne lui donne pas de nom particulier. En C, on passerait NULL, en Rust on indique None. On récupère toujours un Pipeline. Si vous regardez l’interface en C, vous verrez que ça ne renvoie jamais NULL, donc on récupère vraiment un Pipeline.
  • En 2, on veut construire une variable src. On utilise donc gst::ElementFactory::make, ce qui est très similaire à ce que vous feriez en C. L’objectif est de créer une source sur un fichier avec l’extension filesrc. Bien sûr, il peut arriver que l’extension filesrc ne soit pas disponible sur votre machine, cette fonction est donc susceptible d’échouer en renvoyant None. Vous pouvez indiquer comment gérer les différents cas avec la fonction ok_or : « si tout est ok, alors renvoie ce que la fonction gst::ElementFactory::make a généré, sinon renvoie un type d’erreur dédié ». Pour cela, vous pouvez créer une sorte d’énumération d’erreurs et préciser les différents cas tels que ElementNotFound, à quoi vous pouvez ajouter une variable. Dans notre cas, on a indiqué le nom de l’Element. À la fin de la ligne, on trouve un point d’interrogation. Il est là pour indiquer ceci : « en cas d’échec, sors de la fonction et renvoie l’erreur en question ». L’appelant peut donc gérer l’erreur et prendre les mesures appropriées, mais dans la fonction en question on s’arrêtera là en cas d’erreur. Bien sûr, il n’y aura pas de fuite mémoire, tout ce qui doit être déréférencé et détruit le sera automatiquement.
Création de Caps

Voici maintenant un exemple de création d’un objet Caps :

let caps = gst::Caps::new_simple( // 1 "video/x-raw", // 2 &[ // 3 ("format", "BGRA"), // 4 ("width", &(1080i32), // 5 ("height", &(720i32)), // 6 ("framerate", &gst::Fraction::new(30, 1)), // 7 ], );
  • en 1, vous utilisez gst::Caps::new_simple exactement comme en C ;
  • en 2, vous indiquez le nom, rien de spécial à signaler ici ;
  • en 3, vous fournissez un tableau de propriétés qui sont en fait des tuples ;
  • en 5, je pense que ce qu’il faut retenir, c’est que vous n’indiquez pas seulement la valeur pour la propriété, vous devez aussi préciser son type. Assez souvent, c’est quelque chose qui tourne mal en C : les gens fournissent un entier non signé ou un entier sur 64 bits pour une propriété donnée et ça ne fonctionne pas comme prévu ensuite. Ici, vous devez être explicite. En interne, ça ne va pas créer d’objet GValue, si vous lisez le code généré, il sera très similaire à ce que vous auriez obtenu avec du C.

Question d’un membre du public :

— L’esperluette est nécessaire dans ce cas ?
— En fait, l’esperluette n’est pas indispensable ici. L’esperluette crée une référence, c’est comme un pointeur dont la valeur ne peut pas être NULL.
— Et donc, elle indique si ta constante est statique ou non ?
— En fait… Bon, parlons‐en après, cela nécessiterait d’entrer un peu plus dans les détails. En bref, l’esperluette introduit une référence et les références ne peuvent jamais être NULL. Le compilateur s’assure que cette valeur est toujours valide au moment où tu l’utilises. Donc, tu ne peux pas libérer ce qui en dépend, sinon ça ne sera pas accepté à la compilation. Mais, la raison exacte pour laquelle nous avons besoin d’une esperluette ici nécessiterait une explication dans laquelle je ne souhaite pas m’engager maintenant. Ça a un rapport avec le fait que chacun des éléments présente un type différent : en 4 il s’agit d’une chaîne de caractères, en 5 et 6 ce sont des entiers signés, en 7 on trouve une fraction.

N. D. L. T. : À ce stade de la présentation, Sebastian commence à être à court de temps. Il décide donc de passer quelques exemples. Vous pouvez les retrouver dans les planches au format PDF.

Le signal pad-added

Le signal pad-added fait partie des choses utilisées fréquemment. Voici un court exemple utilisant ce signal :

let pipeline = _; // 1 decodebin.connect_pad_added(move |dbin, src_pad| { // 2 let sink = gst::ElementFactory::make( // 3 "fakesink", // 4 None // 5 ).unwrap(); // 6 pipeline.add(&sink); // 7 let sink_pad = sink.get_static_pad("sink").unwrap(); // 8 src_pad.link(&sink_pad); // 9 sink.sync_state_with_parent(); // 10 });
  • En 2, on utilise un decodebin qui a été créé auparavant. On le connecte au signal pad-added en lui passant une fermeture (closure). En C, vous auriez à définir une nouvelle fonction, sa déclaration, tout cette verbosité… Ici, vous pouvez écrire la fonction directement avec la connexion au signal. Tout ce qui est disponible en amont peut être capturé dans la fermeture. Par exemple, le pipeline défini en ligne 1 est utilisé à l’intérieur de la fermeture à la ligne 7. Rust s’assure que tout ce qui est capturé est utilisé en respectant les règles de sûreté. Vous pouvez être amenés à devoir copier les objets pour les utiliser à l’intérieur d’une fermeture parce qu’il peut y avoir des cas pour lesquels l’utilisation du même objet ne serait pas sûre. Mais, généralement, c’est très pratique à utiliser et vous pouvez simplement écrire vos gestionnaires de signaux directement sans code superflu. Vous vous demandez peut‐être à quoi correspond ce truc avec les | en ligne 2. C’est la façon dont on définit une fermeture : vous retrouvez les arguments decodebin et src_pad qui correspondent à ceux passés lors de l’invocation du signal pad-added.
  • À l’intérieur de la fermeture, on crée un fakesink (lignes 3 à 6),
  • que l’on ajoute au pipeline (ligne 7).
  • On récupère ensuite le pad « sink » (ligne 8), que l’on relie au pad « src » du decodebin (ligne 9).
  • Finalement en 10, on lance la synchronisation.

Toute personne ayant déjà utilisé GStreamer devrait être en mesure de lire cet exemple et de comprendre exactement tout ce qu’il s’y passe.

Réaction d’un membre du public :

— inaudible
— Ce n’est pas ton cas ?
— Est‐ce que Rust permet à gst_element_sync_state_with_parent de devenir thread safe ? (rires)
— Bien sûr que non, parce que l’implémentation est en C et que cette fonction est défectueuse par conception. Il faut que l’on trouve une meilleure solution à cela. La fermeture que tu passes ici est marquée comme devant respecter des contraintes de sûreté pour l’exécution en environnement à plusieurs fils d’exécution. Donc, tu ne peux pas simplement utiliser une autre référence vers un GstAdapter là‐dedans par exemple, parce que GstAdapter ne respecte pas ces contraintes. Tu ne peux rien utiliser qui ne soit pas thread safe dans cette fermeture, à moins de migrer la variable à l’intérieur, ou dit autrement : à moins que l’unique référence restante sur cet objet se trouve à l’intérieur de la fermeture au final.

Mapping de Buffer

En Python le mapping de tampon est un peu étrange. En Rust, on peut le faire de façon assez élégante :

let mut buffer = gst::Buffer::with_size(320 * 240 * 4).unwrap(); // 1 { // 2 let buffer = buffer.get_mut().unwrap(); // 3 let mut data = buffer.map_writable().unwrap(); // 4 for p in data.as_mut_slice().chunks_mut(4) { // 5 p[0] = b; p[1] = g; // 6 p[2] = r; p[3] = 0; // 7 } // 8 } // 9
  • En 1, on crée un nouveau Buffer. On a besoin d’un Buffer mutable pour pouvoir écrire dedans.
  • Ensuite de 2 à 9, on est obligé d’écrire un truc un peu moche. Il s’agit d’un nouveau bloc qui limite la validité des variables qu’il contient. Elles seront libérées à la fin du bloc et le destructeur sera exécuté.
  • En 4, on mappe le Buffer en écriture. À la fin du bloc, la fonction unmap est exécutée automatiquement.
  • On peut aussi mentionner que le Buffer doit être récupéré sous une forme mutable (ligne 3) avant de pouvoir en extraire une map en écriture. Toutes ces fonctions peuvent échouer, c’est pour cela qu’on utilise unwrap. En cas d’échec, cette fonction termine l’application. Bien sûr, il y a des façons plus élégantes de gérer cela. Je ne les ai pas indiquées parce que ça surchargerait la planche. Il faudrait un peu de code pour gérer le cas d’erreur.
  • De 5 à 8, on itère sur la zone mémoire et on renseigne les valeurs des composantes R, G et B. On peut simplement utiliser les itérateurs de Rust pour parcourir le Buffer par tronçons de 4 octets, c’est ce que l’on peut lire en ligne 5.

Une fois compilé, ça ressemble pratiquement à ce que vous auriez obtenu si vous l’aviez écrit en C.

Quelques liens
  • Les bindings sont actuellement sur mon dépôt GitHub. J’ai l’intention de les déplacer vers freedesktop à un moment donné, mais j’aimerais qu’on migre d’abord vers GitHub_. Je n’ai pas envie de les déplacer deux fois, donc pour le moment ils restent sur GitHub.
  • Vous pouvez trouver plein d’exemples de code ici.
  • La plupart des tutoriels de GStreamer ont aussi été portés ici. Je n’en ai écrit qu’un, les autres ont été portés par des contributeurs. Donc, grâce à eux, vous disposez des tutoriels.
Écrire des extensions GStreamer en Rust

Je vais vous parler rapidement de la manière d’écrire des extensions GStreamer en Rust. Comme je l’ai dit plus haut, l’année dernière nous disposions d’une infrastructure écrite à la main. La plupart de l’infrastructure pour les extensions est toujours écrite à la main, mais ce qui est important c’est qu’elle s’appuie désormais sur les nouveaux bindings Rust de GStreamer. Toute l’infrastructure hors sous‐classes est générée automatiquement et prise en charge par les bindings. Évidemment, toute l’infrastructure pour les sous‐classes, la surcharge des méthodes virtuelles et l’installation des propriétés sont encore écrites à la main.

La différence par rapport à l’année dernière, c’est que vous pouvez maintenant utiliser des méthodes virtuelles et vous pouvez définir des propriétés. Par ailleurs, les gens qui implémentent des Elements ne sont plus obligés d’écrire du code Rust non sûr (déclaré unsafe), ils peuvent le faire, mais ils n’y sont plus contraints.

Le but de tout cela est de pouvoir écrire des extensions GStreamer en implémentant simplement des traits Rust, sans utiliser quoi que ce soit qui ne fasse pas partie du langage, de façon à ce que cela soit très facile pour des gens connaissant Rust d’écrire des extensions GStreamer.

Comme je l’ai dit, une partie du code est encore écrite à la main. Tout cela va être amélioré. Les gens de GNOME travaillent actuellement sur des solutions à base de macros qui font en gros la même chose que les GST_DEFINE_…s, mais d’une manière plus sympa. À l’avenir vous pourrez écrire du code qui ressemblera à du Vala ou du C#, et les macros convertiront cela en quelque chose de similaire à ce que j’ai écrit à la main. Ceci dit, c’est pour plus tard, cela va prendre un peu de temps avant d’en arriver là.

Classes de base disponibles

Actuellement, des classes de base sont disponibles pour :

  • les Elements ;
  • BaseSrc, BasSink et BaseTransform ;
  • Thibault, qui est peut‐être parmi nous, travaille actuellement sur le binding VideoDecoder et il a aussi l’intention d’écrire un décodeur d’images GIF ;
  • il y a une chose que je voudrais souligner ici. Chaque fois que vous faites quelque chose que vous n’êtes pas autorisé à faire, par exemple ce que je faisais tout à l’heure avec unwrap (la création d’un Element pouvant échouer, car il peut ne pas être disponible), et donc si vous utilisez unwrap, en cas d’erreur, Rust va paniquer. Ce que l’on entend par là, c’est que la pile va être déroulée et…

N. D. L. T. : l’organisation informe Sebastian qu’il ne lui reste plus beaucoup de temps.

Elements disponibles

Nous disposons des Elements suivants :

  • démultiplexeur FLV ;
  • source HTTP ;
  • source et « dissipateur » (sink) depuis et vers un fichier ;
  • source et « dissipateur » (sink) depuis et vers Amazon S3 ;
  • il y a quelques jours, j’ai réécrit en Rust l’Element AudioEcho qui existait déjà en C ;
  • et bientôt, si tout va bien, on aura aussi un décodeur d’images GIF (animées).

Une anecdote intéressante : lorsque j’ai écrit l’Element AudioEcho en Rust, il était environ 1,7 fois plus rapide que l’implémentation en C. Ce n’est pas parce que Rust est plus rapide, mais plutôt parce qu’il était plus difficile de faire en sorte que l’équivalent en C soit rapide. J’ai trouvé l’expérience intéressante. Ce n’était pas exactement l’objectif initial lorsque j’ai entrepris la réécriture de cet Element, mais ça montre bien que l’on n’a pas affaire à un langage de haut niveau qui ralentirait les choses, c’est vraiment un langage que l’on peut utiliser pour ce genre de développements.

État actuel
  • les bindings sont encore assez jeunes ;
  • ils sont utilisables pour une implémentation nécessitant les classes de base que je mentionnais plus haut ;
  • les fonctionnalités manquantes seront ajoutées le moment venu.

Si vous voulez écrire des extensions GStreamer en Rust maintenant, lancez‐vous, dites‐moi s’il manque des choses et je les ajouterai ou je vous aiderai à les ajouter. Jusqu’à présent, j’ai pris beaucoup de plaisir à écrire des extensions GStreamer en Rust, j’ai beaucoup plus apprécié cela que d’en écrire en C. Donc, essayez et voyez si c’est le cas pour vous aussi !

N. D. L. T. : Sebastian passe les exemples de code par manque de temps. Vous pouvez les retrouver dans les planches au format PDF.

Quelques liens

Si vous voulez voir à quoi cela ressemble, c’est sur mon dépôt GitHub. Les extensions sont également dans le dépôt.

À venir…

Encore quelques mots à propos de l’avenir : mon objectif est que l’on écrive de plus en plus de code en Rust plutôt qu’en C. Commençons d’abord par les extensions externes. Plus tard, on pourra aussi envisager de remplacer le code du cœur. Mais, ça, c’est pour l’avenir. Il n’y a pas de raison de se faire du souci pour le moment. Nous pouvons faire tout cela de façon itérative en remplaçant des petites portions de code grâce au système FFI de Rust qui rend les choses vraiment faciles pour s’intégrer dans du code C existant. Vous pouvez remplacer un simple module ou même une simple fonction si vous le souhaitez.

Globalement, je voudrais faire en sorte que les bindings soient mieux finis. Que l’infrastructure pour écrire des extensions soit mieux finie aussi, plus complète, mais bon, je suppose que c’est assez évident.

Et le plus important, c’est que j’aimerais faire en sorte que plus de personnes s’intéressent et s’impliquent dans l’utilisation de Rust, ce qui était le but principal de cette présentation. J’espère avoir atteint mon objectif. Jetez‐y un œil, essayez‐le, j’espère que vous ne le regretterez pas. Moi, je ne le regrette pas ! Plus généralement, je dirais : n’écrivez plus de projets en C, c’est une mauvaise idée. Regardez tous les CVE des projets à base de C… Ce n’est pas une bonne idée !

Merci / Questions ?

On n’a plus le temps pour des questions, donc passez me voir après. Voici encore quelques liens. Il y a pas mal d’informations sur le site Web de Rust, la documentation est de très bonne qualité, vous y trouverez probablement toutes les réponses aux questions que vous vous posez :

Merci !

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de Tryton 4.6

6 novembre, 2017 - 22:41

Déjà six mois depuis la dernière version de Tryton et donc voici la nouvelle mouture pour passer l’hiver.

Pour rappel, Tryton est un progiciel de gestion intégré (aka PGI ou ERP) écrit majoritairement en Python (et un peu de JavaScript). Il suit une architecture architecture trois tiers et tourne par défaut sur PostgreSQL et SQLite. Il possède trois clients : desktop, web et script, et vient avec une suite de plus de cent modules qui couvrent un large éventail des besoins de l’entreprise (achats, ventes, comptabilité, stock, etc.).

Cette nouvelle version reçoit pas moins de neuf nouveaux modules, les plans comptables espagnoles et des améliorations de l’interface utilisateur en corrigeant plein de petits détails.

Comme d’habitude, la migration depuis les versions précédentes de Tryton est prise en charge.

Le conférence annuelle de Tryton aura lieu du 7 au 10 décembre à Liège, et on y fêtera les dix ans du projet.

Les journaux LinuxFr.org les mieux notés du mois d’octobre 2017

5 novembre, 2017 - 21:17

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 d’octobre passé :

    Télécharger ce contenu au format Epub

    Lire les commentaires

    MongooseIM 2.1.0, MongoosePush, MongooseICE, Tide

    5 novembre, 2017 - 13:59

    MongooseIM est une plate‐forme libre de chat ou messagerie instantanée, permettant de construire des applications et clients intégrant des fonctionnalités de messagerie instantanée, qu’ils soient pour le mobile ou pour les ordinateurs de bureau.

    La plate‐forme MongooseIM (par Erlang Solutions) passe en version 2.1.0, faisant un grand pas en avant. Le serveur central MongooseIM, qui donne son nom à la plate‐forme, codé en Erlang sous licence GPL v2, a reçu énormément d’attention tant au niveau code qu’au niveau documentation. MongoosePush est un tout nouveau serveur de « Notifications Push » pour les systèmes Apple iOS et Android, codé en Elixir sous licence Apache 2.0. MongooseICE est un serveur STUN et TURN, pour découvrir les adresses IP dans le cadre de communications temps réel pair à pair, ou pour relayer le flux, il est également codé en Elixir sous licence Apache 2.0. Finalement, Tide est une infrastructure de tests de charge en continu, intégré à GitHub.

    Sommaire Petit bout d’histoire et de contexte

    Dans ses version 1.x, c’est‐à‐dire de 1.0 à 1.6, MongooseIM était un serveur discret et autonome. Puis, avec sa version 2.0, MongooseIM a pivoté vers une plate‐forme homogène et cohérente. Généralement une plate‐forme permet de construire quelque chose par dessus et, plus précisément, la plate‐forme MongooseIM permet de construire des applications de messagerie instantanée (chat) en utilisant ses composants logiciels.

    Les composants logiciels sont basés sur des standards ouverts tels que XMPP, REST, OpenAPI et JSON. Cette plate‐forme convient au déploiement de serveurs XMPP fédérés standards prêts à l’emploi, aussi bien qu’aux entreprises (de la startup en amorçage ou « solo‐preneuriat », au grand groupe ou à la licorne) pour construire leur propre application de messagerie instantanée (ou application fournissant tout autre service, auquel on ajoute de la messagerie instantanée). Le serveur MongooseIM permet de connecter plusieurs dizaines de millions d’utilisateurs.

    Les composants livrés avec la plate‐forme MongooseIM 2.0 étaient (et sont toujours) :

    • amoc : A Murder of Crows, outil de test massivement parallèle en Erlang sous licence Apache 2.0 ;
    • Escalus : client XMPP en Erlang sous licence Apache 2.0  ;
    • XMPPFramework : bibliothèque XMPP en Objective-C pour iOS (tiers) ;
    • Jayme : bibliothèque REST en Swift pour iOS par Inaka ;
    • Smack : bibliothèque XMPP en Java pour Android par IgniteRealTime (tiers) ;
    • Retrofit : bibliothèque REST en Java pour Android par Square (tiers) ;
    • Mangosta iOS et Mangosta Android : clients iOS et Android, libres sous licence Apache 2.0, orientés « team chat » (comme Slack, HipChat, MatterMost, Rocket.Chat, Zulip, Let’s Chat, Cisco Spark, Matrix/Riot, Ring, Gitter, Flock, Keybase, Microsoft Teams, Google Hangouts Chat, Unify Circuit, RingCentral Gip, Zang Spaces, Mitel MiTeam, Flowdock, etc.), et social (comme Movim et Salut à Toi).

    Portée par cette logique de plate‐forme, MongooseIM 2.0 avait aussi apporté une API REST (OpenAPI avec du JSON), à la fois pour les back‐ends/serveurs à des fins de contrôle et d’échange de données dans l’infrastructure, et aussi pour le frontal/client/app pour simplifier et fluidifier le développement pour les non‐aficionados de XMPP.

    La version 2.1 est le renforcement de cette posture de plate‐forme, améliorant l’existant et apportant encore de nouveaux composants logiciels à l’écosystème. Le futur de cette plate‐forme est suggéré à la fin de cet article, dans la partie feuille de route, ouverte à votre influence.

    MongooseIM 2.1.0

    Cette version 2.1.0 est un grand pas en avant en termes de qualité. Le focus a été porté sur la cohérence du code et de la documentation.

    Voici un survol très rapide des changements majeurs :

    • compatibilité Erlang/OTP 20 ;
    • recherche plein texte sur MAM (Message Archive Management) ;
    • XMPP pipelining ;
    • distribution Erlang chiffrée par TLS (à l’intérieur d’une grappe de serveurs — cluster) ;
    • accumulateurs, méta‐données sur les messages pour une inspection et une traçabilité plus fines ;
    • authentification par jeton Web JSON ;
    • passage à rebar3 ;
    • configuration des groupes (pools) pour SGBDR ;
    • bien meilleure couverture de tests (69 % à ce jour) ;
    • améliorations de MAM, MUC light et nos API REST (OpenAPI+JSON) côté serveur et côté client ;
    • énormément de travail de fond sur la documentation.

    Pour les plus voraces en détails :

    MongoosePush et MongooseICE

    MongoosePush est un tout nouveau serveur de « Notifications Push » pour appareils iOS et Android. Ces notifications passent par les serveurs tiers APNS (Apple Push Notification Service) et FCM (Firebase Cloud Messaging, anciennement GCM pour Google Cloud Messaging) pour atteindre l’appareil. Vous pouvez l’utiliser avec la XEP-0357 : Push Notifications. Sinon, il est possible d’utiliser le module mod_aws_sns passant par Amazon AWS SNS (Simple Notification Service) ou le module générique de notifications par HTTP mod_http_notification.

    MongooseICE est un serveur STUN et TURN, donc il permet deux choses dans le cadre de communications binaires temps réel pair à pair : découvrir les adresses IP des appareils désirant entrer en communication, ou de relayer le flux binaire entre les deux appareils. Cela aide énormément à l’établissement des appels voix et vidéo et aussi du partage d’écran, par exemple. Ce type de serveur est généralement couplé avec MongooseIM qui route la partie « signalling » par Jingle.

    MongoosePush et MongooseICE sont tous les deux des serveurs autonomes et indépendants, pouvant fonctionner en dehors de la plate‐forme MongooseIM. Il sont tous les deux codés en Elixir et sont tous les deux placés sous licence Apache 2.0.

    Le schéma de composants de la plate‐forme MongooseIM ressemble désormais à ceci :

    Tide

    Tide est une infrastructure que l’on a développée en interne chez Erlang Solutions, en relation étroite avec l’équipe MongooseIM. Il nous sert pour les tests de charge en continu. Nous passons donc au stade public.

    Tide s’intègre au processus de développement sur Git (GitHub). Chaque fusion (merge) d’une demande d’intégration (pull request) est testée et graphée. Cela nous permet de détecter toute régression en termes de performance. L’analyse n’est pas aisée et nécessite toujours de l’expertise humaine.

    Ce graphe montre un des progrès de MongooseIM sur l’année en cours. Il mesure le TTD (Time To Delivery) d’une grappe de serveurs MongooseIM, c’est‐à‐dire la durée entre l’instant où le message de l’expéditeur est reçu et l’instant où il est renvoyé au destinataire. Il ne prend pas en compte le réseau entre l’utilisateur et la grappe de serveurs MongooseIM.

    Pour l’instant Tide est réservé à un usage dédié à la plate‐forme MongooseIM et nous pensons ouvrir cette infrastructure à nos clients et, éventuellement, à d’autres usages.

    Mini‐livre blanc sur la construction et la croissance d’applications de messagerie instantanée

    Ce mini‐livre blanc, au format PDF, Boost your engine growth with chat and social value (Augmentez la puissance de votre moteur de croissance avec de la valeur autour de la messagerie instantanée et du social) est dédié aux décideurs des entreprises et administrations, type directeur technique ou DSI, PDG, fondateurs de start‐ups… Il évolue autour des applications de messagerie instantanée ou applications intégrant de la messagerie instantanée.

    La problématique solutionnée par ce papier tourne autour des mêmes doutes et risques que l’on retrouve dans ces types d’entreprises. Comment séduire une base d’utilisateurs autour de votre application en construction ? Que faire pour auto‐entretenir cette communauté ? Comment créer une dynamique de viralité ?

    À travers des modélisations telles que les « Pirate Metrics » (AARRR) ou la loi de Metcalfe, je m’efforce de mettre en évidence les effets attendus des fonctionnalités majeures de la messagerie instantanée. Cela permettra aux stratèges de reconnecter la réalité de la messagerie instantanée au business qu’ils sont en train de bâtir.

    Feuille de route (« roadmap ») à court et moyen terme

    MongooseIM 2.1.1 sera une version d’optimisation et de maintenance. Elle sera probablement rendue publique avant la fin de l’année, en fonction des retours que l’on recevra. On peut déjà annoncer toujours plus de qualité, de performance et de documentation.

    Ensuite, les versions MongooseIM 3.x livreront la capacité de déployer MongooseIM à l’échelle planétaire, avec du « géo‐clustering ». Cela permet aux utilisateurs d’une région de se connecter de manière transparente à une grappe de serveurs locale, afin de réduire la latence du réseau utilisateur, et de bénéficier d’un routage ultra‐rapide entre régions.

    Appel de l’aventure

    Si vous avez le temps et le courage de jouer avec MongooseIM, MongoosePush, MongooseICE et Tide, nous serons heureux d’en discuter ouvertement avec vous. Devant la variété de nos composants logiciels, vous trouverez sans doute votre bonheur, si vous souhaitez « hacker ». La documentation est continuellement ouverte à toute suggestion, bien évidemment.

    Vous souhaitez contribuer, influencer ?

    Télécharger ce contenu au format Epub

    Lire les commentaires