Journal Microsoft est dans le top 5 des contributeurs de linux 3.0

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
11
19
juil.
2011

Microsoft a semble-t-il fourni 361 modifications (dont 95% par la même personne) et cela ne me semble pas énorme pour être dans le top 5. Ceci dit je n'ai pas les chiffres exactes ni à quoi ça correspond.

La source première pour plus d'info semble être lwn https://lwn.net/Articles/451243/ mais il faut être abonné.

La plupart des modifications auraient un lien avec Hyper-V, donc au final c'est peut-être beaucoup de bruit pour presque rien, mais ça m'a un peu fait bizarre d'avoir entendu "arrête de critiquer microsoft, ils font parti de ceux qui participent le plus à linux !"

Après, il n'y a pas que le noyau non plus. Mais quand même, ça fait bizarre.

  • # Chuut...vous n'avez pas vu ce journal

    Posté par  (site web personnel) . Évalué à 10.

    Non mais c'est quoi ce déflorage de la news noyau ? Traître ! Imposteur !

  • # et les implications juridique ?

    Posté par  (site web personnel, Mastodon) . Évalué à 7.

    beaucoup de bruit pour presque rien,

    Les trois derniers paragraphes sont ultimes :

    http://www.osnews.com/story/24960/Microsoft_Contributes_361_Changes_to_Linux_3_0

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 8.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: et les implications juridique ?

        Posté par  . Évalué à 3.

        Si tu suivais le lien qu'il donne dans son article tu verrais que la majorite des trucs sont dus au style : ils codaient avec le style Windows (nommage des typdefs, etc...) et ont des lors du passer gentiment au style Linux, rien a voir avec une qualite de code mauvaise.

        Ensuite il y avait des bugs dans leur code et des check-ins supplementaires pour les resoudre ? Grande nouvelle, c'est la meme chose dans le code du kernel qui voit des bugs corriges tout le temps.

        • [^] # Re: et les implications juridique ?

          Posté par  . Évalué à 2.

          Avec le lien c'est mieux: http://www.unixwiz.net/techtips/review-hv-patches.html

        • [^] # Re: et les implications juridique ?

          Posté par  (site web personnel) . Évalué à 5.

          Si tu suivais le lien qu'il donne dans son article tu verrais que la majorite des trucs sont dus au style

          L'article parle des 200 commits initiaux au moment de l'entrée du pilote dans -staging. A ce moment là il y a vraiment eu plus de 200 commits, écrits en grande partie par Greg KH, pour changer le style du code et le mettre au normes Linux.
          C'est déjà un peu bizarre de soumettre un pilote Linux avec des conventions de codage Windows mais passons.

          Là pour le noyau 3.0 ce sont 300 commits en plus qui ont été écrits par les mecs de Microsoft pour corriger leur machin. Donc on ne parle plus du style là mais bien de la fiabilisation.

          • [^] # Re: et les implications juridique ?

            Posté par  . Évalué à 10.

            à pour le noyau 3.0 ce sont 300 commits en plus qui ont été écrits par les mecs de Microsoft pour corriger leur machin

            Comme tu es quelqu'un de consciencieux, tu as surement ete regarder rapidement tous ces commits pour voir quelle quantite est simplement du nettoyage (deplacement des fonctions pour virer les predeclarations, regroupage pour eviter les indirections, suppression du code inutile, renommage pour virer le camelcase, etc.).

            Comment, non? Tiens, cadeau. Il n'y a que 4 page a regarder, ca suffit pour se faire une idee du type de boulot. Un indice: la majorite c'est toujours du nettoyage pour mieux se conformer aux normes du noyau et un peu de re-architecturage de code. Tres peu de correction de bugs ou de reecriture de fonctions parce que c'est ecrit avec les pieds.

            • [^] # Re: et les implications juridique ?

              Posté par  (site web personnel) . Évalué à 10.

              Tu as raison, en regardant les patchs il y a énormément de nettoyage et seulement quelques vraies corrections de fond.

              • [^] # Re: et les implications juridique ?

                Posté par  . Évalué à 4.

                Y’a pas un problème de métrique dans ce cas là ? Si ce sont des changements de style et du nettoyage superficiel, qui fort passer dans le top 5, ce dernier est-il pertinent ?

                • [^] # Re: et les implications juridique ?

                  Posté par  (site web personnel) . Évalué à 7.

                  Oui clairement il faut se méfier de cette métrique. Un mec qui sépare ses changements dans plein de commits sera vu comme plus "productif" qu'un autre développeur qui préfère faire des commits plus gros.
                  D'ailleurs Microsoft est cinquième en terme de commits mais si on regarde en terme de lignes changées alors ils redescendent en 15ème position des entreprises identifiées.

                  • [^] # Re: et les implications juridique ?

                    Posté par  . Évalué à -1.

                    Je ne sais meme pas si on peut appeler le nettoyage d'un code (deja commence par GHK) comme etant un truc hyper important.

                    • [^] # Re: et les implications juridique ?

                      Posté par  . Évalué à 1.

                      Ça peut même être négatif : ça signifie que Microsoft ne se donne pas les moyens pour intégrer du code aux normes du projet auquel il contribue.

                      Remarque, c'est peut-être déjà le cas en interne, ce qui expliquerait la qualité de certains de leurs logiciels…

                      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                      • [^] # Re: et les implications juridique ?

                        Posté par  . Évalué à 0.

                        Ça peut même être négatif : ça signifie que Microsoft ne se donne pas les moyens pour intégrer du code aux normes du projet auquel il contribue.

                        Vu que la contribution a ete contrainte et force (violation de la licence GPL) cela n'est pas etonnant et de plus les dires de GHK avait ete bien clair sur le sujet: le code etait tout pourrit. Ce qui est curieux c'est qu'ils se remettent a faire quelques choses dessus apres l'avoir totalement delaisse pendant 2 ans...

                      • [^] # Re: et les implications juridique ?

                        Posté par  . Évalué à 2.

                        Tu me fais rire, ils paient justement des gens pour faire ce boulot, tu voudrais qu'ils fassent quoi d'autre ?

                        Ils auraient attendu de nettoyer le code avant de l'ouvrir, vous vous seriez plaint qu'ils trainent des pieds pour ouvrir le code, etc...

                        Quand a la qualite des logiciels, le fait que l'enorme majorite des correctifs aient ete un changement entre le style interne a MS et celui de Linux montre plutot que la qualite est bonne, il y a eu au final peu de vrai bugs.

                        • [^] # Re: et les implications juridique ?

                          Posté par  . Évalué à 1.

                          Ça y est ? Ils ont découvert les pages man ? https://linuxfr.org/users/octane/journaux/quand-microsoft-fait-de-lopen-source

                          (^_^)

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                          • [^] # Re: et les implications juridique ?

                            Posté par  . Évalué à -2.

                            Faut les comprendre, sous Linux c'est prehistorique et ils n'ont rien du genre de http://msdn.microsoft.com/en-us/windows/hardware/gg487345 pour eviter ces erreurs betes, alors que sous Windows tout le code est verifie avec ce genre d'outils constamment ce qui evite ces problemes.

                            • [^] # Re: et les implications juridique ?

                              Posté par  (site web personnel) . Évalué à 5.

                              Sparse : https://sparse.wiki.kernel.org/index.php/Main_Page
                              CheckPatch : http://www.kernel.org/pub/linux/kernel/people/apw/checkpatch/
                              Coccinelle : http://coccinelle.lip6.fr/

                              • [^] # Re: et les implications juridique ?

                                Posté par  . Évalué à -10.

                                Dommage qu'aucun d'eux n'arrive a la cheville de PREfast et je ne parles meme pas de PREfix

                                • [^] # Re: et les implications juridique ?

                                  Posté par  (site web personnel) . Évalué à 8.

                                  Ah bon.
                                  D'un autre côté avec ce genre de post péremptoire non argumenté il ne faut pas s'étonner d'être moinssé ;-)

                                  • [^] # Re: et les implications juridique ?

                                    Posté par  . Évalué à -1.

                                    Aucun de ces softs n'est capable de vraiment savoir ce qui est attendu du code, parce que le code du kernel (et de tous les autres projets des distribs quasiment) n'est pas annote.

                                    Rien ne permet de dire que le parametre length de blob(void* buffer, int length) est sense etre la longueur du buffer par exemple, ce qui empeche l'analyse statique d'etre efficace. Tu regardes le code de Windows par contre, il est quasi-entierement (voire entierement maintenant) annote du kernel jusqu'au demineur, ce qui permet aux softs genre PREfix et PREfast de verifier que le buffer qui a ete passe a la fonction dans la plupart des 32 chemins de code possible (il peut evidemment pas verifier tous les cas possibles et imaginables) a une taille au moins aussi grande que la valeur de la variable length, et que la fonction elle meme ne s'amuse pas a acceder au buffer plus loin que la valeur de la variable length.

                                    La plupart de ces softs pour le kernel se contentent de faire de l'analyse "a vue d'oeil", il ne s'agit pas de vrais processeurs et analyseurs C avec un solveur derriere pour trouver les contraintes sur les variables, ils se contentent de voir que le code repond a certaines criteres basiques genre ne pas avoir un "if (a=x)" qui sont facilement detectables.

                                    Bref, deux mondes totalement differents, un monde largement plus avance que l'autre.

                                    • [^] # Re: et les implications juridique ?

                                      Posté par  (site web personnel) . Évalué à 5.

                                      Ce que tu dis est peut-être exact, je ne m'y connais clairement pas dans ce domaine, mais dire que ces softs font de l'analyse "a vue d'oeil" est clairement faux.
                                      Sparse se base lui aussi sur des annotations dans le noyau => http://en.wikipedia.org/wiki/Sparse#Annotations

                                      Et Coccinelle est carrément un projet de recherche à lui tout seul avec une notion de "patch sémantique" qui dit bien qu'il y a une compréhension du code qui va bien au delà du "a vue d'oeil".

                                      • [^] # Re: et les implications juridique ?

                                        Posté par  . Évalué à 7.

                                        Simplement parce qu'il y a des annotations ne signifie pas que c'est pas "a vue d'oeil"

                                        Jettes un oeil au kernel, combien de fonctions sont annotees ? --> Impossible d'analyser correctement, meme si t'as un bon outil
                                        Regarde Sparse (http://linux.die.net/man/1/sparse), ou est le solveur de contraintes ? Il n'y en a pas, il est incapable de te dire par exemple qu'une boucle int b=4; while(b<5) ne s'arretera jamais car il ne peut pas comprendre l'execution du code et voir qu'aucun chemin ne permet de sortir.

                                        Tu peux en decouvrire plus sur Coccinelle ici : http://coccinelle.lip6.fr/papers/fosdem10.pdf et tu decouvriras que c'est idem, c'est des patterns et autres, il n'y a aucune comprehension reelle du code, des appels de fonction, etc... et le nombre de faux-positifs peut etre sacrement eleve a cause de cela.

                                        • [^] # Re: et les implications juridique ?

                                          Posté par  (site web personnel) . Évalué à 6.

                                          Et hop, voilà un "pertinent" bien mérité :-)

                                        • [^] # Re: et les implications juridique ?

                                          Posté par  . Évalué à 2.

                                          Je pense que le plus pertinent sera(i ?)s d'implémenter l’analyse statique sans annotation en module de GCC, puisque c'est maintenant possible. Ça permettrait de n'avoir qu'un seul outil et de ne pas ré-implémenter le parsing du code (on peut toujours imaginer un bug du parser qui est chez l'un des outil mais pas l'autre).

                                          Pour l'utilisation des annotations je ne suis pas certains que ce soit génial, mais ça peut aussi se faire de la même façon (ou avec des pragma).

                                          Comprend moi bien je n'explique pas que c'est mieux sous linux que chez vous, mais justement qu'on pourrait améliorer les choses.

                                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                          • [^] # Re: et les implications juridique ?

                                            Posté par  . Évalué à 0.

                                            A mon avis l'analyse sans annotation n'en vaut pas la peine. Elle a tellement de faux-positifs que le developpeur va vite en avoir marre et elle cause une explosion enorme des arbres d'evaluations qui rend l'analyse bcp moins efficace.

                                            Par contre utiliser gcc pour le parsing a absolument tout son sens.

                                            • [^] # Re: et les implications juridique ?

                                              Posté par  . Évalué à 3.

                                              Le truc c'est que je vois pas l'intérêt des annotation il faut garder à tout prix la cohérence code annotation. Si c'est vraiment nécessaire ça devrait faire partie du langage (qui serait de plus haut niveau et décrirais des actions de plus haut niveau).

                                              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                              • [^] # Re: et les implications juridique ?

                                                Posté par  . Évalué à 3.

                                                Je suis 100% d'accord, mais la realite est que le code est ecrit en C/C++ et qu'on va pas remplacer des millions de lignes de code du jour au lendemain, et que pour un OS c'est d'ailleurs au jour d'aujourd'hui le seul choix realiste(aucun OS grand public n'est ecrit dans un autre langage pour l'instant meme si certains y travaillent...).

                                                Resultat, faut faire avec en attendant, et pour faire de l'analyse statique efficace de C/C++ les annotations sont necessaires car le langage est trop laxiste pour inferer ces elements.

                                    • [^] # Re: et les implications juridique ?

                                      Posté par  . Évalué à 3.

                                      Je comprend l’intérêt de ces outils mais je trouve que l'approche est dommageable.

                                      AMHA, il aurait mieux valut créer un langage qui permet de décrire le programme à la manière de ses annotations pour ensuite le compiler. Quitte à commencer par ne faire qu'un préprocesseur du C/C++ déjà présent, pour accompagner la transition.

                                      Le problème c'est que là le code est écris deux fois une fois en C et une fois en annotation.

                                      Mais j'imagine qu'avec C#, cela aurait fait beaucoup de langages … (je sais que dans vos carton il y a un OS en C#).

                                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                      • [^] # Re: et les implications juridique ?

                                        Posté par  . Évalué à 3.

                                        Ben si on devait tout refaire de 0 y compris en changeant l'education des gens, il y a plein de trucs qui se feraient differemment evidemment, mais faut vivre avec l'existant, avec les outils existants, avec ce que les gens connaissent et en sachant que faire adopter une nouveau language n'est pas chose facile.

                                    • [^] # Re: et les implications juridique ?

                                      Posté par  . Évalué à 1.

                                      C’est intéressant ce que tu dis. Mais présentement, comment ce genre d’analyseur aurait pu éviter la confusion des arguments dans memset ?

                                      Parce que memset(pointer, sizeof(data), 0); est valide et me semble difficilement repérable. Encore là, comme le 0 est en dur, on peut se douter que cette ligne est idiote. Mais dans le cas où le 0 aurait été une variable connue qu’à l’exécution, variable suffisament contrainte pour ne pas être plus grande que la taille du tableau de pointer ? Dans ce cas, je vois mal comment un outil quelconque d’analyse aurait pu trouver l’erreur.

                                      Dans tous les cas cela montre qu’il ne faut pas trop se reposer sur ce genre d’outils. Ne serait-ce parce qu’il se peut que « l’erreur bête » donne quelque chose de valide à travers l’analyseur, la compilation et les tests. En cas de doute, la consultation de la documentation est primordiale. Alors les pages de man sont peut-être préhistoriques, mais c’est typiquement le genre de cas où leur légèreté et leur rapidité leur permettent d’être efficaces.

                                      • [^] # Re: et les implications juridique ?

                                        Posté par  . Évalué à 2.

                                        Le parametre de memset a zero n'a aucun sens, il est sense etre positif --> flag

                                        Que la variable soit connue a l'execution n'est pas forcement un probleme parce que certains de nos outils d'analyse evaluent les arbres et leurs contraintes et sont capables de voir quelles valeurs peuvent atterire dans une variable (pas tout le temps non plus et ils peuvent evidemment pas evaluer toutes les branches a toutes les profondeurs, on n'a pas encore trouve le graal), ces solveurs permettent par exemple de trouver si ton code accede a un buffer hors de sa taille, meme avec index variable.

                                        Dans tous les cas cela montre qu’il ne faut pas trop se reposer sur ce genre d’outils. Ne serait-ce parce qu’il se peut que « l’erreur bête » donne quelque chose de valide à travers l’analyseur, la compilation et les tests. En cas de doute, la consultation de la documentation est primordiale. Alors les pages de man sont peut-être préhistoriques, mais c’est typiquement le genre de cas où leur légèreté et leur rapidité leur permettent d’être efficaces.

                                        Ces outils ne doivent evidemment pas etre le debut et la fin, mais ils sont d'une utilite vraiment enorme, la difference en qualite de code avant qu'on les ait adopte et apres est tout simplement incroyable.

                            • [^] # Re: et les implications juridique ?

                              Posté par  . Évalué à 4.

                              Tu veut dire que chez MS on réfléchis après avoir écris le code ?

                              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                            • [^] # Re: et les implications juridique ?

                              Posté par  (site web personnel) . Évalué à 0.

                              un truc qui me titille :
                              pourquoi tant d'outils veulent penser à la place du dev ?
                              Ces outils qui finissent par nous coincer dans une forme de pensée unique, passant à coté de solutions fonctionnelles et moins bloat (C vs C++ par ex).
                              Non ?
                              Certes, certains projets ou les lignes de code se comptent en millions sont humainement incontrôlables sans outils automatisés. Mais ne sommes nous pas perdus en route ?

                              • [^] # Re: et les implications juridique ?

                                Posté par  . Évalué à 2.

                                Ces outils viennent d'une approche realiste : le dev, aussi bon qu'il soit, va faire des erreurs.

                                L'objectif est donc de trouver ces erreurs, et le plus tot possible.

                                C'est tout, ces outils ne t'obligent a rien niveau langage ou autre, ils programment pas a ta place, ils te forcent pas a changer ton code, tu peux avoir le meme genre d'outils dans differents langages ou autres, ...

                                C'est vraiment 99% positif et 1% negatif (le temps passe a regarder les qqe faux-positifs signales)

                      • [^] # Re: et les implications juridique ?

                        Posté par  . Évalué à 6.

                        https://linuxfr.org/users/nedflanders/journaux/comment-ça-marche-chez-microsoft

                        On avait vu ici auparavant que chez Microsoft, il n'y a pas de conventions de code et qu'ils en sont fier. Depuis, l'article a été supprimé :(

                        DLFP >> PCInpact > Numerama >> LinuxFr.org

                • [^] # Re: et les implications juridique ?

                  Posté par  . Évalué à 4.

                  Bienvenue dans le monde merveilleux des métriques. Où certaines personnes vont dupliquer leur code pour pour de meilleures métriques, en nombre de ligne, plutôt que de factoriser, où il y aura un commentaire "Je mets a+b dans c" devant la ligne c := a+b; car il faut X% de lignes de commentaires, où l'on viendra te demander "pourquoi il a fallu 8 jours pour faire ce test, alors qu'il en a fallu deux pour faire celui là, et que la moyenne est à 5. Alors qu'évidemment, c'est plus simple de tester de la régulation thermique (trop froid je chauffe, trop chaud j'arrête de chauffer, avec un calcul de médiane sur des temperatures) qu'un algo de contrôle d'attitude.

                  Les métriques, c'est mal.

                  Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                  • [^] # Re: et les implications juridique ?

                    Posté par  (Mastodon) . Évalué à 4.

                    "Lorsqu'une mesure devient un objectif, elle cesse d'être une mesure". Loi de Goodhart

                  • [^] # Re: et les implications juridique ?

                    Posté par  . Évalué à 4.

                    C'est pareil pour tous les métiers, pas que pour les développeurs, que ce soit les téléconseillers, les chargés de recrutement, les toubibs, les flics etc.
                    C'est "defective by design" "d'incentiver" des gens par rapport à des indicateurs sur lesquels les "incentivés" peuvent modifier l'input (ou la méthode de calcul des indicateurs).
                    Mais tant que les décideurs n'entendent rien ni à la cybernétique, ni à la dynamique de groupe, c'est pas prêt de changer.
                    "Quand on ne prend les gens que pour des cons, on risque l'effet boomerang."

                    Enzo Bricolo

              • [^] # Re: et les implications juridique ?

                Posté par  . Évalué à 10.

                Ils pourraient en profiter pour faire du ménage dans le reste du noyau.
                Microsoft, la nouvelle femme de ménage de chez Linux. Elle indente les coussins sur le canapé, elle met des commentaires sur les surgelés, elle supprime les processus inutiles sur le sol. Elle fait rentrer les utilisateurs dans votre salon, vérifie les droits d'accès. Mais elle fait sûrement encore d'autres choses...

  • # GPL

    Posté par  . Évalué à 6.

    La plupart des modifications auraient un lien avec Hyper-V, donc au final c'est peut-être beaucoup de bruit pour presque rien

    L'information importante que j'en retiens c'est qu'ils écrivent du code sous licence GPL. Considéré comme le mal il y a encore quelques années.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: GPL

      Posté par  . Évalué à 3.

      Oui, ils le font, mais avec une pince à linge.

    • [^] # Re: GPL

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Si je ne dis pas de bêtise, ils écrivent du code sous licence GPL juste par-ce que à la base ils ont violé la licence GPL justement, donc on ne peut pas dire qu'ils ont changé d'avis volontairement (même si effectivement du coup ils participent au "mal")

    • [^] # Ta signature

      Posté par  . Évalué à 5.

      Milite pour la suppression de l'unicode et de tout ces carateres diacritiques (ASCII est notre sauveur)

      Il y a comme une co(q)uille dans ta signature.
      Ou alors je suis curieux de savoir ce que sont des « carateres »...
      Quelque chose d’intermédiaire entre des caractères et des cratères ?
      Ou alors, ça a avoir avec des carters ?
      Ou des cars à terre ?

      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

      • [^] # Re: Ta signature

        Posté par  . Évalué à 4.

        Ou alors je suis curieux de savoir ce que sont des « carateres »...

        C'est parce que le c n'est pas ASCII.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Ta signature

          Posté par  . Évalué à 2.

          C'est parce que le c n'est pas ASCII.

          Dans ce cas, il faut enlever les autres :
          « Milite pour la suppression de l'uniode et de tout es arateres diaritiques (ASII est notre sauveur) »

          Pas très lisible à mon goût, l’ASII...

          « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

          • [^] # Re: Ta signature

            Posté par  . Évalué à 7.

            Ah si !

          • [^] # Re: Ta signature

            Posté par  . Évalué à 1.

            Dans ce cas, il faut enlever les autres :

            C'était la blague _o_

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Ta signature

        Posté par  . Évalué à 9.

        La diacritique est aisée mais le dard est difficile.

      • [^] # Re: Ta signature

        Posté par  . Évalué à -1.

        C'est des caractères qu'il vaut mieux ne pas emmerder.

    • [^] # Re: GPL

      Posté par  . Évalué à 6.

      C'est surtout que tant qu'à avoir des clients qui utilisent du Linux, ils préfèrent que ce soit en faisant tourner des VMs Linux sur du Windows plutôt que l'inverse...

    • [^] # Re: GPL

      Posté par  . Évalué à 8.

      Ils sont bien obligé de s'adapter puisque la concurrence le fait. VMWare participe activement au noyau Linux (et même à Mesa). Et c'est vraiment super, quand j'installe des Linux sur nos serveurs VMWare, j'ai les pilotes VMWare optimisés out-of-the-box (pvscsi, vmxnet3 et vm-balloon). Et vu que c'est inclus dans le noyau, j'imagine que le code est pas trop merdique. Alors que les VMWare Tools personne n'a vu le code...

      Par contre c'est pas demain qu'on verra Microsoft améliorer la gestion mémoire de Linux ou un autre composant clé, c'est sûr...

    • [^] # Re: GPL

      Posté par  . Évalué à 9.

      Ils ont attrapé le cancer \o/

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # Quel scoop !

    Posté par  . Évalué à 10.

    Microsoft a semble-t-il fourni 361 modifications (dont 95% par la même personne)

    Et avec tout ça, il trouve encore le temps de venir troller comme un goret sur DLFP.
    Total respect.

    • [^] # Fenêtre, stats...

      Posté par  . Évalué à 8.

      Et
      git log leurpremiercommit..HEAD
      aurait même permis de conclure qu'ils étaient à 100% à un temps T

      De même, du 1/1/11 au 2/1/11, ils ont lancé 0 procès sur base de brevets bidons. Ils doivent donc être 100% gentils.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.