pasBill pasGates a écrit 16197 commentaires

C'est un fichier qui est choisi avec le meme nom histoire que les gens s'y retrouvent plus facilement, de la meme maniere que Winsock implemente les API berkeley afin que les softs soient facilement portables, ca veut pas dire que le code sous jacent est le meme.

Je te paries 1 million qu'il n'y a aucune cle de registre pour contourner la chose. Mais a ta place je parierai pas, on est en train de parler du composant sur lequel je bosses tous les jours :+)

Apres lecture de ta page, mon petit doigt me dit que la raison de la lenteur se trouve dans la fenetre de congestion: http://www.faqs.org/rfcs/rfc2001.html(...)
Tu devrais lire la RFC et voir si ca s'applique a ton cas.

On reconnait bien là, la politique légendaire de Microsoft en matière de sécurité, puisque cette limitation serait contournable via une improbable valeur dans une clé de la fumeuse base de registre.

C'est pas configurable dans la registry, c'est en dur dans la stack.

Il ne faut pas se fier aux rumeurs, la stack est 100% MS

T'aurais une capture reseau de la chose(filtree pour ne contenir que ce qui est necessaire si possible...) histoire que je jette un coup d'oeil ? Ma preference va a Netmon, mais si c'est du Ethereal je peux vivre avec.

Désolé mais je peux pas tout faire.
Mais puisque toi tu aimes les archives, cite moi une période où il n'y avait pas de failles critiques non corrigées !

J'ai rien a te citer moi, c'est a toi de prouver tes dires, et depuis le debut du thread tu te defiles.

Comme par hasard, et alors que tu prétendais le contraire, on est dans une période où les failles crtiques connues sont pas corrigées.

Arretes de sortir des conneries et donne un lien sur ces failles.

C'est dingue une mauvaise foi pareille, soit tu prouves tes dires soit tu te tais, c'est pas si complique a comprendre pourtant que tu es sense avoir un minimum d'arguments valables pour supporter tes affirmations non ?

A quel endroit j'ai dit que toutes étaient dues au threads ?

Ou ai-je parle de toutes les failles ?

Désolé que tu comprennes pas, mais tous ceux qui fréquentent régulièrement cette page Secunia ont compris, eux. Tous les jours où on visite cette page, on peut y constater que chaque jour on peut rentrer par effraction dans un systeme XP. Point.

Tu continues a te defiler, files moi ces liens ou arretes de sortir des conneries !

Je n'ai pas d'archive du site Secunia. Et je ne vais pas en chercher une pour tes beaux yeux. Mais tous ceux qui visitent cette page régulièrement savent qu'il n'y a quasiment jamais de jour sans que XP soit crackable à l'aide d'une faille critique.

Ah parce que t'as besoin des archives pour me montrer ce qu'il se passe aujourd'hui ? Le lien que tu as donne ( http://secunia.com/product/22/(...) ) recense les failles jusqu'a 2002, t'as besoin de plus que ca ? Tu te fous de moi ?

Aies un minimum de bonne foi et reconnais que tu as raconte n'importe quoi.

Tu continues a te defiler mon cher :

- Tu pretends que les failles sont dues aux threads, et hop, rien pour justifier
- Tu pretends qu'il y a plein de failles non corrigees dans Windows, et hop, rien pour justifier

Serieux, t'en as pas marre de sortir des conneries et te defiler a chaque fois ?

Maintenant, soit tu me justifies ce que tu as sorti, c'est a dire :

- Les failles sont dues au systeme de threads
- Les failles critiques ne sont pas corrigees

Ou alors svp tu te tais et tu arretes de sortir connerie sur connerie.

Donnes moi le lien sur une faille "highly critical" qui date de plus de 2 semaines et qu'on n'a pas corrige. Apres, peut-etre que je te prendrais au serieux.

T'as pas tout a fait compris il semble, quand tu lances "Demarrer en tant que", il te demande le mot de passe de l'utilisateur sous lequel tu veux lancer le soft.

Et il y en a combien qui sont critiques et qui sont restees non patchees ? Ah ben oui, aucune.

Faudrait penser a faire un peu plus que de la lecture et mettre les mains dans le cambouis mon cher si tu veux que je te prennes au serieux, il n'y a jamais rien pour soutenir tes dires.

Et combien il y en a qui sont "highly critical" et qui ne sont pas corrigees ?

Mais c'est quand meme dingue comme on a devie du sujet principal sur un sujet qui n'a _absolument rien_ a voir car pour je ne sais quelle raison bizarre et que tu n'as toujours pas expliquee et prouvee tu as dit que les failles de securite dans Windows etaient causees par les threads.

Ca serait franchement bien que tu mettes quelques arguments valables dans tes dires, parce que quand je te lis j'ai l'impression que tu ne fais qu'une chose : tu lis la theorie et tu extrapoles sans jamais avoir touche a la pratique.

