pasBill pasGates a écrit 16062 commentaires

DISCLAIMER: Je bosses pour un des 3 gros clouds…

Moi je te lis, et je me dis qu'en fait, tu ne sais pas ce que c'est un cloud.

Et pourtant on est pas des manchots : l'infrastructure construite à partir de serveurs bare metal convient bien, les process sont automatisés. Alors peut-être qu'on va pas scaler en un clic mais on a de la marge et la mise en place de nouvelles ressources se fait très rapidement. À chacun sa solution.

Déjà, il n'y a aucune opposition entre bare metal et cloud, tu trouves du bare metal dans ces clouds par exemple.
Quand a scaler en un clic… Déjà si tu fais du cloud correctement c'est zero click, et tu peux avoir cela même en faisant du bare metal si tu sais ce que tu fais.

Quand je regarde comment mettre en place des services Azure/Google/Amazon, je trouve ça d'un compliqué même pour faire des choses simples comme par exemple mettre un plafond de paiement.

Mettre un plafond de paiement oui c'est compliqué.

Quand tu as une infra entière (stockage, CPU, queues, streaming, …) et que tu arrives au chiffre maximum, tu fais quoi ? Le cloud efface tes données ? Efface toute ton infrastructure ? Coupe tes connections ?

Il faut comparer des oranges aux oranges, pas des pommes.

On finit par trouver des formations, des certifications pour ne plus voir apparaitre que des DevOps en titre de poste. C'est à dire des professionnel des templates, du clic… d'une solution américaine propriétaire.

Et là tu confirmes qu'effectivement tu ne comprends rien à ce qu'est un cloud et ce qu'est un ingénieur cloud. Tu n'as visiblement jamais entendu parler des SDKs que n'importe quel ingénieur cloud utilise à longueur de journée et qui sont la base de toute infrastructure cloud. Personne à part les amateurs ne monte une infra cloud de production à coup de clic. Ce sont des ingénieurs qui comprennent comment construire une infra qui monte en charge et qui limite les couts, qui savent pourquoi il faut utiliser le service A plutôt que le service B selon le contexte et les besoins, qui savent comment gèrer les problèmes de latence, etc…

Je pense qu'ils sont en voie de disparition. Le cloud, comme une boîte noire, est en train de niveler les compétences vers le bas. Ça commence maintenant dès l'école, les dév apprennent à pusher leur code directement dans le nuage et YOLO.

Non c'est surtout toi qui ne sait pas ce qu'est un cloud et qui nous la joue vieux schnock qui critique les petits jeunes et leur technologie que tu ne comprends pas.

Après le faux reproche du scaling, ce qui vient ensuite est le taux de disponibilité des offres non cloud. Je suis agacé de me prendre systématiquement dans les dents le coup de l'incendie d'un datacenter français… Mauvaise pub effectivement mais non représentatif de la technicité qui existe encore dans notre pays

Mais ce sont des aneries cela, tu peux faire de la haute dispo dans les deux, et tu peux faire du non haute dispo dans le deux. Typiquement les gens qui ne comprennent rien au cloud et qui ne savent même pas ce qu'est une availability zone dans AWS.

Parce que ta boîte a Office 365 et pas Office 2021 ?

Ce type, je l'ai vu monter sur la scène devant un millier de personnes sous les huées, puis en redescendre 10 minutes plus tard sous les applaudissement réels et sincères.

Bref ce que tu dis là c'est que la majorité de la salle était comprise de gens avec d'énormes préjugés, qui avaient une réaction irrationnelle à cause du mot Microsoft, et il les a remis à leur place.

Cela n'en dit pas beaucoup sur lui mais cela en dit long sur les gens qui étaient dans la salle. Malheureusement.

Moi je t'invite à grandir, passer la puberté et arrêter de nous faire une crise parce qu'il y a Microsoft dans la dépêche. Ton comportement fait vraiment gamin de 5 ans.

Toi en fait avec ta haine de Microsoft tu as…5 ans ?

C'est tellement gamin comme comportement, c'est triste a voir.

C'est pas un reproche car il n'y a pas de solution miracle. Ils ont choisi un chemin, correctif rapide mais incomplet, qui a ses avantages et inconvénients. Un autre chemin, correctif plus lent mais plus complet, a ses propres avantages et inconvénients.

Le truc étant de ne pas comparer les deux sur une seule dimension : le temps.

De nouveau le problème n'est pas ce que ce projet a fait mais ce que certains comparent.

Mais tu ne comprends pas ce que je dis.

Le problème n'est pas ce que ce projet a fait. Le problème c'est les gens qui prennent leur vitesse de correction et la comparent à quelque chose de fondamentalement différent.

N'importe quelle boîte est capable de changer deux lignes dans son code et sortir une nouvelle version en une heure si ils ne font pas de tests, pas de recherche de variantes, etc… Certains le font d'ailleurs dans les cas d'urgence.

