DragonFlyBSD 3.2, la libellule s’envole toujours plus haut

Posté par . Édité par eggman, d-jo, galactikboulay, baud123, Davy Defaud, Benoît Sibaud, Nÿco, NeoX, bastien et Xavier Claude. Modéré par NeoX. Licence CC by-sa
Tags :
58
5
nov.
2012
DragonFly BSD

DragonFly est un système d’exploitation de type UNIX, issu d’un fork de la branche 4.x de FreeBSD, il y a maintenant presque 10 ans. Initialement, le but était d’arriver à un système d’exploitation pour grappe de serveurs — cluster — et, entre autres, de garantir la cohérence de cache au niveau du système d’exploitation, pour permettre à plusieurs applications de tourner sur une multitude de machines dans un même environnement logiciel. Bien que ce ne soit plus le but premier, ce concept a influencé et continue d’influencer l’architecture du noyau.

Cette dépêche a été rédigée en collaboration avec d-jo, EggMan, bastien, Nÿco et Neox. Merci à tous les participants.

Sommaire

DragonFly 3.2

Le 21 octobre, la version 3.2.1 de DragonFly a été étiquetée dans le dépôt git, 6 mois après la version 3.0.1, sortie en février 2012. Les ISO officielles sont désormais disponibles depuis le 2 novembre sur les miroirs du projet. La suite de la dépêche présente une partie des nouveautés de cette version, ainsi que certains projets à plus long terme.

Noyau

Nouvel ordonnanceur

L’ordonnanceur est le code qui sert à répartir les ressources processeur aux threads qui tournent sur le système. Jusqu’à présent le user mode scheduler était une version un peu modifiée de l’ordonnanceur de BSD 4.4. Il fonctionne avec une file d’exécution par niveau de priorité, le nombre de niveaux de priorité étant fixé. Quand un thread est exécutable, il est placé dans la file correspondant à sa priorité. Le problème de ce code est qu’il avait été écrit dans une optique monocœur. Les files sont protégées par un spinlock, et sont globales (c’est‐à‐dire communes à tous les processeurs), ce qui pose des problèmes de contention.

Dans un premier temps, Mihai Carabas a travaillé durant un GSoC à un framework permettant à l'ordonnanceur de tenir compte de la topologie des CPU (c'est-à-dire de l'agencement des sockets/cores/threads), de manière similaire à ce qui existe dans le noyau Linux. Ce message résume sa contribution, qui consiste en 3 principaux points :

  • L'ajout de code pour détecter la topologie de la machine
  • Une heuristique qui essaie de faire exécuter les threads d'abord sur les cœurs libres puis sur les threads (dans le sens Hyper Threading) du CPU, ce qui a pour effet de rendre les temps d’exécution plus constants, quand le nombre de threads s’exécutant est inférieur au nombre de cœurs. Un exemple avec openssl sur un bi-xeon 12 cœurs/24 threads
  • Une heuristique pour tenter d'améliorer l'effet du cache pour les threads nécessitant beaucoup de CPU, en tentant de les réordonnancer sur le même thread/core/CPU (au choix).

Mais les choses ne se sont pas arrêtées là. Lors de tests consécutifs à ce travail, l’exécution de pgbench sur une Xeon 12x2 (24 thread) a montré des problèmes de passage à l'échelle. Matt Dillon a donc écrit un nouvel user mode scheduler, partiellement basé sur l'ancien, mais avec une logique plus adaptée à un environnement multiprocesseur.

Tout d'abord, les run-queues ne sont plus globales, mais par CPU, ce qui supprime le spinlock global et permet de réduire la contention. Pour reprendre les mots de Matt Dillon,

