wilk a écrit 1171 commentaires

Merci, ça me rassure, vu la rapidité de réponse du support je me demandais si je n'étais pas tout seul sur le bateau ;-)
Pour les logs ça me va très bien de les télécharger avec l'api bien que j'ai trouvé surprenant que les logs routeur soit irrécupérables si on les désactive visuellement…

Je suis ma propre équipe d'admin sys (j'ai des besoins très modestes mais des besoins quand même), du coup ça n'est pas une question de budget mais de temps et surtout de motivation !

Au niveau deux métiers par contre je trouve que le fait de gérer les deux oblige à se poser des questions qui oriente l'un et l'autre et ça peut être très bénéfique. Par exemple j'ai choisi Go en grande partie pour faciliter le déploiement et économiser sur les ressources. Inversement j'imagine très bien des situations ou un choix de dev a des conséquences désastreuses sur l'infra, dépendre d'un fournisseur par ex.

Mais après oui, une fois sur le terrain c'est sur qu'il vaut mieux que chacun soit à sa place.

J'avoue qu'au niveau techno chez Scalingo ils parlent la même langue que moi, Go, ce qui m'arrange plutôt, d'autant plus qu'une partie de leurs outils sont sur github. Ca m'a permis de tester très rapidement leur api.
Chez Clever Cloud j'ai vu que c'était du Rust, y compris sur des traceback du CLI… J'ai eu pas mal de difficultés à faire des essais, utiliser des modules privés en Go, utiliser l'API etc… J'ai pas trop insisté vu que l'idée était justement de ne pas avoir à me prendre la tête.
Si j'ai bien compris Scalingo s'appui d'avantage sur des technos classiques existantes et un fournisseur, sans chercher à étendre trop les fonctionnalités, tandis que Clever Cloud essaye de faire beaucoup plus de choses eux même y compris au sein du kernel (vu sur des confs de Quentin Adam), y compris avec OVH (plus trop confiance…). Plus ambitieux mais ça me semble aussi plus risqué.
Dans un premier temps ce que je vais essayer de faire c'est de rendre mes applis les plus facilement portables de l'un à l'autre (conf en env, stateless etc). Le double effet c'est que si je dois revenir sur mes serveurs je conserverai le principe.

De mon côté j'ai une cartouche en fin de garantie (2020) qui est refusée sur une HP6970, si quelqu'un veut essayer ?
J'ai eu beau expliquer à la fille du support que j'acceptais de prendre le risque de perdre la garantie, rien à faire, elle m'a suggéré l'abonnement instant Ink. Je lui ai parlé des dégâts écologiques de jeter une cartouche pleine, elle m'a proposé de m'envoyer une enveloppe de recyclage. Je lui ai demandé si elle me l'amènerait à vélo…
Le comble c'est que j'ai réussi à lui faire dire que c'était de l'obsolescence programmée !
La cartouche est programmée m'a t'elle dit. Programmée pour ne plus fonctionner après une certaine date ? Oui monsieur, la date indiquée au dos.
J'ai oublié de lui demander si mon imprimante s'arrêtera également à la fin de sa garantie, comme l'a fait la précédente…

Bon, du coup faut prendre quelle marque la prochaine fois ?

Oui mais ce n'est pas tellement le sujet.
Je passe la main à quelqu'un qui l'explique sûrement mieux que moi :
https://medium.com/capital-one-tech/closures-are-the-generics-for-go-cb32021fb5b5

Mais la question qui restera maintenant qu'on a du générique en Go c'est à quel moment préférer des fermetures ou du générique.

Dans ton exemple f et v ne sont pas capturés puisqu'ils sont passés en paramètres.
Les méthodes c'est exactement comme si on écrivait Abs(f MyFloat)

// une interface 
type Rendu interface {
    Rendu(i, j int) string
}

Oui, c'est exactement ce que je décrit, une interface qui utilise une fonction de fermeture. Ce qui est capturé c'est le tableau.
L'algo n'a pas à traiter le tableau, il va juste appeler les cellules par leur index.

Ceci à la place d'une interface, beaucoup plus classique qui serait :

type Rendu interface {
    Rendu() string
}
// mon algo
for c in range cellules {
    c.Rendu()
}

En Python je redéfinissais la méthode Rendu de ma cellule et cette méthode accédait aux cellules voisines par quelque chose comme self.parent.cellules[i-1]...

En Go je pourrai avoir une interface pour récupérer les cellules voisines

type Rendu interface {
  Rendu() string
  Voisines() []Rendu
}

