Reprise du message précédent :
   
 

* Coté DHCP, je ne suis pas le seul à rencontrer le pb. Qui d'ailleurs n'a rien à voir avec la "configuration alternée".
 
* IE pas envahissant : non il est intégré DANS l'os !!
 
* Leak Memoire Rare (MDR): j'ai une "ferme" de 18 serveurs sous NT4 - W2K et Maintenant Win2003. Et nous avons constater le meme phenomene sur ces OS :
Tu demarres une base Oracle, SAP ou MFG/Pro en allouant par ex une share-memory de 500 Mo. Disons avec tous les process liés à la base tu occupe +600 Mo.   Tu arretes ton serveur de base, la memoire liberée n'est pas de 600 Mo. Cela peut se comprendre car l'OS "reserve" des pages memoires au cas ou tu relancerais un processus (lancé precedement). Mais dans notre cas tu relances ta base avec la meme taille pour la share memory.    
==> l'occupation totale n'est pas (occupation OS + 600) comme auparavent mais : occupation OS + 600 Mo + un reliquat !  
 
Pas un "faux svchost" Faut arreter :  cela signifie clairement que nous avons à faire à un OS incapable de reconnaitre ses petits. D'ou les pb actuels de vers et Cie.
 
Enfin je n'evoquerait pas le pb de Bdr qui ceux ci ont été cité plus haut.
 
 
 

vrobaina : Je suis d'accord avec toi sur tout ce que t'a dit depuis le debut... sauf le coup du svchost. Alors la vraiment je vois pas du tout en quoi l'os devrait verifier que chaques processus n'a pas un nom qui resemble a l'un des processus systemes (et le killé si c'est le cas) Ca ce serait carrement un bug grave a mes yeux.
J'aimerai que tu me cite un seul OS qui fait de la surveilance de nom de processus... parce que la... Des OS j'en connais un paquet, mais un OS qui fait ca j'ai jamais vu (et je trouverai ca gravement debile, bonjour la perte de temps pour que dalle... c'est quand meme a l'utilisateur de regarder ce qui tourne sur sa machine)

 
En effet, mais je ne demande pas qu'il verifie les noms des process, Microsoft utilise la notion de signature numerique, pourquoi ne pas le faire sur des exe, dll système afin de garantir leur intégrité ?. Et d'une manière generale pourquoi autoriser une application/process à installer ses propres fichiers dans le répertoire système ?. C'est à mon sens dangereux de mixer appli et OS. Mais cela ce n'est pas un bug, c'est un pb de conception/philosohie.
 
 
 

vrobaina : Quelle heurreur... relis toi bon sang... t'es en train de parler de signature numerique et de tout un tas de saloperie que justement Microsoft a bien l'intention de devoloper, toutes ces choses ou je serai pres a faire a peu pres n'importe quoi pour que ca sorte jamais justement...
Quand a l'emplacement des exe sur le disque, ce n'est pas du tout, mais alors pas DU TOUT le probleme, un cheval de troie peut se mettre n'importe ou et etre aussi dansgeureux de toute facon, pas besoin de se mettre dans le repertoire systeme... Si un jour
je faisait un prog qui devait pas se voir, je sais bien ou je le mettrai, ce serait absolument pas dans les repertoires systemes et la je te garenti que t'es pas pres de le trouver.

Chacun son pt de vue, mais je reste persuader que mixer fichiers appli et fichiers OS reste un bon moyen pour foutre la grouille dans ta bécane. Qt à "la signature numerique" OK, parlons plutot de check de CRC par ex.

Ok, la deja c'est une notion que je prefere. Cela dit, un tel niveau de securité sur les fichiers systemes, desolé mais c'est rarement de base dans les OS hein... Je connais pas bcp de distrib linux qui installe et configure par defaut tripwire and co.
On peut quand meme pas trop en vouloir a l'os pour ca il me semble... d'autres bugs et surtout les nombreuses failles dans les differents logiciels (IE, outlook etc) me semble bien moins normales et bien plus preocupantes.

 
Si le fichier se nomme svchost.exe et se place dans le repertoire de windows ca n'est pas pour tromper l'OS et s'octroyer des droits que windows lui donnerait pensant que c'est un des ces fichier, c'est pour tromper l'utilisateur qui, quand il voit un process svchost qui tourne et qu'il le trouve dans un repertoire systeme, se posera moins de questions que s'il voit un process nommé grosvirus.exe qui se trouve dans c:\repvirus.

[citation=1352367,3]

il me semble que ma deb voit quand les binaires ont changé entre 2 upgrades ... je suis pas sur, mais il me semble qu'une fois elle m'a prévenu (une fois où j'avais compilé moi même un prog dejà installé) ... m'enfin c'est vrai qu'attendre l'upgrade pour s'en rendre compte c'est pas génial mais ça doit pas être compliqué d'étendre ces fonctions