LLVM 2.2 : Un concurrent pour GCC ?

Posté par  (site web personnel) . Modéré par Nÿco.
0
18
fév.
2008
Technologie
Le compilateur LLVM (pour Low Level Virtual Machine) vient de sortir le 11 février dernier dans sa version 2.2 et s'affirme de plus en plus comme un concurrent possible pour le projet GNU GCC.

LLVM n'est pourtant pas tout à fait comparable au compilateur GCC. En effet GCC est un projet complet et monolithique car Richard Stallman a choisi explicitement de ne pas le rendre modulaire afin de ne pas permettre a des programmes propriétaires de s'interfacer avec lui.
LLVM au contraire est placé sous licence BSD et a choisi une conception très modulaire afin d'être réutilisé au maximum par tous. Il se limite à des fonctions d'optimisation et de génération de binaire ; il ne peut analyser lui-même le code source des programmes à compiler (c'est le projet Clang qui est prévu pour ça).

Il sera intéressant de voir ce qui va se passer sur le long terme dans l'écosystème du libre et si LLVM va être capable d'attirer des développeurs utilisant actuellement GCC. LLVM est une machine virtuelle de bas niveau écrite en C++ et qui utilise actuellement en frontal une version 4.0 de GCC. Cela signifie que GCC transforme le code source en une représentation intermédiaire qui est ensuite injectée dans LLVM afin de subir diverses analyses et optimisations. Il est prévu que cette dépendance envers GCC disparaisse le jour où le projet de frontal Clang sera considéré comme mature. Une comparaison entre Clang et GCC est disponible.
L'intérêt de cette séparation architecturale entre Clang et LLVM, outre son avantage en terme de simplicité, est que cela permet de "brancher" des modules d'analyse statique ou de refactoring du code. L'inclusion dans les environnement intégrés de développement (IDE) est également plus facile.

La version 2.2 de LLVM apporte plusieurs nouveautés :
  • Le frontal utilisé passe de GCC 4.0 à GCC 4.2 afin d'améliorer les performances. Le support de la version 4.0 est toujours assuré mais cela ne sera plus le cas dans la prochaine version LLVM 2.3.
  • LLVM 2.2 peut maintenant générer du code adapté aux SPU (Synergistic Processor Unit) du processeur Cell.
  • Les types long double sont maintenant supportés par LLVM alors qu'ils étaient convertis en type long dans les version précédentes. Ces long double sont d'une taille de 80 bits pour les architectures x86/x86-64 et d'une taille de 128 bits pour les PowerPC/PowerPC64.
  • Le ramasse-miettes (Garbage collector en anglais) a été réécrit afin d'améliorer ses performances. Les primitives proposées sont nombreuses et permettent de s'adapter aux divers langages existants.
  • Les passes d'optimisations sont plus perfectionnées et permettent d'utiliser plus facilement les unités multimédias des processeurs (SSE).

Une présentation bien plus détaillée et technique de l'ensemble des nouveautés introduites par la version LLVM 2.2 est disponible sur le site du projet. En dépit de ces progrès le couple LLVM/Clang a encore énormément de chemin à faire avant de rattraper GCC.

La maturité et l'universalité (en terme de langages et d'architectures) de GCC en font un adversaire redoutable. On peut noter que le support C++ de Clang est très préliminaire et qu'il ne sera pas finalisé avant au moins deux ans. De plus la licence GPL de GCC garantit aux divers contributeurs que leur code ne pourra pas être "propriétarisé" par un concurrent. Cela explique que nombre de firmes (IBM, Red Hat ou Novell pour n'en citer que quelques unes) financent largement le développement de GCC. Néanmoins, on sent poindre chez plusieurs observateurs une inquiétude au sujet du conservatisme de GCC et la question de l'inclusion de greffons et de la modularisation de l'architecture ne tardera pas à réapparaître.

