Renault a écrit 7255 commentaires

justement il existe une structure qui centralise de l'argent pour des projets, la Linux Foundation, qui pourrait facilement se lancer là-dedans.

C'est là je pense que tu te trompes.
Plein d'argent, c'est quand même à relativiser. Pour une structure qui a autant de projets en son sein, d'utilisateurs et autant de partenaires industrielles, c'est je trouve un très petit budget. La petite PME dans laquelle je bossais en brassait sans doute plus par année.

L'autre problème, comme cela a été souligné, c'est que la Linux Fondation emploie peu de personnes techniques (des développeurs ou mainteneurs). Donc il faudrait quelqu'un se dévoue pour mobiliser des employés pour aider les chercheurs. La Linux Fondation ne peut pas le faire, elle n'a pas l'effectif pour.

C'est le soucis du fait que la communauté Linux, dans son ensemble, est très décentralisée. L'avantage est que cela facilite l'intégration de travail extérieur (on peut par exemple parler de certaines entreprises qui ont du code libre mais qui ont un très grand contrôle sur le code). L'inconvénient est en effet que cela rend des décisions plus difficiles à mettre en œuvre car personne n'a la légitimité d'imposer des décisions.

Tout cela est au final assez simple, ça demande juste un peu de travail (pour coordonner le tout il faut des gens non-techniques, qui peuvent être payées pour ce boulot comme la Linux Fondation embauche ou sous-traite déjà du travail) et surtout de la bonne volonté.

Mouais, cela demande quand même d'évaluer la recherche, sa pertinence, les ressources nécessaires, de comprendre aussi les rouages suivant le pays en question (je pense qu'un dossier de recherche en Chine ce n'est pas les mêmes règles qu'aux USA, qu'en France, etc.). Personnellement, je ne trouve pas cela simple, je dirais même qu'il faudrait des employés compétents sur la question ce qui nécessite de les trouver, les embaucher, etc.

En soit oui, rien d'impossible, mais le manque de centralisation de cette communauté rend cela difficile si aucun partenaire industriel ne force la main ou prend cela en charge en grande partie.

Ça a un impact, mais comme je l'ai dit, c'est une goutte d'eau.

Pour une fondation avec moins de 50 personnes, envoyer l'un de ses membres les plus influents pendant 1 an, ce n'est pas si négligeable que cela.
C'est amusant car tu te plains (à juste titre) du manque de budget public dans la recherche ce qui pose notamment des soucis pour que chacun puisse voir les conf de son milieu et à côté tu dis qu'envoyer un an à l'étranger un employé cela ne sert à rien et n'est pas une décision importante. Car l'opération, je doute qu'elle a été gratuite.

Encore une fois, c'est de la recherche en systèmes; il y a des chercheurs qui contribuent à Linux dans ce domaine et c'est très bien. Moi je parle de recherche en qualité logicielle (test et analyse de code), et là c'est beaucoup moins clair—à part Coccinelle.

C'est déjà bien que la recherche soit impliquée dans le cœur du métier du noyau, non ? C'est la preuve que malgré tout, le noyau peut récolter et assimiler les résultats de certaines recherches. La qualité du noyau (je dirais même la qualité logicielle au sens large), honnêtement, c'est assez récent comme problématique (moins de 5-10 ans), les choses se mettent en place et les progrès sont malgré tout importants.

Je pense que ceci explique en partie pourquoi Linux a du retard sur d'autres entreprises par rapport à cette problématique.

Pour Mozilla, ce n'est pas très compliqué de dire à l'un de ses employés "si tu veux, on te paie pour aller pendant une semaine à la conférence machin qui t'intéresse, et quand tu discutes avec des gens là-bas, dis-leur bien qu'on est intéressé par le fait de financer des collaborations". Ce ne serait pas très compliqué pour la communauté Linux de faire la même chose.

C'est très différent et je suis étonné que tu ne voies pas le soucis.
Dans un cas c'est un employé, dans l'autre, ce sont des membres d'une communauté. Tu ne gères pas cela de la même façon. Si demain Mozilla veut financer une recherche sur Rust, elle peut forcer des employés à bosser dessus. La Linux Fondation peut juste inciter quelqu'un de le faire, mais ne peut pas forcer cette personne. Et c'est plus facile aussi de finance des gens affiliés à toi. Donc faut que cette personne soit un employé ou membre.

Je trouve que tu as une vision totalement étriquée de la situation. En te lisant sur cette enfilade, on a l'impression (je ne dis pas que c'est forcément le cas) que :

• La Linux Fondation a des sous mais n'en fait rien ;
• Le milieu de la recherche fait des efforts mais que la communauté du noyau n'en fait pas ;
• La Linux Fondation devrait s'impliquer dessus de manière plus forte, comme Mozilla, etc.

C'est étriqué selon moi pour plusieurs raisons. Déjà comparer Linux et Mozilla, c'est difficile. Mozilla est une grosse structure, de plusieurs centaines de développeurs. C'est très centralisé, Mozilla a un grand contrôle de ses produits et donc de l'orientation des projets qu'il développe.

