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
- Les nouveautés de LLVM 2.2 (18 clics)
- Tutoriels pour LLVM (65 clics)
- Clang (23 clics)
# llvm-gcc
Posté par loufoque . Évalué à 2.
[^] # Re: llvm-gcc
Posté par Mildred (site web personnel) . Évalué à 1.
Et vu que LLVM est écrit en C++
# Les mauvaises décisions
Posté par Anonyme . Évalué à 9.
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 benoar . Évalué à 8.
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 Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: Les mauvaises décisions
Posté par David . Évalué à 9.
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 Troy McClure (site web personnel) . Évalué à 3.
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 IsNotGood . Évalué à -1.
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.
[^] # Re: Les mauvaises décisions
Posté par Troy McClure (site web personnel) . Évalué à 7.
> Il faudra te trouver une autre tête de turc.
Pourquoi tete de turc ? est-ce que je l'ai insulté , est-ce que j'ai insinué que sa décision était mauvaise ? arrete tes procès d'intention stp.
bon voilà je me suis fait chier a aller deterrer ce mail où il explique sa position:
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01040.html
[^] # Re: Les mauvaises décisions
Posté par darkleon (site web personnel) . Évalué à 2.
bon voilà je me suis fait chier a aller deterrer ce mail où il explique sa position:http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01040.html
çà n'a rien à voir, dans le post en question, ils parlent de faire des alias de noms de domaines par rapport au projets GNU, pas de modulariser ou de garder un GCC monolithique
0_o
[^] # Re: Les mauvaises décisions
Posté par Troy McClure (site web personnel) . Évalué à 4.
c'était http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html
[^] # Re: Les mauvaises décisions
Posté par benoar . Évalué à 2.
Si les commentaires se sont un peu envenimés, je pense que c'était par le lancé de troll sans justification de la part de patrick_g, et ton ton péremptoir sur la "stricte vérité" en parlant d'un email qui ne prouvait pas grand chose, ne venant pas de l'intéressé.
[^] # La liberté ce n'est pas technique
Posté par ZeroHeure (site web personnel) . Évalué à 10.
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 Gniarf . Évalué à 2.
(d'aucuns jugent que Sun fait pareil avec OpenOffice et Java...)
[^] # Re: La liberté ce n'est pas technique
Posté par Thomas Douillard . Évalué à 2.
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 inico (site web personnel) . Évalué à 10.
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 Damien (site web personnel) . Évalué à 2.
[^] # Re: Les mauvaises décisions
Posté par Putifuto . Évalué à 8.
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 GPL . Évalué à 3.
[^] # Re: Les mauvaises décisions
Posté par abramov_MS . Évalué à 7.
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 GPL . Évalué à 7.
[^] # Re: Les mauvaises décisions
Posté par Space_e_man (site web personnel) . Évalué à 3.
[^] # Re: Les mauvaises décisions
Posté par Jul (site web personnel) . Évalué à 1.
[^] # Re: Les mauvaises décisions
Posté par IsNotGood . Évalué à 10.
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 Jul (site web personnel) . Évalué à 9.
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 IsNotGood . Évalué à 4.
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 Psychofox (Mastodon) . Évalué à 3.
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 alice . Évalué à 4.
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 Jul (site web personnel) . Évalué à 5.
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 briaeros007 . Évalué à 4.
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 alice . Évalué à 6.
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 djano . Évalué à 4.
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 Mildred (site web personnel) . Évalué à 1.
Après, le mieux c'est que ce soit standardisé par XMPP
[^] # Re: Les mauvaises décisions
Posté par djano . Évalué à 2.
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 CrEv (site web personnel) . Évalué à 3.
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 djano . Évalué à 2.
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 alice . Évalué à 2.
[^] # Re: Les mauvaises décisions
Posté par abramov_MS . Évalué à 1.
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 lfmarante . Évalué à -1.
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 Boa Treize (site web personnel) . Évalué à 1.
[^] # Re: Les mauvaises décisions
Posté par kowalsky . Évalué à 3.
Mais chez les GNUs aussi, des fois les gens sont triste.
C'est la vie :)
[^] # Re: Les mauvaises décisions
Posté par timid . Évalué à 4.
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 djano . Évalué à 1.
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 lfmarante . Évalué à 3.
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 Zenitram (site web personnel) . Évalué à 2.
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 lfmarante . Évalué à 0.
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 Zenitram (site web personnel) . Évalué à 6.
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 gpe . Évalué à -2.
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 chl (site web personnel) . Évalué à 2.
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 gpe . Évalué à 1.
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 lfmarante . Évalué à -2.
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 Zenitram (site web personnel) . Évalué à 2.
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 IsNotGood . Évalué à 2.
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 Moonz . Évalué à 10.
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 briaeros007 . Évalué à 2.
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 Moonz . Évalué à 5.
> 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 briaeros007 . Évalué à 2.
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 Moonz . Évalué à 4.
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 briaeros007 . Évalué à 0.
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 zul (site web personnel) . Évalué à 2.
[^] # Re: Les mauvaises décisions
Posté par briaeros007 . Évalué à 1.
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 nullisimo . Évalué à 2.
Source:
http://blogs.sun.com/dillon/entry/open_java#comment-11642487(...)
[^] # Re: Les mauvaises décisions
Posté par zul (site web personnel) . Évalué à 2.
[^] # Re: Les mauvaises décisions
Posté par Psychofox (Mastodon) . Évalué à 1.
Donc le passage à la gpl n'apporterait rien ;-)
[^] # Re: Les mauvaises décisions
Posté par briaeros007 . Évalué à -1.
[^] # Re: Les mauvaises décisions
Posté par Moonz . Évalué à 3.
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 briaeros007 . Évalué à 0.
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 lasher . Évalué à 3.
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 Moonz . Évalué à 2.
> 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 briaeros007 . Évalué à 1.
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 ErrTu . Évalué à 2.
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 briaeros007 . Évalué à -1.
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 TeXitoi (site web personnel) . Évalué à 0.
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 IsNotGood . Évalué à 2.
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 Jul (site web personnel) . Évalué à 3.
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 Zenitram (site web personnel) . Évalué à 1.
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 rewind (Mastodon) . Évalué à 5.
[^] # Re: Les mauvaises décisions
Posté par Jul (site web personnel) . Évalué à 1.
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 Moonz . Évalué à 3.
[^] # Re: Les mauvaises décisions
Posté par zul (site web personnel) . Évalué à 7.
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 IsNotGood . Évalué à -2.
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 Psychofox (Mastodon) . Évalué à 9.
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 IsNotGood . Évalué à 0.
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 Putifuto . Évalué à 5.
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 Zenitram (site web personnel) . Évalué à 1.
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 Thomas Maurin (site web personnel) . Évalué à 0.
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 zul (site web personnel) . Évalué à 1.
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 IsNotGood . Évalué à -1.
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 Zenitram (site web personnel) . Évalué à 1.
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 zul (site web personnel) . Évalué à 6.
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 lfmarante . Évalué à -9.
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 karteum59 . Évalué à 4.
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 TeXitoi (site web personnel) . Évalué à 2.
[^] # Re: Les mauvaises décisions
Posté par suJeSelS . Évalué à 6.
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 loufoque . Évalué à 4.
[^] # Re: Les mauvaises décisions
Posté par IsNotGood . Évalué à -1.
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 djano . Évalué à 9.
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 Mildred (site web personnel) . Évalué à 2.
[^] # Re: Les mauvaises décisions
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 10.
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 IsNotGood . Évalué à -1.
OK, j'ai été un peu brutal.
M'enfin, regarde les commentaires des BSDistes sur la GPL...
[^] # Re: Les mauvaises décisions
Posté par Psychofox (Mastodon) . Évalué à 6.
[^] # Re: Les mauvaises décisions
Posté par Gohar . Évalué à 5.
[^] # Re: Les mauvaises décisions
Posté par psychoslave__ (site web personnel) . Évalué à 3.
[^] # Re: Les mauvaises décisions
Posté par Philippe F (site web personnel) . Évalué à 6.
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 alice . Évalué à -6.
[^] # Re: Les mauvaises décisions
Posté par ZeroHeure (site web personnel) . Évalué à 4.
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 abramov_MS . Évalué à 2.
[^] # Re: Les mauvaises décisions
Posté par djano . Évalué à 3.
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 abramov_MS . Évalué à 1.
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 Nicolas Boulay (site web personnel) . Évalué à 6.
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 gallenza . Évalué à 1.
>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 patrick_g (site web personnel) . Évalué à 7.
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 el_mickey . Évalué à 2.
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 Boa Treize (site web personnel) . Évalué à 4.
[^] # Re: Performances ?
Posté par M . Évalué à 2.
[^] # Re: Performances ?
Posté par Victor STINNER (site web personnel) . Évalué à 7.
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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Performances ?
Posté par Victor STINNER (site web personnel) . Évalué à 6.
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 M . Évalué à 3.
Et je pari que comme par hasard, le code est friand d'optimisation JIT...
[^] # Re: Performances ?
Posté par Victor STINNER (site web personnel) . Évalué à 3.
[^] # Re: Performances ?
Posté par reno . Évalué à 2.
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 briaeros007 . Évalué à 1.
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 fmaz fmaz . Évalué à 1.
[^] # Re: Performances ?
Posté par gpe . Évalué à 2.
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 Philippe F (site web personnel) . Évalué à 2.
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 gpe . Évalué à 3.
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 windu.2b . Évalué à 1.
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 gpe . Évalué à 1.
[^] # Re: Performances ?
Posté par briaeros007 . Évalué à 1.
[^] # Re: Performances ?
Posté par gpe . Évalué à 2.
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 lasher . Évalué à 2.
[^] # Re: Performances ?
Posté par M . Évalué à 3.
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 Francois Revol (site web personnel) . Évalué à 4.
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 M . Évalué à 6.
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 Ontologia (site web personnel) . Évalué à 4.
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 ribwund . Évalué à 3.
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 M . Évalué à 2.
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 djano . Évalué à 1.
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 djano . Évalué à 2.
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 M . Évalué à 2.
llvm-gcc 4.2 ...
Oui mais à terme ils comptent abandonner gcc ? Non ?
[^] # Re: questions
Posté par djano . Évalué à 1.
J'aurais peut être du écrire: "pour le moment il n'y a pas encore d'équivalent".
# Re:
Posté par IsNotGood . Évalué à 3.
> 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 Troy McClure (site web personnel) . Évalué à 9.
Et alors qu'est ce qui t'empeche de faire un fork de llvm en gpl ? (à part la mauvaise foi)
[^] # Re: Re:
Posté par abramov_MS . Évalué à -1.
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 Troy McClure (site web personnel) . Évalué à 7.
[^] # Re: Re:
Posté par IsNotGood . Évalué à -1.
Tu n'as pas le droit.
Soit t'es de mauvais foi, soit t'y connais rien en licence.
[^] # Re: Re:
Posté par Troy McClure (site web personnel) . Évalué à 3.
[^] # Re: Re:
Posté par Olivier Abad . Évalué à -1.
[^] # Re: Re:
Posté par Psychofox (Mastodon) . Évalué à 4.
[^] # Re: Re:
Posté par Olivier Abad . Évalué à 1.
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 TeXitoi (site web personnel) . Évalué à 6.
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 djano . Évalué à 2.
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 benoar . Évalué à 2.
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 djano . Évalué à 2.
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 vjm . Évalué à 7.
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 Anonyme . Évalué à 3.
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 IsNotGood . Évalué à 0.
> 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 Anonyme . Évalué à 1.
Ô 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 djano . Évalué à 2.
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 Anonyme . Évalué à 4.
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 Anonyme . Évalué à 2.
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 djano . Évalué à 2.
> 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 Anonyme . Évalué à 1.
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 djano . Évalué à 2.
> 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 Anonyme . Évalué à 1.
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 inico (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 djano . Évalué à 2.
# Question bête...
Posté par Maclag . Évalué à 3.
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 ribwund . Évalué à 2.
[^] # Re: Question bête...
Posté par djano . Évalué à 3.
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 Mildred (site web personnel) . Évalué à 3.
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 Victor STINNER (site web personnel) . Évalué à 4.
http://plash.beasts.org/wiki/
[^] # Re: Virtual Machine
Posté par djano . Évalué à 1.
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.