Y a pas si longtemps le marqueur social c'était plutôt la petite voiture de sport. Les 4x4 étaient d'ailleurs le plus léger possible pour pouvoir justement passer partout. Les grosses voitures étaient très ringardes.
L'avantage pour les constructeurs c'est que ça ne leur coûte pas beaucoup plus cher de juste rajouter du volume, ils font plus de marge (ce que dit Frédéric Heran).
Dans ma rue la plupart des maisons ont un garage mais plus personne n'arrive à se garer dedans ! Du coup le SUV flambant neuf et ben il dort dehors, ça la fout mal niveau marqueur social je trouve.
J'ai même un voisin qui cherche désespérément un maçon pour lui agrandir son garage, mais déplacer un mur porteur d'une maison des années 30 à étage y a pas grand monde qui a envie de s'y aventurer !
En vue des restrictions énergétiques pour cause de guerre nucléaire ou autres petits aléas je vous suggère les raclettes à la bougie, un petit support qui permet de chauffer le fromage individuellement avec deux ou trois petites bougies (ou des braises si on est en camping). Je ne vous indique pas de marque, il est tout à fait possible de se les bricoler soit-même en découpant dans une tôle.
Comme ça on règle le problème de l'appareil, chacun peut apporter sa propre installation.
Là où je suis hébergé il ne compte pas les mails envoyés entre nous (chez ce même hébergeur). C'est pas mal pour les échanges familiaux ou dans la même boite et ça pourrait inciter à faire du parrainage !
Les paliers sont un peu perturbants, si on passe de 35 à 36 mails, de 5Go à 6Go BOUM! Ca reviendrait moins cher de prendre deux comptes que de passer au plan suivant. Le Go est proportionnellement moins cher sur le plan évolution que sur le plan professionnel.
Est-ce qu'il est prévu d'avoir une tarification plus progressive ?
Les scientifiques ont observé que les pays qui disposent des parcs nucléaires les plus importants n’ont pas tendance à réduire significativement leurs émissions. Dans les pays peu développés, les programmes nucléaires semblent même être associés à un accroissement de celles-ci.
A l’inverse, les Etats qui s’engagent dans des politiques donnant la priorité aux renouvelables parviennent mieux à réduire leurs émissions, et cela quel que soit le niveau de leur PIB ou la période observée.
C'est justement du fait que le CO2 s'accumule qu'il faut diminuer le plus rapidement possible. Plus on attend plus l'effort devra être important et inversement plus on diminue rapidement plus ça nous laisse du temps.
C'est un peu pareil à part que c'est du catchall.
Dans le fond ça revient au même, qu'on "lance des exceptions" qu'on "rattrape" ou qu'on renvoi des "erreurs" qu'on traite comme des valeurs…
Je trouve que la confusion vient du terme "error" qu'on aurait plutôt du appeler "status" ou quelque chose comme ça. C'est une simple information, pas forcément une erreur.
Par exemple io.EOF, sql.ErrNoRows, j'ai des handlers peuvent renvoyer une "erreur" de type Redirect etc.
Du coup c'est une valeur retournée comme une autre et donc traitée comme n'importe quelle valeur.
Comme Go est au départ utilisé pour du réseau le fait que cette "erreur" doit pouvoir renvoyer un string permet de faire transiter tout ça facilement.
C'est aussi comme les retours de commandes unix qui renvoient 0 1 -1…
Y a un copain qui m'a dit récemment, mais tu gérais les erreurs aussi comme ça en Python !
Les véritables erreurs c'est plutôt les panics qu'on rattrape avec recover.
Ca vaut vraiment le coup de fouiller un peu pour trouver les articles et confs qu'ils ont faits sur le sujet, l'équipe est d'un niveau assez impressionnant et les explications très détaillées.
Comme je ne note jamais rien j'ai aucun lien à donner…
D'après cette excellente description il serait possible de générer du code Go à partir du V et inversement et plus facilement que du C, est-ce que ça a été tenté ?
Je me demande tout de même à quel point ça a dû être complexe d'implémenter les garanties ACID en stateless.
Dans l'idée ça reste très classique, il y à toujours qu'un seul master, il n'y a que la couche de stockage qui change avec un serveur "pageserver" (un seul aussi et qui ne bouge pas) qui fait cache et le stockage persistant en copy-and-write.
Je ne répondais pas à ton commentaire non plus, je complémentais !
Je ne retrouve pas la source mais un des fondateur de Neon avait expliqué que l'idée lui était venu par rapport à une procédure qu'il avait mis en place en local, je ne me souviens plus exactement, probablement à base de snapshots fichiers.
Ce qui est pratique avec le côté service c'est également quand la base est très grosse et qu'il est trop long de la rapatrier chaque fois en local pour du dev ou des tests.
Pour l'instant chez eux cette option de scaling coûte plutôt moins cher que sans. Si on considère que c'est de facto une forme de haute dispo c'est même carrément moins cher.
Le côté cloud/serverless n'est pas que, c'est pour ça que j'ai surtout voulu parler du principe des branches.
On a la branche principale qui est celle de prod et on peut créer une branche pour faire un test de dev. C'est du copy-on-write, les données présentes ne sont pas dupliquées, seules les nouvelles données seront séparées. La séparation stockage/moteur permet de lancer un postgresql sur ce stockage dev avec ou pas les mêmes caractéristiques de mémoire etc.
Autant la charge est souvent prédictive en général autant il y a toujours des périodes de grosses mises à jour où on a besoin de plus de puissance très ponctuellement, l'auto scaling est très intéressant dans ce cas.
Sur des applications qui sont utilisées aux horaires de bureau c'est rudement intéressant aussi.
Dans les databases des databases il y a Neon.
Pouvoir faire une branche d'une DB quelque soit sa taille aussi rapidement qu'on ferait un git branch, franchement, c'est une tuerie. En prime ça descend à l'échelle jusque dans la cave.
A l'époque on s'échangeait les disquettes, c'est de ce même réseau qu'on se connaissait. Y avait aussi quelques mentions dans les revues.
Alors je dois avoir du code dans des vieux cartons dans un vieux garage assez loin, aucune idée si c'est encore récupérable. Mais c'est de l'assembleur 6502 sans aucun commentaire, ça pique un peu aujourd'hui !
L'ordinateur était donc éteint, quand le téléphone sonnait driiin, pause, driiin ça envoyait du jus pendant le driiin, l'électro-aimant s'activait, l'ordinateur démarrait, dès la fin du driiin plus de jus, plus d'électro-aimant actif, il fallait donc que l'ordinateur démarre et tout de suite actionne à son tour l'électro aimant. Pour ça c'était codé en language machine et ça démarrait sans OS, on appelait ça un "fast-boot". Le programme était chargé directement au boot, sans OS pour enregistrer les données on les enregistrait sur la disquette directement secteur par secteur.
Un micro serveur c'était un petit micro, un Apple ][, un Atari ST etc. sur lequel on codait un serveur, à peu près de la même manière qu'un serveur web, quelque chose qui écoute et qui répond. Comme tout le monde avait un minitel on connectait le minitel à l'ordinateur et on utilisait le modem du minitel pour écouter. Le minitel était bien sûr relié à la ligne téléphonique. Les visiteurs appelaient notre numéro de téléphone, le téléphone sonnait, on décrochait et on "envoyait la porteuse", le visiteur entendait la porteuse (un son continu strident) et connectait son minitel (une touche "connection"). Une fois connecté il pouvait accéder au serveur, ensuite il raccrochait pour libérer la ligne et quelqu'un d'autre pouvait appeler. Le minitel n'est qu'un simple terminal, une sorte de navigateur.
Au début on entendait la sonnerie, on courrait, on décrochait et la personne disait qu'elle voudrait se connecter, on lançait la porteuse. Ensuite on se faisait un petit boitier électronique qui décrochait et envoyait la porteuse tout seul mais du coup si c'était quelqu'un qui voulait parler il se recevait une porteuse en pleine poire ! Donc y avait des horaires et les plus riches avaient une ligne dédiée.
Comme les ordinateurs chauffaient, (ils n'avaient pas de ventilateur) avec mon paternel on avait fait un boitier électronique avec un électro-aimant qui allumait l'ordinateur quand le téléphone sonnait et qui l'éteignait quand la personne partait, une sorte de cloudrun quoi !
Chaque micro serveur était codé à la main et avait souvent un thème, par exemple un thème sur le hacking, un thème sur la prog, jeux etc, quelques pages de texte et quelques pages de type forum. On pouvait également communiquer directement, uniquement entre celui qui avait le micro-serveur et l'appelant.
Les BBS c'est un peu différent. Ils utilisaient aussi les lignes téléphoniques et les modems mais ils communiquaient entre eux pour partager les messages, comme les newsgroups. Ceux qui communiquaient étaient appelés des "nœuds". Les utilisateurs se connectaient à un des noeuds, le plus proche souvent, à l'aide d'un autre micro qui devait avoir un client adapté (et donc pas un terminal comme le minitel). Et à intervalle régulier les noeuds s'appelaient les uns les autres pour partager les messages. C'était un système très résilient, comme les mails et les newsgroups.
Ca me rappelle l'époque des microserveurs minitel dans les années 80, on inversait le modem du minitel 1200/75 bauds, ils étaient branchés sur la ligne de téléphone familiale et on se donnait des heures d'ouvertures pour ne pas saturer la ligne et ne pas faire trop chauffer le micro. Chaque serveur indiquait ces heures d'ouvertures et ça semblait tout à fait normal vu que dans la vraie vie c'est bien comme ça que ça marche à part quelques exceptions comme les pompiers et les hôpitaux.
[^] # Re: Question peut-être stupide, que-ce qui attire les automobilistes chez les SUV
Posté par wilk . En réponse au lien Sans l'engouement pour les SUV, les émissions des moteurs auraient pu baisser de 30% . Évalué à 5.
Y a pas si longtemps le marqueur social c'était plutôt la petite voiture de sport. Les 4x4 étaient d'ailleurs le plus léger possible pour pouvoir justement passer partout. Les grosses voitures étaient très ringardes.
L'avantage pour les constructeurs c'est que ça ne leur coûte pas beaucoup plus cher de juste rajouter du volume, ils font plus de marge (ce que dit Frédéric Heran).
[^] # Re: Question peut-être stupide, que-ce qui attire les automobilistes chez les SUV
Posté par wilk . En réponse au lien Sans l'engouement pour les SUV, les émissions des moteurs auraient pu baisser de 30% . Évalué à 5.
Dans ma rue la plupart des maisons ont un garage mais plus personne n'arrive à se garer dedans ! Du coup le SUV flambant neuf et ben il dort dehors, ça la fout mal niveau marqueur social je trouve.
J'ai même un voisin qui cherche désespérément un maçon pour lui agrandir son garage, mais déplacer un mur porteur d'une maison des années 30 à étage y a pas grand monde qui a envie de s'y aventurer !
[^] # Re: Confusion
Posté par wilk . En réponse au message Migration e-mails de Gandi vers Pulseheberg. Évalué à 4.
Sauf erreur si tu change de registrar tu cumules, donc tu ne perds pas tes années déjà payées. Goodbye Gandi…
# Bougie
Posté par wilk . En réponse au journal Il est temps que la communauté internationale fasse un choix. Évalué à 4.
En vue des restrictions énergétiques pour cause de guerre nucléaire ou autres petits aléas je vous suggère les raclettes à la bougie, un petit support qui permet de chauffer le fromage individuellement avec deux ou trois petites bougies (ou des braises si on est en camping). Je ne vous indique pas de marque, il est tout à fait possible de se les bricoler soit-même en découpant dans une tôle.
Comme ça on règle le problème de l'appareil, chacun peut apporter sa propre installation.
[^] # Re: Paliers
Posté par wilk . En réponse au journal [publicité] galae, le service email éthique et libre (et français) est désormais ouvert \o/. Évalué à 5.
Attention, si tu cherches des "enjeux" dans les commentaires on va se poser des questions sur l'enjeu de ton journal !
[^] # Re: Paliers
Posté par wilk . En réponse au journal [publicité] galae, le service email éthique et libre (et français) est désormais ouvert \o/. Évalué à 5.
Là où je suis hébergé il ne compte pas les mails envoyés entre nous (chez ce même hébergeur). C'est pas mal pour les échanges familiaux ou dans la même boite et ça pourrait inciter à faire du parrainage !
# Paliers
Posté par wilk . En réponse au journal [publicité] galae, le service email éthique et libre (et français) est désormais ouvert \o/. Évalué à 8.
Les paliers sont un peu perturbants, si on passe de 35 à 36 mails, de 5Go à 6Go BOUM! Ca reviendrait moins cher de prendre deux comptes que de passer au plan suivant. Le Go est proportionnellement moins cher sur le plan évolution que sur le plan professionnel.
Est-ce qu'il est prévu d'avoir une tarification plus progressive ?
[^] # Re: Prédictions
Posté par wilk . En réponse au lien Dérèglement climatique: des scientifiques dénoncent une menace existentielle pour la vie sur Terre. Évalué à 3.
La démocratie actuelle est déjà un système "où des -autoproclamés- experts déterminent la politique optimale".
[^] # Re: hx-on
Posté par wilk . En réponse au lien Surfacing request errors when using HTMX. Évalué à 2. Dernière modification le 18 octobre 2023 à 18:36.
Je viens de voir cette issue : https://github.com/bigskysoftware/htmx/issues/1529
On devrait pouvoir toutes les rattraper avec
hx-on::error# hx-on
Posté par wilk . En réponse au lien Surfacing request errors when using HTMX. Évalué à 4.
Il me semble que maintenant on peut faire plus simple :
<body hx-on::response-error="alert('oups')">[^] # Re: tldr
Posté par wilk . En réponse au lien Rapport du haut conseil pour le climat. Évalué à 6.
Inutile d'aller chercher si loin, "on adore la bagnole" tout simplement (et aussi un peu l'avion).
[^] # Re: Deja vu
Posté par wilk . En réponse au lien Plus de 1000 scientifiques lancent un appel contre la relance du nucléaire en France. Évalué à 3.
Dans l'idéal le nucléaire servirait de base aux ENR et de ce fait permettrait un développement encore plus massif et surtout rapide des ENR.
Mais de fait c'est l'inverse, c'est ce qui pose problème et impose du coup de le rejeter faute de consensus.
https://www.revolution-energetique.com/le-nucleaire-est-moins-efficace-que-les-renouvelables-pour-reduire-les-emissions-de-carbone/ (étude scientifique)
[^] # Re: Deja vu
Posté par wilk . En réponse au lien Plus de 1000 scientifiques lancent un appel contre la relance du nucléaire en France. Évalué à 6.
C'est justement du fait que le CO2 s'accumule qu'il faut diminuer le plus rapidement possible. Plus on attend plus l'effort devra être important et inversement plus on diminue rapidement plus ça nous laisse du temps.
[^] # Re: Deja vu
Posté par wilk . En réponse au lien Plus de 1000 scientifiques lancent un appel contre la relance du nucléaire en France. Évalué à 10.
Moi je pense qu'aujourd'hui l'urgence c'est de moins émettre de CO2 dans les 50 dernières années.
[^] # Re: Une gestion d’erreur moderne ?
Posté par wilk . En réponse à la dépêche À la découverte du langage V. Évalué à 3.
C'est un peu pareil à part que c'est du catchall.
Dans le fond ça revient au même, qu'on "lance des exceptions" qu'on "rattrape" ou qu'on renvoi des "erreurs" qu'on traite comme des valeurs…
[^] # Re: Une gestion d’erreur moderne ?
Posté par wilk . En réponse à la dépêche À la découverte du langage V. Évalué à 4.
Je trouve que la confusion vient du terme "error" qu'on aurait plutôt du appeler "status" ou quelque chose comme ça. C'est une simple information, pas forcément une erreur.
Par exemple io.EOF, sql.ErrNoRows, j'ai des handlers peuvent renvoyer une "erreur" de type Redirect etc.
Du coup c'est une valeur retournée comme une autre et donc traitée comme n'importe quelle valeur.
Comme Go est au départ utilisé pour du réseau le fait que cette "erreur" doit pouvoir renvoyer un string permet de faire transiter tout ça facilement.
C'est aussi comme les retours de commandes unix qui renvoient 0 1 -1…
Y a un copain qui m'a dit récemment, mais tu gérais les erreurs aussi comme ça en Python !
Les véritables erreurs c'est plutôt les panics qu'on rattrape avec recover.
[^] # Re: Neon c'est bon.
Posté par wilk . En réponse au lien database of Databases. Évalué à 2.
Ca vaut vraiment le coup de fouiller un peu pour trouver les articles et confs qu'ils ont faits sur le sujet, l'équipe est d'un niveau assez impressionnant et les explications très détaillées.
Comme je ne note jamais rien j'ai aucun lien à donner…
# Go <-> V
Posté par wilk . En réponse à la dépêche À la découverte du langage V. Évalué à 4.
D'après cette excellente description il serait possible de générer du code Go à partir du V et inversement et plus facilement que du C, est-ce que ça a été tenté ?
[^] # Re: Neon c'est bon.
Posté par wilk . En réponse au lien database of Databases. Évalué à 3.
Dans l'idée ça reste très classique, il y à toujours qu'un seul master, il n'y a que la couche de stockage qui change avec un serveur "pageserver" (un seul aussi et qui ne bouge pas) qui fait cache et le stockage persistant en copy-and-write.
[^] # Re: Neon c'est bon.
Posté par wilk . En réponse au lien database of Databases. Évalué à 3.
Je ne répondais pas à ton commentaire non plus, je complémentais !
Je ne retrouve pas la source mais un des fondateur de Neon avait expliqué que l'idée lui était venu par rapport à une procédure qu'il avait mis en place en local, je ne me souviens plus exactement, probablement à base de snapshots fichiers.
Ce qui est pratique avec le côté service c'est également quand la base est très grosse et qu'il est trop long de la rapatrier chaque fois en local pour du dev ou des tests.
Pour l'instant chez eux cette option de scaling coûte plutôt moins cher que sans. Si on considère que c'est de facto une forme de haute dispo c'est même carrément moins cher.
[^] # Re: Neon c'est bon.
Posté par wilk . En réponse au lien database of Databases. Évalué à 3.
Le côté cloud/serverless n'est pas que, c'est pour ça que j'ai surtout voulu parler du principe des branches.
On a la branche principale qui est celle de prod et on peut créer une branche pour faire un test de dev. C'est du copy-on-write, les données présentes ne sont pas dupliquées, seules les nouvelles données seront séparées. La séparation stockage/moteur permet de lancer un postgresql sur ce stockage dev avec ou pas les mêmes caractéristiques de mémoire etc.
Autant la charge est souvent prédictive en général autant il y a toujours des périodes de grosses mises à jour où on a besoin de plus de puissance très ponctuellement, l'auto scaling est très intéressant dans ce cas.
Sur des applications qui sont utilisées aux horaires de bureau c'est rudement intéressant aussi.
# Neon c'est bon.
Posté par wilk . En réponse au lien database of Databases. Évalué à 2.
Dans les databases des databases il y a Neon.
Pouvoir faire une branche d'une DB quelque soit sa taille aussi rapidement qu'on ferait un git branch, franchement, c'est une tuerie. En prime ça descend à l'échelle jusque dans la cave.
[^] # Re: Un autre site solaire
Posté par wilk . En réponse au lien Solar Protocol. Évalué à 5.
A l'époque on s'échangeait les disquettes, c'est de ce même réseau qu'on se connaissait. Y avait aussi quelques mentions dans les revues.
Alors je dois avoir du code dans des vieux cartons dans un vieux garage assez loin, aucune idée si c'est encore récupérable. Mais c'est de l'assembleur 6502 sans aucun commentaire, ça pique un peu aujourd'hui !
L'ordinateur était donc éteint, quand le téléphone sonnait driiin, pause, driiin ça envoyait du jus pendant le driiin, l'électro-aimant s'activait, l'ordinateur démarrait, dès la fin du driiin plus de jus, plus d'électro-aimant actif, il fallait donc que l'ordinateur démarre et tout de suite actionne à son tour l'électro aimant. Pour ça c'était codé en language machine et ça démarrait sans OS, on appelait ça un "fast-boot". Le programme était chargé directement au boot, sans OS pour enregistrer les données on les enregistrait sur la disquette directement secteur par secteur.
[^] # Re: Un autre site solaire
Posté par wilk . En réponse au lien Solar Protocol. Évalué à 6.
Un micro serveur c'était un petit micro, un Apple ][, un Atari ST etc. sur lequel on codait un serveur, à peu près de la même manière qu'un serveur web, quelque chose qui écoute et qui répond. Comme tout le monde avait un minitel on connectait le minitel à l'ordinateur et on utilisait le modem du minitel pour écouter. Le minitel était bien sûr relié à la ligne téléphonique. Les visiteurs appelaient notre numéro de téléphone, le téléphone sonnait, on décrochait et on "envoyait la porteuse", le visiteur entendait la porteuse (un son continu strident) et connectait son minitel (une touche "connection"). Une fois connecté il pouvait accéder au serveur, ensuite il raccrochait pour libérer la ligne et quelqu'un d'autre pouvait appeler. Le minitel n'est qu'un simple terminal, une sorte de navigateur.
Au début on entendait la sonnerie, on courrait, on décrochait et la personne disait qu'elle voudrait se connecter, on lançait la porteuse. Ensuite on se faisait un petit boitier électronique qui décrochait et envoyait la porteuse tout seul mais du coup si c'était quelqu'un qui voulait parler il se recevait une porteuse en pleine poire ! Donc y avait des horaires et les plus riches avaient une ligne dédiée.
Comme les ordinateurs chauffaient, (ils n'avaient pas de ventilateur) avec mon paternel on avait fait un boitier électronique avec un électro-aimant qui allumait l'ordinateur quand le téléphone sonnait et qui l'éteignait quand la personne partait, une sorte de cloudrun quoi !
Chaque micro serveur était codé à la main et avait souvent un thème, par exemple un thème sur le hacking, un thème sur la prog, jeux etc, quelques pages de texte et quelques pages de type forum. On pouvait également communiquer directement, uniquement entre celui qui avait le micro-serveur et l'appelant.
Les BBS c'est un peu différent. Ils utilisaient aussi les lignes téléphoniques et les modems mais ils communiquaient entre eux pour partager les messages, comme les newsgroups. Ceux qui communiquaient étaient appelés des "nœuds". Les utilisateurs se connectaient à un des noeuds, le plus proche souvent, à l'aide d'un autre micro qui devait avoir un client adapté (et donc pas un terminal comme le minitel). Et à intervalle régulier les noeuds s'appelaient les uns les autres pour partager les messages. C'était un système très résilient, comme les mails et les newsgroups.
[^] # Re: Un autre site solaire
Posté par wilk . En réponse au lien Solar Protocol. Évalué à 5.
Ca me rappelle l'époque des microserveurs minitel dans les années 80, on inversait le modem du minitel 1200/75 bauds, ils étaient branchés sur la ligne de téléphone familiale et on se donnait des heures d'ouvertures pour ne pas saturer la ligne et ne pas faire trop chauffer le micro. Chaque serveur indiquait ces heures d'ouvertures et ça semblait tout à fait normal vu que dans la vraie vie c'est bien comme ça que ça marche à part quelques exceptions comme les pompiers et les hôpitaux.