Le problème est plus général que le simple Linuxfr. C'est aussi vis à vis du plaignant.
Si DLFP se couche, le plaignant va être conforté dans sa position, en pensant avoir raison et pouvant obtenir n'importe quoi des autres avec une menace d'un procès. Si tout le monde agit comme ça, il pourra continuer ce genre de comportements longtemps, avec d'autres personnes, pour d'autres motifs.
Si DLFP résiste, il est probable qu'il se calme par la suite (car un procès c'est cher et ça coûte du temps pour lui aussi).
Ne pas oublier que c'est le plaignant qui a sorti l’artillerie pour un article sans grand intérêt, pas Linuxfr qui ne fait que défendre sa position.
Je redemarre mon linux quand j'ai un kernel ou une libc6 updated (au minimum) mais le redemarrage c'est instantane, il ne me met pas un message "je fais un update" et il bloque a 17% pendant des dizaines de minutes.
Tu n'as pas lu tout ce que j'ai dit. Pour éviter qu'une MaJ foire, il doit être fait dans un environnement minimal. Pour Windows, Android ou macOS / iOS c'est au redémarrage de la machine. D'ailleurs, GNOME Logiciels (avec PackageKit) reprend également cette logique pour cette raison.
Après que ce soit trop long ou fait à des moments peu opportuns, je peux le comprendre mais c'est un autre sujet. Cela n'empêche pas que le redémarrage et l'installation dite hors ligne sont nécessaires.
Autre avantage, vu que windows ne sait toujours pas faire des updates sans redemarrer le pc et le bloquer pendant des dizaines de minutes, je suis sur que cela ne m'arrive pas au mauvais moment.
Je pense qu'il faut arrêter avec le mythe de Microsoft ce sont des imbéciles qui ne savent pas faire des MaJ. Pour avoir bossé sur ce genre de sujet (pour des systèmes embarqués), c'est loin d'être des mauvais sur le sujet.
En fait installer à chaud la mise à jour d'un logiciel, c'est totalement stupide. Oui. C'est le meilleur moyen pour avoir des bogues difficilement reproductibles et compréhensibles, d'avoir une mise à jour que partielle ou d'avoir une corruption de sa machine.
Car, déjà, plus tu as de composants qui tournent, qui prennent des ressources et peuvent faire planter la machine, plus le risque que la MaJ n'aille pas au bout augmente. D'ailleurs, plusieurs distributions ont expérimenté dans leur vie des MaJ qui lancées depuis un terminal dans une console graphique posait des soucis.
En plus, pour qu'une MaJ soit bien appliquée, il faut très souvent relancer toute la machine. Sinon, les bibliothèques ou programmes bas niveaux que tu mets à jour ne seront pas rechargés, en mémoire tu auras l'ancienne version voire un mélange des deux. Et ce mélange peut mener à des problèmes assez amusants pour le système qui ne comprend pas forcément ce qui se passe (le chemin d'une bibliothèque nécessaire est le même que celui d'un autre programme déjà en mémoire, mais les fichiers diffèrent, ils vont tenter d'optimiser la consommation mémoire en partageant la bibliothèque alors qu'en fait ce sera potentiellement incompatible).
La seule façon de faire les MaJ à chaud, ce sont les applications dans des bacs à sable où il suffit de recharger le bac à sable et c'est bon car toutes les dépendances seront correctement rafraîchies. Bizarrement, les grands acteurs (Microsoft, Google et Apple, des branquignoles apparemment pour toi) appliquent cette politique : mise à jour système, il faut redémarrer pour l'appliquer (à chaud ce n'est que le téléchargement), si bac à sable (application de leur Store) suffit de relancer l'application.
Hum, je crois que tu es passé totalement à côté de mon commentaire qui critiquait le titre du journal et les propos d'Andrew que de la question des firmwares et d'Intel.
L'UEFI pourrissait déjà la vie des gens qui souhaitait installer un linux sur leur PC…
Mouais, je ne trouve pas personnellement que ce soit encore le cas aujourd'hui. Honnêtement, tu ne vois pas la différence.
L'UEFI apporte même un certain confort, tu peux faire du multiboot en te débarrassant de GRUB ou équivalent (car l'UEFI permet nativement de le faire lui même), tu as bien plus d'options et de souplesse qu'un BIOS traditionnel… Le partitionnement GPT c'est quand même agréable par rapport à son ancêtre.
Et alors, si vous aviez l'habitude de tranquillement vous évader de votre environnement Windows d'entreprise à coup de linux sous VirtualBox, pourquoi pas piloté par Vagrant, hé bien vous risquez de vous voir imposer Hyper-V comme solution unique de virtualisation pour d'obscures raisons de sécurité.
Je ne vois pas en quoi cet article te permet d'aller vers ta conclusion.
De ce que j'en ai compris, le but est de sécuriser des logiciels sous Windows par des procédés matériels. Donc je ne vois pas le rapport avec la virtualisation habituelle type VirtualBox, et encore moins avec Linux qui virtualiserait un Windows. On ne parle que d'applications sous Windows…
De plus, ce qui est décrit est un cahier des charges pour définir ce qu'est un ordinateur sécurisé. Un peu comme Intel pour les Ultrabook. Cela ne va concerner que certains produits définis (probablement pour des professionnels) et n'empêchera pas de faire autrement (tout comme on a des ordinateurs portables non ultrabook). Mais les constructeurs ne pourront pas abuser d'un terme commercial autour de la sécurité de leur produit s'ils ne respectent pas le cahier des charges en question.
J'ai peut être mal compris de quoi il était question, mais pour l'instant je ne vois pas le lien entre l'article et ce que tu énonces.
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.
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.
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.
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.
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).
[^] # Re: Le plus malin est en général le premier qui cède
Posté par Renault (site web personnel) . En réponse à la dépêche Seconde mise en demeure pour l'association LinuxFr. Évalué à 4.
Tout à fait, d'ailleurs, a-t-il était mis au courant de l'affaire en amont ? Est-il dans la procédure ?
[^] # Re: Vraie question...
Posté par Renault (site web personnel) . En réponse à la dépêche Seconde mise en demeure pour l'association LinuxFr. Évalué à 8.
Il n'y a aucune obligation à censurer ce genre d'informations.
Mais je suppose que Linuxfr se protège contre le risque d'une attaque pour diffamation.
[^] # Re: Le plus malin est en général le premier qui cède
Posté par Renault (site web personnel) . En réponse à la dépêche Seconde mise en demeure pour l'association LinuxFr. Évalué à 10.
Le problème est plus général que le simple Linuxfr. C'est aussi vis à vis du plaignant.
Si DLFP se couche, le plaignant va être conforté dans sa position, en pensant avoir raison et pouvant obtenir n'importe quoi des autres avec une menace d'un procès. Si tout le monde agit comme ça, il pourra continuer ce genre de comportements longtemps, avec d'autres personnes, pour d'autres motifs.
Si DLFP résiste, il est probable qu'il se calme par la suite (car un procès c'est cher et ça coûte du temps pour lui aussi).
Ne pas oublier que c'est le plaignant qui a sorti l’artillerie pour un article sans grand intérêt, pas Linuxfr qui ne fait que défendre sa position.
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par Renault (site web personnel) . En réponse au journal Après l'UEFI, la VBS. Évalué à 4.
Tu n'as pas lu tout ce que j'ai dit. Pour éviter qu'une MaJ foire, il doit être fait dans un environnement minimal. Pour Windows, Android ou macOS / iOS c'est au redémarrage de la machine. D'ailleurs, GNOME Logiciels (avec PackageKit) reprend également cette logique pour cette raison.
Après que ce soit trop long ou fait à des moments peu opportuns, je peux le comprendre mais c'est un autre sujet. Cela n'empêche pas que le redémarrage et l'installation dite hors ligne sont nécessaires.
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par Renault (site web personnel) . En réponse au journal Après l'UEFI, la VBS. Évalué à 6.
Je pense qu'il faut arrêter avec le mythe de Microsoft ce sont des imbéciles qui ne savent pas faire des MaJ. Pour avoir bossé sur ce genre de sujet (pour des systèmes embarqués), c'est loin d'être des mauvais sur le sujet.
En fait installer à chaud la mise à jour d'un logiciel, c'est totalement stupide. Oui. C'est le meilleur moyen pour avoir des bogues difficilement reproductibles et compréhensibles, d'avoir une mise à jour que partielle ou d'avoir une corruption de sa machine.
Car, déjà, plus tu as de composants qui tournent, qui prennent des ressources et peuvent faire planter la machine, plus le risque que la MaJ n'aille pas au bout augmente. D'ailleurs, plusieurs distributions ont expérimenté dans leur vie des MaJ qui lancées depuis un terminal dans une console graphique posait des soucis.
En plus, pour qu'une MaJ soit bien appliquée, il faut très souvent relancer toute la machine. Sinon, les bibliothèques ou programmes bas niveaux que tu mets à jour ne seront pas rechargés, en mémoire tu auras l'ancienne version voire un mélange des deux. Et ce mélange peut mener à des problèmes assez amusants pour le système qui ne comprend pas forcément ce qui se passe (le chemin d'une bibliothèque nécessaire est le même que celui d'un autre programme déjà en mémoire, mais les fichiers diffèrent, ils vont tenter d'optimiser la consommation mémoire en partageant la bibliothèque alors qu'en fait ce sera potentiellement incompatible).
La seule façon de faire les MaJ à chaud, ce sont les applications dans des bacs à sable où il suffit de recharger le bac à sable et c'est bon car toutes les dépendances seront correctement rafraîchies. Bizarrement, les grands acteurs (Microsoft, Google et Apple, des branquignoles apparemment pour toi) appliquent cette politique : mise à jour système, il faut redémarrer pour l'appliquer (à chaud ce n'est que le téléchargement), si bac à sable (application de leur Store) suffit de relancer l'application.
[^] # Re: Best practices
Posté par Renault (site web personnel) . En réponse au journal Après l'UEFI, la VBS. Évalué à 9.
De même qu'avec des BIOS bogué ou tatoué, tu n'étais pas à l'abri d'un soucis pour installer Linux non plus…
[^] # Re: Titre putaclick
Posté par Renault (site web personnel) . En réponse au journal Minix plus utilisé que Linux!. Évalué à 5.
Hum, je crois que tu es passé totalement à côté de mon commentaire qui critiquait le titre du journal et les propos d'Andrew que de la question des firmwares et d'Intel.
# Je ne suis pas sûr que tu aies bien compris
Posté par Renault (site web personnel) . En réponse au journal Après l'UEFI, la VBS. Évalué à 10.
Mouais, je ne trouve pas personnellement que ce soit encore le cas aujourd'hui. Honnêtement, tu ne vois pas la différence.
L'UEFI apporte même un certain confort, tu peux faire du multiboot en te débarrassant de GRUB ou équivalent (car l'UEFI permet nativement de le faire lui même), tu as bien plus d'options et de souplesse qu'un BIOS traditionnel… Le partitionnement GPT c'est quand même agréable par rapport à son ancêtre.
Je ne vois pas en quoi cet article te permet d'aller vers ta conclusion.
De ce que j'en ai compris, le but est de sécuriser des logiciels sous Windows par des procédés matériels. Donc je ne vois pas le rapport avec la virtualisation habituelle type VirtualBox, et encore moins avec Linux qui virtualiserait un Windows. On ne parle que d'applications sous Windows…
De plus, ce qui est décrit est un cahier des charges pour définir ce qu'est un ordinateur sécurisé. Un peu comme Intel pour les Ultrabook. Cela ne va concerner que certains produits définis (probablement pour des professionnels) et n'empêchera pas de faire autrement (tout comme on a des ordinateurs portables non ultrabook). Mais les constructeurs ne pourront pas abuser d'un terme commercial autour de la sécurité de leur produit s'ils ne respectent pas le cahier des charges en question.
J'ai peut être mal compris de quoi il était question, mais pour l'instant je ne vois pas le lien entre l'article et ce que tu énonces.
[^] # Re: Licence
Posté par Renault (site web personnel) . En réponse au journal Minix plus utilisé que Linux!. Évalué à 5.
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.
[^] # Re: Licence
Posté par Renault (site web personnel) . En réponse au journal Minix plus utilisé que Linux!. Évalué à 5.
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).
# Titre putaclick
Posté par Renault (site web personnel) . En réponse au journal Minix plus utilisé que Linux!. Évalué à 10.
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.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Renault (site web personnel) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 7.
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.
Le C a quelques domaines :
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.
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.
[^] # Re: Le cerveau n'est pas logique
Posté par Renault (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
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.
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.
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.
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.
[^] # Re: Le cerveau n'est pas logique
Posté par Renault (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
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.
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.
[^] # Re: Le cerveau n'est pas logique
Posté par Renault (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 6.
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.
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.
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.
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.
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.
[^] # Re: Le cerveau n'est pas logique
Posté par Renault (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
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.
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.
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.
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.
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.
[^] # Re: Le cerveau n'est pas logique
Posté par Renault (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
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 :
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.
[^] # Re: Comportement attendu
Posté par Renault (site web personnel) . En réponse au journal Compilateur trop intelligent. Évalué à 5.
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.
[^] # Re: Comportement indéfini ou incorrect ?
Posté par Renault (site web personnel) . En réponse au journal Compilateur trop intelligent. Évalué à 2.
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.
[^] # Re: Comportement attendu
Posté par Renault (site web personnel) . En réponse au journal Compilateur trop intelligent. Évalué à 10.
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 ?
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.
[^] # Re: Le cerveau n'est pas logique
Posté par Renault (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 6.
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.
[^] # Re: Intégré à Gnome
Posté par Renault (site web personnel) . En réponse au journal Eolie: 6 mois plus tard.. Évalué à 10.
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 :
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 :
Après chacun ses choix, mais cela ne me semble pas aberrant de vouloir un outil intégré dans son environnement, au contraire.
[^] # Re: En parlant de lire ...
Posté par Renault (site web personnel) . En réponse au journal Alerte du 16 octobre en cours : wpa_supplicant souffre d'une faille de sécurité. Évalué à 7.
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.
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 :
Je ne vois aucun avantage objectif à ce que les petits projets type OpenBSD soit privilégié dans ce dossier.
[^] # Re: En parlant de lire ...
Posté par Renault (site web personnel) . En réponse au journal Alerte du 16 octobre en cours : wpa_supplicant souffre d'une faille de sécurité. Évalué à 7.
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.
[^] # Re: En parlant de lire ...
Posté par Renault (site web personnel) . En réponse au journal Alerte du 16 octobre en cours : wpa_supplicant souffre d'une faille de sécurité. Évalué à 7.
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.
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.
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.
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 ?
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 !
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).