pasBill pasGates a écrit 16044 commentaires

justement, l'idée meme de linux et des logiciels libres est d'apporter une alternative fiable, fonctionnelle et prete à l'usage (selon les distros) à des utilisateurs finaux n'y connaissant rien.

Toutes les distribs Linux majeures ont des bootloaders signé avec la cléf de Microsoft et s'installent de manière transparente sans avoir à toucher le BIOS.

Les seules personnes qui auraient besoin de toucher le BIOS sont celles qui veulent … bidouiller.

C'est quoi le fil à retordre ?

Aller dans le BIOS, choisir "off" et redémarrer ? Mon cher, si tu n'est pas capable de faire cela alors tu n'as rien d'une bidouilleur.

Secure Boot est utile pour garantir un certain niveau d'integrité du système, ce qui améliore significativement la vie de tous les utiilisateurs, au prix que le 1% de bidouilleurs doit aller taper une coche pour l'enlever au pire.

Et Secure boot n'a rien de propriétaire.

En fait tout ce que tu nous dis c'est que tu n'as absolument jamais mis les pieds dans une boite américaine, que tu ne sais absolument pas de quoi tu parles et que tu as des préjugés gros comme un gratte ciel.

Chez Twitter, comme toutes les autres boites tech US, les DRH n'ont aucun pouvoir de décision sur qui est engagé, ils s'occupent juste de la gestion. Ce sont les ingénieurs qui font les interviews et qui décident de qui passe ou pas.

Perso je pensais partir en voyage d'affaire a Tahiti pendant 14 ans, le temps qu'ils grandissent, mais ma femme a refusé :)

Non là j'ai un gros point de contention au niveau du sommeil…

C'est plutôt aux gens qui répondent "cloud" à l'auteur du journal qu'il faut répondre ça non ?

Non, parce que visiblement lui ne comprend pas que bare metal n'est pas en opposition a cloud

Ça ne change rien au fait que quand les entreprises embauchent des gens certifiés pour un "cloud" ce n'est pas pour le SDK et que les certifications que j'ai vu passer ne portent pas dessus.

Ben faut regarder à qui tu parles. Déjà içi on ne regarde pas les certifs dans les boites ou je suis passé, à l'interview on regarde si tu sais écrire du code, et si tu comprends comment un cloud fonctionne.

Même les formations azure que j'ai aperçu montrent comment cliquer sur vos sites. Pour que ton commentaire soit constructif il aurait fallu nous pointer vers vos certifications d'ingénieurs sdk etc. ;)

Normal, je bosses chez Amazon, aucune chance que les formations Azure en parlent :D

Mais plus sérieusement, c'est parce que tu ne parles visiblement pas aux bonnes personnes. Tu crois que le microservice qui utilise Azure Storage ou S3 il va utiliser des clics pour stocker des données ? Non, le microservice il est écrit en Java, il utilise l'API.
Déployer le microservice ou une update au microservice c'est idem bien évidemment.

Tu postules pour un poste de dev cloud chez les boites US, si tu leur parles de l'interface graphique ils vont te rire au nez et te renvoyer chez toi

Ca s'appelle avoir un job ET 3 enfants en bas âge :)

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.