Alors si j'ai bien compris a faille qu'utilise sasser etait "inoffensive" ?

La faille qu'a utilise Sasser avait ete corrigee avant que le virus existe, ca n'a rien a voir donc.
Si tu regardes la liste des soi-disant failles non corrigees sur le site, tu verras qu'elles sont extremement limitees et/ou demandent des conditions tres particulieres pour etre reproduisibles, bref ne sont pas exploitables.

Je n'en sais rien sur la fait que des threads introduisent plus de failles (meme si je me permet d'emettre quelques reserves dessus) mais dire que windows est un havre de securite je trouve ca un peu ose quand meme.

Je ne dis pas que c'est un havre de securite, par contre je dis que les failles qui posent un risque on les corrige, les autres vu qu'elles ne posent pas de risque bien evidemment sont traitees differement selon les cas.

Remarque, ca aurait ete bien pour l'espece humaine que 90% des texans soient homos, ca aurait peut-etre permis d'eviter Bush...

Ok, je -->[]

Tu apprendras aussi a analyser ce que tu lis avant d'en tirer des conclusions hatives, et alors tu remarqueras que toutes ces soi-disantes failles reportees sont inoffensives dans l'enorme majorite(celles qu'on ne corrige pas), et en train d'etre corrigees pour les autres.

Et a part ca, tu t'es defile encore une fois, donne moi donc ces exemples montrant que les failles dans Windows sont dues aux threads.

Mais comme d'habitude tu vas eviter de repondre je suppose et detourner le sujet sur autre chose.

Justement, beaucoup d'utilisateurs de windows aimeraient bien que l'architeture multithread de win déconne moins souvent, et avec moins de failles de sécurité publiques non corrigées depuis trop longtemps. Pourquoi ne sont-elles pas corrigées rapidement ?

Tu peux arreter de raconter des conneries STP ?
1) Cites moi des failles publiques non corrigees dans Windows(je parles pas d'IE qui est un browser)
2) Cites moi donc des failles dans l'archi multi-thread de Windows

Ce que tu racontes la c'est 100% conneries, du vent, rien d'autre et soit tu le sais, soit tu vis sur la lune mon cher.

Parce que le moindre changement peut perturber la dynamique des threads, cf l'article que l'on commente, et fait apparaitre de nouveaux bugs. C'est ça l'enfer des threads.

Tu ne sais absolument pas de quoi tu parles, et c'est vraiment gonflant.

En fait, je pense que c'est un des vrais atouts de Kde, les technologies sont vraiment utilisées par toutes les applis ce qui permet un niveau d'intégration bien supérieur à Windows.

Tu compares pas la meme chose la. KDE c'est un ensemble limite d'applications, t'as pas OpenOffice par exemple, ni Gimp, etc...

Comparer KDE a l'ensemble de la plateforme MS y inclus les softs non-MS pour conclure que KDE est plus integre que Windows c'est comparer des pommes et des oranges, tu compares ~100-200 softs venant d'une source unique a 20'000 softs venant de 1000 sources differentes.

T'as visiblement toujours pas compris que les shm sont _plus dangereux_ que les threads vu la lourdeur necessaire pour implementer la meme chose. Les variables privees c'est un element, tu occultes tous les autres(decalages de pointeurs necessaires si mappe dans des endroits differents, modification du malloc, etc...)

Je m'arretes la car on tourne en rond, je n'ai qu'une chose a te dire : Essayes par toi meme plutot que disserter sur une theorie que tu n'as jamais teste, et tu comprendras pourquoi la majorite de la planete utilise des threads plutot qu'une archi multi-processus, il y a de bonnes raisons a cela et tu t'en rendras compte en essayant d'implementer une archi multi-processus.

C'est pas en devenant insultant que tes arguments passeront mieux. Au contraire.

Je suis pas insultant, mais tu occultes totalement les problemes et refuses de voir la verite en face: c'est infaisable dans le monde reel, donc forcement au bout du 10eme argument que tu evites je m'enerves un petit peu.

Unix a 35 ans. Il a acquis sa réputation de fiabilité et d'efficacité en utilisant surtout des process indépendants et communiquant par pipe ou socket. C'est encore vrai aujourd'hui. Et les 20 premières années d'Unix étaient complètement dépourvues de threads.

Oui, et pendant 50 ans les voitures n'ont pas eu d'airbags, ca veut dire que les airbags sont dangereux ? Non, ca n'a rien a voir. De meme avec Unix, le fait qu'Unix ait eu des process independants au debut n'a rien a voir avec sa reputation de fiabilite, c'etait simplement du au fait que les threads n'etaient pas encore implementes.

Je dis simplement que nous devons tirer les leçons de fiabilité de l'histoire d'Unix, et tout simplement remplacer les pipe et les sockets par des shm qui sont plus rapides.

