Dinosaure a écrit 89 commentaires

RPi4 est en effet un peu "overkill". En vérité, ce dernier est plus un "proof of concept" de l'extensibilité de MirageOS sur d'autres architecture physique (comme ESP32, RISC-V, etc.). Le travail nécessaire pour étendre MirageOS à une autre "target" (et pouvoir ré-utiliser les libraires OCaml plus haut niveau comme HTTP ou DNS) est certes compliqué mais minimal! Pour revenir à RPi4, il nous a fallut que 4 jours pour ajouter la "target" à MirageOS et 3 semaines pour programmer notre guirlande.

Les questions derrière ce travail concerne notamment la problématique de la cross-compilation notamment si une librairie tierce embarque du code C. Bref, tout ces aspects devraient être résolu et si on articule bien la séparation entre le micro-micro-kernel et le domaine applicatif, on devrait pouvoir réutiliser le même code pour Raspberry Pi Zero.

Pour ce qui est de Dream, nous avons proposé cet été DreamOS et nous continuons à essayer de supporter Dream. Le développement de ce dernier est plus ou moins actif mais il devient de plus en plus nécessaire pour nous puisque nous essayons de créer un serveur Matrix avec MirageOS + Dream. Bref, de ce côté là aussi ça bouge :) !

Déjà je voudrais remercier les contributeurs qui ont continué d'écrire cette dépêche sans moi et c'est super cool! Merci à eux!

Ensuite, j'aimerais juste continuer un petit peu cette dépêche en parlant de la prochaine release de MirageOS 4. En effet, si je n'ai pas pu prendre le temps de bien écrire cette dépêche dans le détail, c'est entre autre parce que nous étions occupé à préparer cette grosse release qui n'est toujours pas fini.

Cependant, elle risque d'arrivé bientôt puisque nous avons presque enfin toutes les pièces réunis pour continuer notre support avec libseccomp, KVM (gcloud) et Xen. La nouvelle release nous permet d'étendre assez facilement nos cibles et nous avons commencer à proposer un MirageOS pour Raspberry Pi 4 (en bare-metal) - cela reste un proof-of-concept mais il permet de montrer que tout fonctionne correctement. Vous pouvez voir le projet ici: https://github.com/dinosaure/gilbraltar (et j'espère qu'il sera bientôt intégré à MirageOS).

Ensuite, il est mention dans cette dépêche de tout un tas de librairies pour MirageOS. Encore une fois, ces librairies peuvent être utilisés en dehors de MirageOS - et c'est le cas. En parallèle de la release de MirageOS 4, nous avons continué à maintenir ces librairies pour les utilisateurs. À cela, on peut noter plusieurs avancés:
- ocaml-dns va bientôt intégrer le support de DNSSEC (la PR)
- mirage-crypto utilises une version vérifié (à l'aide de Coq) de certains algorithmes de cryptographies (l'article)
- nous avons développé tout une "stack" pour les emails (envoie, réception et vérification) et nous avons désormais un relais SMTP (avec signature DKIM et vérification SPF/DMARC) (le projet)
- irmin continue d'évoluer avec la crypto-monnaie Tezos (irmin)
- un remplacement de la stack HTTP vient de s'opéré étant plus performant (plus de détail ici: le project)
- enfin, nous nous préparons pour une migration vers OCaml multicore
- et nous avons développé un OS qui permet de programmer une Guirlande en OCaml pour notre sapin :) (la photo et la vidéo)

Bref, il y a là un énorme travail de fond pour une petite équipe (~10 personnes). Mais il est certains que si vous voulez jouer avec, nous aurions un plaisir de vous aider!

Pis c'est connu, Github est une blockchain.

