pasBill pasGates a écrit 16204 commentaires

Oui tu peux le compiler, et tu peux meme utiliser un debugger non-MS pour verifier que ce qui se passe est bien ce qui est dans le code.

- oui, en nous signalant les bugs si ils en trouvent histoire qu'on les corrige, mais la theorie et la pratique... J'ai pas encore vu une seule boite externe filer un bug report venant d'une code review sauf quand la boite etait payee pour le faire(= c'est pas une assurance ou autre magasin de chocolat mais une boite de securite).
- Les clients recoivent pas les correctifs finaux plus vite, par contre ils pourraient recevoir une preversion pour qu'ils nous confirment que le probleme qu'ils ont vu chez eux a disparu.
- Les evolutions ben elles passent toutes par nous, personne n'est autorise a avoir un fork du Windows de Microsoft.

Est-ce que quelqu'un (pBpg?) sait si Microsoft bénéficie de beaucoup de retours grâce à cet accès au code source ?

Le retour est pas enorme.

De temps en temps on recoit un bug report d'une boite qui a les sources, mais la plupart du temps c'est simplement qu'ils sont tombes sur un bug, et grace a l'acces aux sources ils ont debugge et corrige le probleme tous seuls et nous envoient le fix pour qu'on l'ajoute si on l'accepte. J'ai pas encore vu un seul bug ou un gars s'etait promene dans les sources pour le fun et avait trouve un bug, ca venait toujours d'un probleme rencontre et d'un debuggage.

La plupart des boites se contentent de passer par notre support quand elles ont un bug, on s'occupe ensuite de debugger/fixer le probleme et leur envoyer un patch.

MS ne fait que repondre a une demande et ne le fait pas pour en tirer profit(et encore ce profit est plus que theorique).

C'est les administrations/gouvernements qui veulent cet acces, c'est pas MS qui veut des gens pour lire son code. MS va pas leur donner le beurre et les payer pour le manger.

Quand a ameliorer le produit, reste encore a voir la proportion de bugs trouves en lisant du code compare aux bugs trouves par test, et tu verras vite que tres tres peu de bugs sont trouves par lecture de code, et c'est valable pour les softs open source.

J'en doute beaucoup.

Je connais peu d'administrations qui s'inquietent pour la sante de MS, vu que l'on assez d'argent de poche pour tenir plusieurs annees avec nos depenses actuelles et sans rien vendre.

Et vu qu'on est encore largement dans le noir et pas pret de se retrouver avec 0 ventes, la perennite de MS a moyen terme du moins ne se pose pas du tout.

Le multi-threading est moins portable Ca je veux bien, c'est effectivement un probleme. De plus, dans ce cas précis avec mplayer l'utilisation d'ipc pour la mémoire partagé est suffisant et sans le moindre coût. L'utilisation dans ce cas précis de semaphore doit être superflux. Ca c'est faux pour la simple et bonne raison que les 2 process doivent se synchroniser l'un l'autre pour etre sur qu'un process ne lit pas trop, et que l'autre process ne decode pas trop, etc... Bref, utiliser des primitives de synchro est inevitable, et utiliser des spin-lock pour ca est bcp plus efficace qu'un semaphore qui implique un context-switch.

Que je sache, les journalistes ont encore le droit de dire la verite.

Ils sont juste plus facile à coder. L'exemple typique sont les serveurs multi-threadé qui enfle à chaque nouveau connecté. Si TUX (serveur web kernel plus rapide encore que khttpd) déchire tant c'est bien parce que il n'utilise pas un thread par connection ! On est bien d'accord qu'utiliser un thread par connection est une connerie, c'est un coup a se prendre un DoS a coup sur, mais c'est pour ca que le concept de thread pool existe. Mais si tu jettes un oeil sur la plupart des softs serveurs, les plus performants utilisent courramment plusieurs process ou plusieurs threads, ce qui revient plus ou moins au meme(qqe segments de memoire partagee par-ci par-la et c'est presque la meme chose). Ce n'est pas un hasard. SQL Server, Oracle, Zeus, Texis,... Tous ces softs utilisent plusieurs threads/process plutot qu'un seul thread, et ils n'ont pas ete ecrits par des manchots.

