Journal VMware et la GPL

Posté par  .
Étiquettes :
0
16
avr.
2008
Hello,

depuis 1 mois je découvre vmware esx, je ne donnerais pas mon avis sur ce produit, sachant que au bout d'un mois il est difficile d'en avoir un objectif. Surtout quand on utilise Xen depuis 2ans.

Mon interrogation vient plutôt de la relation entre l'esx et linux. Je n'ai malheureusement trouvé pour le moment qu'un seul article qui en parle.

http://www.venturecake.com/the-vmware-house-of-cards/

Et d'apres cet article vmware violerait la GPL

  • # Module noyau binaire

    Posté par  . Évalué à 7.

    VMWare viole autant la GPL que NVidia et ATI ( et les autres moins connus) via leur driver propriétaire en mode noyau.

  • # Explication dans les commentaires

    Posté par  . Évalué à 9.

    Cet article date un peu, je ne l'ai pas relu en entier, mais de ce que je me souviens : VMWare utilise Linux pour booter, et après charge un module proprio qui est chargé de la virtualisation. Le truc, c'est qu'à priori, ce module est du code qui existait déjà avant de manière "séparée" du kernel, et qu'il a été "adapté" en tant que module. A priori, Linus ne considère pas ça comme une violation de la GPL (j'avais vu ça dans les commentaires de l'article). Et c'est souvent la défense qu'ont des constructeurs qui "adaptent" des drivers utilisés dans d'autres OS à Linux (genre Broadcom qui porte ses drivers depuis VxWorks).

    En gros, c'est "si ce code fonctionne aussi avec autre chose que Linux, ce n'est pas une violation". J'avoue que ça fait quand même une brèche énorme dans la GPL, mais c'est pas complètement idiot non plus, dans le sens où si je crée un logiciel proprio qui a la même interface (API) qu'un logiciel libre, mais que je crée aussi la lib proprio qui va avec, et que je reste dans mon coin sans utiliser de libre du tout, peut-on m'attaquer parce que mon logiciel "pourrait" fonctionner avec la lib GPL (puisqu'ils ont la même interface) mais que je ne fourni pas le code sous GPL ?

    Et on en arrive donc aussi au problème de licence d'un format ou d'une API : peut-on mettre une licence sur un format/protocole/API ? A première vue, ça parait débile, et c'est ce que fait MS avec OOXML, .Net et compagnie avec son "Open Specification Promise", même si là il se protège par ses brevets plutôt que par une licence . Mais quand on y pense, c'est un peu ce qui arrive avec cette histoire de VMWare : si on adapte son logiciel à une "interface sous GPL" (i.e. on s'interface en tant que module noyau), cela nous oblige-t-il à quelque chose, c'est à dire, est-on soumis à une licence ?

    J'avoue que je n'apporte que peu de réponses et beaucoup de question, mais c'est important d'y réfléchir alors qu'aujourd'hui les problèmes de licence et d'interopérabilité, en particulier avec la GPL, sont de plus en plus discutés.

    • [^] # Re: Explication dans les commentaires

      Posté par  . Évalué à 6.

      Ce n'est pas une faille de la GPLv2, c'est l'interprétation de celle-ci par les constructeurs parce qu'elle leur convient.
      La GPL dit clairement que tout logiciel lié à du code GPL (statiquement ou dynamiquement contrairement à la légende urbaine) doit être mis sous GPL, point barre. Le fait que le module ne soit pas un travail "directement" dérivé du noyau Linux ne constitue pas une excuse valable.

      La GPL par contre ne t'interdit pas de concevoir ou d'utiliser un module propriétaire pour le noyau Linux mais t'interdit de redistribuer l'ensemble.
      Les distributions fournissant dans un même ensemble un noyau Linux "teinté" sont dans l'illégalité -quoique contournable par une EULA mais dès lors la distribution n'est plus libre-, quant à ceux qui fournissent des modules précompilés, c'est borderline.

      • [^] # Re: Explication dans les commentaires

        Posté par  . Évalué à 0.

        >La GPL dit clairement que tout logiciel lié à du code GPL (statiquement
        > ou dynamiquement contrairement à la légende urbaine) doit être mis
        >sous GPL, point barre.

        Tu peux citer le passage concerné ?

        • [^] # Re: Explication dans les commentaires

          Posté par  . Évalué à 1.

          Extrait du texte de la GPLv2
          This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License.

          La même en Français:
          La Licence Publique Générale ne vous permet pas d'incorporer votre programme dans des programmes propriétaires. Si votre programme est une bibliothèque logicielle, vous pourriez considérer comme plus utile de permettre de lier des applications propriétaires avec la bibliothèque. Si c'est ce que vous voulez, utiliser la Licence Publique Générale Moindre (LGPL) en lieu et place de cette licence.


          C'est plus clair maintenant ?

          • [^] # Re: Explication dans les commentaires

            Posté par  . Évalué à 3.

            >C'est plus clair maintenant ?

            Le texte que tu cites est après "END OF TERMS AND CONDITIONS". Il se situe d'ailleurs après un sous-titre nommé "How to Apply These Terms to Your New Programs". Ca semble être une interprétation des gens de la FSF sur la licence GPL, mais le texte contractuel parle plutôt de "derivative work". Et cette notion fait plus appel au bon sens que la terme technique "lien".

            Petit exemple : tu fais un programme qui utilise JDBC pour accéder à une base de données oracle. Si tu fais un programme simple et que tu codes pas comme un cochon, l'utilisateur à qui tu livres ton programme peut le faire fonctionner avec les drivers JDBC MySQL alors que tu n'as jamais vu de prêt ou de loin le code de MySQL. Avec ton interprétation, je dois livrer mes sources vu que je lie dynamiquement avec MySQL ( un debugger montrerai que je me trimballe une MySQLConnection ). Avec la notion de "derivative work", on peut affirmer sans mal que ton soft n'est pas un derivative work de MySQL.

            Deuxième exemple dans l'autre sens : il y'a un gros soft GPL en ligne de commande qui fait tout un tas de traitement. Toi tu fais un soft qui appelle cet exe et qui récupère la sortie pour l'afficher joliment pour l'utilisateur. Ton soft ne lie pas avec l'exe GPL ni statiquement ni dynamiquement et pourtant il ne fait rien sans cet exe. Avec la notion de "derivative work" tu peux tenter de demander des comptes au créateur du front-end. Avec l'approche "lien", tu peux pas.

            http://www.gnu.org/licenses/gpl-2.0.html

            • [^] # Re: Explication dans les commentaires

              Posté par  . Évalué à 3.

              > Ca semble être une interprétation des gens de la FSF sur la licence GPL
              En même temps, c'est eux qui l'ont écrite, ils savent peut-être mieux que toi ou moi ce que signifie la GPL. Sinon, le bout de texte en question fait partie de la licence, c'est la notice d'utilisation, même l'OSI l'a reprise ...
              http://www.opensource.org/licenses/gpl-2.0.php



              Tes exemples sont faux.
              1. Tu passes par une couche d'abstraction en l'occurence JDBC, et tu n'es strictement lié qu'à celui-ci. Par contre, tu n'as pas le droit de distribuer ton pilote JDBC sous GPL avec ton programme mais l'utilisateur final peut les associer si il le souhaite.

              Pour montrer que ton exemple est daubé, prenons le cas du pilote JDBC MySQL® Connector/J sous licence GPL. MySQL Labs précise que si tu ne veux pas être soumis à la GPL, tu dois leur acheter une licence.
              Commercial licenses for either version can also be purchased from MySQL AB, for those who don't wish to be bound by the GPL.
              http://www.mysql.com/products/connector/j/


              2. Là, c'est du grand n'importe quoi. On te parle de lien dans le sens informatique du terme (http://fr.wikipedia.org/wiki/%C3%89dition_de_liens). Là, aucun lien n'est réalisé, tu récupéres la sortie d'un autre programme et tu l'introduit dans l'entrée d'un autre programme, c'est le principes des pipes.
              Si je fais cat mon_fichier.txt | mon_programme_proprio_ala_con, si j'utilise GNU cat, mon_programme_proprio_ala_con n'a pas à passer sous GPL !


              Pour te prouver que les notions de "travaux dérivés" et de "lien" ne sont pas opposé, un extrait de la FAQ GPL.

              If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?
              ---------
              It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.
              If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.
              If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case.

              http://www.fsf.org/licensing/licenses/gpl-faq.html

              En gros, dès que ton code devient intime avec du code sous GPL (même processus, partage de structure, appels de fonctions etc ...), ton code constitue un "travail dérivée" et doit être licencié sous une licence compatible GPL.

              • [^] # Re: Explication dans les commentaires

                Posté par  . Évalué à 2.

                >En même temps, c'est eux qui l'ont écrite, ils savent peut-être mieux que toi ou moi ce que signifie la GPL.

                Il n'y a pas de lien entre être l'auteur d'un contrat et connaitre avec certitude l'interprétation qu'en fera un juge si on lui demandait de trancher ; Par exemple, il y'a beaucoup d'exemples de contrats comportant des clauses qui sont considérées comme abusives lorsque l'on demande à un juge de trancher : avec ton raisonnement, je devrais prendre pour argent comptant ce que me dit mon opérateur de téléphonie sous pretexte que c'est lui qui à écrit le contrat !

                >1. Tu passes par une couche d'abstraction en l'occurence JDBC, et tu n'es strictement lié qu'à celui-ci.

                De la même manière je peux faire un soft qui ne fonctionne qu'avec MySQL ( clauses SQL spécifiques ) en ne me liant qu'avec JDBC. Dans un cas, je suis un travail dérivé de MySQL : je n'existe pas sans MySQL et dans l'autre je ne suis pas un travail dérivé.


                >2. Là, c'est du grand n'importe quoi. On te parle de lien dans le sens informatique du terme. [...] c'est le principes des pipes.

                Là encore tu as une approche technique du problème alors que j'ai une approche juridique. Si ton programme n'existe pas sans le composant GPL, alors tu es un travail dérivé.
                J'aime assez l'analogie de Linus à propos des livres et des chapitres sur ce sujet ( voir les liens d'IsNotGoog un peu plus bas ).


                >En gros, dès que ton code devient intime avec du code sous GPL (même processus, partage de structure, appels de fonctions etc ...), ton code constitue un "travail dérivée"

                Encore approche technique. Avec ces critères, tu prouves que l'appel JDBC MySQL est un travail dérivé alors que tu prétends le contraire quelques lignes avant : le code du driver mysql sous gpl est executé dans le meme processus et il alimente des structures que je lis.

                • [^] # Re: Explication dans les commentaires

                  Posté par  . Évalué à 1.

                  ce troll a déja eu place il y a peu de temps (sur une news en première page).

                  Ce qu'on en a conclu c'est "C'est pas clair" XD
                  des interprétations et arguments peuvent expliquer le pourquoi considérer lié en dynamique peut etre considérer comme un "derivative" ... ou pourquoi lié en dynamique ne peut pas être considéré comme un "derivative".

                • [^] # Re: Explication dans les commentaires

                  Posté par  . Évalué à 3.

                  Le contrat est censé transposer l'aspect technique dans un cadre juridique. Distinguer l'aspect juridique de l'aspect technique est un non-sens.
                  Ton juge pour déterminer si ton logiciel est un travail dérivé, s'appuiera sur le texte de la licence (qui est suffisamment explicite à ce sujet), l'avis des experts techniques et probablement de la position des auteurs de la GPL.
                  La GPL n'a pas été écrite à l'arrache sur un bout de nappe par RMS, des juristes (notamment Eben Moglen) ont participé au processus et ils ont tenu compte de l'aspect technique.



                  Une clause abusive, c'est une clause entrainant un déséquilibre significatif entre les droits et obligations des parties au contrat imposé par la partie la plus forte économiquement parlant.
                  Difficile dès lors de parler de clause abusive dans le cadre de la GPL ...



                  1. Ton exemple est encore faux.
                  Tu a le droit décrire un logiciel propriétaire spécifique à MySQL en utilisant JDBC, mais tu n'as le droit de distribuer les deux ensemble (que ce soit d'une façon ou d'une autre).
                  Si tu veux le faire, comme je l'ai dit précédemment, tu dois acheter une licence auprès de MySQL Labs.
                  C'est exactement la même chose qu'avec les pilotes binaires.

                  2. Tu as une définition abusive du terme "travail dérivé", si on prends ta définition, tu n'as pas le droit par exemple de fournir un IDE proprio avec GCC, ce qui est évidemment faux.
                  Même si en pratique, ta "coquille vide" ne tourne pas sans le composant GPL, tant qu'ils ne sont pas "intimes", c'est OK vis à vis de la GPl (Cf la faq GPL posté précédemment)



                  3. Elle est ou la contradiction ? Je t'ai dis que si tu veux redistribuer ton logiciel proprio + pilote JDBC ensemble, soit tu achètes une licence soit tu changes la licence de ton logiciel ?
                  Par contre, la GPL ne t'interdit pas de les associer dans le cadre d'une utilisation privée mais dès lors tu n'as plus le droit de le diffuser.

                  La GPL explique explicitement ce qu'est ou ce que n'est pas un "travail dérivé". Introduire la sortie d'un programme dans l'entrée d'un autre ne suffit pas à en faire un "travail dérivé".
                  Avec ta définition déformée de ce qu'est un travail dérivé, ce serait un bordel. Pour reprendre ton exemple avec JDBC, supposons que j'écrive un programme proprio utilisant JDBC que je vends avec MS SQL Server mais qui marche très bien également avec MySQL mais sans que je le distribue avec, donc mon programme devrait être sous GPL puisque c'est un travail dérivé.
                  Tu vois le problème ?

      • [^] # Re: Explication dans les commentaires

        Posté par  . Évalué à 3.

        > La GPL dit clairement que tout logiciel lié à du code GPL doit être mis sous GPL
        Non, la GPL dit que si tu distribues l'ensemble, l'ensemble doit être distribué sous licence GPL (ce qui n'impose /rien/ sur les licences des parties de l'ensemble. La preuve, certain drivers Linux sont sous licence BSD)

        • [^] # Re: Explication dans les commentaires

          Posté par  . Évalué à 2.

          > La preuve, certain drivers Linux sont sous licence BSD
          Au dernières nouvelles, la BSD (sans clause de publicité) est compatible GPL.
          Prend une licence incompatible avec la GPL et hop, ça ne fonctionne plus. Au mieux, t'as prouvé que le code lié doit être sous GPL ou une licence compatible, au pire, c'est un mauvais exemple.

          • [^] # Re: Explication dans les commentaires

            Posté par  . Évalué à 4.

            Tu as débranché tes neurones dédiées à la compréhension écrite pour les brancher sur le mode troll dès que tu as lu le mot "BSD", ou tu as juste considéré que lire mon message avant d'y répondre était une perte de temps ?

            > Au dernières nouvelles, la BSD est compatible GPL.
            J'ai dit le contraire ?

            On reprend: dans le noyau Linux, il y a des bouts sous GPL et des bouts sous BSD. La GPL précise qu'il faut alors distribuer le tout (linux-2.6.24.tar.bz2, ton .rpm, le binaire vmlinuz,...) sous GPL. Mais elle ne précise rien sur la licence des parties. Simplement, les licences des parties doivent être compatibles (cad grosso modo doivent être un sous ensemble) avec la licence GPL pour que cela soit possible, ce qui est la cas de la BSD, mais les parties n'ont pas à être sous licence GPL, elles peuvent garder leur licence originale.

            D'où ma correction: un logiciel lié à un logiciel sous licence GPL n'a pas à être sous licence GPL, mais doit être sous une licence compatible GPL (les licences BSD sans clause de publicité le sont) afin que l'ensemble puise être redistribué sous les termes de la licence GPL.

            Ça suffit, ou je dois être encore plus explicite pour te montrer qu'à priori, on est d'accord ?

            • [^] # Re: Explication dans les commentaires

              Posté par  . Évalué à 3.

              je vais mettre un énorme bémol à tout ceci :

              les couillons de la FSF ont montré qu'ils sont capables de modifier la GPL (c'est à dire changer la règle du jeu) au fur et à mesure qu'ils en éprouvent le besoin mystique.

              pour le noyau, c'est (assez heureusement) bloqué en "v2 only". pour tous les projets en GPL "v2 or any later version", rien n'empêchera de se prendre plus tard une clause "se peindre le visage en bleu".

              • [^] # Re: Explication dans les commentaires

                Posté par  . Évalué à 2.

                [je passe sur tes propos acerbes et non démontrés]
                v2 or any later permet de pouvoir migrer un projet facilement, et donc de faire cohabiter sans problème du code gplv{3,4..} avec du code conçu lors de la gplv2.


                Si tu n'utilise que le code "gplv2 or any later version", tu peux n'être soumis qu'aux obligations de la gplv2 (et pas de la gplv3).

                Si tu utilise un projet avec du gplv2 or any later version _et_ gplv3, tu sera soumis à la gplv3.

            • [^] # Re: Explication dans les commentaires

              Posté par  . Évalué à 2.

              Heu, je voudrais pas dire, mais tu as quand même omis de préciser que les "parties" devaient être compatibles GPL dans ton premier commentaire, d'ailleurs tu as même précisé :
              ce qui n'impose /rien/ sur les licences des parties de l'ensemble
              Alors que justement, la GPL impose que les "parties" soient compatibles GPL. Je te trouve un peu dur avec GeneralZod sur ce commentaire ...

      • [^] # Re: Explication dans les commentaires

        Posté par  . Évalué à 1.

        Supaire !
        Si je compile un logiciel libre pour un système propriétaire ça veut dire qu'il devient libre ?

        Je file compiler et lier la libcaca sous Windows pour libérer l'OS de Microsoft alors !


        Heureusement, la GPL permet de le lier du logiciel propriétaire à du code GPL. Enfin seulement si le dit logiciel est une librairie système :
        Both versions of the GPL have an exception to their copyleft, commonly called the system library exception. If the GPL-incompatible libraries you want to use meet the criteria for a system library, then you don't have to do anything special to use them; the requirement to distribute source code for the whole program does not include those libraries, even if you distribute a linked executable containing them.

        http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

        BeOS le faisait il y a 20 ans !

        • [^] # Re: Explication dans les commentaires

          Posté par  . Évalué à 2.

          D'ailleurs la licence de Linux précise que la "vaccination GPL" ne concerne pas les programmes propriétaire utilisant les appels systèmes.
          Le but de la GPL n'est évidemment pas de conquérir le monde mais de coexister avec le propriétaire (à armes égales).

      • [^] # Re: Explication dans les commentaires

        Posté par  . Évalué à 3.

        Puisqu'on est toujours dans les précisions, il y a quand même une chose qui me gène, c'est que même si VMWare est "autorisé" à produire son module proprio, normalement, il n'a pas le droit de distribuer l'ensemble.

        Hors, corrigez moi si je me trompe, mais VMWare ESX est un ensemble distribué par VMWare, contenant le noyau _et_ le module proprio ?! Donc c'est illégal. Non ?

  • # .

    Posté par  . Évalué à -1.

    >La GPL dit clairement que tout logiciel lié à du code GPL (statiquement
    > ou dynamiquement contrairement à la légende urbaine) doit être mis
    >sous GPL, point barre.

    Tu peux citer le passage concerné ?

    • [^] # Re: .

      Posté par  . Évalué à 0.

      Je me suis vautré dans mon [répondre] : le commentaire parent n'est pas un nouveau fil de discussion mais une réponse à un commentaire précédent ; aussi si un modérateur tombe sur ce commentaire et/ou son commentaire parent, je l'invite à ne pas hésiter une seule seconde à les supprimer.

  • # Oui VMware viole la GPL mais...

    Posté par  . Évalué à 3.

    Mais c'est un peut plus compliqué que ça.
    VMware viole la GPL avec l'accord de Linus Torvals. Linux n'applique pas la GPL a la lettre.
    La question a été largement débattue.
    Pour information, le début du fichier COPYING de Linux :

    NOTE! This copyright does *not* cover user programs that use kernel
    services by normal system calls - this is merely considered normal use
    of the kernel, and does *not* fall under the heading of "derived work".
    Also note that the GPL below is copyrighted by the Free Software
    Foundation, but the instance of code that it refers to (the Linux
    kernel) is copyrighted by me and others who actually wrote it.

    Also note that the only valid version of the GPL as far as the kernel
    is concerned is _this_ particular version of the license (ie v2, not
    v2.2 or v3.x or whatever), unless explicitly otherwise stated.

    Linus Torvalds

    Bref, ce que fait VMware, même si ça ne respecte pas la GPL à la lettre, est accèpté.

    • [^] # Re: Oui VMware viole la GPL mais...

      Posté par  . Évalué à 2.

      Mouaif, c'est un peu à côté de la plaque.
      J'ai une circonstance atténuante, c'est vieux cette histoire.

      Pour plus d'info, voir le fichier COPYING.modules qu'on trouve dans les paquets src.rpm de Red Hat ou Fedora (et probablement d'autres) :
      http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/kernel/(...)

    • [^] # Re: Oui VMware viole la GPL mais...

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

      Linus il est gentil, mais il a pas le monopole du copyright sur le kernel il me semble... C'est pas à lui seul d'en décider...

      • [^] # Re: Oui VMware viole la GPL mais...

        Posté par  . Évalué à 2.

        Oui.
        Mais il suffit qu'il refuse une modification du copyright et elle n'est pas accèptée.
        Enfin les histoires de modules ont été décidées il y a bien longtemps (Linux 2.0). A cette époque la voie de Linus était prépondérante.

        Le plus, la concèption qu'a Linus des modules (qui ne serait que des clients du noyau) est partagée par beaucoup de développeurs. Notons, et j'insiste encore sur ça, Linus ne veut pas violer l'esprit de la GPL. Il a une interprétation assez pertinante de "travail dérivé" dans le cas des modules ET pour certaines API (qui ne sont pas marquées GPL-only).

        Je remet le lien car tout y est expliqué en détail :
        http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/kernel/(...)

        • [^] # Re: Oui VMware viole la GPL mais...

          Posté par  . Évalué à 2.

          > ET pour certaines API

          Il y a des choses qu'on ne peut pas faire avec un module proprio. Par exemple on ne peut pas faire un système de fichier (sauf type fuse).
          Les modules proprio sont principalement limités aux drivers, à l'utilisation de LSM et autres "bricoles". Mais en aucun cas l'intention est de permettre tout et n'importe.

    • [^] # Re: Oui VMware viole la GPL mais...

      Posté par  . Évalué à 3.

      Tu précises que tu es à coté de la plaque, effectivement, ici on parle des syscalls, donc de l'interaction avec l'espace utilisateur, ce qui n'a rien à voir avec l'histoire de VMWare qui est un module.

  • # Question.

    Posté par  . Évalué à 4.

    Puisque Linux GNU/Linux le noyaux Linux est un OS subversif fait par des communistes, des pirates sous GPL. Pourquoi les entreprises l'utilise pour des projets tel que VMware?

    Pourquoi ne pas utilisez un noyau BSD qui permet de faire ce VMware fait sans contourner la licence? Surtout que les noyaux BSD sont réputé pour être de qualité.

    Je ne cherche pas à lancer de troll, mais bien à comprendre comment une entreprise peut baser son business modèle sur un terrain aussi glissant. (surtout quand il y a moyen de faire aussi bien légalement).

    si quelqu'un peut m'éclairer.

    Merci

    • [^] # Re: Question.

      Posté par  . Évalué à 0.

      Il y a un problème légal pour celui qui ne connait pas en détail le problème.
      Mais VMware ne prend aucun risque (s'il se plie à certaines règles).

      Dans la pratique les "amendements" de Linus ne respectent pas la GPL à la lettre. Mais la GPL est respecté dans l'esprit. La zone d'ombre est la définition de travail dérivé. Linus (et ses collèges) l'ont maintenant bien définit et des mécanismes type "EXPORT_GPL_SYMBOL" (ou un truc dans ce goût) le reforce.

      Plus d'info ici :
      http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/kernel/(...)

      > Surtout que les noyaux BSD sont réputé pour être de qualité.

      Peut-être parce-que VMware est plus soucieux de la réalité que de la réputation...

      • [^] # Re: Question.

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

        Je serai plutôt tenté de dire que s'ils ont choisi d'utiliser le noyau linux, c'est surtout parce que :

        -le noyau linux est testé et certifié sur de nombreuses machines potentiellement utilisées par les clients de esx. Je connais peu de machines HP, Dell ou autres certifiées pour fonctionner sous un bsd.

        -en raison de sa popularité, il y'a plus de chances de trouver et d'embaucher des devs ayant touché du linux que du bsd.

        La notion de réalité et de réputation...bof bof. Il y'a eu de chaque côté des releases foireuses avec de gros bugs.

        • [^] # Re: Question.

          Posté par  . Évalué à 0.

          > -en raison de sa popularité, il y'a plus de chances de trouver et d'embaucher des devs ayant touché du linux que du bsd.

          Il n'y a pas que ça. Par exemple il me semble que les *BSD n'offre pas plus de 2 Go par processus sur une bécane 64 bits. C'est assez emmerdant...
          Je suis sûr qu'il y a d'autres manques dans BSD qui font cruellement défaut. Il y a-t-il un équivalent de lvm dans BSD ? Le clustering est-il du niveau de Linux ?
          S'il manque un de ces trucs, VMware ne va pas les développer en une semaine.

          • [^] # Re: Question.

            Posté par  . Évalué à 2.

            Sur une bécane i386 un processus peux déjà utiliser 3 Go, donc vérifie les faits avant de sortir une telle escroquerie. Sur une bécane 64 bits, FreeBSD (testé) peut évidement utiliser des dizaines de Go par processus et je pense que les autres BSD doivent pouvoir le faire également.

  • # API

    Posté par  . Évalué à 0.

    J'ai cru comprendre (je ne suis que de loin ce point, et mes compétences en developpement kernel sont plus que limité), que l'api du kernel avait tendance à changer tout le temp.

    Si c'est le cas j'en déduis que vmware doit tout le temp suivre ces changement si il veut avoir un kernel relativement récent.

    Vrai/faux ?

    Si c'est le cas c'est quand même un réelle perte de temp je trouve et je rejoins par là le commentaire sur l'utilisation de BSD plutot que de linux.

    Apple a bien joué sur ce coup là.

    • [^] # Re: API

      Posté par  . Évalué à 0.

      Toi tu devrais faire un peu plus souvent un

      rm -rf /temp/*


      -->[ ]

    • [^] # Re: API

      Posté par  . Évalué à 1.

      Linux n'est pas un produit mais un projet. Un projet avec une communauté de développeur qui ne vont pas stopper le boulot pour faire plaisir à telle ou telle boite.

      Si tu veux que l'API ne bouge pas, utilise RHEL (7 ans de compatibilité source et binaire).

      > Si c'est le cas j'en déduis que vmware doit tout le temp suivre ces changement si il veut avoir un kernel relativement récent.

      Ce n'est pas un vrai problème. VMware a décidé d'être impliqué dans le *projet* Linux. Donc il participe aux discussions de concèption, il est en contact avec les développeurs, etc. C'est un plus pour VMware. Si VMware était concentré sur RHEL, ben là il n'y a presque plus rien à discuter. Et si VMware demande de gros changements à RHEL, Red Hat va envoyer VMware chez Fedora ou mieux chez Linux upstream.

      > Si c'est le cas c'est quand même un réelle perte de temp

      La perde de temps c'est se refuse tout changement d'API. Car Linux ne s'impose pas cette contrainte, il évolue très vite.

      > l'utilisation de BSD plutot que de linux.

      Le monde est injuste et BSD incompris.

      > Apple a bien joué sur ce coup là.

      Apple vend un produit.

    • [^] # Re: API

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

      J'ai cru comprendre (je ne suis que de loin ce point, et mes compétences en developpement kernel sont plus que limité), que l'api du kernel avait tendance à changer tout le temp.

      Si c'est le cas j'en déduis que vmware doit tout le temp suivre ces changement si il veut avoir un kernel relativement récent.


      vmware se base encore sur la version 2.4 de linux. Ils ne sont donc pas directement atteints par les changements d'API incessants. Je pense que tant qu'ils n'en ont pas besoin pour une question de support hardware, ils ne passent pas à une version plus récente et se contentent de patcher les éventuels trous de sécu (et encore quand on voit l'attitude de certaines boites qui font du proprio...).

    • [^] # Re: API

      Posté par  . Évalué à 2.

      Les légendes urbaines ont la vie dure.
      Il faut distinguer deux API dans le noyau Linux:
      * les appels systèmes (kernel <-> userspace) utilisé par les programmes et qui est relativement stable.
      * les appels internes au noyau Linux. Greg Kroah-Hartman l'explique très sur cette page (http://www.kroah.com/log/linux/stable_api_nonsense.html), c'est de la connerie. Si on veut faire une API stable, ça veut dupliquer les API (et risquer que les pilotes continuent à utiliser des API bogués), parfois il est impossible de corriger une faille de sécurité sans casser l'API.
      Quant ton module est dans l'arbre des sources du noyau, il est automatiquement corrigé, si il ne l'est pas comme le module VMWare, bah, c'est à eux de le réparer.
      Donc la vraie perte de temps, c'est d'avoir mis ce putain de module sous licence propriétaire et de ne pas l'avoir inclus dans l'arbre.
      De plus, pour la plupart des modules, les changements sont quasiment invisibles.

      Apple n'a pas un noyau dérivéde BSD, mais un noyau hybride XNU basé sur:
      * un micro-noyau Mach.
      * une couche de compatibilité BSD offrant une interface de programmation UNIX classique.
      * l'I/O Kit: un framework (libre au passage) permettant d'écrire des pilotes matériels utilisant un dialecte C++ (de l'embedded C++, du C++ sans héritage multiple, exceptions, RTTI, templates etc ...)

      Si l'API pour la programmation de pilotes pour XNU est stable, ce n'est pas grâce à BSD mais à l'I/O Kit.
      De plus, XNU est un noyau à moitié mort avec des perfs merdiques comparés à Linux.

      • [^] # Re: API

        Posté par  . Évalué à 2.

        De plus, XNU est un noyau à moitié mort avec des perfs merdiques comparés à Linux.

        <mode="BeOS forever">C'est rigolo mais BeOS aussi avait un noyau tout lent à coté du Linux de l'époque. Ca ne l'empêchait pas d'avoir un niveau de performance tout à fait exceptionnel pour l'utilisateur final ciblé.

        C'est un peu pareil avec MacOSX, le noyau est peut-être lent, il hérite d'une conception qui date des années 80 (NeXT) mais au final il rend bien des services à l'utilisateur.

        Tout ça pour dire que l'interface noyau-utilisateur est parfois plus importante que le noyau lui-même.

        BeOS le faisait il y a 20 ans !

        • [^] # Re: API

          Posté par  . Évalué à 2.

          A une époque un monsieur célebre disait que le multitache était sans intérêt pour un PC perso.

          Pour un usage desktop, les performances du noyau sont vraiment accessoires. Mais pour un serveur avec un gros débit réseau/disque, c'est tout autre chose.
          Bref, même si le noyau MacOS est tout pourri (je n'en sais rien), c'est sans grande conséquence dans un usage desktop.

          • [^] # Re: API

            Posté par  . Évalué à 0.

            mac os x existe également en version serveur. Qu'en est-il dans ce cas-là ? Apparemment ce n'est pas si "pourri".

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

Suivre le flux des commentaires

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