wilk a écrit 1096 commentaires

Oui, non seulement ils parlent d'énergie globale mais surtout de services plutôt que de consommation d'énergie. C'est ce qui est le plus intéressant à mon avis, c'est vraiment dommage de réduire les débats à éolien vs nucléaire, qui plus est en France seulement.

RTE indique également qu'atteindre 50% de nucléaire est un maximum technique (et non dicté par la loi) et loin d'être acquis. Autant on trouve 3 scénarios sans nucléaire + ADME + Negawatt etc, autant on ne trouve aucun scénario avec plus de 50% de nucléaire.
Donc le débat est loin d'être binaire.
Jacques Repussard, ancien directeur de l'IRSN n'écartait pas la probabilité d'un accident tous les 10 ans. Si on mettait tous nos oeufs dans le même panier on aurait l'air malin si on devait changer de navire au milieu du gué !
https://www.sante-environnement.be/Accident-nucleaire-une-certitude-statistique

Que ce soit pour hacker mes logiciels, mon vélo, isoler ma maison ou produire mon énergie je garde la même religion :-)

Encore une fois "garder le nucléaire" n'a pas tellement de sens si on se projette en 2050.
Sur le long terme il est beaucoup plus intéressant de parler d'isolation, d'aménagement du territoire pour éviter les déplacements motorisés, consommer local etc. Quelque chose qui peut être réellement pérenne.

Il n'y a pas de sous-entendu, on est sur Linuxfr, il me semble primordial de préférer les solutions duplicables, ouvertes et qui n'impliquent pas une dépendance !

On trouve une étude sur le foisonnement sur 20 ans de relevés de vent qui indique un foisonnement 90% du temps.
https://www.energiesdelamer.eu/images/PDF/Resultats_foisonnementvf.pdf
L'EPR a été ré-évalué à au moins 19 milliards.
Les socles ne resterons pas dans le sol non plus, c'est interdit depuis 2020.

D'où l'intérêt d'avoir des études réactualisées plutôt que des calculs sur le coin de la table.

Pourquoi devrait-on s'interdire d'avoir un système électrique sans nucléaire ?
Quand on peut fonctionner avec des logiciels libres on ne se pose plus la question de savoir si on se passe ou si on s'interdit les privateurs, on n'en a juste plus besoin.

L'allusion n'est pas anodine ici. Pourra-t-on dupliquer notre solution énergétique en toute transparence à tous les pays qui le souhaitent tout en les laissant entièrement libre d'en faire ce qu'ils veulent ? Au niveau de l'impact sur le climat c'est primordial (et encore une fois ça ne se limite pas à un seul des éléments).

Parce que rien n'est éternel (encore que les déchets sont quand même pas mal), les centrales actuelles ne seront probablement plus en état de fournir un quelconque électron en 2050. La question est donc mal posée, on va inéluctablement devoir se passer du nucléaire actuel.
La question est donc plutôt de savoir ce que l'on fait à la place puisque place se libèrera inéluctablement.
Je dit bien "fait à la place" et pas "met à la place" car c'est ce qui est le plus important dans le scénario Negawatt. C'est à dire ce qui est dans le terme Negawatt lui-même, non pas le changement de mode de production mais surtout le fait de faire des économies d'énergie et de penser services et besoins plutôt qu'apport énergétique.

des gens qui débuteront leur transition avant les autres et il faut essayer de les mettre en avant.

La sobriété heureuse est par définition beaucoup plus discrète…

On remarquera toujours moins une manif de routiers qu'une personne qui va chercher son pain à pied.

A la une : "Mr Martin est allé cherché son pain à pied", une enquête de D., grand reporter, qui l'a suivi au péril de sa vie sur un trottoir de 30cm de large encombré par des GCUMs…
Une startup vient de se lancer, son produit révolutionnaire : le calepin / crayon. Une sorte de tablette / stylet (mais qui demande un temps d'apprentissage non négligeable et n'est toujours pas compatible Orifice365 )…

Bon, je sais pas si on va pouvoir compter sur les médias :-D