Mais du coup je perdrais mon type de cellule… C'est là qu'avec des casts ou du generique ce serait faisable mais au final beaucoup plus compliqué.

Je comprend bien ce que sont les interfaces et les types génériques.
Mais le problème n'est pas tant que le code soit plus ou moins compliqué, ça dépend vraiment des cas, mais le fait qu'il crée une dépendance.
Si c'est un tri par exemple c'est bénéfique car une fois bien codé on n'y touchera plus, et surtout on n'ajoutera jamais de fonctionnalité.
En revanche si on passe à un niveau plus élevé, comme dans mon cas d'une lib qui génère un pdf, c'est bien plus délicat car il y a potentiellement des fonctionnalités qui vont s'ajouter et impacter tout le monde (problème classique des dépendances et de l'héritage).

Je ne vois pas de fermeture dans l'exemple que tu donnes par contre ?
J'en vois sur l'exemple de sort.Slice où la fonction less utilisera probablement un tableau en dehors.

people := []struct {
        Name string
        Age  int
    }{
        {"Gopher", 7},
        {"Alice", 55},
    }
sort.Slice(people, func(i, j int) bool { return people[i].Name < people[j].Name })

L'intérêt des fermetures est de faire en sorte que l'algo central ne dépende d'aucun type particulier, même pas un type générique mais de la plus petite interface possible, par exemple func(i, j int) bool. Le code dépendant du type est dans la fonction avec fermeture et propre à chaque utilisation et donc en dehors de la lib.
Dans mon cas par exemple j'ai un tableau composé de lignes composées de cellules.
Il me faut faire un pdf de tout ça.
L'algo appelle chaque cellule et lui demande son rendu, pour ça une interface Rendu marche très bien. La où ça devient casse tête c'est quand une des cellules a besoin de ses cellules voisines pour calculer son rendu, par ex cellule 2 = cellule 0 + cellule 1
En Python la méthode Rendu de la cellule un = cellule.parent.cellules[0] + cellule.parent.cellules[1]
En Go tintin car cellule.parent.cellules[x] correspondra simplement à une cellule ayant l'interface Rendu. Il faudrait éventuellement faire un cast et perdre l'intérêt du typage statique, ce que je ne voulais pas.
Avec les fermetures la méthode rendu de ma cellule est appelée avec l'index de la ligne et c'est avec cet index que je vais chercher les cellules voisines (donc un tableau en dehors de ma méthode). Je n'ai même plus besoin de cellule.parent.

Bref, avec cette méthode de fermeture mon code de lib est réduit au strict minimum en manipulant uniquement des indexes, par rapport au Python où je pouvais me permettre de manipuler directement les lignes et cellules mais avec un code de lib du coup beaucoup plus complexe. Autrement dit je préfère dans certains cas un code de lib plus simple et déplacer ce qui est complexe au niveau de l'application. Parfois c'est l'inverse (tri par ex).

Avec le générique en Go il y aura moyen de se rapprocher de ce que l'on peut faire avec du typage dynamique. Avec par exemple un tableau qui contient des lignes de type T défini au niveau de l'application. C'est sûrement ce que j'aurai fait s'il y avait eu du générique à l'époque au lieu d'essayer la méthode avec fermeture que je préfère finalement pour ce cas de figure.

Je sais pas si je suis clair, c'est vraiment difficile à décrire…

J'ai eu le cas inverse en réécrivant une lib Python perso fortement basée sur generic + héritage.
Une lib pour faire des tables de rapports pdf avec gestion des cumuls, ruptures, sauts de pages & co avec comme principe que chaque colonne peut contenir n'importe quel type d'objet. Une lib que j'utilise dans quasiment tous mes projets.
Un vrai casse tête à réécrire en Go donc, sans generic ni héritage.
Finalement je me suis basé entièrement sur des closures et composition.
Miraculeusement j'ai réussi à ce que ça tienne en moins de ligne de code mais surtout j'évite ainsi tous les effets de bords qu'on retrouve avec trop de generic et héritage et mon code est beaucoup plus facile à maintenir malgré le fait qu'il soit utilisé dans beaucoup de projets.

Aussi ma conclusion pour le moment c'est que le generic c'est bien pour des codes très réduits et dont les fonctionnalités ne doivent plus bouger mais sur des libs plus grosses, comme toute dépendance c'est très difficile à faire évoluer.

Et encore, même pour des codes réduits, en Go on a l'habitude de faire des petites boucles à tous les coins de rues, pas sûr qu'on y gagne à les remplacer par des fonctions…

