Renault a écrit 7187 commentaires

Tu peux acheter un ordinateur d'Apple ou un ordinateur sans système d'exploitation préinstallée. Le choix est moins large, mais il existe.

Et malgré tout, ce n'est pas une oppression pour autant. Vous mettez vraiment la vente liée à la même marche que l'esclavagisme ? C'est quand même assez insultant pour les esclaves que d'oser faire le rapprochement.

Mais est-ce que Minix ou Windows oppressent les gens ?
Je veux dire, ta comparaison avec l'esclavagisme est bancal. L'esclave en général ne l'était pas de son propre chef, c'est quelqu'un ou la société qui le rendait esclave de force.

Ici le logiciel sous BSD devenu propriétaire ou le logiciel propriétaire d'origine, tu n'es pas obligé de l'acheter, et même si tu l'achètes tu es loin de vivre une oppression quelconque. Tu as des limitations plus ou moins fortes, mais rien qui ne t'amène à ce genre de situation (pour la simple raison qu'entre autre la loi te protège de ce genre de possibilités).

Ne pas oublier qu'on parle de x86 récents de la marque Intel. Il y en a beaucoup qui n'ont pas ce dispositif (car trop ancien, ou produit par AMD) et qu'il y a aussi des PowerPC, ARM et autres dans le monde. En vérité Linux et Windows doivent avoir bien plus d'utilisateurs de part le monde que Minix.

Puis bon, un OS dont personne ne peut réellement dialoguer avec lui, et qui ne sert pas aux applications de l'utilisateur, je crois que tout le monde s'en fout de qui c'est.

En fait, Andrew doit être content car il a découvert qu'il utilise peut être Minix tous les jours ainsi. Bah oui, sans le support de l'USB par exemple, ce n'est pas sûr qu'il l'emploie comme système principal. En attendant, la communauté Minix a du mal, la conférence annuelle de cette année a été annulée faute de présentateurs. Donc peut être que c'est un OS largement déployé, mais il lui manque beaucoup de choses et peu d'entreprises semblent intéressées à faire évoluer la monture.

Et à chaque fois qu'on ose critiquer le C ou le C++, il y a une meute de programmeurs qui se sentent insultés et nous tombent dessus à bras raccourcis.

Bah personnellement, un gars peut écrire son logiciel perso en COBOL, BASIC ou autre, je m'en fout un peu même si je n'aime pas ces langages et sont inadaptés. Je veux dire, cela ne me regarde pas, si le gars assume son choix (qui peut poser des soucis dans l'évolution de son logiciel, dans l'élaboration d'une communauté ou la venue d'autres contributeurs) je ne vois pas le soucis.

à nuancer selon le domaine, bien sûr, mais plus ça va, moins je vois où se trouve le pré carré du C

Le C a quelques domaines :

• La programmation système, de par ses liens avec UNIX et donc POSIX (même si Python, Go et Rust gagnent du terrain) ;
• L'élaboration de certaines bibliothèques, car le C peut facilement être exploité par d'autres langages (comme Python, C++ ou Rust) ;
• Les systèmes embarqués, sa légèreté peut le rendre incontournable, et sa simplicité et son historique lui donne une portabilité sans équivalent ;
• Le très bas niveaux, type noyaux de système d'exploitation, chargeurs de démarrage, où les langages de plus hauts niveaux ont moins d'avantages (car certains mécanismes sont absents).

Si le C perd du terrain dans ces domaines, sa disparition complète risque de prendre beaucoup de temps. Surtout que son historique fait que c'est un langage que pratiquement tout développeur a touché une fois dans sa vie et qu'il y a beaucoup de code à maintenir.

En quoi cela est-il un argument pour défendre l'utilisation de ces outils antédiluviens ?

C'est un projet personnel, je ne vois pas le soucis que quelqu'un fasse ça pour le fun. Dans un contexte professionnel, démarrer un projet en C devrait être lourdement justifié bien entendu, dans un contexte perso, qui s'en préoccupe ? Charge à l'auteur d'assumer ce choix.

Les démonstrations formelles ne sont pas accepté, en DO178b, et commence à l'être en DO178c. Le problème principale est que l'outil de validation lui-même doit être écris en DAL A pour être accepté.