Ta comparaison part d'une bonne intention mais elle est dangereuse parce qu'au départ on admet être aussi incompétent en climatologie qu'en mécanique. Ensuite on regarde comment fonctionne un alternateur et comment ça se change, c'est effectivement très simple.
Et c'est là qu'on réalise que le garagiste c'est foutu de nous quand il nous a fait payer un nouvel alternateur alors qu'il suffisait juste de retendre la courroie.

Et c'est avec ce genre de comparaison qu'on en conclu que si on est capable de comprendre le fonctionnement d'un alternateur il n'y a pas de raison qu'on ne puisse pas comprendre le climat et que les experts se foutent aussi peut-être de nous (d'ailleurs mon beau frère qui sait en plus changer les bougies a lui aussi des doutes sur le RCA…).

performances, l’exécution concurrente et le typage statique.

J'ai déjà entendu ça quelque part… Manque plus qu'un déploiement facilité par un binaire.

Est-ce qu'on est entrain d'assister à une convergence des langages ou du moins des critères d'intérêt ?

Plus de visibilité mais aussi une manière plus courante de soumettre des issues, des pull requests (en particulier des petites choses qui permettent de mettre le pied à l'étrier) etc.

Bonne nouvelle l'interface web et surtout une API !
Puisqu'il vous manque du temps, pourquoi ne pas solliciter d'avantage l'aide communautaire ? Un dépôt git[lab|hub|…] par ex. (facile à dire je sais…)

A mettre en rapport avec la notion de cloud souverain sous licences fermées :

https://linuxfr.org/users/wilk/journaux/le-cloud-souverain-francoogle

https://blog.scaleway.com/fr/doctrine-cloud-au-centre-un-pas-de-geant-pour-la-modernisation-numerique-de-letat-et-des-interrogations/

Le problème restant que 5 ans plus tard le retard aura été d'autant plus creusé que l'on aura subventionné ceux qui creusent !

Le problème de la sobriété c'est surtout le fait que le terme soit péjoratif.
Il y a un livre "âge de pierre, âge d'abondance" qui montre que « Si l'homme primitif ne rentabilise pas son activité, c'est non pas parce qu'il ne sait pas le faire, mais parce qu'il n'en a pas envie. ».
Par exemple à cette époque de nomades à pied le fait de posséder quelque chose est tout de suite une contrainte car il faut le transporter. J'aime bien retrouver cette valeur des choses en randonnée.
En informatique j'aime bien aussi quand j'élimine du code, une dépendance, une couche intermédiaire…
La sobriété pourrait vraiment être vue comme un atout plutôt qu'une contrainte.

Clairement le problème avec ces technos c'est de debuger le client "ça marche pas" alors que sur notre poste ça marche très bien.

La vidéo de la conférence :

https://twitter.com/i/broadcasts/1ynJOBwXEMlGR

C'est du PostgreSQL ou MySQL. On peut faire exactement la même chose chez soit ou chez OVH mais c'est un sacré boulot et on se rend compte que ce que l'on paye ça n'est pas seulement la probabilité que ça prenne feu ou pas mais le service fourni tout autour au cas où ça prendrait feu à un endroit.

Je ne comprends trop l'intérêt de calculer en terme de datacenter. Autant qu'un datacenter parte en fumé c'est assez rare, autant qu'une machine ou encore mieux qu'une vm parte en fumée ça arrive tous les jours. Et pour l'utilisateur c'est ce qui compte, peu importe que les serveurs d'à côté partent en fumée aussi, il en suffit d'un et que ce soit le notre…
L'article met bien l'accent sur le fait de gérer plus ou moins soit-même la redondance.
Il me semble que c'est à ce niveau qu'il faut faire des comparaisons et quitter ou non OVH. C'est à dire dans les services disponibles sur l'infrastructure proposée pour pouvoir gérer cette redondance.
Hors c'est bien à ce niveau que le leader distance complètement les suivants, ça me semble même sans commune mesure.
Eventuellement on peut palier à ça avec des compétences internes, mais on ne compare plus du tout la même chose et encore moins le coût final.
En tout cas bravo à Cozy pour avoir réussi cet exploit, et on peut préciser "en particulier chez OVH" ! Chez l'autre il n'y aurait eu aucun mérite !

edit: pour ceux qui voudraient se rendre compte, regardez les possibilités d'une BDD Aurora par ex, et imaginez faire la même chose chez OVH (ou autres)…

Je ne peux pas l'expliquer pour le moment, je l'ai trouvé par tâtonnement (je me suis fait un défi de passer de websocket à sse dans la journée en prod !)… Ce qui a été délicat c'est qu'en local je testais en accès direct à mon application, et en prod par Nginx. Je n'ai pas encore testé si ça passe par un load balancer type ELB…

Maintenir un version web et une version desktop risque d'être assez lourd non ? Est-ce que l'objectif à terme est de n'en conserver qu'une ?

Ton article m'a donné envie d'essayer les SSE pour remplacer un système de websocket que je n'utilisais que dans un sens (serveur vers client et classique dans l'autre sens).