J'avoue qu'il faudrait montrer du code pour voir de quoi on parle !

Il me semble que dans l'exemple slice.Sort c'est bien le système de clôture/closure, la fonction n'est pas forcément anonyme.

On peut aussi en Go avec panic/defer.
J'ai essayé pour voir, dans des cas où ça ne changeait pas grand chose mais j'en suis vite revenu.
Aujourd'hui c'est quand je me remet au Python que ça m'angoisse de ne pas annoter tout de suite une éventuelle erreur ni de la retourner explicitement !

A force je ne me souviens même plus quand j'en ai eu besoin et que ça m'avait manqué !
La plupart du temps je m'en suis sorti avec des closures, je crois qu'on appelle ça comme ça, un peu comme pour sort.Slice.
Au final de ne pas avoir de généricité je crois que ça m'a évité pas mal de codes difficiles à maintenir, que l'on regrette après coup, comme j'ai pu en avoir dans d'autres langages.
Je suis quand même impatient d'essayer !

Prochaine étape, le faire tourner sur lynx avec l'extension vim, le tout dans un screen qui se connecterait par un tunnel websocket.

Attention aux clichés concernant l'Allemagne…
https://www.ifrap.org/emploi-et-politiques-sociales/emissions-de-co2-et-industrie-la-comparaison-france-allemagne

Principalement : le CO2 à d'avantage baissé en Allemagne, cela malgré une forte industrialisation et exportation.
En France le CO2 a baissé du fait de la désindustrialisation et des importations.
L'Allemagne est dans une période de transition, la France est assise sur des acquis (qui ne vont plus durer très longtemps).

Ca n'est pas pour vanter le modèle Allemand, qui doit lui aussi évoluer, mais il faut faire attention aux comparaisons hâtives.

Comme le montre RTE, il faudra trouver un juste milieu et ça ne sera pas simple.

D'où sort la division par 5 ? dans la synthèse c'est une division par 3.
C'est une moyenne, 30% des camions roulent à vide, la moitié des trajets font moins de 5km, on jette 30% de la nourriture, 6 millions de passoires thermiques, obsolescence programmée etc…
L'effet falaise et le temps de construction c'est dans le rapport de l'AIE-RTE.
On aura plus de précisions demain sur ce qu'il est possible de faire ou pas. Mais dans tous scénario il faut surtout retenir les bonnes idées, à part les chinois personne n'appliquera une planification à 30 ans !

Tu n'es pas idiot et je comprend l'intérêt de ce que tu dis de maximiser les solutions. Ce pourrait-être l'idéal modulo le danger et les déchets (mais à la rigueur c'est un autre débat).

Mais les scénarios de type Negawatt obligent en quelque sorte à faire des économies car comme tu dis sinon ça ne marchera pas. Donc on va mettre les bouchées doubles.
Tu penses que c'est risqué mais je pense que c'est motivant (le cap) et qu'on n'a pas le choix.

En revanche les scénarios qui tablent sur une abondance d'énergie nucléaire donnent des excuses pour ne pas faire d'économies (c'est déjà ce qui se passe en France) d'une part et est risqué car on peut avoir un effet falaise à tout moment et manifestement trop tard et trop cher.

Autrement dit, ton scénario je le vois bien pour 2100 quand on aura déjà atteint une sobriété heureuse et que la recherche aura permis de résoudre les problèmes des risques, des déchets et du terrorisme :-)

Les scénarios RTE qui vont sortir demain nous donnerons également de la matière car on pourra comparer les différences de plusieurs scénarios plutôt que d'en juger un seul et spéculer sur les autres.

A demain ?

Est-ce que je me trompe ou bien négawatt ne compte pas sur une réindustrialisation ?

Attendons la présentation complète mais oui bien sûr la prise en compte de l'énergie grise et des importations est essentielle.
En tout cas c'était le cas dans le scénario précédent, notamment en favorisant l'économie circulaire, les circuits courts, l'efficience etc.

Ce sont des technologies relativement matures et maitrisées.
Je pense que sur ce point tu oublie qu'au niveau climat c'est à l'échelle mondiale qu'il faut raisonner.

Dans tes exemples de scénarios tu ne mentionnes pas les proportions ni les délais, hors c'est capital pour le climat. Le nucléaire représente moins de 5% à l'échelle mondiale et ça n'est pas près de changer avant des décennies même avec la meilleur volonté.
Installer des capacités ENR et faire des économies ça peut être fait dès maintenant, et c'est déjà en partie le cas.
Tu parles aussi de combler le trou des fossiles, mais encore faut-il creuser ce trou ! Si on ne raisonne qu'en terme de construction de nouvelles unités de production, quelles qu'elles soient on ne creuse pas de trou pour autant…
Par exemple si on réduit la consommation des voitures et que du coup on roule plus ça ne change rien.

