Bruno:
S'il y a bien une chose que j'apprécie dans l'évolution de notre métier, c'est qu'à mesure que les nouvelles technos sortent, la barrière à l'entrée baisse. Il est de plus en plus facile pour n'importe qui de créer une application. Ce que l'on perçoit pas forcément, au premier abord en tout cas, c'est que cette ouverture passe par une succession d'abstractions. Car plus on se rapproche du hardware, plus la complexité augmente. Le bas niveau n'a pas connu la même simplification que ces nouvelles couches hautes. Mais alors, code-t-on encore si proche du processeur ? Quelles sont les compétences requises ? Et surtout, le dev bas niveau est-il un dev comme les autres ? Pour répondre à ces questions de niveau, je ne reçois pas Jacques Cousteau, mais il s'y connaît en profondeur. Christophe, bonjour.
Christophe:
Bonjour.
Bruno:
Alors Christophe, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Christophe:
Alors, je m'appelle Christophe Ledouarec, je suis manager chez Corvo, un fabricant de semi-conducteurs et plus précisément dans la division qui fait des puces innovantes liées à l'ultra-wideband. donc une future technologie dont beaucoup de personnes devraient entendre parler. Et puis, j'ai moi-même été dev bas niveau dans le monde des télécoms et de l'automobile. Et puis, par la suite, je me suis mis à encadrer des personnes parce que ça me faisait énormément plaisir de coacher les gens avec qui je travaille.
Bruno:
Je vais me permettre de commencer direct avec une question peut-être très bête. Alors, je ne vais pas dire très bas niveau parce que ce n'est pas le sujet, mais en tout cas, qui n'est pas très élevé. Je trouve ça toujours intéressant qu'on crée des puces on parle des puces wifi, on parle des puces 5G on parle des puces ultra wideband donc on parle quand même de quelque chose d'une technologie de transmission, et donc en fait on est à un niveau aujourd'hui où c'est pas juste une antenne il y a une puce et son rôle c'est quoi du coup c'est juste de décoder le signal de l'antenne et d'encoder du coup le signal qui part ou il y a plus que ça.
Christophe:
Souvent il y a plus que ça parce que on va vouloir essayer d'être le plus performant possible et il y a un moment, de la même manière qu'en logiciel on va essayer de coder des librairies finalement ces librairies on va presque qu'essayer de les faire au niveau hardware. Donc, la manière dont on design un chip aujourd'hui, c'est un peu comme ça. C'est des blocs. Et on va essayer de ramener des fonctionnalités qui nous font gagner du temps, du processing au niveau logiciel.
Bruno:
Donc, en fait, c'est comme un programme déporté qui est dédié à une fonction précise qui a son propre cache, sa propre mémoire et son propre CPU au final.
Christophe:
Oui, exactement.
Bruno:
Et c'est quoi, du coup, l'ampleur si on prend cette notion d'antenne sur un aspect purement hardware, Il y a combien d'expertises, on va dire, qui interviennent pour créer ce tout petit bout de plastique, parce qu'au final, c'est un petit bout de plastique, ou de silicone ? Il y a combien d'expertises qui vont intervenir pour concevoir tout ça ?
Christophe:
Énormément. Il va y avoir des designers hardware spécialisés dans le design des semi-conducteurs, donc pas des personnes qui font des cartes électroniques, mais vraiment des semi-conducteurs. Derrière, il va y avoir des testeurs, il va y avoir de la QA de manière générale. On va avoir des personnes qui vont designer des cartes autour de ça donc toujours des ingénieurs hardware ensuite il y a des ingénieurs logiciels qui vont finalement permettre d'utiliser ces fonctions hardware et à la fin de tout ça on va retrouver un utilisateur peut-être un développeur plus haut niveau qui va avoir une API et qui va envoyer un message via du Bluetooth sans même voir finalement tout le chemin.
Bruno:
Que prend.
Christophe:
Son information pour être transmise.
Bruno:
Alors donc du coup toi aujourd'hui tu gères une équipe donc dite bas niveau donc tu nous as parlé de cet aspect hardware tu nous as parlé de ce dev haut niveau tu parles de tout ce qui se passe entre tout ça ce qu'on appelle du coup le dev bas niveau ça englobe quelle partie tu vois est-ce que la conception du hardware, du CPU en tant que tel est-ce que c'est du bas niveau jusqu'où ça va vis-à-vis du socket que tu mets à disposition, cet API que tu crées, à quel moment tu sors du bas niveau ?
Christophe:
Alors, au niveau vraiment bas niveau, on va rester sur... On ne fait pas du design hardware. Il y a des personnes qui sont vraiment dédiées pour ça, qui ont les connaissances. Maintenant, un développeur bas niveau, il sait lire des schémas blocs, il comprend comment un hardware fonctionne. Ça, c'est un prérequis, c'est même une grosse partie de son travail au quotidien, de pouvoir brancher un oscilloscope et comprendre si les signaux sont corrects. Donc finalement la frontière elle est plutôt de l'autre côté pour savoir où est-ce que ça s'arrête c'est la frontière entre un dev bas niveau et un dev middleware ou plus haut niveau en fonction de comment on peut l'appeler, et là c'est plus flou ça dépend finalement des types de produits, dans des produits un petit peu grand public comme des téléphones on pourrait dire que la frontière elle se fait au niveau kernel space, user space donc dès qu'on sort de l'espace, kernel, on n'est plus un développeur bas niveau, mais c'est aussi pas tout à fait vrai, parce que dans cette famille de développeurs, on va retrouver des intégrateurs et qui, eux, ne développent pas, vont prendre finalement des blocs à droite, à gauche, les assembler, et ça, on ne peut pas non plus considérer que c'est réellement du développement bas niveau.
Bruno:
Et puis surtout, quand tu parles du kernel, au final, on peut se dire peut-être aussi que ces fonctionnalités, entre guillemets, avant d'être dans le kernel, elles étaient du coup considérées comme du haut niveau, Il y avait quand même une partie des choses qui existaient en dehors du kernel avant d'être intégrée, j'imagine, dans le cœur du système ?
Christophe:
Oui, et puis ça dépend effectivement des systèmes sur lesquels on est en train de parler. Là, je parlais vraiment un petit peu kernel Linux pour prendre un exemple. Mais aujourd'hui, on a d'autres systèmes avec des micro-kernels où même les drivers, finalement, on les déporte côté user space pour avoir un kernel qui ne fait que du scheduling de tâches, entre guillemets. Donc oui, en fait, la frontière n'est pas forcément si simple que ça. Mais on va dire quand même, il y a deux aspects qui sont quand même très importants pour un développeur bas niveau, c'est comprendre le hardware et la performance sous toutes ses formes.
Bruno:
Ok. Et alors du coup, ces notions de performance, on parle quoi uniquement de temps de calcul ? Enfin, j'imagine que c'est les contraintes que tu as qui sont imposées par le hardware que tu as à disposition, que tu ne peux pas modifier. Mais du coup, quand on parle du kernel Linux, lui, il peut être installé sur des environnements très différents. Est-ce que du coup toi comme t'es sur ces puces ultra wideband tu connais du coup ton environnement hardware et du coup tu connais les contraintes que t'as ou il faut que t'arrives à faire un système qui soit, suffisamment malléable pour s'adapter aussi bien à un processeur de frigo qu'une antenne wifi je sais que je dis n'importe quoi mais tu vois l'idée.
Christophe:
Je vois bien l'idée effectivement nous on va plutôt essayer de s'adapter au hardware sur lequel on va tourner.
Bruno:
Et effectivement.
Christophe:
Quand on parle de nos puces, on n'est pas forcément non plus sur des OS comme Linux, parce que c'est déjà trop gros finalement. Sur de l'embarqué pur, on peut avoir des produits qui devraient avoir quelques, mettons, 100K de RAM. Donc, on est loin d'un produit comme aujourd'hui dans le cloud, où on a des développeurs qui vont développer avec 4Go de RAM et plus par extension. Donc le hardware finalement c'est la première contrainte c'est ce hardware qui va nous dire est-ce qu'on doit choisir tel ou tel operating system et pourquoi.
Bruno:
Est-ce que du coup ça veut dire que, cet environnement te permet de donner des PC qui ont plus de 10 ans à ton équipe de dev ?
Christophe:
Non. Non, non. En l'occurrence, on a des très bons PC et c'est assez nécessaire. Ce n'est pas parce qu'on travaille sur des systèmes qui sont très restreints, très contraints, que derrière, il n'y a pas une forme de complexité quand même pour développer sur ces systèmes.
Bruno:
Alors, ça, je suis entièrement d'accord pour dire qu'il y a une complexité, c'est-à-dire que vous avez effectivement des problématiques que je pense très peu de devs ont encore aujourd'hui tu parles effectivement des quelques kilo octets de RAM à dispo là où effectivement nous la RAM dans l'environnement web, on en a pléthore je parle même pas de la notion de disque dur on a des bases de données qu'on alimente sans même se soucier de la place que ça prend donc bien évidemment vous avez des contraintes qui sont au delà de ce que nous on peut avoir, mais c'est vrai que tu vois il y avait cette image là de se dire que tu peux du coup avoir un ordinateur qui n'est pas forcément performant mais en fait au delà de ça même en terme d'outillage, tu vois aujourd'hui quand tu prends un dev tu prends un dev React il a quand même tout un ensemble d'outils à sa disposition pour l'aider à coder au quotidien, alors je me trompe très certainement mais tu vois l'image que j'ai je me dis quand tu as un dev bas niveau au final tu as juste ton notepad, tu codes en C tu compiles dans ton terminal et puis c'est marge c'est quoi l'outillage que vous avez pour coder au quotidien ?
Christophe:
C'est à peu près le même que celui des développeurs haut niveau donc on va retrouver des devs qui vont être sur Vimimax comme d'autres qui vont être sur VS Code ou sur des outils, de JetBrains, en plus orientés pour le C, mais des IDE on va dire au sens large. Là-dessus, ce n'est pas sur les outils forcément que les choses changent. De la même manière, on utilise aussi des conteneurs pour avoir nos toolchain de build, etc. Donc pareil, au niveau de l'environnement, je pense qu'il y a une forte modernisation qui a été faite dans le bon sens du terme et donc aujourd'hui ce n'est pas à ce niveau là que la différence réellement existe entre un développeur bas niveau et haut niveau. On utilise les mêmes technologies, on observe aussi ce qui se fait par l'IA pour voir comment ça peut nous aider à mieux développer donc là dessus c'est pas, on n'a pas de vraie différence métier si on peut appeler ça comme ça, à ce niveau là.
Bruno:
Question sur TikTok, est-ce que vous collez du coup sur Mac ?
Christophe:
Il y a des personnes qui développent sur Mac, dans nos équipes. L'essentiel est sur Linux. Quelques-uns sous Windows, c'est plus rare, mais l'essentiel est sur Linux.
Bruno:
Tu disais, du coup, en termes d'outillage, on retrouve les choses traditionnelles que chez un développeur ou une développeuse au niveau. Vous avez du coup aussi une CI-CD, même si j'imagine que la notion de déploiement continu peut être plus compliquée sur ces sujets de hardware, mais vous avez du coup aussi une notion d'intégration continue ?
Christophe:
Oui, oui, oui. Alors, on a des systèmes exactement les mêmes qu'on va retrouver. On peut citer des Jenkins, des GitLab, pourquoi pas des GitHub Workflow, etc. Donc, ce genre d'outils, on les retrouve aussi. Finalement, la vraie différence, ça va être plutôt sur le flow de délivrerie. Dans le monde du web, il y a une étude qui a fait beaucoup parler aussi dans le monde du DevOps. C'était à Accelerate qui dit une bonne équipe aujourd'hui c'est une équipe qui livre plusieurs fois par jour ça dans le monde du bas niveau on aimerait bien mais c'est plus compliqué c'est plus compliqué parce que on peut pas demander à un développeur qui est en train de, mettons développer une technologie, un driver HDMI ça peut arriver pour transmettre de la vidéo finalement il peut pas livrer une petite partie en l'état ça va pas marcher En fait, il faut que tout l'essentiel du pipeline soit là pour que ça fonctionne. Et quand on prend justement un pipeline, comme c'est le cas dans le kernel Linux, ça impose un certain nombre de développements et ça peut... C'est quasi impossible de faire ça en moins de quelques semaines. On ne parle même pas de jours, on est plutôt de l'ordre de la semaine.
Bruno:
Est-ce que l'approche agile peut fonctionner dans un environnement comme ça où tu as besoin, de ce que je comprends, tu ne peux pas faire juste un élément très unitaire, très simple. Tu es obligé d'avoir quand même tout un environnement qui te permet de faire que cet environnement, cet élément simple s'exprime. Du coup, c'est-à-dire, est-ce que l'agilité a plus de mal à s'exprimer sur vos sujets ?
Christophe:
Elle a plus de mal, oui. Elle a plus de mal, elle n'est pas impossible, et nous, on essaie beaucoup de travailler à ce niveau-là. Alors, elle a plus de mal pour plusieurs raisons, à vrai dire. Pour cette raison un petit peu de flot de délivrerie, c'est vrai que le rythme n'est pas le même, c'est plus compliqué. Et aussi pour une question un peu de culture. C'est-à-dire que le monde du bas niveau, d'une manière générale, ça a beaucoup été porté par des industries un peu lourdes, que ce soit, mettons, la défense, l'automobile, l'aéronautique, etc. Et dans ces industries-là, l'agilité est arrivée finalement assez tardivement, comparée au web, par exemple. Et c'est un peu ce qui explique aussi qu'il y a un petit retard à l'allumage. Maintenant on va dire ce retard il a été rattrapé de plus en plus en tout cas moi chez Corvo c'est le cas, mais on sent que si on prend from the book les règles de l'agilité on a essayé, et dans d'autres sociétés que j'ai pu voir ça marche pas forcément il y a des adaptations à faire qui sont propres finalement au profil, des personnes et aussi des produits sur lesquels on développe.
Bruno:
C'est aussi j'imagine que vous avez des contraintes qui sont très fortes. Quand on parle de hardware, de dev bas niveau, vous avez des contraintes hardware dont vous ne pouvez vraiment pas sortir et notamment parce que quand tu mets à jour ton, Ton application, ton code, je ne sais pas comment on le dirait réellement, mais tu ne peux pas le déployer en 20 minutes sur tous tes clients. La mise à jour ne se fait pas meilleure, c'est simple. Et tu ne peux pas modifier les capacités hardware d'un élément que tu as mis en vente il y a 5 ans. Donc, tu as des contraintes qui sont extrêmement fortes sur ce que tu fais. Donc, j'imagine que c'est ça aussi qui fait que l'agilité a du mal à s'appliquer dans ce monde-là.
Christophe:
C'est une des raisons, effectivement, même dans le monde de l'IoT, avec des objets connectés, mettre à jour, ce n'est pas forcément si simple que ça, et surtout sur les aspects les plus bas niveaux, parce qu'il y a toujours des risques aussi, donc il faut en être conscient. Finalement, l'applicatif au-dessus, s'il a un problème, il suffit de remettre à jour. Là, si on parle de l'accès au driver Bluetooth, ça se trouve, le device n'est plus connecté, et donc on ne peut plus du tout le mettre à jour. Donc forcément, les impacts ne sont pas les mêmes. Après, ça ne veut pas non plus dire qu'il n'y a pas des choses sur lesquelles on ne peut pas essayer d'avancer aussi. C'est une vraie problématique aujourd'hui dans le monde du bas niveau. Comment on peut amener ces flux de livraison plus rapidement auprès du client ? On le voit même dans le monde Android aujourd'hui. Ils ont essayé justement de décorréler un petit peu la partie bas niveau et la partie haut niveau. Google, j'entends. Pour permettre justement aux développeurs, aux intégrateurs de type Samsung, Huawei, etc. De pouvoir mettre à jour leur système indépendamment des bases du système, c'est pas encore très très bien suivi et on voit bien que même si l'initiative est bonne dans les faits, je dirais à part Apple qui maîtrise complètement son écosystème pour les autres c'est plus difficile à amener ce.
Bruno:
Alors du coup ces contraintes assez fortes j'imagine que ça vous oblige aussi enfin tu le disais c'est que tu peux pas mettre à jour comme tu veux, donc ça veut dire que si jamais t'as un bug, bah si tu peux pas mettre à jour, bah t'as un produit qui se balade dans la nature avec un bug, donc j'imagine que vous avez quand même des procedures de test qui sont j'imagine aussi peut-être plus sévères, plus strictes que ce qu'on peut avoir dans le monde du web, par exemple est-ce que du coup des pratiques comme le TDD sont des choses, peut-être même qui viennent du bas niveau ou en tout cas qui sont fortement présentes dans le bas niveau ?
Christophe:
Alors, elles viennent pas du bas niveau pour le coup elles viennent vraiment clairement du haut niveau, maintenant c'est quand même des choses qu'on essaye de pousser aussi dans les équipes bas niveau, au niveau du kernel Linux, maintenant on commence à avoir des frameworks de tests intégrés ou même au niveau d'autres RTOS, des OS encore plus minimalistes finalement comme Zephyr il y a de quoi faire des tests mais, ça peut être difficile de faire des tests unitaires pour une simple et bonne raison que généralement quand on va prendre un code d'un point de vue haut niveau. Une façon simple de le rendre testable, c'est on va faire de l'injection de dépendance pour injecter des mocs, etc. Au niveau bas niveau, déjà le C, ce n'est pas le langage le plus abouti pour faire du test. C'est un langage qui date des années 70, donc il n'avait pas forcément pris ça en compte dans sa checklist initiale.
Bruno:
C'était effectivement une époque où le dicton, c'était tester, c'est douter.
Christophe:
Ouais on l'entend encore sous la forme de la blague alors que maintenant non clairement on sait bien qu'il faut tester c'est indispensable il vaut même mieux tester deux fois plutôt qu'une, et donc on voit que non le TDE c'est possible et il faut le faire, mais on revient quand même à la problématique initiale qui est la performance, aujourd'hui quand on fait un code qui doit être performant chaque instruction, donc chaque ligne d'exécution du code elle a son importance. Et rajouter finalement quelque chose qui peut servir, qui va améliorer le design pour rendre plus testable, d'un point de vue d'un développeur haut niveau, c'est une bonne pratique. D'un point de vue d'un développeur bas niveau, c'est une bonne pratique, mais on ne peut pas toujours le faire.
Bruno:
Donc il y a, un équilibre que vous devez trouver entre ça nous apporte une stabilité, une fiabilité sur le long terme versus ça nous ajoute du poids, qui pèsent forcément plus tard, que ce soit sur la mémoire ou sur le temps de processing de chaque information, c'est ça ?
Christophe:
Exactement. Je vais prendre un exemple peut-être simple qui nous est arrivé il n'y a pas très longtemps. On avait une fonction qui fait un logarithme. Donc généralement, quelqu'un qui fait un développement haut niveau, il va prendre la lib standard de son langage, il va y avoir une partie souvent dédiée au mat il va appeler, il va pas trop se poser de questions il y a le résultat, c'est ok sauf que à notre niveau, on peut pas se permettre de faire ça donc on avait déjà une implémentation qui était relativement optimisée, donc qui est pas en flottant qui est en fixpoint etc sur le hardware qu'on avait ça tournait de l'ordre d'une dizaine de microsecondes la fonction, on a dû aller plus loin en l'optimisant donc on est descendu à 5 microsecondes sur la fonction, on a divisé par 2, sur un exemple comme ça on voit bien qu'on va essayer d'optimiser la moindre ligne d'assembleur et rajouter finalement ne serait-ce que même un pointeur qui va être lu sur la stack en entrée de la fonction c'est un coût, et à des moments on peut l'absorber et à d'autres moments on peut pas l'absorber ce coût là.
Bruno:
C'est fou parce qu'en fait Je ne sais pas combien de devs sont comme moi à réaliser à quel point vous avez des problématiques qui sont assez oufes. C'est-à-dire que cette logique de dire que tu ajoutes un pointeur sur ta stack pour qu'il soit l'entrée de fonction... C'est que des mots qu'on comprend, tu vois, en tant que dev, tu vois ce que je veux dire. Mais c'est des problématiques qu'on se pose absolument jamais. Tu vois ce que je veux dire, c'est que c'est un souci du détail. J'ai presque envie de dire, alors je reprends la discussion qu'on avait en se faisant un café tout à l'heure, mais c'est de l'orfèvrerie en fait que vous faites.
Christophe:
Effectivement, la plupart des devs bas niveau, c'est des experts. Ils ne connaissent pas tout sur tous les domaines. Généralement, ils ont un petit peu un domaine d'expertise. mais par contre ce qui va être le lien commun c'est qu'ils maîtrisent parfaitement leur langage et ils maîtrisent parfaitement ce que fait le compilateur en termes de production de code.
Bruno:
Oui parce que je me permets de te couper mais du coup c'est vrai que ce que tu dis, me donne envie de réagir fortement c'est que il y a effectivement une maîtrise du code, vous savez coder de manière très précise vous savez ce qui se passe mais c'est effectivement aussi une maîtrise de se dire, quand j'écris ça quand j'écris ça on sait, le compilateur va en faire ça et du coup alors je vais peut-être dire une connerie mais du coup en assembleur ça va donner ça et du coup en termes d'exécution ça va donner ça donc il y a effectivement une maîtrise de la chaîne, absolument totale pour effectivement avoir cette précision à la microseconde.
Christophe:
Ouais pareil exemple simple tout le monde tout développeur dans n'importe quel langage pourra comprendre aisément je fais un if et je vais tester une variable, finalement le cas le plus probable, si c'est un énuméré ça devrait être la valeur 0 pourquoi ? Parce que finalement quand le code assembleur derrière est produit faire un test un if contre une valeur qui vaut 0 c'est une instruction assembleur, Si je fais avec n'importe quelle autre valeur, généralement, ça dépend des architectures, là, je simplifie, mais c'est deux instructions assembleurs. Donc, on voit qu'à un moment, quand on va vouloir comprendre un petit peu comment on peut aller gratter de la performance, tout compte. Aujourd'hui, on a changé une soustraction dans un code par un XOR parce que ça nous a enlevé deux instructions assembleurs. Donc, effectivement, il y a un moment, il faut comprendre. Par contre, il ne faut pas non plus rentrer dans je dois tout optimiser. En fait, il y a un chemin qui est critique, qui doit être optimisé, mais le reste, la sémantique compte, bien architecturée, rendre testable, ça compte aussi. Donc, il y a un niveau quand même à juger.
Bruno:
Oui, c'est ce que tu disais tout à l'heure aussi sur cette notion de test, en fait. C'est qu'il faut aussi cet équilibre à choisir entre ton code est maintenable, et va du coup te faire gagner du temps dans les évolutions que tu vas devoir faire parce qu'il faut quoi qu'il arrive à faire évoluer ton code, et le fait que il faut que le code prenne lui aussi le moins de temps possible quand il s'exécute, mais est-ce que du coup vous allez plus souvent vers il faut que le code soit rapide ou plus souvent vers il faut que le code soit maintenable ?
Christophe:
Non, il faut que le code soit maintenable ensuite on profile et ensuite on voit finalement là où on peut gagner faire l'inverse c'est clairement rentrer dans un anti-pattern une mauvaise pratique, en plus de nos jours les compilateurs font un énorme travail pour nous donc dans pas mal de cas avec toutes les passes d'optimisation le code, généré sera très bien et donc vaut mieux le rendre d'abord lisible, clair, maintenable secure aussi parce qu'un code qui est lisible c'est souvent aussi un code qui introduira moins de bugs, plutôt qu'essayer de voir faire de la micro-optimisation à tout prix.
Bruno:
Alors du coup, on me dit dans le chat qu'il n'y a pas de full stack dans vos métiers. Est-ce qu'on peut être full stack ou au final, il y a trop de complexité partout pour réussir à avoir cette casquette-là ?
Christophe:
Effectivement, c'est assez difficile. Il y a des personnes qui peuvent l'être, qui souvent vont prendre un peu du recul, vont devenir un petit peu plus architectes. Ils vont avoir c'est des personnes qui ont beaucoup d'expérience et qui auront touché à beaucoup de choses, Si je prends juste l'exemple du kernel Linux, parce que c'est quelque chose que finalement qu'on a tous les jours dans notre vie, aujourd'hui, c'est plus de 30 millions de lignes de code, le kernel Linux. Donc, c'est une belle pièce logicielle, une belle base de code. Et une personne qui développe la pile réseau, généralement, il y a de force chance qu'ils ne sachent absolument pas comment fonctionne, mettons, VKTL2, qui est la manière de gérer de la vidéo sur Linux. Ça demande, en fait, un tel investissement pour comprendre comment les différentes briques fonctionnent. Pourquoi ? Parce qu'il faut comprendre aussi comment le hardware en dessous fonctionne et les standards associés. Donc, ce n'est pas juste une problématique de comment coder, parce que le C est à peu près là partout, même si ça change. Pour en revenir, il y a d'autres langages, Rust, etc., qui arrivent. Mais c'est plus l'utilisation qu'en est faite qui impose finalement d'être expert.
Bruno:
Après, tu prends un exemple où effectivement les deux aspects, tu prends la pile réseau et la partie vidéo, on imagine effectivement des, des briques qui sont effectivement très éloignées l'une de l'autre en termes de problématiques. Mais on peut imaginer qu'il y a quand même des porosités. Donc celui qui fait la pile réseau, il a aussi une connaissance des différents technos de transmission. Et on peut s'imaginer que sur une pile réseau, tu gères des flux d'informations en entrée et en sortie. Et que donc, il peut avoir une compréhension, une connaissance de comment gérer la partie disque dur. L'accès en écriture et en lecture sur un disque dur. où on peut dire que c'est à peu près. Je grossitrais, tu vois, mais tu as une porosité qui est quand même plus proche entre ces deux éléments-là qu'effectivement, sur l'encodage vidéo.
Christophe:
Il va avoir des connaissances, mais dès qu'on va rentrer dans les détails, et ce n'est pas pour rien que le code est aussi gros, c'est que finalement, il y a tellement de spécificités. Là, tu parlais des fichiers, mais on parle de quel système de fichiers ? Il y en a plein. Donc, comprendre le framework peut-être de base du kernel, comment il gère des filesystems, c'est une chose et ce n'est pas forcément le plus compliqué. Mais après, comprendre les spécificités de comment est codé un X4 par rapport à un X3, mettons, ou d'autres filesystems, ça, ça demande un petit peu de connaissance. Et derrière, ramener ça à « je connais comment marche l'HDMI et toute la norme qui va derrière » pour de la vidéo, en fait, c'est assez éloigné finalement.
Bruno:
Ouais, je vois. J'avais une question, je l'ai perdue. C'était... La question commençait par comment tu fais pour choisir ? Non, je ne l'ai plus. Attends, on parlait de quoi avant ? Le point d'avant, c'était sur ?
Christophe:
Bonne question. Il y avait sur le côté full stack.
Bruno:
Il y avait l'aspect full stack. Attends, il y avait autre chose. Ah zut ! Elle n'était pas si mal que ça, en plus, ma question. On va y espérer. On essaiera d'y revenir. Est-ce que du coup, aujourd'hui... Ah oui, c'est ça, j'ai retrouvé ma question. Parce que du coup, tu parlais du compilateur. de cette maîtrise du compilateur. Du coup, j'imagine que parfois, tu en arrives aussi à te dire... Qu'on va réécrire le compilateur pour qu'il te génère du coup un code assembleur différent, parce que j'imagine que vous avez aussi une connaissance de ce que tu nous disais tout à l'heure de toute cette chaîne-là. Tu vois, donc, est-ce que du coup, réécrire le compilateur, parfois, c'est une option qui est plus importante, qui est plus pertinente, pardon, que de réécrire du code ?
Christophe:
Alors, on ne va pas réécrire le compilateur, mais effectivement, on peut jouer sur les options de compilation ou même les versions du compilateur. Je vais prendre un exemple.
Bruno:
Sur les versions, c'est-à-dire que du coup, en fait, tu choisis l'outil adapté, c'est comme si tu prends, tu choisis la taille de ton tournevis, en fait, en fonction de la vis que tu as à faire.
Christophe:
Exactement. Ne serait-ce qu'au sein d'un même logiciel, donc prenons GCC, qui est l'exemple assez classique, le compilateur C sous GNU. Finalement, entre ces différentes versions, il y a des évolutions, il y a des changements. Un exemple vraiment simple, Il y avait une personne, un expert de la communauté C++ qui s'appelle Andrei Alexandrescu qui travaille chez Facebook. Il expliquait pendant une conférence en intro, chez Facebook, on a updaté la version du compilateur. Je ne sais plus si c'était vers la 4.8, vers la 4.9, quelque chose comme ça. Et on a perdu 5% de performance.
Bruno:
Ce qui est énorme quand même.
Christophe:
À leur niveau, c'est des millions parce que derrière, il faut comprendre ce que ça entraîne en fait comme coût d'infrastructure, etc. Donc derrière, en fait, ils se sont aperçus que c'était sur la manière dont le compilateur inlineait des fonctions. Donc c'est de l'optimisation. Ils ont tuné des options d'inlining et ils ont réussi à regagner les 5% plus gagner 2%. Ils n'ont pas changé le code source. Le code est toujours le même. Par contre, ils ont joué un petit peu sur le compilateur pour effectivement avoir quelque chose qui leur convient. Nous, au niveau embarqué, on va avoir d'autres contraintes, par exemple. Des fois, le compilateur, on va le tuner non pas pour la vitesse, mais pour la taille du code produit. Parce qu'effectivement, on a des contraintes en termes de taille de stockage du code. Et on ne peut pas se permettre, on n'a pas des mégas et des gigas de flash sur nos devices. Et donc là aussi à des moments les inlining bon si c'est vraiment nécessaire on va le faire mais, à des moments c'est pas nécessaire ça va pas amener un énorme gain de performance ou en tout cas pas sur le chemin critique et donc on préfère s'en passer et finalement, gagner en termes de taille de code parce que au moins on est sûr que le code rentre dans le produit.
Bruno:
C'est fascinant tous ces sujets là pour vous est-ce que est-ce que du coup vous regardez les devs haut niveau, bien évidemment pas avec des dents parce que c'est pas le sujet mais est-ce que vous avez conscience des niveaux de problématiques que vous avez, et vous avez l'impression que du coup les autres devs ont la belle vie.
Christophe:
Non parce que d'expérience je pense que chaque développeur a ses contraintes c'est pas les mêmes ça c'est sûr mais je pense pas forcément qu'on ait qu'ils aient une vie plus belle que nous ou inversement, je pense que c'est pas les mêmes problématiques effectivement, les développements bas niveau on va livrer peut-être un peu moins vite il faut que ça soit plus stable on n'est pas non plus dans la course effrénée à de la livraison de features au maximum. On n'a peut-être pas, au niveau de la concurrence, je ne sais pas si c'est pareil, mais finalement aujourd'hui, le ticket d'entrée pour faire un site web, il est quand même beaucoup plus facile. Donc, se distinguer par rapport à son concurrent, c'est vraiment amener une expérience utilisateur beaucoup plus forte et qui soit bien conçue. Au niveau du très bas niveau un pipeline de décodage vidéo pour revenir un peu sur cet exemple là on n'a pas ces problématiques là finalement, on est moins face au client final donc on a aussi un petit peu cette, cette protection d'une certaine manière par contre moi ce que je trouve extrêmement intéressant c'est voir ce qui se fait quand même dans le monde du haut niveau aujourd'hui ça bouge beaucoup plus que bas niveau, que ça soit au niveau des langages, des frameworks, etc., des méthodes. Et il y a beaucoup de choses qu'on a à apprendre aussi. C'est pas que, ok, vous, côté web, vous pourriez optimiser un petit peu plus, vous verrez, on peut vous expliquer comment ça marche. Je pense pas que ça soit la bonne approche à faire. L'inverse aussi. Les devs au niveau ont beaucoup de choses à nous apprendre, finalement, on l'a vu, un exemple vraiment aussi là encore simple, le langage Rust, donc quelque chose qui est très bas niveau, qui est très utile maintenant pour les back-end web, etc. Dans la communauté Rust, il y a eu plein de développeurs Ruby qui sont arrivés à un moment sur ce langage. Et cette communauté, qui est un langage plutôt haut niveau, qui est utilisé pour faire des sites web, entre autres, ils ont amené énormément de sémantiques dans la lib standard. Ça, finalement, cet apport-là, il est aussi extrêmement important. C'est-à-dire qu'à des moments, prenez le code du kernel, regardez n'importe quel fichier, regardez le nom des variables, c'est pas toujours très lisible. La sémantique elle y est pas toujours le nom des fonctions n'est pas forcément très explicite, on voit bien que ça il y a des best practices aussi du monde du haut niveau, qui sont vraiment, qui coûtent rien en termes de performance mais qui sont bonnes à prendre donc non non au contraire je pense pas qu'il faut diviser les deux mondes chacun a ses objectifs. Et je pense que c'est intéressant plutôt qu'on essaye de se comprendre parce que même si on a des différences, on a aussi beaucoup de choses en commun on l'a vu sur les outils, l'écosystème à la fin le produit final quand on a un site web qui tourne qui tourne mettons sur un cloud AWS il y a aussi bien, le kernel qui fait tourner le serveur plus le conteneur qui est géré par du bas niveau qui va amener le service à un développeur web qui va développer son micro service au dessus etc, donc les deux sont quand même liés à l'arrivée.
Bruno:
Ils.
Christophe:
Ne se rendent pas toujours compte mais le lien est là pour autant.
Bruno:
Aussi dans le haut niveau quand on commence un projet web mettons avec le framework Symfony dans un environnement PHP ou avec du React, framework ou librairie ça c'est un autre débat mais tu vois on embarque on commence déjà par installer un repo d'un framework ou d'une librairie existante du coup on embarque tout un tas de trucs qui vont peut-être jamais nous servir, et on commence du coup à coder dans cet environnement là donc on a un truc déjà un peu tout fait qui nous mâchent le travail sur beaucoup de choses. C'est-à-dire qu'au-delà de l'abstraction apportée par le langage en tant que tel, on a aussi cette abstraction qui est portée par le framework ou l'environnement qu'on utilise... Encore une fois question très néophyte est-ce que vous c'est la démarche inverse quand tu prends par exemple quand tu crées comme ça, une carte ultra wideband est-ce que toi du coup ton travail au contraire c'est que tu prends le kernel Linux tu retires tout ce que tu vas pas utiliser et tu commences après juste à tweaker de manière très, schématique au final une carte ultra wideband c'est une puce réseau comme une autre c'est juste que le flux de données est tout à fait le même donc est-ce que du coup tu prends le truc d'une carte Ethernet standard. Et tu tuques un peu pour t'adapter à l'environnement whiteband, mais du coup, tu vires tout le reste.
Christophe:
Alors, c'est assez différent, mais je comprends l'image. Au niveau de l'ultra-whiteband, c'est vraiment différent, on va dire, d'une carte réseau, donc on ne peut pas vraiment l'associer telle qu'elle. Mais l'idée, c'est savoir, est-ce qu'on a des briques qu'on réutilise de notre côté régulièrement ? La réponse, c'est oui, mais ce n'est pas toujours évident. Quand tu parlais justement du kernel Linux qu'on tweake, etc., effectivement c'est une problématique dans tous les projets généralement qui ont un Linux embarqué c'est l'optimisation du temps de boot et la première chose qu'on va faire c'est on va virer tout ce qu'on peut virer donc tous les services qui ne sont pas nécessaires, par configuration on va les enlever pourquoi ? Parce que ça fait un code qui est plus petit comme généralement ce qui va se passer c'est qu'il va être chargé en RAM pour s'exécuter c'est plus rapide à charger donc derrière c'est du gain de démarrage donc effectivement, il y a un côté un peu élagage, c'est à dire que du code qui n'est pas nécessaire ne devrait pas être présent, je dis pas que sur des sites web ou autre ça devrait être le cas mais, on n'est pas forcément effectivement à se dire est-ce que ça va rentrer sur mon espace de stockage alors que dans du très bas niveau, c'est le cas.
Bruno:
Est-ce que du coup, aussi, il y a cette... Au-delà de se dire, en fait, ce que je garde, ce que je garde pas... Parce que, pareil, quand on dev dans un environnement web, notamment quand tu fais du node, tu importes des packages un peu n'importe comment, qui du coup importent eux-mêmes des packages, qui parfois importent aussi des packages. Donc tu as une espèce de réaction en chaîne qui se crée. Est-ce que vous, vous avez aussi cette logique-là de récupérer du code existant, ou est-ce que du coup à chaque fois, tu vas prendre une inspiration et tu réécris tout pour être vraiment sur ce travail d'Orphèvre, d'effectivement être à l'octet près et à la microseconde prête d'exécution ?
Christophe:
Ça va dépendre des produits. Si je prends un produit embarqué qu'on peut retrouver dans une voiture, un système de multimédia, avec un Linux, on va récupérer des librairies. Il n'y a aucune raison de réécrire tout. C'est un Linux. Il y a plein de choses qui existent. Tant mieux, autant le récupérer. Par contre, on va vraiment choisir que ce qui est nécessaire, même dans les dépendances, etc. Pour des raisons aussi de sécurité pas que de place mais de la surface d'attaque, sur des produits vraiment IoT très contraints c'est le cas par exemple de nos puces non c'est pas possible il n'y a pas la place donc globalement on peut récupérer des dépendances externes, Mais généralement, pour ce qu'on a à faire, la seule dépendance vraiment externe, c'est l'OS, qui vient souvent déjà avec un certain nombre de fonctionnalités qui nous sont utiles. Et c'est souvent bien suffisant.
Bruno:
Il y a une question dans le chat qui est intéressante, c'est à quel point tu peux passer d'un environnement à un autre quand tu fais du dev bas niveau ? À quel point tu peux comme ça passer d'un, quand tu as appris, tu parlais tout à l'heure des piles réseau, mais au-delà de ça, j'imagine que vous avez quand même des technos, des frameworks, des environnements, à quel point tu peux passer de l'un à l'autre ?
Christophe:
Ce n'est pas si compliqué que ça de passer, on va dire un élément assez contraignant, ça va être l'operating system, donc je parlais de Linux, Zephyr qui est aussi plus un RTOS, minimaliste pour l'IoT, il y a FreeRTOS. Finalement, passer d'un Zephyr à un FreeRTOS, il y a des vraies différences. Ils ne viennent pas tous avec les mêmes fonctionnalités pour le coup. Mais les mécanismes de base, c'est-à-dire la manière dont va gérer le scheduling de tâches, la gestion de la mémoire, etc., ça, c'est toujours assez similaire, finalement. Donc, ces concepts de base, ils sont assez communs. Ça ne demande pas un réapprentissage. il y a peut-être un peu d'API à apprendre mais bon ça se fait assez bien. Par contre finalement ce qui demande le plus d'apprentissage on en revient toujours à la même chose c'est le hardware sur lequel on tourne c'est à dire que quand c'est une petite carte qui tourne sur un processeur Cortex-M c'est pas la même chose qu'un téléphone qui tourne sur un Cortex-A, qu'un algo enfin qu'un PC qui est sur un x86 ou même maintenant les M1 ou M2 chez Apple Sous-titrage Société Radio-Canada, finalement, chaque architecture processeur va amener aussi des contraintes. C'est-à-dire en fonction, très simplement, combien de cœurs j'ai ? Est-ce que j'ai un cache de data ? Est-ce que j'ai un cache d'instruction ? Donc, est-ce que je peux l'utiliser ? Est-ce que je vais devoir développer avec ? Finalement, passer d'un projet à un autre, c'est souvent... Si ça reste dans un OS et une architecture similaire, c'est pas très.
Bruno:
Compliqué par.
Christophe:
Contre si on change d'architecture hardware ça peut être beaucoup plus compliqué finalement ça dépend des cas.
Bruno:
Donc par exemple je peux passer d'un projet de drone qui est dans un environnement Unix à je vais essayer de trouver autre chose un projet de caméra de vidéosurveillance, qui est aussi dans un environnement X ? Ça reste à peu près la même ?
Christophe:
Oui, au niveau des technologies, on va retrouver beaucoup de choses communes, le même type d'OS. Il ne va pas y avoir vraiment de tickets à l'entrée pour les développeurs pour passer d'un système embarqué à un autre, on va dire, tant qu'on reste dans des systèmes hardware proches et des OS aussi qui connaissent.
Bruno:
OK. L'histoire du dev a commencé avec les cartes perforées. On a eu après les premiers processeurs en tant que tel, il y a eu la programmation de portes logiques, donc les gens qui programaient directement le processeur, en binaire ou en hexa après il y a eu l'assembleur, maintenant effectivement on est sur du C, après on est monté dans les couches on l'a déjà évoqué est-ce qu'au final un dev bas niveau en 2023 c'est encore un dev bas niveau ?
Christophe:
C'est toujours un dev bas niveau parce que finalement il va quand même devoir avoir les problématiques de contraintes de performance, de connaître le hardware par contre c'est vrai que les frameworks, pour faire une analogie finalement avec le web se sont énormément complexifiés Linux par exemple ça a explosé en termes de taille en termes de fonctionnalité que ça embarque c'est devenu quelque chose de complexe de la même façon, les architectures hardware elles-mêmes aussi se sont complexifiées. On en parlait, les processeurs, les derniers, je sais plus c'est Intel, AMD qui contiennent 64 coeurs, ils veulent monter à 128 coeurs, avec les architectures ARM on voit que ça va risque d'augmenter encore plus. Donc on voit quand même que le hardware lui-même s'est énormément complexifié et surtout derrière, On a des contraintes, certes, qui sont toujours les mêmes de performance, mais ce qu'on demande à chaque appareil est encore plus grand, finalement. Donc, les méthodologies, les langages n'ont pas forcément tant que ça évolué. Mais par contre, un développeur d'aujourd'hui n'est pas un développeur d'hier.
Bruno:
Est-ce que vous vous passez encore beaucoup de temps sur de l'assembleur en direct ? Vous créez l'assembleur ou vous êtes plutôt sur du C majoritairement ?
Christophe:
Non on est sur du C majoritairement ça peut arriver des fois pour certaines routines d'instruction d'avoir un petit bout en assembleur mais honnêtement c'est vraiment de moins en moins le cas, généralement on va être sur du C et même maintenant je dirais il y a des langages, comme Rust qui arrivent qui amènent finalement une richesse du haut niveau à du bas niveau donc c'est une nouvelle évolution finalement, énorme et plein de possibilités qui s'ouvrent.
Bruno:
Et à quel point ça chamboule l'écosystème justement tu nous parles effectivement de ces assembleurs, on parle quand même de technos qui sont éprouvés, qui sont là depuis un petit moment donc j'imagine qu'il y a des habitudes qui se sont aussi instaurées avec ça, Rust c'est à quoi ça a moins de 10 ans, je crois que c'est à 7 ans 8 ans, quelque chose comme ça on parle du coup quand même d'une techno très récente, à quel point est-ce que c'est bien perçu, mal perçu est-ce qu'il y a des développeurs ou développeuses un peu plus anciennes qui ont tendance à avoir ça du mauvais oeil tu vois comment ça s'est accueilli.
Christophe:
Alors c'est Rust il porte bien son nom, finalement il amène beaucoup de concepts très éprouvés donc c'est de la modernité mais pas n'importe comment non plus, Pour se rendre compte un petit peu de la percée de Rust, et notamment dans le bas niveau, il faut voir que c'est le seul langage aujourd'hui qui vient d'être ajouté au carnet de Linux. Le principal mainteneur et créateur, Linux Torval, avait refusé catégoriquement le C++, Go, on n'en parle même pas, ou d'autres langages relativement, ce qu'on appelle système, avaient été discriminés et c'était hors de question. Rust, finalement, réussit à pénétrer le kernel Linux. Ce n'est pas pour rien, finalement. Ce n'est pas pour rien parce que c'est un langage qui reste très bas niveau, qui ne cache absolument pas les problématiques bas niveau. Du coup, c'est très pédagogique, même pour des développeurs plus haut niveau, de se frotter à Rust, je trouve. Après, au niveau des développeurs eux-mêmes, c'est assez, amusant finalement les premiers développeurs à s'être emparés de Rust c'est pas les développeurs bas niveau parce que eux ils se sont dit pourquoi réapprendre quelque chose qui fait la même chose que ce que je fais déjà aujourd'hui, Au bout d'un moment, généralement, quand on commence à creuser Rust, on se dit « Ah oui, mais quand même, il y a plein de concepts qui sont excessivement intéressants. Ça serait dommage de passer à côté. Ça permet d'écrire un code peut-être encore plus lisible, plus high-level, tout en gardant des performances bas-niveau. » Mais c'est vrai que les développeurs bas niveau font finalement les derniers à 6 mètres, paradoxalement.
Bruno:
Question qui vient du chat. Quel avenir pour les puces hybrides, avec un cœur qui mélange CPU et FPGA ?
Christophe:
Moi, à titre personnel, je pense que c'est une forme d'avenir. Il y a toujours dans les architectures processeurs. Jusqu'à présent on avait beaucoup des corps généralistes, donc c'était un peu les architectures x86 qui savent tout faire plutôt bien mais voilà, moyennement ils excellent pas non plus dans un domaine particulier aujourd'hui finalement pour être vraiment bon dans quelque chose, c'est bien d'ajouter des coeurs spécialisés donc c'est un peu ce qu'on a dans les socs aujourd'hui sur les téléphones, qui embarquent du GPU qui embarquent d'autres choses, de la sécurité ou autre. Et on voit que ce type d'architecture, ça arrive aussi maintenant dans le monde du PC classique, avec Apple notamment. Pourquoi ? Parce que souvent, le fait d'avoir tout dans la même puce, ça va amener des performances énergétiques qui sont intéressantes. Alors du Green IT, c'est quand même important. Et mettons, on a de plus en plus d'IA aujourd'hui partout. Si on veut correctement utiliser l'IA c'est bien d'avoir une puce qui gère spécifiquement, la manière dont fonctionne aujourd'hui par exemple les réseaux de neurones on a des puces qui s'appellent des tpu des tensor processor unit elles sont c'est un peu comme des cartes graphiques optimisées finalement pour les réseaux de neurones on voit que ça amène de la performance, pour des produits contraints qui consomment moins d'énergie, donc à mon sens c'est une forme d'avenir peut-être pas pour tous les architectures, je ne suis pas sûr que dans le cloud c'est forcément le même intérêt.
Bruno:
Est-ce qu'au final cette séparation de la restabilité, donc avec des puces comme ça qui ont chacune une tâche précise est-ce que ce n'est pas un petit peu le micro-service du bas niveau.
Christophe:
Un petit peu effectivement ça serait la notion est assez proche euh, Aujourd'hui, même au niveau hardware, on essaye de voir comment faire des puces qui pourraient un peu se reprogrammer. Et donc là-dessus, on voit, on pourrait voir ce genre d'architecture. On a des types d'architecture hardware et donc qui vont se décliner aussi dans la manière dont on va concevoir le software, qui effectivement nous imposent un peu avoir des blocs comme ça réutilisables, un peu des services. Donc effectivement, on retrouve un peu cette notion. sous une autre forme, mais l'analogie est là.
Bruno:
Merci. Est-ce que, pour toi, il y a une compétence particulière à avoir pour être dev bas niveau par rapport à... Tu vois, une des questions que j'ai évoquée en intro, c'était est-ce que le dev bas niveau est un dev comme les autres ? Est-ce qu'il y a un truc en plus à avoir par rapport à un dev web, par exemple ?
Christophe:
Ouais, j'hésiterais comprendre le hardware. La plupart des devs que, j'encadre savent lire un schéma électronique comprennent ce que font une résistance, pour faire une pull up ou une pull down des notions comme ça comment ça va se traduire finalement dans le software derrière qu'on va utiliser, ça ne veut pas dire que c'est des experts de l'électronique qui connaissent toutes les, toutes les problématiques pour ça il y a des ingéhardware mais comprendre un schéma électronique je pense que c'est déjà une base et après la deuxième problématique c'est, qui va être vraiment une connaissance associée c'est la performance, on en a parlé juste depuis le début mais souvent la performance tout le monde entend la performance en termes de processing mais c'est pas vrai il y a aussi la performance en termes de taille mémoire et aussi la performance en taille enfin de coûts énergétiques d'une puce.
Bruno:
Mais ça, c'est assez nouveau, cette problématique du coût énergétique. Ça date des laptops et des téléphones, surtout, qui ont du coup une quantité d'énergie limitée.
Christophe:
Je ne sais pas si ça n'existe que depuis cette époque-là, mais en tout cas, ça s'est vraiment révélé énormément à ce moment-là. Effectivement, aujourd'hui, on va avoir un téléphone qui a une autonomie de deux jours. Il faut que la puce Bluetooth, Wi-Fi, le processeur consomme moins. Point. On pourra faire tout ce qu'on veut au niveau logiciel au dessus, si par conception déjà les puces ne consomment pas moins ou ne permettent pas de couper, des fonctions pour se mettre en mode de sommeil on ne pourra pas faire grand chose à part mettre une plus grosse batterie on sera assez limité.
Bruno:
Et au final ce que tu évoquais tout à l'heure sur cette capacité du dev bas niveau à lire un schéma électrique, en fait on revient un peu à cette discussion qu'on avait avant de commencer l'enregistrement cette vision un peu plus large qu'il faut avoir quand tu es développeur de pas juste connaître son langage son écosystème c'est de réussir à connaître un petit peu plus que ça est-ce qu'au final c'est pas, la caractéristique qui fait la différence entre un ou une bonne développeuse versus un ou une développeuse moins efficace Effectivement.
Christophe:
Aujourd'hui le langage principal qui est utilisé c'est le C, c'est un langage, il y a très peu de meuclés, c'est pas un langage, même si pour certains ça paraît pas évident, mais c'est pas un langage compliqué le C. Bon, pour développer, il faut tout redévelopper en général, mais c'est pas un langage qui amène une vraie complexité. Par contre, comprendre le système et l'utiliser de manière optimale, ça, c'est une expertise aujourd'hui.
Bruno:
Est-ce que tu penses que tous les développeurs devraient se frotter un peu au bas niveau ?
Christophe:
Je pense d'une façon ou d'une autre. Pas forcément aller voir ce qui se passe dans le kernel. Mais ne serait-ce que comprendre combien leur programme est en train de prendre en termes de taille mémoire, d'allocations de processing en fait ces notions là elles sont importantes et je pense que autant les développeurs bas niveau ça leur paraît évident, autant c'est vrai que dans le monde du haut niveau. Il y a eu un petit peu le coût du processing était pas cher pendant un moment, à un moment quand on voulait aller plus vite on rajoutait du processing, on scalait avec le cloud etc ça c'était bien parce qu'effectivement avoir quelqu'un qu'on va payer pour faire de l'optimisation c'est compliqué, si derrière le code change tout le temps, les features changent tout le temps il va avoir du mal à faire bien son travail et il va coûter finalement plus cher que juste payer un cluster en plus mais aujourd'hui on voit que le coût de l'énergie c'est tout à fait le même, donc ces problématiques là de rendre des systèmes un peu plus efficients, revient énormément, c'est pour ça qu'on parle beaucoup du Green IT ? Et finalement, à ce niveau-là, tout le monde doit en être responsable d'une manière ou d'une autre. C'est-à-dire que le Green IT, ça ne repose pas juste sur la personne qui a conçu le Data Center et qui fait tourner ses serveurs Linux, c'est aussi l'application qui tourne dessus. Dans le haut niveau, on entend souvent parler, pour le web, des co-routines développées de manière asynchrone. effectivement si on peut. Ne pas scéduler on va dire plein d'opérations en attendant qu'on ait une réponse, mais qu'on lance tout en parallèle on sait qu'on va être quand même beaucoup plus efficace et ça va prendre beaucoup moins de temps à la fin à s'exécuter donc, je dirais que ça s'exprime sous différentes formes mais la notion finalement de performance reste la même malgré tout Ok.
Bruno:
Pour un ou une développeuse haut niveau qui aurait envie de se frotter un peu à ces sujets de bas niveau, qu'est-ce que tu conseillerais ? Est-ce qu'un Raspberry Pi, un Arduino, est-ce que c'est un bon moyen de commencer ? Est-ce que s'attaquer au kernel Linux, il faudra peut-être un petit peu plus de bouteilles ? Qu'est-ce que tu conseillerais pour commencer ?
Christophe:
Effectivement Raspberry Pi ça peut être pas mal mais c'est devenu aussi complexe on se rend pas compte la puissance qu'il y a dans un Raspberry Pi les derniers, l'Arduino je trouve que c'est bien parce que, c'est très bar métal dans l'esprit donc c'est vraiment minimaliste c'est assez peu puissant c'est assez contraint c'est pas très dur à programmer il y a même des surcouches en Python, on peut programmer en Python dessus Donc, je pense que c'est assez intéressant. Ce n'est pas cher, en plus. Donc, on peut en acheter un, faire des essais. Je n'irais pas faire de la domotique chez soi, forcément, tout de suite. Mais je pense que c'est quelque chose qui est abordable. Aussi bien techniquement que l'environnement, tout a été fait pour que ça soit facile à faire. Raspberry Pi... C'est déjà l'étape d'après pour moi.
Bruno:
D'accord, pour toi, c'est du haut niveau presque, le Raspberry ?
Christophe:
Ce n'est pas du haut niveau, mais c'est un peu un entre-deux. Il y a quand même tout un kernel. Oui, un développeur bas niveau va essayer d'optimiser le temps de démarrage, faire un kernel sur mesure, piloter des GPIO, des choses comme ça qui sont sur le Raspberry. Par contre, dessus, on peut faire tourner un Ubuntu avec des applis graphiques, avec du Qt, avec un site web, pourquoi pas. donc là on est déjà.
Bruno:
Plus dans.
Christophe:
Le bas niveau.
Bruno:
On est très très haut, pour terminer moi il y a aussi un truc que je trouve assez fascinant, dans les différences qu'il y a entre le bas niveau et le haut niveau en tout cas de ma perception c'est que moi quand je crée un site web, je change quelques bouts de code j'ouvre mon navigateur, je fais un refresh et puis je vois le résultat immédiatement et de ma perception en tout cas quand tu fais du dev bas niveau t'as pas ce retour aussi médié de ce que tu fais, j'ai quand même l'impression qu'il faut déjà avoir fait plus de choses avant de pouvoir voir des résultats et que la mesure du résultat est plus complexe que juste faire, un refresh sur un navigateur je me trompe ou ?
Christophe:
Non non tu te trompes pas, effectivement à des moments, voir le résultat d'une optimisation par exemple qui a pu être faite c'est pas si simple que ça, parce que ça va demander des outils de mesure ces outils peuvent être aussi intrusifs donc affecter finalement la performance d'une certaine manière on va avoir aussi, Quand on est vraiment sur des séquences, mettons des pilotages de montée d'alim, etc., parce qu'on doit driver un sensor, finalement, la seule façon de s'en rendre compte, c'est brancher un oscilloscope et regarder qu'on lève bien les GPIO, par exemple, avec le bon timing, la bonne séquence qui est mentionnée dans la Tata Sheet. Ce genre de choses là, on ne s'en rend pas forcément compte effectivement on n'a pas tout de suite sur son bureau, le résultat instantanément on peut l'avoir parce qu'on a quand même des outils qui nous aident mais en fonction de ce qu'on veut faire non, et des fois ça peut être aussi un peu frustrant parce que on n'a pas un retour direct par contre ce qui est assez passionnant c'est qu'on a l'objet souvent dans les mains mais.
Bruno:
T'as une version t'as un prototype de l'objet en général non ? T'as quelque chose d'assez rudimentaire qui est peut-être pas forcément la version finale ?
Christophe:
Pas tout le temps ça dépend des types de produits, on peut avoir des versions plus on avance finalement dans un projet plus à la fin on va avoir les produits quasi définitifs voire définitifs ok.
Bruno:
Top merci beaucoup Christophe, j'aurais quelques questions rituelles pour toi la première c'est est-ce qu'il y a un contenu que tu aimerais partager avec l'ensemble des auditeurs soit tech ou non tech.
Christophe:
Ouais alors j'aurais déjà je pense que le Rustbook qui est un peu le guide du Rust et notamment il a une partie embedded je pense que c'est quelque chose qui peut être intéressant pour quelqu'un qui vient du haut niveau pour comprendre un peu des aspects mémoire par extension, moi j'aime beaucoup les conférences en ligne donc je trouve que celles de la Cppcon sont très bien il y en a vraiment plein des passionnantes, ou celles de la Linux Foundation, puisqu'on va retrouver aussi bien sur Linux que sur Zephyr, vu que ça appartient à la Linux Foundation. Et elles sont souvent assez pédagogiques. Et après, ça c'est plus maintenant ma carrière de manager, mais il y a des livres, je trouve, qui sont assez inspirants aujourd'hui. Rien de fancy, c'est Manager Pass de Camille Fournier. On va retrouver aussi Staff Engineering où il y a un site, je le recommande, qui concerne finalement la carrière des seniors et plus, c'est-à-dire vraiment des personnes qui sont un peu expertes d'une certaine manière. Donc voilà, si c'est des ressources que vous n'avez jamais vues, je vous conseille.
Bruno:
Ça fait déjà pas mal de ressources qu'on mettra bien évidemment en description de cet épisode pour que tout le monde puisse les retrouver facilement. Dernière question pour toi, quelle est la question rituelle du podcast SIFTTD ? Est-ce que tu es plutôt espace ou tabulation ?
Christophe:
Je suis espace, mais j'adore moi avoir un système qui m'auto-formate type ces langues pour ne pas me poser de questions, ces langues formatent.
Bruno:
Merci beaucoup Christophe pour cet échange. merci et merci à tous d'avoir écouté cet épisode jusqu'au bout, merci aussi à Divin Hadès qui précise que son. Que son ex-chef présente toujours aussi bien dit-il dans le chat sur Twitch j'aimerais remercier aussi alors j'ai que le handle Twitter mais c'est JobZero c'est sur Mastodonde qui a mis un petit commentaire sympa sur Twitter en rediffusant un épisode de DIVTTD, donc merci beaucoup à toi et merci à tous aussi de partager ce podcast autour de vous bien évidemment ce qui me permet de continuer à faire des épisodes toujours aussi. Aussi fun et de rencontrer des tas de gens sur des tas de techno et d'apprendre plein de choses et j'espère que vous aussi je vous remercie beaucoup en tout cas d'avoir écouté cet épisode jusqu'au bout, je vous souhaite une très bonne fin de semaine je vous dis à la semaine prochaine et d'ici là collez bien.
