Microsoft a annoncé la libération des sources de sa bibliothèque standard C++. Le tout est disponible sur github sous une licence Apache avec exception LLVM, soit la même licence que celle de libc++ (la bibliothèque standard du projet LLVM). Pour ceux qui se poseraient la question, l'exception dit juste qu'on n'est pas obligé de citer Microsoft si on lie la bibliothèque standard, statiquement ou dynamiquement.
Microsoft continue donc d'ouvrir ses sources. Ça reste des trucs pas vraiment dans leur cœur de métier (ni Windows ni MS Office) mais on va quand même apprécier le geste.
# README.md
Posté par barmic 🦦 . Évalué à 4.
D'après leur README, ce n'est pas juste une libération en mode « voila le code », mais il semble y avoir une volonté d'accepter les contributions extérieures, les rapports de bug, etc.
De plus cette libération du code n'est pas complète d'après le README. Ils travaillent encore sur le build et les tests.
Par contre, ils expliquent clairement ne pas vouloir porter leur STL sur d'autres plateforme.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Ça attaque sec
Posté par Zenitram (site web personnel) . Évalué à 9.
Et ils disent qu'ils discutent avec LLVM, pour des travaux communs… Donc en gros Windows et Mac à 99% (reste MinGW/Cygwin) + de plus en plus d'essais de compiler une distro Linux entière avec LLVM. ça ressemble pas mal à une attaque groupée pour reléguer la lib de GCC (sous licence copyleft) dans la case "ne va pas suivre technologiquement"… Pour le moment à ma connaissance GCC suit pas mal (surtout depuis que LLVM a botté les fesses et motivé GCC à virer les limites techniques arbitraires de RMS), mais demain avec autant de ressource sur le "concurrent"?
[^] # Re: Ça attaque sec
Posté par Renault (site web personnel) . Évalué à 10.
En tout cas pour les distributions Linux, la motivation n'est pas tellement de se débarrasser de GCC et des licences associées.
L'objectif d'avoir une compatibilité LLVM est multiple. Tout d'abord cela offre accès à d'autres outils de profilage, de décompilation, ou d'analyses qui sont utiles et performants.
Plus un programme peut être compilé par plusieurs compilateurs, plus son comportement est fiable car il repose en théorie sur moins de comportements spécifiques de l'un d'entre eux. Donc plus portable et plus propre.
Investir dans LLVM c'est se protéger pour l'avenir. Si GCC stagne, l'écosystème pourra toujours se rabattre sur LLVM qui serait à la hauteur. Ne parier que sur GCC est un pari risqué pour l'avenir car tout est possible.
Cela permet aussi de stimuler la concurrence entre les deux, aujourd'hui et tu l'as mentionné, GCC a beaucoup œuvré pour rattraper son retard et c'est très bien. GCC est aussi assez complet et a quelques atouts dans son sac autour de son écosystème et ses options. Même si LLVM se rapproche aussi de GCC sur ce point.
C'est selon moi une saine concurrence. Après il est vrai que si Microsoft (et d'autres acteurs) poussent LLVM plus loin, GCC pourrait se retrouver distancé à terme mais pour l'instant ce n'est pas le cas et cela ne semble pas se profiler dans un futur proche encore.
Après le noyau Linux lui même n'est toujours pas prêt à compiler exclusivement avec LLVM / CLang et je crois que les dernières étapes manquantes doivent être comblées par le compilateur et non le noyau qui ne veut pas se passer spécialement de certains comportements qui sont pour l'instant centrés sur celui de GCC.
[^] # Re: Ça attaque sec
Posté par Benjamin Henrion (site web personnel) . Évalué à 8.
"LLVM c'est se protéger pour l'avenir"
Ca permettra juste aux fabricants de puces de modifier les compilos et de ne pas devoir donner les sources.
Sans la GPL, c'est "make proprietary software great again".
[^] # Re: Ça attaque sec
Posté par Zenitram (site web personnel) . Évalué à -4. Dernière modification le 18 septembre 2019 à 11:04.
C'est vrai, Apache server, PHP… C'est la porte ouverte au proprio.
Ce qui est libre reste libre, rien ne t'est enlevé en liberté, mais bon je sais difficile de laisser des libertés aux autres… Du même acabit que "le libre ça permet à mes concurrents de reprendre mon code, horreur".
Sérieux, c'est vraiment le genre de commentaire qui incite à s'éloigner de la GPL, à la vue de l'extrémisme quasi religieux de ses défenseurs contre ce qui ne plaît pas…
[^] # Re: Ça attaque sec
Posté par Firwen (site web personnel) . Évalué à 10.
Il a raison et ça n'a rien d'extrèmisme.
Une bonne partie des grandes compagnies, spécialement dans le hardware, ne publient en OSS que parce qu'elles y sont forcées, pas par plaisir.
NVidia, Qualcomm, Broadcom entre autres.
Et il y a des raisons à ça, car d'un point de vue managériale, défendre sa propriété intellectuelle est plus important que la substituabilité d'un écosystème et d'une plateforme.
Le résultat, c'est des compilateurs propriétaire, périmés, buggé, et plus supportés depuis 10 ans car pas rentable… Et des drivers binaires inutilisables, impossible à faire évolués qui te lock sur des versions préhistoriques.
Ça n'a rien de "théorique", je peux te donner une bonne dizaine d'example… Et la gueule / le status des drivers des BSD comparé à Linux parle de lui même sur le sujet.
[^] # Re: Ça attaque sec
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à -1.
Bah bien sûr une entreprise qui vend des processeurs elle a tout intérêt à te filer un compilateur qui marche pas avec, comme ça tu ne peux pas utiliser leur matériel correctement et tu finis par acheter celui du concurrent. C'est pas du tout suicidaire comme approche.
S'ils avaient eu envie de faire ça, ils auraient juste pas du tout utilisé GCC et développé leur machin en interne. Et du coup, entre un machin développé en interne qui marche à moitié et un truc basé sur LLVM qui fonctionne bien, en effet y'a des chances qu'ils prennent LLVM.
Mais ceux qui avaient choisi GCC et de jouer le jeu du logiciel libre, ils y voient peut être un intérêt supplémentaire (au hasard, que la communauté fasse "gratuitement" une partie du travail pour eux)? Et du coup, ils vont peut être bien continuer dans la même voie?
Faut arrêter de croire que toutes les entreprises sont forcément des gros méchants qui ne veulent que du code propriétaire et fermé.
[^] # Re: Ça attaque sec
Posté par Firwen (site web personnel) . Évalué à 10. Dernière modification le 18 septembre 2019 à 13:20.
C'est pourtant ce qu'a fait IBM avec le marché du HPC et XLC pendant pratiquement 10 ans avec un compilo complétement aux fraises.
Il y a la théorie et il y a la pratique.
La pratique c'est que celui qui achète du hardware, c'est rarement celui qui code sur la platforme. Et le nombre de bugs associé au compilateur pourri, proprio, que tu ne pourras jamais toucher car non Open Source, il n'est pas marqué sur le power point du type qui te vend le hardware.
Par le passé, beaucoup de vendeurs se sont pliés à fournir un backend GCC pour leur platforme car:
1- C'était ce que les clients voulaient.
2- Créer son propre compilateur C/C++/Fortran from scratch était beaucoup trop cher.
Maintenant, ils pourront éviter ça en forkant leur propre bouse à partir de LLVM et re-brander ça comme un "compilateur" maison.
Oh surprise, c'est déja ce qui se fait avec :
Le compilateur "ARM", car c'est connu un compilo platforme specifique c'est toujours mieux.
XLC, qui aprés avoir faillit mourrir pour le bien commun, malheureusement est réssussité derrière LLVM.
Nvidia, qui n'attend qu'une chose c'est de dropper le frontend GCC à CUDA pour fournir son propre tool proprio "key in hand" avec toutes les merdes en terme de compatibilités qui vont avec.
Apple qui vampirise déja clang et LLVM pour son compilo maison, propriétaire et qui respecte à moitiés les standards.
Sony, pour son compiler Playstation.
Et un peu prés tous les fournisseurs de platformes embarquées chinoises qui fournissent leur propre compilo.
Le vieux dogme BSD "vous verrez, ils reviendront au libre quand ils verront que c'est mieux pour eux" ne marchent pas et n'a jamais marché et ne marchera jamais.
Car ce n'est pas comme ça que le monde du business marche.
Car les gens qui prennent les décisions de sous quelle licence sera ton soft ne comprennent rien au logiciel libre et ça ne les intéresse absolument pas d'ailleurs.
LLVM est une toolchain géniale. Mais la license ultra-permissive made-in-apple de LLVM a juste ouvert la porte a une génération entière de compilo dégeulasse qui resteront imbuvables et buggés alors que ces même compilateurs étaient sur la voie de l'exctinction, pour le bien commun.
[^] # Re: Ça attaque sec
Posté par freem . Évalué à 10.
Moi, j'ai constaté que, depuis que LLVM a pris en popularité, pour des raisons techniques (je l'ai adopté initialement parce que son usage de RAM/process était divisé par 2 comparé à GCC, ce qui m'a permis de coder dans le train en utilisant 5 process au lieu de 2 sur un netbook ayant 1Gio de RAM, sans parler des erreur de templates qui n'étaient déchiffrable qu'avec Clang. Oui, c'était avant C++11), gcc s'est méchamment amélioré, même si je ne considère toujours pas qu'il soit égal. Du coup, je compile en debug avec clang, et en release (because la cible est Debian, et autant éviter les emmerdes d'ABI) avec gcc.
Du coup, j'ai les 2 familles de warn/errors, et j'adore ça, je suis obligé de coder plus proprement, d'avoir un code plus explicite sur son intention (j'active tous les warn, sauf certains que je désactive intentionnellement si je pense comprendre leur raison).
Mais peut-être que, justement, GCC était l'un de ces «compilo dégeulasse»?
[^] # Re: Ça attaque sec
Posté par Firwen (site web personnel) . Évalué à 2.
Non seulement c'est du troll, mais c'est irrelevant.
Je n'ai jamais critiqué les qualités techniques de LLVM/Clang qui est un excellent projet / compilateur.
Ce que je critique c'est la license du projet qui a permis de créé toute une génération de compilateurs proprio effectivement dégeulasses, mal supportés et intouchables. Tu l'as trés bien compris je pense d'ailleurs.
Ton commentaire sur GCC n'a aucun intérêt car GCC, comme Clang, comme tout compilateur Open Source n'a pas ce problème car il est Open Source, donc modifiable, donc évoluable.
[^] # Re: Ça attaque sec
Posté par lasher . Évalué à 5.
Il va falloir encore que je me répète. Soupir.
LLVM est issue de la recherche US. La « licence ultra-permissive » de LLVM (récemment changée en licence Apache 2.0, soit dit en passant, à cause d'abus sur les brevets logiciels), elle vient de la communauté scientifique qui a fait naître le projet. Le projet vit très bien, malgré ses financeurs tant privés (Apple, Nvidia, etc.), que publics.
Soit dit en passant, Nvidia, via la compagnie PGI, propose un compilateur C/C++/Fortran avec OpenMP et OpenACC… basé sur LLVM. Donc s'ils cherchent encore à se débarrasser de GCC pour Cuda, je suis étonné qu'ils ne l'aient pas fait depuis, car ils ont clairement les compétences pour découpler tout ça (surtout que Clang/LLVM prend officiellement compte de propriétés GPU depuis quelques temps).
Les gens qui utilisent une licence BSD ne pensent pas de cette manière à ma connaissance. C'est plutôt : « On fait du soft de pointe, on est bon, si tu veux rendre le soft proprio, pas de souci, mais comme on le fait évoluer vite, si tu nous livres pas tes modifs, ce sera à ta charge de porter toutes tes modifications spécifiques sur les nouvelles versions, y compris quand on aura décidé de casser des bouts d'API. »
Lorsque je regarde les 4 plus gros contributeurs de Clang entre 2007 et 2019, on a 2 dév de chez Apple, Chris Lattner (papa de LLVM, ex-Apple, maintenant chez Google), et un Richard Smith, un dév faisant partie du comité de normalisation de C++ (et "owner" de Clang++). En zoomant sur 2018-2019, Richard Smith passe nº1, un autre dév Apple est nº2, etc. Si je mate les dévs de LLVM depuis ~2018, le numéro un vient de chez Sony, les deux suivants on ne sait pas, le 4è vient de chez AMD, et le 5è vient de chez Google. Donc on a bien un minimum de mutualisation du développement par des gens payés pour le faire.
Donc, que des éditeurs de logiciels sortent des compilos « horribles » propriétaires basés sur LLVM : grand bien leur fasse. Le projet LLVM lui-même continue d'avancer, et de proposer plein de trucs chouettes.
[^] # Re: Ça attaque sec
Posté par Firwen (site web personnel) . Évalué à 8. Dernière modification le 18 septembre 2019 à 12:35.
Ça se fait déja.
Les dernières versions du compilateur XLC d'IBM sont basées sur LLVM. Et tu pourras toujours te brosser pour avoir les modifications apportées Martine.
[^] # Re: Ça attaque sec
Posté par David Marec (site web personnel) . Évalué à 3.
Ah bon. J'ai toujours cru qu'il n'utilisait que CLang, c'est à dire uniquement le language front-end.
S'il ne s'agit bien que du front-end, l’intérêt d'avoir les modification est réduit.
[^] # Re: Ça attaque sec
Posté par Renault (site web personnel) . Évalué à 6.
Bah tiens, voilà que cela devrait être possible, du moins pour l'architecture x86_64. Mais il reste d'autres architectures et projets bas niveaux où le support est manquant encore.
[^] # Re: Ça attaque sec
Posté par David Demelier (site web personnel) . Évalué à 6. Dernière modification le 18 septembre 2019 à 10:49.
C'est ce que je suis entrain de faire. Dans l'ensemble ça fonctionne plutôt bien avec 2/3 patchs par ci par là.
Le plus gros problème sont les projets surtout initiés par RedHat qui contiennent pas mal d'extensions et pas toujours compatible. À ce jour, grub, elfutils et le noyau Linux nécessitent encore gcc.
En grande partie, le système peut tourner sans GCC (ni libgcc/gcc_s).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Ça attaque sec
Posté par windu.2b . Évalué à 3.
(question de newbie)
C'étaient quoi, les limites techniques arbitraires de RMS ?
[^] # Re: Ça attaque sec
Posté par Zenitram (site web personnel) . Évalué à 5.
De tête par exemple non modularité (pour ne pas permettre les modules non libres, que la GPL empêche si tout statique mais ne peut empêcher si modules non nécessaires au démarrage de l'application et chargés dynamiquement).
Étonnant ;-), LLVM est très modulaire.
# Brevets
Posté par antistress (site web personnel) . Évalué à 4.
Espérons que la question des brevets ne se pose pas (dans les pays concernés) comme avec le c#..?
http://libre-ouvert.toile-libre.org/index.php?tag/brevets
Sinon libérer le code source sans les brevets serait juste de la mauvaise foi
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.