En même temps… c'était le prix Turing. Donc pas vraiment le lieu pour la pratique!
Pour le reste, quelque soit le domaine quasiment l'intégralité de ce qui est fait en bas niveau l'est désormais chez les fondeurs. Tout simplement car ils en ont besoin pour tester eux-mêmes (et des composants de plus en plus complexes) et que le logiciel libre (à travers de projets comme u-boot ou l'horreur EDKII, qui si Intel ne s'y était pas collé n'aurait jamais pu déployer un UEFI si inutilement complexe que de plus en plus de monde cherche à le remplacer…) offrait un cadre à mutualisation qui est aussi devenu un élément concurrentiel.
Ajoutons que chez certains (Intel pour ne pas le nommer), cela permet aussi de bâcler les docs: On fournit le code, prenez le donc et foutez nous la paix. De toutes manières notre support est nul!
Bref, vous achetez le dernier SoC de chez Cavium ou Freescale et le u-boot de la carte de référence sera donné, certes à adapter à votre matériel mais ça tourne et a un niveau ou le debug se fait à la bite et au couteau, mine de rien par rapport à il y a 20 ans ca compte. Surtout avec la complexité croissante des chips.
Côté Intel, on refusera tout support bas niveau, ne fournissant même pas les firmwares non signés (sauf à se faire vraiment botter le cul) et vous enverra vers un fournisseur de BIOS qui, en fait, n'est plus qu'un intégrateur du EDK2 fourni par Intel, des reference code (RC) de la plateforme (en particulier le gros morceau du MRC chargé de l'init DDR, faite toute en soft chez Intel contrairement à d'autres ou c'est un paramétrage et un enable suite auquel le hardware se démerde pendant quelques dizaines de ms et roule) également fournis par Intel (c'est la version source du FSP, qui permet à coreboot d'exister, mais avec qq API manquantes pour un projet industriel, c'est conçu pour!)… auquel on ajoute quelques libs (crypto etc) sous licence MIT et les petits ajouts cosmétiques d'un AMI/Insyde/Poenix ainsi que l'IDE qui va avec. Tout ceci bien entendu traînant sa chaîne de compilation: Intel pour le pur Intel (RC), Microsoft pour EDK2 (même si GCC semble utilisable ici) et le code de l'éditeur, GNU pour les libs libres.
Sur ce dernier point, proprement ahurissant de complexité inutile, on est sur EDK2 en implémentation de référence sur un nb de lignes de code comparable au kernel Linux. Pour un boot loader qui est loin derrière niveau fonctionnalités. Il faut dire qu'avec ses 3 phases (SEC/PEI/DXE) relativement étanches, pas mal de choses utiles aux trois doivent en réalité être codées en autant d'exemplaires.
=> La majorité du boulot en UEFI… c'est l'infra UEFI elle-même. Pas vraiment du bas niveau dont Intel se charge entièrement et fait tout pour que ça dure.
Niveau GPU, je ne connais pas personnellement mais je ne pense pas que grand chose sorte de chez NVIDIA ou AMD.
Il n'y a pas des dizaines de milliers de personnes, principalement chez un nombre de fondeurs principaux se comptant sur les doigts d'une main, sur ce qui tape vraiment bas.
Niveau sécurité, je ne crois pas qu'il y ait grand chose à relativiser dans sa prise en compte: Sa présentation à réception de son prix Turing est d'ailleurs fondatrice dans le domaine.
Pour le reste, combien de personnes sont encore capables actuellement de coder un truc bare-metal, sans dépendances plus ou moins maîtrisées ni système de build tordu pour faire tomber tout cela en marche (avec le moindre "hello world" qui en sorte pesant quelques dizaines de MB)? Quelques centaines de personnes peut-être sur la masse mondiale des codeurs divers, sans doute plutôt désormais à rechercher chez les fondeurs dans les équipes qui supportent leurs reference design et spécialisées dans le démarrage initial d'un processeur… et pas vraiment pour faire un OS complet derrière.
J'en parle, certes sans grande expérience de ce langage, car je trouve vraiment dangereux d'avoir a ce point voulu imposer une présentation propre (ce qui en soit se défend) aux dépens de la robustesse du langage (ce qui est indéfendable).
Surtout, encore une fois, que sans délimiteurs aucun outil ne peut décider automatiquement comment corriger le tir. Du C formaté cochon, en quelques milli-secondes c'est rectifiable automatiquement. Si on fait des "beautifier" de source, c'est justement pour ne pas s'emmerder à cela. Des boites les passent automatiquement, d'ailleurs, pour imposer sans douleur cette partie des règles de codage dès qu'on check-in des modifications de sa branche de dev. Simple et efficace. On peut même quand on prends des sources y coller son formatage préféré car on a le cerveau cablé depuis des années dessus, sans impact pour les autres. C'est la différence entre la mentalité BDFL, ou pas!
D'autres ont souligné plus haut que python 3 semble ne plus vouloir interpréter des lignes mixant tabulations et espaces. Comme quoi je n'ai pas dû être le seul à pester là dessus et j'espère même que cette vérification est faite au niveau du source complet. Sinon une ligne ajoutée en fin de bloc pré-existant avec un éditeur non configuré à l'identique du précédent peut aussi poser problème.
Tout source passé par plusieurs éditeurs dont au moins un n'était pas configuré pour transformer les tabulations en espace peut poser le problème sur la/les lignes de fin de bloc.
Je ne crois par ailleurs pas avoir dit que C était plus fiable que Python. Juste que sauf bug compilo ou processeur, au moins il fait toujours ce que le programmeur voit dans son éditeur préféré. Qu'on l'évite de plus en plus partout ou il est évitable ne me pose pas de problème, mais bon, travaillant au ras des pâquerettes c'est forcément 99% de ce que je produis et si ca n'avait pas été le cas, n'importe quel autre langage utilisant des délimiteurs (cad l'immense majorité) aurait pu être pris en exemple.
Vu comme on nous flique sur ce qu'on livre, surtout depuis 10 ans que blackduck repère/colle une licence sur chaque bout de code y compris compilé (=> à partir de là, n'importe quel concurrent faisant un dump de votre firmware s'il y trouvait un bout de code GPL pouvait vous obliger à en publier des pans entiers ou vous bloquer niveau vente!), pas de risque d'aller à la pêche sur le net.
Je n'ai pour ma part en effet fait que du 2, essentiellement pour de petits outils/scripts ou le shell montrait ses limites…
Bonne chose que cela ait été corrigé en 3. Désormais, je passe un "expand -t 8" dès que je récupère un source pour voir visuellement si un truc se décale. Mais c'est vraiment fastidieux car cela oblige à comprendre chaque bout de source ou le problème se présente pour savoir de quel côté il faut mettre la/les lignes en question.
Astyle reformate n'importe quel code C au goût de celui qui le reprends, sans erreur possible.
Forcément, là le style on s'en fout car la grammaire est robuste.
Délimiter les blocs avec des indentations est LA très mauvaise idée du Python ayant mené à des tétra-chiées de bugs sans doute fort coûteux.
Après cela, on a beau jeu de dire que le C est dangereux…
Ce qui éviterait d'avoir l'interpréteur qui exécute parfois un code qui n'est pas celui présenté visuellement à son auteur.
Ne pas avoir voulu mettre de délimiteur de bloc amène à cette situation. C'est certes volontaire pour pousser à présenter correctement, mais c'est hyper dangereux: Le nb de fois ou j'ai eu la fin d'un bloc qui était sorti du bloc après édition avec des éditeurs configurés différemment, sans que visuellement cela apparaisse.
Et sur un langage avec délimiteurs (genre {} en C), les outils automatiques permettent de reformater sans problème. Pas avec Python: Il faut avoir en tête ce que fait le programme pour savoir s'il y a un truc qui sort du bloc pour des questions de présentation ou non.
Le genre de "détail" qui flingue un langage pour une utilisation ou la fiabilité est fondamentale.
Se rendre compte qu'il y a un problème le jour ou la branche de code interprétée de travers (vs sa représentation visuelle) est exécutée, c'est vraiment un problème.
Un programme C mal présenté: Astyle s'en sort toujours. En Python, non.
[^] # Re: Relativisons
Posté par lym . En réponse à la dépêche Portrait de Ken Thompson. Évalué à 0.
En même temps… c'était le prix Turing. Donc pas vraiment le lieu pour la pratique!
Pour le reste, quelque soit le domaine quasiment l'intégralité de ce qui est fait en bas niveau l'est désormais chez les fondeurs. Tout simplement car ils en ont besoin pour tester eux-mêmes (et des composants de plus en plus complexes) et que le logiciel libre (à travers de projets comme u-boot ou l'horreur EDKII, qui si Intel ne s'y était pas collé n'aurait jamais pu déployer un UEFI si inutilement complexe que de plus en plus de monde cherche à le remplacer…) offrait un cadre à mutualisation qui est aussi devenu un élément concurrentiel.
Ajoutons que chez certains (Intel pour ne pas le nommer), cela permet aussi de bâcler les docs: On fournit le code, prenez le donc et foutez nous la paix. De toutes manières notre support est nul!
Bref, vous achetez le dernier SoC de chez Cavium ou Freescale et le u-boot de la carte de référence sera donné, certes à adapter à votre matériel mais ça tourne et a un niveau ou le debug se fait à la bite et au couteau, mine de rien par rapport à il y a 20 ans ca compte. Surtout avec la complexité croissante des chips.
Côté Intel, on refusera tout support bas niveau, ne fournissant même pas les firmwares non signés (sauf à se faire vraiment botter le cul) et vous enverra vers un fournisseur de BIOS qui, en fait, n'est plus qu'un intégrateur du EDK2 fourni par Intel, des reference code (RC) de la plateforme (en particulier le gros morceau du MRC chargé de l'init DDR, faite toute en soft chez Intel contrairement à d'autres ou c'est un paramétrage et un enable suite auquel le hardware se démerde pendant quelques dizaines de ms et roule) également fournis par Intel (c'est la version source du FSP, qui permet à coreboot d'exister, mais avec qq API manquantes pour un projet industriel, c'est conçu pour!)… auquel on ajoute quelques libs (crypto etc) sous licence MIT et les petits ajouts cosmétiques d'un AMI/Insyde/Poenix ainsi que l'IDE qui va avec. Tout ceci bien entendu traînant sa chaîne de compilation: Intel pour le pur Intel (RC), Microsoft pour EDK2 (même si GCC semble utilisable ici) et le code de l'éditeur, GNU pour les libs libres.
Sur ce dernier point, proprement ahurissant de complexité inutile, on est sur EDK2 en implémentation de référence sur un nb de lignes de code comparable au kernel Linux. Pour un boot loader qui est loin derrière niveau fonctionnalités. Il faut dire qu'avec ses 3 phases (SEC/PEI/DXE) relativement étanches, pas mal de choses utiles aux trois doivent en réalité être codées en autant d'exemplaires.
=> La majorité du boulot en UEFI… c'est l'infra UEFI elle-même. Pas vraiment du bas niveau dont Intel se charge entièrement et fait tout pour que ça dure.
Niveau GPU, je ne connais pas personnellement mais je ne pense pas que grand chose sorte de chez NVIDIA ou AMD.
Il n'y a pas des dizaines de milliers de personnes, principalement chez un nombre de fondeurs principaux se comptant sur les doigts d'une main, sur ce qui tape vraiment bas.
[^] # Re: Relativisons
Posté par lym . En réponse à la dépêche Portrait de Ken Thompson. Évalué à -4.
Niveau sécurité, je ne crois pas qu'il y ait grand chose à relativiser dans sa prise en compte: Sa présentation à réception de son prix Turing est d'ailleurs fondatrice dans le domaine.
https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
Pour le reste, combien de personnes sont encore capables actuellement de coder un truc bare-metal, sans dépendances plus ou moins maîtrisées ni système de build tordu pour faire tomber tout cela en marche (avec le moindre "hello world" qui en sorte pesant quelques dizaines de MB)? Quelques centaines de personnes peut-être sur la masse mondiale des codeurs divers, sans doute plutôt désormais à rechercher chez les fondeurs dans les équipes qui supportent leurs reference design et spécialisées dans le démarrage initial d'un processeur… et pas vraiment pour faire un OS complet derrière.
Non, sincèrement, je ne vois rien à relativiser!
[^] # Re: Retour sur des grosses applications
Posté par lym . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 2.
J'en parle, certes sans grande expérience de ce langage, car je trouve vraiment dangereux d'avoir a ce point voulu imposer une présentation propre (ce qui en soit se défend) aux dépens de la robustesse du langage (ce qui est indéfendable).
Surtout, encore une fois, que sans délimiteurs aucun outil ne peut décider automatiquement comment corriger le tir. Du C formaté cochon, en quelques milli-secondes c'est rectifiable automatiquement. Si on fait des "beautifier" de source, c'est justement pour ne pas s'emmerder à cela. Des boites les passent automatiquement, d'ailleurs, pour imposer sans douleur cette partie des règles de codage dès qu'on check-in des modifications de sa branche de dev. Simple et efficace. On peut même quand on prends des sources y coller son formatage préféré car on a le cerveau cablé depuis des années dessus, sans impact pour les autres. C'est la différence entre la mentalité BDFL, ou pas!
D'autres ont souligné plus haut que python 3 semble ne plus vouloir interpréter des lignes mixant tabulations et espaces. Comme quoi je n'ai pas dû être le seul à pester là dessus et j'espère même que cette vérification est faite au niveau du source complet. Sinon une ligne ajoutée en fin de bloc pré-existant avec un éditeur non configuré à l'identique du précédent peut aussi poser problème.
[^] # Re: Retour sur des grosses applications
Posté par lym . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 0. Dernière modification le 11 septembre 2019 à 08:45.
Tout source passé par plusieurs éditeurs dont au moins un n'était pas configuré pour transformer les tabulations en espace peut poser le problème sur la/les lignes de fin de bloc.
Je ne crois par ailleurs pas avoir dit que C était plus fiable que Python. Juste que sauf bug compilo ou processeur, au moins il fait toujours ce que le programmeur voit dans son éditeur préféré. Qu'on l'évite de plus en plus partout ou il est évitable ne me pose pas de problème, mais bon, travaillant au ras des pâquerettes c'est forcément 99% de ce que je produis et si ca n'avait pas été le cas, n'importe quel autre langage utilisant des délimiteurs (cad l'immense majorité) aurait pu être pris en exemple.
Vu comme on nous flique sur ce qu'on livre, surtout depuis 10 ans que blackduck repère/colle une licence sur chaque bout de code y compris compilé (=> à partir de là, n'importe quel concurrent faisant un dump de votre firmware s'il y trouvait un bout de code GPL pouvait vous obliger à en publier des pans entiers ou vous bloquer niveau vente!), pas de risque d'aller à la pêche sur le net.
[^] # Re: Pourquoi je n'aime pas Python...
Posté par lym . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 0.
Je n'ai pour ma part en effet fait que du 2, essentiellement pour de petits outils/scripts ou le shell montrait ses limites…
Bonne chose que cela ait été corrigé en 3. Désormais, je passe un "expand -t 8" dès que je récupère un source pour voir visuellement si un truc se décale. Mais c'est vraiment fastidieux car cela oblige à comprendre chaque bout de source ou le problème se présente pour savoir de quel côté il faut mettre la/les lignes en question.
[^] # Re: Retour sur des grosses applications
Posté par lym . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 1.
Astyle reformate n'importe quel code C au goût de celui qui le reprends, sans erreur possible.
Forcément, là le style on s'en fout car la grammaire est robuste.
Délimiter les blocs avec des indentations est LA très mauvaise idée du Python ayant mené à des tétra-chiées de bugs sans doute fort coûteux.
Après cela, on a beau jeu de dire que le C est dangereux…
[^] # Re: Pourquoi je n'aime pas Python...
Posté par lym . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 3.
Ce qui éviterait d'avoir l'interpréteur qui exécute parfois un code qui n'est pas celui présenté visuellement à son auteur.
Ne pas avoir voulu mettre de délimiteur de bloc amène à cette situation. C'est certes volontaire pour pousser à présenter correctement, mais c'est hyper dangereux: Le nb de fois ou j'ai eu la fin d'un bloc qui était sorti du bloc après édition avec des éditeurs configurés différemment, sans que visuellement cela apparaisse.
Et sur un langage avec délimiteurs (genre {} en C), les outils automatiques permettent de reformater sans problème. Pas avec Python: Il faut avoir en tête ce que fait le programme pour savoir s'il y a un truc qui sort du bloc pour des questions de présentation ou non.
Le genre de "détail" qui flingue un langage pour une utilisation ou la fiabilité est fondamentale.
Se rendre compte qu'il y a un problème le jour ou la branche de code interprétée de travers (vs sa représentation visuelle) est exécutée, c'est vraiment un problème.
Un programme C mal présenté: Astyle s'en sort toujours. En Python, non.