Sortie de DragonFlyBSD 1.4

Posté par patrick_g (site web personnel) le 10 janvier 2006 à 16:01. Modéré par Amaury.

Étiquettes :

jan.

2006

Le projet DragonFlyBSD est issu d'une divergence entre les développeurs de FreeBSD et Matt Dillon qui était un contributeur régulier. Celui-ci pensait que le chemin emprunté par la série des FreeBSD 5.x n'était pas le bon et il a donc choisi de se baser sur la série (robuste et éprouvée) FreeBSD 4.x pour la faire évoluer. Le but final est d'obtenir un système à image unique pour les clusters (un seul OS pour n machines) au lieu d'un cluster traditionnel (n OS pour n machines).

Voici donc, depuis le 7 janvier, la version 1.4 de ce système original.

Les nouveautés essentielles concernent une mise à jour profonde de la librairie C et l'introduction du système de packages de NetBSD (PKGSRC). Le compilateur par défaut est maintenant GCC 3.4 (la série 2.95 n'est plus supportée). Le démon NTP (synchronisation du temps) est DNTPD et il devient spécifique à cet OS. TLS (Thread Local Storage) est maintenant en espace utilisateur et les programmes peuvent donc l'utiliser directement (qu'ils soient multithreadés ou pas).

La liste des améliorations et des corrections de bugs est importante et Matt Dillon annonce que cette version 1.4 est la meilleure de toute sur le plan de la stabilité. La seule architecture supportée reste x86 mais un port vers x86-64 a démarré. Dans le cas d'un ordinateur multiprocesseurs la solution logicielle habituelle est l'implantation d'un gros verrou (Big kernel lock) qui empêche deux tâches d'accéder simultanément au noyau. Pour améliorer les performances le système FreeBSD 5.x utilise des verrous fins locaux (mutex pour mutual exclusion). C'est un système extrêmement compliqué et le code est difficile à maintenir.

Selon Matt Dillon cette complexité extrême de FreeBSD 5.x (avec son nouveau modèle de processus, son ordonnanceur de nouvelle génération, l'implémentation de verrous locaux pour les processus au détriment du verrou global, etc.) va empêcher l'obtention d'une grande fiabilité.

Pour DragonFlyBSD c'est la voie de la simplicité qui a été retenue. Le système (LWKT pour Light Weight Kernel Threads) utilise un ordonnanceur par CPU (les processus sont donc compartimentés dans leur CPU) et ils ne peuvent migrer qu'exceptionnellement avec un inter-processor interrupt (IPI). Les mutex de FreeBSD sont remplacés par des sortes de jetons logiciels (serialized tokens) qui garantissent à un ensemble de threads qu'ils ne tourneront jamais en même temps à condition qu'ils ne bloquent pas dans un appel système.

L'avantage principal de LWKT est que la mémoire cache des processeurs est mieux utilisée puisqu'elle duplique beaucoup moins d'informations. Le code est également plus simple, plus lisible et plus maintenable.

Matt Dillon a également beaucoup d'idées originales et singulières pour les versions futures de DragonFlyBSD (en particulier la réécriture du système de fichier virtuel en userspace et utilisant LWKT).

Cet OS mérite certainement qu'on s'y intéresse.

Aller plus loin

Les nouveautés de la version 1.4 : (1 clic)
DragonFlyFBSD sur fr.Wikipedia : (3 clics)
Version plus riche sur en.Wikipedia : (1 clic)
Le test (critique) de Distrowatch : (0 clic)
Les plans pour la version 1.5 : (1 clic)

# Et la mascote?

Posté par psychoslave__ (site web personnel) le 10 janvier 2006 à 17:12. Évalué à 3.

Et pour la mascote y aura un super dragon qui crache des flammes et tout?
Ce serait argument de poid ça quand même...
- [^] # Re: Et la mascote?
  
  Posté par Jean-Christophe Berthon (site web personnel) le 10 janvier 2006 à 17:16. Évalué à 10.
  
  euh ... dragonfly c'est libellule en français ;-)
  désolé de brider ton imagination !
  :-)
  - [^] # Re: Et la mascote?
    
    Posté par psychoslave__ (site web personnel) le 10 janvier 2006 à 17:36. Évalué à 7.
    
    zut, une libellule qui crache du feux alors? ;P
  - [^] # Re: Et la mascote?
    
    Posté par tuiu pol le 10 janvier 2006 à 17:39. Évalué à 3.
    
    Voila, cf -> http://www.dragonflybsd.org/smalldf.jpg
    - [^] # Re: Et la mascote?
      
      Posté par JoeltheLion (site web personnel) le 11 janvier 2006 à 01:37. Évalué à 4.
      
      Pff, déception totale!