La Linux Fondation (et la communauté Linux en général) n'est pas centralisée. C'est plus une fédération. La Linux Fondation n'est qu'un outil pour que des entreprises puissent monter des projets en commun autour du noyau. La Linux Fondation a très peu de contrôle sur le noyau lui même (l'essentiel des contributions viennent des entreprises membres de la fondation, pas de la fondation elle même). D'ailleurs elle peine déjà à développé son programme d'intégration des femmes et des personnes souvent discriminées, donc le milieu de la recherche ce n'est pas gagné.

Du coup rien ne peut se faire sans une impulsion des membres de la fondation. Par exemple Tizen est un projet de la Linux Fondation. Mais le code provient essentiellement de Samsung aujourd'hui, voire d'Intel à une époque. C'est toujours comme ça. On est loin de Mozilla qui peut recruter (ou mobiliser) du jour au lendemain une armée de développeurs pour lancer Firefox OS.

Et tu minimisais l'importance de Greg à l'Inria, pourtant il me semble que c'est un signal fort que la fondation envoie pendant un an (probablement à ses frais) l'un des mainteneurs les plus importants à bosser dans le milieu de la recherche.

La communauté en générale a toujours été comme ça chacun apporte ce qu'il veut au noyau, il n'y a pas de commandants qui impose une voie à suivre. Seules les entreprises contributrices ont ce pouvoir en fait.

Et bien sûr, le code accepté ne l'est que si ça répond aux exigences de qualité d'une part et si ça apporte quelque chose considéré comme utile d'autres part. Ce n'est pas parce que c'est taggué "recherche universitaire" que c'est accepté. D'ailleurs on a la preuve que cela ne fonctionne pas toujours, on se souviendra de Tanembaum qui a craché sur les noyaux non-micronoyaux et pourtant aucun noyau largement déployé aujourd'hui n'en est un 20 ans après. Ça fait très argument d'autorité du coup, il faut que les chercheurs montrent que leurs travaux sont utiles, les résultats intéressants et comment employer cela. On a la preuve qu'en persévérant un peu, ça finit par être accepté. Cela a été pareil pour la culture du tests du noyau, longtemps négligé mais aujourd'hui ça se développe fortement.

Mais c'est comme tout, le libre ce n'est pas la présence de petits esclaves pour implémenter ton idée géniale. Soit les chercheurs font le boulots eux mêmes (ce que font certains), soit ils parviennent à convaincre, ou quelqu'un qui se posait la question est motivé pour aider. Typiquement, si pour avoir un noyau plus stable il faut mobiliser 10 personnes pendant 3 ans pour faire des tâches ingrates, cela peut devenir compliqué à faire sans que instance dirigeantes forte. Cela ne se fera pas spontanément par des bénévoles, et une entreprise seule ne va probablement pas le faire sans qu'elle n'en voit un bénéfice intéressant pour elle même par rapport à l'effort consenti.

Note par ailleurs que sans chercher très longtemps je suis tombé sur des recherches autour du noyau Linux mais bien sûr fait par une entreprise ou université elle même. D’ailleurs l'Université de Louvain-la-Neuve planche sur le mulltipath TCP avec Linux comme implémentation de référence. Tu as aussi des universités (essentiellement américaines et chinoises) qui sont membres de la Linux Fondation (donc à même de proposer des projets de recherche), etc.

Donc bon, qu'en conclure ? Je ne crois pas que la Linux Fondation, de part la nature de la communauté du noyau, soit à même de faire ce que Mozilla ou Microsoft font de leur côté. Je ne crois pas non plus que l'argument d'autorité "provient de la recherche" soit valable pour que le noyau s'intéresse spontanément et accepte sans difficulté les travaux des chercheurs. Et on a des signaux loin d'être négligeables selon moi que le monde de la recherche emploie Linux avec ou sans concertation des mainteneurs du projet.

Tu as des options pour l'optimisation mémoire ou de débogage : -Os ou -Og.

Notons que dans l'ensemble, à part les ajouts de GCC/LLVM au langage C de base, les compilateurs respectent la norme du langage C. Mais oui, à des fins d'optimisations ils exploitent largement les comportements indéfinis ou invalides ce qui est normal : ces cas étant déclaré non valides, le compilateur est libre d'en faire ce qu'il veut pour aboutir à un programme qui finit sur quelque chose qui a du sens. C'est standard. Ces cas indéfinis sont prévus pour cela aussi.

C'est pourquoi, en C ou C++, si on veut de la vraie portabilité, il faut s'assurer que son programme fonctionne sur des OS, architectures matérielles et généré avec des compilateurs différents pour s'assurer que le bon fonctionnement ne dépend pas de l'interprétation d'un comportement indéfini.

Et pour ceux qui reprochent au C et C++ ce manque de définition, il ne faut pas oublier qu'à l'époque l'univers informatique était bien plus diversifiée que cela (et donc il fallait s'assurer que le C puisse tourner partout facilement) et que cela simplifie grandement le port ou l'écriture d'un compilateur. Le C n'a pas d'équivalent en terme de diversité d'environnements d'exécution, en partie grâce à cela.

Et j'ai un mauvais souvenir d'un autre compilo qui faisait l'inverse, initialisation implicite a zero en mode debug, et initialisation "aléatoire" en mode release… c'était surprenant.

Bah c'est plutôt habituel comme comportement ça. Les assignations à la valeur nulle par défaut ont un coût donc pour des raisons de perfs le compilateur par défaut va laisser la valeur en mode ça prend la valeur de la case mémoire où il est placé (et tant pis si c'est n'importe quoi). Mais pour le débogue, pour faciliter le travail, tout est initialisé par défaut.Car en mode débogue tout le monde s'en fout de la course à la performance.

Cela explique pourquoi certains bogues disparaissent en mode débogue.

