pasBill pasGates a écrit 16169 commentaires

J'expliques ca par le fait qu'Access est mal code(si c'est vraiment le probleme).

Si je t'ecris un soft pour Linux qui demande d'etre root pour envoyer un e-mail, c'est ma faute, pas celle de Linux

Ou as tu vu que ce serait MS qui signerait les softs/documents/... ?

Nulle part, tu supputes.

Ben justement, les 34 trolls precedents etaient deja la pour se faire une opinion de ce qui est connu jusqu'a maintenant ,et depuis il n'y a rien eu de nouveau.

Je vois donc mal ce que l'on peut amener de plus, surtout vu le peu d'infos disponibles sur la chose.

Les virus tournent avec les droits de l'utilisateur qui les a lances, comme sur Linux.

Tu veux donc dire que Linux n'a pas non plus de systeme de permissions ?

Ben non, personne ne sait a quoi va ressembler Palladium, y compris ici(enfin, a part les gars qui bossent dessus).
Vu qu'on a fait deja 34 fois le troll du Palladium=danger, et que personne ne sait a quoi ca ressemblera, ni meme si ca finira par exister un jour, je preferes de ne pas perdre mon temps a imaginer des trucs sans infos supplementaires.

Le jour ou on aura plus d'infos sur les contours de la bete, il y aura materiel a discussion, mais je n'ai rien vu de nouveau depuis le dernier troll^H^H^Harticle.

Ce que les gens font je m'en tapes, je parles des capacites du systeme.

Si bcp de gens utilisaient Linux en root et qu'un type debarquait et disait que tout tourne en root sous Linux et que les virus ont tous les droits, je paries que tu serais enerve et reagirais.

Dire qu'une gestion minimale des droits est un argument marketing pour MS est un gros mensonge, cette gestion de droits est presente depuis un bon moment, MS n'a pas attendu Palladium pour ca.

Non, juste quelqu'un qui sait faire la difference entre les capacites d'un systeme et la maniere dont les gens l'utilisent.

Mais faut pas oublier que dans le monde MSWin (et l'esprit des gens qui l'utilisent), tout tourne en root et les virus peuvent tout faire. Une gestion des droits, même minimale empechant ca, est pour MS un argument marketing..

Tiens, un gros mensonge.

Tu as deja essaye d'installer OpenOffice sur un Linux de 1995 ? Gnome ? KDE ?

Ben l'idee n'est surement pas de corriger les bugs dont MS n'a rien a faire vu qu'ils n'en ont pas le droit.

Quand a trouver des bugs avec les options de debug en lancant un debuggeur, ben les gens peuvent deja faire ca aujourd'hui, la version debug de Windows est dispo (on appelle ca "checked build" chez nous), les symboles aussi, le debuggeur aussi, le seul truc qui manquait c'etait les sources.

C'est pas pour autant que les gens vont se mettre a chercher des bugs dans nos softs, ceux qui ont deja les sources ne le font pas, ils se contentent de debugger lorsqu'ils ont un probleme.

Je crois en effet que le meilleur de moyen de lutter contre le terrorisme est de lutter contre la misère et/ou le désespoir qui frappent aujourd'hui la grande majorité des humains qui en ont marre de vivre dans un monde de plus en plus égoïste.

Ah... Si seulement le trisomique (desole pour les handicapes de les insulter pareillement) qui habite a la maison blanche pouvait comprendre cela, ca ferait le plus grand bien a la planete.

Malheureusement je sens qu'il vaut mieux esperer qu'il crevera etouffe par un pretzel qu'esperer qu'il va comprendre cela, c'est plus realiste.

C'etait la partie experience/connaissances (il avait pas separe les 2 cet abruti).

A lire le gars, ca aurait du etre un specialiste pour tout ce qui est methodes de test, etc... mais c'est tout juste si il savait se servir d'un ordinateur, bref il etait expert pour taper des CV bourres d'aneries dans Word et faire du blabla, mais son expertise s'arrete la.

chichtaouk = poitrine de poulet(en brochette ou pas) marinee dans une sauce tomate avec quelques epices, du citron,...

Ah j'oubliais, c'est aussi mon plat prefere :+)

MS change son OS tous les ans pour un soucis d'INCOMPATIBILITé et donc se faire plus de fric.


Gros FUD sans argument

Vu que sendmail, bind, wu_ftpd et autres sont des fromages a trou( != gruyere, == emmental) bien que leurs sources soient ouvertes depuis des annees et qu'ils soient tres repandus, le mythe du given enough eyeballs, all bugs are shallow ne vaut rien du tout.

Quand au code de Windows, il n'est pas accessible qu'aux managers bien evidemment.

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.