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.
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.
[^] # 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.
[^] # 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.