Pas sûr du tout, le fait de conserver du nucléaire aurait aussi pu ralentir la montée des renouvelables comme chez nous et probablement qu'ils en seraient également au même stade que nous englué dans un débat qui finalement bloque l'un comme l'autre.
Et comment je fais si aucun logiciel libre ne répond actuellement à mes besoins la tout de suite à l'instant ?
Quelle est la part des logiciels libres dans notre parc informatique aujourd'hui ?
On est un lobby aussi ici, attention de ne pas jeter la pierre en l'air on pourrait se retrouver dessous aussi. Nous ne sommes pas forcément une source d'information mais ça n'empêche pas de l'être parfois.
On the other hand, multiple people told me things like “this is the first system I've seen that I'd actually opt in to, but I'd still turn it off if it was on by default.”
Ne jetez pas la pierre sur le "militant sectaire", n'oublions jamais qu'on a tous été considérés comme tel ici il n'y a pas si longtemps.
On peut tout à faire dégager ce lien s'il est hors sujet ou y répondre avec arguments sans faire de procès d'intention.
Pour éviter l'utilisation de inutile pour pas d'accord est-ce qu'on a étudié l'idée d'avoir les deux ? Ainsi on pourrait indiquer pas d'accord mais pertinent ou d'accord et inutile…
Non, au contraire, c'est comme ça que fonctionne Aurora (AWS). Quelque soit l'architecture utilisée il y a toujours une gestion de cache d'ailleurs.
Plus la charge va être forte plus le cache va jouer à priori. Inversement c'est surtout pour les petites charges qu'il y a du démarrage à froid (Aurora v2 ne scale plus à zéro comme la v1 du coup).
A suivre…
Il y a une couche intermédiaire qui sert de cache. J'imagine que le problème va se poser sur des grosses bases où d'un coup on va vouloir tirer des infos "froides"…
Pour l'instant en beta test on a droit qu'à des toutes petites bases.
Y a les deux côtés, le côté interne c'est ça, l'instance POstgresql est découplée du stockage voir inexistante, c'est le vrai serverless si on considère que le stockage ça n'est pas du serveur.
Et le côté service, là c'est serverless pour le client mais pas pour le fournisseur où là pour le coup c'est du servermore vu qu'il va avoir un serveur pour le stockage, un pour la couche intermédiaire, un pour le moteur, un pour l'api etc !
ps: pour l'instant je ne crois pas qu'il y ait de read-replicas, donc une seule instance ou zéro, mais c'est prévu ainsi que le scaling vertical automatique (pour ne pas avoir à choisir le type d'instance).
Vu que le stockage est à part la base et les branches existent même si aucun moteur n'est lancé.
Since storage is separate, compute, which is a Postgres process, becomes stateless (barring the buffer cache). This allows dynamically rescheduling compute and moving it from one node to another.
Lancement prochain du mode autopilot. Plus besoin de tweeter soit-même. Grace à une IA, nommée KePenserDe, on pourra tweeter sans même avoir besoin d'être réveillé. Enfin des débats "sains" et non plus souillés par notre propre pensée archaïque soumise aux aléas biologiques d'un autre temps.
Bien vu, apparemment c'est un problème qui n'est pas résolu et qui concerne pas mal d'autres frameworks, y a une recherche de consensus au niveau w3 pour permettre que des attributs persos soient valides mais c'est pas encore le cas. Théoriquement il faudrait utiliser quelque chose qui commence par data-. Je ne sais pas si c'est possible de le configurer…
Désolé j'ai raté l'option, c'est une migration d'une boite française mais c'est pas en français…
A part ça je peux aussi témoigner sur l'intérêt de cette petite lib qui permet d'ajouter un peu de réactivité aux pages sans renier la logique du rendu serveur… Que du bonheur.
Dernier truc rigolo en date, en récupération de billet (acheté sur TER et transféré sur l'appli) il n'en récupère qu'un sur 4 et me l'affiche avec 2h en moins ! Ca sent le problème de timezone… J'imprime…
C'est que maintenant les gens sont tellement habitués à voir des applis pleins de bugs que soit mon appli en à aussi et c'est normal c'est comme ça, comme les grands, soit elle n'en n'a pas (et en plus elle est rapide) et je passe pour un génie !
edit:
Et maintenant je pourrai dire à mes clients, attention si vous ne testez pas la beta ça va finir comme à la SNCF.
J'ai trouvé le graal du serverless sans la contrainte de réécrire les apps ! Ca s'appelle Knative, ça scale de zéro… Je dis knative pour ne pas citer Scaleway et CloudRun qui le proposent « as a service ». Le principe est simple, l'application doit écouter sur le port 8080 comme n'importe quel serveur http.
Longtemps j'étais réticent à quitter l'infra à la papa où rien n'a changé ou presque sous le capot depuis 30 ans et qui permet de comprendre ce qui se passe et agir à tous les niveaux. Mais là j'avoue, c'est bluffant. Git push et voilà.
L'avantage du Go dans ce cas il est simple, un Dockerfile avec un distroless on ne plus simple et le démarrage à froid se fait dans la seconde, une empreinte mémoire ridicule, un cpu qui reste au raz des pâquerettes. Tout ce qu'il faut pour faire un serveur http est dans la lib standard, même les templates html, même l'embarquement des assets dans le binaire !
Autre avantage de Go c'est de pouvoir jongler soit avec des goroutines+channel en interne soit reproduire exactement la même chose en microservices séparés (les channels sont à sens unique). Il m'est arrivé plusieurs fois de passer de l'une à l'autre méthode en changeant quelques lignes de code simplement.
Niveau de la simplicité du langage personnellement ça me rappelle le C de ma jeunesse, que de bons souvenirs !
Bref, à part la partie cachée du serverless, je retrouve le côté simple d'unix un binaire qui vet voilà.
Tellement rapide. Je modifie un fichier, j'enregistre, le code est formaté, les imports ajustés, les erreurs de types détectées, le temps d'aller sur le bureau d'à côté et de recharger ma page le bouzin est déjà recompilé. C'est plus rapide que quand de relancer un serveur python !
[^] # Re: Et le prix du soutien aux énergies fossiles est décerné à...
Posté par wilk . En réponse au lien Part de la consommation d'électricité couverte par l'énergie éolienne en Europe en 2022 . Évalué à 3.
Pas sûr du tout, le fait de conserver du nucléaire aurait aussi pu ralentir la montée des renouvelables comme chez nous et probablement qu'ils en seraient également au même stade que nous englué dans un débat qui finalement bloque l'un comme l'autre.
[^] # Re: Constat
Posté par wilk . En réponse au lien Part de la consommation d'électricité couverte par l'énergie éolienne en Europe en 2022 . Évalué à 3.
Et comment je fais si aucun logiciel libre ne répond actuellement à mes besoins la tout de suite à l'instant ?
Quelle est la part des logiciels libres dans notre parc informatique aujourd'hui ?
A replacer quelques années en arrière !
[^] # Re: Attendu
Posté par wilk . En réponse au lien Nucléaire: démantèlement de l’IRSN au profit de l’ASN, du CEA et du ministère de la Défense. Évalué à 5.
On est un lobby aussi ici, attention de ne pas jeter la pierre en l'air on pourrait se retrouver dessous aussi. Nous ne sommes pas forcément une source d'information mais ça n'empêche pas de l'être parfois.
[^] # Re: Alternative pour les mails pro
Posté par wilk . En réponse au lien Gandi casse son offre mail ?. Évalué à 2.
Tu peux en dire un peu plus ?
[^] # Re: Industrie vers industrie
Posté par wilk . En réponse au lien Énergies renouvelables : la "chaleur fatale", une énergie antigaspi bénéfique pour l'environnement. Évalué à 2.
Voyons le bon côté, mon vieux thinkpad génère sa petite chaleur fatale comme les grands !
# J'aurai pas dit mieux !
Posté par wilk . En réponse au lien La télémétrie dans le tooling de Go (compilateur & co) sera par défaut désactivé (opt-in). Évalué à 4.
[^] # Re: La règle d'une bonne politique de sauvegarde : 3, 2, 1 !
Posté par wilk . En réponse au journal OVH va devoir payer pour l'incendie de son datacenter.... Évalué à 5.
4/ ne pas faire confiance aux fournisseurs de services.
[^] # Re: fake news ou relai de fake news.
Posté par wilk . En réponse au lien Centrale nucléaire de Golfech : la Garonne contaminée sur une "centaine de kilomètres" . Évalué à 4. Dernière modification le 10 février 2023 à 17:01.
Ne jetez pas la pierre sur le "militant sectaire", n'oublions jamais qu'on a tous été considérés comme tel ici il n'y a pas si longtemps.
On peut tout à faire dégager ce lien s'il est hors sujet ou y répondre avec arguments sans faire de procès d'intention.
[^] # Re: Dénomination pertinent/inutile
Posté par wilk . En réponse au sondage Seriez-vous pour masquer le score des commentaires ?. Évalué à 5.
Pour éviter l'utilisation de inutile pour pas d'accord est-ce qu'on a étudié l'idée d'avoir les deux ? Ainsi on pourrait indiquer pas d'accord mais pertinent ou d'accord et inutile…
# Y en avait autant ?
Posté par wilk . En réponse au lien Firefox perd env 16 millions d'utilisateurs depuis un an. Évalué à 7.
Déjà ça montre qu'il y avait au moins 16 millions d'utilisateurs.
[^] # Re: je ne vois qu'une solution
Posté par wilk . En réponse au lien Firefox perd env 16 millions d'utilisateurs depuis un an. Évalué à 5.
Attention y en a qui doublent par la bande d'arrêt d'urgence.
https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html
[^] # Re: A savoir
Posté par wilk . En réponse au lien Nucléaire - Six mois de retard supplémentaire pour l'EPR de Flamanville. Évalué à 4.
Le vent
[^] # Re: S3 ?
Posté par wilk . En réponse au journal Neon : Postgresql serverless avec branches. Évalué à 2.
https://cloud.google.com/blog/products/databases/announcing-the-general-availability-of-alloydb-for-postgresql
Idem chez l'autre.
[^] # Re: S3 ?
Posté par wilk . En réponse au journal Neon : Postgresql serverless avec branches. Évalué à 2.
Non, au contraire, c'est comme ça que fonctionne Aurora (AWS). Quelque soit l'architecture utilisée il y a toujours une gestion de cache d'ailleurs.
Plus la charge va être forte plus le cache va jouer à priori. Inversement c'est surtout pour les petites charges qu'il y a du démarrage à froid (Aurora v2 ne scale plus à zéro comme la v1 du coup).
A suivre…
[^] # Re: S3 ?
Posté par wilk . En réponse au journal Neon : Postgresql serverless avec branches. Évalué à 3.
Il y a une couche intermédiaire qui sert de cache. J'imagine que le problème va se poser sur des grosses bases où d'un coup on va vouloir tirer des infos "froides"…
Pour l'instant en beta test on a droit qu'à des toutes petites bases.
[^] # Re: Serverless ?
Posté par wilk . En réponse au journal Neon : Postgresql serverless avec branches. Évalué à 3.
Y a les deux côtés, le côté interne c'est ça, l'instance POstgresql est découplée du stockage voir inexistante, c'est le vrai serverless si on considère que le stockage ça n'est pas du serveur.
Et le côté service, là c'est serverless pour le client mais pas pour le fournisseur où là pour le coup c'est du servermore vu qu'il va avoir un serveur pour le stockage, un pour la couche intermédiaire, un pour le moteur, un pour l'api etc !
ps: pour l'instant je ne crois pas qu'il y ait de read-replicas, donc une seule instance ou zéro, mais c'est prévu ainsi que le scaling vertical automatique (pour ne pas avoir à choisir le type d'instance).
[^] # Re: Serverless ?
Posté par wilk . En réponse au journal Neon : Postgresql serverless avec branches. Évalué à 3.
Oui, en tout cas c'est comme ça qu'ils le décrivent https://neon.tech/blog/hello-world/
Vu que le stockage est à part la base et les branches existent même si aucun moteur n'est lancé.
# Suivi
Posté par wilk . En réponse au lien Le Courrier du hacker (n°199) - de Twitter vers Mastodon. Évalué à 3.
Ils ont déjà des mails @assemblee-nationale.fr, et il est possible de migrer vers une autre instance avec un suivi non ?
# Pilotage automatique
Posté par wilk . En réponse au lien Le milliardaire Elon Musk a pris le contrôle de Twitter et licencié des dirigeants. Évalué à 5.
Lancement prochain du mode autopilot. Plus besoin de tweeter soit-même. Grace à une IA, nommée KePenserDe, on pourra tweeter sans même avoir besoin d'être réveillé. Enfin des débats "sains" et non plus souillés par notre propre pensée archaïque soumise aux aléas biologiques d'un autre temps.
[^] # Re: Validité de l'HTML ?
Posté par wilk . En réponse au lien Migration de react vers htmx. Évalué à 4. Dernière modification le 20 octobre 2022 à 09:13.
Bien vu, apparemment c'est un problème qui n'est pas résolu et qui concerne pas mal d'autres frameworks, y a une recherche de consensus au niveau w3 pour permettre que des attributs persos soient valides mais c'est pas encore le cas. Théoriquement il faudrait utiliser quelque chose qui commence par
data-. Je ne sais pas si c'est possible de le configurer…# SPA en français
Posté par wilk . En réponse au lien Migration de react vers htmx. Évalué à 6.
Désolé j'ai raté l'option, c'est une migration d'une boite française mais c'est pas en français…
A part ça je peux aussi témoigner sur l'intérêt de cette petite lib qui permet d'ajouter un peu de réactivité aux pages sans renier la logique du rendu serveur… Que du bonheur.
[^] # Re: Histoire de casser du sucre
Posté par wilk . En réponse au lien Dans les coulisses produit de SNCF Connect, l’appli qui a déraillé au départ. Évalué à 7.
Dernier truc rigolo en date, en récupération de billet (acheté sur TER et transféré sur l'appli) il n'en récupère qu'un sur 4 et me l'affiche avec 2h en moins ! Ca sent le problème de timezone… J'imprime…
# Le bon côté
Posté par wilk . En réponse au lien Dans les coulisses produit de SNCF Connect, l’appli qui a déraillé au départ. Évalué à 6. Dernière modification le 24 septembre 2022 à 21:18.
C'est que maintenant les gens sont tellement habitués à voir des applis pleins de bugs que soit mon appli en à aussi et c'est normal c'est comme ça, comme les grands, soit elle n'en n'a pas (et en plus elle est rapide) et je passe pour un génie !
edit:
Et maintenant je pourrai dire à mes clients, attention si vous ne testez pas la beta ça va finir comme à la SNCF.
# Knative, le graal.
Posté par wilk . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été. Évalué à 4.
J'ai trouvé le graal du serverless sans la contrainte de réécrire les apps ! Ca s'appelle Knative, ça scale de zéro… Je dis knative pour ne pas citer Scaleway et CloudRun qui le proposent « as a service ». Le principe est simple, l'application doit écouter sur le port 8080 comme n'importe quel serveur http.
Longtemps j'étais réticent à quitter l'infra à la papa où rien n'a changé ou presque sous le capot depuis 30 ans et qui permet de comprendre ce qui se passe et agir à tous les niveaux. Mais là j'avoue, c'est bluffant. Git push et voilà.
L'avantage du Go dans ce cas il est simple, un Dockerfile avec un distroless on ne plus simple et le démarrage à froid se fait dans la seconde, une empreinte mémoire ridicule, un cpu qui reste au raz des pâquerettes. Tout ce qu'il faut pour faire un serveur http est dans la lib standard, même les templates html, même l'embarquement des assets dans le binaire !
Autre avantage de Go c'est de pouvoir jongler soit avec des goroutines+channel en interne soit reproduire exactement la même chose en microservices séparés (les channels sont à sens unique). Il m'est arrivé plusieurs fois de passer de l'une à l'autre méthode en changeant quelques lignes de code simplement.
Niveau de la simplicité du langage personnellement ça me rappelle le C de ma jeunesse, que de bons souvenirs !
Bref, à part la partie cachée du serverless, je retrouve le côté simple d'unix un binaire qui vet voilà.
[^] # Re: Go remplace Java
Posté par wilk . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été. Évalué à 6.
Tellement rapide. Je modifie un fichier, j'enregistre, le code est formaté, les imports ajustés, les erreurs de types détectées, le temps d'aller sur le bureau d'à côté et de recharger ma page le bouzin est déjà recompilé. C'est plus rapide que quand de relancer un serveur python !