trancheX a écrit 81 commentaires

Pas si vite pour le match nul.
Puisqu'on prendrai en compte le rendement de la production d'électricité : il manque le rendement de la production d'essence (extraction, acheminement, raffinage tous ça…). Même si c'est moche à dire une centrale Nucléaire a surement un bien meilleur rendement que de produire l'équivalent de puissance en baril d'essence utilisable par nos voiture.

Je vais essayer d'expliquer mais je suis pas un expert en cryptographie et en stat.

En fait tu donnes un peu la réponse dans ta question : ça rend couteux l'attaque qui essayerait de compromettre la blockchain.
La preuve de travail dans le cas de Bitcoin est un problème dont :

• la solution est très couteuse en temps de calcul à trouver
• la solution est vérifiable très facilement

La validation d'un nouveau block de la blockchain nécessite de fournir la solution à un problème émis à tous les nœuds. Les nœuds ayant trouver la solution envoient le résultat aux autres nœuds qui peuvent vérifier la réponse facilement. Si tous les nœuds valident la solution envoyée alors c'est bon.
Une attaque nécessiterai de contrôler tous les nœuds ayant trouvés la solution ce qui est, du fait du nombre de participants et de la difficulté, statistiquement impossible.

Je ne suis pas capable d'expliquer mieux et ce n'est sans doute pas assez précis mais en gros c'est l'idée. La page wikipedia sur ce sujet en parle peut être mieux que moi

Après faut reconnaitre que :

• il y aurait plein de portefeuilles Bitcoin perdus
• c'est pas vraiment utilisable tel quel le Bitcoin

Mais oui, c'est pour ça que je dis que c'est de la chrématistique (un mot classe pour dire pic-sous)

Tu les as eu comment les chiffres sur le nombre d'échanges (bitcoin et économie mondiale) ? Parce que j'ai voulu faire cette comparaison puis j'ai laissé tomber faute de données "sourçables".

Arf, désolé. J'ai pas fais du tout de recherches pour remplacer des mots par des synonymes afin d'éviter d'avoir des répétitions.
Pour moi efficience = bon rendement tout simplement

Merci, c'est vrai que j'avais complétement sous estimé le temps que ça me prendrai de faire une réponse complète. "Chronophage" c'est vraiment le mot qui convient; je ferais pas ça tous les 4 matins.

Ha, j'avais pas vu ça : j'aurai du chercher avant de dire des âneries. C'est juste moi qui n’ai encore jamais vu de puces ARM smt dans les projets de ma boite (de MIPS non plus), mais en fait ça existe. Bon à savoir.

Ça a rien de bon pour MIPS qui n'a aucune chance de revenir dans la course du coup.

Pour en remettre une couche sur les bookmarks : Cloudflare avait fait des bechmarks (pour leur cas d'utilisation) relativement détaillé entre intel vs qualcomm et ce qui en ressort c'est que à part quelque soft pas encore très optimisé pour ARM64 les puces serveur de Qualcomm sont très compétitive … en tous cas pour ce que CloudFlare utilise.
Le rapport perf/Watt est à l'avantage de ARM manifestement.
De plus il me semble que les puces ARM sont nettement moins chère que les x86 intel, le rapport perf/$ à l'achat et sans doute aussi à l'avantage de ARM.

Le patron de cloudflare avait déclaré que même avec des puces intel gratuites il leur serait toujours plus intéressant de passer à ARM :

“We think we're now at a point where we can go one hundred percent to ARM. In our analysis, we found that even if Intel gave us the chips for free, it would still make sense to switch to ARM, because the power efficiency is so much better.”

Mais il n'y a pas que ARM, je ne sais pas si MIPS ne pourrait pas venir le concurrencer sur les serveurs avec des puces gérant le SMT, ce que à ma connaissance ne fait pas ARM.

J'avoue que j'ai du mal à conceptualiser un algo qui pourrait comprendre les règles de n’importe quel jeux simplement en observant des parties. Et dans cette phrase je ne met pas en doute ce que tu dis : je reconnais ma propre limite. Tu as donc sans doute raison; même si ça m'embête un peu.

Bien que les résultats d'AlphaGo_Zero soient impressionnants, le terme IA est survendu. Ça ne reste que des programmes et des algorithmes, le fait qu'ils soient compliqués n'y change rien : ils restent cantonné aux domaines pour lesquels ils ont été programmé.
L'apprentissage d'alphaGo_zero c'est le résultat d'un programme qui a optimisé un réseau de neurone pour un problème donné.

Par exemple est ce que l'intelligence artificiel d'AlphaGo_Zero aurait était capable de faire de même sans qu'on lui programme les règles du jeux ? En ne lui laissant qu'observer des parties.
Un humain saura apprendre et déduire simplement en observant, les IA actuelles en sont incapables … (ou je me trompe ?).

Je travail aussi dans l'embarqué et je parle vraiment en connaissance de cause quand je dis pas de MMU + freeRTOS + lwIP (de toute façon freeRTOS est plus un framework d'OS qu'un OS et n'as donc pas besoin de MMU).