Le truc est que les boîtes pour beaucoup font des tests significatifs, du moins les grands éditeurs, et on se retrouve avec des gens qui comparent la vitesse de sortie d'un patch peu testé, sans recherche de variantes, avec des patchs qui ont subi une batterie de tests énorme et qui ensuite viennent clamer que le monde OSS patche plus vite, ce qui est ridicule comme comparaison.

100% d'accord et je ne les blames absolument pas, au contraire je les plains !

Non le problème c'est pas eux, ils font ce qu'ils peuvent. Le problème c'est les gens qui assument que ce projet a des pouvoirs magiques niveau gestion des failles simplement du fait de sa licence.

J'ai passé ma carrière à gérer des reports de failles à Microsoft.

Tous ces cas auraient été couvert dans la recherche de variantes, le seul cas qui ne l'aurait pas été est le CVE relatif à un changement dans le fichier de config parce que l'on aurait considéré ce cas peu important (ai tu peux modifier le fichier config tu peux probablement faire bcp de mauvaises choses)

Vitesse de correction : ah ben ouais ils ont vite corrigé. Bon ils n'ont fait aucune recherche de variantes ce qui fait qu'on en est au 3 ou 4eme patch de suite a installer en deux semaines mais tout va bien ! Non cette prétendue différence de vitesse est principalement due aux gens qui ne comprennent pas ce que les éditeurs proprios font et croient qu'ils traînent des pieds.

Tout le monde peut corriger : c'est une belle théorie, bon en pratique cela importe peu mais la théorie est belle.

Pourquoi cela importe peu ? Parce que soit les mainteneurs sont responsifs pour les patchs propose et sans ce cas pour l'énorme majorité des bugs ils auront de toute façon déjà fait le correctif car pour la plupart ils sont petits, soit ils ne sont pas responsifs aux patchs envoyé et dans ce cas ben le patch ne va nulle part, et personne ne veut de gérer des forks.

Alors des différences ? Oui sûrement, mais minimes. Rien de fondamental.

Il n'y va aucun blâme à donner à qui que ce soit. Les failles celà arrive à tout le monde.

De mon point de vue c'est simplement un énième exemple du fait que le code ouvert n'est en rien différent du code propriétaire niveau sécurité.

Non c'est simplement que tu ne sais pas configurer un système.

Mon W10 installe les updates quand je le lui permet, et c'est tout.

Le paramétrage par défaut a tout son sens pour les gens qui ne comprennent rien a la sécurité car sinon ils ne mettraient jamais leur machine à jour sans en comprendre les conséquences.

WHQL est très utile. Que tu ne comprenne pas a quoi il sert c'est autre chose. Personne n'a jamais promis que WHQL trouverait tous les problèmes dans un driver et WHQL est sans équivalent sous Linux

Et non être libre ne signifie pas qu'il s ne sont pas vérolés.

a) T'as pas de drivers vérolés dans Linux ? Mais mon cher, tu n'en sais absolument rien, il n'y a rien d'équivalent a WHQL pour les drivers Linux, et on sait tous que quasiment personne audite le code

b) comparer le nombre de CVEs est hilarant mais ne montre pas grand chose si ce n'est l'intéret des chercheurs sécurité

condition inutile car en plus de 20 ans elle n'a pas montré qu'elle servait à quoi que ce soit sur ce sujet.

Pour autant, se dédouaner que des pilotes sont « externes » alors que validés pour installation sur un Windows, c'est un peu limite tout de même :/

Ben ils sont externes… MS n'a pas leur code source, pas de droit de modifier leur code, etc… et tu ne peux pas t'attendre à ce que les constructeurs hardware donnent cela à MS. Cf. NVidia et ses pratiques.

WHQL fait certains tests de sécurité (j'ai écrit le fuzzer pour les drivers SCSI il y a plus de 11 ans, et ils sont toujours là de ce que j'ai vu) et driver verifier est requis pour passer la certification mais MS est limité par ce qui est faisable sans code source, sans code pour exercer les diffèrentes fonctionnalités des drivers.

Non, 2000. Et le code n'est pas parfait hein, ils ont aussi des composants qui montrent leur âge et qui mériteraient d'être réecrit, ils font aussi des conneries de temps en temps, mais au total, je trouves la qualité du code plus haute là-bas, le souci du point de vue sécurité plus haut là-bas, et ils ont tout une infrastructure et un processus de sécurité et qualité qu'on ne retrouve pas dans l'ensemble des packages qui font un OS Linux (kernel + libc + …)

C'est le stress post traumatique après avoir dû se taper tout ce bordel.

La réalité est que les bugs, ben ils arrivent partout, et log4j est un grand exemple que les bugs stupides arrivent partout, y compris dans le LL, et y restent pendant des années comme partout. Les gens n'auditent pas forcément le LL plus.

Moi je vais faire simple : j'ai passé 13 ans dans la sécurité du code de Windows, en user et Kernel.

