wilk a écrit 1405 commentaires

Surtout si on jette le panier dans les nuages en espérant qu'il y reste bien accroché !

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

https://neon.tech/blog/architecture-decisions-in-neon

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.

https://github.com/neondatabase

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.

Personnellement j’ai perdu...

Ca montre bien que c'est pas faute d'avoir essayé !

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.

1ère règle de modération :

Éviter les doublons

CQFD

D'autant plus qu'on pourrait toujours lui laisser poster des journaux sur Emacs. En compensation. Par exemple.

Dans 20 ou 30 ans ce sera plus apaisé pour en discuter.
là le débat n'est pas possible en l'etat

Et bien soit, rdv dans 20 ou 30 ans. Disons 50 pour être sûr.

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.

Es-tu confiant que ton commentaire initial ne va pas se retrouver planqué dans les archives de linuxfr ?

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 ?

https://open-web-advocacy.org/blog/the-digital-markets-act-is-in-force-what-happens-now/

(Ou un modo supprime/remplace le premier lien ?)

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 !

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.

La startup en question n'ayant jamais perçu de RSA ces obligations sont nulles et non avenues.

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