…mais de là à dire que cela bloque le déploiement de l'IPv6 il ne faut pas abuser.

J'ai jamais dis que ça ralentit l'adoption d'IPv6, juste que ces équipements vont exister encore quelque temps, c'est comme ça et personne n'est vraiment à blâmer.
Le fait d'avoir quelque équipements ne gérant que l'IPv4 sur son réseau local ne doit pas être un frein à l'adoption d'IPv6.

Je ne sais pas où tu vis, mais tous les équipements et systèmes vendus dans le commerce aujourd'hui, et depuis de nombreuses années d'ailleurs (à part de rares exceptions ?) sont compatibles IPv6. Même les boxs des FAI.

C'est vrai pour la plupart des équipements réseaux (et heureusement pour les box des FAI).
Mais pour des équipements dit "embarqué", comme c'est surement le cas pour beaucoup de caméras de vidéo surveillance connectées (pas chère) : il est probable qu'elles fonctionnes juste avec des microcontrôleurs sans MMU donc pas de linux ni de *BSD donc pas d'OS avec de pile IPV4+v6 toute faite.
C'est souvent du freeRTOS ou autre "miniOS" et la pile IP la plus utilisé est sans doute lwIP, qui supporte l'ipv6 et l'ipv4 conjointement depuis la version 2.0 qui date de Novembre 2016.

Et novembre 2016 c'était peut être pas pas hier, mais disons avant hier pour du code embarqué dans des produits disposant de peu de suivi et/ou dont les validations de code peuvent être longue.
Avant qu'on ne commence à critiquer les fabricants de ces systèmes. Je vais comparer la version de lwIP majoritairement utilisé avec la version du noyau d'Android la plus utilisé qui est Marshmallow avec 28.6% d'utilisation (au moment ou j'écris ces lignes) et qui tourne avec un noyau Linux (3.18) qui date de décembre 2014

C'est donc pas rare ni étonnant d'avoir des équipements tournant avec lwIP 1.4.0 et donc ne pas avoir le support d'IPv6

Même s'il est peu probable que quelqu'un devine leur IP IPv6 publique…

Attention quand même : il y a pas besoin de deviner si on est malin. Le service NTP de nombreux équipements est souvent ntp.pool.org , il suffit que des personnes mal intentionnées rejoignent le pool et ils pourront récolter des ipv6 publique.
-> En fait ça a déjà été fait

Pour la représentation de l'heure, c'est quand même une mauvaise idée : le client au brésil qui aura pas de bol et sera trop perfectionniste va chercher pendant une semaine pourquoi son parc de machine affiche une mauvaise heure dans l'UEFI pendant la semaine du Carnavale lui ça le dessert d'avoir l'heure quand il va dans le BIOS.
Alors qu'aucun utilisateur ne reprochera de devoir regarder sa montre/son telephone pour avoir l'heure lorsqu'il modifi son BIOS/UEFI.

Le fait de calculer un décalage d'heure indique de pouvoir calculer genre le dernier ou le 3eme dimanche du mois ou le premier lundi (enfin tous ça dépend des pays) + de stocker les régles de changement d'heure.
Ok ça fait pas des milliers de ligne mais un peu plus que quelque lignes

Tous le problème n'est pas là effectivement il y a des choses complexe mais si elle doivent être faite c'est normal de le faire (U-Boot, PXE etc sont des exemples).
Le problème c'est que j'ai l'impression que ce genre de chose participe à un bordel ambiant chez les concepteurs de carte mère (je veux dire bordel dans leur code).
En fait, ce que je reproche aux UEFI des fabricants c'est justement de ne pas se concentrer sur l'essentiel :
- être sécurisé
- être auditable
- booter rapidement
- booter rapidement
- booter rapidement
et booter plus rapidement

Franchement pas mal de PC le BIOS/UEFI est plus lent que le démarrage du kernel et pour les serveurs c'est encore plus flagrant.

