Pour avoir un avantage concurrentiel avec des machines qui démarrent beaucoup plus vite, peut-être!
En arriver à passer plus de temps dans le BIOS qu'au démarrage d'un OS complet, c'est quand même un peu le miracle de l'UEFI: 3 phases étanches (SEC, et surtout PEI/DXE), un agglomérat du RC/MRC Intel, EDK2, auxquelles on ajoute le propre code du fournisseur de BIOS (configuration, son code legacy, son système de build mal fichu qui colle plus ou moins bien les morceaux).
On a donc bien souvent des choses écrites quasiment à l'identique dans ces 3 phases et pour les 3 origines possibles (avec de bonnes raisons à cela, le fournisseur de BIOS pouvant utiliser une chaîne de compil microsoft, Intel la sienne et EDK2 GCC).
Forcément, ce n'est pas très efficient. Surtout quand on charge cela (et tous les firmwares obscurs dont Intel raffole) d'une flash SPI.
J'espère de tout coeur que vous réussirez, revenu sur Intel en me bouchant le nez (avec un niveau de support très bas sur ces sujets) après plus de 2 décennies sur le PowerPC dans l'industrie télécoms.
Maintenant, sur des machines destinées à faire tourner Linux, il serait bon de commencer à faire du lourd passé Intel table rase. Le PowerPC crève de la politique d'IBM hélas, mais RiscV progresse…
Le point qui m’intéressait, c'était que ça tourne sur un PI3, je dois dire.
Ce qui m'embêtait, c'est que c'est le serveur qui centralise, son rôle ne se limitant visiblement pas à la gestion des utilisateurs et leur "mise en relation". Ce qui fait que la visio n'est pas là, elle coincerait de toute façons sur une petite config avec un fonctionnement non pair à pair.
Mais si en prime la config est lourde c'est mort pour sortir famille/amis de zoom et autres machins troués… mais qu'un proche de 80 ans arrive à utiliser avec quelques directives simples.
Ce qui manque en fait toujours, c'est vraiment un Skype libre avec un fonctionnement d'avant son sabordage par Microsoft qui l'a tué, comme à peu près tout ce qu'ils rachètent, en le centralisant…
Pour le -fpatchable-function, on verrait une version plus générique du -finstrument-functions de gcc mais à y réfléchir un peu ça semble difficilement utilisable en comparaison, surtout dans un contexte visant plusieurs architectures avec des tailles d'instruction "nop" potentiellement différentes…
Unix est traversé par la pile réseau depuis qu'il existe. Le reste a suivi cette philo et X aussi qui fait le job nativement. Un remplaçant qui retire des fonctionnalités pareilles ça n'aide pas à son adoption et d'ailleurs ça traîne depuis presque 10 ans (je m'étais d'ailleurs fait rembarrer en exposant ce gros manque aux développeurs il y a fort fort longtemps…). Maintenant que ca arrive enfin (pour les installations, pas les upgrades) avec même Debian qui s'y risque, ce qui manque et qui avait pu échapper a des utilisateurs pas forcément branchés sur le dessous du capot de l'affichage graphique va se voir. Et visiblement, certains commencent à y pallier.
Wayland et Gnome (3): Des projets un peu dogmatiques à mon goût et qui n'écoutent qu'eux mêmes… Au final, d'autres ayant des compétences sur les sujets qui fâchent font Cinnamon et waypipe, certes, mais ces attitudes n'aident pas le libre. Tout comme conchier X: Je préfère un truc qui marche à travers le réseau que gagner des FPS au jeu, même si les deux ce serait l'idéal.
Puis la sécurité, c'est un peu l'alibi du siècle. J'attends toujours les ennuis personnellement.
… bien plus réel que l'auteur ne le laisse supposer, à titre personnel je vivrais très mal sans cela:
-En télétravail, je suis habituellement connecté à minimum une machine windows (en RDP) et 2 machines Linux (une saloperie dans le cloud et une physique en lab). Et qu'est-ce qui est le plus chiant: Ce RDP obligeant sous windows à tirer un foutu bureau complet (sans pouvoir avoir le même utilisateur utilisant le bureau en distant et local, + avec un win10 distant des polices généralement floues en distant si la définition de l'écran distant n'est pas identique au local) et d'en avoir au final 2 à gérer au lieu de fenêtres applicatives qui s'y intègrent en organisant ça par bureau virtuel.
Tirer un bureau complet distant, c'est au final de mon point de vue pas très pro, voir carrément très "tata Janine":
-A la maison, même un PI qui gère la baraque avec une raspbian minimale (sans bureau graphique complet, inutile, il est headless) fait du X11 forwarding via SSH, le combo idéal, avec juste le paquet xvfb (X11 frame-buffer) installé dessus: Si on évite les applicatifs issus de gnome/kde tirant des tétrachiées de dépendances, genre des terminaux light comme urxvt et éditeurs graphiques genre nedit, ca permet quand même de travailler dessus de manière bien plus confortable qu'avec des consoles. Avec wayland, je ne sais pas si le même genre de choses sera possible…
De ce point de vue, wayland était une regrettable régression sur l’ancêtre X11 qui fait que tant que X11 sera là, il restera sur mes machines… mais comme ça ne sera sans doute possible qu'un temps, tout ce qui va dans le sens de combler ce foutu manque va dans le bon sens, surtout si on gagne un support de l'accélération graphique au passage.
Le plus incroyable, c'est que cela n'ait pas été fait nativement. Il ne s'agit quand même pas de windows-clicodrome, mais d'un Unice construit depuis les débuts autour de la pile réseau, affichage compris.
Je pense que c'est lié au fait que la génération qui code cela, ne sachant pas vivre sans une IDE Eclipse (personnellement, je fuie), trouve que X11 via le réseau ne fonctionne pas forcément très bien avec des trucs trop complexes graphiquement (mais déjà un peu moins mal en activant la compression à la volée de SSH en plus du X11 forwarding : "ssh -XC toto@machineDistante") et non utilisatrice n'a même pas pensé à essayer de faire mieux de ce point de vue.
Merci en tout cas d'avoir fait connaître cet ajout, surtout en n'en éprouvant pas personnellement le besoin!
Pour ma part, j'avais regardé la dépêche initiale car je recherche une solution de reco vocale hors cloud et GAFA, mais l'utilité étant sur un système domotique headless sans écran/clavier, ni environnement graphique/bureau installé… Je n'avais pas persévéré.
C'est tellement évident que nos records de température de cet été… les modèles basés sur l'effet CO2 les prévoyaient… dans 30 ans!
Alors soit ils sont archi faux et ceux qui sont payés à les affiner depuis des décennies devraient être invités à changer de métier, soit il y a d'autres facteurs bien plus conséquents à un réchauffement que personne ne conteste.
Pour l'effet sécheresse en Australie, c'est un peu comme la vitesse pour la sécurité routière: Un facteur essentiellement aggravant. De là à en éluder encore une fois ce qui cause au profit de ce qui aggrave…
Pour l'article, le fait qu'on ait laissé le bush à l'abandon et bloqué les voies d'accès c'est du factuel.
Si on fait pareil dans les Landes, le résultat est garanti en peu d'années et blâmer le réchauffement tiendra de la prophétie autoréalisatrice.
Partir sur Greta, je pense que c'était partir clivant pour ne pas dire mal. Il n'y a pas que le grand blanc (pour se la jouer verbiage banlieusard) pour regretter sa notoriété éclair et au fond trop belle pour être honnête: Son téléguidage (pas forcément conscient) par les communicants de la croissance dite verte est largement démontré.
Ces vertueux qui jugent bon de produire de l'électricité avec des éoliennes peinant à produire 20% de la puissance théorique installée, ancrées sur plusieurs milliers de T de béton qui resteront quand on décidera d'arrêter de défigurer le paysage ou que les riverains les dynamiteront lassés des nuisances… ou avec des km2 de produit de fonderie silicium hautement énergivore à la production/recyclage logiquement réservés, avant les aides mal inspirées, a l’électrification des sites isolés. Ou prônant la mobilité électrique incarnée par le succès, lui aussi largement subventionné, de la Zoé. Ou comment faire passer pour vertueuse une citadine de 1.5T, illustration d'un monde qui part vraiment cul par dessus tête!
Niveau émissions, pas mieux: Arriver à faire passer la préoccupation d'un non polluant, le CO2, devant le reste des véritables polluants et monter de toutes pièces une économie de sa taxation… Comment dire? Renvoyer aux propos d'Haroun Tazieff qui dénonçait, depuis son passage au ministère alors en charge des risques naturels (et avoir consulté ses archives), les biais voire mensonges éhontés (distrayant l'opinion des vrais problèmes) de la politique environnementale alors balbutiante?
Deux décennies après sa mort le problème s'est bien aggravé. Il avait démonté d'entrée la thèse du rôle des CFC sur la couche d'ozone, que l'on commence à peine actuellement à remettre en cause. Et pas plus cru à la fable de voir quelques centièmes de pourcent de CO2 dans l'atmosphère responsables de changements climatiques majeurs.
Mais en face, on réfléchit quand même encore. Au point de voir, en Australie puisqu'on en parle aussi, les pompiers faire des doigts d'honneur à leur politiques pour des raisons très claires qui n'ont rien à voir avec le réchauffement et qui étaient déjà exposées ici il y a 2 mois:
En résumé, poussé par les verts le gvt a abandonné et même fait en sorte de bloquer l'entretien du bush afin de le rendre impénétrable aux visiteurs pour le plus grand bonheur des animaux, allant jusqu'à bloquer définitivement les accès pompiers d'enrochements.
Résultat, 1/2 million d'animaux morts à la faveur d'épisodes de forte températures et sécheresse (qui vont souvent de pair, revoir Haroun qui démontrait déjà que le climat était bien plus lié à l'humidité dans l'air qu'a des pouillèmes de CO2) et c'est pas fini.
Mouais… Cela doit dépendre d’où l'on vient car le := me semble pour ma part plus clair.
Visiblement, les discutions ont été agitées au point de tuer le père! En arriver là, vu de dehors, ramène un peu à Sigmund.
Je me rappelle en avoir essayé quelques uns (je parlais d'ailleurs d'outils lint pour le C, désormais tombés en désuétude, j'avais naturellement cherché un équivalent), mais la richesse syntaxique de Python ne me semblait pas être ici un atout: Bien trop de faux positifs à mon goût.
Pourtant, mon usage de Python étant limité, je ne crois pas faire des trucs tordus.. Peut-être pas assez "pythonic" en fait.
En même temps, depuis 2003, les chaînes de compil ont un peu évolué niveau verbosité de warning/erreur et particulièrement pour GCC, intelligibilité.
Le C laisse beaucoup de liberté et c'est très bien ainsi car là ou il est le plus utilisé c'est soit inévitable soit s'en passer a un rapport bénéfice/risque difficilement justifiable.
Alors même si tous les 5 ans on nous annonce son successeur en mieux (dont souvent des langages objet, pourtant au final toujours exclus depuis qu'ils existent car impossible d'y gérer finement l'utilisation mémoire), je pense que c'est bien le seul langage enseigné dont on peut assurer qu'il sera encore là quand ceux qui sortent d'école d'ingé actuellement prendront leur retraite!
En même temps, c'est plus un problème sur un langage interprété.
Ça fait des lustres que les compilateurs lèvent un warning sur ce type d'erreurs sans aller vers la nécessité d'un "décodeur maître Yoda" visuel!
A ce sujet, ayant passé l'essentiel de ma vie à faire du C et ne faisant du python qu'occasionnellement (outils/test au taf ou domotique à la maison), je ne crois pas avoir vu abordé dans les dépêches les outils d'analyse syntaxiques simples et efficaces, s'il y en a, qui permettent d'éviter de ne voir les erreurs à l’exécution (et encore, si on fait en sorte de passer dans la bonne branche de code)?
Bon, ça ramènera 30 ans en arrière quand passer un coup de lint pouvait faire gagner beaucoup de temps vu les temps de compilation de l'époque… Mais si j'en avais testé quelques uns pour Python, adopté aucuns: Trop de faux positifs, configuration pénible (visant de gros projets).
Posté par lym .
En réponse à la dépêche Firefox 69 ☯.
Évalué à 3.
Flash est certes enfin dégagé quasiment à 100% du web, merci html5… Mais reste utilisé par pas mal de sites embarqués pour configurer du matériel réseau, type caméra IP.
Bon, on change pas tous les jours des config l'utilisant (type zones de détection de mouvement) alors l'activer à la demande n'est pas vraiment un problème pour ce type d'usage limité.
Par contre, ce serait bien que cela ne dégage pas totalement tout de même, histoire de ne pas devoir mettre à la poubelle du matériel fonctionnel au moindre besoin de reconfiguration. En tout cas pour ceux qui n'auront pas forcément le réflexe de garder une ancienne version et ses dépendances dans un coin de leur arborescence pour cet usage.
Mais bon, sous Linux ce serait visiblement aussi éviter Wayland ce qui ne fonctionnera qu'un temps même si pour ma part je continuerais à le faire aussi longtemps que possible: Je ne souhaite en effet pas revenir plus de 20 ans en arrière et ne pouvoir tirer une appli graphique à travers le réseau en X11 forwarding (via ssh), se retrouver à tirer un bureau complet (j'ai des machines headless sans environnement de bureau et juste une install X minimale via la version frame-buffer xvfb, ce qui apporte du confort comparé à quelques terminaux en permettant d'utiliser de l'applicatif simple comme rxvt et autres nedit d'une unique connection ssh) via un ersatz de VNC ou RDP, non merci. X a été conçu traversé par la pile réseau et a priori c'était pas trop les plans des développeurs de Wayland, ce qui était pour moi une regression incroyable tant tout le monde utilise ceci. Bon, ca a peut-être changé ceci dit, vu que la réponse il y a qq années m'avait fait en plus du tout regarder ce projet. Attitude pas sans rappeler celle du projet Gnome au passage de 2 à 3, avec les utilisateurs qui hurlaient (Cinnamon, voire Mate sur de petites configs, ont depuis résolu le problème).
Pour en revenir au sujet, côté politique extensions, cela m'a surtout affecté pour Thunderbird: Beaucoup de monde étant passé (par facilité, c'est quand même un pis-aller) au webmail, il a sans doute bcp moins d'utilisateurs que Firefox et aussi de suivi des plugins par leurs auteurs. Là j'ai du bloquer ses MAJ car je me passe assez difficilement de l'extension "attachment extractor" qui n'a pas passé la version 60, je suis donc resté en 52 (Debian = versions ESR).
C'est donc toujours dommage, en effet, de faire de la casse là dessus. Surtout quand leur variété fut un gros point fort.
Ce qui est bien conçu/découpé, quitte en effet à faire peu mais bien et stable, n'a pas vraiment besoin de changer. Le changement ne vient alors que de nouveaux besoins à travers de nouvelles API.
Ce que je visais, c'est l'effet délétère de l'agile sur le développement informatique réfléchi en général. Un vrai carnage dès qu'il est sorti de son cadre initial (les IHM, essentiellement) pour arriver sur des fondamentaux plateforme.
Sinon, j'ai sans doute plus écrit de C sans aucune dépendance (même pas la libc) qu'avec. Mais contexte un peu particulier.
On part AMHA déjà mal car ce n'est pas vraiment un problème lié au langage d'une part (la solution ne sera donc pas à ce niveau) et d'autre part, un problème devenu complexe car il n'a pas souvent été bien géré dès le départ. Une dépendance correctement pensée/architecturée niveau API (n'ayant donc pas à être modifiée un jour) et le problème se ramène à du versionnage (quels appels dispo sur telle version) et une compatibilité ascendante.
Rien de plus simple, en fait.
Quand on écrivait des specs bien revues au lieu de post-it qui s'envolent, je dirais que cela se passait tout de même un peu mieux. Ce qui donne tout de même un léger avantage aux vieux langages comparé aux nouveaux.
Vieux qui d'ailleurs permettent encore d'ailleurs d'écrire, certes à condition d'aimer réinventer la roue (sauf contexte particulier), du code capable de s’exécuter sans tirer… la moindre dépendance!
En résumé: Les dépendances ont toujours été un problème, il va croissant avec les process généralisés ces 10 dernières années (totalement sortis de leur contexte initial, il faut le dire). Et en prime, aucun langage moderne ne sait plus s'en passer! De quoi expliquer le problème posé, certes, mais de là à le justifier…
La richesse des libs python permet de faire pas mal de choses rapidement, mais en illustration je suggère la vision de la fosse remplie de serpents d'un épisode d'Indiana Jones!
En réalité, les multiples interpréteurs (et leur obésité qui en arrive à les faire peser plus lourd que le système complet qui les fait tourner), les possibilités de casse système ou au mieux limitées à l'utilisateur induites par les chemins multiples d'installation de paquets, ce qui amène aux environnements virtuels (et autant de doublons) cela me rappelle un truc: Le syndrome Java!
Ce que j'appelle le syndrome Java, c'est que quasiment chaque appli codée en Java embarque désormais le plus souvent sa VM et dépendances pour éviter (même pas toujours) les ennuis/instabilités. Un gâchis faramineux.
Il n'y a bien que sous Androïd que Google semble avoir réussi, vu de (pas trop, j'espère?) haut tout du moins, à bien cadrer l'affaire. Au prix d'un applicatif bien lent tout de même, surtout à avoir snobbé Jazelle pour ne pas se lier pieds et poings à l'architecture ARM.
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: Congrats
Posté par lym . En réponse au journal Microcode ouvert sur materiel HPE ?. Évalué à 0.
Pour avoir un avantage concurrentiel avec des machines qui démarrent beaucoup plus vite, peut-être!
En arriver à passer plus de temps dans le BIOS qu'au démarrage d'un OS complet, c'est quand même un peu le miracle de l'UEFI: 3 phases étanches (SEC, et surtout PEI/DXE), un agglomérat du RC/MRC Intel, EDK2, auxquelles on ajoute le propre code du fournisseur de BIOS (configuration, son code legacy, son système de build mal fichu qui colle plus ou moins bien les morceaux).
On a donc bien souvent des choses écrites quasiment à l'identique dans ces 3 phases et pour les 3 origines possibles (avec de bonnes raisons à cela, le fournisseur de BIOS pouvant utiliser une chaîne de compil microsoft, Intel la sienne et EDK2 GCC).
Forcément, ce n'est pas très efficient. Surtout quand on charge cela (et tous les firmwares obscurs dont Intel raffole) d'une flash SPI.
J'espère de tout coeur que vous réussirez, revenu sur Intel en me bouchant le nez (avec un niveau de support très bas sur ces sujets) après plus de 2 décennies sur le PowerPC dans l'industrie télécoms.
Maintenant, sur des machines destinées à faire tourner Linux, il serait bon de commencer à faire du lourd passé Intel table rase. Le PowerPC crève de la politique d'IBM hélas, mais RiscV progresse…
[^] # Re: Accessibilité
Posté par lym . En réponse à la dépêche Audio‑conférences en ligne avec Mumble. Évalué à -1.
Le point qui m’intéressait, c'était que ça tourne sur un PI3, je dois dire.
Ce qui m'embêtait, c'est que c'est le serveur qui centralise, son rôle ne se limitant visiblement pas à la gestion des utilisateurs et leur "mise en relation". Ce qui fait que la visio n'est pas là, elle coincerait de toute façons sur une petite config avec un fonctionnement non pair à pair.
Mais si en prime la config est lourde c'est mort pour sortir famille/amis de zoom et autres machins troués… mais qu'un proche de 80 ans arrive à utiliser avec quelques directives simples.
Ce qui manque en fait toujours, c'est vraiment un Skype libre avec un fonctionnement d'avant son sabordage par Microsoft qui l'a tué, comme à peu près tout ce qu'ils rachètent, en le centralisant…
# Patch
Posté par lym . En réponse au journal Sortie de LLVM 10.0.0. Évalué à 0.
Pour le -fpatchable-function, on verrait une version plus générique du -finstrument-functions de gcc mais à y réfléchir un peu ça semble difficilement utilisable en comparaison, surtout dans un contexte visant plusieurs architectures avec des tailles d'instruction "nop" potentiellement différentes…
[^] # Re: Comble un manque...
Posté par lym . En réponse au journal waypipe, affichage distant natif pour Wayland. Évalué à 0.
Unix est traversé par la pile réseau depuis qu'il existe. Le reste a suivi cette philo et X aussi qui fait le job nativement. Un remplaçant qui retire des fonctionnalités pareilles ça n'aide pas à son adoption et d'ailleurs ça traîne depuis presque 10 ans (je m'étais d'ailleurs fait rembarrer en exposant ce gros manque aux développeurs il y a fort fort longtemps…). Maintenant que ca arrive enfin (pour les installations, pas les upgrades) avec même Debian qui s'y risque, ce qui manque et qui avait pu échapper a des utilisateurs pas forcément branchés sur le dessous du capot de l'affichage graphique va se voir. Et visiblement, certains commencent à y pallier.
Wayland et Gnome (3): Des projets un peu dogmatiques à mon goût et qui n'écoutent qu'eux mêmes… Au final, d'autres ayant des compétences sur les sujets qui fâchent font Cinnamon et waypipe, certes, mais ces attitudes n'aident pas le libre. Tout comme conchier X: Je préfère un truc qui marche à travers le réseau que gagner des FPS au jeu, même si les deux ce serait l'idéal.
Puis la sécurité, c'est un peu l'alibi du siècle. J'attends toujours les ennuis personnellement.
# Comble un manque...
Posté par lym . En réponse au journal waypipe, affichage distant natif pour Wayland. Évalué à 0.
… bien plus réel que l'auteur ne le laisse supposer, à titre personnel je vivrais très mal sans cela:
-En télétravail, je suis habituellement connecté à minimum une machine windows (en RDP) et 2 machines Linux (une saloperie dans le cloud et une physique en lab). Et qu'est-ce qui est le plus chiant: Ce RDP obligeant sous windows à tirer un foutu bureau complet (sans pouvoir avoir le même utilisateur utilisant le bureau en distant et local, + avec un win10 distant des polices généralement floues en distant si la définition de l'écran distant n'est pas identique au local) et d'en avoir au final 2 à gérer au lieu de fenêtres applicatives qui s'y intègrent en organisant ça par bureau virtuel.
Tirer un bureau complet distant, c'est au final de mon point de vue pas très pro, voir carrément très "tata Janine":
-A la maison, même un PI qui gère la baraque avec une raspbian minimale (sans bureau graphique complet, inutile, il est headless) fait du X11 forwarding via SSH, le combo idéal, avec juste le paquet xvfb (X11 frame-buffer) installé dessus: Si on évite les applicatifs issus de gnome/kde tirant des tétrachiées de dépendances, genre des terminaux light comme urxvt et éditeurs graphiques genre nedit, ca permet quand même de travailler dessus de manière bien plus confortable qu'avec des consoles. Avec wayland, je ne sais pas si le même genre de choses sera possible…
De ce point de vue, wayland était une regrettable régression sur l’ancêtre X11 qui fait que tant que X11 sera là, il restera sur mes machines… mais comme ça ne sera sans doute possible qu'un temps, tout ce qui va dans le sens de combler ce foutu manque va dans le bon sens, surtout si on gagne un support de l'accélération graphique au passage.
Le plus incroyable, c'est que cela n'ait pas été fait nativement. Il ne s'agit quand même pas de windows-clicodrome, mais d'un Unice construit depuis les débuts autour de la pile réseau, affichage compris.
Je pense que c'est lié au fait que la génération qui code cela, ne sachant pas vivre sans une IDE Eclipse (personnellement, je fuie), trouve que X11 via le réseau ne fonctionne pas forcément très bien avec des trucs trop complexes graphiquement (mais déjà un peu moins mal en activant la compression à la volée de SSH en plus du X11 forwarding : "ssh -XC toto@machineDistante") et non utilisatrice n'a même pas pensé à essayer de faire mieux de ce point de vue.
Merci en tout cas d'avoir fait connaître cet ajout, surtout en n'en éprouvant pas personnellement le besoin!
# Env graphique requis
Posté par lym . En réponse à la dépêche NoComprendo, version 1.0. Évalué à 2.
Pour ma part, j'avais regardé la dépêche initiale car je recherche une solution de reco vocale hors cloud et GAFA, mais l'utilité étant sur un système domotique headless sans écran/clavier, ni environnement graphique/bureau installé… Je n'avais pas persévéré.
[^] # Re: Mouais...
Posté par lym . En réponse à la dépêche Que retenir de l’année 2019 ? Le point de vue de quelques membres de LinuxFr.org. Évalué à -3.
C'est tellement évident que nos records de température de cet été… les modèles basés sur l'effet CO2 les prévoyaient… dans 30 ans!
Alors soit ils sont archi faux et ceux qui sont payés à les affiner depuis des décennies devraient être invités à changer de métier, soit il y a d'autres facteurs bien plus conséquents à un réchauffement que personne ne conteste.
Pour l'effet sécheresse en Australie, c'est un peu comme la vitesse pour la sécurité routière: Un facteur essentiellement aggravant. De là à en éluder encore une fois ce qui cause au profit de ce qui aggrave…
Pour l'article, le fait qu'on ait laissé le bush à l'abandon et bloqué les voies d'accès c'est du factuel.
Si on fait pareil dans les Landes, le résultat est garanti en peu d'années et blâmer le réchauffement tiendra de la prophétie autoréalisatrice.
# Mouais...
Posté par lym . En réponse à la dépêche Que retenir de l’année 2019 ? Le point de vue de quelques membres de LinuxFr.org. Évalué à -2.
Partir sur Greta, je pense que c'était partir clivant pour ne pas dire mal. Il n'y a pas que le grand blanc (pour se la jouer verbiage banlieusard) pour regretter sa notoriété éclair et au fond trop belle pour être honnête: Son téléguidage (pas forcément conscient) par les communicants de la croissance dite verte est largement démontré.
Ces vertueux qui jugent bon de produire de l'électricité avec des éoliennes peinant à produire 20% de la puissance théorique installée, ancrées sur plusieurs milliers de T de béton qui resteront quand on décidera d'arrêter de défigurer le paysage ou que les riverains les dynamiteront lassés des nuisances… ou avec des km2 de produit de fonderie silicium hautement énergivore à la production/recyclage logiquement réservés, avant les aides mal inspirées, a l’électrification des sites isolés. Ou prônant la mobilité électrique incarnée par le succès, lui aussi largement subventionné, de la Zoé. Ou comment faire passer pour vertueuse une citadine de 1.5T, illustration d'un monde qui part vraiment cul par dessus tête!
Niveau émissions, pas mieux: Arriver à faire passer la préoccupation d'un non polluant, le CO2, devant le reste des véritables polluants et monter de toutes pièces une économie de sa taxation… Comment dire? Renvoyer aux propos d'Haroun Tazieff qui dénonçait, depuis son passage au ministère alors en charge des risques naturels (et avoir consulté ses archives), les biais voire mensonges éhontés (distrayant l'opinion des vrais problèmes) de la politique environnementale alors balbutiante?
Deux décennies après sa mort le problème s'est bien aggravé. Il avait démonté d'entrée la thèse du rôle des CFC sur la couche d'ozone, que l'on commence à peine actuellement à remettre en cause. Et pas plus cru à la fable de voir quelques centièmes de pourcent de CO2 dans l'atmosphère responsables de changements climatiques majeurs.
Mais en face, on réfléchit quand même encore. Au point de voir, en Australie puisqu'on en parle aussi, les pompiers faire des doigts d'honneur à leur politiques pour des raisons très claires qui n'ont rien à voir avec le réchauffement et qui étaient déjà exposées ici il y a 2 mois:
https://volunteerfirefighters.org.au/it-is-high-time-bureaucrats-and-politicians-stopped-blaming-climate-change-for-a-bushfire-crisis-that-is-very-much-of-their-own-making-and-is-putting-lives-at-risk
En résumé, poussé par les verts le gvt a abandonné et même fait en sorte de bloquer l'entretien du bush afin de le rendre impénétrable aux visiteurs pour le plus grand bonheur des animaux, allant jusqu'à bloquer définitivement les accès pompiers d'enrochements.
Résultat, 1/2 million d'animaux morts à la faveur d'épisodes de forte températures et sécheresse (qui vont souvent de pair, revoir Haroun qui démontrait déjà que le climat était bien plus lié à l'humidité dans l'air qu'a des pouillèmes de CO2) et c'est pas fini.
[^] # Re: Python se rapproche du Perl ?
Posté par lym . En réponse à la dépêche Python 3.8 : opérateur d’assignation, REPL async, Pickle v5 et plus. Évalué à 2.
Mouais… Cela doit dépendre d’où l'on vient car le := me semble pour ma part plus clair.
Visiblement, les discutions ont été agitées au point de tuer le père! En arriver là, vu de dehors, ramène un peu à Sigmund.
[^] # Re: Yoda ?
Posté par lym . En réponse à la dépêche Python 3.8 : opérateur d’assignation, REPL async, Pickle v5 et plus. Évalué à 1. Dernière modification le 18 octobre 2019 à 14:12.
Je me rappelle en avoir essayé quelques uns (je parlais d'ailleurs d'outils lint pour le C, désormais tombés en désuétude, j'avais naturellement cherché un équivalent), mais la richesse syntaxique de Python ne me semblait pas être ici un atout: Bien trop de faux positifs à mon goût.
Pourtant, mon usage de Python étant limité, je ne crois pas faire des trucs tordus.. Peut-être pas assez "pythonic" en fait.
[^] # Re: Yoda ?
Posté par lym . En réponse à la dépêche Python 3.8 : opérateur d’assignation, REPL async, Pickle v5 et plus. Évalué à 4. Dernière modification le 18 octobre 2019 à 14:00.
En même temps, depuis 2003, les chaînes de compil ont un peu évolué niveau verbosité de warning/erreur et particulièrement pour GCC, intelligibilité.
Le C laisse beaucoup de liberté et c'est très bien ainsi car là ou il est le plus utilisé c'est soit inévitable soit s'en passer a un rapport bénéfice/risque difficilement justifiable.
Alors même si tous les 5 ans on nous annonce son successeur en mieux (dont souvent des langages objet, pourtant au final toujours exclus depuis qu'ils existent car impossible d'y gérer finement l'utilisation mémoire), je pense que c'est bien le seul langage enseigné dont on peut assurer qu'il sera encore là quand ceux qui sortent d'école d'ingé actuellement prendront leur retraite!
[^] # Re: Yoda ?
Posté par lym . En réponse à la dépêche Python 3.8 : opérateur d’assignation, REPL async, Pickle v5 et plus. Évalué à 2.
En même temps, c'est plus un problème sur un langage interprété.
Ça fait des lustres que les compilateurs lèvent un warning sur ce type d'erreurs sans aller vers la nécessité d'un "décodeur maître Yoda" visuel!
A ce sujet, ayant passé l'essentiel de ma vie à faire du C et ne faisant du python qu'occasionnellement (outils/test au taf ou domotique à la maison), je ne crois pas avoir vu abordé dans les dépêches les outils d'analyse syntaxiques simples et efficaces, s'il y en a, qui permettent d'éviter de ne voir les erreurs à l’exécution (et encore, si on fait en sorte de passer dans la bonne branche de code)?
Bon, ça ramènera 30 ans en arrière quand passer un coup de lint pouvait faire gagner beaucoup de temps vu les temps de compilation de l'époque… Mais si j'en avais testé quelques uns pour Python, adopté aucuns: Trop de faux positifs, configuration pénible (visant de gros projets).
[^] # Re: la version Wayland de Firefox ne prend pas en charge Flash
Posté par lym . En réponse à la dépêche Firefox 69 ☯. Évalué à 3.
Flash est certes enfin dégagé quasiment à 100% du web, merci html5… Mais reste utilisé par pas mal de sites embarqués pour configurer du matériel réseau, type caméra IP.
Bon, on change pas tous les jours des config l'utilisant (type zones de détection de mouvement) alors l'activer à la demande n'est pas vraiment un problème pour ce type d'usage limité.
Par contre, ce serait bien que cela ne dégage pas totalement tout de même, histoire de ne pas devoir mettre à la poubelle du matériel fonctionnel au moindre besoin de reconfiguration. En tout cas pour ceux qui n'auront pas forcément le réflexe de garder une ancienne version et ses dépendances dans un coin de leur arborescence pour cet usage.
Mais bon, sous Linux ce serait visiblement aussi éviter Wayland ce qui ne fonctionnera qu'un temps même si pour ma part je continuerais à le faire aussi longtemps que possible: Je ne souhaite en effet pas revenir plus de 20 ans en arrière et ne pouvoir tirer une appli graphique à travers le réseau en X11 forwarding (via ssh), se retrouver à tirer un bureau complet (j'ai des machines headless sans environnement de bureau et juste une install X minimale via la version frame-buffer xvfb, ce qui apporte du confort comparé à quelques terminaux en permettant d'utiliser de l'applicatif simple comme rxvt et autres nedit d'une unique connection ssh) via un ersatz de VNC ou RDP, non merci. X a été conçu traversé par la pile réseau et a priori c'était pas trop les plans des développeurs de Wayland, ce qui était pour moi une regression incroyable tant tout le monde utilise ceci. Bon, ca a peut-être changé ceci dit, vu que la réponse il y a qq années m'avait fait en plus du tout regarder ce projet. Attitude pas sans rappeler celle du projet Gnome au passage de 2 à 3, avec les utilisateurs qui hurlaient (Cinnamon, voire Mate sur de petites configs, ont depuis résolu le problème).
Pour en revenir au sujet, côté politique extensions, cela m'a surtout affecté pour Thunderbird: Beaucoup de monde étant passé (par facilité, c'est quand même un pis-aller) au webmail, il a sans doute bcp moins d'utilisateurs que Firefox et aussi de suivi des plugins par leurs auteurs. Là j'ai du bloquer ses MAJ car je me passe assez difficilement de l'extension "attachment extractor" qui n'a pas passé la version 60, je suis donc resté en 52 (Debian = versions ESR).
C'est donc toujours dommage, en effet, de faire de la casse là dessus. Surtout quand leur variété fut un gros point fort.
[^] # Re: Bazar!
Posté par lym . En réponse à la dépêche Python — partie 3 — Installation de Python et de paquets. Évalué à 0.
Ce qui est bien conçu/découpé, quitte en effet à faire peu mais bien et stable, n'a pas vraiment besoin de changer. Le changement ne vient alors que de nouveaux besoins à travers de nouvelles API.
Ce que je visais, c'est l'effet délétère de l'agile sur le développement informatique réfléchi en général. Un vrai carnage dès qu'il est sorti de son cadre initial (les IHM, essentiellement) pour arriver sur des fondamentaux plateforme.
Sinon, j'ai sans doute plus écrit de C sans aucune dépendance (même pas la libc) qu'avec. Mais contexte un peu particulier.
[^] # Re: Bazar!
Posté par lym . En réponse à la dépêche Python — partie 3 — Installation de Python et de paquets. Évalué à 0.
On part AMHA déjà mal car ce n'est pas vraiment un problème lié au langage d'une part (la solution ne sera donc pas à ce niveau) et d'autre part, un problème devenu complexe car il n'a pas souvent été bien géré dès le départ. Une dépendance correctement pensée/architecturée niveau API (n'ayant donc pas à être modifiée un jour) et le problème se ramène à du versionnage (quels appels dispo sur telle version) et une compatibilité ascendante.
Rien de plus simple, en fait.
Quand on écrivait des specs bien revues au lieu de post-it qui s'envolent, je dirais que cela se passait tout de même un peu mieux. Ce qui donne tout de même un léger avantage aux vieux langages comparé aux nouveaux.
Vieux qui d'ailleurs permettent encore d'ailleurs d'écrire, certes à condition d'aimer réinventer la roue (sauf contexte particulier), du code capable de s’exécuter sans tirer… la moindre dépendance!
En résumé: Les dépendances ont toujours été un problème, il va croissant avec les process généralisés ces 10 dernières années (totalement sortis de leur contexte initial, il faut le dire). Et en prime, aucun langage moderne ne sait plus s'en passer! De quoi expliquer le problème posé, certes, mais de là à le justifier…
# Bazar!
Posté par lym . En réponse à la dépêche Python — partie 3 — Installation de Python et de paquets. Évalué à 0.
La richesse des libs python permet de faire pas mal de choses rapidement, mais en illustration je suggère la vision de la fosse remplie de serpents d'un épisode d'Indiana Jones!
En réalité, les multiples interpréteurs (et leur obésité qui en arrive à les faire peser plus lourd que le système complet qui les fait tourner), les possibilités de casse système ou au mieux limitées à l'utilisateur induites par les chemins multiples d'installation de paquets, ce qui amène aux environnements virtuels (et autant de doublons) cela me rappelle un truc: Le syndrome Java!
Ce que j'appelle le syndrome Java, c'est que quasiment chaque appli codée en Java embarque désormais le plus souvent sa VM et dépendances pour éviter (même pas toujours) les ennuis/instabilités. Un gâchis faramineux.
Il n'y a bien que sous Androïd que Google semble avoir réussi, vu de (pas trop, j'espère?) haut tout du moins, à bien cadrer l'affaire. Au prix d'un applicatif bien lent tout de même, surtout à avoir snobbé Jazelle pour ne pas se lier pieds et poings à l'architecture ARM.
[^] # 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.