# Motivation?

Posté par Sylvain Briole (site web personnel) le 10 janvier 2006 à 17:24. Évalué à 7.

Une petite question (je viens de parcourir le site de DragonFly) : quel est exactement le "positionnement" de DragonFly BSD par rapport aux autres BSD libres?

Pour l'instant, j'avais : (merci de commenter ;-))
- NetBSD : portabilité, propreté du code (qualité du code prioritaire sur l'implémentation de la fonctionnalité)
- OpenBSD : sécurité à tout prix (ou presque)
- FreeBSD : mix des deux précédents, avec accent mis sur la fonctionnalité

Puis-je rajouter :
- DragonFly BSD : multi-processeur/multi-tâches, expérimenter des nouvelles voies?
- [^] # Re: Motivation?
  
  Posté par patrick_g (site web personnel) le 10 janvier 2006 à 17:37. Évalué à 8.
  
  Oui et non.
  Le multi-processeur/multi-tâches c'est aussi et surtout le credo de FreeBSD puisqu'il se focalise sur les performances.
  Pour DragonFlyBSD je dirais qu'un positionnement clair n'a pas encore emergé (du fait de la jeunesse du projet) mais que, d'après les textes de Matt Dillon, ce serait "la performance et l'innovation mais en gardant le code simple".....autrement dit c'est pas gagné pour s'insérer dans le paysage !
  Au moment du fork j'y croyais pas trop mais finalement le projet avance et y'a du traffic sur les mailing-lists.
# Commentaire supprimé

Posté par Anonyme le 10 janvier 2006 à 18:26. Évalué à 5.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Section de la dépêche
  
  Posté par patrick_g (site web personnel) le 10 janvier 2006 à 18:35. Évalué à 5.
  
  Ben j'ai hésité mais ça aurait été faux de le mettre dans la catégorie FreeBSD et y'avait pas de catégorie DragonFlyBSD...alors j'ai choisi la section noyau.
  C'est pas très important de toute façon.
# Petite Correction TLS

Posté par buju le 10 janvier 2006 à 19:59. Évalué à 10.

TLS ne correspond pas ici à Transport Layer Security mais à Thread Local Storage, c'est à dire la possibilité d'avoir des variables globales mais différentes pour chaque thread.
Description sur wikipedia : http://en.wikipedia.org/wiki/Thread-local_storage
Le paper : http://people.redhat.com/drepper/tls.pdf
- [^] # Re: Petite Correction TLS
  
  Posté par patrick_g (site web personnel) le 11 janvier 2006 à 08:48. Évalué à 4.
  
  Je savais que j'allais faire au moins une connerie malgré les relectures...pfff...et en plus j'ai mis un petit drapeau anglais pour le lien vers fr.wikipedia. Le boulet.
  Merci beaucoup pour cette correction !
  - [^] # Re: Petite Correction TLS
    
    Posté par Nÿco (site web personnel) le 11 janvier 2006 à 11:50. Évalué à 4.
    
    Euh... Patrick... des boulets, y'en a plein qui ont relu avant de modérer... ;-)
    Donc voilà, corrigé le drapeau parceque c'est facile...
    Corrigé l'acronyme de TLS aussi, mais la phrase a-t-elle un sens maintenant ?
    - [^] # Re: Petite Correction TLS
      
      Posté par patrick_g (site web personnel) le 11 janvier 2006 à 12:22. Évalué à 2.
      
      Merci pour les corrections.
      Oui la phrase continue d'avoir un sens (essentiellement parceque je l'ai entièrement pompée sur l'annonce en anglais et que je me suis contenté de traduire : Implement direct TLS support for programs whether threaded or not.).
# Matt Dillon

Posté par mmbpeople le 11 janvier 2006 à 09:44. Évalué à 5.

A ben voila pourquoi on le voit plus au cinéma Matt Dillon ! Il est trop occupé à programmer !
- [^] # Re: Matt Dillon
  
  Posté par reno le 11 janvier 2006 à 09:50. Évalué à 1.
  
  Dans un même ordre d'idée, qu'est-ce qu'il est fort Alan Cox, contribuer à la fois à FreeBSD et à Linux..
# DragonFly_F_BSD ?

Posté par Mathieu Bouju le 11 janvier 2006 à 12:29. Évalué à 1.

C'est une coquille ? j'ai suivi vite fait les liens donnés dans l'article, et je ne retrouve nulle part cette dénomination...
# Multithread

Posté par GuieA_7 (site web personnel) le 11 janvier 2006 à 12:44. Évalué à 2.

Si j'ai bien tout compris (c'est pas gagné :), avec DFBSD tous les threads d'un même processus s'exécutent sur le même CPU. Alors que même la machine de monsieur Tout-le-monde a tendance à devenir multicore/multiproc, n'est ce pas "petit bras" comme façon de faire (je ne dis pas ça méchamment, je suis sûr que les gars de DFBSD sont très compétents) ?
En même temps je ne connais pas le nombre de grosses applis du libre qui sont lourdement multitreadées (du genre des threads à 100 % du CPU pendant plusieurs secondes) et qui seraient donc pénalisées...
- [^] # Re: Multithread
  
  Posté par patrick_g (site web personnel) le 11 janvier 2006 à 14:46. Évalué à 2.
  
  Quand on dit que "tous les threads d'un même processus s'exécutent sur le même CPU" cela signifie qu'ils s'exécutent tous dans le même core. Si t'a un dual-core t'aura un thread dans le core 1 et un autre thread dans le core 2...DFBSD profite donc pleinement des applications multithreadés.
  - [^] # Re: Multithread
    
    Posté par GuieA_7 (site web personnel) le 11 janvier 2006 à 16:04. Évalué à 2.
    
    Heu, il me semble que tu te contredis (mais j'ai pu mal comprendre) : tu dis "tous dans le même core" puis "un thread dans le core 1 et un autre thread dans le core 2".
    Je reste donc sur mon impression de 'tous dans le même core', donc un problème potentiel de perfs avec du multithread (ce qui a entraîné les choix de la branche 5 de FreeBSD).
    - [^] # Re: Multithread
      
      Posté par patrick_g (site web personnel) le 11 janvier 2006 à 16:21. Évalué à 3.
      
      Je suis loin d'être un spécialiste. Je te colle l'extrait de wikipedia :
      
      In DragonFly, threads are locked to CPUs by design, and each processor has its own LWKT scheduler. Threads are never preemptively switched from one processor to another; they are only migrated by the passing of an "Interprocessor Interrupt" (IPI) message between the CPUs involved. Interprocessor thread scheduling is also accomplished by sending asynchronous IPI messages. One advantage to this clean compartmentalization of the threading subsystem is that the processors' on-board caches in SMP systems do not contain duplicated data, allowing for higher performance by giving each processor in the system the ability to use its own cache to store different things to work on.
      
      The LWKT subsystem is being employed to partition work among multiple kernel threads (for example in the networking code; one thread per protocol), reducing contention by removing the need to share certain resources among various kernel tasks. This thread partitioning implementation of CPU localization algorithims is arguably the key differentiating feature of DragonFly's design.
      - [^] # Re: Multithread
        
        Posté par vieuxshell (site web personnel) le 11 janvier 2006 à 19:21. Évalué à 2.
        
        Si j'ai bien compris c'est cette phrase dans la news qui pose probleme:
        
        (les processus sont donc compartimentés dans leur CPU)
        
        Ce qui laisse à penser que tous les threads du processus restent sur le même Core. Du coup ça a peu d'interet pour les applis qui ont générallement 1 processus lancant moultes threads.
        
        Mais au vue de la citation de Wikipedia, il semble que ce soit les threads et non les processus qui soient cantonés à 1 Core.
        
        J'ai bon ?
        
        [^] # Re: Multithread
        
        Posté par patrick_g (site web personnel) le 12 janvier 2006 à 09:35. Évalué à 4.
        
        >> J'ai bon ?
        
        Je sais pas si t'a bon mais ça semble être l'explication la plus cohérente.
# BSD Pour les nuls

Posté par Mais qui suis-je ? :) le 11 janvier 2006 à 15:19. Évalué à 1.