Le nouvel ordonnanceur contient une réécriture des algorithmes se basant sur la topologie des CPU pour mettre en place une méthode d'ordonnancement verticale (Machine → socket → cœur → hyperthread), essentiellement par 3 mécanismes :

  1. il calcule un facteur de charge pour chaque niveau de la topologie, et équilibre les processus assignés aux CPU selon ce facteur en tenant compte de la topologie. Cela signifie que 4 processus s’exécutant dans un environnement 4x2 (8 threads) seront assignés aux 4 cœurs et non à des hyperthreads d'un même cœur.
  2. il essaye d'éviter de migrer des processus quand c'est possible, et si ce n'est pas le cas, il essaye de les garder proches au sens topologique.
  3. il détecte les événements de type blocage/réveil des processus qui, par exemple, associent deux processus et essaye de déplacer les deux éléments de la paire plus près l'un de l'autre, en utilisant ces informations. Par exemple, s'il y a beaucoup de clients et de serveurs PostgreSQL sur une grosse machine, assez pour charger tous les cœurs, les couples clients/serveurs s’exécuteront sur les mêmes sockets, ce qui permet d'utiliser les caches des processeurs pour les communications interprocessus.

Les gains de ce travail sont immenses, comme le montre le test de performances globales présenté plus bas. Ils ont un impact sur différentes charges, comme par exemple la compilation du noyau.

Virtual memory : optimisation de la mémoire partagée pour x86_64

Les tests de passage à l'échelle avec pgbench ont montré un goulot d'étranglement dans la gestion des segments de mémoire partagée de grande taille qu'ils soient obtenus par SYSV SHM ou MMAP. En effet, quand un processus effectue un fork, chaque processus doit passer par un grand nombre de page faults. Quand de nombreux processus effectuent un fork, comme c'est le cas dans les tests pgbench, il s'agit de millions de page faults. En outre, les page tables sont dupliquées.

Pour comprendre cette optimisation, une vue d'ensemble du fonctionnement de la mémoire virtuelle sous DragonFlyBSD est nécessaire. Si vous êtes intéressés, ce vieil article explique le fonctionnement général de la mémoire virtuelle.
Pour éviter ces problèmes, quand un vm_object est assez grand, la partie de la page table concernée est stockée dans l'objet lui-même et non dans le pmap du processus. De ce fait, les page tables pour ce segment sont conservées dans l'objet sous-jacent, et ne sont plus détruites lors d'un fork(). En outre, les page tables concernées ne sont plus dupliquées dans les pmap de chaque processus, mais sont partagées.

Cette optimisation permet d'améliorer les performances dans ce genre de conditions, mais aussi au lancement d'applications X par exemple, et de réduire la pression sur le cache des processeurs. Pour en savoir plus, voir le message de Matt Dillon à ce sujet

Autres optimisations SMP

Outre le travail sur l'ordonnanceur, de nombreux goulots d'étranglement ont été supprimés dans diverses parties du noyau, comme les sockets unix, ou les sémaphores POSIX.

Tout ce travail a conduit à une impressionnante amélioration du passage à l'échelle dans divers domaines. Cette amélioration est particulièrement visible dans le cas de pgbench, puisque c'est ce test de performance qui a été surtout utilisé pour identifier les goulots cette fois-ci, mais elle touche beaucoup d'usages. Ce PDF illustre les améliorations obtenues et donne à titre indicatif les chiffres obtenus sur d'autres BSD ou sur Linux avec la même machine : entre DragonFly 3.0 et 3.2, il s'agit d'une amélioration de 500% dans le meilleur des cas.

Augmentation des performances
Dans ce graphique, les meilleures performances sont les nombres des ordonnées les plus élevés.

Pile USB

Markus Pfeiffer a porté la nouvelle pile USB introduite dans FreeBSD  8, après 5 ans de développement. Cette nouvelle pile permet notamment de gérer la norme USB3 et devrait améliorer grandement la gestion de l'USB, ainsi que les performances. Cette pile n'est toutefois pas compilée par défaut, car l'import est récent et n'a pas encore été largement testé.

Systèmes de fichiers

puffs

