FreeBSD 10.0 abandonne GCC et Bind

Version imprimable

21/01/2014, 15h34
Cedric Chevalier

FreeBSD 10.0 abandonne GCC et Bind

FreeBSD 10.0 abandonne GCC et Bind
le système d'exploitation sort avec des améliorations de son temps de démarrage

FreeBSD 10.0 est disponible. Au programme, beaucoup de nouvelles fonctionnalités qui raviront à coup sûr les inconditionnels de ce système d’exploitation sont au rendez-vous. D’entrée de jeu, on note l’abandon des deux logiciels phares GCC et Bind qui tirent leur révérence. Ils cèdent leurs places aux nouveaux venus Clang, LDNS et Unbound.

On note également la prise en charge du RaspBerry Pi, une meilleure intégration pour la solution de virtualisation Hyper-V de Microsoft, ainsi que des améliorations pour bhyve (une solution de virtualisation maison).

Pour ce qui concerne l’architecture ARM, FreeBSD prend en charge les puces ARMv6, ARMv7 et certains SoC (System on chip) comme le MV78x60 et OMAP4.

Les cartes graphiques du constructeur ATI n’ont pas été oubliées. En prenant en charge le « kernel-modsetting » pour les GPU ATI, la nouvelle distribution offre la possibilité d’utiliser le nouveau driver xf86 pour les cartes ATI.

Côté réseau, des efforts ont été faits pour le support des normes sans fil 802.11s (norme prévue pour le routage d’information dans un réseau sans fil maillé), et 802.11n (qui décrit les procédures nécessaires pour accroître le débit de transfert des données grâce à l’utilisation de plusieurs antennes). De plus, on note aussi une amélioration des drivers des cartes réseau Artheros, pour la prise en charge du standard 802.11n.

Le système ZFS de l'OS n’est pas en reste. Il se dote d’un nouvel algorithme de compression baptisé LZ4, qui offre une amélioration des performances pour les opérations de compression/décompression de 50 % à 80 % par rapport à l’ancien standard LZJB.

Par ailleurs, FreeBSD démarre encore plus rapidement grâce à de meilleures performances de lecture de la cache. Il faut aussi ajouter à cela que les noms des utilisateurs (login name) peuvent désormais atteindre 32 caractères de long.

:fleche: Télécharger FreeBSD 10.0

Source : Wiki FreeBSD

Et vous ?

:fleche: Allez-vous tester cette nouvelle version ?
21/01/2014, 18h14
plawyx

non, pas encore. Mais j'ai hâte de voir son comportement sur un raspberry pi.
21/01/2014, 21h14
transgohan

Nouveautés intéressantes.

J'ai cru qu'ils ne permettaient plus la compilation du noyau via les outils GCC et j'ai cherché un moment pourquoi...
Non parce que c'est pas changer de compilateur qui va améliorer le temps de boot d'un OS. :lol:
Il manque un "de plus" ou un "et" pour qu'on évite l'amalgame.
Ou bien c'est juste que je suis super fatigué...
21/01/2014, 22h00
cocowin

Pourquoi Clang plutôt que GCC ? Qu'est-ce que Clang a de plus que GCC ?
21/01/2014, 23h35
Waikiki

En autre le passage de gcc en licence GPLv3.

Ensuite Clang est "supposé" être plus rapide et moins gourmand en mémoire que gcc, dans la pratique je sais pas si c'est vrai.
22/01/2014, 08h04
Markand

Le retrait de GCC est principalement du à la licence GPL qui n'est pas vraiment en adéquation avec celle du projet. Ensuite, par la même occasion, l'ajout de Clang a permis l'inclusion de la libc++ qui supporte très bien C++11.
22/01/2014, 13h51
Bestel74

Est-ce que quelqu'un a vu un comparatif de qualité entre, par exemple, Debian (ou Linux en général) et FreeBSD ?

C'est vraiment un monde à part, et je n'ai jamais rien trouvé de qualité ou de récent sur ce sujet. Le fait que ça tourne sur la raspberry PI m'intrigue énormément ! Quelqu'un a-t-il déjà essayé ?
24/01/2014, 22h36
SurferIX

Je ne comprends pas trop le fait que Clang soit plus rapide. Ici, un technicien extrêmement pointu livre ses expériences et comparaisons, et le dernier gcc bats Clang sur la plupart des optimisations (02- 03).

Je cite : "Clang a fait un meilleur travail sans aucune réflexion sur mon code, ni aucune optimisation. Après avoir réfléchi à faire un meilleur code, gcc a battu Clang à plate couture sur tous les points" :

"Clang has done much better than GCC at at wringing speed out of my C++ code when I was giving it no help. When I put my mind to helping, GCC did a much better job than Clang."
25/01/2014, 12h59
Kalith