Techniquement parlant, on retrouve le principe de "blockchain" dans Git ceci dit (bien entendu, sans le principe de Proof of *, puisque c'est les développeurs qui font autorité).

Je pense que c'est ce qui m'a le plus choqué dans l'article qui est cette dissociation entre une consommation du « virtuel » et le coût réel dans la mise en place de cette virtualité. Le bitcoin est autant assujetti à la consommation en énergie de l'extraction de métaux précieux que l'or stocké dans nos banques (tout comme les panneaux solaires ou les éoliennes qui - même si ils assurent une production en électricité sans émission de CO2 - ont besoin d'une énergie pour leurs constructions - c'est d'ailleurs une question centrale aujourd'hui, on parle alors de TRE).

Bien entendu, on peut considérer à juste titre que ces coûts (qui concerne la fabrication de ces unités de calcul mais aussi l'énergie en place pour la mise en place du réseau informatique) n'ont pas eu comme seul objectif le Bitcoin - d'où la difficulté de calculer ces coûts justement qui ne s'appliquent pas exclusivement au Bitcoin.

Cependant, l'impact est là et l'acquis ainsi que sa maintenance ont un coût qu'on a encore du mal à quantifier par rapport au système terre qui, comme il a été dit est, entre autre, un système inertiel.

On rajoutera à cela des limites physiques du coût en énergie au traitement de l'information qui fait que l'on peut désormais se poser la question d'un « TRE » possible à nos applications informatiques. Tout cela pour dire que considérer la question écologique sur le secteur de l'informatique en général est une question très difficile à laquelle on est bien obligé de considérer un impact néfaste bien plus large que ce que l'on peut s'imaginer (et qui va au delà de la simple consommation de notre ordinateur).

Malheureusement, ce sont des points qu'on omet toujours - qui pourtant, dans les considérations des énergies vertes justement font parties du bilan comptable - mais qu'il faudra un moment vraiment s'en rendre compte.

Ntoch a fait plusieurs sessions de stream de code pour certains de ces jeux mais au delà de cette ambition égocentrique de vouloir prouver qu'il peut faire un jeu en quelques jours, on peut utiliser ce support pour faire des sessions explicatives sur des concepts particuliers - c'est comme poser la question de pourquoi des gens font des tutos vidéos pour apprendre à programmer.

Si c'est bien utilisé, cela peut être une porte d'entrer aux novices.

De mon cote, c'est la même galère. Par une convergence de faits inappropriés, j'ai fait un renouvellement de carte de BP depuis l’étranger sans pour autant que la BP ne soit au courant que je suis a l’étranger - j'utilise préférablement mon compte Barclays.

En somme, la seule chose que je peux faire en l’état, c'est retirer de l'argent auprès d'un ATM. Je ne peux pas payer tout simplement - tout mes paiements sont DECLINED.

J'en renseigne le Service Client après avoir appeler ma conseillère financière qui m'explique qu'elle ne peut rien y faire. J'ai donc entame depuis 2 semaines maintenant une communication déconstruite voir même insensé parfois (me mentionnant qu'hier, j’étais au Cambodge pour me signaler le lendemain que je suis désormais au Canada) qui ne résout toujours pas ma situation.

Mon expérience avec la BP a toujours été privilégié puisque je suis issu d'une famille de postier. Mais même en connaissant les tréfonds de cette banque, en ayant des contacts qui ont plus ou moins une marge de manœuvre, j'ai toujours été face a l’absurdité de l'administration de la BP ou de d'autres services La Poste dans d'autres secteurs - et en soit, il n'est pas normal a ce que la BP résolve mon problème parce que je connais des gens.

En cela, j'ai toujours considéré la BP comme ma banque en dernier recours et aujourd'hui, j'en fait les frais.

Il y a cette technique sinon mais cela me semble très proche des références dans Git - avec la notion de mutabilité inhérente.

Mais dans ce genre de contexte, on préféra utiliser des outils (externes ou internes au langage) pour assurer le maximum de chose (et c'est ce qui ce fait dans l’aéronautique).

Je sais parfaitement ce qu'est l'hégémonie du capital et au delà de m'intéresser à la politique, je m'intéresse notamment à la littérature à propos de ces questions. Ceci permet entre autres de préciser les idées et d'utiliser les bons mots selon le paradigmes et l'échelle.

Il est très facile (trop ?) de généraliser un propos et de s'attaquer directement à la source de ce qui nous semble être le problème en y énonçant notre radicalité. Face à des gens qui auraient déjà cette sensibilité au structuralisme du capital, présenter un lexique comme rapport de force, aliénation, force de travail, etc. n'est d'une utilité dialectique quasi-nul puisque tout ces mots font référence au courant de pensé anti-capitaliste.

Oui, aliénation, c'est complètement marxiste …

Maintenant, on est pas dans un meeting du PCF ou du NPA ici. Il y a des gens qui ont d'autres idées et d'autres paradigmes. Alors, j'aurais très bien pu laisser un commentaire comme: "c'est le capital, les méchants bourgeois, ils nous asservissent tous" mais ça aurait été inaudible pour pas mal de gens puisque ce serait juste une réaction primaire inintelligible pour peu qu'on n'est pas connaissance des outils qui permettent de critiquer le capitalisme.

Dans le cas présent, dans le paradigme de la critique du capitalisme, il est bien question d'aliénation entre le client et ces entreprises. Et ce de cette aliénation ainsi que de d'autres paramètres qui caractérisent le capital, on peut en convenir à un asservissement face à l'implacable hégémonie du capital.

Donc ouais, puisque je suis de cette sensibilité, ouais tu as raisons. Mais arnaudus à tout aussi raison de critiquer l'utilisation du mot asservissement si on est pas adepte de la doctrine marxiste et c'est là où il y a d'autres mots qui existent et qui peuvent expliquer plus précisément la situation. Donc avant que le grand soir arrive, il faudrait surtout que les gens nous (te ?) comprennent.

Je pense que le terme qui conviendrait serait aliénation au lieu d'asservissement. Je dis ça, je dis rien.

Hmmhmm, pour le coup non. Mais la transformation d'une fonction récursive en une fonction tail-récurvise à l'aide du style CPS est quelque chose de très commun en OCaml (et dans les langages fonctionnels en général - pour peu que ces derniers optimisent les fonctions tail-rec).

Après, il est vrai que ce n'est pas spontané mais avec un peu de logique et de pratique, on y arrive sans trop de mal.

Juste concernant Go, il me semble que l'approche (en tout cas des critiques que j'ai pu lire ici et là) n'est pas type-safe dans le sens où interface{} serait en réalité le type top comme la classe Object en Java - ce qui permet de facilement bypasser le système de type de Go.

Alors, j'ai pas trop cherché à appliquer ça chez moi (si c'est encore d'actualité d'ailleurs) cependant, c'est plutôt une approche qu'on devrait éliminer quand on souhaite faire du bon code - cela revient au void * en C.

J'ai essayé avec ce petit script OCaml qui utilise Jsonm (qui n'est qu'un lexer) et le parser utilise le style CPS pour être sûr que les fonctions soient tail-rec. Bien entendu, il y a la présence d'un accumulateur qui grossit en fonction du nombre d'éléments.

Bref, comme la version en C, le test passe les 1 000 000. Le style CPS permet de ne pas faire exploser la stack. Niveau performance par contre, je ne sais pas.

Pour compiler, je conseille d'avoir opam. J'utilise actuellement la version 4.03.0 du compilation OCaml. Ensuite, il faut installer Jsonm, Fmt et ocamlbuild:

$ opam install jsonm fmt ocamlbuild

Pour compiler et tester avec ceci:

$ ls
main.ml
$ ocamlbuild -use-ocamlfind -package jsonm -package fmt main.native
$ ./main.native < test

Pour revenir sur le sujet du journal, c'est quand même du foutage de gueule d'une personne n'aimant pas le libre (un peu comme les pseudo-libristes disant que le libre c'est génial puis font du CC-NC car il faut se battre contre les méchants commerciaux, j'en rigole chaque semaine de ça je crois) qui veut faire croire à zéro contraintes quand elle en met des tonnes de contraintes.

C'est fondamentalement la différence entre liberté individuelle et liberté collective (note bien que dans les deux termes, il est question de liberté). On peut considérer que le choix émanent de ta liberté individuelle (de ton "libre arbitre") puisse rentrer en conflit avec l'objectif d'un idéal ou d'un dessein politique qui, lui, se concrétise au travers de la soumission à un corps social régit par des règles (la notion d'obligation de réciprocité) pour assurer cette liberté collective.

Les deux solutions ne sont pas parfaites, les critiques de la liberté collective uniquement possible à la soumission à un corps social nous rapproche plus d'un totalitarisme que d'un idéal libertaire - et l'histoire peut tout aussi nous le montrer.

Mais la critique de la liberté individuelle l'est tout aussi rien que dans la critique de ce qu'on peut admettre du libre arbitre - suis-je vraiment libre de faire ce choix ou est ce le résultat d'un ensemble déterministe de causes ? Ainsi, laisser à chacun la liberté de faire ce qu'il veut (la notion de licence permissive) ne nous soumet pas, par un rapport de force, à un autoritarisme violent ?

Je ne dis pas que GPL > BSD/MIT ou que GPL < BSD/MIT mais force est de constater que les deux défendent un idéal selon des moyens différents et qui utilise la GPL n'est pas plus ou moins libriste que ceux qui utilise la licence BSD ou MIT.

Après que, toi, tu considères que la réelle notion de liberté ne se trouve que dans ta liberté individuelle et que celle-ci ne serait soumis à aucunes causes de ton environnement et serait donc intrinsèque à toi même, bon déjà c'est un peu naïf et radical comme vision des choses mais c'est surtout ne pas admettre la nuance et être finalement très autoritaire (<> libéral) sur la notion de liberté !

J'avoue que pour le coup, j'ai du mal à cerner cette communauté qui ne veut pas d'OCaml-multicore ou même des outils disponibles aujourd'hui comme Lwt ou Async.

Après, je peux tout de même essayer de faire une proposition de réponse sur ce qu'est OCaml pour pas mal de gens encore. C'est un langage à PoC ni plus ni moins qui permet de faire l'état de l'art à des concepts qu'on ne retrouve que sur papier. En cela, l'ambition de pas mal de gens qui utilise (utilisait) OCaml n'était que de parvenir à un résultat qui les satisfasse et pas forcément en phase avec ce qu'une communauté attendrait d'eux.

En cela, l'intérêt de s'occuper du multi-threading dans les programmes Caml serait une tâche au mieux nécessaire si la mise à l'échelle ne fonctionne pas - et comme le souligne kantien, OCaml a de très bonne performances, donc cette question ce pose rarement - ou au pire trop coûteux en temps et développement pour s'y atteler.

Mais à l'opposé de cela, une communauté (plus industrielle) souhaite créer et utiliser des outils et les questions sur le multi-threading interviennent donc (notamment puisque le problème de la mise à l'échelle, dans un contexte industrielle, ce pose de facto). Mais pour cela, il faut un peu se désaliéner du milieu de la recherche et plutôt côtoyer les acteurs industriels de la communauté OCaml - qui n'ont qu'un avis trancher entre Lwt/Async mais pas sur la question du multi-threading vu la proportion de projets utilisant ces librairies.

Après, de mon point de vu, je trouve ça plutôt cool qu'il est des gens (qui sont en général pas si bêtes) pour s'offusquer du multicore car ça laisse toujours des questions et réponses intéressantes sur l'intérêt du multicore qui, à mon sens, n'est pas systématique. En cela, la problématique est prise avec des pincettes pour satisfaire le plus grand nombre sans partir tête baissé sur une implémentation duquel un bon nombre de la communauté n'y serait pas regardant.

Les extrêmes ne sont jamais bon et dieu sait qu'il y en a dans la communauté OCaml - et c'est toujours drôles de lire les mailing lists - mais si on arrive à cristalliser ces clivages et à en produire quelque chose qui satisfait tout le monde, ça peut prendre du temps et beaucoup de patience, mais le résultat n'en sera que meilleur.

Cf. git rerere :)

Il me semble que le principal inconvénient, à l'époque, d'OCaml comme choix a été le support sur Windows.

Aujourd'hui, un effort constant par OCamllabs (en la personne de David Allsopp) essaye d'intégrer OCaml sur Windows. Cependant, cet effort a été entrepris après le choix de l'équipe de Pijul.

Je suis le premier à être déçu de ce choix (que je comprends ceci dit) puisque Pijul aurait pu être un projet intéressant pour des problématiques courantes à l'éco-système d'OCaml et a des projets sur lesquelles je travaille. Mais bon, si j'ai le temps je pourrais m'y pencher et faire revivre l'implémentation en OCaml :D !

Cela va au delà de la différence entre PoS et PoW malheureusement.

On peut réellement se poser des questions de l'impact écologique de l'utilisation de cette monnaie en surface mais du prérequis nécessaire aussi à l'utilisation de cette monnaie ensuite. Et je vois dans les commentaires que l'extraction de l'or ou la production de billet n'est tout autant pas écologique (et ils ont raisons) mais la virtualité du bitcoin (ou autre monnaie comme ethereum) n'est accessible qu'avec la conception d'unité de calcul - ces dernières requérant aussi de l'or (certes, en très petite quantité) et dont le recyclage pose un grave problème.

On peut rajouter la consommation en électricité nécessaire et à l'infrastructure globale du réseau internet mondial pour véritablement se poser une question du prix en énergie pour tout cela - et, empiriquement, on peut facilement dire que écologiquement, toute cette technologie pose véritablement un problème.

Une crypto-monnaie PoS demande aussi une simulation des votes pour valider un consensus. Cette simulation, d'un point de vu technique pose tout autant problème en ayant eu connaissance des limitations qu'avait Tezos sur la non-implémentation d'un processus de Git en OCaml (qui fait littéralement exploser les inodes sur ton système de fichier) - je pourrais entrer dans le détail mais flemme.

Tout ceci pour dire que si on se pose la question écologique, j'ai l'intime conviction qu'en l'état, toutes ces crypto-monnaies posent plus un problème qu'elles n'en résolvent.

L'article n'est peut être pas drôle mais vos commentaires le sont :) !

