Pourquoi encore et toujours restreindre à la France?
Car on parle de Jancovici, qui est un ingénieur français et dont ses travaux portent essentiellement sur le cas français.
Ne pas oublier que la politique énergétique en rapport avec la lutte contre le CO2 sera propre à chaque pays, en lien avec ses ressources naturelles, sa population, sa géographie, des coûts et compétences sur place et sa pollution actuelle. On ne peut pas généraliser une politique énergétique mondiale.
Typiquement la Belgique a des points communs avec la France. Un nucléaire très présent. Mais il y a des différences de taille, le pays est bien plus dense (donc les coûts d’implémentation d'une éolienne n'est pas la même), a très peu d'hydroélectricité et a donc recours a beaucoup plus de charbon / gaz / pétrole que la France, la météo n'est pas la même non plus. La Belgique a aussi bien plus recours au gaz de chauffage que la France où le radiateur électrique est trop présent (ce qui induit une très forte sensibilité au froid hivernale pour la consommation électrique).
Donc on peut en parler de la situation belge (je précise que j'y vis aujourd'hui)., ou même la situation canadienne, allemande ou polonaise. Mais il faut le préciser. Avec l'histoire du Jancovici pro-nucléaire, le début se porte surtout sur le cas français qu'il étudie.
continuer a se faire entuber par les fournisseurs étrangers (GDF-Suez) jusqu'à se que Tihange nous irradie tous (c'est probablement se que va choisir le gang mafieux qu'on appel gouvernement [de droite]) ou chercher plusieurs autres solutions compatible avec notre surpopulation.
Note, le soucis en Belgique semble venir du fait que l'AFCN (l'autorité qui s'occupe du nucléaire civile n'est pas indépendante comme en France. Donc l'État peut faire ou subir des pressions politiques pour le maintient du nucléaire même si les infrastructures ne sont pas à la hauteur. C'est ça je pense le vrai problème. Le fait que ce soit des opérateurs étrangers n'a pas une grande importance.
Des trucs comme ça lié au charbon (sans compter les mines et que dans le reste du monde la situation est sans doute pire), ce n'est pas nouveau. Les radiations de Fukushima n'ont entrainé la mort de personne à ce jour (les seuls morts liés sont liés au stress de la catastrophe et à l'évacuation de la zone sinistrée par le séisme).
donc j'ai du mal à voir pourquoi on en parle autant comme d'une solution, même en mettant de côté tous ses dangers.
Car en France nous avons déjà le nucléaire et que de ne pas les exploiter jusqu'au bout est absurde pour l'environnement et pour les coûts (car on rentabilisera moins les investissements sur les centrales).
Jamais je n'ai dit qu'il fallait miser sur le nucléaire au niveau mondial, mais prolonger la situation existantes dans les pays qui en ont car les infrastructures, le savoir faire et les gains associés sont déjà là.
Bref, le seul truc objectif qui, à mon avis, pourrait faire baisser significativement la part du pétrole, charbon et du gaz, c'est juste qu'on consomme moins
Oui, et il faut faire ça avant de passer à des énergies comme l'éolien ou solaire à cause des coûts et investissements à faire. Car si on produit un parc pour la consommation d'aujourd'hui alors que dans 20 ans on aurait pu avoir un parc producteur deux fois plus petit, ça coûtera cher pour un gain dérisoire.
on n'en a pas les moyens à grande échelle, c'est juste un solution (pour l'électrique uniquement) pour un petit nombre de pays
On parle ici de la France, il est évident que la question du 100% renouvelable demande des stratégies différentes suivant les États. On ne peut pas comparer la France qui a une électricité peu émettrice en CO2 grâce au nucléaire avec la Norvège ou Suède qui reposent essentiellement sur l'hydroélectricité (à un niveau que la France ne peut pas atteindre), de la géothermie pour l'Islande qu'avec la Pologne ou la Chine où le charbon est roi.
Une éolienne en Pologne a donc un effet bénéfique bien plus important et moins coûteux qu'en France pour la lutte contre le CO2. Cela change tout dans la stratégie à adopter pour le siècle en cours. C'est ça qui faut retenir. Donc personne ne dit qu'il faut construire en masse des réacteurs nucléaires dans le monde, on parle des pays qui en ont de les maintenir en vie le plus longtemps possible. C'est différent.
On parle d'un scénario 100% renouvelable en France pour remplacer le nucléaire, avec une énergie hydraulique quasiment à pleine capacité, la France ne peut pas recourir à cette méthode pour avoir de l'électricité renouvelable pas chère.
Sinon on peut aussi parler de la géothermie islandais, mais jusqu'à présent ce n'est pas possible à cette échelle en France non plus.
La loi de Moore est déjà entrain de ralentir. On est passé de 18 mois à 22 mois
WTF ? La loi de Moore c'est 2 ans soit 24 mois. Ca n'a jamais été 18 mois.
Et le ralentissement est projeté avec une accélération durant la prochaine décennie
La plupart des acteurs s'accordent à dire qu'après 2020, la loi de Moore sera véritablement finie. Mais dans les faits aujourd'hui ça tourne encore.
C'est probablement une des explications du rattrapage en cour de amd et arm sur Intel.
Bof, Intel ce n'est pas juste une bonne finesse de gravure, c'est aussi de bonnes idées. Mais depuis 5 ans quand AMD était au fond du trou et ARM qui stagnait à augmenter la menace, Intel s'est relâché, ses dernières puces étaient de simple rafraichissements des gammes plus vieilles. AMD avec Ryzen a tout remis à plat pour revenir dans la course.
Note d'ailleurs que ARM et AMD ne font pas leur puce eux même mais exploitent les usines de Samsung ou de TSMC qui eux ont réussi à devancer Intel sur la question de la finesse de gravure.
Bref, tu as raison sur quasiment tous les points, mais dire que la loi de Moore ne fonctionne plus aujourd'hui est faux même si sa fin approche à grand pas.
AMD n'est pas un fondeur tout d'abord.
Intel n'est pas seul sur le marché, Samsung et TSMC sont aussi dans la course (d'ailleurs Intel a un léger retard sur la question sur la concurrence).
Et non, malgré tout la cadence reste haute. Note que ce n'est pas la question du nombre de transistor qui compte mais la densité de transistors. Et pour réduire la consommation d'une puce, le mieux est d'augmenter cette densité, car cela réduit l'effet Joule des connections (car plus petits) donc besoin de moins d'énergie pour faire tourner la puce.
Puis en plus, en tout cas pour le stockage sur des SSD, on a des couches de transistors maintenant. Donc avec une légère élévation spatiale, on peut doubler le nombre de transistors sur une même surface. SI on prend ça en compte, la loi de Moore pourrait s'appliquer longtemps.
Elle l'est, les prévisions tablent plutôt sur un fléchissement à partir de 2020. En tout cas à l'heure actuelle elle reste d'actualité.
Notons que la loi de Moore ne parle que d'un nombre de transistors par centimètres carrés qui doit doubler tous les deux ans, cela ne parle pas de performance (qui resterait à savoir mesurer).
Même sans considérer le problème des déchets, qui n’a jamais été résolu
Il y a pourtant un réacteur nucléaire naturel dans le monde, peu de gens semblent se soucier des déchets de cette réaction naturelle.
et si tous les pays se mettaient à avoir la même proportion de nucléaire que la France, il ne durerait pas longtemps.
L'objectif n'est pas que cela dure longtemps, l'objectif est de se donner plus de temps pour s'adapter car à l'heure actuelle les énergies renouvelables sont bien plus chers que le nucléaire et pour que ce soit viable il faut considérablement réduire la consommation énergétique en très peu de temps. Le risque est donc que le climat se dérègle le temps qu'une solution vraiment pérenne soit mise en place.
C'est une question de priorité, si on considère le CO2 comme le problème numéro 1, le nucléaire est une bonne solution pour le siècle en cours.
Concernant le plutonium, on a abandonné, faute de réussir à sécuriser le refroidissement, mais on espère développer la fusion… alors qu’elle dégage encore plus d’énergie que la fission du plutonium.
Sauf que la fusion et la fission n'ont rien à voir, ce n'est pas le même genre de procédés techniques derrière. Ce qui n'est pas faisable avec le plutonium peut l'être pour la fusion, ce n'est pas qu'une question d'énergie.
Mais dans la réalité, le parc de centrales du pays le plus nucléarisé du monde est vétuste
Ce n'est pas parce qu'un réacteur est à l'arrêt pour maintenance qu'il est vétuste. Tu noteras que malgré cela, le rendement d'une centrale est supérieur à n'importe qu'elle autre source d'énergie (centrale à charbon, gaz, hydraulique, éolienne ou solaire). Une centrale injecte dans le réseau plus longtemps d'électricité que les autres sources. Pas mal pour un truc vétuste. Note que les américains par exemple ont des centrales dont l'âge de l'arrêt est de 80 ans. La France en est encore loin.
on n’est plus capable que de construire une centrale défectueuse en explosant les délais et les budgets.
Car c'est le premier et que la règlementation a changé aussi au milieu. Ce n'est pas anodin dans la réalisation d'un tel projet.
Pour ça, il faudrait commencer par arrêter de mettre des jean-foutres à la tête de l’État : si nous avions des dirigeants un tant soit peu responsables, ils imposeraient déjà que l’EPR soit conforme à l’état de l’art avant qu’il soit mis en service ; ça donnerait un premier signe fort à la filière qu’il est temps d’arrêter les conneries.
Je rappelle que l'État n'a pas un grand pouvoir sur le nucléaire qui est gérée par un organisme indépendant et dont apparemment beaucoup trop de gens semblent ignorer ses avis. Par exemple insister pour fermer la centrale de Fessenheim alors que selon l'autorité d'autres centrales seraient meilleures candidates.
Le problème du tout renouvelable est que pour l'instant :
La production énergétique est trop aléatoire, il faudra redonder les installations et avoir de quoi stocker en cas de panne sèche (ce qui n'est évidemment pas gratuit, on parle d'une électricité entre 2 à 20 fois plus cher) ;
Cela consomme en minerais voire en énergie (produire un panneau solaire avec l'électricité au charbon de Chine, ce n'est pas terrible) ;
Ces installations ne sont pas pilotables (contrairement à l'hydraulique, le nucléaire ou le charbon / gaz) ce qui rend difficile le maintient du signal électrique à 50 Hz si on ne s'alimente qu'avec cela. Pourtant c'est essentiel d'avoir cette garantie pour nos appareils ;
L'électricité français consomme déjà très peu de CO2, passer au renouvelable tout de suite pourrait même nous en faire consommer plus et en aucun cas cela aidera la France à remplir ses objectifs de CO2 (qui est je pense la priorité numéro 1) ;
Malgré toute la crainte du nucléaire, le charbon, et le gaz (qui resteront nécessaires même en cas de 100% renouvelable pour assurer le pilotage du réseau) ont tué et tuent plus aujourd'hui que le nucléaire. Que ce soit dans les mines ou la pollution.
Personnellement, je suis favorable au nucléaire en temps que système temporaire pour gagner du temps pour résoudre l'ensemble du problème vis à vis du climat (et donc de notre mode de vie ou des progrès techniques). Comme le temps manque, je pense qu'on n'a pas le luxe de condamner le nucléaire pour le moment. Il faut je pense plutôt chercher à diminuer notre consommation (en rénovant les bâtiments par exemple) ce qui permettra de fermer notamment des centrales faute de besoin plutôt que de les remplacer tout de suite alors que la demande énergétique reste forte.
Hé ! ce ne serait pas une allusion déguisée à certains de nos échanges récents sur un autre journal. :-P
Pas du tout, à des souvenirs traumatisants du professeur qui ponctuait ses corrections par des références à l'évidence même sans réel explication. Par contre si l'élève osait sous entendre qu'un point de sa démonstration était évidente pour ne pas l'étayer, la sanction arrivait vite.
C'est vrai que les justifications du type mais c'est évident ! ressemble fort à un prof de maths qui ne souhaite pas expliquer la solution en détails. :-)
il n'y a même pas une même phrase identique et on pourrait arguer que M.Gallaire a également commis une infraction en s'inspirant de la communication de Debian.
Tout à fait, c'est là le ridicule de la situation.
Après il n'existe pas en droit français quelque chose contre des assignation abusive ? (je suis citoyen suisse vivant en Suisse, donc je ne connais pas votre droit).
De mémoire, non. C'est le juge qui va déterminer si l'assignation est fondée ou non et donc engager une procédure ou pas. Après suivant comment l'assignation été faite et le motif, il peut être possible d'engager une procédure au bâtonnier contre l'avocat du plaignant pour violation des règles du métier.
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.
[^] # Re: Le nucléaire est sur le déclin
Posté par Renault (site web personnel) . En réponse au journal Next, la web-série sur les risques d’effondrement de notre civilisation, et le monde d’après. Évalué à 6.
Car on parle de Jancovici, qui est un ingénieur français et dont ses travaux portent essentiellement sur le cas français.
Ne pas oublier que la politique énergétique en rapport avec la lutte contre le CO2 sera propre à chaque pays, en lien avec ses ressources naturelles, sa population, sa géographie, des coûts et compétences sur place et sa pollution actuelle. On ne peut pas généraliser une politique énergétique mondiale.
Typiquement la Belgique a des points communs avec la France. Un nucléaire très présent. Mais il y a des différences de taille, le pays est bien plus dense (donc les coûts d’implémentation d'une éolienne n'est pas la même), a très peu d'hydroélectricité et a donc recours a beaucoup plus de charbon / gaz / pétrole que la France, la météo n'est pas la même non plus. La Belgique a aussi bien plus recours au gaz de chauffage que la France où le radiateur électrique est trop présent (ce qui induit une très forte sensibilité au froid hivernale pour la consommation électrique).
Donc on peut en parler de la situation belge (je précise que j'y vis aujourd'hui)., ou même la situation canadienne, allemande ou polonaise. Mais il faut le préciser. Avec l'histoire du Jancovici pro-nucléaire, le début se porte surtout sur le cas français qu'il étudie.
Note, le soucis en Belgique semble venir du fait que l'AFCN (l'autorité qui s'occupe du nucléaire civile n'est pas indépendante comme en France. Donc l'État peut faire ou subir des pressions politiques pour le maintient du nucléaire même si les infrastructures ne sont pas à la hauteur. C'est ça je pense le vrai problème. Le fait que ce soit des opérateurs étrangers n'a pas une grande importance.
[^] # Re: Le nucléaire est sur le déclin
Posté par Renault (site web personnel) . En réponse au journal Next, la web-série sur les risques d’effondrement de notre civilisation, et le monde d’après. Évalué à 4.
Suffit de sortir tous les articles parus ces dernières années qui chiffrent des morts liés à la pollution atmosphérique, aller j'en ai un : http://www.lemonde.fr/pollution/article/2016/07/05/le-charbon-entraine-23-000-morts-prematurees-en-europe-chaque-annee_4964092_1652666.html
Des trucs comme ça lié au charbon (sans compter les mines et que dans le reste du monde la situation est sans doute pire), ce n'est pas nouveau. Les radiations de Fukushima n'ont entrainé la mort de personne à ce jour (les seuls morts liés sont liés au stress de la catastrophe et à l'évacuation de la zone sinistrée par le séisme).
Car en France nous avons déjà le nucléaire et que de ne pas les exploiter jusqu'au bout est absurde pour l'environnement et pour les coûts (car on rentabilisera moins les investissements sur les centrales).
Jamais je n'ai dit qu'il fallait miser sur le nucléaire au niveau mondial, mais prolonger la situation existantes dans les pays qui en ont car les infrastructures, le savoir faire et les gains associés sont déjà là.
Oui, et il faut faire ça avant de passer à des énergies comme l'éolien ou solaire à cause des coûts et investissements à faire. Car si on produit un parc pour la consommation d'aujourd'hui alors que dans 20 ans on aurait pu avoir un parc producteur deux fois plus petit, ça coûtera cher pour un gain dérisoire.
On parle ici de la France, il est évident que la question du 100% renouvelable demande des stratégies différentes suivant les États. On ne peut pas comparer la France qui a une électricité peu émettrice en CO2 grâce au nucléaire avec la Norvège ou Suède qui reposent essentiellement sur l'hydroélectricité (à un niveau que la France ne peut pas atteindre), de la géothermie pour l'Islande qu'avec la Pologne ou la Chine où le charbon est roi.
Une éolienne en Pologne a donc un effet bénéfique bien plus important et moins coûteux qu'en France pour la lutte contre le CO2. Cela change tout dans la stratégie à adopter pour le siècle en cours. C'est ça qui faut retenir. Donc personne ne dit qu'il faut construire en masse des réacteurs nucléaires dans le monde, on parle des pays qui en ont de les maintenir en vie le plus longtemps possible. C'est différent.
[^] # Re: Le nucléaire est sur le déclin
Posté par Renault (site web personnel) . En réponse au journal Next, la web-série sur les risques d’effondrement de notre civilisation, et le monde d’après. Évalué à 6.
C'est gentil de me prendre pour un idiot mais je pensais plutôt à un cas naturel sur Terre en surface : https://fr.wikipedia.org/wiki/R%C3%A9acteur_nucl%C3%A9aire_naturel_d%27Oklo
[^] # Re: Le nucléaire est sur le déclin
Posté par Renault (site web personnel) . En réponse au journal Next, la web-série sur les risques d’effondrement de notre civilisation, et le monde d’après. Évalué à 7.
On parle d'un scénario 100% renouvelable en France pour remplacer le nucléaire, avec une énergie hydraulique quasiment à pleine capacité, la France ne peut pas recourir à cette méthode pour avoir de l'électricité renouvelable pas chère.
Sinon on peut aussi parler de la géothermie islandais, mais jusqu'à présent ce n'est pas possible à cette échelle en France non plus.
[^] # Re: Jouer au démineur en 2157
Posté par Renault (site web personnel) . En réponse au journal Next, la web-série sur les risques d’effondrement de notre civilisation, et le monde d’après. Évalué à 4.
WTF ? La loi de Moore c'est 2 ans soit 24 mois. Ca n'a jamais été 18 mois.
La plupart des acteurs s'accordent à dire qu'après 2020, la loi de Moore sera véritablement finie. Mais dans les faits aujourd'hui ça tourne encore.
Bof, Intel ce n'est pas juste une bonne finesse de gravure, c'est aussi de bonnes idées. Mais depuis 5 ans quand AMD était au fond du trou et ARM qui stagnait à augmenter la menace, Intel s'est relâché, ses dernières puces étaient de simple rafraichissements des gammes plus vieilles. AMD avec Ryzen a tout remis à plat pour revenir dans la course.
Note d'ailleurs que ARM et AMD ne font pas leur puce eux même mais exploitent les usines de Samsung ou de TSMC qui eux ont réussi à devancer Intel sur la question de la finesse de gravure.
Bref, tu as raison sur quasiment tous les points, mais dire que la loi de Moore ne fonctionne plus aujourd'hui est faux même si sa fin approche à grand pas.
[^] # Re: Jouer au démineur en 2157
Posté par Renault (site web personnel) . En réponse au journal Next, la web-série sur les risques d’effondrement de notre civilisation, et le monde d’après. Évalué à 3.
AMD n'est pas un fondeur tout d'abord.
Intel n'est pas seul sur le marché, Samsung et TSMC sont aussi dans la course (d'ailleurs Intel a un léger retard sur la question sur la concurrence).
Et non, malgré tout la cadence reste haute. Note que ce n'est pas la question du nombre de transistor qui compte mais la densité de transistors. Et pour réduire la consommation d'une puce, le mieux est d'augmenter cette densité, car cela réduit l'effet Joule des connections (car plus petits) donc besoin de moins d'énergie pour faire tourner la puce.
Puis en plus, en tout cas pour le stockage sur des SSD, on a des couches de transistors maintenant. Donc avec une légère élévation spatiale, on peut doubler le nombre de transistors sur une même surface. SI on prend ça en compte, la loi de Moore pourrait s'appliquer longtemps.
[^] # Re: Jouer au démineur en 2157
Posté par Renault (site web personnel) . En réponse au journal Next, la web-série sur les risques d’effondrement de notre civilisation, et le monde d’après. Évalué à 3.
Elle l'est, les prévisions tablent plutôt sur un fléchissement à partir de 2020. En tout cas à l'heure actuelle elle reste d'actualité.
Notons que la loi de Moore ne parle que d'un nombre de transistors par centimètres carrés qui doit doubler tous les deux ans, cela ne parle pas de performance (qui resterait à savoir mesurer).
[^] # Re: Le nucléaire est sur le déclin
Posté par Renault (site web personnel) . En réponse au journal Next, la web-série sur les risques d’effondrement de notre civilisation, et le monde d’après. Évalué à 7.
Il y a pourtant un réacteur nucléaire naturel dans le monde, peu de gens semblent se soucier des déchets de cette réaction naturelle.
L'objectif n'est pas que cela dure longtemps, l'objectif est de se donner plus de temps pour s'adapter car à l'heure actuelle les énergies renouvelables sont bien plus chers que le nucléaire et pour que ce soit viable il faut considérablement réduire la consommation énergétique en très peu de temps. Le risque est donc que le climat se dérègle le temps qu'une solution vraiment pérenne soit mise en place.
C'est une question de priorité, si on considère le CO2 comme le problème numéro 1, le nucléaire est une bonne solution pour le siècle en cours.
Sauf que la fusion et la fission n'ont rien à voir, ce n'est pas le même genre de procédés techniques derrière. Ce qui n'est pas faisable avec le plutonium peut l'être pour la fusion, ce n'est pas qu'une question d'énergie.
Ce n'est pas parce qu'un réacteur est à l'arrêt pour maintenance qu'il est vétuste. Tu noteras que malgré cela, le rendement d'une centrale est supérieur à n'importe qu'elle autre source d'énergie (centrale à charbon, gaz, hydraulique, éolienne ou solaire). Une centrale injecte dans le réseau plus longtemps d'électricité que les autres sources. Pas mal pour un truc vétuste. Note que les américains par exemple ont des centrales dont l'âge de l'arrêt est de 80 ans. La France en est encore loin.
Car c'est le premier et que la règlementation a changé aussi au milieu. Ce n'est pas anodin dans la réalisation d'un tel projet.
Je rappelle que l'État n'a pas un grand pouvoir sur le nucléaire qui est gérée par un organisme indépendant et dont apparemment beaucoup trop de gens semblent ignorer ses avis. Par exemple insister pour fermer la centrale de Fessenheim alors que selon l'autorité d'autres centrales seraient meilleures candidates.
Le problème du tout renouvelable est que pour l'instant :
Personnellement, je suis favorable au nucléaire en temps que système temporaire pour gagner du temps pour résoudre l'ensemble du problème vis à vis du climat (et donc de notre mode de vie ou des progrès techniques). Comme le temps manque, je pense qu'on n'a pas le luxe de condamner le nucléaire pour le moment. Il faut je pense plutôt chercher à diminuer notre consommation (en rénovant les bâtiments par exemple) ce qui permettra de fermer notamment des centrales faute de besoin plutôt que de les remplacer tout de suite alors que la demande énergétique reste forte.
[^] # Re: l'assignation ne va jamais venir
Posté par Renault (site web personnel) . En réponse à la dépêche Seconde mise en demeure pour l'association LinuxFr. Évalué à 6.
Pas du tout, à des souvenirs traumatisants du professeur qui ponctuait ses corrections par des références à l'évidence même sans réel explication. Par contre si l'élève osait sous entendre qu'un point de sa démonstration était évidente pour ne pas l'étayer, la sanction arrivait vite.
[^] # Re: l'assignation ne va jamais venir
Posté par Renault (site web personnel) . En réponse à la dépêche Seconde mise en demeure pour l'association LinuxFr. Évalué à 5.
C'est vrai que les justifications du type mais c'est évident ! ressemble fort à un prof de maths qui ne souhaite pas expliquer la solution en détails. :-)
Tout à fait, c'est là le ridicule de la situation.
De mémoire, non. C'est le juge qui va déterminer si l'assignation est fondée ou non et donc engager une procédure ou pas. Après suivant comment l'assignation été faite et le motif, il peut être possible d'engager une procédure au bâtonnier contre l'avocat du plaignant pour violation des règles du métier.
[^] # 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.