Dans les manuels de GCC, c'est spécifié de souvenir qu'à partir de -O2 (depuis peu, avant c'était -O3), ils se réservent le droit de changer la sémantique du code. Ce sont des optimisations destructrices. Sinon à quoi servirait les optimisations non destructrices, suffiraient de les appliquer en permanence, non ?

Ok, je veux bien qu’il optimise, mais de là à faire « ce qu’il veut. », je ne suis pas d’accord… un compilateur traduit l’intention du programmeur. Quand il optimise, il n’est pas sensé modifié le comportement du programme.

Sauf qu'il est spécifié dans la norme qu'un pointeur nul déférencé était forcément invalide. Donc quelle est la motivation du codeur dans ce cas de figure ? Comment le compilateur peut considérer un cas défini comme invalide comme une intention valide ?

Il fait donc ce qui lui paraît valide à partir des éléments à sa disposition.

il n'y a pas de raison qu'on ne puisse pas y arriver pour le kernel Linux, mais encore une fois, ça demande une volonté et une culture favorable dans le projet.

Juste petite précision, la Fondation Linux et la recherche travaillent ensemble. D'ailleurs, un de ses membre imminents (Greg Kroah-Hartman) est allé bossé pendant un an à l'Inria de Paris : https://www.inria.fr/centre/paris/actualites/greg-kroah-hartman-rejoint-l-equipe-whisper

Sans compter l'usage de Coccinelle qui n'est pas si anecdotique que cela.

Ce n'est peut être pas assez, mais preuve que les univers communiquent quand même.

Firefox n'est pas un désastre sur la question, mais l'intégration est loin d'être parfaite.

Pour qu'une intégration soit réussie, il faut que l'application soit capable de :

• Avoir le thème de l'environnement ;
• Avoir l'ergonomie de l'environnement (disposition des boutons, barre d'outils, apparence globale) ;
• Utiliser les API / fonctions de l'environnement : impression, navigateur de fichiers, notifications, éventuellement gestion de l'énergie, etc.
• L’internationalisation.

Globalement Firefox ne respecte que le point 3. Et encore, il ne prend pas en charge la gestion des mots de passe depuis GNOME, il n'offre pas la possibilité d’interaction depuis la recherche globale de GNOME.

Le dernier point peut être surprenant, mais si tous les projets travaillent ensemble sur la question de l'ergonomie, etc. ils peuvent définir un dictionnaire commun des textes à afficher (donc employer les mêmes mots et pas des synonymes) et cela peut se faire également pour les traductions. Cela apporte une cohérence.

Mais les deux premiers points ne sont vraiment pas respectés. Firefox a son propre thème (GNOME a développé un thème spécialement pour Firefox mais avec les Webextensions, ils ne fonctionne plus) et pendant longtemps il était impossible d'avoir un thème sombre natif. Les icônes ne collent pas non plus.

Le second est aussi évident. Firefox n'affiche rien depuis le menu global de GNOME Shell, ses boutons et menus ne respectent absolument pas les règles d'ergonomie de GNOME, etc.

Ce n'est pas un reproche envers Firefox, une intégration parfaite demande un gros travail. Même Apple et Microsoft qui contrôlent leurs logiciels et leur environnement ont des difficultés à maintenir une cohérence dans le temps (on peut penser au thème de IE sous XP qui avait la tête d'une application pour Vista ou 7 par exemple). Et cela est d'autant plus vrai quand tu souhaites le multiplateforme car tu dois concilier des organisations très différentes de l'interface.

Personnellement j'adore Firefox et GNOME, donc je les mets ensemble, mais c'est vrai qu'un Firefox qui aurait une interface correspondant aux autres applications de GNOME, ce serait l'idéal. L'intégration apporte quand même un grand confort :

• C'est beau (et oui, ça compte) ;
• Si tu changes un paramètre, cela impacte tout le monde, donc gain de temps et d'énergie, on peut penser aux thèmes de l'environnement par exemple ;
• Possibilités d’interaction entre les applications (par exemple si je clique sur un numéro de téléphone, m'ouvrir l'application de contact), les applications de GNOME tout comme de KDE dialoguent ensemble ;
• C'est plus rapide et simple si tous les outils ont la même interfaces, si les boutons du menu sont au même endroit, si un paramètre similaire se configure de la même façon, etc.

Après chacun ses choix, mais cela ne me semble pas aberrant de vouloir un outil intégré dans son environnement, au contraire.

J'ai dit « en particulier pour les paresseux », je conçois bien que pour certains, c'est honnêtement compliqué.

Il reste à démontrer si dans les entreprises prévenues, il y avait des paresseux. Je pense que non, mais c'est à toi de démontrer qu'ils le sont.

Toujours est-il, qu'il y a un part de jugement éthique subjectif sur la chose et qu'il est difficile d'être tous d'accord.

Non, il y a des critères objectifs.

Tu as d'un côté de grandes entreprises avec une inertie forte car ils ont énormément de clients et de produits et de l'autre des petites communautés qui réagissent plus vite.

Il y a des critères non subjectifs pour favoriser, avec l'embargo, les entreprises du premier cas :

• Plus de produits concernés, donc si exploitation de la faille il y a, plus probable que cela touche ces appareils ;
• Le niveau technique de l'utilisateur moyen est bien plus faible dans le premier cas, donc ce sont probablement des gens qui font moins attestation par défaut à la sécurité et la confidentialité des données (donc ils bénéficient moins du chiffrement applicatif et ont plus tendance à communiquer des infos sensibles par mégarde que les autres) ;
• En cas de MaJ qui pose soucis, car on essaye d'aller vite, ce seront probablement eux les plus concernés de part la diversité des configurations logicielles et matérielles existantes et par le niveau de technicité bas de ses utilisateurs.

Je ne vois aucun avantage objectif à ce que les petits projets type OpenBSD soit privilégié dans ce dossier.

Oui, et ?

Malgré tout tout ce beau monde doit communiquer, se synchroniser, faire ses tests, peut être introduire d'autres changements avec, etc. C'est beaucoup de temps de faire ça.

Et vu la non-criticité de cette faille (car bon, honnêtement, tu dois avoir des failles bien plus importantes corrigées dans les mises à jour habituelles de ton OS et navigateur), je peux comprendre que cela ne justifie pas de se précipiter.

Le problème ce n'est pas les gouvernements, c'est qu'en 4 mois vu le nombre d'acteur t'es certain que la faille a fuité

Mouais, il ne doit pas y avoir beaucoup de gens impliqués dans ce genre de procédures, et malgré tout 4 mois c'est court pour exploiter une faille qui a finalement pas un si grand impact que cela.

Du reste cette faille a une solution de contournement très simple et facile : ne pas utiliser le wifi.

Ou chiffrer de manière applicative les communications (car de toute façon, si tout est en clair en filaire ce n'est pas terrible non plus).

Et grâce aux efforts de tout le monde sur cette question, c'est de plus en plus le cas.

Reproduire le souçis, trouve le correctif adéquoit. Ce sont des étapes qui ne prennent pas plus de temps à GROSSEMEGACORPORATION qu'à un dev openbsd ou wpa_suppliquant.

Bah figure toi que si.

Microsoft, Apple et Samsung gèrent des dizaines de produits logiciels et matériels en simultanées. Donc il faut vérifier qui est concerné, comment, établir le correctif pour chacun.

Puis étant donné que ce sont de grosses structures, je suppose que l'employé qui a accès aux données des embargo n'a pas accès à tous les dépôts de la boîte et n'est pas expert en tout. Donc il va falloir probablement contacter du monde, prévenir la hiérarchie aussi pour savoir la marche à suivre, le calendrier des opérations. Il va falloir synchroniser les MaJ des différents produits ce qui demande du travail de planification.

Je suppose aussi que les employés sécurité chez eux ne se contentent pas de juste corriger le bogue pour faire le correctif. Très probable qu'ils analysent si ce genre de failles ne peut pas se retrouver ailleurs. Ou s'il n'y a pas une faille cachée proche de cette faille dans la gestion du Wifi.

Quand tu ne gère qu'un OS, utilisé par des débrouillards en informatique sans structure hiérarchique ou équipes de développement, tu peux aller plus vite à tous les étapes. Ce n'est pas pour autant une bonne chose.

Si tu affirmes pouvoir supporter et assurer la sécurité de x milliers/millions/millards de devices différents , tu dois aussi faire les investissements nécessaire pour assurer un contrôle qualité dans un temps raisonnable pour une faille jugée critique

1-Cette faille n'est pas si critique que cela, franchement des failles révélées en grande pompe ces dernières années, c'est sans doute la moins inquiétante que j'ai vu.
2-Ce n'est pas qu'une question de budget et du nombre d'employés, tu as des délais incompressibles pour bien faire les choses. Tu sais remplir complètement un cahier de tests, et réaliser ces tests, ça demande pas mal de temps (pour l'avoir fait une fois)… Et étant donnés la diversité du matériel et des logiciels impliqués, ça en fait du boulot pour tout valider.

Il faut je pense arrêter que sous prétexte de la sécurité tout doit être corrigé dans la seconde. C'est le meilleur moyen de se louper quelque part. Ils me semblent avoir vu que le noyau Linux en voulant corrigé une faille, une autre a été introduite par mégarde. C'est con non ?

Et j'ajouterai que dans certains cas la correction de failles jugées importantes doit pouvoir primer sur le fait que x milliers de devices pourraient éventuellemnent être briqués si MEGACORPORATIONTARTANPION

Oui bien sûr, tu achètes un produit 1000€ (cas de certains téléphones je le rappelle) pour qu'il tombe en rade suite à une MaJ ? Bonjour l'image de marque et la satisfaction de l'utilisateur !

Un vol d'identité c'est potentiellement bien plus emmerdant par exemple.

Ouais, faut encore démontrer que cette faille dans la vraie vie permette de faire ça facilement. De ce que j'en ai compris, ce n'est pas si évident que cela, surtout si tu chiffres tes communications au dessus du WPA2 (et j'espère que les gens ne transmettent pas en clair des données sensibles du genre, Wifi ou non, WPA2 ou pas).

d'un, ils avaient l'accord

Certes, mais apparemment ils ont pas mal insisté pour l'obtenir.
Et comme OpenBSD semble contre le processus des embargo, les gens ne leur font plus assez confiance pour l'avenir d'où cette décision.

Un embargo n'a de sens que si les acteurs travaillent conjointement et sont d'accord avec ces règles.

ils n'ont pas besoin de trois ou quatre mois pour préparer un patch, 2h en l'occurrence pour adapter le patch fourni, donc c'est pas comme si ça va changer grand chose

Bah si, si OpenBSD délivre un correctif en lien avec la sécurité, des gens vont l'analyser si cela n'impacte pas d'autres systèmes et donc générer des attaques contre les dits systèmes qui n'ont pas encore corrigé la faille.

et de trois, attendre presque deux mois après que CERT et donc les agences gouvernementales soient au courant, ça montre un peu les limites de ce genre d'embargo à rallonge : de quoi laisser largement le temps à ceux qui voudraient en profiter parmi les nombreux acteurs au courant.

Oui, le méchant gouvernement est au courant donc ils vont profiter de l'embargo pour attaquer tous azimuts.

Déjà, la faille est surfaite, elle n'est pas si critique que présentée. En réalité si tu as un chiffrement applicatif, ce qui est de plus en plus le cas (HTTPS, chiffrement SMTP/IMAP, VPN, etc.) ces flux ne sont pas concernés. Et les actions possibles restent malgré tout assez limitée. Donc l'urgence selon moi n'était pas non plus de mise.

Trois mois (ou plus pour certains en fait), c'est pour les gros vendeurs, en particulier les négligents et paresseux, et pour assurer la médiatisation, ça n'a pas grand chose à voir avec la sécurité.

C'est vraiment naïf je pense de présenter cela ainsi.
Je ne dis pas que les 4 mois sont nécessaires, je n'en sais rien, mais cela ne demande pas deux jours non plus.

Car bon, le développeur OpenBSD qui fait son correctif à l'arrache en 4h n'a pas les mêmes contraintes (ni la même qualité de service) qu'une entreprise comme Microsoft, Samsung ou Apple. Ces entreprises ont souvent beaucoup de versions de leur logiciel à maintenir. Entre les différents Windows (3 sont encore maintenus), macOS, iOS, et pour Samsung c'est plusieurs versions d'Android et de Tizen à toucher pour des dizaines de périphériques (avec leur propre version du système).

Bref, les entreprises commerciales ont une certaine inertie pour ce genre de correctifs mais c'est justifié. Ils doivent reproduire le soucis, trouver le correctif adéquat, le tester sur tous les appareils concernés (quand tu as une vraie QA, cette étape prend du temps). Car bien entendu, on doit être sûr que la MaJ ne casse rien pour personne car ma grand mère ne va pas déboguer et faire un rapport de bogue pour sa machine auprès de ses entreprises (ce que l'utilisateur d'OpenBSD moyen saurait faire). Ensuite il faut générer la mise à jour et en faire la diffusion (et étant donné leur infra, cela ne se fait pas en une minute). Sans compter que comme les MaJ ça coûte à en faire, ils vont probablement intégrer ce changement avec d'autres qui étaient prévus. Ce qui ralenti le processus.

Donc bon, non ils ne sont pas fainéants, paresseux ou incompétents. Mais assurer une qualité de service pour des millions / milliards de produits diffusés dans le monde, utilisés par des non informaticiens, cela ne s'improvise pas. Même un changement banal nécessite de gros efforts pour éviter des problèmes. Du coup ils ne peuvent pas se permettre de faire comme OpenBSD ou Debian de faire un correctif rapidement et de le diffuser dans la foulée ou presque.

C'est difficile de concilier toutes ces contraintes à la fois.

Sauf qu'il n'y a jamais et n'aura jamais de lien entre le salaire et le niveau d'étude. Cela dépend du métier, de la branche d'activité, de la demande / besoin autour de cette activité.

Je ne trouve pas aberrant qu'un diplômé de master dans un filaire déjà bouchée ait du mal à avoir un gros salaire voire un emploi. Ce qui fait que certains, comme certains artisans, gagnent plus malgré un niveau baccalauréat ou bac+2.

Je ne dis pas que les enseignants chercheurs doivent être payés au lance pierre, mais je ne trouve pas que la logique "bac+X > bac+Y" implique "salaireX > salaireY". Il faut se baser sur d'autres principes. Je pense en effet que les enseignants chercheurs devraient être choyés, mais j'ai personnellement d'autres idées sur cette raison : l'importance d'attirer les gens à faire ce métier, qui est utile, exigeant, hautement valorisable, découvertes qui peuvent servir à bien d'autres gens dont notre économie, industrie ou simplement notre culture et savoir faire…

Mouais, le mythe de la famille qui t'empêche d'avoir des loisirs.
Ce n'est pas parce que tu as des gamins que tu n'as le temps de rien faire du tout à côté. Ce serait le cas je pense que beaucoup ne fonderait pas de famille. Tu as certes moins de temps libre, mais pas zéro.

Après cela reste une question de priorité, comme le rappelle Zenitram. Tu peux vouloir passer plus de temps avec ta famille au détriment du LL. Personne ne dit que c'est mal. Mais cela reste un choix, volontaire.

Je ne pense pas que ce que dise Uncle Bob est ridicule, vu les ouvrages de référence qu'il a écrit (Clean Code, principe SOLID, etc.).

Tout n'est pas ridicule, mais il me semble en effet ridicule de croire que le code source contient toutes les informations utiles pour un projet d'envergure.

Comme toute analogie, elle a ses limites, mais elle me parait légitimer le code en tant que document de référence qu'il faut garder le plus lisible possible.

Sauf que, comme je l'ai dit, le code ne peut servir de référence ultime :

• Nombreux sont ceux qui ne savent pas le lire, et les docs générés à partir des sources sont compris par des codeurs, rarement par des non-codeurs ;
• Un projet a un contexte, des contraintes, rarement exprimés dans le code (car ce n'est pas le rôle du code que de décrire le projet de A à Z) donc il sera nécessaire de détailler tout cela dans des documents annexes au code ;
• Dans un projet non uniquement informaticien-centré, tu as des tas de métiers qui vont intervenir, dialoguer entre eux, etc. Je pense à des gens du matériel, des ergonomes, des architectes logiciels (qui n'ont pas codé dans le langage X depuis un bail), des auditeurs qualité, des testeurs, des ingénieurs systèmes, ou tout simplement le client (qui n'est pas codeur mais celui qui va utiliser le produit).

Le dernier point est souvent oublié mais il est capitale. J'ai bossé avec des non-codeurs et pour eux il est inconcevable qu'ils lisent du code ou qu'ils essayent de trouver l'info qui leur faut dans la documentation du projet qui est dans le code. Ils perdraient trop de temps.

Par exemple, perso je m'occupe souvent de l'interface noyau / matériel et noyau / logiciels. Je ne pouvais pas exiger des ingénieurs électroniciens de lire ma doc pour savoir ce que je fais avec leur matériel. Ils s'en foutent de l'architecture du noyau et des détails dont seul le logiciel a a s'en préoccuper. De même que moi je m'en fou de savoir exactement les plans de routage de la carte électronique dessous.

Résultat, nous devons concevoir une documentation pour décrire l'interface logiciel / matériel, quelle puce est accessible sur quel bus, les registres importants à changer, certaines possibilités en options, les changements exactes entre la version A du matériel et la version B, etc.

Non seulement c'est utile pour nous, éviter de perdre du temps à récupérer les infos pertinentes, cela nous permet d'éviter les erreurs car on doit dialoguer pour se mettre d'accord sur les tâches à faire. En plus comme le projet était en contexte aéronautique, nous devons fournir ce genre de document pour être audité par des non informaticiens (les ingénieurs systèmes).

Et avec les non programmeurs ? Bah c'est aussi utile. Pour beaucoup de programmeurs, le noyau est une boîte noire et doit le rester. Ils s'en foutent de l'architecture de mes pilotes, et en plus la plupart ne savent pas forcément coder en C. Comme pour le matériel, ce qui faut, c'est la description des entrées / sorties. Le reste tout le monde s'en fiche (sauf moi pour maintenir mon propre code). De même que je n'ai pas envie de plonger dans un code écrit dans un langage que je comprends mal pour vérifier si le format des entrées / sorties correspond. Et comme la doc en général ressort toute l'architecture, te peux prendre du temps pour identifier la section qui t'intéresse.

Tout cela pour dire quoi ? Que je trouve très important que l'on documente nos codes à différents échelons. Il faut décrire les interfaces d'entrées / sorties pour ceux qui vont dialoguer avec toi, il faut décrire l'architecture détaillée (dans le code) pour ceux qui vont coder ou reprendre ce module, et il faut décrire une architecture simpliste pour ceux qui vont gérer le projet et faire l'architecture / relecture globale. Cela demande différents niveaux d'abstractions, de formats de documents donc (fichier texte, UML et code). Croire que seul le code avec la doc généré suffit est je pense trop simpliste et ne peut fonctionner pour un projet d'envergure qui fait intervenir des non codeurs dans la procédure.

Plusieurs dizaines de milliers de lignes, ce n'est pas très gros hein. ;-)
Et cela ne change pas grand chose au problème, si tu as des briques plus élémentaires, il faut malgré tout concevoir et documenter les interactions entre elles. Ce n'est pas magique.

Et il faut forcément que quelqu'un puisse ou ait en tête l'architecture globale d'un projet, tu ne peux pas lui dire de lire le code d'une dizaine de modules pour qu'il comprenne l'architecture de l'ensemble. Cela n'a pas de sens.

Dans l'ingénierie traditionnelle on prend les documents de conception et on construit l'objet, et dans l'informatique on fait exactement la même chose sauf que les documents de conception sont les fichiers sources !

Bah non, la conception n'est pas le code source qui en est une implémentation.

Une spécification, qui est le résultat de la conception, ne peut être exprimée convenablement dans un code source car cela n'est pas son but. Le code source décrit un programme, des algorithmes.

Je veux dire, une spécification, ce n'est pas juste décrire les limites du programmes ou ce qu'il fait. C'est aussi expliquer des choix de conception. Et ça, tu en trouves rarement dans le code source. Et oui, ton produit n'a pas que des limitations techniques (genre le nombre d'imbrications du fichier JSON acceptable), c'est aussi exprimer que le système doit démarrer en moins de 60 secondes, que par défaut on souhaite qu'une certaine interface soit présentée, etc. Décisions qui impactent souvent des non codeurs (ergonomes, client, etc.) et qui ne sont pas dans le code source car son but n'est pas de collecter les comptes rendus de réunion de spécification mais d'expliquer son code.

C'est donc le compilateur qui construit le logiciel et la différence avec l'ingénierie de biens matériels c'est que le temps et le coût de génération sont très petits.

Mouais, concevoir un logiciel un peu conséquent, cela prend des années. Certes le logiciel peut faire des mises à jour progressive, faire des prototypes et tout. Mais un gros projet c'est loin d'être si différent en coût par rapport à la production d'un bien manufacturé.

Puis le début de ta phrase est fausse. Le compilateur transforme le code source en un exécutable exploitable par la machine. Ce n'est pas lui qui conçoit et doit améliorer le logiciel à l'avenir. Si on va dans ton sens, un produit manufacturé n'a pas besoin de spécifications non plus, car comme c'est la chaîne d'assemblage qui réalise le produit final, il suffit de regarder la conf des machines outils, leur code source, la liste des matières premières et hop tu as tout ce qu'il faut ! C'est ridicule.

C'est sûr que quand tu travailles sur des projets simples, avec peu de conséquences, et peu d’interactions, se passer de la conception hors code c'est simple et confortable.

J'ai bossé sur des systèmes embarqués (sur des systèmes critiques ou non) et j'ai bien apprécié que le code ne soit pas la seule source de documentation :

• Faut définir le lien matériel - chargeur de démarrage / noyau, heureusement que les gars du matériel ne disent pas lis mon schéma électronique pour comprendre exactement ce que je dois faire ;
• Le lien noyau (pilotes) avec l'espace utilisateur doit être décrit, qui envoie quoi et quand à l'autre. Ce qui intéresse de part et d'autre c'est l’interaction entre ces composants (les entrées / sorties), pas les rouages internes pour essayer de déterminer les entrées / sorties de chacun ;
• Pareil pour la communication entre les applications, ou avec une bibliothèque.

Bref, le code c'est la documentation c'est valable pour un logiciel isolé avec une équipe composée uniquement de codeurs, capable de lire le code ou la documentation générée. Mais ce n'est pas systématique. Quand je code un logiciel qui communique avec celui de mon collègue, j'apprécie de ne pas avoir besoin de connaître en détail son architecture pour savoir ce que je peux lui envoyer et ce que je dois recevoir. Ce qui m'intéresse ce sont les entrées / sorties et c'est tout.

Et la conception, pour des logiciels non enfouis, il y a souvent un non technicien qui va intervenir dans la conception de l'UX par exemple. Son rôle n'est pas de déterminer depuis le code (ou sa documentation) comment ça va s'afficher, les options proposées et autres. Il a besoin de documents qui ne gèrent que cela.

Du coup un document texte et des diagrammes UML c'est utile pour que tout le monde communique sans exclure les non codeurs. Cela me paraît essentiel.

Faire disparaitre la partie technique c'est louable pour le client (même si 90% de la population d'ici deviendraient chômeurs ;) )

Bof non, heureusement l'industrie du logiciel ne se concentre pas uniquement sur des applications type gestion de stock qui sont en effet bien gérés par ce genre d'outils.

Je ne me vois pas coder le site Web d'Amazon, de Google, Facebook, concevoir le logiciel d'une carte embarquée avec ce genre d'outils. Sans compter les applications bureautiques riches (genre Photoshop / GIMP, les suites Office, etc.). Bref, ces outils sont réservés à une fraction seulement des applications possibles.

Est-ce que SELinux est toujours intégré et activé par défaut dans Fedora ?

Oui, après tu peux librement le désactiver si tu veux.
Il faut garder à l'esprit que cela apporte une sécurité non négligeable de le garder actif, et honnêtement c'est très rare que je doive intervenir pour faire quelque chose.

Faire tourner un programme qui n'est pas autorisé par SELinux parait très très compliqué.

Ce n'est pas très compliqué, SELinux te dit même quoi taper pour autoriser une action interdite.

SELinux lui même parait être une usine à gaz, ou un rêve pour les adorateurs de casse-tête et de syntaxes absconses, au choix.

Ce n'est pas une usine à gaz, honnêtement il fait peu de choses et sa conception est assez simple. Mais la sécurité qu'il apporte peut gêner l'utilisateur. Question de choix.

Je pense qu'on peut regretter le fait historique que Linux, en tant que projet communautaire de noyau libre, est parti sur un noyau monolithique plutôt qu'un micro-noyau—aujourd'hui le noyau est presque impossible à sécuriser (je parle de sortir du jeu du chat et de la souris des attaques/réponses en rendant toute les classes d'attaques courantes impossibles grâce à la conception du système)

Deux choses. Encore une fois, tu oublies significativement le contexte ou tu le rends négligeable. Pourtant ils sont fondamentaux.

Linux était un projet jouet pour Torvalds, pour apprendre l'x86. Le monolithique était juste le moyen le plus simple pour aboutir à un résultat rapidement. Ce sont ensuite les autres qui ont porté Linux au delà du projet jouet, car Linux était à ce moment là, le seul noyau libre convenable. *BSD avait l'épée de Damoclès du procès (et est de toute façon monolithique aussi), Minix n'était pas libre et Hurd on l'attend toujours.

Torvalds n'aurait jamais lancé un tel projet si un micro-noyau libre existait et fonctionnait, Linux n'aurait jamais été un micro-noyau car ce n'était pas l'objectif de Torvalds avec le contexte de l'époque.

Et l'avenir lui a donné raison, il n'existe aucun micro-noyau pur avec une utilisation très large. Windows et macOS (qui ne sont pas codés par des ignorants non plus) n'ont jamais franchi le pas de tout mettre en espace utilisateur faute de performances acceptables.

Et on peut largement sécuriser encore le noyau Linux sans aller dans le micro-noyau fondamentalement. Mais là encore, la sécurité absolue au niveau noyau, c'est contre les performances aussi. Il faut faire des compromis. Et le compromis, ce n'est pas un micro-noyau pur.

Mais il y a une différence importante, c'est que (1) à l'époque les micronoyaux étaient difficiles à rendre efficace (L4 a fait beaucoup de progrès depuis), et (2) tu parles d'un choix de design fondamental qui demande de complètement tout refaire.

Tu as pourtant reproché des choses à Go qui demanderaient de changer l'architecture de Go. et qui est difficile à faire aujourd'hui car ce n'est pas cohérent avec l'architecture choisie. Que c'est trop tard.

Il ne s'agit pas de demander de tout changer au langage, ou de le transformer en une variante de Coq. C'est une fonctionnalité qui n'est pas copmliquée à expliquer ou implémenter, qui se mélange bien avec la plupart des autres traits du langage, et qui lui donne une meilleure capacité à modéliser les domaines métiers—et donc d'écrire du code plus clair. On n'est pas du tout au niveau du "il faut tout refaire avec un micro-noyau".

Mais pourtant on te l'a expliqué que les développeurs de Go, sur cet aspect, connaissait ce que tu énonçais mais l'ont ignoré pour certaines raisons. Tu peux dire ce que tu veux, mais ils ont fait un choix, un compromis et c'est nécessaire d'en faire sur certains sujets. Honnêtement, je ne suis toujours pas convaincu que c'est un manque aussi important que tu l'énonces.

Tu parles de récrire des millions de lignes de code, mais au moment où Go a été conçu, il n'y avait aucune ligne déjà écrite dans ce langage (ou alors juste des exemples exploratoires).

Tu oublies le code passé et la formation des gens. Il y a bien plus de gens, surtout dans le milieu où Go évolue, où le C (voire C++ et Python) est la référence qu'OCaml ou Rust. Go était destiné quand même à ces gens là, une évolution en douceur. Cela ne me paraît pas débile de garder un langage simple et assez proche d'un autre langage pour attirer les développeurs sans leur faire peur.

De la même façon que développeurs COBOL n'est pas parti sur OCaml non plus pour refaire les systèmes bancaires alors que les avantages du langage sont évidents. Mais voilà, pareil, les gens efficaces en Java tu en as suffisamment et les développeurs de COBOL trouvent sans doute la transition plus douce aussi.

C'est un ensemble de choix fait par des gens, et l'un des choix qui se propose c'est de réfléchir à l'apport de la théorie, d'écouter ce qu'elle a à dire et d'entrer en contact avec des gens qui en font

Tu es toujours dans l'histoire du théorie -> pratique, mais au vue de tes déclarations où tu sembles (volontairement ou non) ignorer ce qu'est la vraie vie d'un projet informatique en entreprise, du savoir des développeurs. Je dirais que l'inverse devrait aussi se faire, que les théoriciens ne s'offusquent pas car ils n'ont pas été entendus par eux. Peut être qu'ils l'ont été mais qu'ils ont arbitré différemment avec leur justification (ce que Go notamment a explicité sur certains choix). Je trouve facile de toujours réclamer à être entendu mais de ne pas faire l'effort soi même dans l'autre sens.

Sauf que heureusement, l'ABI du noyau avec l'espace utilisateur est très stable. Cela peut tenir des années ainsi.

L'exemple microkernel vs monolytique n'est pas une bonne analogie. A ma connaissance, l'état de l'art sur les systèmes a micronoyaux n'a pas encore depassé celui des architectures monolithiques mis a part dans certains domaines très précis mais pas de manière générale.

Pourtant au niveau de la recherche sur le sujet, le noyau monolithique est obsolète par conception. Ce n'est pas moi qui le dit mais Tanambaum en 1992, qui est quand même un chercheur émérite du domaine. D'autant plus qu'il parlait au nom de son milieu, et non uniquement son point de vue personnel. Et il a répété jusqu'à sa retraite de la recherche que la conception de Linux, en n'étant pas un noyau monolithique, était toujours une erreur, que seuls les pure micro-noyaux avaient grâce à ses yeux.

Il a comparé Linux, en 1992 quand Torvalds était encore qu'un étudiant, qu'il ne lui donnerait même pas la moyenne pour ce projet à cause de ce choix architectural dépassé.

Bref, c'est en tout point semblable à ce que gasche déclare à propos de Go en tant que faute professionnelle en ignorant la recherche de son secteur d'activité sur le sujet.

Opposer théorie et pratique n'a pas de sens.

Bah, si.
Les deux doivent communiquer pour que le tout avance, mais on ne peut pas prétendre qu'une bonne idée théorique est systématiquement une bonne idée pratique. Nous en avons constamment la preuve, les noyaux (domaine que je connais mieux que les langages) en est une bonne démonstration car le modèle actuel dominant est plus sur les approches hybrides (monolithique modulaire pour Linux et *BSD ou noyau hybride comme ceux de macOS ou Windows) que pure micro-noyau qui sont réservés aujourd'hui à des niches.

En général la théorie cherche la solution la plus élégante. Sur le papier, la théorie peut toujours l'emporter sur l'approche pratique. Mais voilà, la pratique c'est aussi les contraintes de la vie : la formation, les outils, les projets existants, l'Histoire. La théorie ne s'en préoccupe pas vraiment et c'est normal. Mais la pratique ne peut faire comme la théorie et tout refaire de zéro car la théorie dit que c'est mieux ainsi.

Certes ces nouveaux outils impliquent un cout non négligeable de formation, mais a choisir en entre cout de formation et cout en QA ou debugging, le choix sera vite fait. Payer des journées de dev pour coder ce qui pourrait se faire automatiquement avec des langages modernes ou a débugger des data race alors que le compilo pourrait en garantir l'absence a chaque build sera une position de plus en plus dur a justifier.

Mais tu ne peux dire demain de jeter des millions de lignes de code, de former des millions de développeurs d'un coup sur les nouvelles pratiques et espérer que ce soit économiquement intéressant. Les processus d'évolution que tu cites demandent du temps. Beaucoup de temps. Même certains langages comme COBOL, pourtant décriés, avec peu de personnes capables d'en tirer quelque chose était jusqu'à peu le pilier des applications bancaires. La transition vers Java fut très longue. Tu ne crois quand même pas qu'ils vont passer à Rust ou autre dès demain, si ?

Sinon dès demain tout le monde utiliserait Coq pour avoir un programme sans bogue. Mais ce n'est pas le cas, car le gain n'en mérite peut être pas le coût associé. Ce n'est pas pour rien que Coq est globalement employé par les secteurs où le niveau de criticité est telle que Coq revient finalement moins cher qu'un code C minimal testé de toute part. Car c'est là qu'il se met en valeur.

Tu t'inventes ta propre histoire de Go.

Pas vraiment. Cette page ne contre indique pas ce que j'énonce.
En 2007, nombre des domaines qu'ils listent sont trustés par le C, pour des raisons souvent historiques mais aussi parce qu'il est fortement lié à UNIX ce qui le rendait très apprécié pour la programmation système. Et le C a influé grandement le C++, Java et Python même si peu à peu, certains s'en éloignent aujourd'hui.

Bref, ils ne le citent pas directement dans cet article, mais ça reste une caractéristique importante de Go. Le fait que Pike et Thompson, qui ont fait du C (ou du Limbo, que tu parlais précédemment) pratiquement toute leur vie, ont contribué à Go dès les débuts n'est pas je pense étranger à cela.

L'Histoire ne se résume pas à une FAQ d'un site Web (qui peut aussi subir des effets du genre storytelling pour mieux promouvoir le produit maison), c'est aussi un contexte historique, des personnages avec une expérience, un passé…

Les types sommes ont été introduits par le langage Hope (dynamiquement typé) dans les années 70. Ils sont utilisés à moyenne échelle par les programmeurs ML et Haskell depuis les années 90. (Tous les étudiants qui ont fait l'option informatique une prépa MPSI dans les 20 dernières années en France les ont appris; une partie de ces étudiants travaillent d'ailleurs maintenant à Google.) Ce n'est pas exactement ce qu'on appelle "l'état de l'art".

Mais est-ce un vrai manque ? Les lambda-calculs, ce n'est pas nouveau non plus, beaucoup de langages n'en ont pas. Est-ce grave ? Est-ce que ce que tu énonces était essentiel pour répondre à leur problématique ? J'ai l'impression que non.

Tu as une vision très théorique de la situation. D'autres plus empiriques, ils ne prennent que ce qui est nécessaire ou conforme à ce qui est voulu. Tu disais que les concepteurs de langages devaient écouter les théoriciens, je n'ai rien contre cela, mais l'inverse est vrai aussi, les chercheurs doivent écouter et comprendre ceux qui programment dans l'ensemble des contextes industriels existants.

Il me semble que c'est courant pour nous tous, quand on écrit du code, de dire (ou d'écrire) familièrement : ça c'est laid. (Ça ne t'arrive jamais ? C'est forcément, pour toi, un signe de mépris intolérable pour la personne qui a écrit le code, souvent soi-même ?)