Enedis va augmenter son bénéfice (ou diminuer son déficit ?) et je maintiens que nous n'en verrons pas les répercussions.

Argument souvent donné "contre le capitalisme", tout aussi usé. Comme les "5 minutes", c'est rien jusqu'à ce qu'au final ça change quand même quelque chose pour tout le monde.

Moi, à la place d'Enedis, je garderais l'oseille quand même.

Après ta mécanique de pensé dans ta dernière phrase paraphrase assez bien celle d'Adam Smith sur le capitalisme:

Tout en ne cherchant que son intérêt personnel, [chacun] travaille souvent d'une manière bien plus efficace pour l'intérêt de la société, que s'il avait réellement pour but d'y travailler… Je n'ai jamais vu que ceux qui aspiraient, dans leurs entreprises de commerce, à travailler pour le bien général, aient fait beaucoup de bonnes choses.

Mais c'est omettre l'intérêt personnel, moteur premier du capitalisme. Et il sera bien d'un intérêt personnel à Enedis de garder l'oseille :) !

Et toi tu proposes quoi comme banque éthique (et crédible comme suggestion pour le bon peuple hein, si la suggestion c'est une association coopérative locale qui propose, au lieu d'une CB, de payer en monnaie altermondialiste valable uniquement dans les 5km autour de son unique "agence" (un squat), merci mais non merci) ?