Salut
Histoire de satisfaire ma curiosite
savez vous ou je peux trouver un portrait de famille bsd ecrit en langage humainement comprehensible

Sous entendu pas d'explication technique sur la vie intime du kernell
Mais plutot des resumer disant

tel bsd pour une machine de bureau
tel bsd pour un serveur web
tel bsd pour un serveur de calcul
tel bsd pour un cluster
tel bsd pour ...
etc ...

Puisque les bsd on en parle beacoup mais finalement dans quel domaines c'est interessant et dans quel domaine ca ne l'est pas ?

Merci
- [^] # Re: BSD Pour les nuls
  
  Posté par Sylvain Briole (site web personnel) le 11 janvier 2006 à 16:14. Évalué à 3.
  
  Puisque les bsd on en parle beacoup mais finalement dans quel domaines c'est interessant et dans quel domaine ca ne l'est pas ?
  
  Juste une pierre à l'édifice que d'autres vont construire : j'utilise personnellement NetBSD par rapport à Linux parce que je préfère le système un peu centralisé de développement par rapport au modèle cathédrale de Linux.
  Ainsi, l'évolution d'un noyau NetBSD est relativement lente, et les développeurs réfléchissent à 4 fois avant d'intégrer une fonctionnalité ou un pilote. Les API du noyau évoluent très peu.
  Le revers de la médaille : le "quick & dirty" est, dans les noyaux "stables" (pas la version CVS en développement), peu ou prou présent, alors que c'est parfois le cas dans le noyau Linux. Et même dans les version dites stables (e.g. le coup du
  #ifdef ALPHA
  #define U32 unsigned int
  #else
  #define U32 unsigned long
  #endif
  dans un pilote SCSI du noyau 2.4.9)
  Pour avoir parcouru le code, je le trouve personnellement plus "propre" que celui de Linux (relativement bien commenté, un style d'écriture de bout en bout, ...).
  
  Mais ce modèle de développement a son revers de médaille : la lenteur d'intégration des fonctionnalités fait que certaines choses ne sont pas encore dans le noyau (e.g.: pas de SMP sous NetBSD alors que cela fait des lustres que c'est présent sous Linux!).
  
  Personnellement, si j'utilise encore Linux, c'est parce que j'ai du matériel ou des applications qui ne peuvent pas tourner sous NetBSD, trop méconnu de certains constructeurs ou développeurs.
  
  En gros, pour des applications qu'on a le temps de valider proprement, qui ont un passé connu, NetBSD fait très bien l'affaire, par contre, pour celui qui veut rester à la pointe de la technologie (matérielle/logicielle), Linux s'en sort souvent beaucoup mieux!
  - [^] # Re: BSD Pour les nuls
    
    Posté par agmk le 11 janvier 2006 à 18:18. Évalué à 4.
    
    >je préfère le système un peu centralisé de développement par rapport au modèle cathédrale de Linux.
    
    C'est pas plutôt par rapport au modèle *bazar* de Linux ? Et cathédrale de NetBSD ?
    - [^] # Re: BSD Pour les nuls
      
      Posté par Sylvain Briole (site web personnel) le 11 janvier 2006 à 20:38. Évalué à 3.
      
      Si en effet : mea culpa.

Suivre le flux des commentaires

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