Ici il y a un team complet(le mien) qui ne fait qu'une chose : s'occuper de sortir des hotfix et des service packs pour les bugs dans Windows, on ne fait absolument RIEN d'autre.
Les devs qui ecrivent le produit sont juste a cote de nous, on va les voir quand on a des questions tordues sur le pourquoi de ce qu'ils ont fait, mais ils ne s'occupent pas de corriger les bugs(si ce n'est etre sur qu'ils ne sont pas non plus dans la prochaine release).
Vu que le dev dans ces cas la c'est moi de temps en temps, je suis plutot bien place pour savoir comment on accepte un bug ou pas, et effectivement, si le bug on n'arrive pas a le reproduire on le corrige pas, normal vu qu'on peut pas le trouver...
Quand au cote commercial, ben je doutes que tu trouves le moindre exemple pour appuyer cela.
- J'ai 8 machines dans mon bureau qui sont toutes avec 128Mo de RAM(dont ma machine de dev) + 2 avec 64
- A la maison j'ai 2 bi-pro avec des tonnes de RAM mais c'est pour des raisons liees au developpements que je fais chez moi qui demandent des tonnes de RAM a partir d'un certain seuil.
Si c'etait aussi insupportable que ca avec 128Mo, j'aurais passe ma machine de dev a 256 ou plus vu que je passes mes journees et ces derniers temps meme mes nuits devant, hors j'en ressens pas le besoin, et vu le post plus haut il semble que je sois pas le seul.
Ben justement moi mon avis est que la courbe est la meme et qu'il n'y a aucune difference.
Je sais pas, il faudrait faire des statistiques serieuses/sondages/recensement/... pour voir si ca se verifie en prenant un tres large echantillon(petits softs et gros softs, ...) mais selon moi il n'y a aucune difference ou alors hyper-minime.
C'est un peu vrai effectivement, mais ici on recoit un grand nombre de bug reports de la part d'entreprises, car la les gens veulent avoir le bug corrige vu que ca affecte leur travail, et l'avantage est que dans les grosses entreprises ils ont souvent un departement IT avec quelques types qui savent ce qu'ils font contrairement a leurs collegues et qui font meme de temps en temps le debuggage eux-meme.
Sinon, les neuneux qui ont paye la version beta de XP et qui ont fait des bugs reports, ils ont recu la version finale gratuitement, au final ils ont un soft plus stable, ils ont paye l'OS moins cher, ils peuvent se la jouer branleur devant leur copains qui en ont rien a foutre car ils ont l'OS avant les autres, et ils comprennent mieux comment il fonctionne, pour certains ca peut etre interessant.
Oui mais la tu compares un driver et l'API qui est au dessus(GLX/OpenGL/Mesa) avec un driver et son API(DirectX), normal que les perfs soient a peu pres identique tant que les drivers sont ecrit correctement et que l'API est pas pourri.
Il faut comparer les primitives GDI avec les primitives des fonctions graphiques de X-Windows, c'est ca l'equivalent dans ce cas la.
Dans X-Windows si n'importe quelle primitive graphique torche, il n'y a que X-Windows qui torche, pas le systeme.
Sous NT/2000, il faut qu'une des quelques primitives torche pour que le systeme tombe, si une des API GDI au dessus qui appelle cette primitive torche, le systeme ne tombe pas. C'est tres localise.
Oui c'est vrai, n'importe qui peut rechercher ou se trouve le bug.
1) ca veut pas dire que tout le monde le fait
2) c'est quand tu tombes sur le bug, quasiment personne ne s'amuse a lire le code des softs pour faire un audit, sauf chez undesBSD.
Dans le proprio:
1) Ben ca c'est moins faisable c'est sur.
2) Autre methode: les gens envoient un bug report a l'editeur en disant quelles etapes ils ont faites et quel a ete le resultat, ensuite c'est le dev qui chasse le bug, et vu que c'est son code et il le connait par coeur, plusieurs fois il passe meme pas par le debuggeur, il se dit "p*tain ce que je suis c*n!" et il va corriger le bug tout de suite.
Comment marche un swap:
Objectif: garder en RAM physique les pages qui sont le plus susceptibles d'etre appelees.
--> les pages les moins utilisees finissent sur le swap quand pas assez de RAM physique.
Cas 1)
Quand tu lis un fichier:
le fichier est mappe en RAM, et pour optimiser la choses la VM lit des pages 'en avance' --> des pages ont besoin d'etre chargees en RAM. Si tu copies un gros fichier, le systeme charge toutes les pages du fichier, pour ca il doit faire de la place --> tous ces softs que t'as pas touche depuis longtemps(-> qui ont peu de probabilite d'etre retouches dans un futur proche) tombent dans le swap.
Cas 2)
Tu as 1-2 softs qui tournent en background et qui consomment 30Mo de RAM, mais ton desktop lui ne fait rien.
Ces softs consomment au total 30Mo de RAM au total, mais c'est en fait un amas d'allocations/deallocations, si les allocations ne peuvent pas se faire dans les blocs desalloues car les tailles ne sont pas compatibles, il faut allouer de nouvelles pages --> il faut les mettre en RAM --> il faut mettre des vieilles pages sur le swap --> ton desktop part sur le swap
Cas typique de la memoire fragmentee car le soft alloue sa memoire comme un porc.
Voila, c'est assez primitif comme explication mais ca t'eclaireras peut-etre.
Oui, et dans la licence MS il est dit la meme chose que dans la GPL, et dans la licence Adobe aussi, et dans la licence Apple aussi, et dans la licence Symantec aussi, et ....
Tout le monde fait ca, car il est IMPOSSIBLE de garantir un soft 100% bug free, alors garantir un truc dont tu sais qu'il va te retomber sur la gueule a un moment ou un autre, j'en connais pas beaucoup qui le feraient.
Bon j'aurais pu effectivement ne pas mettre cette phrase car ca ne refletait que mon point de vue et c'etait pas vraiment en rapport direct avec la news, OK je fais mon mea culpa.
Mais en meme temps je trouvais que ca pouvait prouver a certains de ces "gros boeufs" comme tu les appelles qui s'evertuaient a m'expliquer que Open Source = moins de bugs a coup sur que proprio que ce n'est pas forcement toujours vrai.
Si quelque uns arrivent a comprendre cela de cet article en faisant le rapprochement, ca sera toujours un point positif.
Non serieusement, c'est clair que c'est pas prouvable a 100% vu que vous pouvez pas voir le code, mais des centaines de personnes hors MS l'ont vu dans un tas de boites differentes.
Ca aurait fini par se savoir si c'etait le cas vu l'attrait que ce genre de news peut avoir, hors ca n'est jamais arrive.
La GDI dans le kernel(quelques primitives pour etre precis, c'est pas toute la partie graphique) ca amene comme desavantage:
- un risque de bugs supplementaires dans le kernel vu que ca amene du code en plus.
et comme avantage:
- une plus grande rapidite
Partant de la, il y avait un choix a faire, MS a voulu prendre le risque, et moi je trouves que le resultat est pas mal(Win2k/XP), je dirais pas que c'est 3x mieux que si on l'avait pas fait, mais je ne trouves pas que ca a eu des repercussions negatives.
NT4 etait pas tres stable, mais il faut voir pourquoi, est-ce que c'etait a cause de ces primitives rajoutees au kernel ? oui il y a eu quelques bugs la-dedans qui ont ete corriges depuis. Depuis le debut de Win2000, on n'en a trouve aucun dans cette partie du kernel. Si NT4 plantait c'etait a cause d'autres bugs.
Quand a la serie 9x, bon moi j'ai probablement une opinion pire que la plupart des gens ici sur ces OS du point de vue technique, donc on va pas s'etendre sur ces bouses.
Le serveur telnet, c'est sur qu'il est pas top, mais en passant, si t'as des plaintes justifiees et reproduisibles quand au serveur telnet pour Win2k(bugs, standard pas respecte,..), envoie les moi et je m'occuperai de la chose. SVP, pour les bugs ca serait cool d'avoir des etapes pour reproduire la chose...
Quand a NT6, ben j'ai probablement pas le droit d'en parler, donc j'ai rien lu.
Cites moi donc UNE SEULE ligne de code du noyau NT qui a ete rachetee a qui que ce soit.
NT c'est 100% MS.
Ils ont engage Dave Cutler et d'autres gars de chez DEC et l'OS a ete cree par eux.
Quand au code tiers, ben a mon avis il doit surement y avoir quelques bouts de code a droite a gauche qui viennent d'ailleurs(genre ftp.exe/telnet.exe et autres outils IP ont des parties de code reprises a une version BSD) mais je suis sur a 100% que +95% du code de l'OS a ete developpe ici.
Aucun OS n'est architecture de la meme maniere ou ne ressemble a Windows, le kernel est bien different de n'importe quel autre kernel, ...
Dans ce genre de cas, c'est probablement plus couteux et long d'essayer d'adapter un truc completement different(avec les risques que ca comporte point de vue retards/bugs/... que le reecrire.
Quand a vendre du code, ben je vois rien de choquant la dedans personnellement, qu'est ce qu'il y a de choquant a vendre du code ?
Eh, j'ai jamais dit que proprio et libre c'est la meme chose, c'est TRES clairement different.
Mais du point de vue 'soft bug free', aucun des 2 n'est exempt, c'est tout ce que je dis et RIEN d'autre. J'ai jamais dit que LES problemes etaient les memes, je dis que CE probleme est le meme, il faut pas extrapoler non plus.
Que les devs se gueulent dessus, ben ca arrive partout ca, ca n'a rien d'etonnant, et je dirais meme plus c'est bon signe pour le soft, ca veut dire que les devs s'en occupent et s'en soucient :+)
Ben la comparaison que je fais c'est le cote "bug free" c'est tout, ensuite les gens qui sont pas d'accord entre eux, bon ca aussi c'est dans les 2 mais dans le monde proprio ca se voit pas vu que les mailing-lists sont internes a l'entreprise et non-divulgees(de ce cote la on peut dire que c'est different, ca ne se sait pas), mais crois-moi, ca flame pas mal aussi chez les devs proprietaires, et pour des trucs tres tres cons parfois....
Oui je confirme, le but de Windows c'est d'etre accessible a tout le monde, donc au debutant, en tout cas c'est un critere essentiel de l'OS.
Ensuite MS a decide qu'il etait possible de faire plus que des petits serveurs web/serveurs de fichiers dans les PME et Win2000 est arrive, et la ben t'as tout ce dont l'admin a besoin pour gerer des parcs enormes de machines depuis un seul desktop.
Ce qu'il faut comprendre c'est que ta mere va pas etre capable de gerer un parc de 50 serveurs parce que pour ca il faut des competences, mais pour une utilisation "desktop" elle a absolument pas besoin d'un command line.
[^] # Re: sacré pbpg
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à -1.
[^] # Re: PBPG -1 ; modérateurs -1
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à -1.
Les devs qui ecrivent le produit sont juste a cote de nous, on va les voir quand on a des questions tordues sur le pourquoi de ce qu'ils ont fait, mais ils ne s'occupent pas de corriger les bugs(si ce n'est etre sur qu'ils ne sont pas non plus dans la prochaine release).
[^] # Re: PBPG -1 ; modérateurs -1
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à -1.
Vu que le dev dans ces cas la c'est moi de temps en temps, je suis plutot bien place pour savoir comment on accepte un bug ou pas, et effectivement, si le bug on n'arrive pas a le reproduire on le corrige pas, normal vu qu'on peut pas le trouver...
Quand au cote commercial, ben je doutes que tu trouves le moindre exemple pour appuyer cela.
[^] # Re: sacré pbpg
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à 1.
- J'ai 8 machines dans mon bureau qui sont toutes avec 128Mo de RAM(dont ma machine de dev) + 2 avec 64
- A la maison j'ai 2 bi-pro avec des tonnes de RAM mais c'est pour des raisons liees au developpements que je fais chez moi qui demandent des tonnes de RAM a partir d'un certain seuil.
Si c'etait aussi insupportable que ca avec 128Mo, j'aurais passe ma machine de dev a 256 ou plus vu que je passes mes journees et ces derniers temps meme mes nuits devant, hors j'en ressens pas le besoin, et vu le post plus haut il semble que je sois pas le seul.
[^] # Re: PBPG -1 ; modérateurs -1
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à -6.
Je sais pas, il faudrait faire des statistiques serieuses/sondages/recensement/... pour voir si ca se verifie en prenant un tres large echantillon(petits softs et gros softs, ...) mais selon moi il n'y a aucune difference ou alors hyper-minime.
[^] # Re: PBPG -1 ; modérateurs -1
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à -1.
Sinon, les neuneux qui ont paye la version beta de XP et qui ont fait des bugs reports, ils ont recu la version finale gratuitement, au final ils ont un soft plus stable, ils ont paye l'OS moins cher, ils peuvent se la jouer branleur devant leur copains qui en ont rien a foutre car ils ont l'OS avant les autres, et ils comprennent mieux comment il fonctionne, pour certains ca peut etre interessant.
[^] # Re: mouais
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à -1.
Il faut comparer les primitives GDI avec les primitives des fonctions graphiques de X-Windows, c'est ca l'equivalent dans ce cas la.
Dans X-Windows si n'importe quelle primitive graphique torche, il n'y a que X-Windows qui torche, pas le systeme.
Sous NT/2000, il faut qu'une des quelques primitives torche pour que le systeme tombe, si une des API GDI au dessus qui appelle cette primitive torche, le systeme ne tombe pas. C'est tres localise.
[^] # Re: PBPG -1 ; modérateurs -1
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à -1.
1) ca veut pas dire que tout le monde le fait
2) c'est quand tu tombes sur le bug, quasiment personne ne s'amuse a lire le code des softs pour faire un audit, sauf chez undesBSD.
Dans le proprio:
1) Ben ca c'est moins faisable c'est sur.
2) Autre methode: les gens envoient un bug report a l'editeur en disant quelles etapes ils ont faites et quel a ete le resultat, ensuite c'est le dev qui chasse le bug, et vu que c'est son code et il le connait par coeur, plusieurs fois il passe meme pas par le debuggeur, il se dit "p*tain ce que je suis c*n!" et il va corriger le bug tout de suite.
[^] # Re: sacré pbpg
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à -2.
[^] # Re: Pas tous les mêmes problèmes
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à -1.
[^] # Re: sacré pbpg
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à 3.
Objectif: garder en RAM physique les pages qui sont le plus susceptibles d'etre appelees.
--> les pages les moins utilisees finissent sur le swap quand pas assez de RAM physique.
Cas 1)
Quand tu lis un fichier:
le fichier est mappe en RAM, et pour optimiser la choses la VM lit des pages 'en avance' --> des pages ont besoin d'etre chargees en RAM. Si tu copies un gros fichier, le systeme charge toutes les pages du fichier, pour ca il doit faire de la place --> tous ces softs que t'as pas touche depuis longtemps(-> qui ont peu de probabilite d'etre retouches dans un futur proche) tombent dans le swap.
Cas 2)
Tu as 1-2 softs qui tournent en background et qui consomment 30Mo de RAM, mais ton desktop lui ne fait rien.
Ces softs consomment au total 30Mo de RAM au total, mais c'est en fait un amas d'allocations/deallocations, si les allocations ne peuvent pas se faire dans les blocs desalloues car les tailles ne sont pas compatibles, il faut allouer de nouvelles pages --> il faut les mettre en RAM --> il faut mettre des vieilles pages sur le swap --> ton desktop part sur le swap
Cas typique de la memoire fragmentee car le soft alloue sa memoire comme un porc.
Voila, c'est assez primitif comme explication mais ca t'eclaireras peut-etre.
[^] # Re: Pas tous les mêmes problèmes
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à 4.
Tout le monde fait ca, car il est IMPOSSIBLE de garantir un soft 100% bug free, alors garantir un truc dont tu sais qu'il va te retomber sur la gueule a un moment ou un autre, j'en connais pas beaucoup qui le feraient.
[^] # Re: sacré pbpg
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à -1.
Task Manager -> Performance -> Kernel Memory -> Paged ?
Euh non, ca c'est la memoire qui PEUT etre mise sur swap, ca veut pas dire qu'elle l'est.
[^] # Re: PBPG -1 ; modérateurs -1
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à 2.
Mais en meme temps je trouvais que ca pouvait prouver a certains de ces "gros boeufs" comme tu les appelles qui s'evertuaient a m'expliquer que Open Source = moins de bugs a coup sur que proprio que ce n'est pas forcement toujours vrai.
Si quelque uns arrivent a comprendre cela de cet article en faisant le rapprochement, ca sera toujours un point positif.
[^] # Re: sacré pbpg
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à -1.
T'appelles quoi "demarrage de la machine" ? avant le login ou apres ?
-1 car toujours HS
[^] # Re: troll in the news
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à -2.
Ca te va ? :+)
Non serieusement, c'est clair que c'est pas prouvable a 100% vu que vous pouvez pas voir le code, mais des centaines de personnes hors MS l'ont vu dans un tas de boites differentes.
Ca aurait fini par se savoir si c'etait le cas vu l'attrait que ce genre de news peut avoir, hors ca n'est jamais arrive.
[^] # Re: sacré pbpg
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à -3.
-1 car HS
[^] # Re: mouais
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à 10.
- un risque de bugs supplementaires dans le kernel vu que ca amene du code en plus.
et comme avantage:
- une plus grande rapidite
Partant de la, il y avait un choix a faire, MS a voulu prendre le risque, et moi je trouves que le resultat est pas mal(Win2k/XP), je dirais pas que c'est 3x mieux que si on l'avait pas fait, mais je ne trouves pas que ca a eu des repercussions negatives.
NT4 etait pas tres stable, mais il faut voir pourquoi, est-ce que c'etait a cause de ces primitives rajoutees au kernel ? oui il y a eu quelques bugs la-dedans qui ont ete corriges depuis. Depuis le debut de Win2000, on n'en a trouve aucun dans cette partie du kernel. Si NT4 plantait c'etait a cause d'autres bugs.
Quand a la serie 9x, bon moi j'ai probablement une opinion pire que la plupart des gens ici sur ces OS du point de vue technique, donc on va pas s'etendre sur ces bouses.
Le serveur telnet, c'est sur qu'il est pas top, mais en passant, si t'as des plaintes justifiees et reproduisibles quand au serveur telnet pour Win2k(bugs, standard pas respecte,..), envoie les moi et je m'occuperai de la chose. SVP, pour les bugs ca serait cool d'avoir des etapes pour reproduire la chose...
Quand a NT6, ben j'ai probablement pas le droit d'en parler, donc j'ai rien lu.
[^] # Re: troll in the news
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à -1.
Cites moi donc UNE SEULE ligne de code du noyau NT qui a ete rachetee a qui que ce soit.
NT c'est 100% MS.
Ils ont engage Dave Cutler et d'autres gars de chez DEC et l'OS a ete cree par eux.
Quand au code tiers, ben a mon avis il doit surement y avoir quelques bouts de code a droite a gauche qui viennent d'ailleurs(genre ftp.exe/telnet.exe et autres outils IP ont des parties de code reprises a une version BSD) mais je suis sur a 100% que +95% du code de l'OS a ete developpe ici.
Aucun OS n'est architecture de la meme maniere ou ne ressemble a Windows, le kernel est bien different de n'importe quel autre kernel, ...
Dans ce genre de cas, c'est probablement plus couteux et long d'essayer d'adapter un truc completement different(avec les risques que ca comporte point de vue retards/bugs/... que le reecrire.
Quand a vendre du code, ben je vois rien de choquant la dedans personnellement, qu'est ce qu'il y a de choquant a vendre du code ?
[^] # Re: troll in the news
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à -3.
probleme = "soft bug free"
Ensuite le cote devs pas d'accord, pour moi c'est pas un probleme mais un plus, ca montre qu'il y a au moins une remise en cause des choix.
[^] # Re: sacré pbpg
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à 7.
Mais du point de vue 'soft bug free', aucun des 2 n'est exempt, c'est tout ce que je dis et RIEN d'autre. J'ai jamais dit que LES problemes etaient les memes, je dis que CE probleme est le meme, il faut pas extrapoler non plus.
Que les devs se gueulent dessus, ben ca arrive partout ca, ca n'a rien d'etonnant, et je dirais meme plus c'est bon signe pour le soft, ca veut dire que les devs s'en occupent et s'en soucient :+)
[^] # Re: mouais
Posté par pasBill pasGates . En réponse à la dépêche Une bonne explication du probleme de la VM dans le kernel 2.4 et de ses implications. Évalué à 8.
[^] # Re: Fatal error: core dumped
Posté par pasBill pasGates . En réponse à la dépêche Windows XP : Attention au crash !. Évalué à 1.
Ensuite MS a decide qu'il etait possible de faire plus que des petits serveurs web/serveurs de fichiers dans les PME et Win2000 est arrive, et la ben t'as tout ce dont l'admin a besoin pour gerer des parcs enormes de machines depuis un seul desktop.
Ce qu'il faut comprendre c'est que ta mere va pas etre capable de gerer un parc de 50 serveurs parce que pour ca il faut des competences, mais pour une utilisation "desktop" elle a absolument pas besoin d'un command line.
[^] # Re: Inexact ...
Posté par pasBill pasGates . En réponse à la dépêche Windows XP : Attention au crash !. Évalué à 0.
[^] # Re: Pas possible.
Posté par pasBill pasGates . En réponse à la dépêche Windows XP : Attention au crash !. Évalué à 2.