L'idée même de pouvoir reconnaître ces faits et de s'en insurger montre une défiance (justifié ou non) des actes de ce genre de banque. Et c'est seulement au travers de cette défiance que l'on peut espérer que les banques puissent considérer l'éthique comme un argument de vente - et c'est d'ailleurs le cas pour quelques unes.

Il n'a jamais été question de créer une société économiquement parallèle afin d'avoir une conscience tranquille et une bien-pensance. Il s'agit surtout de porter une critique afin d'avoir les outils nécessaires pour s'insurger face à ces actes. Après, il peut y avoir de l'extrapolation d'un côté, du négationisme de l'autre mais avoir une attitude comme quoi "de toute façon, ça ne changera pas, tout le monde fait ça" ou plutôt être dans une attitude fatidique n'a jamais aidé personne.

L'immobilisme et l'inertie sur ce qui ne va pas de soi amène à un conservatisme et à une servitude volontaire qui révèle surtout une indifférence face à des situations au mieux grotesques, au pire inhumaines.

En cela, et quand bien même je ne sois pas forcément d'accord avec le propos (considérant que le boycott individuel dans une société capitalisme est plus un aveu de faiblesse qu'une lutte), je trouverais toujours plus intéressant des gens qui délivrent une opinion marqué plutôt qu'une attitude apathique, ces derniers ayant perdu d'avance la possession de leurs futurs.