Il y a quelques années pour apprendre le langage Go j'avais réécris un système de websocket en Python (pour un jeu de scrabble) qui fonctionnait mais il m'était impossible de faire évoluer ce code spaghetti. Le résultat était déjà plutôt concluant, mais plat de pâte tout de même.
Du coup je viens de le réécrire avec SSE.
Première chose plus besoin de dépendre d'une lib externe (gorilla.websocket) et pas mal de code de tuyauterie à supprimer autant côté serveur que client.
Ensuite le côté sens unique de SSE correspond exactement au fonctionnement des channels en Go. Ce qui fait que mon dispatcher fonctionne aussi bien avec des clients distants (un client SSE = un channel) ou des goroutines (par exemple un robot joueur).
En Python j'avais séparé mon appli en plusieurs services (les robots à part) qui communiquaient par websocket, et la du coup je les ais réintégrés dans la même application et ils communiquent par channel sans changer grand chose au code, ça me laisse le choix.
Bref, les SSE sont un excellent moyen de familiariser aux concepts de channel en Go.

A part ça, j'ai eu quelques surprises niveau Nginx.
Dans un premier temps je me suis dit, avec http ça va aller tout seul. Effectivement ça semble fonctionner tout seul.
Mais en regardant les logs je me suis aperçu que la connexion était coupée toutes les minutes.
J'ai rajouté ça :

proxy_buffering off;
proxy_cache off;
proxy_set_header Connection '';
proxy_http_version 1.1;
chunked_transfer_encoding off;

Tout allait bien jusqu'à ce que des joueurs se plaignent que ça rame, ce que n'avais pas constaté dans mes essais. Après enquête je comprends que c'est quand on ouvre plusieurs onglets. J'essaye d'ouvrir une dizaine d'onglets, l'ordinateur se met à souffler comme un malade et les derniers onglets tournent sans rien afficher. Systématiquement à partir du sixième ! J'essaye un autre navigateur, pareil, 6 onglets max.
C'est finalement une limitation http, je trouve enfin qu'il faut passer en http2

server {
listen 443 ssl http2;

Tout semble rentrer dans l'ordre.

Bilan, les SSE en Go c'est un régal, je garde.

Ce qu'il faudrait expliciter vraiment (si j'ai bien compris), c'est que une fois le socket "ouvert", le serveur peut être à l'initiative d'un message vers le client, ce qui est normalement réservé au client. En fait, on peut faire un vrai "push" ici : pour recevoir des données du serveurs, on ne contente pas d'attendre le retour de requêtes envoyées au serveur. Le serveur peut de lui même initier des requêtes vers le client. Je suppose que cela sous-entend une prise en charge particulière dans les proxies et NAT.

Je pense que tu as bien compris le but de la manœuvre. Je fais un petit retour d'xp dans un autre fil, ça répondra peut-être à tes questions.

A propos du code, un truc qui m'a perturbé quand j'ai regardé (y a longtemps), c'est les noms des tables et champs PostgreSQL en majuscule, ça oblige à les mettre entre guillemet ce qui n'est pas toujours pratique… D'où vient cette idée ?