pasBill pasGates a écrit 16057 commentaires

Je me demandes, tu vis sur quelle planete ?

Va comparer le nombre de failles d'IIS 6 et Apache 2.0.x (sortis a peu pres en meme temps).

Une fois que tu auras vu les chiffres, va acheter un paquet de mouchoirs.

Il y a même eu un moment (si je ne dis pas de bêtise) où MS eux mêmes utilisaient de l'Apache sous FreeBSD… Pour des raisons financières ? J'en doute.

Pas pour raisons financieres, parce qu'ils avaient achete Hotmail, et que tu changes pas des centaines de serveurs du jour au lendemain.

Tout a fait, il y a le temps de correction + la qualite du patch qui compte pour evaluer la securite entiere du produit.

Mais quand on parle du cote "with enough eyes all bugs are shallow" du libre, ca n'entre absolument pas en compte, la seul le nombre de bugs compte.

Oh que si bien sur, c'etait mon job d'ailleurs.

Mais tout comme les softs OSS, les failles trouvees en interne ne sont le plus souvent pas corrigees par patch mais en service pack / version suivante.

Et sinon, vu la question ici meme, faudrait de toute facon pas les compter vu qu'ils ont justement ete trouves en interne (= preuve que le modele de developpement est de qualite, les failles sont trouvees en interne avant d'etre trouvees par des externes)

Faudrait aussi lire le truc entier, ou ils ecrivent ca bien clairement pour dire qu'on ne peut pas comparer une distrib Linux a Windows par exemple.

Ces chiffres sont utiles, quand ils sont compares correctement, typiquement : 2 produits qui font sensiblement la meme chose, sortis a peu pres a la meme periode.

Ca veut pas non plus dire que ces chiffres sont la reponse entiere, mais ils en sont certainement une bonne partie.

Parce que MS aurait le pouvoir de les garder secret ?

Les failles sont quasiment toutes trouvees par des chercheurs externes au produit que ce soit dans les softs OSS ou proprios (tu suis les liens des failles, tu verras qui les a trouvees, c'est clair), si MS ne disait rien, les chercheurs les annonceraient eux-meme (c'est leur gagne pain pour la plupart : se faire un nom avec).

http://secunia.com/advisories/product/73/?task=statistics
http://secunia.com/advisories/product/1438/?task=advisories

http://secunia.com/advisories/product/8355/?task=advisories
http://secunia.com/advisories/product/6782/?task=advisories

etc…

Les chiffres d'utilisation internet sont clairs : 1%, stable.

Tu vas peut-etre venir me dire qu'ils ne vont jamais sur internet, dans une proportion tres differente aux utilisateurs d'autres plateformes, et qu'ils n'apparaissent donc pas dans les statistiques ?

C'est quelle partie qui est biaisee et illuminee ? Celle ou les chiffres montrent le fait cite ?

et je te répondrais qu'il y a tout de même plus d'utilisateurs sur CyanogenMod que sur Windows Phone (oui Cyanogen est la fameuse 3eme plateforme mobile).

Faut revenir sur terre, la proportion d'utilisateurs Android qui root leur phones est infime. Les geeks font ca, ils sont une toute petite proportion des utilisateurs Android.

Toute la difference est que MS a fait un effort tres clair pour le tourner en OS desktop, ce qui n'a jamais ete vraiment le cas du cote de Linux. Ubuntu a un peu essaye mais ils n'ont jamais eu les moyens de le faire proprement (pas possible de forker tout ce qu'il faut, maintenir, … vu que les projets centraux n'etaient semble t'il pas interesses)

Tu regardes le nombre de problemes dans Firefox, dans MySQL, dans PHP, dans Apache, etc… tu compares aux equivalents proprios et tu as la reponse.

Rien de circulaire. La pratique a demontre qu'ils ne sont pas plus surs (nombre de failles, etc…), ce qui demontre que l'acces aux sources n'amene rien de ce cote.

Ah ca clairement, choper 1% du desktop en 20 ans, c'est un gros succes.

PS :
a) Android ce n'est pas un Linux dans le sens OS (parler de kernel ici n'a pas de sens vu qu'on parle de droits utilisateur)
b) Android ne contient rien de ce dont on parle ici (t'en connais combien des gens qui ont le mot de passe root de leur telephone Android ? Ah oui, personne)

Non, c'est pour faire mousser les petits rigolos sur linuxfr qui parlent sans meme savoir de quoi ils parlent.

(indice : il n'y a jamais eu de difference sur ce point entre les versions d'un meme OS)

Le choix des logiciels libres est souvent argumenté en avançant la stabilité et la sécurité ; cela ne tient pas uniquement à la qualité intrinsèque du code et d'accès aux sources

Non ca certainement pas, parce que les LL ne sont pas plus stables ou plus surs, et l'acces aux sources n'amene pas grand chose de ce cote la (la preuve : ils ne sont pas plus stables ou plus surs justement).

mais aussi du fait que l'on essaye d'apprendre aux gens à ne pas faire "tout et n'importe quoi" avec le système, y compris utiliser le compte root sans raison.

Non ca a surtout a voir que Linux derive d'Unix (tous ces principes de securite viennent d'Unix, pas du libre) et a toujours ete pousse dans une optique serveur plutot que grand publique. C'est pas par hasard qu'il a fait un bide sur le desktop.

Parce que t'as toujours un driver ici ou la qui fait des cochonneries plutot que respecter l'API publique.

Si tu veux simplement lire le fichier PDF oui, mais quand tu as des operations a faire dessus (conversion, etc…) va bien falloir faire le parsing du PDF, stocker tes objets, etc…

Ben non :/ C'est juste découpé en morceau et traité en morceau.

