Découvrir la programmation système en Rust, chapitre 1

Tout le monde se secoue !

J'ai commencé (jeudi 11 août 2016 à 11h57) la rédaction d'un article au doux nom de « Découvrir la programmation système en Rust, chapitre 1 » et j'ai dans l'objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limite pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à l'adresse suivante :

Merci !

Je ne détaille pas le contexte de la rédaction, tout est décrit dans l’introduction de l’article. Même si je ne le dis pas, mon inspiration est évidemment la série d’articles de Ge0 sur les failles de sécurité.

L’article ne restera pas un mois en bêta comme je fais habituellement : j’ai d’ores et déjà l’essentiel de ce que je vais mettre dans le deuxième article, donc j’aimerais que cela ne traîne pas en longueur.

Toutes les remarques sont les bienvenues, bien sûr, mais surtout ne vous retenez pas si vous voyez une coquille orthotypo : je ne compte pas rester assez longtemps en bêta pour une double passe fond puis forme.

Bonne lecture !

Salut,

Je ne suis pas convaincu que le public officiel (défini dans l'intro) de l'article soit capable de tenir jusqu'au bout. Le passage sur libevdev devient imbuvable à la fin. On n'a pas réellement commencé qu'on commence déjà à décrocher. En fait, si je reprends ton intro, je dirai que les deux passages suivants sont méga optimistes :

• En fait, même si vous n’y connaissez rien [à la programmation système], ce ne devrait pas être gênant
• Il n’attend en revanche pas de connaissance préalable en Rust. L’objectif est bien de faire découvrir ce langage, par l’exemple.

Je ne connais pas la prog système, et c'est ça qui m'a fait lâcher. Si ça, c'est simple, je n'ose pas imaginer ce que sont les trucs compliqués. Le corolaire, c'est que le deuxième objectif failli aussi : j'ai la tête pleine de trucs que je ne comprends que vaguement, je sature, alors que le seul truc en Rust que j'ai vu, c'est un hello world.

En fait, c'est surement un bon article pour apprendre la programmation système en Rust, pas pour apprendre le Rust par l'exemple.

orthographe

mais surtout de fouiller dans la documentation d’un bibliothèque.

d'une

Pinaillage à fond : tu mets parfois Rust ou C sans déterminant (en effet, à l’heure actuelle, C et C++ dominent) et parfois avec (il est nécessaire que vous soyez familiers du C). Autrement dit, tu sous-entends parfois langage devant Rust/C/…, parfois non.

Hello,

Le sujet est très intéressant. Je n'ai hélas qu'un smartphone sur une connexion en carton et ne peut donc pas faire de retour complet. Néanmoins en première apporche, je peux déjà dire que ta prose gagnerait pas mal à être épurée des informations parasites. Exemple :

Je recommande de passer par la commande avec curl plutôt que de télécharger l’archive.

Le lecteur ciblé est censé savoir installer un logiciel, il a probablement ses propres préférences en termes d'outils de téléchargements. Ce genre de remarque n'apporte donc rien et allonge inutilement la lecture.

(Note que je ne parle que des informations inutiles et non de ton style, je sais qu'on est pas d'accord sur ce dernier point).

@Gabbro : pour te replacer un peu le contexte, il y a quelques mois, je ne connaissais presque rien à la programmation système, et je me suis fait les dents sur libdrm. La démarche de découverte que j’adopte dans cet article est celle que j’ai suivie lorsque je me suis moi-même formé à la prog système en partant de presque rien, et qui ne m’a pas posé de difficulté particulière. Tu as l’air de dire que mon impression de facilité est faussée et que la pente est plus abrupte que celle que j’aie eu l’impression de grimper.

Du coup, deux questions parallèles.

• Si j’introduis un prérequis de ne pas être largué en programmation système, si j’oriente l’article vers ce public plus restreint, est-ce qu’il te semble que la partie « apprendre le Rust par l’exemple » est abordable ?
• Si au contraire je décide de garder un public plus large, pourrais-tu me dire de manière détaillée ce qu’il faudrait que j’explique pour me mettre au bon niveau ?

Sinon, sur ton pinaillage : en théorie, je me force à ne pas mettre d’article, mais ça arrive qu’il y en ait un qui m’échappe. Si tu repères un de ces sacripants, n’hésite pas à la dénoncer à la HANSTOG.

@SpaceFox : je pense avoir à peu près ciblé ce qui te paraît inutile, mais n’hésite pas à faire une liste complète, c’est le meilleur moyen que je sois sûr.

Si au contraire je décide de garder un public plus large, pourrais-tu me dire de manière détaillée ce qu’il faudrait que j’explique pour me mettre au bon niveau ?

La nuit porte conseil, et je pense que le problème vient de la quantité d'information à stoquer avant de faire quelque chose. Comme j'ai un petit cerveau lent, mettons que puisse retenir 10 nouvelles informations et 2 idées directrices avant de devoir faire une pause¹ (j'aurai donc besoin d'un rappel en revenant de ma pause ), ou de fixer les informations par la pratique ou similaire.

Commençons directement avec « Exposé des motifs ». Les infos qui rentrent sont donc les suivantes :

• evdev = entrée
• API noyau
• idée directrices : on va réimplémenter libevdev
• pourquoi libevdev
• comparaison à libdrm (et description de celle-ci)

À l’attaque !

• Une bonne première piste : quels sont les autres ? Si c'est la première, je m'attends à avoir la suite après
• premiers noms de fichier
• l'exemple marche pas
• gros code (en fait, c'est 10 lignes utiles + plein de print, mais tu ne le dis pas)
• les eventX
• admin
• tout est fichier
• (note : alors que je rédige ce texte, je commence à me dire ici que ça commence à faire beaucoup, alors que j'y vais lentement et que c'est le milieu de la mâtinée, on est d'ailleurs à 11 informations)
• je ne connais pas la prog système, je me demande donc un peu comment on fait pour que les différents accès aux fichiers systèmes ne se marchent pas dessus (fichier modifié entre-temps, par exemple). Je vois d'ailleurs qu'il n'y a pas de close dans le code.
• deuxième lieu libevdev_new_from_fd
• troisième lieu libevdev_get_name
• quatrième lieu libevdev_next_event

Là, lors de ma première lecture, j'ai lâché.

Bien. De là, je te propose (après, c'est évident que tu fais ce que tu veux, tu voulais une publication rapide alors que je propose des changements non négligeables, ce serait bien d'ailleurs si quelqu'un d'autre sans bagage de programmation système passait par là ) les choses suivantes :

• Comme le dit SpaceFox, ce qui est inutile peut disparaitre.
• Ce qui est accessoire doit être mis au second plan. Tu as surement de très bonne raisons d'avoir choisi libevdev, elles sont probablement très intéressantes, mais pour qui débute la programmation système par ton texte, ça fait des informations en plus qui ne servent pas directement. Je serai partisant de les mettre en note de bas de page, en annexe, dans une balise secrète, bref, n'importe quoi qui permette de dire « si vous êtes un nouveau, laissez filer les points en plus ».
• Comme j'aime à le dire en science, on ne laisse pas un résultat sans commentaire. Si tu obtiens une formule d'importance, tu le commentes tout de suite. Là, c'est pareil avec les codes. Deux mots pour dire que le code n'est rien d'autre qu'une initialisation, un amas de print, puis la récupération d'évènements dans la boucle suffirait à apporter de la lisibilité. Actuellement, on a des détails sur les inputX, puis sur le tout est fichier, puis… et enfin des commentaires en 4 points alors qu'on a peut-être pas encore bien pigé comment c'était organisé (ou oublié, 6 paragraphes ont passé).
• Évite de faire des pavés quand il n'y a rien à dire. Par exemple, le code d'exemple ne marche pas. Là, c'est 3 lignes qui détaille bien pourquoi il ne marche pas. Un simple « Quant au code d’exemple, il est inutilisable en l’état : il manque la fonction main, tous les en-têtes et utilise des fonctions qui n’existent pas. » suffi très largement, et est deux fois plus court. On ne se focalisera pas dessus (et ça tombe bien, il ne faut pas). De manière générale, tu as tendance à être un peu verbeux par moment.

Voilà. J'espère avoir été plus claire et précis sur ce qui m'avait gêné.

Bonjour,

La bêta du contenu « Découvrir la programmation système en Rust, chapitre 1 » a été désactivée.

Bon, on ne va pas se mentir, les changements demandés par Gabbro me saoulent. Pas en tant que tels, mais parce qu’ils me prendraient trop de temps par rapport à ce que je cherche à faire. En effet, j’avance déjà super lentement sur la programmation du fait que j’écris un cours en parallèle, si en plus je dois le rendre accessible à ceux qui ont du mal à faire le tri entre les informations à retenir tout de suite et celles à garder sous le coude pour plus tard, je ne vais plus y prendre aucun plaisir.

Dans ces conditions, j’ai décidé de le publier par mes propres moyens, sous la forme d’un site GitHub Pages. Une fois qu’on s’est mis un peu dans le bain de comment marche la bête, ça permet d’avoir un site pas trop mal foutu et facile à maintenir, et en lien direct avec le dépôt sur lequel se trouve le code.

J’ai réorganisé le premier chapitre pour prendre en compte certaines remarques et virer la prétention de s’adresser à des débutants complets en programmation système. Certains morceaux se retrouvent sur la page d’accueil du site et dans l’intro de la série d’articles. Et surtout, j’ai publié un deuxième chapitre. Donc pour ceux qui s’en sentent, la lecture se poursuit !