Le compte aurait été supprimé par Google à cause d'une erreur de configuration. Mais comme on dit maintenant "qui aurait pu prévoir ?" vu que promis juré ça n'est jamais arrivé et ça n'arrivera plus jamais.
Et comme Google fait bien les choses les sauvegardes sur plusieurs régions on été supprimées également.
Heureusement la boite avait prévu une sauvegarde chez un autre provider.
Personnellement j'utilise les mêmes combinaisons de touches depuis des décennies que ce soit dans Vim, Fluxbox ou le navigateur, que j'édite du code ou un mail ou autre…
Tu peux développer ce qui à l'air particulier à ce niveau ?
Ce qui se rapprocherait plus de l'event sourcing au niveau Pg ce serait plutôt la réplication logique.
La on est sur du très bas niveau et il n'était pas prévu au départ d'en faire autre chose que du stockage sur FS, d'où le boulot qui est fait en ce moment pour en faire autre chose côté cloud.
En pratique le WAL c'est juste une série de fichiers sur disque. Quand on veut faire de la réplication il suffit de les copier sur un autre disque au fur et à mesure. Si on veut revenir dans le temps il suffit de partir d'un snapshot et d'appliquer uniquement les fichiers jusqu'à une certaine date (c'est lent parce qu'il faut repartir d'un snapshot).
L'astuce de Neon c'est que le stockage lui-même est effectué sous forme incrémentale ce qui fait qu'on a des snapshots prêts instantanément et on gagne en fiabilité (les données sont immuables). Comme ZFS, c'est de là qu'est venue l'idée.
Neon s'interface entre les WAL et le stockage (je pense que c'est une partie qui va remonter dans le core).
Ensuite toute la difficulté va être de jouer sur le cache avec une partie des données périmées d'un côté et les données en cours de l'autre…
RDS c'est juste une installation et une maintenance sur des resources fixes que tu choisis, y a pas de scaling automatique. Aurora c'est exactement le même principe que Neon (ou plutôt l'inverse !), le stockage est dissocié du moteur ce qui fait que le moteur peut changer à la volée. J'imagine que niveau perf tout est dans la gestion du cache entre les deux. Mais je ne crois pas que les perfs soient le premier objectif de Neon, c'est plutôt le côté dev, enfin du moins dans un premier temps.
Tu parles de Aurora plutôt que RDS non ?
Neon a dépassé Aurora du côté des fonctionnalités pour les devs mais je ne pense pas qu'ils s'approchent encore des performances et du reste leur infra est encore uniquement sur AWS. Mais espérons qu'un jour ça permette d'autres alternatives sur d'autres clouds et avec d'autres fournisseurs.
Ce qui est intéressant avec cet article c'est justement de montrer que c'est le principe des WAL de PostgreSQL qui permet de faire toutes sortes de choses dès l'instant où on raisonne en terme de journaux et non de stockage fixe. Il y a plusieurs manières ensuite de l'automatiser, Neon en est une mais ça fait longtemps qu'on peut faire du PITR.
Pour la comparaison avec RDS, comme avec Neon il n'y à aucune différence au niveau de l'utilisation, c'est un PostgresSQL tout ce qu'il y a de plus classique, (au pire il manquera des extensions ?), je ne vois pas où tu vois un problème pour quitter le service ?
Neon est open source à part la GUI. C'est surtout le fait que ce soit encore récent qui limite la prod et les éventuelles reprises par d'autres.
Je me souviens un jour en allant montrer tout content la nouvelle version à l'utilisatrice qui allait ainsi "gagner du temps". Elle m'a regardé bizarrement et m'a dit "et je vais faire quoi moi du coup maintenant ?"… Une entreprise moyenne, familiale…
Le fait de se baser sur les journaux de transaction permet sans dupliquer les données et de manière quasiment instantanée de :
- Créer des branches indépendantes
- Lancer des requêtes à un instant antérieur (en créant une branche de manière transparente)
- Lancer un read-replica
C'est incroyablement pratique en dev et à priori très résilient en prod (à vérifier à l'usage…).
Il y a eu quantité d'article de blog sur leur infra mais celui-là me semble particulièrement pédagogique.
L'infra est codée en Rust et la partie qui concerne spécifiquement le moteur est libre.
Le nombre d'interventions montre surtout qu'on a beaucoup de compassion pour un membre de notre communauté qu'on aimerait bien aider et qu'on aurait peine à rejeter.
Merci pour ces informations, on a tout lu, on est tous convaincus. Mission accomplie. Tu peux maintenant aller informer d'autres congénères, nous c'est bon, c'est fait.
Il faudrait par contre supprimer ce journal au plus vite parce que vu la puissance de ce complot il ne faudrait pas qu'on en subisse les représailles maintenant qu'on l'a mis à jour.
Pas tant que ça, ça fait 1 par seconde fiche par fiche pendant un peu plus d'un an.
Il peut y avoir des pages de type listing, des exports et autres, ça peut aller très vite et ça reste très loin d'un ddos donc indétectable si ça n'est pas prévu.
Ca me semble tellement facile de faire du scrapping sur ce genre de données vu que n'importe quel employé a accès aux fiches.
Quel serait la parade ? Tracer et limiter le nombre de consultations par utilisateur ?
La blague c'est quand ils sortent l'argument de la sécurité pour freiner.
Mais comme aurait dit Coluche, il suffirait que les gens ne les utilisent pas pour que ces messageries propriétaires disparaissent.
Dans un sens est-ce que les bloqueurs de pubs ne sont pas contre productifs pour mettre en avant les sites qui n'en n'ont pas (de pub) ?
A l'époque où je lisais uniquement les journaux papiers je ne me posais pas la question longtemps entre un journal avec ou sans pub.
Le problème avec OVH & Scaleway c'est quand même qu'ils n'admettent jamais qu'ils ne sont pas du tout prêt. Ce qui est tout à fait compréhensible vu qu'ils n'ont pas les mêmes moyens et aucun engagement de l'état pour les soutenir. Mais ne pas l'admettre empêche de voir les vrais problèmes et donc de chercher les bonnes solutions.
Pour les besoins simples (ou pas ?) Caddy est une bonne alternative.
Pour les besoins encore plus simples ou beaucoup plus compliqués on peut coder un proxy en Go avec une qualité de prod sans dépendances extérieures. C'est fait pour j'ai envie de dire…
[^] # Re: Résumé
Posté par wilk . En réponse au lien Google cloud (GCP) efface un compte par accident.. Évalué à 4 (+2/-0).
Surtout si on jette le panier dans les nuages en espérant qu'il y reste bien accroché !
# Résumé
Posté par wilk . En réponse au lien Google cloud (GCP) efface un compte par accident.. Évalué à 6 (+4/-0).
Le compte aurait été supprimé par Google à cause d'une erreur de configuration. Mais comme on dit maintenant "qui aurait pu prévoir ?" vu que promis juré ça n'est jamais arrivé et ça n'arrivera plus jamais.
Et comme Google fait bien les choses les sauvegardes sur plusieurs régions on été supprimées également.
Heureusement la boite avait prévu une sauvegarde chez un autre provider.
[^] # Re: Sans vouloir faire mon vieux con...
Posté par wilk . En réponse au lien dte : un autre éditeur de texte normal. Évalué à 2 (+2/-2).
Personnellement j'utilise les mêmes combinaisons de touches depuis des décennies que ce soit dans Vim, Fluxbox ou le navigateur, que j'édite du code ou un mail ou autre…
Tu peux développer ce qui à l'air particulier à ce niveau ?
[^] # Re: Résumé
Posté par wilk . En réponse au lien Postgresql en tant que journal de transactions. Évalué à 2 (+0/-0).
Ce qui se rapprocherait plus de l'event sourcing au niveau Pg ce serait plutôt la réplication logique.
La on est sur du très bas niveau et il n'était pas prévu au départ d'en faire autre chose que du stockage sur FS, d'où le boulot qui est fait en ce moment pour en faire autre chose côté cloud.
En pratique le WAL c'est juste une série de fichiers sur disque. Quand on veut faire de la réplication il suffit de les copier sur un autre disque au fur et à mesure. Si on veut revenir dans le temps il suffit de partir d'un snapshot et d'appliquer uniquement les fichiers jusqu'à une certaine date (c'est lent parce qu'il faut repartir d'un snapshot).
L'astuce de Neon c'est que le stockage lui-même est effectué sous forme incrémentale ce qui fait qu'on a des snapshots prêts instantanément et on gagne en fiabilité (les données sont immuables). Comme ZFS, c'est de là qu'est venue l'idée.
Neon s'interface entre les WAL et le stockage (je pense que c'est une partie qui va remonter dans le core).
Ensuite toute la difficulté va être de jouer sur le cache avec une partie des données périmées d'un côté et les données en cours de l'autre…
https://neon.tech/blog/architecture-decisions-in-neon
[^] # Re: Résumé
Posté par wilk . En réponse au lien Postgresql en tant que journal de transactions. Évalué à 3 (+1/-0).
RDS c'est juste une installation et une maintenance sur des resources fixes que tu choisis, y a pas de scaling automatique. Aurora c'est exactement le même principe que Neon (ou plutôt l'inverse !), le stockage est dissocié du moteur ce qui fait que le moteur peut changer à la volée. J'imagine que niveau perf tout est dans la gestion du cache entre les deux. Mais je ne crois pas que les perfs soient le premier objectif de Neon, c'est plutôt le côté dev, enfin du moins dans un premier temps.
[^] # Re: Résumé
Posté par wilk . En réponse au lien Postgresql en tant que journal de transactions. Évalué à 3 (+1/-0).
Tu parles de Aurora plutôt que RDS non ?
Neon a dépassé Aurora du côté des fonctionnalités pour les devs mais je ne pense pas qu'ils s'approchent encore des performances et du reste leur infra est encore uniquement sur AWS. Mais espérons qu'un jour ça permette d'autres alternatives sur d'autres clouds et avec d'autres fournisseurs.
[^] # Re: Résumé
Posté par wilk . En réponse au lien Postgresql en tant que journal de transactions. Évalué à 3 (+1/-0).
Ce qui est intéressant avec cet article c'est justement de montrer que c'est le principe des WAL de PostgreSQL qui permet de faire toutes sortes de choses dès l'instant où on raisonne en terme de journaux et non de stockage fixe. Il y a plusieurs manières ensuite de l'automatiser, Neon en est une mais ça fait longtemps qu'on peut faire du PITR.
Pour la comparaison avec RDS, comme avec Neon il n'y à aucune différence au niveau de l'utilisation, c'est un PostgresSQL tout ce qu'il y a de plus classique, (au pire il manquera des extensions ?), je ne vois pas où tu vois un problème pour quitter le service ?
Neon est open source à part la GUI. C'est surtout le fait que ce soit encore récent qui limite la prod et les éventuelles reprises par d'autres.
https://github.com/neondatabase
[^] # Re: Suite du dégraissage du mammouth
Posté par wilk . En réponse au journal Google vire son équipe Python aux US et délocalise en Allemagne.. Évalué à 6 (+4/-0).
Je me souviens un jour en allant montrer tout content la nouvelle version à l'utilisatrice qui allait ainsi "gagner du temps". Elle m'a regardé bizarrement et m'a dit "et je vais faire quoi moi du coup maintenant ?"… Une entreprise moyenne, familiale…
# Résumé
Posté par wilk . En réponse au lien Postgresql en tant que journal de transactions. Évalué à 5 (+3/-0).
Le fait de se baser sur les journaux de transaction permet sans dupliquer les données et de manière quasiment instantanée de :
- Créer des branches indépendantes
- Lancer des requêtes à un instant antérieur (en créant une branche de manière transparente)
- Lancer un read-replica
C'est incroyablement pratique en dev et à priori très résilient en prod (à vérifier à l'usage…).
Il y a eu quantité d'article de blog sur leur infra mais celui-là me semble particulièrement pédagogique.
L'infra est codée en Rust et la partie qui concerne spécifiquement le moteur est libre.
[^] # Re: Ça commence à bien faire
Posté par wilk . En réponse au journal Epidémie de Fraudes : Où l’on reparle de l’HCQ.. Évalué à 2 (+0/-0).
Ca montre bien que c'est pas faute d'avoir essayé !
[^] # Re: Ça commence à bien faire
Posté par wilk . En réponse au journal Epidémie de Fraudes : Où l’on reparle de l’HCQ.. Évalué à 6 (+5/-1).
Le nombre d'interventions montre surtout qu'on a beaucoup de compassion pour un membre de notre communauté qu'on aimerait bien aider et qu'on aurait peine à rejeter.
[^] # Re: Ça commence à bien faire
Posté par wilk . En réponse au journal Epidémie de Fraudes : Où l’on reparle de l’HCQ.. Évalué à 3 (+1/-0).
1ère règle de modération :
Éviter les doublons
CQFD
[^] # Re: Ça commence à bien faire
Posté par wilk . En réponse au journal Epidémie de Fraudes : Où l’on reparle de l’HCQ.. Évalué à 2 (+1/-1).
D'autant plus qu'on pourrait toujours lui laisser poster des journaux sur Emacs. En compensation. Par exemple.
[^] # Re: Excellent !
Posté par wilk . En réponse au journal Epidémie de Fraudes : Où l’on reparle de l’HCQ.. Évalué à 8 (+7/-1).
Et bien soit, rdv dans 20 ou 30 ans. Disons 50 pour être sûr.
# Merci, au revoir.
Posté par wilk . En réponse au journal Epidémie de Fraudes : Où l’on reparle de l’HCQ.. Évalué à 10 (+13/-2).
Merci pour ces informations, on a tout lu, on est tous convaincus. Mission accomplie. Tu peux maintenant aller informer d'autres congénères, nous c'est bon, c'est fait.
Il faudrait par contre supprimer ce journal au plus vite parce que vu la puissance de ce complot il ne faudrait pas qu'on en subisse les représailles maintenant qu'on l'a mis à jour.
[^] # Re: Scrapping ?
Posté par wilk . En réponse au lien 43 millions de comptes France-Travail potentiellement compromis. Évalué à 5 (+3/-0).
Es-tu confiant que ton commentaire initial ne va pas se retrouver planqué dans les archives de linuxfr ?
[^] # Re: Scrapping ?
Posté par wilk . En réponse au lien 43 millions de comptes France-Travail potentiellement compromis. Évalué à 4 (+2/-0).
Pas tant que ça, ça fait 1 par seconde fiche par fiche pendant un peu plus d'un an.
Il peut y avoir des pages de type listing, des exports et autres, ça peut aller très vite et ça reste très loin d'un ddos donc indétectable si ça n'est pas prévu.
# Scrapping ?
Posté par wilk . En réponse au lien 43 millions de comptes France-Travail potentiellement compromis. Évalué à 4 (+3/-1).
Ca me semble tellement facile de faire du scrapping sur ce genre de données vu que n'importe quel employé a accès aux fiches.
Quel serait la parade ? Tracer et limiter le nombre de consultations par utilisateur ?
# Je m'est trompé de lien
Posté par wilk . En réponse au lien Les conséquences du DMA pour les Web Apps. Évalué à 4 (+2/-0). Dernière modification le 07 mars 2024 à 14:28.
https://open-web-advocacy.org/blog/the-digital-markets-act-is-in-force-what-happens-now/
(Ou un modo supprime/remplace le premier lien ?)
# Par ici la sortie
Posté par wilk . En réponse au lien Le Digital Markets Act entre en vigueur aujourd’hui. Évalué à 5 (+3/-0).
https://aws.amazon.com/fr/blogs/aws/free-data-transfer-out-to-internet-when-moving-out-of-aws/
https://cloud.google.com/blog/products/networking/eliminating-data-transfer-fees-when-migrating-off-google-cloud
Tu veux partir ? Chiche !
[^] # Re: Trop de messageries
Posté par wilk . En réponse au lien Le Digital Markets Act entre en vigueur aujourd’hui. Évalué à 5 (+3/-0).
La blague c'est quand ils sortent l'argument de la sécurité pour freiner.
Mais comme aurait dit Coluche, il suffirait que les gens ne les utilisent pas pour que ces messageries propriétaires disparaissent.
[^] # Re: Subventionné ?
Posté par wilk . En réponse au lien Mistral perdant. Évalué à 8 (+6/-0).
La startup en question n'ayant jamais perçu de RSA ces obligations sont nulles et non avenues.
# Boycottons les sites avec de la pub
Posté par wilk . En réponse au lien Merdification de Chrome anti-bloqueurs de pub. Évalué à 8 (+6/-0).
Dans un sens est-ce que les bloqueurs de pubs ne sont pas contre productifs pour mettre en avant les sites qui n'en n'ont pas (de pub) ?
A l'époque où je lisais uniquement les journaux papiers je ne me posais pas la question longtemps entre un journal avec ou sans pub.
[^] # Re: Toujours la même blague
Posté par wilk . En réponse au lien EDF - contrat avec Amazon pour gérer la planification de la maintenance des centrales nucléaires. Évalué à 2 (+0/-0).
Le problème avec OVH & Scaleway c'est quand même qu'ils n'admettent jamais qu'ils ne sont pas du tout prêt. Ce qui est tout à fait compréhensible vu qu'ils n'ont pas les mêmes moyens et aucun engagement de l'état pour les soutenir. Mais ne pas l'admettre empêche de voir les vrais problèmes et donc de chercher les bonnes solutions.
# Caddy et Go
Posté par wilk . En réponse à la dépêche L’auteur de Nginx enfourche le proprio. Évalué à 4 (+4/-2).
Pour les besoins simples (ou pas ?) Caddy est une bonne alternative.
Pour les besoins encore plus simples ou beaucoup plus compliqués on peut coder un proxy en Go avec une qualité de prod sans dépendances extérieures. C'est fait pour j'ai envie de dire…