Les pipe et socket oui c'est possible dans bcp de cas(pas tous), mais remplacer les threads pas du tout, c'est totalement different et c'est pratiquement irrealisable.

Où as-tu un équivalent de kdcop (un explorateur de DCOP : il liste les interfaces, objets et fonctions accessibles via DCOP avec génération automatique des commandes shell, C++ ou Python) ?

Oui ca s'appelle OLE Viewer, et ca existe depuis longtemps(je sais pas si ca genere les commandes par contre)

Et comment une application peut-elle exporter facilement une interface via COM ? Quand je codais avec Delphi, à aucun moment je n'ai vu de mise en avant de ceci alors que c'est le cas dans KDE (kdevelop met par défaut une interface DCOP quand tu génères une application KDE)

Ben tu definis l'interface COM, quelles methodes exporter, etc.. de la programmation classique. Visual Studio .Net a des wizards pour aider a la creation de ces interfaces par exemple, Borland C++ builder aussi,...

Toutes les applications windows exportent une interface via COM ou c'est au petit bonheur la chance ? (les applications KDE exportent quasiment systématiquement une interface via DCOP)

Bcp d'applications le font, mais pas toutes. C'est au choix du developpeur de l'application de decider ce qu'il exporte.
Tous les softs MS par exemple exportent systematiquement des interfaces COM pour tout et n'importe quoi. Bcp de softs non-MS, par exemple a peu pres tous les softs Adobe(photoshop, illustrator, acrobat,...), Oracle, Siebel, iTunes, ... exportent des interfaces COM aussi.

C'est present dans Windows depuis des annees.

Ah toujours le meme qui parle de ce qu'il ne connait pas...

Adobe Photoshop
Adobe Illustrator
Adobe Acrobat
iTunes
Metrowerks CodeWarrior
Siebel
Oracle
LotusNotes
etc...

Ca serait bien si de temps en temps tu te renseignais sur le sujet avant de sortir des enormites, parce que t'as un passif plutot lourd de ce cote la et ca n'aide pas ta credibilite.

Sous win tu peux écrire une applications en 15 lignes de code qui te mette away sur IRC (konversation), Jabber (Kopete), qui mette en pause amarok et qui verrouille l'écran ? (Bien sûr y'a des options pour pas toucher amarok, pas verrouiller l'écran, pour choisir son message d'absence ou dire qu'on revient)
(application écrite avec gambas)

VBScript et COM permettent de faire ce genre de choses depuis des lustres.

oui, c'est un partage par defaut et il faut etre authentifie pour y avoir acces(et avoir les droits pour aussi)

Non mais tu te fiches de moi...

Je te rappelle que l'article concerne la complexité du debuggage des threads.

Quedalle, debugger des threads concurrents c'est tout aussi complique debugger des processus concurrents, meme topo.
La question c'est laquelle des 2 architectures est la meilleure pour eviter des bugs et avoir des perfs decentes.

Tu n'es vraiment pas objectif car tu n'as pas un dit un mot sur l'enfer de ce debuggage comparé au débuggage des processus multiples. Cet enfer des threads est bel et bien du aux fait que les variables privées ne sont pas respectées et que les threads encouragent à faire des algorithmes multipliant les variables partagées inutiles, et donc ajoutant de nombreux besoins de synchronisation supplémentaires qui ne sont pas toujours suffisament pris en compte.

Rien du tout, la complexite du debuggage est la meme, mais bien evidemment tu ne le sais pas car tu n'as jamais essaye toi meme.
Le partage des donnees, que ce soit des threads ou processus avec shm c'est le meme topo.

Enfer qui est incommensurablement plus grand que d'avoir à utiliser une bibliotheque pour les allocations et une bibliotheque pour les spinlocks.

Mais tu fais expres c'est pas possible...

Le seul fait de devoir faire des decalages pour les pointeurs si les segments ne peuvent etre mappes au meme endroit fait que la solution shm est totalement irrealiste, partant de la la question ne se pose meme pas, mais tu refuses de comprendre et t'obstines a croire une theorie que tu n'as jamais eprouvee plutot qu'ecouter qq'un qui a deja teste les 2 techniques.


On peut très facilement utiliser shm pour remplacer un pipe ou une socket entre 2 processus. Pas besoin de malloc pour faire cela. Ce faisant, on obtient des performances similaires aux threads tout en utilisant la technologie éprouvée des processus qui est à la base de la fiabilité des UNIX.

Ca c'est une conclusion qui prouve que tu n'as absolument rien compris au probleme.
Les shm oui c'est utile pour remplacer les pipe ou socket(dans certains cas), mais ca n'a rien a voir avec les threads et cela ne les remplace pas, pour la tres simple raison que les pipe et socket ca n'a jamais ete une alternative aux threads, c'est pour un usage different.

Je t'en prie, arretes de parler de maniere si affirmative d'une technologie que manifestement tu n'as jamais utilisee, ce que tu racontes est reellement effarant.