J'ai passé les 7 dernières années dans le code de Linux.

A choisir je prends Windows. Le code est plus clean, Lea pratiques sécurité de MS pour la qualité du code sont plus avancées que ce qu'on trouve sous Linux et ce mythe que le code Linux est revu plus parce que livre est un gros gag.

Mais bon faut pas prendre mes dires pour vérité. Par contre on peut aller voir ce que Brad Spengler pense : https://slo-tech.com/clanki/10001en/

Et pour finir, appelez moi quand Linux aura l'équivalent de HVCI, WDAC, Edge Application Guard, Office Application Guard, une protection contre un SMM compromis, sera compilé avec support pour les Shadow stack par défaut, etc… MS inkove dans la sécurité d'OS depuis longtemps et ce qu'ils font avec les capacités de leur hypervisor est à des kilomètres de Linux et ses containers rigolos qui ne protègent pas grand chose.

La triste réalité est que les gens qui critiquent la sécurité de Windows sont typiquement des gens qui ne comprennent rien à la sécurité et à Windows.

Ensuite pour les LL audités, ben je vais me contenter de rigoler en pensant a log4j

Mais quand tu as une infrastructure élastique (hum…cloud) ben tu te fous de savoir combien de serveurs tu as, si tu en veux un cela prend 10 secondes plutôt que devoir attendre 3 semaines, et si tu en veux 100 cela prend 10 secondes aussi !

Ensuite il y a le côut, mais quand tu prend en compte le côut pour les équipes de devoir commander des serveurs, attendre qu'ils arrivent et qu'ils soient installés, etc… ben tu commences à comprendre pourquoi plein de bôites s'y mettent.

Alors oui, il y a certains trucs très particuliers qui s'y prettent potentiellement moins, mais pour tout ce qui est infra d'entreprise c'est évident que cela marche, et je suis sûr que tu serveur de calcul, pour vérifier qu'il fonctionne il n'y a pas besoin d'un calcul de 6 semaines, tu peux le tester en bcp moins de temps avec une batterie de tests correcte.

Avec ce modèle, tu te fiches de penser à bloquer des serveurs, tu en as un nombre infini, tu peux les rendre quand tu veux, et tu ne les paies quand quand tu les utilises.

Non vraiment, quand je t'entends, j'ai l'impression d'être de retour dans les années 90 - début 2000.

Bonjour,

Ici on update des [je peux pas donner le chiffre mais il y a bcp de zero] de milliers de serveurs, chaque jour.

Il y a tout un concept de pipeline, A/B testing, deploiement par étapes, … et tout est automatisé.

Faut penser à passer au 21ème siècle, la méthode manuelle avec 3 semaines de test pour un serveur c'est has been

Toi tu vis encore dans les années 90

Quand tu as un service en ligne, que ce soit Windows ou Linux, tu le construis de manière à ce qu'il :

• monte en charge automatiquement (= ajout de machines et load balancing)
• n'ait aucune perte de service quand les machines sont recyclées, tombent, … : t'as un système de heartbeat et tu arrètes d'envoyer des requètes à cette machine et draine les requètes en cours si elle tombe ou si elle se marque hors jeu

Et le deuxième point là, cela te permet de :
- mettre à jour ton service toutes les heures si cela te chante
- enlever des machines quand tu veux si ils ne répondent plus ou … si tu veux les patcher

C'est un concept basique de nos jours, et avec celui là, on se fout que la machine doive rebooter ou pas.

Non, le problème de cette boite c'est qu'ils ne savent pas gérer leur infrastructure.

Oh et sinon, pour ce qui est du patching : https://docs.microsoft.com/en-us/azure/automanage/automanage-hotpatch

Ah mais j'ai bien clarifié que les Suisses étaient des guignols niveau vaccination…

Avec la France et son taux de vaccination supérieur j'imagine qu'un vote serait encore plus clair qu'en Suisse.

Son moinssage me fait une belle jambe, cela fait plus de 20 ans que je suis là et j'éspère que LinuxFr utilise un compteur 64bit pour le nombre de "moins" que j'ai recu parce que sinon il va y avoir un overflow.

Il nous fait une petite crise parce qu'il se rend compte que même ici ou il pensait avoir des gens avec des idées similaires aux siennes ben …. non, la plupart des gens ici sont sain d'esprit et trouvent que son point de vue sur le pass et les vaccins est totalement ridicule.

Ca la fout mal quand ces gens se rendent compte que non seulement dans le monde réel mais même dans leur monde virtuel ils sont en petite minorité. C'est un peu comme nos anti-pass à nous en Suisse qui ont fait une crise d'angoisse à la vue des résultats du vote de dimanche passé ou le pass a été approuvé par 62% de la population, et pourtant les Suisses sont des guignols niveau vaccination par rapport au reste de l'Europe.

Il y a un certain nombre de documents qui viennent de Google et qui on va dire n'aide pas son image…