Mais de nouveau, c'est le cas uniquement si ton probleme se prete a etre traite en morceaux.

Peut-être chez toi. Mais pas chez moi.

Quand t'es le gars qui ecrit le soft, t'as aucun controle la dessus, t'es sense faire pour que cela marche dans la plupart des cas correctement.

???

Selon la fragmentation de l'espace memoire du soft, t'as beau avoir 60Mb de libre, tu n'arriveras pas a faire une alloc de plus de 2Mb…

Et pour quoi donc avec morcellement ? On garantit juste que 1024 clients seront très bien servis ! Tant pis pour les autres. De toutes manières le système ne supportera pas mieux.

Ce sera vrai uniquement si tu prealloue 1024 blocs de 8Mb, resultat tu forces ton processus a avoir 8Gb alloues tout le temps, super…. (et evidemment en imaginant que ton probleme se prete au modele ou aucune autre allocation dynamique est necessaire)

J'ai 8M, par défaut, chez moi.

Et sur Windows c'est 1Mb… Dans un systeme avec plein de processus et/ou threads, ca commence a te couter pas mal et tu vas le reduire.

Tu ne réserves pas vraiment. Tu alloues sur le stack.

J'ai bien compris, mais quand tu fais ca dans une librairie, tu ne sais pas tout ce qu'il y a au dessus de toi sur la stack, resultat tu tend a etre conservateur pour eviter de te prendre un stack overflow.

Pour les serveurs, travailler par petits morceau, minimiser les allocations, ce sont de très très bonnes pratiques.

Tout a fait, quand c'est possible. Le truc est qu'il y a plein de cas ou tu n'as pas trop le choix parce que le probleme ne s'y prete pas.

Tous les cas ou ta taille de bloc est "presque" aleatoire par exemple. Si tu ne sais pas d'avance quelle taille tu va devoir gerer, tu dois soit allouer dynamiquement, soit avoir un tas de buffers gardes de cote que tu n'utilises quasiment jamais et qui coutent sur le systeme.

Ça tombe bien j'ai dis qu'il fallait l'ignorer (windows fait quoi lorsqu'il n'a plus de mémoire ?).

Tout depend de l'operation. Si c'est le noyau qui fait l'allocation et c'est pour un truc absolument critique, ben il finit en ecran bleu, pas le choix. Si c'est quoi que ce soit d'autre (kernel et truc pas critique, processus utilisateur…), le code gere le fait que l'allocation rate et continue. Pas de OOM killer du tout.

Et tu voudrais qu'on processus en traite des centaines ? (puisque tu refuse les pools de processus)

Si c'est un serveur (fait des conversions, extrait du texte, de l'edition en groupes, etc… que sais-je) oui. Quel interet d'avoir plusieurs processus identiques? Ca te coute en ressources et le service fournit est identique.

Si tu as un malloc() qui plante tu perdra quoi qu'il en soit des connexions quoi qu'il arrive.

Tu m'expliqueras comment. malloc retourne NULL, tu essaie de renvoyer une erreur au client, si ca ca rate, tu fermes le socket. Tu as perdu cette connection la, mais toutes les connections en cours sont toujours la.

Eviter de faire des mallocs ?

En theorie c'est joli et je suis plutot d'accord, mais cela a ses limites. Deja la pile ne contiendra pas de buffer qui fasse plus que qqe dizaines de Kbs sous peine de te taper un stack overflow potentiellement. Ensuite tes buffers alloues statiquement, soit tu traites des petites requetes et c'est tout bon, soit tu gardes sous la main assez de gros buffers (genre 10Mb on dira) et la tu bouffes de la RAM pour rien le plus souvent.
Il va bien falloir que tu alloues a un moment ou un autre (t'as pas reserve assez de buffers, etc…), pas de miracle.

Ensuite pour le traitement pas petits morceaux… tout depend de ce que ton service fournit, si c'est faisable oui, si ca ne l'est pas, ben t'as pas le choix.

Rappel : OOM Killer c'est specifique a Linux… Tous les OS ne traitent pas le manque de memoire de la meme maniere.

Je veux bien que les tres grosses allocs soient a eviter, mais le truc est que 10 ou 20Mb c'est pas si enorme… Regarde les PDF d'aujourd'hui, il y en a plein qui font cette taille. Si ton serveur explose en vol a cause d'une alloc de 20Mb parce que t'es temporairement a court de RAM il y a quand meme un sacre probleme.

Un pool de processus c'est toujours pourri au niveau du design, tu te tapes le cout de chaque processus a part le 1er (stack assignee au process, tous les buffers statiques, etc…) en extra. Tout ce que tu fais au final c'est accelerer le moment ou tu seras OOM vu que tu consommes plus, et tu perdras toujours des connections vu que c'est un pool, a moins de faire 1 process / connection mais la c'est tellement un desastre niveau architectural qu'il vaut mieux pas imaginer.

Et tu te retrouves avec une limite totalement artificielle qui t'empeche de gerer des requetes de taille tout a fait normale, toujours sans avoir aucune garantie que ton allocation fonctionnera car tu n'as aucun controle sur la pression memoire du systeme en entier (tu ne sais pas ce que le serveur contient d'autre) et peu sur la fragmentation de l'espace memoire de ton soft.

Resultat, meme avec ta limite a 8Mo, tu as toujours des chances de planter.

Et si le client t'envoie 30Mb, que ton systeme est sous pression memoire temporairement mais peut quand meme gerer des requetes de moins de 20Mb tu fais quoi ? Tu exploses parce que c'est plus de 20Mb, tu coupes le service et coupe toutes les connections qui etaient en cours ?