J'ai également pu observer que les exécutables générés par clang sont en général moins rapide que ceux créés par gcc. Pas de beaucoup, mais c'est mesurable.
En revanche, clang compile au moins deux fois plus rapidement que gcc. Dans mon cas c'est pratiquement aussi important que le temps d'exécution (certains programmes mettent 10 secondes à compiler, pour une poignée de secondes de temps d'exécution). Sans compter que les messages d'erreur de clang sont bien plus agréables à lire que ceux de gcc (à noter qu'ils ont enfin fait des efforts sur ce point dans la version 4.8.2).

Pour une distribution comme FreeBSD, j'imagine que le choix du compilateur est extrêmement important. Contrairement à ce que pense transgohan, ça peut impacter les performances (au boot et ailleurs), vu que tous les exécutables/bibliothèques de la distrib sont créés avec ce compilateur. D'un autre côté, ils doivent recompiler sans cesse à chaque patch, et ça doit prendre un certain temps aussi.
Apparemment ici le choix est principalement motivé par un problème de licence, mais je suppose qu'ils n'ont pas fait ce changement à la légère et qu'ils en ont mesuré l'impact.
25/01/2014, 17h20
transgohan

Citation:

Envoyé par Kalith

Pour une distribution comme FreeBSD, j'imagine que le choix du compilateur est extrêmement important. Contrairement à ce que pense transgohan, ça peut impacter les performances (au boot et ailleurs), vu que tous les exécutables/bibliothèques de la distrib sont créés avec ce compilateur. D'un autre côté, ils doivent recompiler sans cesse à chaque patch, et ça doit prendre un certain temps aussi.

Cette perte de temps est selon moi négligeable, cela ne se mesure pas dans l'ordre de la seconde.
Même le plus mauvais des compilateurs(je parle d'un compilateur qui mérite de porter ce titre hein... moi aussi je sais programmer un compilateur qui va vous ralentir votre programme par 1 million...) ne ferra pas perdre 30s de boot. Ou alors c'est vraiment que le code est très chiadé... :lol:
25/01/2014, 20h32
Kalith

Citation:

Envoyé par transgohan

Cette perte de temps est selon moi négligeable, cela ne se mesure pas dans l'ordre de la seconde.
Même le plus mauvais des compilateurs(je parle d'un compilateur qui mérite de porter ce titre hein... moi aussi je sais programmer un compilateur qui va vous ralentir votre programme par 1 million...) ne ferra pas perdre 30s de boot. Ou alors c'est vraiment que le code est très chiadé... :lol:

La seule manière de savoir vraiment serait de faire un benchmark de FreeBSD compilé avec clang et avec gcc. Je dois avouer que j'ai d'autre choses plus intéressantes à faire :) Mais si tu te bases sur l'exemple de la question SO citée ci-dessus, l'auteur de la réponse voit une différence de l'ordre de 20% entre les deux compilateurs en -O3 (sur son programme). En supposant qu'une même différence s'appliquerait au code de FreeBSD, un boot de 10 secondes pourrait durer 2 secondes de plus/moins selon le compilateur. Je pense que tu sens la différence.
26/01/2014, 01h17
transgohan

Cela me paraît fort improbable. A moins d'avoir un code très sale.
M'enfin... Pareil j'ai pas le temps, mais si un jour quelqu'un a le temps ça m'intéresse aussi de voir de tels résultats. :)

Après 2 secondes sur 10 c'est totalement négligeable pour moi. En dessous de l'ordre de la minute je ne vois franchement pas l'intérêt de l'investissement hormis pour un système temps réel ou critique.
Or dans ces cas là on mets pas un FreeBSD. :aie:
26/01/2014, 04h41
Chuck_Norris

Citation:

Envoyé par transgohan

Après 2 secondes sur 10 c'est totalement négligeable pour moi.

Ce n'est absolument pas négligeable, non.

Citation:

Envoyé par transgohan

je ne vois franchement pas l'intérêt de l'investissement

Mais de quel investissement tu parles vu que gcc existe déjà et il est tout aussi libre que clang ? On s'étonne du remplacement d'un compilateur C bien établi par un nouveau venu moins performant.
26/01/2014, 10h02
transgohan

Citation:

Envoyé par Chuck_Norris

Ce n'est absolument pas négligeable, non.

Que ton système boot en 8 ou 10 secondes humainement parlant tu ne vois que rarement la différence. Et si on parle de l'autre côté, pour un système embarqué on s'amuse pas à rebooter tous les jours, de même pour un serveur. Ce sont des systèmes qui tournent pendant des mois.

Citation:

Envoyé par Chuck_Norris

Mais de quel investissement tu parles vu que gcc existe déjà et il est tout aussi libre que clang ? On s'étonne du remplacement d'un compilateur C bien établi par un nouveau venu moins performant.

Le remplacement est-il vraiment plug&play ?
J'ai l'habitude de travailler avec des chaînes de compilation telles que Microtec et autre pour l'embarqué et si je devais passer à GCC il me faudrait repenser tout le link et la génération de toutes les librairies.
26/01/2014, 11h29
jlliagre

Citation:

Envoyé par Chuck_Norris

Mais de quel investissement tu parles vu que gcc existe déjà et il est tout aussi libre que clang ?

Non, la licence de clang (de type BSD) est plus permissive que celle gcc (GPL). C'est certainement la première motivation de son adoption par freeBSD.

Citation:

On s'étonne du remplacement d'un compilateur C bien établi par un nouveau venu moins performant.

clang est certes plus récent que gcc mais n'est plus tout à fait un nouveau venu. D'ailleurs, ce n'est pas forcément un défaut. Son architecture interne est considérée comme meilleure que celle de gcc. Il est utilisé par Apple depuis 9 ans, Apple et Google sont les premiers contributeurs de clang (et llvm), ce qui devrait inciter à prendre ces logiciels au sérieux.
Le remplacement de programmes bien établis par de nouveaux venus est quelque chose d'assez courant, on pourait faire un parallèle avec l'évolution du nombre d'utilisateurs de firefox par ceux de chrome/chromium.
27/01/2014, 10h54
Markand

Citation:

Envoyé par Chuck_Norris

Ce n'est absolument pas négligeable, non.

Mais de quel investissement tu parles vu que gcc existe déjà et il est tout aussi libre que clang ? On s'étonne du remplacement d'un compilateur C bien établi par un nouveau venu moins performant.

On t'a dit au dessus (faut lire) que la licence GPLv3 est une des raisons à pousser GCC hors de FreeBSD. FreeBSD n'est pas une distribution Linux et n'est pas distribué sous licence GPL. De ce fait, les applications sous licence GPL rentrent en conflit avec le système.
27/01/2014, 15h34
Chuck_Norris

Citation:

Envoyé par Markand

On t'a dit au dessus (faut lire) que la licence GPLv3 est une des raisons à pousser GCC hors de FreeBSD. FreeBSD n'est pas une distribution Linux et n'est pas distribué sous licence GPL. De ce fait, les applications sous licence GPL rentrent en conflit avec le système.

C'est gentil mais je suis parfaitement au courant de la raison principale de ce changement. Je trouve en revanche que des disputes sur les licences qui donnent quelque chose de moins performant au final, c'est dommage. Si 12 ou 10 secondes au boot cela n'a effectivement que peu d'importance, en revanche cela veut aussi dire que n'importe quel logiciel sera donc un peu moins performant avec le nouveau compilateur.
27/01/2014, 17h17
Markand

Citation:

Envoyé par Chuck_Norris

C'est gentil mais je suis parfaitement au courant de la raison principale de ce changement. Je trouve en revanche que des disputes sur les licences qui donnent quelque chose de moins performant au final, c'est dommage. Si 12 ou 10 secondes au boot cela n'a effectivement que peu d'importance, en revanche cela veut aussi dire que n'importe quel logiciel sera donc un peu moins performant avec le nouveau compilateur.

Stop l'exagération, personne a dit qu'il y avait 10 secondes de + au boot. D'ailleurs pour ma part j'ai aucune différence de performance.

Concernant les licences, ce n'est pas une simple "dispute" la GPL est extrêmement contraignante et est complètement opposée à la BSD. Ce qui signifie que les personnes désirant faire un fork de FreeBSD, de l'inclure sur un système privateur ils devront se débarasser du compilateur. D'ailleurs c'est bien pour ça qu'il y a un répertoire dédié à tout ce qui est GNU dans le système de base ;)
27/01/2014, 18h18
transgohan

Citation:

Envoyé par Markand

Stop l'exagération, personne a dit qu'il y avait 10 secondes de + au boot. D'ailleurs pour ma part j'ai aucune différence de performance.

Il voulait plutôt dire que le boot prenne 10 secondes ou bien 12 secondes ne l'incommodait pas.
27/01/2014, 18h21
Chuck_Norris

Citation:

Envoyé par Markand

Stop l'exagération, personne a dit qu'il y avait 10 secondes de + au boot.

Personne en effet. Je n'ai jamais dit une chose pareille moi non plus. Je n'ai fait que répondre à transgohan qui parle d'un hypothétique allongement de 2 secondes du temps de boot qui serait donc négligeable à ses yeux, sur lequel j'ai d'ailleurs approuvé. Je ne pensais pas à un temps de boot (qui se fait si rarement qu'il n'a aucune importance), mais à un temps de traitement d'un logiciel spécifique qui pourrait être gênant dans certaines circonstances.

Citation:

Envoyé par Markand

Concernant les licences, ce n'est pas une simple "dispute" la GPL est extrêmement contraignante et est complètement opposée à la BSD. Ce qui signifie que les personnes désirant faire un fork de FreeBSD, de l'inclure sur un système privateur ils devront se débarasser du compilateur. D'ailleurs c'est bien pour ça qu'il y a un répertoire dédié à tout ce qui est GNU dans le système de base ;)

Oui, je sais bien que la GPL est très contraignante. J'aurais personnellement préféré largement que le libre soit justement davantage libre, plutôt que d'être enfermé à cause d'une licence pareille. Je comprends les raisons de RMS pour cela, mais je pense qu'il est allé trop loin avec les contraintes de la GPL qui a posé, pose et posera toujours ce genre de soucis.

Après je n'ai jamais dit que clang était mauvais. Que son temps de compilation soit meilleur est une très bonne chose, gcc étant d'une lenteur extrême. Mais s'il n'y avait pas de telles disputes sur les licences, on aurait pu avoir le choix. Compiler avec gcc ce qui est critique en terme de performances, et clang pour le reste, par exemple.