Pour les 3 premières raisons GCC convient parfaitement (cross-compilation pour les machines peu puissantes, compile tout le système et capable de bootstrap, gère toutes les archis cibles d'OpenBSD).
En revanche les 2 dernières raisons sont parfaitement légitimes et je comprends pourquoi les devs d'OpenBSD cherchent une alternative à GCC

[ Répondre ]

>>> Un compilo C/C++ qui se focaliserait sur la rapidité de compilation ça serait génial.

Pourquoi ne pas opter pour la solution évidente : quand on écrit le programme et qu'on fait pleins de cycles compilation/modifs/compilation alors n'optimise pas du tout le code pour que la compilation soit rapide (-O0) et à la fin de l'écriture du programme on n'a plus qu'a optimiser à fond (-O3).

[ Répondre ]

T'avais lu le PS du post je présume ?

[ Répondre ]

>>> si tu avais regardé avant de dégainer, tu aurais vu que j'ai fait quelques dépeches/journaux autour d'OpenBSD

J'ai regardé avant d'écrire mon post et c'est parce que j'ai vu que tu avais fait la news d'OpenBSD 3.8 que je me suis dit que tu pouvais continuer au lieu de critiquer.

>>> je laisse ce boulot à d'autres qui ont beaucoup plus de patience et de tact que moi :)

J'ai fais les news OpenBSD 3.9 et OpenBSD 4.0...est-ce à dire que j'ai beaucoup plus de patience et de tact ? Ou bien est-ce parce que ton accusation de baveur anti -BSD à mon encontre est finalement mal fondée ?

[ Répondre ]

Non tu n'a pas compris (ou je me suis mal exprimé). Si on avait eu un GCC modulaire alors Apple aurait gardé pour elle (sous licence propriétaire) son analyseur de source Objective-C et l'aurait "branché" sur la partie génératrice de binaire de GCC.
C'est ça que veut éviter Stallman : le fait pour une entreprise de garder des plugins proprios qu'on peut brancher sur GCC.
Stallman préfère, et on le comprends, que le code contribué soit sous licence libre et pour cela il oblige à contribuer directement à GCC.

[ Répondre ]

>>> Stallman justifie des abérations techniques en invoquant des raisons politiques

Y'a quand même un bel avantage technique qui est sorti de la position de Stallman : Apple a contribué au support d'Objective-C dans GCC alors que si il était possible d'avoir un GCC très modulaire il est fort probable (euphémisme pour "plus que certain") que le support d'Objective-C serait resté purement dans le giron d'Apple.

[ Répondre ]

>>> Je sens une certain dénigrement de PCC

Mais en quoi le fait de dire que PCC ne pourra pas remplacer GCC tant qu'il ne supportera pas d'autres langages que le C est un dénigrement ? Pour moi c'est juste le rappel d'un fait.
Si l'utilisateur peut se contenter du C (antérieur à C99) alors PCC est effectivement une alternative, sinon non.

En quoi le fait de dire que l'argument selon lequel GCC ne serait pas maintenu est faux est un dénigrement de PCC ? Pour moi c'est juste le rappel d'un fait. Cet argument du manque de développement upstream ne doit pas être utilisé car il est faux.

En quoi le fait de dire que l'écart de 10% de performances n'est pas soutenu par des benchmarks est un dénigrement ? Pour moi c'est juste le rappel d'un fait. Tant que nous n'aurons pas des benchs comparatifs il est normal et sain d'être quelque peu sceptique au sujet des performances car, de l'aveu même de son mainteneur, PCC n'est pas optimisé.

Dire que je bave systématiquement sur les BSD est absurde. J'ai écrit pas mal de news sur les OS BSD, sur PC-BSD et j'ai même écrit la news sur LLVM 2.2 qui est un compilateur sous licence BSD : http://linuxfr.org//2008/02/18/23723.html

[ Répondre ]

>>> On connait pas le sujet, donc bavons !

Nous serions plus qu'heureux que tu proposes de belles dépêches en relation avec le monde BSD. Cela contribuerait à élever le niveau et à faire connaitre le sujet.

[ Répondre ]

>>> les habituelles baves de patrick_g

Mais oui. Des baves du style "PCC a donc toute sa place (dans la catégorie C-only et taille réduite sans trop d'optimisations) et on ne peut que lui souhaiter bonne chance" n'est ce pas ?
Je dis explicitement que le développement de PCC est souhaitable pour le logiciel libre dans son ensemble mais visiblement tu ne lis que ce que tu veux bien lire.

Je ne sais pas ce qu'ont certains utilisateurs de systèmes BSD mais il semble que dès qu'on émet la moindre réserve on se fait traiter de tous les noms.

[ Répondre ]

Plutôt Lojban non ?

[ Répondre ]

grmmmbl....c'est fait.
J'aurai jamais du me lancer là-dedans, je sens que ça va être sans fin.

[ Répondre ]

Merci pour tes remarques. C'est corrigé.

[ Répondre ]

>>> À propos de gcc j'avais entendu dire que son architecture avait volontairement été rendu moins pratique par Sallman, pour rendre plus difficile les extension propriétaires. Est-ce que que quelqu'un serait dire si cela à un fond de vérité ou si il s'agit de pure légende urbaine

C'est la vérité vraie (même si le mail ou il déclare ça date de 2000):

http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html

Y'avait eu une discussion sur LWN ou j'avais aussi posté le lien vers ce mail et il y a des commentaires intéressants:
http://lwn.net/Articles/301135/

[ Répondre ]

>>> Beaucoup voient en lui une alternative viable à GCC qui pourra à terme le remplacer

Heu...alternative peut-être...mais uniquement si on veut compiler du C !
Pour les autres langages supportés par GCC (C++, Java, Fortran, Ada, Objective-C) elle est ou l'alternative ?

>>> pour une vitesse d'exécution environ 10% plus lente

Ou sont les benchs qui prouvent cette affirmation ? Vu le boulot incroyable incorporé dans l'optimisation de GCC j'ose conjecturer que l'écart entre PCC et GCC est bien plus grand que 10%. J'attends de pied ferme une réfutation de cette conjecture.

Quand à la motivation du projet PCC il est certain qu'une situation de monopole n'est jamais saine. GCC a beau être un superbe soft il vaut mieux pour le logiciel libre que des alternatives émergent (on pense à LLVM par exemple). PCC a donc toute sa place (dans la catégorie C-only et taille réduite sans trop d'optimisations) et on ne peut que lui souhaiter bonne chance.
Je ne peux toutefois m'empêcher de trouver curieuse la justification apportée par Theo de Raadt dans cette interview d'octobre 2007: http://www.thejemreport.com/content/view/369/

Je cite : "What other hurdles remain in replacing GPL-licensed programs in OpenBSD?

TdR: But that's never really been the agenda, see. Some people think we hate GNU code. But the thing is we hate large code, and buggy code that upstream does not maintain. That's the real problem...".

Si Theo pense vraiment que GCC n'est pas maintenu upstream alors il doit vivre dans un monde parallèle au notre. Un monde ou IBM, Red Hat, Novell, Bull, Google, l'INRIA, et de nombreuses autres entreprises et universités ne contribuent pas au développement de GCC (allez donc voir les affiliations des auteurs des articles des différents GCC summits).
Dire qu'on soutient PCC car on trouve que GCC n'est pas maintenu c'est grotesque.

[ Répondre ]

>>> Je n'ai jamais douté que Linux puisse devenir grand public

A mon avis un grand pas sera fait quand les entreprises basculeront vers GNU/Linux et que les salariés bosseront donc avec une distro classique (Suse, Red Hat, Debian, Ubuntu ou autre).
Il y a de bonnes chances que ce soit cette utilisation banalisée dans le monde du travail qui provoquere la bascule pour le grand public.

[ Répondre ]

Extrait de la page de news de Knuth : "it is no longer safe to write personal checks. A criminal who sees the numbers that are printed at the bottom of any check that you write can use that information to withdraw all the money from your account."

C'est vrai ce truc ? Est-ce aussi le cas en Europe ?

[ Répondre ]

ça marche pour toi le changement en passant par https://linuxfr.org/css.html ?

[ Répondre ]

>>> Tout ce qu'il a fait dans Ubuntu, il aurait pu le faire dans Debian, sans forker.

Sauf qu'avec Ubuntu il est aux manettes et il peux prendre des décisions. Avec Debian le processus décisionnel est...hum...plus long.

[ Répondre ]

Une fille dégarnie alors : http://www.flickr.com/photos/11384633@N00/642537254/ (photo prise lors de la réunion des modérorelecteurs du site).

[ Répondre ]

D'après le changelog du 2.6.27.1 le vrai bug est enfin corrigé (le coupable se révèle être CONFIG_DYNAMIC_FTRACE qui provoquait une corruption).

[ Répondre ]