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 …
j'ai de la chance, depuis 7ans c'est moi le patron. Et avant ça j'ai lutté et j'ai gagné. Enfin je me suis fait virer. En un sens j'ai gagné je dirais.
On a donc depuis le tout début des années 2000: i3(essentiellement gnome jusqu'en 2014 en vrai), gnome-terminal, une debian (depuis la 2.0), vim pour le python et le reste, jupyter pour la datascience et firefox. C'est bien tout et c'est bien suffisant.
Ah oui, j'ajouterai discord. J'ai réussi à mettre tous mes clients et j'en suis très content. Pour le chat, la visio le partage d'écran c'est top.
c'est tout pour moi. Je compatis avec ceux dans les grosses boites à qui on impose des outils qu'ils n'aiment pas. Quand je dois utiliser xcode pour compiler mes apps mobile je pleure des larmes de sangs. Heureusement fastlane est la.
Pour les limaces : arrêter de tondre son jardin comme un green de golf. Plus simplement, laisser des endroits pour que les hérissons viennent s'installer. Et pouf, plus de limace. Ça marche aussi avec les canards, et eux on peut les mangers.
Globalement pour que le jardin marche la bonne solution est de laisser faire et d'apprendre à apprécier ce qu'il se passe. Ou je suis actuellement j'ai une vigne qui est super pote avec un chêne. C'est bizarre mais ça l'air de leur convenir. Alors pour ramasser le raisin il faut une échelle :). Mais sans absolument rien faire j'ai mes 15/20kg de raisin chaque année. Bien plus que ce que je peux en manger.
En tout cas code libre et permaculture ont l'air de bien s'entendre. J'aime bien ca.
Je dirais que du bon code dans un langage c'est l'utiliser de la manière dont il a été pensé. Ou pas d'ailleurs.
J'ai le sentiment que python a été pensé. En tout les cas c'est ce que je ressens quand je m'en sers. Rien n'est frustrant. Tout vient bien. Bin ok sauf le moteur de regexp que je trouve trop complexe.
A contrario je n'ai pas l'impression que Java ait été pensé mais que c'est plus un mille-feuille résultats d'années de baston entre entreprises qui veulent rajouter leur truc à eux par dessus. Et dans ce cas la faire du bon java c'est savoir faire le tri dans tout ce bordel.
ce n'est pas ce que je dis. Si je me suis mal exprimé j'en suis désolé. Mon propos est de dire que il me semble que pour faire du bon java il faut être très bon. Pour faire du bon python il ne me semble pas que ce soit nécessaire. Je ne crois pas qu'il y est un PEP 20 en java ;)
un outil intégré pour de la gestion administrative dans un secteur particulier. Paye, compta etc. En gros ça gère la paperasse des entreprises d'un secteur bien particulier. C'est très complet comme application. D’où la taille je pense. Mais quand même.
Je ne dis pas que c'est plus simple. Je dis que avec un seul langage je peux aussi faire ca. Et question performance et fonctionnalités c'est parfait vu que c'est la lib en c qui est utilisée.
Pour Java je dirais que ca illustre le niveau qu'il faut avoir pour rester propre concis et efficace.
[^] # 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 …
# pdm
Posté par oau . En réponse à la dépêche Environnement moderne de travail Python. Évalué à 1.
je suis récemment passé de pypenv à pdm et j'en suis content. Conda c'est une bête d'usine à gaz. Pdm c'est bien :)
# Rien changé depuis plus de 20ans
Posté par oau . En réponse au sondage Développeur Libristes, oui ! mais macOS, Visual Studio et Azure ?. Évalué à 2.
j'ai de la chance, depuis 7ans c'est moi le patron. Et avant ça j'ai lutté et j'ai gagné. Enfin je me suis fait virer. En un sens j'ai gagné je dirais.
On a donc depuis le tout début des années 2000: i3(essentiellement gnome jusqu'en 2014 en vrai), gnome-terminal, une debian (depuis la 2.0), vim pour le python et le reste, jupyter pour la datascience et firefox. C'est bien tout et c'est bien suffisant.
Ah oui, j'ajouterai discord. J'ai réussi à mettre tous mes clients et j'en suis très content. Pour le chat, la visio le partage d'écran c'est top.
c'est tout pour moi. Je compatis avec ceux dans les grosses boites à qui on impose des outils qu'ils n'aiment pas. Quand je dois utiliser xcode pour compiler mes apps mobile je pleure des larmes de sangs. Heureusement fastlane est la.
[^] # Re: J'étale ma permacuculture
Posté par oau . En réponse au journal J'ai mangé une pomme. Évalué à 2.
Pour les limaces : arrêter de tondre son jardin comme un green de golf. Plus simplement, laisser des endroits pour que les hérissons viennent s'installer. Et pouf, plus de limace. Ça marche aussi avec les canards, et eux on peut les mangers.
Globalement pour que le jardin marche la bonne solution est de laisser faire et d'apprendre à apprécier ce qu'il se passe. Ou je suis actuellement j'ai une vigne qui est super pote avec un chêne. C'est bizarre mais ça l'air de leur convenir. Alors pour ramasser le raisin il faut une échelle :). Mais sans absolument rien faire j'ai mes 15/20kg de raisin chaque année. Bien plus que ce que je peux en manger.
En tout cas code libre et permaculture ont l'air de bien s'entendre. J'aime bien ca.
[^] # Re: Flutter et le libre...
Posté par oau . En réponse à la dépêche Changeons ces logiciels open source qui nous espionnent. Évalué à 2.
Pourquoi pas nuxtjs ? C'est français en plus
[^] # Re: J'aime pyhton car
Posté par oau . En réponse à la dépêche Python dépasse Java en popularité selon l’indice TIOBE de novembre. Évalué à -2.
Je dirais que du bon code dans un langage c'est l'utiliser de la manière dont il a été pensé. Ou pas d'ailleurs.
J'ai le sentiment que python a été pensé. En tout les cas c'est ce que je ressens quand je m'en sers. Rien n'est frustrant. Tout vient bien. Bin ok sauf le moteur de regexp que je trouve trop complexe.
A contrario je n'ai pas l'impression que Java ait été pensé mais que c'est plus un mille-feuille résultats d'années de baston entre entreprises qui veulent rajouter leur truc à eux par dessus. Et dans ce cas la faire du bon java c'est savoir faire le tri dans tout ce bordel.
[^] # Re: J'aime pyhton car
Posté par oau . En réponse à la dépêche Python dépasse Java en popularité selon l’indice TIOBE de novembre. Évalué à 0.
ce n'est pas ce que je dis. Si je me suis mal exprimé j'en suis désolé. Mon propos est de dire que il me semble que pour faire du bon java il faut être très bon. Pour faire du bon python il ne me semble pas que ce soit nécessaire. Je ne crois pas qu'il y est un PEP 20 en java ;)
[^] # Re: Description française
Posté par oau . En réponse au lien Série de cours en ligne du CERN sur l'informatique quantique. Évalué à 2.
seulement le premier cours est disponible. Grosse déception. Alors je vous mets ma liste de podcast sur le sujet.
https://www.franceculture.fr/emissions/la-methode-scientifique/la-methode-scientifique-emission-du-mercredi-16-octobre-2019
https://www.franceculture.fr/emissions/science-publique/l-ordinateur-est-il-en-train-de-devenir-quantique
https://www.franceculture.fr/emissions/la-methode-scientifique/superordinateurs-y-a-t-il-une-limite-au-calcul-numerique
https://www.franceculture.fr/emissions/la-conversation-scientifique/aurons-nous-un-jour-des-ordinateurs-quantiques
https://www.franceculture.fr/emissions/la-methode-scientifique/ordinateur-quantique-le-dernier-pas-avant-la-singularite
[^] # Re: J'aime pyhton car
Posté par oau . En réponse à la dépêche Python dépasse Java en popularité selon l’indice TIOBE de novembre. Évalué à 1.
un outil intégré pour de la gestion administrative dans un secteur particulier. Paye, compta etc. En gros ça gère la paperasse des entreprises d'un secteur bien particulier. C'est très complet comme application. D’où la taille je pense. Mais quand même.
[^] # Re: J'aime pyhton car
Posté par oau . En réponse à la dépêche Python dépasse Java en popularité selon l’indice TIOBE de novembre. Évalué à 1.
Je ne dis pas que c'est plus simple. Je dis que avec un seul langage je peux aussi faire ca. Et question performance et fonctionnalités c'est parfait vu que c'est la lib en c qui est utilisée.
Pour Java je dirais que ca illustre le niveau qu'il faut avoir pour rester propre concis et efficace.