Il y a une histoire de contexte. Dire c'est laid pour rire, pourquoi pas, je le fais aussi, mais comme tu insistais pour dire que le Go c'est de la merde, le côté humoristique a disparu.

Le plus amusant, c'est qu'on avait eu un débat ici il y a quoi, 2 ans sur ce qui était acceptable en terme de communication, qu'il fallait éviter de froisser les gens. Tu semblais soutenir que c'était possible de parler entre adultes systématiquement sans jamais froisser quiconque tout en pouvant développer une culture communautaire saine. Alors, tu soutiens toujours le même point de vue ?

Au contraire j'ai dit "à l'époque de C c'était compréhensible, aujourd'hui (à l'époque de Go) c'est une faute professionnelle". Je parle de faute dans le contexte de Go. Oui, je pense qu'on peut argumenter qu'ignorer une fonctionnalité de langages de programmation (les types somme) qui ajoute peu de complexité, améliore la clarté et la sûreté et évite des bugs et des erreurs, quand on est, professionnellement, concepteur de langage de programmation, c'est une faute.

Bah non, je conteste encore, ce serait comme dire que pondre un noyau monolithique serait aussi une faute professionnelle.

Le Go a une cible très précise en tête, qui est en gros de remplacer le C tout en étant proche de lui pour la programmation système (qui est un domaine particulier, rarement considéré par la recherche informatique qui semble se concentrer sur des applications plus lourdes / critiques).

Le Go doit donc avoir cette simplicité (de conception) du C, reprendre l'essentiel de sa syntaxe (un développeur C n'est pas choqué par la syntaxe du Go) tout en apportant la possibilité de faire des trucs utiles simplement (comme la programmation parallèle). Le cahier des charges est rempli, il fait son boulot.

