wilk a écrit 1159 commentaires

Le problème du coût des jets d'encre n'est pas tant le coût à la page mais obsolescence programmée.
Par exemple sur une hp6970 j'ai jeté une cartouche originale et dans son emballage d'origine juste parce qu'elle était "en fin de garantie" (la cartouche oui !).
Je ne compte pas non plus les multiples nettoyages et réinitialisations qui vident les cartouches à cause d'un message d'erreur incongru.
Ce sont des imprimantes à jet, jet d'encre, jet à la poubelle, je ne compte plus les imprimantes parties à la casse en retour de vacance parce que j'avais oublié de les laisser allumées pour qu'elles fassent leur petite consommation automatique.

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 ?

A replacer quelques années en arrière !

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.

Tu peux en dire un peu plus ?

Merci, je ne connaissais pas le terme chaleur fatale.
Je reste relativement pessimiste

Voyons le bon côté, mon vieux thinkpad génère sa petite chaleur fatale comme les grands !

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.”

4/ ne pas faire confiance aux fournisseurs de services.

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…

Déjà ça montre qu'il y avait au moins 16 millions d'utilisateurs.

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

Le vent

https://cloud.google.com/blog/products/databases/announcing-the-general-availability-of-alloydb-for-postgresql

Idem chez l'autre.

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).

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é.

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.

l’Assemblée nationale et le Sénat pourraient créer leurs propres instances. Mais, que se passerait-il quand le parlementaire n’est plus en fonction ?

Ils ont déjà des mails @assemblee-nationale.fr, et il est possible de migrer vers une autre instance avec un suivi non ?

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à.