Aller plus loin

  • # llvm-gcc

    Posté par  . Évalué à 2.

    clang (nouveau frontend C/C++ pour LLVM) n'est pas utilisable, mais llvm-gcc (frontend C/C++ de GCC adapté à LLVM) l'est...
    • [^] # Re: llvm-gcc

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

      Il me semble que clang est désormais utilisable pour C et ObjectiveC ... mais effectivement pas pour C++. Ce qui semble normal vu la complexité de C++.
      Et vu que LLVM est écrit en C++
  • # Les mauvaises décisions

    Posté par  . Évalué à 9.

    Richard Stallman a choisi explicitement de ne pas le rendre modulaire afin de ne pas permettre a des programmes propriétaires de s'interfacer avec lui.

    Ou comment mélanger politique et technique se passe toujours très mal. Cette décision a eu pour implications : 1) rendre plus difficile l'ajout de nouveau languages, 2) motiver des gens pour faire une alternative a gcc.

    Résultat, un compilateur sous BSD proprio compliant alors qu'on aurait pu avoir du gcc en GPL, certes soumis a quelques dérives et abus autour de la GPL, mais au moins sous la pierre angulaire de GNU : sa licence.

    A chaque fois que quelqu'un fait des décisions de conception apportant des limitation techniques pour soit disant 'protéger' son application, ca se finit en drame. Je trouve ca bien triste de voir ca dans du libre.
    • [^] # Re: Les mauvaises décisions

      Posté par  . Évalué à 8.

      Richard Stallman a choisi explicitement de ne pas le rendre modulaire afin de ne pas permettre a des programmes propriétaires de s'interfacer avec lui.
      J'aurais bien aimé avoir la source de cette citation quand meme, car ca fait gros lancé de troll .... Meme si ca ne m'étonnerait pas trop de la part de RMS.
      • [^] # Re: Les mauvaises décisions

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

        • [^] # Re: Les mauvaises décisions

          Posté par  . Évalué à 9.

          Est-ce que quelqu'un a lu le lien avant de plusser ? Je ne savais pas que Joe Buck parlait un nom de RMS...

          Synopsys est une societe des logiciels proprietaires pour la micro-electronique, et leur simulateur VCS depend enormement de gcc. Je comprend volontier que Joe Buck aimerait que la GPL et RMS n'existe pas, et que gcc soit sous license BSD-like ...

          D'ailleurs dans le meme fil de discussion, d'autres personnes sont intervenir pour contredire J.Buck.
          • [^] # Re: Les mauvaises décisions

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

            Il est bien membre du steering committee http://gcc.gnu.org/steering.html , non ? Donc j'imagine qu'il est très bien placé pour connaitre l'opinion de rms..

            Qu'il prefere du bsd n'a rien a voir avec la choucroute. La question est de savoir si oui ou non c'est stallman qui refuse que gcc soit extensible via un systeme de plugins.
            • [^] # Re: Les mauvaises décisions

              Posté par  . Évalué à -1.

              > il est très bien placé pour connaitre l'opinion de rms..

              RMS n'a plus touché gcc depuis 10 ans...
              Regarde les log si t'en doute.

              > La question est de savoir si oui ou non c'est stallman qui refuse que gcc soit extensible via un systeme de plugins.

              La réponse est claire, c'est non.
              La dernière fois que RMS a touché à gcc, c'était pour ajouter le fichier README.SCO.
              Il faudra te trouver une autre tête de turc.
    • [^] # La liberté ce n'est pas technique

      Posté par  . Évalué à 10.

      Ou comment mélanger politique et technique se passe toujours très mal

      Je trouve ce propos assez mal venu:
      la FSF a toujours mélangé politique et technique, ses revendications ne sont pas techniques mais bien politiques: la liberté ce n'est pas technique. C'est ce qui a permit de faire émerger et conserver un mouvement autour des logiciels libres, puis "du libre" en général.

      Que je sache, la qualité des logiciels sortis de la FSF est excellente. Ils ne prétendent pas être les meilleurs mais garantir certaines libertés nécessaires.

      Que Stallman soit têtu, c'est tout à son honneur: têtu et obstiné il garde un certain cap, ne se laisse pas détourner ni pervertir de son but initial (ça semble si facile de pervertir quelqu'un avec l'argent de nos jours). Depuis le temps, il a pas mal mené sa barque je trouve.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: La liberté ce n'est pas technique

        Posté par  . Évalué à 2.

        disons que si Macromedia^WAdobe avait libéré un gros morceau de sa technologie Flash en utilisant la même ficelle, ta FSF chérie aurait crié au meurtre. alors bon, hein...

        (d'aucuns jugent que Sun fait pareil avec OpenOffice et Java...)
      • [^] # Re: La liberté ce n'est pas technique

        Posté par  . Évalué à 2.

        Depuis le temps, il a pas mal mené sa barque je trouve.

        Sans offense, je suis très loin d'être certain que ce soit lui qui mène la barque aujourd'hui. Le LL (et opensource) doit avoir environ un million d'acteurs de plus qu'il y a 25 ans ...

        De là à dire que le ll a passé le cap de l'adolescence et peut vivre maintenant sans son père spirituel, il n'y a qu'un pas.
    • [^] # Re: Les mauvaises décisions

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

      Ca a néanmois forcé Apple a distribué ses modifications dans gcc et l'a incité à contribuer upstream (au support objective-c).
      Donc dans le passé, cette conception a déjà eue un impact bénéfique au logiciel libre.
      • [^] # Re: Les mauvaises décisions

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

        Apple est un des gros contributeurs à LLVM.
        • [^] # Re: Les mauvaises décisions

          Posté par  . Évalué à 8.

          tu m'étonnes.

          Apple est un furieux adepte du modèle proprio. S'il a fait quelques pas vers l'Open Source (et non le logiciel libre), c'est pour attirer du monde sur Mac Os X en encourageant le portage d'appli.

          Ils prennent ce qui les intéresse dans les logiciels mais n'aiment "jouer le jeux" en prenant le contrôle des projets (genre, CUPS, ou WebKit)

          Mon dernier Apple est un macGS II et il n'y en aura pas d'autres.
          • [^] # Re: Les mauvaises décisions

            Posté par  . Évalué à 3.

            ... et NTFS-3G...
          • [^] # Re: Les mauvaises décisions

            Posté par  . Évalué à 7.

            le jour qui se rapproche ou apple va pouvoir dire merde a l'esprit du logiciel libre s'approche plus vite que l'on ne pense a mon avis et le support a llvm n'est qu'un pas de plus dans cette direction. Je pense aussi qu'il n'est pas tout a fait innocent que la suite apple n'est pas de filtre ODF par exemple.

            Ils auront pris ce dont ils auront eu besoin dans le libre pour se reconstruire mais ils redonnent a contre coeur la contre-partie cf le probleme avec khtml (sinon pourquoi aqua serait t'il toujours closed-source?).

            Enfin bon on verra bien.
            • [^] # Re: Les mauvaises décisions

              Posté par  . Évalué à 7.

              Aaaaaaaaah! Les merveilles de la license BSD!
              • [^] # Re: Les mauvaises décisions

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

                « BSD, c'est tout cadeau au proprio ! »
                • [^] # Re: Les mauvaises décisions

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

                  et GPL c'est coder avec un commissaire politique dans le dos.
                  • [^] # Re: Les mauvaises décisions

                    Posté par  . Évalué à 10.

                    > et GPL c'est coder avec un commissaire politique dans le dos.

                    Le méchant logiciel libre qui veut rester libre.
                    Ces vilains développeurs qui ont fait du code en libre et qui veulent qu'il reste libre en le mettant sous GPL. Salauds de séveloppeurs !
                    • [^] # Re: Les mauvaises décisions

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

                      Il y a plus d'une manière de rester libre, la FSF prône "la "bonne manière de faire". Je suis pas sûr d'aimer ça plus que la bonne manière de faire du business avec microsoft.

                      Puis faire un soft proprio avec du BSD ça paraît facile, mais tenir le fork sur la longueur si on a une équipe de bras cassés, c'est pas couru d'avance.

                      Donc une manière pour un projet BSD de rester libre, c'est d'être excellent. Ce qui est tout autant respectable que la GPL.

                      Faut arrêter la crise d'ado les gars, le monde est pas tout blanc ou tout noir.
                      • [^] # Re: Les mauvaises décisions

                        Posté par  . Évalué à 4.

                        > Donc une manière pour un projet BSD de rester libre, c'est d'être excellent.

                        Mouaif...
                        Si c'est nul, aucune boite le reprend...
                        De plus tu passes sous silence les problèmes de brevets, de tivolisation, etc.

                        > Faut arrêter la crise d'ado les gars, le monde est pas tout blanc ou tout noir.

                        Idem pour toi. La BSD tu ne la prend pas seulement car c'est libre, mais car ça permet de faire du proprio. On peut être pour ou contre, mais il ne faut pas se raconter d'histoire.
                        Si tu ne veux pas que ton code se retrouve dans du proprio (breveté, DRMisé, tivolisé, pas source, etc) ben tu prends la GPL (ou équivalent).
                        Si tu le "supporte", ben tu prends une BSD (ou équivalent).
                        • [^] # Re: Les mauvaises décisions

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

                          Si tu ne veux pas que ton code se retrouve dans du proprio (breveté, DRMisé, tivolisé, pas source, etc) ben tu prends la GPL (ou équivalent).

                          A vrai dire, je ne vois pas ce que - en tant que développeur - tu en ais à foutre que ce soit breveté, tivolisé, DRMisé, propriétarisé si ta version libre demeure...ça ne blesse personne, à part peut-être ton égo trop dimenssionné.
                          • [^] # Re: Les mauvaises décisions

                            Posté par  . Évalué à 4.

                            Imagine que tu développes un logiciel de messagerie révolutionnaire.

                            Tu le mets sous licence BSD et une entreprise malveillante en fait une version proprio et grâce à sa puissance marketing impose sa version à la majorité des gens.

                            Comme cette version proprio change aussi le protocole de communication et ne le documente pas, ton logiciel libre ne sert plus à rien et tu l'as dans l'os!
                            • [^] # Re: Les mauvaises décisions

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

                              1) les révolutions j'y crois pas trop
                              2) pour protéger un protocole, le mieux est de participer à un comité de normalisation (ouvert) pour s'assurer qu'il soit adopté
                              3) le problème des normes et du logiciels est indépendant
                              4) si mon logiciel est bon, et qu'ils adoptent le protocole, alors il y a aura plus d'ordinateurs qui communiqueront proprement (cf ssh, openssl), et les sysadmins me vénéreront
                              5) arrête la parano, le monde du proprio est plus souvent incompétent qu'orienté vers une volonté délibérée de nuire .

                              A ce titre j'aurais aimé que microsoft reprenne le code d'un brouteur libre, car j'aimerais vivre dans un monde où l'on développe pas les pages web d'un coté pour IE de l'autre pour le reste du monde qui respecte (un peu mieux) les normes.
                              • [^] # Re: Les mauvaises décisions

                                Posté par  . Évalué à 4.

                                5) arrête la parano, le monde du proprio est plus souvent incompétent qu'orienté vers une volonté délibérée de nuire .
                                D'ailleur on l'a bien vu avec nessus.
                                (qui d'ailleur n'a pas pu suivre avec le libre et est reparti vers le modèle propriétaire).

                                Croire que c'est parce qu'ils sont proprio qu'ils sont con mais pas dangereux est une dangereuse erreur amha.
                              • [^] # Re: Les mauvaises décisions

                                Posté par  . Évalué à 6.

                                5) arrête la parano, le monde du proprio est plus souvent incompétent qu'orienté vers une volonté délibérée de nuire .

                                Et ça c'est de la parano?

                                http://code.google.com/android/migrating/m3-to-m5/m5-api-cha(...)
                                • [^] # Re: Les mauvaises décisions

                                  Posté par  . Évalué à 4.

                                  Pour les non anglophones, dans Android, les packages spécifiques a XMPP sont renommés en des packages spécifiques a Gtalk. Une des raisons est que Gtalk n'a pas l'ambition d'être une API XMPP générique et que son implémentation future va surement utiliser un format binaire. En gros Gtalk ne sera plus une implémentation XMPP, si ce n'est pas deja le cas :,( .

                                  Le fameux "Don't be evil" en prend un coup.

                                  Purée, Google prend de plus en plus la voie des tenebre. C'est triste, mais cela se voyait de plus en plus.
                                  La liste des logiciels d'IM proprio va s'allonger. C'est tres tres triste.
                                  • [^] # Re: Les mauvaises décisions

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

                                    En même temps, techniquement, je me demande si ce n'est pas une mauvaise chose que de faire un XMPP binaire ... Je me demande si ca ne peux pas améliorer les performances des serveurs (parsing XML pas a faire)

                                    Après, le mieux c'est que ce soit standardisé par XMPP
                                    • [^] # Re: Les mauvaises décisions

                                      Posté par  . Évalué à 2.

                                      Je pense effectivement que le passage au binaire pourrait améliorer significativement les performances du protocole. A partir du moment ou cela reste standardisé et ouvert, je ne vois pas de problèmes.

                                      Je t'avoue que ce n'est pas tant le fait que ce soit du binaire qui me dérange, mais plutôt que Gtalk se désolidarise de Jabber/XMPP. Ce changement dans le nom des packages annonce que GTalk ne va plus être compatible avec l'implémentation actuelle de XMPP. C'est un désaveu très fort pour ce protocole que l'on pensait bien parti avec son implémentation dans GTalk.

                                      Maintenant, peut être que c'est l'intention de Google de d'abord pousser les améliorations au protocole dans GTalk puis de les standardiser, mais vu les virages que prend cette entreprise actuellement, le doute m'assaille. Je serais très heureux de me tromper et que GTalk ne rejoigne pas la liste des logiciels d'IM utilisant des protocoles propriétaire:
                                      http://fr.wikipedia.org/wiki/Messagerie_instantan%C3%A9e#Pro(...)
                                      http://nyco.wordpress.com/2007/01/06/mais-quel-bordel/

                                      Finalement est ce que Jabber a vraiment gagné Nÿco?
                                      http://nyco.wordpress.com/2007/07/05/ca-y-est-jabber-a-gagne(...)
                                      • [^] # Re: Les mauvaises décisions

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

                                        ptetre tout simplement qu'ils n'ont pas envie d'attendre et que rien ne se passe alors c'est libre et ils prennent les devant (non pas que je sois forcément d'accord, mais c'est logique)

                                        Comment la voix est arrivée dans jabber par exemple ?
                                        Les premières propositions pour ajouter la voix dans jabber datent de 1999.
                                        Et ensuite ? ben pas grand chose, des débats sur diverses XEP et ... rien
                                        Jusqu'au jour ou Google a pondu jingle pour ses besoins (gtalk) et là "génial, jabber, voix, vive google, toussa..."

                                        Donc bon, non pas que je sois content que google s'écarte de jabber, mais que peuvent-ils faire d'autre ?
                                        Si leur implémentation reste open source, que leur reprocher réellement ? d'utiliser le libre ? ben oui mais c'est le libre justement. De le modifier pour répondre à leurs besoins ? ben c'est le libre et je croyais que c'était comme ça que ça avancait justement

                                        Maintenant, peut-être y-a-t-il du boulot à faire du côté de jabber pour implémenter ce que (certains) utilisateurs aimeraient, le faire par la communauté et alors ne plus dépendre de google pour les nouveautés (oui je sais où est mon patch, toussa)
                                        • [^] # Re: Les mauvaises décisions

                                          Posté par  . Évalué à 2.

                                          Si leur implémentation reste open source, que leur reprocher réellement ?
                                          Je pensais que GTalk était entiérement propriétaire. Je ne savais pas que la libjingle était libre. Au temps pour moi. Si la jabber foundation est un frein je comprends qu'ils veuillent passer outre elle.
                                          Je n'ai pas de reproches a faire sur le fait d'utiliser le libre puisque justement, ... c'est libre.
                                    • [^] # Re: Les mauvaises décisions

                                      Posté par  . Évalué à 2.

                              • [^] # Re: Les mauvaises décisions

                                Posté par  . Évalué à 1.

                                A ce titre j'aurais aimé que microsoft reprenne le code d'un brouteur libre

                                Qu'est ce qui les en empeche? Ils peuvent tout a fait le faire sauf que:

                                1) lorsque l'on est al boite la plus riche du monde et avec le plus grand nombre de developpeurs montrer que l'on arrive pas a faire mieux qu
                                une bande d'excite communiste ca la fout mal.

                                2) La licence. Il faudraient qu'il refile les "modifs" faites dedans pour le rendre incompatible avec le reste et garder leur monopole.

                                3) cf la fin de petit 2 et je pense que c'est legerement volontaire les "bugs" de rendus de IE. Enfin vu Vista ou auparavant Millenium ca peut aussi etre juste de l'incompetence...
                          • [^] # Re: Les mauvaises décisions

                            Posté par  . Évalué à -1.

                            A vrai dire, je ne vois pas ce que - en tant que développeur - tu en ais à foutre que ce soit breveté, tivolisé, DRMisé, propriétarisé si ta version libre demeure...ça ne blesse personne, à part peut-être ton égo trop dimenssionné.

                            Petit, écoute je vais t'apprendre une grande vérité. Notre société tourne beaucoup autour du pognon, le fric. Ouai je sais c'est dur comme vérité mais c'est comme ça. Néanmoins une cyber tribu résiste encore et toujours à l'envahisseur. La tribu des gnu. Une tribu de gens idéaliste qui codent librement afin d'apporter des logiciels de grande qualité au monde entier sans recevoir de salaire. Néanmoins certains décidents en mettant leur code en BSD ont eu sacrément mal au cul le jour ou ils ont vu que des gens faisaient des millions de bénéfices sur leur dos, augmentaient la notorité de leur boîte, et enfermeaient les utilisateurs avec leur logiciels et DRM. Alors le petit codeur candide s'alimentant de pain et d'eau fraîche il a une partie de son anatomie qui grate, qui tire et boîte un peu, mais il est content, il a prit une license BSD! Béni soit la BSD!

                            Dire que si la BSD n'aurait pas existé, apple n'existerait plus.
                            • [^] # Re: Les mauvaises décisions

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

                              Tu peux citer des gens qui ayant mis volontairement leur code sous licence BSD on eu « mal au cul » le jour où des gens « ont fait des millions de bénéfices sur leur dos » ?
                              • [^] # Re: Les mauvaises décisions

                                Posté par  . Évalué à 3.

                                Chez OpenBSD, ils ont eu l'arriere train qui les a graté à propos d'OpenSSH.

                                Mais chez les GNUs aussi, des fois les gens sont triste.
                                C'est la vie :)
                              • [^] # Re: Les mauvaises décisions

                                Posté par  . Évalué à 4.

                                Wine par exemple ?
                                Pas de millions de benef, mais le jour ou cedega a repris le code ils sont passé sous GPL
                            • [^] # Re: Les mauvaises décisions

                              Posté par  . Évalué à 1.

                              > Dire que si la BSD n'aurait pas existé, apple n'existerait plus.
                              Et? Est ce que ce serait mieux?

                              Mac OS X, IPod, IPhone, etc. on quand meme des succes non négligeables et ont permis de montrer au commun des mortels qu'il n'y avait pas que Microsoft, Windows et Office. ca a révolutionné pas mal de choses. Si Apple avait disparu, est ce que tu aurais connu de tels changements?

                              Safari (et plus encore Firefox bien sur) ont montré a nouveau la voie du respect des standards du web.

                              Je veux bien qu'Apple ne soit pas le meilleur allié du libre, mais de la a dire qu'Apple est totalement maléfique et que tout ce que fait Apple est merdique, il y a la un pas que je ne franchis pas et ne franchirais jamais. il faut reconnaitre ses mérites, mais aussi ses mauvaises actions. Bref, il faut rester critique envers ce qu'ils font.
                              • [^] # Re: Les mauvaises décisions

                                Posté par  . Évalué à 3.

                                Mac OS X, IPod, IPhone, etc. on quand meme des succes non négligeables et ont permis de montrer au commun des mortels qu'il n'y avait pas que Microsoft, Windows et Office.</cite

                                Linux, lecteur multimédia portable lisant toute sortes de formats et qui ne t'enferme pas dans des DRM, des téléphones qui font téléphones(Oui de nos jours on oublis parfois qu'on peux téléphoner avec ces choses la plutôt que de passer son temps à se venter d'avoir une Idaube©), Kde, Firefox, etc. on quand meme des succes non négligeables et ont permis de montrer au commun des mortels qu'il n'y avait pas que Microsoft, Windows et Office. ca a révolutionné pas mal de choses. Si le monde du libre n'aurait jamais existé à quoi penses tu que ressemblerait l'informatique aujourd'hui ?

                                Je me suis permit quelques réctifications de tes phrases afin de t'exposer mon ti point de vu :)
                            • [^] # Re: Les mauvaises décisions

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

                              Néanmoins certains décidents en mettant leur code en BSD ont eu sacrément mal au cul le jour ou ils ont vu que des gens faisaient des millions de bénéfices sur leur dos

                              Je ne vois pas en quoi ils auraient mal au cul : ils ont choisit, ils savaient, ils assument.
                              Un gars qui se plaint que le proprio a fait des sous avec un produit proprio basé sur son travail est ton simplement idiot : il l'a autorisé, point.
                              C'est un choix, et 99% des DSDistes ont fait volontairement ce choix.
                              Pourquoi toi tu aurais la science infuse, et les obligerai à faire autre chose que ce qu'ils veulent?
                              • [^] # Re: Les mauvaises décisions

                                Posté par  . Évalué à 0.

                                C'est très concept ce que tu nous dis la.

                                Coder et fournir la sueur de son travail gratuitement à la première entreprise venue au pouvoir marketing. (C'est comme Sarko, le travail plus pour gagner moins c'est une forme de BSD aussi :))

                                On connaissais les gens qui donnent des sous pour l'humanitaire, voir dans notre cas de geeks soutenir des projets libres. Bref on donne quelque chose mais pour la bonne cause.

                                Or la ils sont ou neuneux ou bien sado masochistes.
                                Je cerne pas bien l'idée de fournir un boulot pour que les autres empochent le jackpote à notre place, mais je t'en prie explique moi...
                                • [^] # Re: Les mauvaises décisions

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

                                  Ton pro-"GPL rulez" devient gonflant...
                                  Le choix des BSDistes de faire du BSD a été maintes fois dit, si tu ne sais pas lire...
                                  - Ils préfèrent qu'une entreprise utilise leur code propre plutôt qu'un code autre pourri (genre faire un OS from scratch tout troué...).
                                  - Faire un proof of concept pour diffuser un protocole (exemple : TCP/IP)
                                  - Attaché à la philosophie de la liberté, la GPL n'est pas considéré libre de leur point de vue, puisqu'elle empeche la liberté de faire du proprio.
                                  - Rien à foutre de la philosophie, veux juste faire du code.
                                  - etc... N'étant pas pro-BSD, je ne peux te donner tous les arguments.

                                  Et encore une fois : de quel droit veux-tu leur <b<imposer ton point de vue sur les licences? Pourquoi leur refuses-tu le droit de faire comme ça si ils en ont envie? Pourquoi les insulter juste parce qu'ils n'ont pas choisit ta licence (en plus, du BSD peut devenir GPL... DOnc tu gardes tes libertés.)
                                  • [^] # Re: Les mauvaises décisions

                                    Posté par  . Évalué à -2.

                                    Ils préfèrent qu'une entreprise utilise leur code propre plutôt qu'un code autre pourri (genre faire un OS from scratch tout troué...).

                                    Ca fait un peu suffisant comme justification. En gros seul les BSDistes seraient capables de coder proprement et les codeurs faisant du proprio en entreprises seraient des codeurs de bas gamme incapable d'aligner deux lignes de codes proprement et ne feraient que du code pourri?
                                    Le fait qu'un code soit libre ou fermé n'a jamais fait (et ne fera jamais) sa qualité.
                                    • [^] # Re: Les mauvaises décisions

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

                                      En gros seul les BSDistes seraient capables de coder proprement et les codeurs faisant du proprio en entreprises seraient des codeurs de bas gamme incapable d'aligner deux lignes de codes proprement et ne feraient que du code pourri?

                                      Non mais un code BSD tout pourri ca se voit, alors qu'un code proprio tout pourri, cela ne se voit pas.
                                      • [^] # Re: Les mauvaises décisions

                                        Posté par  . Évalué à 1.

                                        Ce n'est pas parce que toi tu ne le vois pas que ça ne se voit pas!
                                        Une entreprise préfère payer sa R&D à faire des nouveaux dev plutôt qu'à galérer à faire de la maintenance parce que le code est pourrit et imbittable.

                                        Et puis du code libre pourrit ça existe aussi...
                                  • [^] # Re: Les mauvaises décisions

                                    Posté par  . Évalué à -2.

                                    - Ils préfèrent qu'une entreprise utilise leur code propre plutôt qu'un code autre pourri (genre faire un OS from scratch tout troué...).


                                    TUTAFAY !! D'ailleurs c'est pour ça que Red Hat ils sont à la rue niveau et n'arrivent pas a avoir de rentrée d'argent et un modéle économique viable.

                                    Bref que tu prennes ce que je dis pour quelque chose de gonflant ça ne regarde que toi. Je t'invite à ne pas me lire. Tu éviteras ainsi de te échauffer la cervelle. C'est vrai après tout c'est mieux de coder pour le compte de grandes sociètes qui font pleins de millions et ne rien recevoir en échange. Alors que pourtant des exemples d'entreprises qui se reposent sur un modele libre arrivent à être viables.

                                    D'ailleurs on t'invite souvent à dîner ?
                                    • [^] # Re: Les mauvaises décisions

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

                                      Mais c'est qu'il insiste l'apprenti dictateur...
                                      1/ Je ne suis pas du BSDiste pour le moment.
                                      2/ Par contre, j'essaye de vivre en société, en acceptant que les autres pensent différemment. Et je comrpend les gens qui disent que la GPL n'est pas libre, étant donné qu'elle supprime plein de libertés.
                                      3/ Un autre te l'a déjà démontré, la GPL a exactement le même problème : d'autres se font du blé sur le dos des gens qui programment. Donc j'en conclue que tu es anti-GPL, cette licence qui permet à d'autres de profiter de ton travail...

                                      Donc bon, pourquoi tu es ici? Ici on parle principalement du libre, et toi tu es anti-libre... Tu veux du code fermé, de la propriété intellectuelle à tous va etc... Seule réponse à ta volonté qu'on ne fasse rien avec le fruit de ton travail.
                                      • [^] # Re: Les mauvaises décisions

                                        Posté par  . Évalué à 2.

                                        > Et je comrpend les gens qui disent que la GPL n'est pas libre, étant donné qu'elle supprime plein de libertés.

                                        Elle supprime la liberté de supprimer des libertés !

                                        Avec la GPL, tu donnes à tout le monde la liberté de voir le code, le modifier, etc. Ceci que tu reçoivent le code (évidemment) mais aussi le binaire.

                                        Avec la BSD ? Ben si t'as le code oui. Mais comme personne n'est obligé de te donner le code...

                                        Le problème c'est à quelle "distance" tu regardes la licence. Si tu as le code et ne pense qu'à ta pomme, la BSD est plus "libre". Si tu penses à l'ensemble des utilisateurs, la GPL est plus libre (tous les utilisateurs peuvent avoir le code (c'est un droit), le modifier, etc).
                                        • [^] # Re: Les mauvaises décisions

                                          Posté par  . Évalué à 10.

                                          > Elle supprime la liberté de supprimer des libertés

                                          Cet argument commence sérieusement à me casser les couilles !
                                          Tu fais du GPL, tu es compatible avec GPL et deux autres licences qui sont juste "GPL mais avec un nom différent"
                                          Tu fais du BSD, tu es compatibe avec le reste du monde. Avec le proprio aussi, mais c'est un effet de bord tout à fait involontaire (dans mon cas, en tout cas)
                                          Avec la GPL, en faisant du propriétaire ton ennemi, tu t'aliènes plein d'amis potentiels.
                                          Avec la BSD, en te faisant le plus d'amis potentiels, tu fais tu propriétaire ton "ami".
                                          La GPL a été faite avec le proprio en point central, "le proprio NE DOIT PAS être compatible"
                                          La BSD a été faite avec le partage en point centra, "je DOIS être compatible avec le plus de monde possible"
                                          Personnellement, si je préfère la licence BSD, ce n'est pas parce que j'aime le logiciel propriétaire, mais parce que je considère que faire du propriétaire son ennemi fini par donner des situations du type "GPLv2 incompatible GPLv3", ce qui est plus dommageable que tout ce que le propriétaire pourra nous faire en repiquant notre code. La force du libre est le partage. Ne le bridons pas sous prétexte d'une sorte de "croisade" contre le logiciel propriétaire.

                                          Pour certains, l'aspect "compatible proprio" de la BSD n'est ni un point principal, ni volontaire, ni même souhaitable. C'est juste un compromis acceptable pour pouvoir être compatible avec le plus de monde possible. Pour le partage. Tu peux comprendre ça, ou je dois continuer ?
                                          • [^] # Re: Les mauvaises décisions

                                            Posté par  . Évalué à 2.

                                            mais qu'est ce que tu as a tout ramené au proprio.

                                            La GPL a été faite, non pas vers le "proprio parce que le proprio c'est mal" mais vers "On veut que les liberté offerte par les dvp sur le programme soient conservée pour TOUS les utilisateurs".

                                            En parlant du contrepied on peut faire beaucoup de supposition, mais ca ne les rend pas plus "intelligentes"/"pertinentes" pour autant.
                                            • [^] # Re: Les mauvaises décisions

                                              Posté par  . Évalué à 5.

                                              J'ai beau relire la plupart des commentaires ici, c'est à 99% les défenseurs de la GPL qui ramènent toujours le débat au proprio. Moi, je veux bien d'un débat sur les qualités de GPL/BSD sans entendre la moindre occurence, voilée ou non, de "proprio". Mais malheureusement, il y a toujours un GPLeu pour commencer à dire "oui, mais avec la BSD, on peut repiquer le code pour le mettre dans du proprio".

                                              > On veut que les liberté offerte par les dvp sur le programme soient conservée pour TOUS les utilisateurs
                                              Ben dans ce cas, c'est super, on est d'accord. Le proprio ne mérite même pas qu'on en fasse tout un fromage. Ignorons le donc.

                                              Le truc, c'est qu'AMHA une licence faite sans penser au proprio ressemble plus à une BSD qu'à une GPL (qui est assez explicitement CONTRE le proprio, au lieu de seulement dire "osef, qu'ils fasent comme ils veulent, ils ne méritent même pas une ligne pour eux dans le texte de la licence...". A moins que les modifications apportées à la GPLv3 ne soient là que pour le plaisir d'emmerder les utilisateurs de GPLv2 ?)

                                              > On veut que les liberté offerte par les dvp sur le programme soient conservée pour TOUS les utilisateurs

                                              C'est un peu (beaucoup, en fait) aussi le cas avec la BSD, tu sais. Tous les utilisateurs de Net/Free/OpenBSD/Darwin/... ont accès au code et ont liberté (presque, ya toujours consrver le texte de la licence & et les infos de copyright) totale pour le modifier.

                                              Après, un utilisateur peut choisir d'utiliser un fork non libre. Mais dans le cas, je vois mal comment blamer la licence pour ça, si l'utilisateur se contrefout de sa liberté...
                                              • [^] # Re: Les mauvaises décisions

                                                Posté par  . Évalué à 2.

                                                J'ai beau relire la plupart des commentaires ici, c'est à 99% les défenseurs de la GPL qui ramènent toujours le débat au proprio.
                                                Oki d'accord, le GPL-eux dis "la bsd permet du proprio" et le bsd-eux dis "la gpl empeche la cohabitation proprio".
                                                1 partout la balle au centre.

                                                Mais malheureusement, il y a toujours un GPLeu pour commencer à dire "oui, mais avec la BSD, on peut repiquer le code pour le mettre dans du proprio".
                                                Mythe du martyr ? Procés d'intention?
                                                Des BSD qui font de tels procés aux gpleux ca existe aussi, ne t'inquiète pas.
                                                Dans un tel cas, les torts sont le plus souvent partagés.

                                                Le truc, c'est qu'AMHA une licence faite sans penser au proprio ressemble plus à une BSD qu'à une GPL
                                                Ben non, je veux une licence qui garantisse a tous mes utilisateurs les même libertée que celle que j'ai accordé au premier utilisateur.
                                                J'ai pas dis "je veux éviter que le proprio le prenne", j'ai dis "je veux conserver les mêmes libertés pour tous".
                                                La encore tu repart sur des contraposée, et confond conséquence et cause. (La cause est que je veux que tous mes utilisateur aient les mêmes libertés, la conséquence est que le proprio ne peut donc pas retirer mes libertés, ni n'importe quoi d'autre)

                                                C'est un peu (beaucoup, en fait) aussi le cas avec la BSD, tu sais.
                                                Je pouvais modifier la pile tcp/ip de windows ?
                                                Non ?
                                                Dommage! :P
                                                Parce que , qui sait, elle était peut être non modifiée.

                                                Mais je comprend ce que tu veux dire
                                                Effectivement je n'ai pas fait un pavé sur le but de la gpl , comme faire en sorte que les contributions soient reversées : cad qu'effectivement tous les utilisateurs aient les libertés que j'ai voulu donner a mon programme, même si quelqu'un décide de le modifier.
                                                De plus la GPL a un autre avantage, c'est qu'un "neuneu" peut savoir facilement qu'il peut récupérer les sources. Avec un code BSD enfoui beaucoup moins (voir les fameux crédits de BSD sous windows , qui commencaient par "\0").
                                                Mais effectivement, si tout le monde jouait le jeux (car il y a aussi des entreprises qui font ça pour gpl, j'en suis conscient), ca serait beaucoup moins problématiques.

                                                Pour beaucoup d'entreprise BSD==Droit Public. /o\



                                                Enfin perso, je m'en tape de savoir qu'un programme est sous bsd/gpl/... (sauf si je dois voir quel solution prendre pour dvp dans mon boulot) : le dvp est maître de son truc , et il fait ce qu'il veut avec. Si ca me plait pas, je peux toujours redevelloper, récup des bonnes idées et réimplémenter etc...
                                                • [^] # Re: Les mauvaises décisions

                                                  Posté par  . Évalué à 4.

                                                  > le bsd-eux dis "la gpl empeche la cohabitation proprio".
                                                  Non, le bsd-eu il dit "la gplvx emêche la cohabitation avec d'autres projets sous d'autres licences" (cddl, gplv(x+1), et surement d'autres)
                                                  Comme dit avant, le proprio, je m'en fout. Je l'ignore. Pour moi, il n'existe virtuellement pas. Par contre, que je puisse pas reprendre du code GPLv3 pour le mettre dans du GPLv2, ça me dérange beaucoup plus...

                                                  > Mythe du martyr ? Procés d'intention?
                                                  Justement, pas vraiment. Tu as visiblement survolé mon post, alors je vais mettre en gras la partie intéressante
                                                  "l'aspect "compatible proprio" de la BSD n'est ni un point principal, ni volontaire, ni même souhaitable."
                                                  Oui, ma licence préférée est BSD (en fait ISC, mais ne jouons pas sur les mots). Oui, je considère le fait que le proprio puisse réutiliser mon code comme un inconvénient. Mais cet inconvénient est, à mon sens, négligeable (et de beaucoup) devant les avantages apportés (concision et simplicité du texte -- KISS appliqué aux licences, j'adore ;) -- , réutilisabilité et partage avec d'autres codes libres grandement facilités)
                                                  Dans ce cas, non, je ne tendrai pas le baton pour me faire frapper en mettant le proprio sur la table -- simple question de bon sens. Donc, quand je trolle avec un GPLeu, pour que le proprio arrive dans le débat, il faut que ce soit le GPLeu qui l'amène.

                                                  Puisque tu sembles aimer la logique: dans un monde où le concept même de logiciel propriétaire n'existe pas, la GPL a t'elle la moindre utilité ? Personnellement, je ne pense pas, donc pas de proprio => pas de GPL donc GPL => proprio. L'existence du concept de logiciel proriétaire est donc une condition nécessaire à l'existence de la GPL. C'est en ce sens, et uniquement en ce sens que je dis "la licence GPL est beaucoup plus centrée sur ses relations avec le logiciel propriétaire que la licence BSD".

                                                  > De plus la GPL a un autre avantage, c'est qu'un "neuneu" peut savoir facilement qu'il peut récupérer les sources
                                                  Le neuneu, il s'en tape le coquillard des sources. Désolé, mais c'est comme ça.

                                                  > La cause est que je veux que tous mes utilisateur aient les mêmes libertés, la conséquence est que le proprio ne peut donc pas retirer mes libertés
                                                  Désolé, mais je peux pas être d'accord avec ça. Tu insinues (même liberté pour tous les utilisateurs d'un soft) implique (soft sous une licence copyleft)
                                                  Tous les utilisateurs de FreeBSD ont les même libertés, et pourtant FreeBSD n'est pas sous une licence de type copyleft. Contre exemple trivial de ta proposition (après, j'ai peut être mal compris ce que tu voulais dire...)

                                                  > Je pouvais modifier la pile tcp/ip de windows ?
                                                  Tu ne peux pas plus modifier le code de NTFS de windows..
                                                  Ce que tu demandes là, c'est modifier Windows. Hors Windows n'est pas libre. Si tu veux modifier la pile réseau de ton OS, choisis un OS libre. C'est aussi simple que ça...

                                                  > Si ca me plait pas, je peux toujours redevelloper, récup des bonnes idées et réimplémenter etc...
                                                  Toutafé.
                                                  Mais dit toi que si le code original était sous BSD-like, tu peux même récupérer des bouts intéressants. Avec une licence de type copyleft, c'est déjà moins trivial. Après, je dis pas que dans le cas contraire l'auteur n'est qu'un salopard de propriétaire, je dis juste que c'est fortement dommage pour l'aspect partage du logiciel libre...)
                                                  • [^] # Re: Les mauvaises décisions

                                                    Posté par  . Évalué à 0.

                                                    la GPL a t'elle la moindre utilité ? Personnellement, je ne pense pas, donc pas de proprio => pas de GPL donc GPL => proprio.
                                                    L'ennui, c'est que tu peux remplacer GPL par BSD, et ça marche très bien aussi ...
                                                    Si tout était forcément libre, sans brevet, etc... : pas de probleme de licence !

                                                    Non, le bsd-eu il dit "la gplvx emêche la cohabitation avec d'autres projets sous d'autres licences" (cddl, gplv(x+1), et surement d'autres)
                                                    D'un autre coté, la cddl (par exemple) empêche aussi la cohabitation avec bsd (tu peux pas mettre un code cddl sous bsd) , la gpl, et plein d'autres licences.
                                                    Alors est ce que c'est le but de la gpl d'empêcher la cohabitation avec les autres projets libres ?
                                                    Perso je ne pense pas, mais bon je n'ai pas participer à sa création ;)


                                                    Par contre, que je puisse pas reprendre du code GPLv3 pour le mettre dans du GPLv2, ça me dérange beaucoup plus...
                                                    Les utilisateurs de GPLv3 veulent peut être assurée que leur utilisateur continuent d'avoir les mêmes libertées qu'ils ont données. Et ils ont vu qu'avec la GPLv2 il y avait des failles.
                                                    Donc si on corrige les failles dans une version, c'est pas pour autoriser a les exploitée.

                                                    Je comprend ce que tu veux dire, mais c'est la décision du dvp de passer en gplv3, car il veut s'assurer que tout les utilisateurs aient les mêmes libertées, et pas qu'un utilisateur

                                                    Ce que tu demandes là, c'est modifier Windows. Hors Windows n'est pas libre. Si tu veux modifier la pile réseau de ton OS, choisis un OS libre. C'est aussi simple que ça...
                                                    Mais tu utilise une pile libre!
                                                    Et le dvp de la pile veut peut etre que quiconque veut utiliser cette pile puisse la modifier!
                                                    C'est ça que j'entend par "tous ses utilisateurs peuvent la modifier" : c'est vraiment tous ses utilisateurs (cad tous ceux qui l'utilise). et pas seuls les utilisateurs qui ont pris une version qu'ils peuvent modifier.


                                                    je dis juste que c'est fortement dommage pour l'aspect partage du logiciel libre...
                                                    Chaque chose a ses pros et ses cons.
                                                    Je me souviens d'un certain theo qui ralait parce que les entreprises osait utiliser son code bsd sans lui payer un billet d'avion pour assister à une conf.
                                                    L'intérêt de gpl est de forcer un code issu d'un projet libre à rester dedans (comme un tout , a ne pas être incoporé dans du code proprio). C'est un intérêt local évident.
                                                    La bsd cherche plus à "déssiminer" du code libre (je sais je m'exprime mal).
                                                    • [^] # Re: Les mauvaises décisions

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

                                                      La CDDL est compatible avec la BSD, parce que la CDDL n'est pas contaminante. On peut lier de la CDDL avec du code BSD sans problème. D'ou la possibilité d'avoir ZFS sur FreeBSD. (à faire vérifier par un juriste parce que la CDDL c'est aussi lisible que la GPL:))
                                                      • [^] # Re: Les mauvaises décisions

                                                        Posté par  . Évalué à 1.

                                                        tu es sur de ça ?
                                                        sous freebsd ils ont pas fait comme sous linux : cad un module sous licence BSD, et "linké" dynamiquement (enfin utilisé en user space pour linux) ?

                                                        Si tel n'est pas le cas, je te prie d'accepter mes sincères excuses.
                                                    • [^] # Re: Les mauvaises décisions

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

                                                      Openssh serait sous GPL, ca changerait vraiment le comportement des utilisateurs ? Tu pense qu'il y'a beaucoup de gens qui modifient openssh ? Pour un usage non-inter-entreprise (et là la GPL ne peut rien pour toi).
                                                      • [^] # Re: Les mauvaises décisions

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

                                                        le code de openssh est utilisé dans un grand nombre de devices réseaux. Mais bon à la limite on s'en fout, il serait en gpl les boites qui font du proprio coderaient leur propre serveur ssh ou en mettraient peut-être un autre sous licence.

                                                        Donc le passage à la gpl n'apporterait rien ;-)
                                                      • [^] # Re: Les mauvaises décisions

                                                        Posté par  . Évalué à -1.

                                                        le problème c'est pas "open ssh serait sous gpl", c'est "un gars qui arrête pas d'utiliser la BSD pour tout se plaint quand même quand les entreprises utilise son projet sans contribuer".
                                                    • [^] # Re: Les mauvaises décisions

                                                      Posté par  . Évalué à 3.

                                                      > L'ennui, c'est que tu peux remplacer GPL par BSD, et ça marche très bien aussi ...
                                                      Non. La BSD possède toujours des points qui la différentient du domaine public:
                                                      - conservation du nom des auteurs,
                                                      - clause de non-responsabilité,
                                                      - clause de conservation de la licence (sinon, suffit de virer la licence pour pouvoir virer les deux points précédents ;)) (qui, je le précise tout de suite, n'a rien à voir avec le copyleft)
                                                      D'accord, la GPL possède aussi ces clauses. Mais c'est une infime proportion de tout le texte de la licence, et l'écrasante majorité de ce texte (et c'est tout ce qui fait ses problèmes d'interprétation) reste pour la partie copyleft.

                                                      Je reformule donc pour préciser ma pensée:
                                                      Dit autrement, dans le monde utopique sans propriétaire, 80% de la GPL est à jeter car inutile, contre 0% de la BSD... Non, dans un tel monde tout dans la GPL n'est pas à jeter, mais ce qui reste est franchement très proche de la BSD. Donc, toujours avec cette supposition la GPL (fortement simplifiée, sans le copyleft) n'a pas plus d'intérêt que la BSD (non modifiée). Pour faire plus simple, la GPL n'est pas inutile, mais le principe de copyleft, qui est tout de même le point central de la GPL, l'est. Après, tu peux reprendre mon raisonnement précédent pour arriver au "la licence GPL est beaucoup plus centrée sur ses relations avec le logiciel propriétaire que la licence BSD"

                                                      > Alors est ce que c'est le but de la gpl d'empêcher la cohabitation avec les autres projets libres ?
                                                      J'ose espérer que tu inventes et que tu n'as pas compris ça de mon message, sinon ça veut dire que soit tu es de mauvaise foi, soit je me suis vraiment mal exprimé.
                                                      Bien évidemment que le but premier de la GPL n'est pas d'empêcher a cohabitation avec le reste du logiciel libre. Mais le résultat en est toutefois très proche, même si c'est involontaire (certainement pas souhaitable je pense, mais négligeable et acceptable devant les avantages procurés par le principe de copyleft selon les rédacteurs de la GPL).
                                                      GPL: notre principe de copyleft limite le partage avec d'autres licences ? Dommage, c'est un inconvénient certain, mais tout à fait négligeable devant les avantages apportés par le copyleft.
                                                      BSD: cela permet de se faire repiquer notre code par le proprio ? Dommage, c'est un inconvénient certain, mais tout à fait négligeable devant les avantages apportés par les possibilités de partage et de réutilisabilité.
                                                      Voilà la différence "philosophique" entre GPL et BSD.

                                                      > Mais tu utilise une pile libre!
                                                      Mais justement, non ! Cette pile fait partie intégrante de l'OS qui n'est pas libre !
                                                      Tu t'imagines que si la pile avait été sous GPL, MS aurait mis Windows sous GPL et n'importe qui aurait pu modifier la pile ? Pas du tout. MS aurait développé sa propre pile, et tu n'aurais pas pu plus la modifier. Le problème, c'est la politique de la boite qui est de faire du proprio et l'utilisateur qui accepte cette politique en achetant des softs de cette boite. Pas la licence du code original. Pile sous GPL ou non, tu ne pourras jamais modifier la pile TCP/IP ou pas si Microsoft ne le veut pas et préfère la réecrire. Mais tu as acheté du Microsoft en pleine connaissance de cause, donc où est le souci ?

                                                      > La bsd cherche plus à "déssiminer" du code libre (je sais je m'exprime mal).
                                                      Tu voulais dire "disséminer", non ? (si oui, je suis d'accord ;))

                                                      > Et le dvp de la pile veut peut etre que quiconque veut utiliser cette pile puisse la modifier!
                                                      Ne t'en fais pas, j'ai parfaitement compris l'état d'esprit de ceux qui mettent du code en GPL, et je ne vais pas crier à l'hérésie... Chacun ses choix, après tout. Mais ce qui me dérange, c'est plutôt le:
                                                      > comme un tout
                                                      qui est justement le problème. "le tout", c'est ton exécutable, le résultat de ton "make". Celui ci restera toujours libre, même si on te prend des bouts, que ce soit avec GPL ou BSD. Windows est un tout non libre, y compris son ancienne pile TCP/IP, peut importe l'origine de la petite partie du tout (provenant d'un code sous BSD, ou développé en interne). FreeBSD est "un tout" libre, et le restera autant que Linux. La GPL ne protège pas plus le tout que la BSD, mais protège individuellement toutes les sous parties du tout, ce que ne fait pas BSD. Mais tant que le tout reste libre, cela ne me dérange pas outre mesure que des parties seront reprises dans du code non libre. En tout cas, je pense que j'y survivrai :)
                                                      Là, je crois que c'est moi qui me suis mal exprimé, mais je vois mal comment mieux le faire. Tant pis, comprenne qui pourra :)

                                                      Ce troll fut un plaisir, mais je vais devoir lâcher linuxfr quelques jours, pas la peine d'attendre une suite de ma part...
                                                      • [^] # Re: Les mauvaises décisions

                                                        Posté par  . Évalué à 0.

                                                        Après, tu peux reprendre mon raisonnement précédent pour arriver au "la licence GPL est beaucoup plus centrée sur ses relations avec le logiciel propriétaire que la licence BSD"
                                                        C'est vrai, si tu es d'accord dans le cas que la licence BSD est une licence "utopique" pour protéger le LL, vu que ça suppose le monde utopique de "no proprio".
                                                        Non?

                                                        Bien évidemment que le but premier de la GPL n'est pas d'empêcher a cohabitation avec le reste du logiciel libre. Mais le résultat en est toutefois très proche
                                                        Je ne suis pas sur que le "reste" du logiciel libre est incompatible avec la GPL.
                                                        Il existe multitude de licence, et, en toute honnêteté, je ne peux pas dire "il y n% de licence représentant n% de code qui sont compatible avec la GPL".
                                                        Mais on est quand même d'accord que la majorité de la partie restante, qui est en licence BSD like ou CDDL (solaris c'est un gros projet), est incompatible ;)


                                                        peut importe l'origine de la petite partie du tout
                                                        Ca peut etre aussi la majeure partie du tout, et l'entreprise a juste rajoutée "printf ("Ceci est un logiciel sous copyright. Vous devez payer une licence pour l'utiliser\n");"
                                                        C'est déjà arrivé avec nessus, alors pourquoi pas avec d'autres programmes?

                                                        Tu voulais dire "disséminer", non ? (si oui, je suis d'accord ;))
                                                        voui, désolé ;)


                                                        Pour finir, je crois qu'on est tout les deux d'accord, juste qu'on ne sait pas s'exprimer ;)

                                                        Ce troll fut un plaisir, mais je vais devoir lâcher linuxfr quelques jours, pas la peine d'attendre une suite de ma part...
                                                        Bonnes vacances ;)
                                                        • [^] # Re: Les mauvaises décisions

                                                          Posté par  . Évalué à 3.

                                                          [ Rajout d'un printf pour rendre le code "propriétaire"]
                                                          Tu oublies un truc : Nessus était en GPL, pas en BSD. Les boites et "consultants" qui ont fait ça ont été dans l'illégalité la plus totale. Ce qui montre bien que GPL ou BSD, du moment qu'il n'y a pas de trace, les boites sans scrupules violent la licence libre, quelle qu'elle soit.
                                                • [^] # Re: Les mauvaises décisions

                                                  Posté par  . Évalué à 2.

                                                  J'ai cliqué trop vite sur envoyer... :p

                                                  > De plus la GPL a un autre avantage, c'est qu'un "neuneu" peut savoir facilement qu'il peut récupérer les source
                                                  Comme dis dans mon autre réponse, je trouve ça fortement fallacieux et capillotracté, mais si c'est vraiment ce que tu veux, certaines licences comme l'ancienne BSD imposent une condition de "publicité"...
                                                  • [^] # Re: Les mauvaises décisions

                                                    Posté par  . Évalué à 1.

                                                    me suis mal exprimé : sait qu'il possède les 4 libertés :
                                                    récupérer les sources, les modifier, l'installer sur n'importe quel soft, etc...

                                                    A nouveau je reprend l'exemple du code de la (ancienne) pile tcp/ip de windows) qui était basé sur du BSD.

                                                    Est ce que je pouvais récupérer les sources de la pile utilisée ?
                                                    Non. Juste une version sans les modifs apportée, et non incoporée dans windows.
                                                    Est ce que je pouvais modifier la pile tcp/ip que j'étais en train d'utiliser, pour l'utiliser en lieu et place de l'actuelle ?
                                                    Non, vu que je ne savais pas comment l'incorporer à windows.

                                                    Ici l'utilisateur final a donc moins de liberté qu'avec un projet entièrement libre.
                                                    Alors que la pile tcp/ip est initialement libre, elle ne l'est pas pour l'utilisateur final dans le sens ou il ne peut pas l'utiliser en lieu et place du code libre utilisée
                                  • [^] # Re: Les mauvaises décisions

                                    Posté par  . Évalué à 2.

                                    en plus, du BSD peut devenir GPL...

                                    Non, on ne peut pas changer la licence du code sous BSD pour la transformer en GPL. Rien ne nous empêche d'inclure du code BSD dans un projet GPL mais cette portion de code reste malgrès tout sous licence BSD (et elle ne devient donc pas miraculeusement du code sous GPL). C'est marqué dans les trois lignes de la licence BSD.

                                    (Seul le détenteur du copyright a le droit de changer la licence du code.)
                                    • [^] # Re: Les mauvaises décisions

                                      Posté par  . Évalué à -1.

                                      je sais pas en ce qui concerne BSD->GPL, même si je penche plutôt pour l'hypothèse contraire a ce que tu viens de dire.

                                      mais sur ça
                                      Seul le détenteur du copyright a le droit de changer la licence du code.
                                      Si le détenteur du copyright , dans sa licence, a décidé que n'importe qui peut changer la licence du code, alors n'importe qui peut la changer.
                                      • [^] # Re: Les mauvaises décisions

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

                                        Prenons une bonne BSD (http://en.wikipedia.org/wiki/ISC_license):
                                        Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.

                                        [Clause de non garantie]


                                        La licence doit donc rester dans le source, et donc sur le fichier.

                                        Si on regarde la licence MIT, par contre, elle permet le "souslicencement" :

                                        Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

                                        The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

                                        [Clause de non garantie]


                                        Pour plus des infos complémentaire, je conseille http://undeadly.org/cgi?action=article&sid=2007091301431(...)
                                  • [^] # Re: Les mauvaises décisions

                                    Posté par  . Évalué à 2.

                                    > - Attaché à la philosophie de la liberté, la GPL n'est pas considéré libre de leur point de vue, puisqu'elle empeche la liberté de faire du proprio.

                                    Et être attaché à la "philosophie de la liberté" c'est donner aux autres le droit d'interdire la liberté ?
                                    Autant dire que Windows est libre, MS peut le libérer quand il veut...
                                    Ça n'a pas de sens.
                                    La GPL interdit de retirer des libertés donnés par la GPL.
                                    • [^] # Re: Les mauvaises décisions

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

                                      Si tu regardes bien, le copyleft (la clause obligeant à redistribuer le code selon la licence initiale) ne fait pas partie des 4 libertés dont parle Stallman. En tant que tel, on peut même parler de restriction de la liberté 0 (celle d'utiliser le code).

                                      La GPL est l'une des licences libres les moins libres.

                                      La GPL v3 est encore pire car elle ajoute des restrictions d'ordre "politique" à l'usage du code (limitations sur les brevets ...) qui pour moi est une solution technique (sur le plan légal) à un problème politque/social.
                                    • [^] # Re: Les mauvaises décisions

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

                                      Tu penses ce que tu veux, c'est ton choix, mais je ne vois pas pourquoi tu veux "interdire" aux autre de penser différemment...

                                      La GPL interdit de retirer des libertés donnés par la GPL
                                      Elle interdit. --> Tu n'es pas libre de (c'est dans le dictionnaire...)
                                      Je suis entièrement d'accord avec toi sur le fait qu'il vaut mieux garder cette interdiction, mais il faut aussi que tu assumes : tu aimes une licence restrictive. Ton point de vue sur la raison de cette restriction ne l'empêche pas d'être restrictive, et d'autre peuvent avoir envie d'utiliser une licence qui t'offre plus de liberté (=moins de restrictions).

                                      Laisse le choix aux gens, accepte de cohabiter, la BSD ce n'est pas de la merde comme peuvent le dire des pro-GPL aigris, c'est un choix, libre. Et heureusement qu'on peut choisir... On peut même cohabiter. Et que le meilleur modèle gagne.
                                      • [^] # Re: Les mauvaises décisions

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

                                        Franchement, en arriver à dire que la GPL "interdit" et est "restrictive" en mettant tout ça bien en gras, vous vous trompez d'ennemis les gars. Lisez le CLUF de MS pour voir une licence restrictive qui interdit, pas la GPL.
                                        • [^] # Re: Les mauvaises décisions

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

                                          Il n'y a pas d'ennemis, il y a que des paris différents, et chacun de choisir son mode de vie.

                                          Certains pensent que le code doit être libre et n'ont pas envie de se prendre la tête, ils veulent juste pouvoir réutiliser leur code, et prennent une licence libre défensive.

                                          D'autres veulent imposer une vision du libre, farcissent leurs licences d'aspects irréalistes (sauf à avoir des avocats partout) et au final se retrouvent à être déçus.

                                          Les gens qui mettent trop dans la GPL finiront aigris et déçus à mon avis.
                                        • [^] # Re: Les mauvaises décisions

                                          Posté par  . Évalué à 3.

                                          Ce n'est pas binaire, il n'y a pas d'un côté "les licences restrictives" et "les licences non restrictives" de l'autre. Juste des licences qui le sont plus ou moins relativement à d'autres. Et effectivement, le cluf de windows est plus restrictif que la GPL, personne ne le nie. Mais il est tout à fait aussi évident que la GPL est plus restrictive que la BSD.
                                • [^] # Re: Les mauvaises décisions

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

                                  C'est marrant. On pourrait appliquer la même chose à la GPL. La GPL impose que le code soit diffusé au client, pas à l'ensemble de la communauté. La majorité de l'argent en informatique c'est du service intra entreprise. Donc y'a plein de code GPL qui circule et qu'on ne verra jamais. Ces mêmes sociétés se font des couilles en or sur le code GPL. Si les Ipod tournaient sous un Os GPL, tu crois vraiment que ca changerait son destin de faire gagner des Milliards à Apple ? Pour quelle contribution d'apple ? 3 drivers ? La GPL n'empeche pas les entreprise de se faire des couilles en or avec le code associé.

                                  Apple a leeché du code BSD pour faire son MacOSX. Whaou c'est horrible. N'empeche que ca fait une plateforme Posix de plus, donc beaucoup moins de code chiant à se retaper. MacOSX aurait ete basé sur disons GNU/Linux. Ca aurait changé quoi ? Rien, la couche AQUA/COCOA est assez largement séparé du reste pour qu'il n'y ait aucun besoin de l'ouvrir.

                                  Je ne vais pas continuer les contre exemples.

                                  La licence BSD a plusieurs avantages. Tout le monde peut la comprendre. Je passerai sur tous les gens qui foutent leur code sans GPL sans même l'avoir lu, se contentant du résumé des 4 libertés de Stallman. Deuxiement, la première des libertés, c'est la liberté de choix. Imposer la liberté, ce n'est pas mieux qu'une dictature de la "liberté", ca n'a pas de sens. Et en plus c'est contre productif, parce que les gens ne se posent plus de questions. Combien de GNU/Linuxien, au combien adepte du libre, utilise quotidiennement .doc, flash, le protocole msn, hotmail, les mp3z ...
                                  • [^] # Re: Les mauvaises décisions

                                    Posté par  . Évalué à -2.

                                    > La GPL n'empeche pas les entreprise de se faire des couilles en or avec le code associé.

                                    Oui, et je ne vois vraiment pas en quoi c'est un problème.
                                    Si l'OS d'Apple était sous GPL, on pourrait le reprendre en toute tranquilité.
                                    Et s'il est sous BSD ?
                                    Ben faut qu'Apple est la gentillesse de fournir les sources...
                                    Ben faut qu'Apple n'est pas de brevet dessus.
                                    Etc.
                                    Avec la GPL, pas de soucis. RHEL est libre, donc il y a CentOS. Et si Red Hat se fait du pognon ? Ben tant mieux pour Red Hat.
                                    En passant, Red Hat vend un service, pas du code. CentOS n'a rien payé à Red Hat.

                                    La BSD permet de faire des programmes proprio. Pas la GPL.
                                    Je ne suis pas pro-GPL, je suis pro-libre, anti-proprio.

                                    > MacOSX aurait ete basé sur disons GNU/Linux. Ca aurait changé quoi ?

                                    Ben on aurait les drivers du hardware Mac par exemple.
                                    On pourrait auditer le code.
                                    Parque actuellement c'est moyen... et pas mieux pour les systèmes BSD.
                                    Et si Apple ajoutait des trucs tordus ou une extension à tcp/ip que seul Apple comprend, ben on est dans le merde, tout BSD que soit Mac OS.
                                    Et Apple avait fait iTune sous GPL ?
                                    Ben on aurait l'assurance de ne pas être emmerdé avec les brevets.

                                    > La GPL impose que le code soit diffusé au client, pas à l'ensemble de la communauté.

                                    C'est qui la "communauté" ?
                                    C'est ceux qui utilisent ton programme, ton code. Ces derniers (donc la communauté) à la code.

                                    > Apple a leeché du code BSD pour faire son MacOSX. Whaou c'est horrible.

                                    Non, ce n'est pas horrible pour un BSDiste.
                                    Mais c'est un fait. La BSD permet de faire du proprio.

                                    En passant, Theo De Raadt (pro BSD qui vomit la GPL) pleurait toute les larmes de son corps car un driver avait été passé de BSD à GPL (avec l'accord du déteneur du copyright, évidemment). Il gueulait car les contributions aux codes GPL ne pouvaient pas être incluses à la version BSD (mais il suffit de demander au mainteneur qui n'a pas la réputation d'être un tiran).
                                    Bizarre, que les BSDiste trouve ça horrible quand c'est Linux qui le fait (alors qu'il y a encore accès au code) et normal quand c'est Apple (alors qu'il n'y a plus accès au code).

                                    > La licence BSD a plusieurs avantages.

                                    Elle a surtout l'avantage de permettre de faire du proprio. Mac OS est proprio.

                                    > Imposer la liberté

                                    La liberté ou la dictature ça s'impose. La première c'est généralement le peuple qui l'impose, la seconde c'est un dictateur (avec l'armée).
                                    Sarkozy n'est pas libre car il n'a pas le droit d'imposer une dictature ?
                                    Une constitution qui autorise l'établissement d'une dictature est une constitution libre ?
                                    Une constitution qui défend/impose la liberté est une constitution pas libre ?

                                    Le fait même de dire "vous être libre" c'est imposer la liberté. La liberté implique la responsabilité.
                                    La GPL n'impose pas la liberté, elle donne des droits à celui qui obtient le programme. Droits que ce dernier utilise ou non. L'utilisateur n'est pas obligé de regarder le source, il n'est pas obligé de le modifier, etc.
                                    NB: les utilisateurs sont généralement beaucoup plus nombreux qui les diffuseurs.
                                    La GPL impose un devoir au distributeur : mettre à disposition le code source.
                                    La GPL n'est pas compatible proprio. Si le code a un brevet et qu'il est exiger, par exemple, de payer pour l'utiliser, la GPL ne permet plus la distribution.

                                    > Combien de GNU/Linuxien, au combien adepte du libre, utilise quotidiennement .doc, flash, le protocole msn, hotmail, les mp3z ...

                                    Et alors ?
                                    Fait un hymne à Windows tant que tu y es. Plus de 90 % des PC sont sous Windows. Ça ne veut pas dire que 90 % des gens accèptent la dictature Windows. Ils font avec, comme les habitants des dictatures font avec leur dictateur.



                                    J'ai rien contre les BSDiste (d'une certaine manière).
                                    Mais si vous aimer la possibilité que donne la BSD de faire du proprio, ben dite le au-lieu de vomir sur la GPL.
                                    • [^] # Re: Les mauvaises décisions

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

                                      ta prose entre la GPL et les brevets, c'est pipo et hors sujet. La GPL ne protège de rien. La seule chose qui peut protèger d'un brevets, c'est le prior art.

                                      En passant, Theo De Raadt (pro BSD qui vomit la GPL) pleurait toute les larmes de son corps car un driver avait été passé de BSD à GPL (avec l'accord du déteneur du copyright, évidemment). Il gueulait car les contributions aux codes GPL ne pouvaient pas être incluses à la version BSD (mais il suffit de demander au mainteneur qui n'a pas la réputation d'être un tiran).
                                      Bizarre, que les BSDiste trouve ça horrible quand c'est Linux qui le fait (alors qu'il y a encore accès au code) et normal quand c'est Apple (alors qu'il n'y a plus accès au code).


                                      Ben non c'est pas bizarre puisque dans ce cas la les devs du driver linux prétendaient faire du libre alors qu'ils ont sciemment bloqué l'accès au code aux autres acteurs du libre alors que le changement de licence n'apportait rien.

                                      Bon après tu déforme la réalité sur le fait que le déteneur du copyright avait donné son accord, ce qui n'était pas le cas.

                                      après dire que BSD est fait pour faire du proprio c'est du FUD. Dans ce cas on pourrait aussi dire que la GPL, c'est fait pour diviser le libre en empêchant le partage du code avec d'autres licences libres. Et bien non, ni l'une, ni l'autre des affirmations est vraie, ce sont des effets de bords. Personnellement, je trouve le second effet de bord (empêcher le partage de code entre des projets libres) bien plus grave que le second (permettre à des gens d'intégrer du code libre dans du proprio), puisque j'en ai rien à carrer de ce que font les vendeurs de proprio, ça ne touche pas mon système libre.
                            • [^] # Re: Les mauvaises décisions

                              Posté par  . Évalué à 0.

                              Je ne comprend pas pourquoi il se fait moinser, c'est vrai.
                              Ceci dit, ça arrive moins aujourd'hui.

                              M'enfin, la pile Windows est du BSD, Apple prend plein de truc à BSD et donne en retour à sa convenance, il y a (eu) des tonnes de systèmes Unix qui ont pompé BSD sans rien en retour, etc.

                              Un développeur qui prend la BSD et accèpte ça, ben c'est sa décision, c'est son code il n'y a rien à redire sur sa décision. La GPL n'accèpte pas ça. Que la GPL l'interdise, n'implique pas que la GPL est moins libre. A chaque fois que du code/binaire est sous GPL, c'est libre. Si du code/binaire est sous BSD, c'est peut-être libre.

                              Oui, j'en ai plein le cul des "la BSD sai plus libre que la GPL".
                              • [^] # Re: Les mauvaises décisions

                                Posté par  . Évalué à 5.

                                Juste pour rétablir un point

                                MS n'a jamais directement pris la pile de BSD, ils avaient a l'epoque achete la pile TCP/IP a une societe nommee Spider, qui elle s'etait basee sur BSD,et en tout cas depuis Windows 2000 c'est du 100% MS (et ca a de nouveau ete 100% reecrit pour Vista/WS08)

                                La pile spider n'a été utilisé que pour Windows NT 3.51, donc, ca fait au moins 15 ans.
                              • [^] # Re: Les mauvaises décisions

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

                                Oui, j'en ai plein le cul des "la BSD sai plus libre que la GPL".

                                Désolé, mais entre une licence qui interdit des choses, et une licence qui interdit pas, la liberté vient de celle qui n'interdit pas...
                                la GPL interdit de faire du non-GPL, la BSD ne l'interdit pas.
                                la BSD offre donc plus de libertés que la GPL.
                                CQFD.
                                C'est du français, des maths, rien de plus.

                                Ne change pas la significations des mots quand ça t'arrange... Ou alors, argumente : comment la GPL peut être plus libre (ou aussi libre) en interdisant plus de chose? Comment une licence qui empêche des libertés (faire du proprio est une liberté!!!) peut être considérée comme plus libre?
                                • [^] # Re: Les mauvaises décisions

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

                                  Question de point de vue.

                                  C'est le concept d'interdire pour *le bien de la communauté*. C'est totalement subjectif et j'admets volontiers que certains soient même révoltés par cette idée mais je la partage. Pour moi le plus important n'est pas la liberté de faire mais celle du savoir. La GPL assure et promeut la liberté du savoir, la BSD non. Fin du débat pour moi, mon choix est fait.

                                  Oui c'est politique, non ça n'est pas purement technique.

                                  Sinon : "C'est du français, des maths, rien de plus.". C'est très joliment dit mais exceptionnellement inexact. Je te suggère d'aller te renseigner sur le sens du mot "interprétation".
                          • [^] # Re: Les mauvaises décisions

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

                            Il ne semble pas que la GPLv2 protège de la DRMisation, Tivolisation et cie :). Et la majorité des projets sont encore distribués sous GPLv2 (ou later). Ah oui la fameuse GPLv3, encore plus illisible que la version précédente a écrit des trucs spécifiques pour ces cas particuliers (et je suis sur que ces salauds de devs^W avocats proprios vont trouver rapidement un moyen de contourner).

                            Le code BSD reste libre, autant que le code GPL. Clairement quand des gens qui font du proprio prennent du code BSD, ca ne lèse personne au final. Il vaut mieux qu'ils réutilisent du bon code libre que d'écrire du mauvais code (pour tout le monde).
                            • [^] # Re: Les mauvaises décisions

                              Posté par  . Évalué à -1.

                              > Le code BSD reste libre, autant que le code GPL.

                              Si tu utilises un super programme et te dis "Hum, j'aimerai bien voir comme il marche et lui faire un petit modification", que ce passe-t-il si c'est la BSD ou la GPL.

                              Si le programme est sous GPL : Tu as un droit d'accès aux sources et celui qui a founit le programme a obligation de fournir les sources.

                              Si le programme est sous BSD : Ben ça dépend. Il va peut-être te vendre le code à un prix exorbitant.

                              Le code est libre, mais y-a-tu accès ? Avec la GPL c'est OUI (et au pire au prix du support/transport). Avec la BSD, peut-être.

                              Le code est libre avec la BSD. Le programme pas forcément.

                              Que veulent les gens ?
                              Moi je veux des programmes libres (et donc j'aurais les sources si nécessaire).
                              Je ne veux pas peut-être des bouts de code à des conditions décidé par d'autres. Je ne veux pas que ma liberté soit décidé par d'autres.
                              • [^] # Re: Les mauvaises décisions

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

                                Moi je veux des programmes libres (et donc j'aurais les sources si nécessaire).

                                Un code sous BSD respecte les 4 libertés de la FSF, il est donc libre (et reconnu comme libre par la FSF.
                                Je ne sais pas ce qu'il te faut...

                                Sinon, le reste de ta propose est un mélange de tout, entre un code fourni sous BSD (qui est libre) et un code fermé qui s'est basé sur du code fermé (c'est pas libre, on s'en fout)

                                Si le programme est sous BSD : Ben ça dépend. Il va peut-être te vendre le code à un prix exorbitant.
                                N'importe quoi : si c'est sous BSD, le code est dispo, comme pour la GPL.
                                La tu parles q'un autre code, pas sous BSD.
                                Ca n'a rien à voir.
                                • [^] # Re: Les mauvaises décisions

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

                                  [HS]
                                  Tu ne devrai pas te fatiguer à répondre à IsNotGood. Moi je me tais et je me contente de le moinser (je lis le commentaire quand même en général, mais vu la qualité général de l'oeuvre du bonhomme).
                                  [/HS]
                                  • [^] # Re: Les mauvaises décisions

                                    Posté par  . Évalué à -9.

                                    C'est vrai que quand on n'a rien à dire, ou on dit de la merde, car on a des idées obtues le moinssage est d'une facilité simplissime. Zul & Zenitram nos deux compères sauveurs de la planète et de la liberté, même de celles les plus immorables que de coder et ce faire spoiler son code sans jamais avoir de contribution en retour.

                                    Sérieusement avouez on vous invite souvent à aller diner tout les deux ? Non pas la peine de répondre je vous bien occupés tout les soirs. Faut dire aussi que vous avez de bonne têtes de vainqueurs. Si Si je vous assure, vous pourriez avoir des doutes... néanmoins permettez moi de vous les enlever et vous assurer que vous un profil excellent. Non vraiment je trouve.
                • [^] # Re: Les mauvaises décisions

                  Posté par  . Évalué à 4.

                  Le meilleur compromis alors c'est peut-être la LGPL, même pour les applis !

                  Avec la LGPL, je garantis que mon travail et ce qui en est dérivé reste libre, mais je n'impacte pas le choix des autres.

                  Avec la LGPL, je ne mets pas de limite technique à cause de choix politique (un autre exemple ? Tiens, suppose que je veuille expérimenter un noyau d'OS avec davantage de parties en user-space (sous forme de libs) et un micro-noyau tout petit. Je ne peux pas me baser sur Linux car autrement toutes les libs/applies qui se linkeront (par exemple) à ma lib qui gère le système de fichiers devront être sous GPL ! Aucun problème de cet ordre si tout était LGPL !)

                  Les devs BSD reconnaissent souvent eux-mêmes que la GPL leur pose problème, mais pas la LGPL... !
                  • [^] # Re: Les mauvaises décisions

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

                    Je rajoure perso l'exception de link statique comme le fait OCaml (voir la licence de la bibliothèque standard d'OCaml), voir j'utilise la CeCILL C qui ne parle pas de technique (parce que faire une différence entre lien statique et dynamique, sachant que sur certaines architectures, le lien dynamique n'existe pas...)
            • [^] # Re: Les mauvaises décisions

              Posté par  . Évalué à 6.

              Je pense aussi qu'il n'est pas tout a fait innocent que la suite apple n'est pas de filtre ODF par exemple.

              Oui et ce qui est d'autant plus amusant, c'est que leur système semble contenir un lecteur de documents odf (leur logiciel textedit et les aperçu savent les afficher), donc ils ne peuvent même pas prétexter un manque de moyens/temps pour l'implémenter. Ce sont vraiment des faux-culs.
        • [^] # Re: Les mauvaises décisions

          Posté par  . Évalué à 4.

          L'équipe de LLVM est embauchée par Apple, même.
    • [^] # Re: Les mauvaises décisions

      Posté par  . Évalué à -1.

      > 1) rendre plus difficile l'ajout de nouveau languages

      Pourtant gcc est le compilateur qui supporte le plus de language...

      > 2) motiver des gens pour faire une alternative a gcc.

      Pourtant gcc n'a toujours pas de réel concurrent alors qu'il existe depuis des années...

      > Résultat, un compilateur sous BSD proprio compliant alors qu'on aurait pu avoir du gcc en GPL, certes soumis a quelques dérives et abus autour de la GPL, mais au moins sous la pierre angulaire de GNU : sa licence.

      BSD préfère le proprio au libre, c'est les oignons de BSD. Ce n'est pas les affaires de RMS ni de la FSF qui n'ont pas pour but d'être proprio friendly contrairement à BSD.

      > A chaque fois que quelqu'un fait des décisions de conception apportant des limitation techniques pour soit disant 'protéger' son application, ca se finit en drame.

      Et quel drame !
      Gcc est le meilleur compilateur libre actuellement disponible.

      Joli score ton commentaire alors qu'il n'a que du FUD.
      • [^] # Re: Les mauvaises décisions

        Posté par  . Évalué à 9.

        > Pourtant gcc est le compilateur qui supporte le plus de language...
        Oui, d'ailleurs c'est un vrai tour de force.
        Il supporte aussi un max de plateformes et architectures. La liste dans les sources est assez impressionnante.

        Il est juste dommage que le code de GCC ne soit pas plus facilement réutilisable pour écrire des outils d'analyse du code source, des outils pour la documentation, le refactoring, etc. Cela n'encourage pas à l'utiliser pour créer d'autres outils. Est ce un manque de documentation, de tutoriaux, ou bien un mal plus important tel que le manque de modularité?

        C'est la que clang + llvm offre une plus grande réutilisation en offrant des librairies que l'on n'a qu'à empiler comme des briques.
        Ensuite, il est vrai que la licence de llvm facilite la propriétisation du code, malheureusement, chose que la GPL n'autorise pas. Bref, c'est du Apple tout craché.

        C'est pourquoi GCC devrait avoir une architecture plus ouverte pour permettre de "plugger" différentes analyse ou même réutiliser le front end indépendamment du middle end ou du back end ce qui apparemment n'est pas facile actuellement.
        Ensuite rien ne leur empêche de dire que les interfaces ne sont pas figées et que ceux qui les utilise le font à leurs risques et périls. C'est ce qui se passe dans le libre, pour tous les patches au noyau, pour ses interfaces internes, ainsi que pour beaucoup d'autres projets libres. Là où le libre est très fort, c'est pour s'adapter à ces changements, alors que le logiciel propriétaire n'aime pas du tout ça:
        cf Vista qui casse tous les logiciels propriétaires uniquement distribués en binaire et qui sont bons à jeter à la poubelle lors d'un changement d'OS, sauf à prier pour des patches de Microsoft ou de l'éditeur du soft qui résoudraient le problème, mais là, on peut toujours espérer.


        En tout cas, longue vie à GCC et un grand merci à ses développeurs!!
      • [^] # Re: Les mauvaises décisions

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

        BSD préfère le proprio au libre, c'est les oignons de BSD. Ce n'est pas les affaires de RMS ni de la FSF qui n'ont pas pour but d'être proprio friendly contrairement à BSD.

        Purée mais vous allez arrêter un jour ?

        Quand on choisit une licence bsd, en général c'est pour dire, j'ai (on a) fait un truc sympa, c'est cadeau faîtes-en ce que vous voulez, et ce n'est jamais, à ma connaissance, on s'est défoncé alors faîtes du pognon avec notre truc sans nous aider.
      • [^] # Re: Les mauvaises décisions

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

        > Pourtant gcc n'a toujours pas de réel concurrent alors qu'il existe depuis des années...

        Il en a eu un : egcs. Celui-ci a tellement bien marché que la branche originale de gcc a été abandonnée et que egcs est devenu le nouveau gcc:

        http://en.wikipedia.org/wiki/Egcs

        La lecture de l'article est d'ailleurs édifiante sur l'attitude à l'époque de la FSF vis à vis de développement logiciel ouvert. Ils ont peut-être écrit la GPL mais leur attitude laisse presqu'à penser qu'ils auraient préféré que gcc reste un logiciel libre mais fermé dans le giron de la FSF.

        Pour réussir le fork d'un projet comme gcc, il faut quand même être sacrément motivé. Les développeurs ont du sérieusement être énervés par RMS.

        Avec ça, XEmacs et Hurd, on peut dire que la FSF montre quand même gravement ses limites en terme de "vision technique". C'est pas étonnant qu'un étudiant finlandais ait réussi à faire mieux qu'eux, il suffisait d'ouvrir le développement du code.
        • [^] # Re: Les mauvaises décisions

          Posté par  . Évalué à -6.

          Tu n'aurais pas une source plus fiable que wikipedia?
        • [^] # Re: Les mauvaises décisions

          Posté par  . Évalué à 4.

          mieux qu'eux

          Mieux que sur quoi ? tu vas pas un peu vite, là ?... La FSF ne se résume pas au Hurd. Son travail ne porte pas que sur un noyau (gcc, bash, tar, gzip, less, etc. etc).
          J'ai du mal à voir les limites de la vision technique de la FSF, dans la mesure où un tas de ses projets sont couramment utilisés aujourd'hui. De plus ces projets, mis en route dans les années 80, sont anciens et souffrent peut-être de cela ainsi que de la compatibilité voulue avec les outils Unix existants.

          Linus a réutilisé plein de petits et gros projets de la FSF et a semblé en apprécier les qualités techniques (il l'a dit autrefois).

          Maintenant que la FSF ne soit pas omnisciente, qu'elle se soit plantée parfois, prouve seulement qu'elle n'est pas constituée d'anges guidés par un dieu. La belle affaire.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: Les mauvaises décisions

            Posté par  . Évalué à 2.

            ouhais mais Errare humanum est, perseverare diabolicum et c'est ce que fait un peu le FSF. Le Hurd ca veut 15 ans qu'ils en parlent, ca fait des annees que c'est soit disant la faut du noyau mach si hurd traine (MacOSX semble demontrer que c'est pas franchement vrai), le passage a L4 qui etait annonce et qui a longtemps "ralenti" le reste du boulot a jamais ete fait il me semble et je ne sais meme pas si Hurd peut avoir des partitions de plus de 2Gigs. C'etait rigolo il y avait avant sur ce site des devs de hurd donc on etait un peu au courrant de ce qui se passait. Visiblement le projet est totalement mort et la FSF devrait peut etre l'admettre...
            • [^] # Re: Les mauvaises décisions

              Posté par  . Évalué à 3.

              Oh non Hurd n'est pas mort!!! Il est juste en sommeil (comme les volcans, c'est a dire pour très longtemps). Je crois que le port L4 est mort pour une sombre histoire de feature manquante nécessaire a la vision Hurdienne du monde qui permettait d'autoriser certaines opérations entre serveurs Hurd et de se passer les autorisations entre eux (les capabilities).

              Les devs Hurd voulaient remplacer L4 par un autre noyau, Coyotos pour lequel Jonathan Shapiro joue un grand role ( https://linuxfr.org//2005/09/26/19619.html , oui! ca date de 2005!). D'apres ce que j'avais lu, Markus Brinkmann travaille sur d'autres projets actuellement. Est ce qu'il va jamais revenir sur Hurd? Je me pose légitimement la question.

              Dans une interview que j'ai lu il y a un moment, RMS disait simplement que le besoin philosophique pour le Hurd était retombé depuis que Linux avait pris sa place. Bref, RMS reconnaît que le Hurd n'est plus si utile que ça.
              Maintenant s'il y a des gens qui veulent bosser dessus, ce n'est quand même pas la faute de la FSF!!
              Enfin dire qu'un projet est mort arrive rarement, par contre le nombre de projet orphelin est lui assez phénoménal. Je crois d'ailleurs que la FSF recherche des mainteneurs pour certains de ces projets.

              PS: non je ne suis pas dév du Hurd ni meme utilisateur.
              • [^] # Re: Les mauvaises décisions

                Posté par  . Évalué à 1.

                Maintenant s'il y a des gens qui veulent bosser dessus, ce n'est quand même pas la faute de la FSF!!

                Certes mais bon c'est tout de meme le kernel officiel de la FSF a moins que cela ait change aussi. Ca me rappelle un peu GNUstep qui est (etait) cense etre le bureau officiel de la FSF...

                Enfin chacun fait ce qu'il veut de son temps libre (ou paye :) ) c'est ca la liberte!
    • [^] # Re: Les mauvaises décisions

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

      C'est au contraire une bonne décision.

      Tous les soft populaires en BSD qui ont interressé les boites proprio ont connu des forks dans tous les sens incompatibles entre eux (X11, spice, ...).

      "La première sécurité est la liberté"

    • [^] # Re: Les mauvaises décisions

      Posté par  . Évalué à 1.

      C'est incroyable de voir égrainer autant de contre-vérités aussi flagrantes, et de les voir plussées de surcroit :

      >1) rendre plus difficile l'ajout de nouveau languages
      gcc supporte 7 langages en standards, et 7 de plus ce qui mène à 14 : c'est de très loin le compilateur au monde supportant le plus de langages (et le plus de plateformes cibles) !!

      >2) motiver des gens pour faire une alternative a gcc.
      ah bon?? d'ailleurs il en existe tellement que les *BSD utilisent...gcc ! et comme tout le monde en fait, car il n'y a justement pas le choix!

      >Richard Stallman a choisi explicitement de ne pas le rendre modulaire afin de ne pas permettre a des programmes propriétaires de s'interfacer avec lui.

      C'est totalement absurde, que ce soit passé entre les fouches caudines de la modération et affiché en première page est réelement incroyable.
      Ce qui protège GCC des programmes propriétaires c'est sa licence : la GPL, pas son architecture!
      De plus LLVM utilise l'AST fourni par GCC, c'est donc bien qu'il permet de s'interfacer dans les étapes intermédiaires de la compilation.
      • [^] # Re: Les mauvaises décisions

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

        >>> C'est totalement absurde, que ce soit passé entre les fouches caudines de la modération et affiché en première page est réelement incroyable.

        Au lieu de t'offusquer tu ferais mieux de lire le lien posté plus haut par Troy McClure.
        C'est un post de Stallman lui même qui explique pourquoi GCC ne doit pas être rendu modulaire car cela faciliterait l'utilisation par des firmes faisant du code proprio.
        Et oui, ce que tu qualifiais de "totalement absurde" et indigne d'apparaitre sur linuxfr et bel et bien vrai.

        Pour info un petit extrait du post de RMS :
        "Anything that makes it easier to use GCC back ends without GCC front ends--or simply brings GCC a big step closer to a form that would make such usage easy--would endanger our leverage for causing new front ends to be free."

        Selon RMS c'est cette absence voulue de modularité qui a permis l'inclusion des frontends C++ et ObjectiveC dans GCC et donc cette non modularité a été bénéfique pour le libre :
        "The reason we have free C++ and Objective C support is because the companies which wrote these front ends had no *feasible* way to use them without making them part of GCC, where the GPL required them to be free. It is vital that we preserve this situation."
  • # Performances ?

    Posté par  . Évalué à 2.

    Ca à l'air tout joli comme architecture.
    Mais au niveau des performances ça donne quoi ? Parce que bon c'est quand même un des buts premiers des compilateurs et GCC n'est pas forcément non plus le plus rapide du monde. Si c'est pour avoir voir un compilateur mieux architecturé mais encore plus lent...
    • [^] # Re: Performances ?

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

      Euh, tu parles de la vitesse du compilateur ou de la vitesse du code produit ?
    • [^] # Re: Performances ?

      Posté par  . Évalué à 2.

      Au niveau du code générer je crois qu'il y a encore pas mal de boulot à faire pour avoir du code plus performant que gcc.
      • [^] # Re: Performances ?

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

        LLVM 2.0+gcc 4.2 est 20% plus rapide que gcc 4.2 seul :
        http://lucille.atso-net.jp/blog/?p=294

        L'architecture de LLVM permet des optimisations que gcc n'est âs capable de produire.

        Je serai intéressé par des benchmarks frais ;-)
        • [^] # Re: Performances ?

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

          Je n'arrive pas à lire le lien mais je serais très étonné que le résultat résumé soit réaliste et significatif. Effectivement, sur architecture Intel (au hasard :-) em64t mes propres benchmarks et plusieurs autres que j'ai pu trouver sur le net montrent que gcc est environ 10% moins rapide que le compilateur intel (ifort/icc) qui fait tout de même figure de référence sur cette architecture. Alors 20% de mieux que gcc... Je suis un peu dubitatif.

          « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

          • [^] # Re: Performances ?

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

            Ah oui, l'url semble HS maintenant. Une copie avec Google Cache :

            gcc 4.0.1(apple) (latest gcc from Xcode Tools)
            $ gcc -o bmt -O3 -DSMALL himenoBMTxps.c
            $ ./bmt
            ...
            Gosa : 1.167853e-04
            MFLOPS measured : 544.017453 cpu : 56.726971
            Score based on Pentium III 600MHz : 6.634359

            gcc 4.2
            $ gcc-4.2 -o bmt -O3 -DSMALL himenoBMTxps.c
            $ ./bmt
            ...
            Gosa : 1.753087e-05
            MFLOPS measured : 953.891485 cpu : 54.242544
            Score based on Pentium III 600MHz : 11.632823

            Emit LLVM code with llvm-gcc-4-2.0, then exec it with LLVM JIT.
            $ ~/src/llvm-gcc4-2.0-x86-darwin8/bin/llvm-gcc -emit-llvm \
            -O3 -DSMALL -c himenoBMTxps.c
            $ ~/src/llvm-2.0/Release/bin/lli himenoBMTxps.o

            Gosa : 2.229028e-05
            MFLOPS measured : 1147.841139 cpu : 42.767418
            Score based on Pentium III 600MHz : 13.998063

            The result tells me that LLVM JIT does good job(20% faster than natively geneted code by gcc-4.2),
            altough we must pay attention that “Gosa”(which means computational error in Japanese) is a bit higher than gcc-4.2’s result.
            gcc-4.0.1 is fairly bad… I don’t know why…
            • [^] # Re: Performances ?

              Posté par  . Évalué à 3.

              Ho mais tu triches, ton code générer par llvm n'est pas exécuter nativement comme pour gcc, mais dans une VM qui fait des optimisations JIT.

              Et je pari que comme par hasard, le code est friand d'optimisation JIT...
              • [^] # Re: Performances ?

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

                Hum, en quoi est-ce de la "triche" ? Le but est d'aller le plus vite possible, qu'importe les moyens. gcc n'a pas de JIT, il va moins vite. LLVM utilise du JIT, il va plus vite. Bah vive le JIT non ?
                • [^] # Re: Performances ?

                  Posté par  . Évalué à 2.

                  Ouai enfin le benchmark, c'est quoi? Un seul test, plusieurs?

                  Si c'était un truc connu genre SpecInt, ce serait peut-être plus crédible, la évaluer un compilateur sur un obscur benchmark, c'est peut-être un peu leger..
                • [^] # Re: Performances ?

                  Posté par  . Évalué à 1.

                  euh non, le but c'est de pouvoir optimiser de façon le plus générique possible, entre une optimisation qui permet de gagner 10% du temps sur un cas particulier, mais qui donne du code 20% moins rapide 99% du temps, et une qui donne du code 5% plus rapide 100% du temps,

                  devine qui on va choisir.

                  Bref, un benchmark ça veut RIEN dire, encore moins quand y a rien de précisé.
              • [^] # Re: Performances ?

                Posté par  . Évalué à 1.

                Que le programme soit choisi pour mettre en valeur les qualités de llvm, c'est de bonne guerre. En revanche, l'argument « ho et la, machine virtuelle, tricher... », je ne suis pas d'accord. Pour l'utilisateur, entre taper ./toto et ./titi, c'est du pareil au même. Ensuite, que toto soit une machine virtuelle qui interprete un programme bytecode ou un script python ou un binaire, c'est du pareil au même. Donc si avec des machines virtuelles, on peut toujours avoir de meilleur performances, pourquoi gcc ne s'y met pas ?
      • [^] # Re: Performances ?

        Posté par  . Évalué à 2.

        Au niveau du code générer je crois qu'il y a encore pas mal de boulot à faire pour avoir du code plus performant que gcc.

        Ah bon? Ce n'est pourtant pas particulièrement difficile. Des compilos qui font du code plus efficace que gcc ça ne manque pas.
        Sur cible ARM, gcc se prend une grande claque par rapport à RVCT ...
        • [^] # Re: Performances ?

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

          Après, il faut voir que gcc est multi-plateforme. Il y a surement des plateformes où le générateur final est à la traine et donc gcc se fait exploser sur les benchs.

          Ce qui est intéressant, c'est que sur une plate-forme a priori bien maintenue, intel, gcc n'est pas si à la traine que ça. Ca veut dire que globalement, il tient la route.
          • [^] # Re: Performances ?

            Posté par  . Évalué à 3.

            Je ne dis pas le contraire.
            Mais la plateforme ARM n'est pas ce que l'on peut appeler une plateforme marginale. Je n'ai pas de chiffre mais à vue de nez je dirais qu'il y a plus de code dans le monde qui tourne sur du ARM que sur du x86 ...
            • [^] # Re: Performances ?

              Posté par  . Évalué à 1.

              "Je n'ai pas de chiffre mais à vue de nez je dirais qu'il y a plus de code dans le monde qui tourne sur du ARM que sur du x86 ... "
              Cette phrase m'ayant surpris, je suis allé chez l'ami Wikipedia ([[Processeur ARM]]) et j'y ai vu ceci :
              "L'architecture ARM est très répandue notamment dans la téléphonie mobile. De nombreux systèmes sont portés sur cette architecture. À savoir Linux avec Android, Mac OS X avec l'iPhone, et Windows Mobile."

              Il y a donc plus de téléphones mobiles que d'ordinateurs dans le monde ?
              • [^] # Re: Performances ?

                Posté par  . Évalué à 1.

                Oh que oui! En France le taux de pénétration des téléphones mobiles doit tourner autour de 90%, les PC environ 60 ou 70% (?). En asie dans des pays comme la Chine et l'Inde les téléphones mobiles sont très répandu alors que les PC ...
                • [^] # Re: Performances ?

                  Posté par  . Évalué à 1.

                  il n'y a pas que les pc grands publics qui sont à base de x86, hein.
                  • [^] # Re: Performances ?

                    Posté par  . Évalué à 2.

                    Non bien sur mais il n'y a pas non plus que les téléphones mobiles qui sont à base de ARM...
                    Perso ça fait plus de 10 ans que je bosse dans l'embarqué et je n'ai jamais eu à bosser sur une plateforme x86.

                    PS: je n'ai pas dit qu'il n'y avait d'embarqué sur x86.
          • [^] # Re: Performances ?

            Posté par  . Évalué à 2.

            Il ne faut pas oublier que l'archi x86 (32 ou 64 bits) comprend tout plein de mécanismes hardware qui font que du code pas très optimisé tourne au final pas si mal. Par exemple sur architecture Core, on a des prefetchers hardware au niveau des caches, un cache de micro-instructions (bon ok, tout petit, mais quand meme), une exécution dans le désordre des instructions ... Bref, le compilateur est beaucoup soulagé par une architecture qui fait beaucoup de choses sans qu'on lui demande.
        • [^] # Re: Performances ?

          Posté par  . Évalué à 3.

          Ah bon? Ce n'est pourtant pas particulièrement difficile.
          Ben propose tes patchs a gcc.

          Sur cible ARM, gcc se prend une grande claque par rapport à RVCT .
          Qui est le compilo de ARM et qui ne gère que ARM.

          De plus le passage gcc3.x à gcc 4.x à quand même améliorer les choses en taille et vitesse.

          PS : pour llvm, regarde le README arm pour juger l'état
  • # plusieurs projets...

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

    gcc n'est pas si monothique que ça... il a besoin de binutils pour générer des binaires.
    Malheureusement il semble qu'ici aussi on ait droit à plusieurs projets séparés (pas au même endroit).

    Je crains que celà n'implique les même problèmes qu'avec gcc+binutils dont il faut toujours chercher quelles versions fonctionnent ensemble, surtout si on doit utiliser une certaine version d'un des deux.
  • # questions

    Posté par  . Évalué à 6.

    A la lecture de la news, j'ai quelques point que je ne comprend pas.

    J'avais cru comprendre que LLVM transformait un code intermédiaire en assembleur.
    Un frontend (gcc, clang) se chargeant de convertir le langage source utilisé dans ce langage intermédiaire.

    Or dans ce cas, comment un changement du frontend améliore les performance [1]. Il génère un code intermédiaire plus détaillé ?

    On nous parle de type "long double" supporté par LLVM, mais c'est pas plutôt le boulot du frontend de supporter les types du language qu'il parse ? Après lecture des release note, la modif est bien dans llvm-gcc.

    On nous parle pas du tout de bibliothèque rattaché au langage.
    Par exemple quelle libc llvm-gcc/clang supporte ?
    Ou sera l'équivalent de libgcc (qui par exemple implémente le support des flottants en soft pour les archi qui ne l'ont pas) ?


    PS :
    Un inconvénient à LLVM est qu'il n'est pas bootstrapable facilement, c'est à dire qu'il aura toujours besoin que le système de destination ai déjà un compilo c++.


    [1]
    Le frontal utilisé passe de GCC 4.0 à GCC 4.2 afin d'améliorer les performances.
    • [^] # Re: questions

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

      Or dans ce cas, comment un changement du frontend améliore les performance [1]. Il génère un code intermédiaire plus détaillé ?

      GCC fonctionne un peu comme LLVM : il a un code intermédiaire dans lequel est traduit le code venant du front-end (Gcc, Gcj, Ada, G++, etc ...), ce code est ensuite traduit dans l'assembler cible, après avoir été optimisé.

      Je suppose que LLVM s'est fait un mode GCC dans lequel l'assembleur cible est le bytecode LLVM. Bien évidemment, il profite des optims du processus de compilation de GCC.

      On nous parle de type "long double" supporté par LLVM, mais c'est pas plutôt le boulot du frontend de supporter les types du language qu'il parse ? Après lecture des release note, la modif est bien dans llvm-gcc.

      Je suppose que c'est un problème de gestion du 64 bits dans l'assembleur cible (ie. LLVM), dans laquelle la gestion du "plus que 32" doit être un problème, à cause de la "sérialisation" de ce genre de nombre sur deux valeurs de 32 bits.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: questions

        Posté par  . Évalué à 3.

        Je suppose que c'est un problème de gestion du 64 bits dans l'assembleur cible (ie. LLVM), dans laquelle la gestion du "plus que 32" doit être un problème, à cause de la "sérialisation" de ce genre de nombre sur deux valeurs de 32 bits.

        Non, ca doit être dans le front-end, ca fait un moment que le bitcode de llvm supporte des entiers de taille arbitraire.
      • [^] # Re: questions

        Posté par  . Évalué à 2.

        Je suppose que LLVM s'est fait un mode GCC dans lequel l'assembleur cible est le bytecode LLVM. Bien évidemment, il profite des optims du processus de compilation de GCC.
        Ha, dans ce cas ça fait un truc quand même assez tordu :
        - gcc converti le langage dans sa representation interne.
        - Il fait des optimisation dessus (générique et propre à la cible). Dans notre cas c'est quoi la cible LLVM ou l'archi finale ?
        - Ensuite cette representation serait converti en bytecode LLVM.
        - Ce bytecode serait ensuite retransformé par LLVM.
        - Puis on générerait enfin le code assembleur.

        Et comment il vont faire avec clang ?
        • [^] # Re: questions

          Posté par  . Évalué à 1.

          Je pense que seul le frontend de GCC est utilisé. C'est vraiment trop tordu autrement!!
          En plus le besoin pour LLVM serait reduit: Refaire 2 fois toutes les optimisations? Faire toutes les conversions entre les formats internes de GCC? Quelle perte de temps lors de la compilation!!

          clang va transformer directement le code C vers représentation intermédiaire de LLVM. Regarde le tutoriel de la création d'un front end pour avoir une idée de comment c'est réalisé.
    • [^] # Re: questions

      Posté par  . Évalué à 2.

      > Or dans ce cas, comment un changement du frontend améliore les performance [1]. Il génère un code intermédiaire plus détaillé ?
      Les notes de version en anglais, ne parlent pas d'amélioration des performances grâce au changement de front end gcc.

      > On nous parle de type "long double" supporté par LLVM, mais c'est pas plutôt le boulot du frontend de supporter les types du language qu'il parse ? Après lecture des release note, la modif est bien dans llvm-gcc.
      Oui pour les types propres au langage, mais il faut également qu'ils disposent d'un équivalent dans le middle end. Apparemment, c'est ce qui a été implémenté ici: un équivalent du type "long double" pour l'IR (la représentation interne) de LLVM. Ensuite, cela se traduit au niveau utilisateur par un support du type C "long double" tel qu'on l'attend de la part du compilateur.

      > On nous parle pas du tout de bibliothèque rattaché au langage.
      > Par exemple quelle libc llvm-gcc/clang supporte ?
      http://llvm.org/releases/2.2/docs/ReleaseNotes.html#portabil(...) :
      # Intel and AMD machines running on Win32 using MinGW libraries (native).
      # Intel and AMD machines running on Win32 with the Cygwin libraries (limited support is available for native builds with Visual C++).

      Pour linux je suppose qu'ils utilisent les librairies standard de GCC, llvm-gcc n'étant qu'un compilateur après tout.

      > Ou sera l'équivalent de libgcc (qui par exemple implémente le support des flottants en soft pour les archi qui ne l'ont pas) ?
      hé bien justement il n'y a pas d'équivalent:
      llvm-gcc 4.2 supports CellSPU as a 'configure' target and progress is being made so that libgcc.a compiles cleanly. Notable pieces still in development include full 64-bit integer and full double precision floating point support.
      • [^] # Re: questions

        Posté par  . Évalué à 2.

        hé bien justement il n'y a pas d'équivalent:
        llvm-gcc 4.2 ...

        Oui mais à terme ils comptent abandonner gcc ? Non ?
        • [^] # Re: questions

          Posté par  . Évalué à 1.

          Je pense que oui, mais ils ne peuvent pas tout faire d'un coup.
          J'aurais peut être du écrire: "pour le moment il n'y a pas encore d'équivalent".
  • # Re:

    Posté par  . Évalué à 3.

    > LLVM au contraire est placé sous licence BSD et a choisi une conception très modulaire afin d'être réutilisé au maximum par tous.

    > De plus la licence GPL de GCC garantit aux divers contributeurs que leur code ne pourra pas être "propriétarisé" par un concurrent. Cela explique que nombre de firmes (IBM, Red Hat ou Novell pour n'en citer que quelques unes) financent largement le développement de GCC.

    Tu ne crois pas que tu fais une contradiction ?

    En passant, Linux est modulaire mais est très strict. La modularité de Linux en outrepassant la licence GPL est quasi uniquement pour les drivers. Il n'y a pas et n'aura pas de système de fichier proprio distribué avec Linux par exemple. Idem pour la VM, la pile tcp/ip, etc.
    Donc gcc pourrait très bien être modulaire sans que son objectif de rester libre soit remis en cause. Il ne faut pas mélanger ces deux questions.


    Globalement, ça commence à me chauffer les oreilles ces critiques ou remises en cause de gcc. Gcc est libre, s'il y a des problèmes techniques (et non politique, gcc doit rester libre et non être un truc proprio-friendly) il y aura un fork. Il y a déjà eu un fork de gcc ! C'était egcs (repris par quasiment toutes les distributions Linux).
    S'il y a un vrai problème avec gcc, il y aura fork (comme c'est arrivé avec egcs). Pour l'instant il n'y a pas le début d'un ambrillon d'amorce de fork. Donc gcc n'est pas remise en cause. Qu'il y ait des concurrents à gcc, ne remet pas en cause gcc. Gnome a des concurrents (KDE, XFCE), ça ne remet pas en cause Gnome. Linux a des concurrents (*BSD, OpenSolaris), ça ne remet pas en cause Linux. Le libre n'interdit pas la diversité, fort heureusement. Le libre ce n'est pas dicter un produit pour tout le monde.
    Enfin, c'est une petite erreur de mettre en concurrent "open source" et logicie libre. La GPL garantit que c'est et ça reste du logiciel libre. Une licence open source ne c'est pas le cas.

    Enfin quel remise en cause ? Le but de gcc en prenant la licence GPL, n'est pas être le compilateur le plus populaire de la planète. Le but est d'être libre ET totalement libre (avoir un compilateur sans dépendre d'éléments proprio). Gcc est libre (comme depuis des années), donc gcc (sous GPL) a rempli cet object.
    Que gcc soit aujourd'hui populaire est un "effet de bord".
    Si gcc devient moins populaire par l'arrivée de solution plus proprio-friendly (open source mais pas free software), ça ne remet aucunement en cause gcc. Ce qui pourrait remettre en cause gcc, c'est l'arrivé d'un compilateur logiciel libre (sous GPL typiquement) et qui devient plus populaire que gcc (comme c'est arrivé avec egcs (que ça soit un fork de gcc ou non ne change rien).

    Souvent les gens pensent que la BSD va amener des contributions des boites commerciales. Le choix de la BSD est souvent fait pour ça. Mais en moyenne ce n'est pas ce qu'on voit. On voyait ça il y a de nombreuses années, ce n'est plus le cas aujourd'hui.
    Contrairement aux idées reçues (je ne dis pas ça pour patrick_g) la GPL est souvent appréciée par les boites commerciales. Elle est détestée par les boites qui veulent faire du proprio (MS déteste la GPL et aime la BSD). Une boite commerciale n'est pas toujours une boite qui veut faire du proprio. On peut se réjouir de constater que c'est de moins en moins le cas. On peut se réjouir de voir que logiciel libre n'est pas l'ennemi des boites commerciales.

    Avec gcc (via la licence GPL) on a la garantit que gcc restera libre. Ce n'est pas le cas de llvm. Même si llvm devient meilleur que gcc, je resterai sous gcc.
    • [^] # Re: Re:

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

      Avec gcc (via la licence GPL) on a la garantit que gcc restera libre. Ce n'est pas le cas de llvm. Même si llvm devient meilleur que gcc, je resterai sous gcc.

      Et alors qu'est ce qui t'empeche de faire un fork de llvm en gpl ? (à part la mauvaise foi)
      • [^] # Re: Re:

        Posté par  . Évalué à -1.

        combien de langage et/ou d'architecture supporte par llvm?

        Vu que ce projet est un projet apple je soupconne que en dehors des architectures concernant leur matos il y aura pas grand chose.
        • [^] # Re: Re:

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

          llvm n'est pas un projet apple, c'est un projet d'origine académique qui a beaucoup interessé apple (qui a du coup embauché chris lattner, qui etait à l'origine du projet)
      • [^] # Re: Re:

        Posté par  . Évalué à -1.

        > Et alors qu'est ce qui t'empeche de faire un fork de llvm en gpl ?

        Tu n'as pas le droit.
        Soit t'es de mauvais foi, soit t'y connais rien en licence.
        • [^] # Re: Re:

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

          developpe un peu alors, pour l'édification des masses.
          • [^] # Re: Re:

            Posté par  . Évalué à -1.

            Seul le détenteur du copyright peut modifier la licence.
            • [^] # Re: Re:

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

              c'est un peu différent en fait, on peut relicencier le logiciel sous une autre licence, mais le code qui est déja en BSD restera en BSD. C'est un peu comme si le logiciel était en double licence sur certaines parties du code.
              • [^] # Re: Re:

                Posté par  . Évalué à 1.

                C'est un peu comme si le logiciel était en double licence sur certaines parties du code.

                Les parties de code issues de LLVM ne sont pas sous double licence. Elles restent en BSD. Le nouveau code par contre peut être en GPL.

                Mais je n'appelle pas ça "un fork de LLVM en GPL".

                Si on veut créer un "LLVM" GPL, il faut réécrire tout le code BSD, et ce n'est donc plus un fork.
                • [^] # Re: Re:

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

                  Les parties de code issues de LLVM ne sont pas sous double licence. Elles restent en BSD. Le nouveau code par contre peut être en GPL.

                  Mais je n'appelle pas ça "un fork de LLVM en GPL".


                  Dans ce cas, le logiciel sera sous GPL, donc, à mon avis, on peut appelé ca un fork de LLVM en GPL.
              • [^] # Re: Re:

                Posté par  . Évalué à 2.

                En fait si j'ai bien compris la licence Illinois Open Source License/NCSA (licence de LLVM), le code source initialement développé sous cette licence doit rester sous cette licence puisque cette derniere stipule que le code doit conserver les conditions de la licence ainsi que son texte.

                Si l'on y ajoute du code sous GPL, le travail combiné est sous GPL, mais le code source d'origine NCSA doit rester sous cette licence. Donc la distribution du logiciel sous forme binaire peut se faire sous GPL si la documentation associée au logiciel cite le copyright du code original sous licence NCSA.

                Dans ce cas, faire un logiciel propriétaire doit répondre aux mêmes exigences.

                Donc pour résumer, comme le dis PsychoFox, on peut bien faire un fork en GPL si le logiciel (travail combiné) contient du code source en GPL, le code source sous licence NCSA doit garder son copyright original (et la doc du logiciel doit citer ce copyright).
                • [^] # Re: Re:

                  Posté par  . Évalué à 2.

                  Oui, ca a toujours été comme ca pour toutes les licences de type BSD, c'est juste que beaucoup de gens ici font un raccourci un peu trop rapide en parlant de "changement" la licence : de toutes facons, tu ne peux pas dire a la place de l'auteur du code qui a sorti son soft sous BSD "Non, maintenant tu n'a plus le droit de faire ci ou ca" ; c'est son code !
                  Enfin, au final, comme le version de départ du fork GPL sera toujours dispo, et que les modifs sont apportées sous GPL, on peut dire que l'ensemble est GPL puisqu'on aura pas le droit de faire autre chose de la GPL si on dérive du code modifié. Et si on dérive du code original, il est toujours sous BSD, ce n'est pas parce que quelqu'un a fait un fork GPL que ca change quoi que ce soit au projet d'origine. Donc en partant de celui-ci, tu fais toujours "ce que tu veux" (i.e. on neglige souvent de parler de la citation requise par les BSD, mais c'est vu, je pense, comme un inconvéniant "mineur" quand on fait du proprio, par exemple).
                  • [^] # Re: Re:

                    Posté par  . Évalué à 2.

                    > de toutes facons, tu ne peux pas dire a la place de l'auteur du code qui a sorti son soft sous BSD "Non, maintenant tu n'a plus le droit de faire ci ou ca" ; c'est son code !

                    Oui j'ai bien conscience de ca. Ce que je disais plus haut etait simplement pour le cas suivant:
                    - le projet A est sous NCSA
                    - le projet B rajoute du code GPL au code BSD et distribue le tout sous GPL.
                    - les fichiers copié depuis le projet A dans le projet B doivent rester sous licence NCSA, même dans le SVN du projet B.

                    Bien évidemment, on est d'accord que les fichiers sous licence NCSA du projet A restent sous licence NCSA tant que le contributeur ne modifie pas cette licence. Mais même dans ce cas, a-t-il le droit de demander au projet B de modifier la licence du code copié? Je crois qu'en France, les droits moraux lui en donneraient le droit, mais quid des US?
    • [^] # Re: Re:

      Posté par  . Évalué à 7.

      Souvent les gens pensent que la BSD va amener des contributions des boites commerciales. Le choix de la BSD est souvent fait pour ça.

      Je pense que c'est plus souvent parce que le développeur accepte une utilisation et une distribution très libérale de son code. Et c'est tout.

      Mais en moyenne ce n'est pas ce qu'on voit. On voyait ça il y a de nombreuses années, ce n'est plus le cas aujourd'hui.

      D'ailleurs Yahoo!, Juniper, Cisco, NetASQ, NetApp, Isilon, Google ou IronPort (pour ne citer que celles que je connais pour utiliser FreeBSD et contribuer à divers niveaux au projet en retour) font semblant d'utiliser *BSD par bonté d'âme.

      Sincèrement je pense que globalement t'as une idée très réduite de l'état d'esprit des développeurs *BSD ainsi que des situations dans lesquels ils sont utilisés.
    • [^] # Re: Re:

      Posté par  . Évalué à 3.

      Il n'y a pas et n'aura pas de système de fichier proprio distribué avec Linux

      FS proprio pour linux:
      http://linuxdevices.com/news/NS3780930308.html

      Bien sur comme les drivers de CG, il ne sera pas distribué directement linké (car cela ne serait pas légal) mais quand même...

      Pour en revenir à GCC, dans le cadre d'un projet j'ai eu besoin de personnaliser le code généré par un complateur C-->x86, j'ai essayé avec GCC, mais le temps qu'il faut pour se retrouver dedans... du coup j'ai opté pour TCC (je n'avais pas connaissance de LLVM à l'époque).

      Une architecture plus modulaire aurait quand même été sympa.
      • [^] # Re: Re:

        Posté par  . Évalué à 0.

        > FS proprio pour linux:
        > http://linuxdevices.com/news/NS3780930308.html

        Où tu vois que c'est proprio ?
        Il ne l'ont pas diffusé (du moins j'ai vu). On en sait rien. T'as vu la licence ?

        > Bien sur comme les drivers de CG, il ne sera pas distribué directement linké (car cela ne serait pas légal) mais quand même...

        Où t'as vu ça ?
        ça dit :
        Datalight has ported its commercial flash filesystem to Linux.
        Ce n'est pas proprio. commercial != proprio.
        RHEL est une distribution commerciale, mais pas proprio. Tu fais la différence ?
        • [^] # Re: Re:

          Posté par  . Évalué à 1.

          Ce n'est pas proprio. commercial != proprio.
          Ô merci grand vizir de m'éclairer ainsi :-)

          Sinon, exact on n'en sait rien, mais bon, si tu avais un peu l'habitude de travailler avec linux dans l'embarqué, tu serais qu'il y a peu de chance.

          Tu veux parier ta couille gauche qu'il sera libre lorsqu'il sera diffusé ? X-D
          • [^] # Re: Re:

            Posté par  . Évalué à 2.

            Question: supposons que quelqu'un livre un logiciel proprio sous forme de code source qui doit s'interfacer avec un logiciel sous GPL (cas qui nous intéresse ici), mais sans le livrer avec le logiciel sous GPL, par exemple sous forme de patch.

            Lorsque le client combine le patch propriétaire avec le logiciel sous GPL l'ensemble devrait être couvert par la GPL, n'est ce pas? Dans quelle mesure le client pourrait (ou ne pourrait pas) demander a l'éditeur du patch propriétaire de lui fournir les sources?

            En écrivant ça, je me rend compte que ce cas couvre aussi bien ce filesystem proprio que les modules binaires de NVidia par exemple. La différence fondamentale étant que les modules du noyau sont considérés différemment par Linus Torlvalds que les filesystem qui font partie intégrante du noyau (sauf s'ils sont utilisés via FUSE, mais les perfs en prennent un coup je pense).

            Que savez vous a ce sujet?
            • [^] # Re: Re:

              Posté par  . Évalué à 4.

              Il faut bien faire attention que le respect de la GPL est liée à la distribution. Celui qui livre le patch propriétaire n'a rien distribué sous GPL, puisqu'il ne distribue que son patch. C'est le client qui prend la décision de linker le tout. Le binaire qu'il obtient au final n'est alors pas distribuable lui, puisque le client ne serait pas en mesure de fournir l'ensemble sous license GPL ou compatible.

              C'est exactement ce que fait NVIDIA, il te file un fichier objet, un fichier C qui interface le ficher objet avec le noyau, et c'est à toi de finir le travail de compilation/linkage. De cette manière, jamais NVIDIA ne distribue un module du noyau déjà tout pret, il distribue d'un coté un fichier C sous GPL, de l'autre un blob binaire sur lequel ils ont le copyright. Ce n'est bien sur absolument pas dans l'esprit de la GPL, mais c'est légal (je pense, je ne suis avocat).

              Que ca soit un module pour un FS ou un module pour une CG, ca ne change rien, linus ne considère pas différement les 2, un module linké dynamiquement avec le noyau, n'est pas légalement distribuable.
              • [^] # Re: Re:

                Posté par  . Évalué à 2.

                Petit oublie ^^

                Que ca soit un module pour un FS ou un module pour une CG, ca ne change rien, linus ne considère pas différement les 2, un module linké dynamiquement avec le noyau, n'est pas légalement distribuable.
                Si le module contient du code sous license incompatible avec la GPL bien sur.
                • [^] # Re: Re:

                  Posté par  . Évalué à 2.

                  Merci pour l'explication.

                  > Il distribue d'un coté un fichier C sous GPL, de l'autre un blob binaire.
                  J'ai téléchargé le fichier et je ne trouve aucune trace du fichier C en GPL. Je pense qu'il n'y en a en fait même pas besoin.

                  Par contre les distributions qui inclue le driver NVidia avec le noyau linux deviennent alors hors la loi, non?
                  J'ai regardé pour Ubuntu, et en fait, il semble que le driver est téléchargé a la demande, donc ils sont ok puisque encore une fois c'est l'utilisateur qui installe lui même le driver.

                  Bref, je comprends maintenant mieux l'opposition de RMS a la modularisation de GCC, même si je ne suis pas d'accord avec elle.
                  • [^] # Re: Re:

                    Posté par  . Évalué à 1.

                    J'ai téléchargé le fichier et je ne trouve aucune trace du fichier C en GPL. Je pense qu'il n'y en a en fait même pas besoin.
                    Si si je t'assure ^^ (il y en a même plusieurs), c'est juste que le fichier .run que tu télécharges sur le site de nvidia est une archive auto-extractible qui exécute ensuite automatiquement la compilation.

                    De toute facon, ils n'ont pas trop le choix, pour pouvoir charger un module dans le noyau, il faut qu'il ait été compilé avec les mêmes headers que ton noyau et le même compilateur (à une vache près), vu le nombre de distribs/versions du noyau/versions du compilateur, c'est plus simple de laisser l'utilisateur finir la compilation localement que de faire 72 paquets différents.

                    Et ils n'ont d'autant pas le choix que comme je l'ai dit précédemment, un module près à être chargé, donc complètement linké, ne pourrait être distribué légalement s'il n'est pas 100% compatible GPL. Aucune échappatoire à cela.

                    Par contre les distributions qui inclue le driver NVidia avec le noyau linux deviennent alors hors la loi, non?
                    Oui.

                    J'ai regardé pour Ubuntu, et en fait, il semble que le driver est téléchargé a la demande, donc ils sont ok puisque encore une fois c'est l'utilisateur qui installe lui même le driver
                    Encore une fois ce n'est pas une question de qui installe quoi volontairement, c'est une question de qui distribue quoi. Il n'est pas légal de distribuer un programme/module/... qui utiliserait à la fois du code GPL et du code incompatible GPL, même si la personne à qui cela ait distribué est d'accord. Je ne connait pas Ubuntu mais je parie que le module n'est pas tout pret à être chargé dans le noyau juste après le téléchargement et qu'au minimum il reste le phase de linkage à faire sur le pc de l'utilisateur.
                    • [^] # Re: Re:

                      Posté par  . Évalué à 2.

                      >> J'ai téléchargé le fichier et je ne trouve aucune trace du fichier C en GPL. Je pense qu'il n'y en a en fait même pas besoin.
                      > Si si je t'assure ^^ (il y en a même plusieurs), c'est juste que le fichier .run que tu télécharges sur le site de nvidia est une archive auto-extractible qui exécute ensuite automatiquement la compilation.


                      En fait, Je me suis mal exprimé. Quand je disais qu'il n'y en a pas besoin, je ne parlais pas du fichier C en lui même qui n'est qu'un adaptateur pour le blob binaire. Ce que je voulais dire c'est que ce fichier ne me semble même pas avoir besoin d'être sous GPL pour que le processus décrit marche sans enfreindre la GPL.

                      > Je ne connait pas Ubuntu mais je parie que le module n'est pas tout pret à être chargé dans le noyau juste après le téléchargement et qu'au minimum il reste le phase de linkage à faire sur le pc de l'utilisateur.

                      En regardant sur le wiki d'Ubuntu la procédure a suivre pour installer manuellement le driver proprio d'ATI, j'ai des doutes sur ce qu'ils font (a moins qu'apt-get soit capable de compiler du code): https://help.ubuntu.com/community/BinaryDriverHowto/ATI
                      C'est pas pour les dénoncer, mais plutôt pour comprendre comment ils contournent le problème.
                      • [^] # Re: Re:

                        Posté par  . Évalué à 1.

                        Pour la partie Xorg (DRI), étant sous licence X11 (~MIT), ya pas de problème.

                        C'est la partie Kernel (DRM) qui elle ne doit pas pouvoir être distribué déjà linkée.

                        Je me trompe p-e mais je vois pas comment on pourrait distribuer un module proprio pour linux tout pret à être chargé.

                        Encore une fois je ne connait pas ubuntu, mais apt doit bien etre capable d'exécuter des scripts de pre/post install ?
                        • [^] # Re: Re:

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


                          $ wget http://security.ubuntu.com/ubuntu/pool/restricted/l/linux-re(...)
                          --11:14:32-- http://security.ubuntu.com/ubuntu/pool/restricted/l/linux-re(...)
                          => `linux-restricted-modules-2.6.24-7-generic_2.6.24.8-7.19_i386.deb'Résolution de security.ubuntu.com... 91.189.88.37
                          Connexion vers security.ubuntu.com|91.189.88.37|:80... connecté.
                          requête HTTP transmise, en attente de la réponse... 200 OK
                          Longueur: 10 490 246 (10M) [application/x-debian-package]

                          100%[===================================>] 10 490 246 415.87K/s ETA 00:008

                          11:15:06 (366.55 KB/s) - « linux-restricted-modules-2.6.24-7-generic_2.6.24.8-7.19_i386.deb » sauvegardé [10490246/10490246]
                          $ dpkg-deb -x linux-restricted-modules-2.6.24-7-generic_2.6.24.8-7.19_i386.deb .
                          $ find lib/
                          lib/
                          lib/linux-restricted-modules
                          lib/linux-restricted-modules/2.6.24-7-generic
                          lib/linux-restricted-modules/2.6.24-7-generic/fglrx
                          lib/linux-restricted-modules/2.6.24-7-generic/fglrx/firegl_public.o
                          lib/linux-restricted-modules/2.6.24-7-generic/fglrx/libfglrx_ip.a.GCC4
                          lib/linux-restricted-modules/2.6.24-7-generic/fglrx/fglrx.mod.o
                          lib/linux-restricted-modules/2.6.24-7-generic/ath_hal
                          lib/linux-restricted-modules/2.6.24-7-generic/ath_hal/ah_os.o
                          lib/linux-restricted-modules/2.6.24-7-generic/ath_hal/i386-elf.hal.o
                          lib/linux-restricted-modules/2.6.24-7-generic/ath_hal/ath_hal.mod.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_legacy
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_legacy/nv-kernel.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_legacy/nv.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_legacy/nv-vm.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_legacy/os-agp.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_legacy/os-interface.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_legacy/os-registry.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_legacy/nvidia.mod.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia/nv-kernel.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia/nv.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia/nv-vm.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia/os-agp.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia/os-interface.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia/os-registry.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia/nv-i2c.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia/nvidia.mod.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/nv-kernel.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/nv.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/nv-vm.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/os-agp.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/os-interface.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/os-registry.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/nv-i2c.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/nvacpi.o
                          lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/nvidia.mod.o
                          lib/modules
                          lib/modules/2.6.24-7-generic
                          lib/modules/2.6.24-7-generic/madwifi
                          lib/modules/2.6.24-7-generic/madwifi/wlan.ko
                          lib/modules/2.6.24-7-generic/madwifi/wlan_acl.ko
                          lib/modules/2.6.24-7-generic/madwifi/wlan_ccmp.ko
                          lib/modules/2.6.24-7-generic/madwifi/wlan_scan_ap.ko
                          lib/modules/2.6.24-7-generic/madwifi/wlan_scan_sta.ko
                          lib/modules/2.6.24-7-generic/madwifi/wlan_tkip.ko
                          lib/modules/2.6.24-7-generic/madwifi/wlan_wep.ko
                          lib/modules/2.6.24-7-generic/madwifi/wlan_xauth.ko
                          lib/modules/2.6.24-7-generic/madwifi/ath_rate_onoe.ko
                          lib/modules/2.6.24-7-generic/madwifi/ath_rate_amrr.ko
                          lib/modules/2.6.24-7-generic/madwifi/ath_rate_sample.ko
                          lib/modules/2.6.24-7-generic/madwifi/ath_pci.ko
                          lib/firmware
                          lib/firmware/2.6.24-7-generic
                          lib/firmware/2.6.24-7-generic/acx
                          lib/firmware/2.6.24-7-generic/acx/1.0.9
                          lib/firmware/2.6.24-7-generic/acx/1.0.9/tiacx100usb
                          lib/firmware/2.6.24-7-generic/acx/default
                          lib/firmware/2.6.24-7-generic/acx/default/tiacx100r11
                          lib/firmware/2.6.24-7-generic/acx/default/tiacx100
                          lib/firmware/2.6.24-7-generic/acx/default/tiacx100r0D
                          lib/firmware/2.6.24-7-generic/acx/default/tiacx111c17
                          lib/firmware/2.6.24-7-generic/acx/default/tiacx100r15
                          lib/firmware/2.6.24-7-generic/acx/default/tiacx100usb
                          lib/firmware/2.6.24-7-generic/acx/default/tiacx111c19
                          lib/firmware/2.6.24-7-generic/acx/default/tiacx111c16
                          lib/firmware/2.6.24-7-generic/acx/1.9.8.b
                          lib/firmware/2.6.24-7-generic/acx/1.9.8.b/tiacx100r15
                          lib/firmware/2.6.24-7-generic/acx/1.9.8.b/tiacx100r0D
                          lib/firmware/2.6.24-7-generic/acx/1.9.8.b/tiacx100
                          lib/firmware/2.6.24-7-generic/acx/1.9.8.b/tiacx100r11
                          lib/firmware/2.6.24-7-generic/acx/1.2.0.30
                          lib/firmware/2.6.24-7-generic/acx/1.2.0.30/tiacx111
                          lib/firmware/2.6.24-7-generic/acx/1.2.0.30/tiacx111r17
                          lib/firmware/2.6.24-7-generic/acx/1.2.0.30/tiacx111c16
                          lib/firmware/2.6.24-7-generic/acx/1.2.0.30/tiacx111r16
                          lib/firmware/2.6.24-7-generic/acx/1.2.0.30/tiacx111c17
                          lib/firmware/2.6.24-7-generic/acx/1.0.7
                          lib/firmware/2.6.24-7-generic/acx/1.0.7/tiacx100usb
                          lib/firmware/2.6.24-7-generic/acx/0.4.11.4
                          lib/firmware/2.6.24-7-generic/acx/0.4.11.4/tiacx111c16
                          lib/firmware/2.6.24-7-generic/acx/1.2.1.34
                          lib/firmware/2.6.24-7-generic/acx/1.2.1.34/tiacx111
                          lib/firmware/2.6.24-7-generic/acx/1.2.1.34/tiacx111r17
                          lib/firmware/2.6.24-7-generic/acx/1.2.1.34/tiacx111c16
                          lib/firmware/2.6.24-7-generic/acx/1.2.1.34/tiacx111r16
                          lib/firmware/2.6.24-7-generic/acx/1.2.1.34/tiacx111c17
                          lib/firmware/2.6.24-7-generic/acx/1.7.0
                          lib/firmware/2.6.24-7-generic/acx/1.7.0/tiacx100r0D
                          lib/firmware/2.6.24-7-generic/acx/1.7.0/tiacx100
                          lib/firmware/2.6.24-7-generic/acx/1.7.0/tiacx100r11
                          lib/firmware/2.6.24-7-generic/acx/readme.txt
                          lib/firmware/2.6.24-7-generic/acx/0.1.0.11
                          lib/firmware/2.6.24-7-generic/acx/0.1.0.11/tiacx111c16
                          lib/firmware/2.6.24-7-generic/acx/2.3.1.31
                          lib/firmware/2.6.24-7-generic/acx/2.3.1.31/tiacx111c16
                          lib/firmware/2.6.24-7-generic/acx/2.3.1.31/tiacx111c19
                          lib/firmware/2.6.24-7-generic/acx/2.3.1.31/tiacx111c17
                          lib/firmware/2.6.24-7-generic/acx/0.4.11.9
                          lib/firmware/2.6.24-7-generic/acx/0.4.11.9/tiacx111
                          lib/firmware/2.6.24-7-generic/acx/0.4.11.9/tiacx111c16
                          lib/firmware/2.6.24-7-generic/acx/0.4.11.9/tiacx111r16
                          lib/firmware/2.6.24-7-generic/dvb-fe-or51132-qam.fw
                          lib/firmware/2.6.24-7-generic/dvb-fe-or51132-vsb.fw
                          lib/firmware/2.6.24-7-generic/dvb-fe-or51211.fw
                          lib/firmware/2.6.24-7-generic/dvb-ttpci-01.fw
                          lib/firmware/2.6.24-7-generic/dvb-usb-avertv-a800-02.fw
                          lib/firmware/2.6.24-7-generic/dvb-usb-dib0700-1.10.fw
                          lib/firmware/2.6.24-7-generic/dvb-usb-dibusb-5.0.0.11.fw
                          lib/firmware/2.6.24-7-generic/dvb-usb-dibusb-6.0.0.8.fw
                          lib/firmware/2.6.24-7-generic/dvb-usb-dtt200u-01.fw
                          lib/firmware/2.6.24-7-generic/dvb-usb-umt-010-02.fw
                          lib/firmware/2.6.24-7-generic/dvb-usb-vp702x-01.fw
                          lib/firmware/2.6.24-7-generic/dvb-usb-vp7045-01.fw
                          lib/firmware/2.6.24-7-generic/dvb-usb-wt220u-02.fw
                          lib/firmware/2.6.24-7-generic/dvb-usb-wt220u-fc03.fw
                          lib/firmware/2.6.24-7-generic/dvb-usb-wt220u-zl0353-01.fw
                          $ dpkg-deb -e linux-restricted-modules-2.6.24-7-generic_2.6.24.8-7.19_i386.deb .
                          $ cat postinst
                          #!/bin/sh

                          case "$1" in
                          configure)
                          lrm-manager --kver=2.6.24-7-generic
                          ;;
                          esac
                          $ head /sbin/lrm-manager
                          #!/bin/sh

                          # Note that this script is not only /sbin/lrm-manager, but it also
                          # ends up being the postinst for nic-restricted-modules. Take care
                          # when adding features to make sure they'll work in d-i's busybox

                          # If you wish to disable the link-on-boot feature for certain modules,
                          # please see /etc/default/linux-restricted-modules-common for details.

                          set -e

                          Le .deb contient les .o que lrm-manager link au moment du postinst.
                          Les .ko sont les modules madwifi GPL, seul ath_hal est proprio.
                          • [^] # Re: Re:

                            Posté par  . Évalué à 2.

                            Merci pour tes réponses Sigmatador et merci pour la démonstration inico.
  • # Question bête...

    Posté par  . Évalué à 3.

    Bon, je ne comprends pas grand chose aux compilateurs, je sais juste que j'ai un code source au début et du binaire à la fin, les étapes intermédiaires, j'en ai qu'une très vague idée. (ceci est un avertissement).

    Mais si GCC est si "tellement trop monolithique", et si Clang+LLVM, c'est ça la modularité et qu'on peut mettre plein de trucs comme on veut, comment donc font-ils pour utiliser un LLVM+GCC (ce dernier étant ultra monolithique et tout et tout, là il est bien utilisé en partie, non?)
    • [^] # Re: Question bête...

      Posté par  . Évalué à 2.

      llvm-gcc est fait contre le gré de la FSF (et stallman), un peu de la même façon que pour le backend qui fait du bytecode .NET, ils ont du vraiment se battre pour convaincre RMS que ca ne permettrait pas de plugguer gcc avec un backend proprio.
    • [^] # Re: Question bête...

      Posté par  . Évalué à 3.

      LLVM + gcc doit etre compris comme LLVM + des front ends GCC. Ils ne gardent que ce qu'ils n'ont pas développé: les front ends.

      Ce n'est pas parce que c'est difficilement réutilisable que tu ne peux pas le réutiliser. Simplement ca demande beaucoup plus de travail.

      LLVM a existé bien avant que clang n'existe, donc pour pouvoir réellement tester et utiliser LLVM ainsi que le pousser dans ses retranchements, il fallait trouver des front ends qui servent d'interface entre le code source et la représentation intermédiaire de LLVM. Or GCC offre plusieurs front ends vraiment tres matures permettant ainsi d'utiliser LLVM avec des langages courant tels que C, C++ (celui-ci est un des front ends les plus durs a realiser), Fortran, Ada, Objective-C et meme maintenant Java.
  • # Virtual Machine

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

    Je m'intéresse depuis un certain temps à LLVM notamment car il semble fournir une machine virtuelle. Mon but est de pouvoir avoir un environnement d'exécution restreint.

    En gros, j'aimerais controller tous les appels a des bibliothèques extérieures ... Savez vous si (et comment) c'est possible ? J'ai longtemps cherché sur le site mais n'ai pas encore trouvé grand chose.
    • [^] # Re: Virtual Machine

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

      Si le but est d'isoler l'application testée du reste du "monde", c'est ce qu'on appelle le sandboxing. Ça sert à observer des animaux en cage (ex: virus). Quelques exemples Plash, Subterfuge (projet mort), SELinux, AppArmor, jail BSD, zone Solaris, Qemu, Xen, ... Site web de Plash :
      http://plash.beasts.org/wiki/
    • [^] # Re: Virtual Machine

      Posté par  . Évalué à 1.

      Une machine virtuelle? Tu ne ferais pas une confusion avec le compilateur JIT? Tu peux avoir un compilateur JIT sans avoir de machine virtuelle. Il y a un exemple dans le tutoriel sur comment utiliser LLVM en tant que compilateur JIT.

      Je ne suis pas sur de quel niveau de contrôle tu disposes sur le code source de l'application a surveiller. C'est un binaire ou tu disposes du code source?

      Ce que t'as dit Victor STINNER me semble tout a fait valide si tu ne disposes pas du code source.

      Cependant si tu en disposes, tu peux regarder du coté de Valgrind qui exécute un bytecode représentant ton programme en contrôlant beaucoup de choses. Peut être que ça peut marcher.

      Ensuite je ne sais pas exactement quel est ton but pur contrôler les appels aux bibliothèques externes, mais autrement WINE a du faire beaucoup de travail dans ce domaine pour trouver les fonctions appelées par les binaires Win32 pour pouvoir ensuite les réimplémenter dans leur code source pour Linux / Unix.

      J'espère que ça t'aide.

Suivre le flux des commentaires

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