Un port de PUFFS depuis NetBSD et FreeBSD, issu du projet de Nick Prokharau pour le GSoC 2011 a été inclus. PUFFS est un mécanisme permettant d'implémenter des systèmes de fichiers en espace utilisateur. Il est composé de plusieurs parties :

  • Le sous-système puffs, dans le noyau, qui s'intègre à la couche VFS, et qui exporte une interface utilisateur via un fichier dans /dev.
  • une bibliothèque libpuffs qui permet de communiquer simplement avec la partie noyau et qui fournit un ensemble d'utilitaires pour simplifier la création de systèmes de fichiers.
  • une bibliothèque librefuse qui fournit une couche de compatibilité avec le système Filesystem_in_Userspace utilisé par Linux.
vquota

Le système de gestion des quotas a été modifié. vquota(8) est un sous-système permettant de définir des quotas de manière indépendante du système de fichiers sous-jacent, en se basant sur la couche VFS. Il faut noter toutefois que ce problème soulève des questions difficiles à résoudre : combien de fois par exemple doit-on compter les hardlinks d'un même fichier ? Ou, pire, le système de fichiers Hammer conserve l'historique des transactions et, donc, des contenus pour une durée déterminée. Un fichier de 20 Ko, modifié souvent, peut en réalité prendre plusieurs Mo sur le disque.

tmpfs

tmpf(5) est un système de fichiers résidant dans la mémoire virtuelle. Il a profité de diverses corrections de bugs et améliorations. Par exemple, les répertoires ont désormais une structure d'arbre rouge/noir et non de liste, ce qui accélère les opérations de recherche. En outre, les systèmes de fichiers tmpfs sont désormais accessibles par NFS.

pilotes et réseau

