C'est une question difficile. Et encore mon fils est petit. Il n'a que 9ans. Dès le collège ça deviendra encore plus compliqué parce que pour le moment il n'y a pas dans son école d'interaction sociale via les réseaux.
Pour le moment j'ai réussi à faire en sorte que l'écran, quel qu'il soit (tv, console, pc, téléphone) soit une activité que l'on fait ensemble. On choisit un film, une série, un jeu vidéo et on le fait ensemble. On joue à ingress ou à pokémon go sur le téléphone mais dehors.
De mon point de vue le problème n'est pas l'écran en lui-même mais plutôt ce que l'on en fait. Si c'est pour les mettre devant loft story, tfou ou jouer à gta à 10ans parce que comme ca ils sont tranquilles c'est non. Si c'est pour faire un truc ensemble et de leur âge (it takes two sur ps4, porco rosso ou astérix et cléopatre) c'est oui.
Quand il joue seul il fait du lego, du découpage, il invente des jeux, crée des labyrinthes bref, quand il est seul il n'y a pas d'écran.
Seule entorse, une fois la table mise il a 20min pour regarder un épisode de pokémon pendant que le repas cuit.
je n'aime pas trop faire ma pub ici, ou ailleurs d'ailleurs. On est pas particulièrement en recherche de client en ce moment. Et surtout on cherche d'abord des gens sympas avec qui bosser. Mais on peut discuter sur oau[at]nmlq.fr
c'est ce que je faisais avant avec des baies de disques. Et bien c'est un boulot à plein temps et à part entière. Sans compte le prix du hardware et l'impossibilité de vraiment savoir ce qu'il se passe dans la baie.
depuis que je fais du ceph le storage j'y pense plus.
Posté par oau .
En réponse au journal Le cloud ça scale bien.
Évalué à 1.
Dernière modification le 15 novembre 2022 à 11:32.
la couche base de données avec N instances permet de basculer un master vers un réplica en cas de perte du master plus rapidement que de démonter un fs et le remonter ailleurs puis de relancer la base de données. Ca permet aussi de répartir les lectures sur plusieurs instances de la db
la couche ceph permet d'avoir une solidité plus importante qu'un simple fs et permet de remonter un disque d'une machine à une autre.
Donc :
si je perd un master db je bascule sur un réplica. C'est rapide, pratiquement pas de coupure
je peux répartir mes lectures sur plusieurs machine
quoi qu'il arrive je retrouve toujours mes données sur le disque tenu par ceph, modulo le temps de démonter le fs puis de le remonter ailleurs et de relancer la db.
Tu as raison. Mais avec k8s c'est plus simple. Je ne ne gère pas l'allocation des noeuds du cluster pg sur les nodes du cluster k8s, ni la création des lv et des fs. Je n'ai pas besoin de savoir quelle instance est où ni sur quel fs etc.
Si k8s à besoin de bouger un noeud de la base sur un autre noeud du cluster k8s c'est possible. Que ce soit pour pg ou n'importe quoi d'autre d'ailleurs.
D'autres part toute la conf de pg est dans un yaml dans ma cicd. Nombre de noeud du cluster pg, user, db, config de la base, la taille des disques, le backup, le streaming des wal dans S3, le type de réplication que je veux pour chaque noeud. Je peux créer une base à partir d'une autre, à un instant t juste avec un yaml. Parfait pour tester une version de dev avec des vraies données.
Bref pour pg, comme pour tout le reste j'ai de l'infrastructure as code. En vrai techniquement ça change rien. Mais en standardisant et en automatisant à outrance on peut gérer énormément de service.
La plupart de nos clients sont des applications en SaaS ou des algorithmes de traitement de données. J'ai une stack redis, dB, front www JS et serveur d'applications backend genre python,ruby ou java. J'injecte l'id du client et le type de plateforme que je veux. Production, staging, dev, une branche en particulier etc. Et je déploy via la cicd.
Que j'ai 10 fois l'application, ou 10 000 fois ça change rien. K8s se débrouille pour tout déployer en fonction des contraintes que je lui donne. Essentiellement de ne pas démarrer deux noeuds de base pg dans la même zone.
Quand c'est des algorithmes de traitement de données je peux avoir 10 algorithmes différents qui tournent en parallèle sur les mêmes données (merci Kafka) et qui remplissent 10 cluster pg différents. Juste en me basant dans ce cas là sur le nom de la branche git. En vrai on fait l'administration pratiquement uniquement avec git. Et c'est la cicd qui gère.
Enfin quand je n'ai plus de place ou plus de ressources sur le cluster, j'ajoute des serveurs.
Posté par oau .
En réponse au journal Le cloud ça scale bien.
Évalué à 4.
Dernière modification le 13 novembre 2022 à 22:47.
Oui ceph tient très bien la charge et oui j'ai des pg et des MySQL dessus. Environ 900 pg et 150 MySQL. Par contre attention la différence de performance entre un nvme et ceph est énorme. Il faut donc bien configurer pg, ceph et bien faire attention aux requêtes que l'on fait.
Dans les cas extrêmes on peut repasser directement sur les disques locaux. Tout en gardant le tout dans k8s. On perd juste un peu de flexibilité. Les pods étant fixés sur un node particulier.
Ceph fournit aussi un fs de type S3 très utile pour le traitement de données.
Un post de fichiers dans S3 trigger une notification dans Kafka. Ensuite les données sont traités. Le gros avantage c'est que tout se fait via k8s par l'intermédiaire de knative et donc de config yaml directement dans la cicd.
Oui effectivement c'est aussi notre métier. Mais il ne faut pas croire que pour gérer ton infra, gafam ou pas, k8s ou pas, tu n'as pas besoin de compétences. La prod c'est un métier.
Ensuite oui les gafams sont intéressants quand tu ne t'en sers pas tout le temps.
Mais c'est un piège. Parce que si au début tu ne t'en sers pas tout le temps ça finira par arriver avec la croissance de ta production et c'est la que les coûts explose.
En avant vente on présente notre modèle comme un log. Plus cher au début mais dont la croissance sera un log. Là où chez un gafam c'est au mieux linéaire. Le plus souvent exponentiel. Surtout si on utilise beaucoup de leurs services à la demande.
Le monitoring c'est mon métier depuis plus de 20ans et j'ai mes outils. Effectivement monitorer k8s avec les outils officiel est une plaie.
Pour les mises à jour franchement j'ai connu bien, bien pire. Websphere, oracle et même redhat c'était bien pénible. Avec le temps c'est devenu une routine de faire les maj. Et ça se passe plutôt bien.
Concernant les mises à jour des versions de l'API des ressources, kubernetes te préviens longtemps avant que ça va changer et vraiment tu as tout le temps d'anticiper. Et c'est souvent pas grand choses.
Je fais de l'administration de serveur Linux depuis la fin des années 90 et de la prod depuis le début des années 2000. On a aujourd'hui des outils qui marchent tellement bien et tellement simple d'utilisation que c'est devenu anecdotique de faire l'administration. Je pense à postgres ou à ceph par exemple. Un vrai bonheur. En plus de k8s bien sûr.
On installe tout avec l'API d'ovh puis avec des playbook ansible. Il faut moins d'une heure pour ajouter un noeud avec tout le confort moderne. Monitoring, sssd, LDAP pour k8s, conf réseau (vlan k8s, ceph, adm, monitoring, backup, vpn vive le vrack) et ajouter le nouveau noeud dans ceph. En vrai le plus long c'est d'attendre la disponibilité des serveurs et la synchronisation de ceph. Sur les grosses machines il faut des fois plusieurs mois pour les avoir.
Surtout pour le client le coût est connu à l'avance. J'ai migré des clients de chez gcp avec des factures qui pouvait varier de 50% d'un mois sur l'autre. Et chez les gafams il y a aucun support malgré les tarifs exorbitants. T'es planté ? débrouille toi.
Alors qu'est chez nous, avec le prix de la machine plus notre coût d'administration on reste moins cher d'environ 50% par rapport à gcp ou aws. On ne fait pas de azure.
Je pense sincèrement être arrivé sur un plateau qui devait tenir un moment. Je n'ai besoin de rien de plus. OVH, Debian, k8s, ceph, vrack, Kafka, gitlab, python, nuxtjs et les quelques outils de glue autour de ça et je dors très tranquillement.
Kubernetes sur du baremetal chez OVH c'est infiniment moins cher, non magique, avec un tarif prévisible et ça fonctionne parfaitement bien.
OVH match aussi les appels d'offres de certains secteurs économiques de plus en plus frileux à être hébergé chez les gafams.
Testé et approuvé depuis 2016 avec de plus en plus de machines.
Seul bémol la bande passante publique reste chère. Mais avec 1gbps on est quand même déjà pas mal.
Il est arrivé en 2 ans deux incidents qui ont coupé toutes ma prod pendant 2h la première fois. 15 min la seconde. Ce sont les deux seuls incidents vraiment impactant en 6ans. Problème de réseau sur le backbone qui a coupé OVH d'internet.
L'incendie de sbg n'a eut d'impact que sur les clients qui n'écoutent pas …
Installer k8s et faîtes votre cloud. Ca change la vie !
Push dans mon ceph s3 via tcp, mqtt, http, sftp, ftp qui push dans mon kafka et j'ai mes petits bot knative qui mangent les data qui arrivent au fil de l'eau. Tout ca avec un minimum de config. Honnêtement l'infra ça marche tellement bien aujourd'hui, que en tant qu'admin sys on s'ennuie pas mal.
Rien. C'est juste "bien", de son point de vue. Tout le monde son propre patron, une application. C'est la liberté du marché, la startup nation. "C'est bien". Ça va pas plus loin. Et depuis il nous a bien montré que sa réflexion ne va jamais bien loin. C'est un bourgeois capitaliste. Il défend son idéologie. Ses intérêts de classe. Rien de nouveau.
Justement ce midi j'expliquais comment Edf vend son électricité moins chère à ses concurrents. Question légitime de mon interlocutrice : Pourquoi ? C'est complétement con. Oui, ca l'est. Mais c'est la liberté du marché. Alors "c'est bien". Et ca vaut pour tout le reste, la santé, l'école, les autoroutes, les avions etc. On a quand même vendu Alstom aux ricains. Pour en racheter un bon 8 ans plus tard. Ils l'ont vendu parce que "c'est bien" de vendre des trucs. Pourquoi, comment, à qui ? Rien à faire.
et manifestement ce n'est pas le leur …. bref. Tant mieux j'aurais toujours du travail.
Et oui pg c'est vraiment une tuerie. Et non un sharedfs ce n'est vraiment pas une bonne idée pour faire tourner une db. Ils essaient de contourner des problèmes qu'ils se créent tout seul en allant chez aws.
Pour info ma solution pour gérer beaucoup de données, beaucoup en vrai : kafka, k8s, ceph et bien sur pg. Actuellement j'ai 800 pg en prod qui ingère plusieurs To de data chaque jour. Mais aucune de mes bases ne fait plus de 1To. C'est la limite que je me suis fixé. 1to en 10Gbps ça se copie rapidement. Et 10Gbps en 2022 c'est très courant. Et 25 ça arrive vite.
Pour finir ruby …. pour traiter des données, ce n'est pas la meilleure des idées. Bref. Oui c'est flippant. Et ca fait pas sérieux. Vraiment.
Enfin ce genre de présentation sans mettre aucun cout en face, ça n'a strictement aucun intérêt.
J'ai vécu à Paris de 2000 à 2008. Au début il n'y avait pas de TGV entre marseille et paris. Mais à partir de 2001 oui il me semble. Bref. J'étais étudiant et je faisais les a/r paris marseille très souvent. Plusieurs fois par mois. (Oui la vie à paris a été un véritable calvaire.) J'ai JAMAIS eu de gros ennuis. Peut être de temps en temps un retard d'un heure, une heure trente. Qui peut être chiant quand on arrive après 1h du matin à Paris. Mais habitant pas trop loin (porte dorée) de gare de lyon je pouvais rentrer à pied.
Tout ça pour dire que le meilleur moyen de tuer son chien c'est de dire qu'il a la rage. Pour avoir aussi pas mal vécu en Angleterre, je peux vous assurer que la privatisation du train est pas une super idée …
# Pas simple
Posté par oau . En réponse au sondage Les zécrans de vos enfants. Évalué à 6.
C'est une question difficile. Et encore mon fils est petit. Il n'a que 9ans. Dès le collège ça deviendra encore plus compliqué parce que pour le moment il n'y a pas dans son école d'interaction sociale via les réseaux.
Pour le moment j'ai réussi à faire en sorte que l'écran, quel qu'il soit (tv, console, pc, téléphone) soit une activité que l'on fait ensemble. On choisit un film, une série, un jeu vidéo et on le fait ensemble. On joue à ingress ou à pokémon go sur le téléphone mais dehors.
De mon point de vue le problème n'est pas l'écran en lui-même mais plutôt ce que l'on en fait. Si c'est pour les mettre devant loft story, tfou ou jouer à gta à 10ans parce que comme ca ils sont tranquilles c'est non. Si c'est pour faire un truc ensemble et de leur âge (it takes two sur ps4, porco rosso ou astérix et cléopatre) c'est oui.
Quand il joue seul il fait du lego, du découpage, il invente des jeux, crée des labyrinthes bref, quand il est seul il n'y a pas d'écran.
Seule entorse, une fois la table mise il a 20min pour regarder un épisode de pokémon pendant que le repas cuit.
# Merci
Posté par oau . En réponse au journal RPCDataloader: chargement et pré-traitement de données distribué pour l'IA. Évalué à 1.
Pour la découverte, ici on utilise knative et Kafka pour faire ça. J'avoue ça juste marche parfaitement. Mais je vais quand même regarder ça. Merci.
[^] # Re: Vim
Posté par oau . En réponse au journal VSCodium & support python : pyright. Évalué à 3.
Vim c'est bien
[^] # Re: c'est pour ca que
Posté par oau . En réponse au journal Comment j'ai foutu en l'air une partie de notre prod (et comment on l'a remise sur pieds). Évalué à 3.
c'était le sens de ces mots :)
# c'est pour ca que
Posté par oau . En réponse au journal Comment j'ai foutu en l'air une partie de notre prod (et comment on l'a remise sur pieds). Évalué à 8.
et on teste les backup
ceph + borg
[^] # Re: Alternative ?
Posté par oau . En réponse au journal scratch_manager: gestionnaire de mise en cache de jeux de données. Évalué à 1. Dernière modification le 17 décembre 2022 à 19:11.
Ceph , cephfs et S3 c'est excellent pour faire ça. J'ai le même genre de problèmatique que j'ai résolu avec une stack ceph + k8s + kafka.
Effectivement ça demande des compétences mais quand il faut passer en production un pipeline de traitement de données il faut des compétences.
[^] # Re: Réponse
Posté par oau . En réponse au journal Adieu Grammalecte ?. Évalué à 2.
des bisous des bisous des bisous :)
[^] # Re: cloud baremetal
Posté par oau . En réponse au journal Le cloud ça scale bien. Évalué à 1.
Pas sûr 3 DC dans 3 zones différentes. Si ta baie cramé tu perds tout.
[^] # Re: cloud baremetal
Posté par oau . En réponse au journal Le cloud ça scale bien. Évalué à 2.
Certes mais ton disque que tu exposes en iscsi est sur une machine. Si cette machine disparait tu perds ton disque.
L'avantage de ceph est que ton disque (rbd, nfs, iscsi, samba, whatever) et toujours disponible tant que ton cluster fonctionne.
Avec le setup qu'on fait on peut perdre les deux tiers des serveurs sans perdre de données. Chaque block est répliqué trois fois.
[^] # Re: Et pour un simple utilisateur ?
Posté par oau . En réponse au journal Le cloud ça scale bien. Évalué à 1.
hello
je n'aime pas trop faire ma pub ici, ou ailleurs d'ailleurs. On est pas particulièrement en recherche de client en ce moment. Et surtout on cherche d'abord des gens sympas avec qui bosser. Mais on peut discuter sur oau[at]nmlq.fr
[^] # Re: Et pour un simple utilisateur ?
Posté par oau . En réponse au journal Le cloud ça scale bien. Évalué à 0.
Bonjour,
c'est très exactement ce nous faisons :)
oau
[^] # Re: cloud baremetal
Posté par oau . En réponse au journal Le cloud ça scale bien. Évalué à 2.
c'est ce que je faisais avant avec des baies de disques. Et bien c'est un boulot à plein temps et à part entière. Sans compte le prix du hardware et l'impossibilité de vraiment savoir ce qu'il se passe dans la baie.
depuis que je fais du ceph le storage j'y pense plus.
[^] # Re: cloud baremetal
Posté par oau . En réponse au journal Le cloud ça scale bien. Évalué à 1. Dernière modification le 15 novembre 2022 à 11:32.
la couche base de données avec N instances permet de basculer un master vers un réplica en cas de perte du master plus rapidement que de démonter un fs et le remonter ailleurs puis de relancer la base de données. Ca permet aussi de répartir les lectures sur plusieurs instances de la db
la couche ceph permet d'avoir une solidité plus importante qu'un simple fs et permet de remonter un disque d'une machine à une autre.
Donc :
si je perd un master db je bascule sur un réplica. C'est rapide, pratiquement pas de coupure
je peux répartir mes lectures sur plusieurs machine
quoi qu'il arrive je retrouve toujours mes données sur le disque tenu par ceph, modulo le temps de démonter le fs puis de le remonter ailleurs et de relancer la db.
[^] # Re: cloud baremetal
Posté par oau . En réponse au journal Le cloud ça scale bien. Évalué à 2.
Tu as raison. Mais avec k8s c'est plus simple. Je ne ne gère pas l'allocation des noeuds du cluster pg sur les nodes du cluster k8s, ni la création des lv et des fs. Je n'ai pas besoin de savoir quelle instance est où ni sur quel fs etc.
Si k8s à besoin de bouger un noeud de la base sur un autre noeud du cluster k8s c'est possible. Que ce soit pour pg ou n'importe quoi d'autre d'ailleurs.
D'autres part toute la conf de pg est dans un yaml dans ma cicd. Nombre de noeud du cluster pg, user, db, config de la base, la taille des disques, le backup, le streaming des wal dans S3, le type de réplication que je veux pour chaque noeud. Je peux créer une base à partir d'une autre, à un instant t juste avec un yaml. Parfait pour tester une version de dev avec des vraies données.
Bref pour pg, comme pour tout le reste j'ai de l'infrastructure as code. En vrai techniquement ça change rien. Mais en standardisant et en automatisant à outrance on peut gérer énormément de service.
La plupart de nos clients sont des applications en SaaS ou des algorithmes de traitement de données. J'ai une stack redis, dB, front www JS et serveur d'applications backend genre python,ruby ou java. J'injecte l'id du client et le type de plateforme que je veux. Production, staging, dev, une branche en particulier etc. Et je déploy via la cicd.
Que j'ai 10 fois l'application, ou 10 000 fois ça change rien. K8s se débrouille pour tout déployer en fonction des contraintes que je lui donne. Essentiellement de ne pas démarrer deux noeuds de base pg dans la même zone.
Quand c'est des algorithmes de traitement de données je peux avoir 10 algorithmes différents qui tournent en parallèle sur les mêmes données (merci Kafka) et qui remplissent 10 cluster pg différents. Juste en me basant dans ce cas là sur le nom de la branche git. En vrai on fait l'administration pratiquement uniquement avec git. Et c'est la cicd qui gère.
Enfin quand je n'ai plus de place ou plus de ressources sur le cluster, j'ajoute des serveurs.
[^] # Re: cloud baremetal
Posté par oau . En réponse au journal Le cloud ça scale bien. Évalué à 4. Dernière modification le 13 novembre 2022 à 22:47.
Oui ceph tient très bien la charge et oui j'ai des pg et des MySQL dessus. Environ 900 pg et 150 MySQL. Par contre attention la différence de performance entre un nvme et ceph est énorme. Il faut donc bien configurer pg, ceph et bien faire attention aux requêtes que l'on fait.
Dans les cas extrêmes on peut repasser directement sur les disques locaux. Tout en gardant le tout dans k8s. On perd juste un peu de flexibilité. Les pods étant fixés sur un node particulier.
Ceph fournit aussi un fs de type S3 très utile pour le traitement de données.
Un post de fichiers dans S3 trigger une notification dans Kafka. Ensuite les données sont traités. Le gros avantage c'est que tout se fait via k8s par l'intermédiaire de knative et donc de config yaml directement dans la cicd.
[^] # Re: cloud baremetal
Posté par oau . En réponse au journal Le cloud ça scale bien. Évalué à 7.
Oui effectivement c'est aussi notre métier. Mais il ne faut pas croire que pour gérer ton infra, gafam ou pas, k8s ou pas, tu n'as pas besoin de compétences. La prod c'est un métier.
Ensuite oui les gafams sont intéressants quand tu ne t'en sers pas tout le temps.
Mais c'est un piège. Parce que si au début tu ne t'en sers pas tout le temps ça finira par arriver avec la croissance de ta production et c'est la que les coûts explose.
En avant vente on présente notre modèle comme un log. Plus cher au début mais dont la croissance sera un log. Là où chez un gafam c'est au mieux linéaire. Le plus souvent exponentiel. Surtout si on utilise beaucoup de leurs services à la demande.
[^] # Re: cloud baremetal
Posté par oau . En réponse au journal Le cloud ça scale bien. Évalué à 9.
Le monitoring c'est mon métier depuis plus de 20ans et j'ai mes outils. Effectivement monitorer k8s avec les outils officiel est une plaie.
Pour les mises à jour franchement j'ai connu bien, bien pire. Websphere, oracle et même redhat c'était bien pénible. Avec le temps c'est devenu une routine de faire les maj. Et ça se passe plutôt bien.
Concernant les mises à jour des versions de l'API des ressources, kubernetes te préviens longtemps avant que ça va changer et vraiment tu as tout le temps d'anticiper. Et c'est souvent pas grand choses.
Je fais de l'administration de serveur Linux depuis la fin des années 90 et de la prod depuis le début des années 2000. On a aujourd'hui des outils qui marchent tellement bien et tellement simple d'utilisation que c'est devenu anecdotique de faire l'administration. Je pense à postgres ou à ceph par exemple. Un vrai bonheur. En plus de k8s bien sûr.
On installe tout avec l'API d'ovh puis avec des playbook ansible. Il faut moins d'une heure pour ajouter un noeud avec tout le confort moderne. Monitoring, sssd, LDAP pour k8s, conf réseau (vlan k8s, ceph, adm, monitoring, backup, vpn vive le vrack) et ajouter le nouveau noeud dans ceph. En vrai le plus long c'est d'attendre la disponibilité des serveurs et la synchronisation de ceph. Sur les grosses machines il faut des fois plusieurs mois pour les avoir.
Surtout pour le client le coût est connu à l'avance. J'ai migré des clients de chez gcp avec des factures qui pouvait varier de 50% d'un mois sur l'autre. Et chez les gafams il y a aucun support malgré les tarifs exorbitants. T'es planté ? débrouille toi.
Alors qu'est chez nous, avec le prix de la machine plus notre coût d'administration on reste moins cher d'environ 50% par rapport à gcp ou aws. On ne fait pas de azure.
Je pense sincèrement être arrivé sur un plateau qui devait tenir un moment. Je n'ai besoin de rien de plus. OVH, Debian, k8s, ceph, vrack, Kafka, gitlab, python, nuxtjs et les quelques outils de glue autour de ça et je dors très tranquillement.
[^] # Re: cloud baremetal
Posté par oau . En réponse au journal Le cloud ça scale bien. Évalué à 8.
Le client qui prend toute ses machines sur sbg alors qu'on lui dit d'en prendre une sur Roubaix une sur Gravelines et une sur sbg.
# cloud baremetal
Posté par oau . En réponse au journal Le cloud ça scale bien. Évalué à 6.
Kubernetes sur du baremetal chez OVH c'est infiniment moins cher, non magique, avec un tarif prévisible et ça fonctionne parfaitement bien.
OVH match aussi les appels d'offres de certains secteurs économiques de plus en plus frileux à être hébergé chez les gafams.
Testé et approuvé depuis 2016 avec de plus en plus de machines.
Seul bémol la bande passante publique reste chère. Mais avec 1gbps on est quand même déjà pas mal.
Il est arrivé en 2 ans deux incidents qui ont coupé toutes ma prod pendant 2h la première fois. 15 min la seconde. Ce sont les deux seuls incidents vraiment impactant en 6ans. Problème de réseau sur le backbone qui a coupé OVH d'internet.
L'incendie de sbg n'a eut d'impact que sur les clients qui n'écoutent pas …
Installer k8s et faîtes votre cloud. Ca change la vie !
[^] # Re: Knative, le graal.
Posté par oau . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 1.
j'avoue knative c'est bien :)
Push dans mon ceph s3 via tcp, mqtt, http, sftp, ftp qui push dans mon kafka et j'ai mes petits bot knative qui mangent les data qui arrivent au fil de l'eau. Tout ca avec un minimum de config. Honnêtement l'infra ça marche tellement bien aujourd'hui, que en tant qu'admin sys on s'ennuie pas mal.
https://medium.com/analytics-vidhya/automated-data-pipeline-using-ceph-notifications-and-kserving-5e1e9b996661
[^] # Re: utilisation ?
Posté par oau . En réponse à la dépêche Moniteur de tunnels SSH Tunnelmon en version 1.1 . Évalué à 10.
Hello
Dans ton authorizedkey tu peux limiter ce qu'il est possible de faire sur la machine de destination.
Très utile pour les scripts de backup.
[^] # Re: Rappel sur les bienfaits d'Uber
Posté par oau . En réponse au lien « Uber Files » : une plongée inédite et alarmante dans la boîte noire du lobbying. Évalué à 1.
euh non. En quoi c'est une putain d'appli ?
[^] # Re: Suivre l'argent
Posté par oau . En réponse au lien « Uber Files » : une plongée inédite et alarmante dans la boîte noire du lobbying. Évalué à 10.
Rien. C'est juste "bien", de son point de vue. Tout le monde son propre patron, une application. C'est la liberté du marché, la startup nation. "C'est bien". Ça va pas plus loin. Et depuis il nous a bien montré que sa réflexion ne va jamais bien loin. C'est un bourgeois capitaliste. Il défend son idéologie. Ses intérêts de classe. Rien de nouveau.
Justement ce midi j'expliquais comment Edf vend son électricité moins chère à ses concurrents. Question légitime de mon interlocutrice : Pourquoi ? C'est complétement con. Oui, ca l'est. Mais c'est la liberté du marché. Alors "c'est bien". Et ca vaut pour tout le reste, la santé, l'école, les autoroutes, les avions etc. On a quand même vendu Alstom aux ricains. Pour en racheter un bon 8 ans plus tard. Ils l'ont vendu parce que "c'est bien" de vendre des trucs. Pourquoi, comment, à qui ? Rien à faire.
# DBA c'est un métier
Posté par oau . En réponse au lien Doctolib présente sa base de données à Devoxx 2022 et c'est flippant. Évalué à 8.
et manifestement ce n'est pas le leur …. bref. Tant mieux j'aurais toujours du travail.
Et oui pg c'est vraiment une tuerie. Et non un sharedfs ce n'est vraiment pas une bonne idée pour faire tourner une db. Ils essaient de contourner des problèmes qu'ils se créent tout seul en allant chez aws.
Pour info ma solution pour gérer beaucoup de données, beaucoup en vrai : kafka, k8s, ceph et bien sur pg. Actuellement j'ai 800 pg en prod qui ingère plusieurs To de data chaque jour. Mais aucune de mes bases ne fait plus de 1To. C'est la limite que je me suis fixé. 1to en 10Gbps ça se copie rapidement. Et 10Gbps en 2022 c'est très courant. Et 25 ça arrive vite.
Pour finir ruby …. pour traiter des données, ce n'est pas la meilleure des idées. Bref. Oui c'est flippant. Et ca fait pas sérieux. Vraiment.
Enfin ce genre de présentation sans mettre aucun cout en face, ça n'a strictement aucun intérêt.
# Manifestement le train c'était mieux avant
Posté par oau . En réponse au journal Testons la concurrence à la concurrence à la SNCF. Évalué à 9.
J'ai vécu à Paris de 2000 à 2008. Au début il n'y avait pas de TGV entre marseille et paris. Mais à partir de 2001 oui il me semble. Bref. J'étais étudiant et je faisais les a/r paris marseille très souvent. Plusieurs fois par mois. (Oui la vie à paris a été un véritable calvaire.) J'ai JAMAIS eu de gros ennuis. Peut être de temps en temps un retard d'un heure, une heure trente. Qui peut être chiant quand on arrive après 1h du matin à Paris. Mais habitant pas trop loin (porte dorée) de gare de lyon je pouvais rentrer à pied.
Tout ça pour dire que le meilleur moyen de tuer son chien c'est de dire qu'il a la rage. Pour avoir aussi pas mal vécu en Angleterre, je peux vous assurer que la privatisation du train est pas une super idée …