Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».
Ce projet s'annonce donc comme la continuation logique de FreeBSD 4. Il est disponible sous forme de « LiveCD ».
Améliorations techniques
La façon d'implémenter le SMP, et son impact sur l'organisation d'un noyau Unix, constitue une des raisons ayant motivé la création de DragonFly BSD.
Alors que FreeBSD 4 utilisait un seul gros verrou pour empêcher deux tâches d'accéder simultanément au noyau, FreeBSD 5 emploie de nombreux mutex fins pour verrouiller certaines portions de code. Cela pose, aux yeux de Matt Dillon, de nombreux problèmes de complexité, rendant le code difficile à maintenir, et de performance.
À la place, DragonFly utilise un système de serializing tokens ne posant pas ces problèmes, mais surtout un système puissant nommé LWKT.
LWKT
LWKT (Light Weight Kernel Threads), annoncé officiellement sur les listes de diffusion de FreeBSD, constitue un système puissant d'échange de messages entre les threads légers noyau, leur permettant de coopérer efficacement.
Réécriture de la couche VFS
La réécriture de la couche VFS héritée de 4.4BSD est un projet que FreeBSD et DragonFly BSD envisagent tous deux. Dans ce dernier, elle utiliserait alors LWKT, et permettrait d'avoir des systèmes de fichiers en espace utilisateur (« userspace »).
Système de paquets
Les systèmes BSD libres utilisent traditionnellement une hiérarchie de fichiers nécessaires pour compiler une application à partir des sources, nommé « ports » sous FreeBSD et OpenBSD, et « pkgsrc » sous NetBSD et DragonFly BSD[3] — bien que cela soit présenté comme transitoire pour ce dernier. En parallèle, il existe aussi un système de « paquets » pour installer une application à partir de binaires pré-compilés.
Matt Dillon considère que DragonFly BSD, s'adressant à des administrateurs et des utilisateurs n'ayant ni l'utilité, ni le désir de compiler l'ensemble de leurs applications, devra à terme[3] employer principalement un système de « paquets » ne présentant pas les problèmes habituels, tels les conflits de bibliothèques, et les interdépendances complexes, compliquant les mises à jour. Le tout sans omettre la possibilité de compiler à partir des sources pour adapter l'application aux besoins de chacun.