Une bonne occasion de me mettre au Coq (même si je continue à dire qu'il n'y a que les fous pour utiliser ce langage :p ).

Python permet la surcharge de l’opérateur + (la fonction correspondante s’appelle add) et son message est on ne peut plus clair.

Oui enfin Python n'a pas un algorithme d'unification derrière … Il faut comparer ce qui est comparable aussi (c'est pour ça que je compare pas cette problématique spécifique avec OCaml). Ce domaine demande encore pas mal de travail comme le prouve ce papier de recherche du OCaml Workshop 2014 notamment (si on prends la problématique dans sa globalité). Donc cette condescendance que Python y arrive mieux que Rust, non merci.

Rust est un langage typé au même titre que Haskell et OCaml. Il faut bien comprendre que les erreurs de types sont difficile à rendre compréhensible. La surcharge possible de l'opérateur ( + ) en Rust complexifie la tâche et pour le coup, même si Haskell serait pour le coup un bonne exemple à suivre pour Rust, en général, c'est avec l'expérience qu'on comprends de manière évidente ces erreurs et on peut difficilement faire mieux.

Tout ceux qui ont essayer de jouer avec les GADTs en OCaml savent de quoi je parle ('a#0 qui n'arrive pas à s'unifier avec 'a#1) et que cette critique (pertinente) est à re-contextualiser par rapport à ce qu'on est capable de faire aujourd'hui et que la problématique reste encore difficile.

Mais on peut aisément imaginer qu'avec l'engouement de reste, on est plus d'investissement humain pour résoudre ce problème.

En vérité, les banques sont peut être le pire exemple dans le domaine de la sécurité qu'on peut prendre.

Il faut être pragmatique sur un point, ce n'est pas rentable pour les banques d'investir dans la recherche et le développement pour sécuriser leurs infrastructures. La réalité est qu'il est plus rentable de fixer un problème de sécurité à chaud pour la banque que d'avoir des permanents qui travaillent sur ce sujet (après on peut discuter de la moralité de cette décision).

Pour ce qui est de la sécurité, il faut plutôt ce tourner vers des systèmes militaires et aéronautiques ou encore la recherche, les considérations y sont plus fortes (rien que le facteur vie humaine est à prendre en compte).

Mon commentaire n'était pas vraiment une critique mais une extension de ma pensé quand je t'ai lu :) .