Côté réseau, on notera l'ajout d'un nouveau pilote pour les cartes réseau Intel 10Gb (ixgbe(4)) ainsi que la mise à jour des pilotes pour les cartes Broadcom (bge(4), bnx(4)). Également notable, un gros travail sur TSO (TCP Segmentation Offload) qui touche les pilotes em(4), emx(4), bce(4), bge(4), bnx(4), igb(4) et jme(4) et sur la conformité et l'implémentation des standards :

  • RFC3390 (Increasing TCP's Initial Window),
  • RFC6298 (Computing TCP's Retransmission Timer),
  • RFC6633 (Deprecation of ICMP Source Quench Messages),
  • RFC4015 (The Eifel Response Algorithm for TCP),
  • RFC6675 (A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP)
  • et RFC4653 (Improving the Robustness of TCP to Non-Congestion Events).

Diverses autres améliorations ont eu lieu, avec près de 400 commits.

Côté RAID matériel, on compte deux nouveaux pilotes : hpt27xx(4) pour les cartes à base de HighPoint RocketRAID 27xx et hptrr(4) pour toute une série de modèles de la même marque. Une grande partie des autres pilotes de contrôleurs RAID ont été mis à jour.

Des pilotes pour gérer les watchdog des chipsets AMD et Intel ont été importés de FreeBSD, ichwd(4) et amdsbwd(4), et l'implémentation ACPI a été mise à jour.

Espace utilisateur

GCC 4.7

DragonFly contient deux compilateurs dans sa base. Sous DragonFly 3.0, il s'agissait de GCC 4.4 comme compilateur par défaut et de GCC 4.1 comme second compilateur. John Marino s'est attelé à la lourde tâche d'intégration de GCC 4.7, qui est désormais le compilateur secondaire et qui permet de compiler un système fonctionnel.

Il faut noter qu'il est possible de compiler le système avec clang, fourni comme paquet via pkgsrc. L'opinion actuelle est que GCC 4.7 risque de rester dans la base pour un moment, même si clang pourrait y être introduit, notamment car il est le dernier GCC qui ne nécessite pas C++.

Éditeur de liens dynamiques

L'éditeur de liens dynamiques permet de retarder l'édition des liens à l’exécution et, donc, d'utiliser des bibliothèques partagées. RTLD, l'éditeur de liens dynamiques de DragonFly est le même que celui de FreeBSD, les deux projets contribuant à son développement. Outre diverses améliorations, il gère désormais l'extension GNU DT_GNU_HASH pour le format ELF, qui permet de réduire le temps de recherche des symboles. Le système de base tire parti de cette fonctionnalité. Dans la pratique, ces changements permettent de réduire de 50% le temps de chargement de certains binaires.

Divers

Pour ceux qui se demandent s'il y a des interactions entre les BSD, dhclient(8) a été mis à jour depuis OpenBSD, ftp(1) et libedit depuis NetBSD, cut(1) et sh(1) depuis FreeBSD. Il existe également des projets communs tels que libarchive qui a pour l'occasion été mise à jour en version 3.0.4.

La commande mount essaie désormais de détecter automatiquement le type de système de fichiers.

Paquets

DragonFly fournit des paquets binaires basés sur pkgsrc, le système de paquet issu de NetBSD. Les paquets binaires peuvent être simplement gérés par un gestionnaire de paquets (pkg_radd, ou même pkgin), comme sous les distributions GNU/Linux. Avec la version 3.2, c'est la branche pkgsrc-2012Q3 qu'on peut installer par défaut. Rappelons que les paquets ne font pas à proprement parler partie de l'OS et qu'il s'agit de logiciels tiers. Pkgsrc donne accès à plus de 13000 paquets.

Qualité du code

Malgré son peu de ressources humaines, les développeurs de DragonFlyBSD apportent un grand soin à la qualité du code et de la documentation. On remarquera en particulier le travail de Sascha Wildner qui se consacre presque exclusivement à cette tâche. Entre la version 3.0 et 3.2, on a 25254 commits, dont 1788 concernent les pages de man et 347 les tests. Avec les corrections de style, de coquilles, les suppressions de code mort, la mise à jour de code utilisant d'anciennes API, on peut considérer qu'environ 15% à 25% de l'activité concerne l'amélioration de la qualité.

Projets

Hammer2

En mai 2011, Matt a publié une première spécification du système de fichiers hammer2. Il s'agit d'une évolution majeure de hammerfs, proposant de véritables fonctionnalités réseau. Quelques mois après, la branche hammer2 sur le dépôt git, permettait d'entrer dans le vif du sujet.

La première tâche à laquelle Matt s’est attelé concerne les briques de base de la partie réseau. Il fait état de leur avancement dans un long message début août. Actuellement, l'implémentation permet aux machines de se connecter entre elles de façon chiffrée et d'échanger des messages transactionnels. Un protocole de type spanning tree protocol permet la diffusion de l'information au niveau du cluster. L'idée est de pouvoir utiliser un seul système de fichiers sur plusieurs machines, sans avoir à se soucier manuellement de la topologie du réseau. Les différentes instances communiquent entre elles, permettant une mise à jour des pfs (les "volumes" de hammer) en ligne ou une resynchronisation à la connexion.

Hammer2 devant permettre une grande souplesse dans les choix topologiques (toutes les combinaisons possibles de nœuds maîtres, esclaves, cache et client), l'implémentation de ces briques de base est essentielle et laborieuse. Cela dit, Matt pense bientôt voir le bout du tunnel et commencer la partie amusante (sic), c'est-à-dire l'implémentation de fonctionnalités de haut niveau : haute disponibilité, réplication, répartition…

Le système d'échange de messages a par ailleurs été généralisé et poussé dans master, car il devrait trouver des applications hors de hammerfs, comme l’exposition de périphériques sur le réseau.

bmake

Comme c'est le cas pour son cousin FreeBSD, DragonFlyBSD est en train de changer d'implémentation de make. Le vénérable pmake, peu maintenu, sera remplacé par bmake issu de NetBSD.

inotify

Vishesh Yadav a travaillé cet été dans le cadre du GSoC à une implémentation de l'interface inotify sous DragonFlyBSD. Il semble que son code doive être commité bientôt. L’intérêt d'inotify, par rapport à kqueue, est d'éviter d'avoir à maintenir un descripteur de fichier par fichier surveillé. L'API proposée par Linux semblant stable et efficace, elle sera utilisable en plus de kqueue, améliorant la compatibilité entre les deux OS.

Desktop

Il y a eu courant juillet un long fil sur l'utilisation de DragonFlyBSD comme Desktop. Stéphane Russell y raconte son expérience qui n'est, selon son expression, pas si mauvaise. À noter qu'un certain nombre de commits sur les pilotes de carte audio, le précédent travail sur KMS et la nouvelle pile USB devraient améliorer les choses. XFCE semble être l'environnement de bureau le plus fonctionnel.

dargonfly xfce

  • # Une ch'tite erreur sur le but initial

    Posté par . Évalué à  2 .

    Il est marqué "initialement, le but était d'arriver à un OS pour cluster" euh non ça c'était la position de repli.

    D'après mon souvenir, c'était pour le support du SMP, wikipedia confirme ("résulte d'un fork en 2003 de FreeBSD 4.8 mené par Matt Dillon, jugeant le nouveau système de threading et SMP de FreeBSD 5 peu performant et difficile à maintenir"), mais en fait il s'est plus focalisé sur les clusters..

    • [^] # Re: Une ch'tite erreur sur le but initial

      Posté par . Évalué à  10 .

      Il va falloir que tu m'expliques en quoi c'est complétement différent. Pour, c'est le même problème, ou du moins, le SMP est juste un sous problème du cluster. Le projet SMP avait pour but d'augmenter la localité des données, et d'isoler les sous-systèmes tout en peremttant d'avoir des mécanismes de communication et de serialisation performants. Pour moi, c'est exactement ce qui est nécessaire pour faire un OS de cluster. Après, la partie restante, la cohérence de cache a je pense été abandonnée (j'en sais rien), parce que les nouveaux processeurs ccNUMA ou SMP gèrent ça eux même.

      Il me semble que le SMP est juste un moyen, pas un but.

      Well I strongly believe that any project needs to have an unattainable goal, and our unattainable goal (which I hope actually winds up being attainable) is to develop DragonFly into a transparently cluster-capable system implementing native SSI (Single System Image). It is something that no non-commercial system today can do (the type of clustering Linux supports isn't even close to the type of clustering that we have as our goal, and clustering has never been one of the other BSD's goals as far as I can tell).

      In the short term, I have become very exciting about our light weight kernel threading technology, in particular the methodlogy we are adopting to serialize data access by partitioning major subsystems into threads instead of serializing data access with mutexes (FreeBSD-5 and Linux use a mutex-centric model, DragonFly uses a thread-centric model). The reason for this excitement is that it is becoming clear to us that we can develop very clean-looking, elegant, debuggable, SMP scaleable software using this model whereas using the mutex model generally results in much less elegant (even ugly), difficult-to-debug code. Code complexity and code quality is a very important issue in any large piece of software and we believe we have hit on a model that directly addresses the issue in an SMP environment without compromising performance.

  • # manque d'interet

    Posté par . Évalué à  5 .

    Je remarque qu'il y a peu de messages concernant cette dépêche, est ce du au faut qu'on est pas sur bsdfr.org ?
    Ça n’intéresse personne les bsd ?

    • [^] # Re: manque d'interet

      Posté par . Évalué à  -5 .

      Promis, je ne répondrai pas, ce n'est pas encore vendredi…

    • [^] # Re: manque d'interet

      Posté par (page perso) . Évalué à  5 .

      Ou alors qu'il n'y a pas grand chose à dire dessus. Elle a quand même une note de 46 au moment où j'écris ce commentaire, ce qui n'est pas mal du tout.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: manque d'interet

      Posté par . Évalué à  5 .

      Ils se sont peut-être arrêtés quand ils ont vu que son installeur avait la même tête que celui de Windows XP.

      Blague à part cette actu est très intéressante, j'ai déjà eu affaire à NetBSD/OpenBSD, un petit peu à FreeBSD, mais DragonflyBSD je n'y ai jamais mis les pieds, et maintenant j'en ai vraiment envie !

      Le benchmark est assez intéressant dans le sens où il montre que Linux 2.6.32 qui est quand même assez vieux poutre tout le monde et de loin.

  • # performances

    Posté par . Évalué à  2 .

    Quelques questions ou remarques sur les performances.

    1/ Le fait de s'adapter à la topologie des machines paraît une bonne idée. Est ce que les autres *BSD, Linux ou tout autre noyau utilise ce principe ?

    2/ Je ne connaissais pas Scientific Linux. Cela semble juste une distribution particulière de Linux mais avec rien de spécifique sur le noyau, n'est ce pas ?

    3/ Le texte de la dépêche est alléchant sur le sujet performance ("500%") mais au final, on se rend compte que la version 3.0 était pas top et que la version 3.2 ne fait que ramener ce système dans le haut du panier.

    4/ du coup, est ce que l'approche "topologique" est bonne ou simplement, Linux le fait déjà et dragonfly ne fait que rattraper son retard ?

    • [^] # Re: performances

      Posté par . Évalué à  5 .

      1/ Le fait de s'adapter à la topologie des machines paraît une bonne idée. Est ce que les autres *BSD, Linux ou tout autre noyau utilise ce principe ?

      Linux, ainsi que solaris et freeBSD, tiennent compte de la topologie dans leur scheduler. Toutefois, les schedulers sont différents et suivent des approches différentes. Linux bénéficie d'un gros travail sur les perfs du scheduler.

      2/ Je ne connaissais pas Scientific Linux. Cela semble juste une distribution particulière de Linux mais avec rien de spécifique sur le noyau, n'est ce pas ?

      C'est un clone de RHEL, donc un noyau RHEL. C'est juste le noyau 2.6.32.

      3/ Le texte de la dépêche est alléchant sur le sujet performance ("500%") mais au final, on se rend compte que la version 3.0 était pas top et que la version 3.2 ne fait que ramener ce système dans le haut du panier.

      Oui. Mais il faut se dire que le passage de la 3.0 à la 3.2 n'est que la partie visible de l'iceberg. C'est juste l'aboutissement d'un travail de base, les derniers réglages qui font que tout marche. D'ailleurs, les perfs de pgbench ont augmentées depuis plusieurs versions.

      4/ du coup, est ce que l'approche "topologique" est bonne ou simplement, Linux le fait déjà et dragonfly ne fait que rattraper son retard ?

      Si tant est qu'on puisse parler de retard, oui, on peut dire ça. Mais rattraper ce n'est pas forcément adapté, car l'approche est un peu différente.

  • # Les autres BSD à la traine

    Posté par (page perso) . Évalué à  2 . Dernière modification : le 06/11/12 à 21:34

    Est-ce que le travail sur l'ordonnanceur de DragonflyBSD pourra être bénéfique aux autres BSD ?

    FreeBSD se targue d'être utilisé dans de grosses boîtes comme yahoo, m'enfin vu les performances, on se demande s'ils n'en viendraient pas à regretter leur choix au moins de ce côté des choses.

    Et qu'en est-il d'OpenBSD ? Bien que ça ne soit pas forcément son objectif, si NetBSD est là alors pourquoi pas OpenBSD. pgsql n'a pas encore été porté peut-être.

    Love, bépo.

    • [^] # Re: Les autres BSD à la traine

      Posté par . Évalué à  7 .

      Est-ce que le travail sur l'ordonnanceur de DragonflyBSD pourra être bénéfique aux autres BSD ?

      Dans la majorité, non, car ils dépendent de choix techniques spécifiques à dragonfly. Les modifications de pmap pourraient être porté simplement sous FreeBSD je pense, mais FreeBSD vise déjà les huge pages.

      FreeBSD se targue d'être utilisé dans de grosses boîtes comme yahoo, m'enfin vu les performances, on se demande s'ils n'en viendraient pas à regretter leur choix au moins de ce côté des choses.

      Premièrement, les performances, ça ne veut rien dire, c'est un benchmark spécifique qui ne reflette même pas les conditions réelles. DragonFly a travaillé sur ce benchmark pour améliorer les performances SMP, mais ça n'en fait pas une mesure fiable. En plus il y a les réglages par défaut qui comptent, via sysctl, et qui peuvent aussi jouer sur les perfs. Je pense qu'optimizer FreeBSD dans ce cas ne serait peut être pas plus dur que d'optimiser dragonFly comme cela a été fait.

      Et qu'en est-il d'OpenBSD ? Bien que ça ne soit pas forcément son objectif, si NetBSD est là alors pourquoi pas OpenBSD. pgsql n'a pas encore été porté peut-être.

      Parce qu'openBSD n'avait pas de threads 1:1 jusqu'a la dernière version ? Alors tester le passage à l'échelle SMP, c'est un peu étrange…

      Quand à pgsql qui ne serait pas porté : http://openports.se/databases/postgresql

      • [^] # Re: Les autres BSD à la traine

        Posté par (page perso) . Évalué à  2 .

        Bon ben je pense que j'ai du pain sur la planche pour comprendre vraiment de quoi il retourne. Pour pgsql, je pensais à la version utilisée et non pas à son portage en général ;)

        Love, bépo.

  • # Quelqu'un pourrait m'expliquer ?

    Posté par . Évalué à  6 .

    L'opinion actuelle est que GCC 4.7 risque de rester dans la base pour un moment, même si clang pourrait y être introduit, notamment car il est le dernier GCC qui ne nécessite pas C++.

    Y a un truc que je pige pas, DragonFlyBSD envisage de passer à clang/llvm uniquement parce que GCC >= 4.8.x sera (partiellement) réécrit en C++ (enfin un sous-ensemble) ?
    Le truc c'est que clang/llvm c'est écrit en C++, donc ça me semble un peu léger comme argumentaire.
    FreeBSD a longtemps été bloqué à GCC 4.2.x parce que c'était la dernière version non GPLv3 (jugée incompatible avec les valeurs du projet FreeBSD), ça et l'idée d'avoir une chaine de compilation 100% sous licence BSD constituait une bonne raison de switcher.

    • [^] # Re: Quelqu'un pourrait m'expliquer ?

      Posté par . Évalué à  1 .

      On peut imaginer que C++ seul ou GPL seul sont acceptables mais pas les deux.

    • [^] # Re: Quelqu'un pourrait m'expliquer ?

      Posté par (page perso) . Évalué à  4 .

      Trois choses :

      • L'unité au niveau licence n'est pas un objectif majeur en soit. C'est éventuellement un plus.

      • DragonFlyBSD essaye de supporter un maximum de compilateurs

      • Le C++ doit être évité si possible. Il est avant tout exclus dans la libc et du noyau

      • Ce qui compte avant tout c'est la qualité du code, les fonctionnalités, la rapidité. C'est à ce niveau qu'est le débat.

        http://lists.dragonflybsd.org/pipermail/users/2012-October/017562.html

      • [^] # Re: Quelqu'un pourrait m'expliquer ?

        Posté par . Évalué à  -1 .

        J'aurais bien aimer voir les différences entre GNU/Linux ex:(debian) et les BSD qui on était citer ici,
        pour voir réellement les avancer qui on était faite de pare et d'autre.

        Est ce possible ou pas.

        Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.

Suivre le flux des commentaires

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