Comme beaucoup d'UEFI sont programmés en Asie, en réalité c'est l'anglais qui est une traduction. :-)
C'est quand même dommage qu'il aient tous repris le code UEFI d'intel (donc en anglais) l'ai lu est compris et ré-implémenté pour y coller une interface traduite :-(

parfois il vaut mieux quelque chose qui fonctionne bien pour 90%

C'est plus du tout pareil que :

gérer l'heure matérielle de la machine proprement de manière univoque

… mais bon pour le cas présent ça va l'UEFI n'essait pas de faire ça (en tout cas la spec ne dit pas ça)

Le problème c'est que ce genre de chose ne sert à rien, ça ajoute beaucoup de complexité pour rien.

Tout comme traduire l'interface de la configuration de la carte mère, je préfères que tous les constructeurs fassent une interface avec les même termes en anglais; les utilisateurs qui voudrons changer quelque chose sauront très bien retrouver ce qu'ils souhaitent même sans aucune maitrise de l'anglais (juste un coup baidu/yandex/google/ddg/…)
ça sera 1000x mieux qu'une interface passé au google-translate

Je comprend bien que l'UEFI permet une abstraction qui standardise et fait qu'on peut installer n’importe quel OS sur n’importe quel PC; mais l'UEFI n'as pas besoin d'être un OS pour faire ça.

Pourquoi l'UEFI de la carte mère devrait être incapable d'afficher l'heure réelle de chez moi quand j'y vais dedans ? D'autant que ce n'est pas si compliqué ?

Alors là non, que la carte mère dispose des champs mémoire nécessaire à un OS pour calculer l'heure locale, ok ; qu'elle sache le faire toutes seule là non. Car :
- Si chez toi c'est sur l'île de Lord Howe alors (comme chacun sait) l'heure d'été ne fait un offset que de 30min ici
- Si chez toi c'est au Maroc alors il y 4 changements d'heure dans l'année
- Si chez toi c'est au Brésil la fin du changement d'heure est décalé d'une semaine si elle tombe en même temps que le Carnaval de Rio
- Si chez toi c'était en Israël la carte mère aurait nécessité une MAJ pour calculer la bonne heure depuis 2013 car les autorité locales on changé le changement d'heure
- Si chez toi c'était en Jordanie en tu n'as fait qu'un changement d'heure entre 2012 et 2013, puis en 2014 les changement d'heure on repris une activité normale
- Si chez toi c'était au Chili tu n'as pas changé d'heure en 2015 puis en 2016 c'est reparti en changeant la règle de changement d'heure
- Si chez toi c'est en Iran les changement d'heure se font aux equinoxe, comment calculer les équinoxes ?

Comme on peut s'en douter la plupart de ces cas impliquent un programme complexe et surtout des mise à jour régulière, quel intérêt à faire ce genre de chose au niveau de la carte mère ?
Tant qu'on y est pourquoi pas y mettre un OS ? au wait

Merci.
C'est pas hyper clair mais de ce que je comprends l'UEFI ne fait heureusement pas les calculs de changement d'heure : page 255 :

While the returned EFI_TIME structure contains TimeZone and Daylight savings time information, the actual clock does not maintain these values

OK, outre le fait que c'est un peu bête un OS qui met l'heure locale dans le BIOS.

gérer l'heure matérielle de la machine proprement de manière univoque.

C'est à dire que l'UEFI a les champs nécessaires au calcul de l'heure locale, mais rassurez moi il ne calcul pas lui même les changement d'heure (été/hiver) suivant la location ?

Du coups c'est quoi exactement les services UEFI ?

J'avoue qu'en allant voir sur wikipedia : autant "Variable service" pourquoi pas mais quand je vois que le "Time services" peut faire ça :

Time services include support for timezone and daylight saving fields, which allow the hardware real-time clock to be set to local time or UTC

Alors là je me demande : le BIOS gère donc tous les fuseaux horaires et changements d'heure !!?? mais pourquoi faire ? C'est pas plutôt à l'OS de gérer ça ? … soit j'ai mal compris : l'UEFI ne calcule pas lui même les changements d'heure mais dispose juste d'un champ "timezone" et d'un champ "DST rules" qui permet à l'OS de le faire ; soit les concepteurs d'UEFI sont des consommateurs de drogues dure durant les heures de travail.

Donc ma question est plutôt : y a vraiment que des trucs qui servent à rien dans les UEFI services ?
Par exemple l'OS va chercher comment l'heure du BIOS sans l'UEFI "Time service" ?

1/ OK pour l'entorse, ce n'étais absolument pas une critique de ma part. J'avoue que je ne pensais pas que cela fonctionnait comme ça et je croyais vraiment que la MMU était un truc imparable dans tous les cas.

Pour spectre je ne comprenais pas comment un process pouvait aller voir les pipelines d'instruction d'un autre process.
En fait j'avais le même problème de compréhension que BlueDian, grâce aux autre commentaires c'est plus clair (merci Pinarf, BlueDian et Obsidian je vais me coucher moins bête).

Spectre est particulièrement sioux et si j'ai bien compris le kernel ne peut absolument rien y faire : ça va être aux compilateurs de faire autrement pour ne pas générer de code "prédictible" … avec les perfs en moins qui vont avec (Note: le patch llvm est assez bien expliqué et compréhensible après avoir lu ce qu'est l'instruction RET).
Et je supposes que tout les langages qui font du JIT (je penses surtout à javascript et aux navigateurs, mais hotspot) vont devoir faire de même ?

Donc si je résume un max le problème :
1. pour des raisons de performance les OS font des entorses à la séparation mémoire kernel/userspace permise par la MMU pour des raisons de performance et les processeurs implémentent des "optimisations" pour faciliter cela.
2. certaine ""optimisations"" s'accompagnent de 2 types de failles de sécurité : une grossière (Meltdown concerne intel seulement) et une pernicieuse (Spectre concerne intel, ARM, AMD).
3. Ces failles se situant niveau hardware, l'OS ne peut pas les corriger "proprement".

J'avoue que en regardant les explications de comment est utilisé/partagé la mémoire kernel/userspace je ne comprends plus trop : la MMU ne joue plus le rôle de gardien du tout ?
Parce que normalement la MMU devrait empêcher complétement qu'un processus puisse aller voir la mémoire du kernel ou celle d'un autre processus.

Je croyais que le projet LLVM-Linux avait aboutit … visiblement c'est au point mort. J'ai du mélanger avec freeBSD ou autre.
Effectivement les analyseurs n'ont pas l'air de faire trop d'intelligence sur ce genre de problème : ils avertissent juste que la variable est écrasée sans avoir été utilisée.

Et du coup GCC n'a aucun flag qui permettrait de lever un warning la dessus (variable écrasé bêtement) : j'ai testé ton code avec -Wall -Wextra et -Wpedantic (ouai -Wpedantic parcequ'on sait jamais, et à défaut de -Wbrico3000), RAS pour lui.
J'aurai bien vu un flag pour ça parmis tous les flags de GCC mais visiblement non… dommage pour les étourdis comme moi.

Super, voilà 2 outils que je ne connaissais pas (scan-build et SonarQube). La prochaine fois que je ferais du c++ je testerai (j'ai plein de projets JS et Go à finir d'abord).
Mais du coup, simple curiosité + flem de le faire moi même : quand on lance un scan-build ou SonarQube sur un kernel ça donne quoi comme nombre d'alerte de ce genre : c'est monstrueux/énorme/pas-si-pire/ça-va/RAS/c'est-pas-si-simple ?

C'est vrai que c'est dommage que ce genre de chose ne soit qu'un warning mais ça doit être complexe de faire mieux comme ce n'est crypto_get_default_rng() ne sert "que" à initialiser une structure et c'est suivant la valeur retourné que l'ont sait si tous c'est bien passé… Je ne sais pas si les analyseurs sont capable de "comprendre" ça auquel cas ils pourraient dire que c'est une erreur et pas un warning.

D’ailleurs question technique pour SonarQube : le warning est levé tout simplement parce que la variable err est écrasé sans être utilisé ou bien il y a des mécanismes en plus ?

Tout d'abord merci le patch et surtout les explications. C'est bien d'avoir pris le temps de faire un fix + pris le temps d'expliquer le cheminement, le bémol c'est que maintenant si jamais ça m'arrive j'aurai plus trop d'excuses pour ne pas chercher de même.

Je me demande juste si un outils d'analyse/validation de code genre coverity* ou autre n'aurait pas pu lever une alerte sur ce genre d'erreur ?
Et il me semblait que coverity était utilisé sur le kernel, c'est donc que ce genre d'outil n'est pas capable d'avertir sur ce problème (ce qui me parait pourtant faisable) ?

*: (le genre de chose que j'ai jamais utilisé, donc je parle d'un truc que je maitrise pas : pas taper)

Je me réponds à moi même : GnomeShell4 est le projet qui a pour ojectif de résoudre ce problème (+ quelque autres qui sont détaillés sur la page).
C'est une reflection en cours et la soution propre (Option A) nécessitera de ré-écrire une grande partie de GnamoeShell et cassera toute les extensions existante (comme le passage à Firefox version 57).

Tous cela sera bien possible avec Wayland qui n'est qu'un protocole. Le fait qu'on ne puisse pas ré-utiliser les mêmes logiciels de partage/capture d'écran que ceux de X11 c'était un peu dans le cahier des charges de Waland/MIR côté sécurité.

Ma critique/remarque (Gnome-Shell pas crash-proof) se fait uniquement sur l'implémentation de Wayland qui est faite aujourd'hui dans Gnome et qui me semble être une régression par rapport à X11 sur la résistance au crash.
Wayland n'est pas responsable de ça.