Bref, pour moi l'essentiel reste de réduire la consommation d'énergie pour que le reste soit de moins en moins important. Changer une vieille voiture qui pollue a moins d'importance si on ne l'utilise quasiment plus (c'est même contre productif). C'était le piège du nucléaire, pas cher donc on chauffe plutôt qu'isoler.

Au contraire, plus on arrive à se passer d'énergie en direct (isolation vs chauffage) plus ça en laisse aux industriels et autres.
Plus on roule à vélo plus ça laisse de la place aux voitures restantes.
Par contre penser que tout le monde peut pomper sans regarder et qu'il en restera toujours indéfiniment commence à être de plus en plus illusoire.
De fait les coupures arrivent quand on tire trop, jamais quand on tire moins.

La question c'est plutôt est-ce imaginable d'avoir une action sur le climat sans décroissance de la consommation d'énergie ?

Ca ne me dérange pas de diminuer mes revenus si je n'ai plus à me chauffer parce que ma maison est bien isolée, plus à avoir de voiture parce que toute ma famille peut se déplacer à vélo ou en TC, plus changer mes appareils alors qu'ils pourraient être réparés, plus à verser des impôts pour subventionner des politiques de gaspillage, plus à acheter des logiciels privateurs ;-) etc.
Il ne faut pas confondre décroissance de la consommation d'énergie et récession économique.
https://bonpote.com/decroissance-et-prejuges/

Le pari du nucléaire est de toutes façons déjà perdu au vu du temps nécessaire pour construire de nouveaux réacteurs. Qui plus est au niveau du climat il faudrait le faire dans le monde entier. Hors l'AIEA n'espère pas plus que 12% de l'électricité dans le meilleur des cas.

le climat est considérablement plus dangereux que le nucléaire.
D'après l'AIEA le nucléaire pourrait atteindre au mieux 12% du mix en 2050. Il est complètement illusoire de penser que le nucléaire pourrait sauver le climat.
Le scénario Negawatt est ambitieux, mais a-t-on vraiment le choix ?

Il n'y a pas que la propagande écolo qui infuse, il y a aussi l'ASN qui rappelle les lourds travaux nécessaires (et donc arrêts) si l'on veut prolonger les centrales ainsi que le potentiel effet falaise.
RTE infuse également en expliquant que l'on peut espérer atteindre maximum 50% de nucléaire en 2050.
Donc dans tous les cas un mix sera nécessaire.

Même sans aucun mort, un accident, une tentative terroriste etc, entraînera l'arrêt net des projets de constructions, que l'on considère ça comme rationnel ou pas ne changera rien à l'effet falaise induit.

Négawatt, en mettant en hypothèse qu'il y a pas d'augmentation de la consommation

C'est pas une hypothèse c'est l'objectif principal. Réduire la consommation en se focalisant sur les services plutôt que sur la consommation. Isoler plutôt que chauffer etc.
Le reste en découle et non l'inverse.
Et comme tu dis, si on arrive à baisser la consommation on peut sortir du nucléaire et autres, en fait le choix du mode de production devient secondaire. C'est pour ça qu'a mon avis le principe de Negawatt n'est pas du quitte ou double car les économies resterons quoi que l'on trouve comme solution pour la production (qui va de toutes façon évoluer au fil des avancées technologiques, des coûts etc).

Par contre partir dès le départ sur une augmentation de la consommation (comme c'est annoncé par le gvt actuel par ex) oblige effectivement à toutes sortes de contortions sur les modes de productions. Remplacer l'autosolisme thermique par de l'autosolisme électrique plutôt que de développer le vélo par ex.

10% sans électricité provenant des éoliennes offshore. Même les centrales nucléaires ne produisent pas 100% du temps à cause des arrêts pour maintenance et autres. D'où l'intérêt d'un mix.

Ce qui est intéressant aussi par rapport à notre domaine informatique c'est l'idée de résilience entre une multitude de productions variables par rapport à une production centralisée théoriquement infaillible.

Il me semble que c'est justement l'objectif de cette étude que de montrer qu'il faut agir sur les trois leviers que tu cites.
L'avantage c'est que ça n'est pas du quitte ou double contrairement à tout baser seulement sur un changement de type de production énergétique qui plus est en augmentant la production globale comme par magie !