Je suis au courant de cela, je disais juste que des équipes se servent de cela durant les étapes de développement pour gagner du temps dans la période avant la certification et éviter de devoir y passer plusieurs fois (car c'est cher).

Je sais bien que ces résultats ne sont pas exploités par les agences de certification ou de contrôle.

Cela commence tout doucement.

Oui, c'est bien ce que je dis, la migration est lente. Si je me souviens bien, un CPU dans la norme DO est considéré comme valide sans plus de preuves que cela s'il est monocoeur et ne réorganise pas l'ordre des instructions… Ce qui est de plus en plus rare aujourd'hui.

Concernant les GPU, je n'ai pas encore vu de code certifié.

Le problème du GPU c'est aussi qu'ils partent sur des hypothèses de GPU simples et donc assez peu puissants. Typiquement on a tâté les limites de la DO avec du Tegra K1 en DAL C, avec donc un CPU et un GPU qui ont une grande mémoire partagée, qui sont très modernes (donc réorganisation des instructions par exemple) et très parallélisés.

Ce cas de figure n'est pas vraiment documenté dans les standards aéro, et ils ont globalement 20 ans de retard sur ce qui est considéré comme standard. Ce qui est un soucis pour introduire bien sûr des calculs plus puissants pour le contrôle de l'appareil.

A part ça, je suis persuadé qu'il doit être possible de pouvoir créer un langage qui respecte toutes les contraintes de la DO178b, de le bootstraper et ensuite de pouvoir écrire plus facilement des applications qualifié.

Je n'en suis pas sûr, quand je m'y étais un peu intéressé il semblait impossible de pouvoir (mathématiquement) faire le langage parfait qui puisse exprimer n'importe quel programme de manière assez simple et en garantir la preuve de son bon fonctionnement.

Car bon, si pour réaliser un noyau de la taille de Linux ou Windows, prouvé fonctionnel, il faut des années de travail, avec une maintenance difficile et des fonctionnalités en moins, ça risque d'être difficile à imposer.

Tu fais références à quoi ?

La démonstration formelle que l'application X (genre le contrôleur des moteurs de l'avion ne crachera pas). Je sais que Coq (ou des outils similaires) ont été utilisé dans ce genre de contexte. Mais que cela reste réservé à ce niveau de criticité et pour des logiciels assez petits.

Il n'y a pas d'étude formelle, mais il y a une norme à respecter https://fr.wikipedia.org/wiki/DO-254

Bien sûr, je connais, j'ai bossé dans le milieu (DAL C au plus haut). Mais tu n'as pas besoin d'aller si loin que ce que kantien annonce à savoir démontrer par les maths que ton système va marcher à tous les coups.

D'ailleurs pour les DAL >= C, il devient difficile d'employer des CPU multi-cœurs ou avec un GPU moderne tellement que c'est contraignant vis à vis des normes. Donc imaginer démontrer avec Coq que Linux tourne bien sur le dernier Intel couplé avec un GPU nVidia, on en est très très loin.

J'ai terminé mes études il y a une quinzaine d'années et ce genre de questions étaient au cœur de la formation.

Je ne sais pas quelle formation tu as eu, mais la question de la qualité dans le développement logiciel c'est loin d'être généralisé même aujourd'hui, que ce soit en entreprise ou dans les formations.

Globalement la qualité se résume souvent à un cahier de tests, avec des tests unitaires ou fuzzing sans oublier la revue de code et l'intégration continue. Quand tu as ça, déjà, tu es content.

À l'époque, les deux seuls langages que l'ont m'a enseigné était OCaml et Coq

Juste pour préciser, très peu d'ingénieurs en France et Belgique (et je pense que c'est plus ou moins pareil partout pour des ingés niveau master) voient dans le cadre scolaire les langages fonctionnels de manière sérieuse. Alors Coq et OCaml tu comprendras que ta formation est assez décalée de ce que rencontre la plupart des développeurs.

Ceci étant dit, il est connu de longue date que la qualité logicielle relève de la preuve mathématique. Les approches dignes des sciences expérimentales à coup de tests unitaires ou de fuzzer, c'est gentil : ça peut détecter la présence de bugs, mais cela n'en prouvera jamais l'absence. À un moment, quand on affirme, il faut pouvoir prouver, quitte à le faire à la main :