Actuellement mplayer utilise deux proces (et non deux threads !) : - un pour la lecture - un pour le décodade et affichage Les deux proces sont utilisés uniquement si l'option -cache est spécifié. L'utilisation de deux proces est intéressante pour un fichier avi sur le réseau (http://....) car le noyau ne peut pas "bufferiser" ce qui est sur le réseau. En gros, il fait deja ce que je recommande :+) Avoir 2 threads ou 2 process n'est pas tres different, avoir 2 process rend les choses un peu plus compliquees car il faut gerer soi-meme les segments de memoire partagee mais a part ca il n'y a pas grande difference, un thread est moins lourd a creer qu'un process sur la plupart des architectures(normal, il y a moins de boulot a faire). Sans compter qu'avoir 2 threads plutot que 2 process, ca permet d'utiliser des spin-locks(bcp + rapide que des mutex dans bcp de cas car pas de context-swtich) sans se casser la tronche a gerer soi-meme leur creation dans des segments de memoire partagee. Bref, mieux vaut avoir des threads au bout du compte, ca simplifie.

Ce que tu décris s'appelle les acces asynchrones ou non bloquant (asyncIO). Il me semble que la glibc sait faire ça depuis longtemps elle même et que linux 2.4 le prends en charge maintenant commeun grand.

Il est donc parfaitement inutile de programmer un thread pour ça.


Non, ce que je decris c'est une methode naturelle d'utiliser au mieux les perfs, que ta machine soit SMP ou pas, le soft fera au mieux (rien n'interdit d'utiliser les async I/O dans un soft multithread, c'est meme conseille), tout en simplifiant le design.

De plus, lors d'acces io, si le temps est trop long, le scheduler peut décider de donner la main à un autre process (cela se voit facilement avec l'utilisation d'un lentissime printf). Tu ne perds donc aucun cycle.

Exact, ce qui revient a dire que pendant que l'acces I/O s'effectue, ton process qui est sense afficher une video est stoppe.
Hors le but ici ce n'est pas d'economiser au maximum des cycles, c'est d'avoir une video qui s'affiche de maniere fluide, et de faire du boulot en avance en prevision de problemes futurs.

Si les threads s'imposent de plus en plus comme le modele a suivre c'est pas pour rien, c'est definitevement plus efficace que le modele monothread.

mplayer fait :
1) lecture depuis le disque
2) decodage
3) affichage

Vu le type d'operation effectue, il est evident qu'un model multithreade est plus efficace pour ce type de soft.

Faire sequentiellement de la lecture(qui revient a s'arreter et attendre que le systeme d'I/O complete la requete), decodage, puis affichage, c'est perdre du temps.
Tu peux tout a fait avoir un thread qui lit depuis le disque et stocke les buffer en RAM et d'autres threads qui s'occupent du decodage et de l'affichage pendant que l'operation d'I/O du/des buffers suivants est effectuee, ca c'est un modele qui optimise l'utilisation du CPU et qui te donne un player performant.

J'aurais presque envie d'ajouter quelque mots sur les I/O completion ports, mais je vais aller dormir un peu avant :+)

Tu n'as jamais du faire de softs multithreads pour dire un truc pareil.

Un exemple tres simple pour mplayer, ce qu'il faut faire :
1) lire les donnees
2) les decoder
3) les afficher

Le point 1) implique des acces disque, chose EXTREMEMENT lente par rapport aux acces memoires et autres operations.
Bref, si tu fais un soft monothread, ton soft passe son temps a lire, stopper, decoder, afficher, lire, stopper, decoder, afficher,...

Si tu as 2 threads, tu as un thread qui s'occupe de lire les donnees du disque, pendant que l'autre s'occupe de decoder/afficher.