Le fait qu'il ne soit pas à l'état de l'art du domaine n'est pas le sujet. En réalité, tout le monde s'en moque de suivre l'état de l'art, ce n'est pas le critère. La question est toujours "est-ce que l'état de l'art m'apporte quelque chose pour répondre à mon cahier des charges ?" Parfois oui, parfois non, j'ai l'impression que pour le Go (de ce que j'en ai lu), c'est plutôt voulu et assumé de faire autrement, car l'état de l'art ne l'aidait pas pour ce qu'ils voulaient faire.

Dire que les gens commettent des fautes, je ne trouve pas que ce soit méprisant.

Attends, je te cite, par exemple :

j'ai tendance à préfèrer augmenter la quantité de beauté dans le monde qu'atténuer les souffrances des gens qui vivent dans le laid,

Tu ne trouves pas que de traiter tout ce qui ne répond pas à tes critères comme du laid ne soit pas méprisant ? Envers ceux qui ont développé et qui utilisent ce langage pour diverses raisons.

J'ai aussi appuyé le commentaire de c3 sur le fait que Go ignore (volontairement) les développements en langages de programmation qui ne viennent pas de ses auteurs. Je ne pense pas que rappeler un fait soit un signe de "condescendance assez violente", même quand il n'est pas à l'avantage du langage dont on parle.

Bah si, car tu sembles prioriser dans les critères le fait que les concepteurs doivent écouter et suivre les chercheurs systématiquement. Tu fais un jugement de valeur et cela se transcrit tout le long de ta prose ce qui ressemble à une grosse condescendance envers ceux qui n'ont pas les mêmes critères, objectifs que toi et qui du coup ne suivent pas forcément la même voie.

Si tu respectais ces choix, tu n'en ferais pas des pavés pour dire qu'ils sont dans l'erreur et que tu es dans le vrai. Tu le mentionnerais rapidement et tu passerais à autre chose.

Personnellement, je trouve que l'ensemble de ton discours sur C et Go montre une certaine forme de condescendance assez violente de ta part (voire de ton milieu) envers ces langages.

Non pas que ces langages ne présentent pas de défauts, loin de là, mais tu sembles tellement obnubilé sur l'aspect théorique que tu perds toute vision des autres critères pourtant essentiels dans le milieu. Un peu comme certains mathématiciens qui hurlent devant des documents de physiques sur des points qui n'ont finalement pas d'impacts sur la valeur du document et qui sert plus de prétexte à critiquer qu'à vraiment faire avancer le sujet.

C'est compréhensible pour C qui a été écrit par des chercheurs en systèmes à une époque où il y avait peu de communication entre les équipes de recherche (il faut quand même noter que C et ML ont été inventé à la même époque, donc l'idée des types algébriques était déjà dans l'air et aurait pu être ajoutée à C si ses concepteurs avaient été un peu curieux), aujourd'hui c'est une faute professionnelle, appelons un chat un chat.

Appeler le C de faute professionnelle, c'est un peu fort quand même. Dans ce cas je dirais que tout le monde devrait être au chômage.

Non pas que le C est parfait, je connais ses défauts, mais je connais aussi ses avantages (avantages essentiels pour l'époque) : tu aurais pu écrire UNIX en 1970 avec ML ou un langage similaire, dans les conditions qu'il a été écrit, pour les machines cibles ? J'en doute très certainement.

Tu sembles aussi induire que Ritchie et Thompson sont de sombres incompétents, étant donné leurs parcours, leurs apports et le milieu dans lequel ils ont évolué, j'émets un doute sur cet avis. Apparemment, comme d'autres, ils ont choisi une voie moins élégante théoriquement mais qui permettait de résoudre des problèmes concrets de leur époque.

Cela me fait penser un peu au discours Tanambaum contre Torvalds sur le noyau monolithique contre micro-noyau. Théoriquement le micro-noyau explose tout, mais voilà il y a les contraintes de la vraie vie aussi et 25 ans après on attend toujours le micro-noyau qui montrera que c'était la seule voie à suivre. Ni Apple, ni Microsoft n'ont trouvé le 100% noyau assez séduisant pour l'utiliser massivement, préférant une approche hybride. Et Minix, malgré sa licence libre, peine à convaincre face à Linux dans la plupart des domaines.

Bref, je pense que tu devrais un peu plus t'informer sur les circonstances du choix de conception de certains produits, de constater que la méthode élégante n'était pas à ce moment là pertinente. Ce n'est pas parce que des gens ont choisi une autre voie qu'ils sont incompétents, cela peut être une explication, mais il y en a d'autres.