Je pense que personne ne va te contredire sur ce point, d'ailleurs Knuth a une citation sur le sujet. Mais il me semble naïf de croire que cette méthode soit viable et générique, en tout cas aujourd'hui.

Je veux dire, en général cette artillerie est réservée vraiment à des domaines de haute criticité où le rapport bénéfice / coût est évident. Typiquement en aéronautique cela sera exigé / recommandé pour les DAL A ou B, mais pas au delà. Et les coûts d'un tel travail est tel que c'est rarement appliqué en dehors de ces contextes là. Qui d'ailleurs reposent sur du matériel et du logiciel simple, élémentaire pour faciliter ce travail. Voire le rendre possible, car si je ne me trompe pas, tu ne peux pas prouver formellement que n'importe quel programme fonctionnera tel qu'attendu.

D'autant que si ton programme a un lien fort avec ton matériel (cas du noyau ou d'un logiciel embarqué), il faut aussi formaliser le matériel et cette liaison. Est-ce que des processeurs ou GPU modernes bénéficient d'un tel travail ? J'en doute.

je tombe des nues. :-O Mais enfin, c'est une évidence pour qui est un minimum rigoureux intellectuellement !

Déjà, je dirais que pour être rigoureux intellectuellement, il faut démontrer que la solution proposée apporte quelque chose. Même si cela paraît évident. Car comme je l'ai dit, ce n'est pas parce que ton travail provient de la recherche universitaire que cela est forcément bénéfique. On ne va pas lister le nombre de prédictions théoriques de la recherche fondamentale (dont sur les noyaux de système d'exploitation) qui n'ont jamais su percer dans l'industrie faute d'adéquation en réalité.

Et encore, c'est en supposant que le travail soit gratuit, ce qui ne l'est bien évidemment pas vrai. Car c'est bien de venir avec une théorie, une idée, il faut quelqu'un pour le mettre en œuvre, le maintenir et que cela ne gêne pas les autres développeurs. Typiquement si tu viens avec un système d'annotation du code, qui pourrait apporter un gain pour l'analyse du noyau. Il faut que quelqu'un annote tout le code existant, documente cette section et que les autres développeurs exploitent cela. C'est un travail titanesque et potentiellement ingrate. Même si le gain sur le long terme est démontré, il faut encore que quelqu'un ou une entité investisse dedans et ce n'est rien d'évident. Surtout que pendant la période de transition tu risques d'avoir des pertes de productivité importantes aussi.

Bref, tout dépend, mais il faut tenir compte de ces éléments aussi dans l'aspect "démonstration". La réalité a ses propres contraintes qui peuvent rendre difficile la transposition recherche théorique / logiciels industriels.

Il vient donc naturellement à l'esprit cette question : la communauté en charge du développement du noyau est-elle sensible à ces questions ou s'en moque-t-elle fondamentalement ?

La communauté ne s'en moque pas, la question de la qualité du noyau est de plus en plus centrale dans les discussions. Cela passe par l'intégration continue, le fuzzing, les tests unitaires, etc. qui se généralisent.

Mais la communauté du noyau n'a pas d'exigence particulière non plus. Selon la communauté avec qui tu parles, la sécurité doit être le critère 1, ici ça parle plutôt de l'analyse et de la conformité du code, pour d'autres ce sera la performance, etc. La communauté du noyau le cherche pas l'excellence dans tous les domaines à la fois (ce n'est pas réaliste) mais un compromis.

De la même façon qu'aujourd'hui tu n'as aucun micro-noyau pur utilisé massivement pour une large gamme d'utilisation. Car si la théorie est belle, les contraintes sont telles que le compromis impose soit de faire du monolithique modulaire (Linux, BSD) ou du micro-noyau enrichi (Windows, macOS, iOS). Pourtant Microsoft et Apple ne sont pas des brelles (ils ont des équipes de R&D à la hauteur), ils peuvent largement payer ou contraindre des employés de bosser sur la question. Et pourtant le résultat est contraire à la prédiction de la recherche du secteur depuis 25 ans.

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.