Resultat des courses:
- Ton soft multithread est plus rapide qu'un soft monothread, car mplayer ne se tourne pas les pouces pendant que les donnees sont lues depuis le disque.

De meme, ce soft multithread pourra faire du boulot EN AVANCE, ce qui evite d'avoir besoin de ressources CPU plus tard, ce qui evite des saccades et autres dans le cas ou elles ne seraient pas disponibles,...

La regle c'est : Fais le boulot quand tu as le temps plutot qu'attendre le derniere moment et te retrouver dans un cul de sac.

Le multithread au total ca prend effectivement quelques cycles de plus, mais en temps, ca en prend moins, car ca gaspille moins de cycles, c'est ca le miracle.
Les machines en general gaspillent un nombre de cycles enorme a ne rien faire, et les lenteurs viennent du fait que plusieurs softs demandent des ressources au meme moment, faire du travail a l'avance, ca evite ces problemes, faire du multithread pour des softs qui font pas mal de calculs sur des donnees lues depuis le disque, c'est gagner enormement en perfs.

Toi non, mais si une autre personne branchee sur ta machine lance un truc un peu lourd, tu l'as dans le fion avec ton film.

Et le fait est que l'on est en train de se diriger vers ce genre de chose pour les PC de maison aussi, avec genre une machine qui est au centre d'un tas de bordel qu'elle controle, et tout ca tourne en arriere plan, et tu n'as aucune idee de ce que tel periph voudra faire demain pendant que toi tu seras en train de regarder ton DivX ou autre, donc autant faire les choses bien des le debut plutot qu'avoir un design limite qui demandera encore plus de changements plus tard.

Ben desole mais je pense au contraire que l'approche threadee est bien plus judicieuse.

Ca permet de :

1) Faire le boulot tant que tu as le temps, tu ne sais pas si dans les 2 minutes qui suivent toto ne va pas lancer une compile avec un make -j 25 pour le fun ou autre truc bourrin qui va etrangler ton mplayer niveau acces CPU

2) Balancer la charge, plutot qu'avoir ton mplayer qui passe de 5 a 20% d'utilisation de temps en temps, la courbe d'utilisation CPU s'adoucit, ce qui est bien mieux point de vue temps de reponse

3) Le design est plus propre, et tire parti au mieux des perfs du systeme. Parce qu'il faut bien se souvenir que les x% de cycles CPU utilises par mplayer pendant un moment donne(et qui auraient pu etre utilise avant quand il n'y avait pas urgence) sont x% de cycles que les autres softs ne peuvent pas utiliser, et peut-etre qu'ils en auraient besoin eux.

Oui, c'est celle de RMS et bcp d'autres, et en meme temps bcp d'autres gens en ont une autre definition, qui est basee sur ce que j'ai explique, l'origine du mot hacker.

Quand a imposer des definitions uniques, ben je suis pas forcement contre, mais reste a savoir quelle definition imposer, et je ne considere certainement pas celle de RMS comme la seule definition valide.

Le truc est que la definition que ESR donne a "hacker", c'est sa definition, ce n'est pas une verite universelle. cf. plus bas, hacker ca vient de "to hack", et quand tu vois le sens du mot, tu te rends compte que ca peut tres bien s'appliquer a quelqu'un qui penetre un reseau informatique ou autre.

Belle exemple de connerie. Le service pack qui enleve les icones, etc... c'est le SP3. Tu m'expliqueras comment t'as fait pour installer un service pack apres ca, vu que le SP4 est pas encore sorti.

Le groupe d'indiens est pas specifiquement responsable de la compilation de Windows, car ils sont partout dans Microsoft, mon chef est indien, le chef de mon chef est indien, je ne sais combien de mes collegues sont indiens,... Sinon, oui effectivement ceux que je vois sont souvent tres bons(pas tous des dieux non plus, mais ils sont bons), cependant je sais pas si ca vient du fait que tous ceux sortant des ecoles en Inde sont forts, ou simplement que le processus de selection aux interviews a vire les mauvais. A mon avis c'est un peu des deux, mais croire que les indiens sont embauches car ils bossent 24h/24 pour pas cher c'est une anerie, ils sont tout aussi bien payes que n'importe qui, c'est simplement que l'Inde de par sa taille et son systeme educatif a un grand nombre d'informaticiens de bon niveau. Il y a surement des boites vereuses qui profitent du fait que les indiens veulent venir aux USA pour les faire trimer comme des anes, mais ca n'enleve rien a leur qualite et a mon avis ce n'est pas la majorite des entreprises.

Que ESR explique que le terme "hacker" signifie un type qui pond du code, je veux bien, ca n'empeche que bcp de gens avant ESR appelaient "hacker" les gens qui se glissaient dans les reseaux et autres.

Ca vient tout simplement du verbe "to hack" qui selon mon cher Larousse veut dire "taillader, tailler a la hache", etc...

Ce qui s'applique tres bien a quelqu'un qui penetre un systeme informatique.

Rien ne t'oblige a l'accepter, il te suffit de prendre une distrib Linux ou un Mac si le contenu de Windows ne te plait pas.

le danger est surtout qu'ils en abusent pour refourguer tout et n'importe quoi dans ce qu'ils appellent un "OS", pour anéantir la concurrence ("Ben pourquoi j'installerais autre chose, ça existe déjà et c'est déjà sur mon OS ?"). Il suffit de voir les ajouts de XP pour s'en rendre compte : Media Player, décompression Zip, IE (bon d'accord il y était déjà avant, mais pour moi ça n'a rien à voir avec l'OS).

Ca te gene pas qu'il y ait une stack TCP/IP dans Windows ?

C'est ou que tu trace la limite pour ce qu'on peut mettre dans un OS ? En quoi cette limite que tu traces serait acceptable pour tout le monde ?

Ouh lala, il est fache dis moi :+)

Quel rapport avec le schmilblick ? T'avais juste envie de jeter ton fiel la maintenant histoire de foutre la merde dans une news qui n'a rien a voir vu qu'ici ca parle de Sun/Java <-> MS ?

Je vais etre gentil pour tout le monde, je vais eviter de plonger dans ton troll(on l'a deja fait 15x celui-la, faut innover sinon c'est pas marrant) histoire que ca reste lisible.

Allez, va prendre un valium, tu te sentiras mieux apres.

Microsoft a essayé de marginaliser la Java en sortant une version incompatible du langage avec Windows

Je tiens a dementir, nous n'avons rien contre ce type de danse chez Microsoft !

PS pour les moderos: Il y a un message subliminal pour vous dans ce post.

Allez hop -->[] avant de recolter mes premiers [-]

Non, ce qu'il faut a Vulcan, c'est savoir ou se trouvent les blocs, jumps, etc...

Dans n'importe quel compilateur, tu as cette etape ou tu transformes en binaire, et c'est la qu'il se greffe.
Vulcan ne depend pas du langage, il ne depend pas du fait que tel langage permet les fonctions virtuelles, ou autre feature. Il a juste besoin de connaitre la tronche de ton binaire au final, et quand je dis au final, ca veut dire une fois transforme en langage machine x86, IA64 ou MSIL.

Israel n'a absolument rien a foutre de l'ONU, sauf quand l'ONU se range de leur cote, ce qui n'arrive quasiment jamais vu les pratiques degueulasses d'Israel.

Resultat: Israel n'a effectivement rien a branler de l'ONU, ils savent que leur petit copain americain va bloquer l'ONU pour les proteger a chaque fois qu'ils font un truc ignoble.

Le jour ou l'ONU cessera d'etre un empire feodal ou 5 seigneurs ont plus de droits que les autres, le monde se sentira bcp mieux, mais d'ici la beaucoup de gratte-ciels vont tomber je sens.