DragonFly BSD 4.2

La nouvelle version stable du système d'exploitation DragonFly BSD, la 4.2, est sortie aujourd'hui 29 juin 2015. Elle est disponible au téléchargement. De nombreux changements ont été apportés depuis la version 4.0 de novembre dernier, notamment de nombreuses améliorations pour le pilote i915. GCC 5.1.1 fait son apparition dans base, d'importants changements ont lieu dans les pilotes wifi, et la pile audio qui souffrait de plusieurs problèmes a été revue en profondeur.

Merci à tous les contributeurs à cette dépêche et en particulier à François Tigeot et Joris Giovannangeli.

Sommaire

• Noyau
  • Performances
  • Systèmes de fichiers
    • HAMMER
    • HAMMER2
    • tmpfs et ext2
  • Pile graphique
    • i915
    • radeon
  • Pile sonore
  • Pile USB
  • Fiabilité, facilité de maintenance et disponibilité
    • Capteurs de température et compteurs ECC
    • Watchdogs
  • Réseau
    • Protocoles
      • Fonctionnalités
      • Performances et parallélisme
    • Pilotes réseau
    • Nouveau pare-feu : ipfw3
  • Divers
• Espace utilisateur
  • Outils de développement
  • Introduction de sshlockout(8)
  • DMA remplace Sendmail en tant que MTA par défaut
  • Bibliothèque mathématique
  • Symbol versioning
  • Unicode
  • Divers
• Divers
  • Chargeur d'amorçage en couleur
  • /usr intégré dans la racine
  • Slider, un outil pour naviguer dans l'historique de HAMMER
  • Suppression des page info
  • Gestionnaire de service svc
• Notes de mise à jour

Noyau

Performances

Maintenant que la plupart des sous-système importants du noyau peuvent fonctionner en parallèle sans verrous, les performances en charge peuvent être dégradées par des choses apparemment anodines.
C'est le cas du sous-système sysctl, utilisé pour échanger des informations entre le noyau et les applications en espace utilisateur, qui utilisait jusqu'à maintenant un verrou global.
Ce verrou n'est maintenant utilisé plus que pour la création et la suppression de nœuds. L'immense majorité des opérations peuvent désormais se dérouler en parallèle, sans se bloquer.

L'algorithme CRC iscsi a été remplacé par la version rapide de Gary S. Brown, obtenue depuis FreeBSD. Cela devrait permettre d'améliorer grandement les performances du système de fichier HAMMER2.

Une fonction critique du sous-système SCSI, la CAM SWI est maintenant capable de fonctionner sur plusieurs processeurs en parallèle, ce qui devrait améliorer les performances en entrée/sorties lorsque plusieurs disques ou SSD travaillent en même temps.

Le sous-système callout a été réécrit pour fonctionner de manière plus efficace. Cette interface de programmation du noyau permet d'enregistrer des minuteurs associés à une fonction de traitement. Quand le temps demandé est écoulé, la fonction enregistrée est exécutée. Il est désormais plus simple de forcer l’exécution des fonctions sur un CPU particulier. Une API permettant de se saisir automatiquement d'un verrou avant d’exécuter certaines fonctions, à la manière de FreeBSD, a été implémentée. Cette fonctionnalité devrait faciliter le port de pilotes venant du noyau FreeBSD.

L'allocateur mémoire interne du noyau utilise le mécanisme de Slab allocation. Pour les tailles les plus courantes, l'allocation est arrondie à la puissance de 2 supérieure. Au lieu de créer les objets uns à uns, des zones mémoires de tailles fixes pouvant contenir plusieurs objets de tailles très proches sont allouées d'un seul coup, puis remplies selon la demande. Cela permet de réduire la pression sur le sous-système mémoire. La fonction slab_cleanup est chargée de détruire les zones qui ne sont plus utilisées. Elle utilisait jusqu'à présent des listes simplement chaînées. Sur certaines machines comportant une quantité de mémoire importante, supprimer des slabs inutilisés pouvait consommer un temps excessif de processeur. Les listes sont désormais doublement chaînées, ce qui réduit la complexité de l'opération. Ce changement était particulièrement visible sur Monster, une machine de test quadri-Opteron avec 128GB de mémoire et 48 cœurs relativement lents.

Systèmes de fichiers

HAMMER

HAMMER est un système de fichiers déclaré stable pour la production lors de la sortie de DragonFly 2.2 en avril 2009 et utilisé comme système de fichiers par défaut à l'installation avec la sortie de DragonFly 2.4 en septembre 2009. Avec les années, HAMMER a bénéficié de nombreux ajustements, améliorations de performance ou encore de la dé-duplication de données.

Cependant, Matt Dillon, l'auteur de HAMMER, consacre désormais une bonne partie de son temps au développement de HAMMER2, un nouveau système de fichiers qui devrait corriger les quelques défauts de HAMMER ainsi qu'apporter la prise en charge du clustering au niveau du système de fichiers. Une personne non proche du développement de DragonFly pourrait penser que HAMMER ne reçoit désormais plus le soin nécessaire à sa maintenance mais il n'en est rien.

De nouveaux développements mineurs d'HAMMER ont ainsi eu lieu depuis DragonFly 4.0 :

• une commande "hammer abort-cleanup" a été ajoutée ;
• l'export NFS de systèmes de fichiers esclaves a été rendu possible.

L'utilisation d'HAMMER en production sur des serveurs de stockage de plus en plus importants a également permis de corriger des bugs gênants mais qui n'étaient pas visibles sur des machines comportant un nombre de disques modestes.

La bibliothèque libhammer(3), permettant de gérer les fonctions avancées des systèmes de fichier HAMMER, a également fait l'objet de nombreuses corrections de bugs.

Par ailleurs, un nouveau contributeur, Tomohiro Kusumi, a fait son apparition depuis février dernier. Jusqu'à présent il a apporté quasi exclusivement des corrections mineures à ce système de fichier, tout en étudiant en détail son fonctionnement.

Pour la petite histoire, Tomohiro souhaitait initialement faire un portage natif de HAMMER pour Linux (donc sans passer par FUSE) ce qui l'a poussé à regarder le code source et à commencer à soumettre quelque patchs. Le temps passant, il a fini par prendre goût à DragonFly, recevoir un commit bit et abandonner l'idée du port Linux.

De toute façon HAMMER serait très difficile à porter sur une autre plateforme selon Matt Dillon. C'est un des "défauts" que HAMMER2 devrait combler…

HAMMER2

Les personnes qui pourraient penser que HAMMER2 n'est qu'une simple évolution de HAMMER se tromperaient. Ce système de fichiers, toujours en cours d'écriture, est entièrement différent. Alors qu'il est prévu qu'il conserve les fonctionnalités de HAMMER qui lui donnent tout son intérêt (historique fin (paramétrable), snapshoting, gestion multi-volume, mirroring via le réseau, récupération instantanée lors de crashs (fsck(8) n'est pas nécessaire), …), il est également prévu de faire encore un pas en avant.

Matt Dillon a acquis une excellente expérience lors du développement de HAMMER ce qui lui permet aujourd'hui d'identifier les points faibles de son implémentation. Par exemple, les arbres B+ utilisés comme structure de données sur disque et en mémoire sont remplacés par des arbres radix pour HAMMER2. Ce choix permet de réduire la complexité du code et facilite la synchronisation de plusieurs systèmes de fichiers sur le réseau, car les fichiers sont représentés naturellement par un arbre radix.

HAMMER2 est pensé pour fonctionner en multi-maîtres dans le cadre d'un cluster, chaque machine du groupe ayant la même vue du système de fichiers et les opérations effectuées sur n'importe quel nœud étant visibles par les autres.

HAMMER2 est loin d'être fini mais de nombreux progrès ont été faits depuis DragonFly 4.0 :

• la libération d'espace après suppression de fichiers est maintenant fonctionnelle ; par le passé, le système de fichier ne pouvait que se remplir et seule une opération de formatage de type newfs permettait de récupérer l'espace disque ;
• la gestion de disques distants est maintenant opérationnelle ;
• la gestion de messages du cluster est maintenant opérationnelle ;
• du travail a été fait pour la validation de quorum dans le cadre d'un cluster ;
• la gestion de la synchronisation des données et la gestion des erreurs réseau est également en cours de développement ;
• les Pseudo File Systems (PFS) sont maintenant compressés par défaut avec l'algorithme lz4.

Le processus de développement est itératif et des changements de structures de données disque ainsi que du refactoring de certains sous-ensembles du code de HAMMER2 ont lieu en fonction des problèmes rencontrés lors des progrès de l'implémentation.

Le document de référence HAMMER2 a été mis à jour en fonction de ces changements.

tmpfs et ext2

Non content d'avoir amélioré de nombreux détails du code de HAMMER, Tomohiro Kusumi a également commencé à s'attaquer à tmpfs et ext2, apportant de nombreuses corrections de bugs et corrigeant la documentation lorsque cela était nécessaire.
Le pilote de gestion des systèmes de fichier ext2 n'est pas actuellement fonctionnel, mais si Tomohiro continue son travail il sera sans doute bientôt possible de relire de vieux disques durs formatés en ext2fs ou d'utiliser ce système de fichiers pour une partition d'échange entre Linux et DragonFly.

Pile graphique

Le code noyau drm a été partiellement mis à jour vers Linux 3.14 afin d'accompagner l'évolution des pilotes i915 et radeon.

De nombreuses interfaces de programmation et structures de données Linux ont été implémentées afin de faire tourner le code drm et ses pilotes avec aussi peu de modifications que possible. Du point de vue du sous-système graphique, le noyau DragonFly peut ainsi être considéré comme une implémentation sous licence BSD de Linux.

i915

Le pilote drm/i915 a été mis à jour vers la version de Linux 3.14, ce qui apporte notamment une prise en charge des GPU Broadwell (mais sans accélération pour le moment).

• La plupart des chemins de code GEM sont maintenant similaires à ceux de Linux, entraînant une augmentation de la stabilité et des performances. Faire ce changement a été grandement aidé par l'étude du code OpenBSD.
• De nombreuses corrections de bugs ont été apportées. Le pilote est maintenant plus robuste et résiste mieux aux plantages du GPU.
• Les fonctions d'économie d'énergie et de compression du framebuffer sont maintenant activées par défaut (suivant la famille de GPU utilisée).
• La gestion de l'économie d'énergie a par ailleurs été grandement améliorée.
• Les écrans HDMI 4K sont maintenant pris en charge, ainsi que les systèmes d'affichage 3D/stéréo.
• La gestion du modesetting a été améliorée. Il devrait maintenant être possible d'utiliser des systèmes d'affichage utilisant des couleurs 30 bits.
• Le branchement d'écrans à chaud a été amélioré et devrait être plus robuste.
• Outre une prise en charge initiale des GPU Broadwell, de nouveaux membres de la famille Haswell ont été ajoutés
• Le changement de fréquence et l'overclocking ont été grandement améliorés sur les familles de GPU Sandy-Bridge à Haswell
• Le cache géant de 128MB est maintenant activé sur les GPU Haswell qui le possèdent
• Le moteur VECS est maintenant activé sur Haswell. Il est utilisé par libva pour des tâches de post-traitement video.

radeon

Le pilote drm/radeon a été mis à jour vers la version de Linux 3.11. Parmi les diverses améliorations que cela apporte, on peut noter une prise en charge du son via HDMI (fonctionnalité encore expérimentale).
Il est également désormais possible de lire les informations des capteurs de température.

Pile sonore

Le sous-système de gestion du son a été mis à jour vers la pile sonore de FreeBSD 11 (version en cours de développement) datée de janvier 2015.

Cela a permis d'améliorer la prise en charge du matériel récent (en particulier les chipsets Intel depuis la génération de processeurs Ivy-Bridge) et d'apporter la gestion des flux audio sur liens HDMI et DisplayPort.
Il est désormais possible de changer simplement la carte son utilisée par défaut grâce au sysctl(8) hw.snd.default_unit.

L'amélioration la plus visible est que les vidéos HTML5 peuvent maintenant être lues avec du son sans manipulation particulière.

La qualité du son est également améliorée, la nouvelle pile utilisant des algorithmes avancés de conversion et de ré-échantillonnage conçus pour respecter au maximum la fidélité des données.

Plusieurs pilotes aux licences jugées trop restrictives ou nécessitant l'emploi de blobs binaires ont été éliminés. À l'inverse, un nouveau pilote a été ajouté pour gérer le son sur les portables Acer Chromebook de la série C720. Ce pilote n'est pas présent dans FreeBSD.

Pile USB

La pile USB a été mise à jour depuis FreeBSD. La gestion de l'USB 3 est maintenant activée par défaut et les chipsets Wildcat Point gérés.

Les pilotes aue(4), cue(4), ipheth(4), kue(4) et axge(4) pour adaptateurs ethernet USB ont été portés depuis FreeBSD.

Fiabilité, facilité de maintenance et disponibilité

Capteurs de température et compteurs ECC

Les pilotes dimm(4), ecc(4), coretemp(4) et memtemp(4) ont été créés ou mis à jour afin de pouvoir obtenir et traiter les informations concernant l'état du matériel de la part des capteurs inclus dans les cœurs processeur et les barrettes mémoire.

Les informations de température ainsi que le taux d'erreur ecc remontés par les différents composants sont classés en fonction de la topologie matérielle afin de pouvoir identifier facilement les composants problématiques.

Un taux d'erreurs mémoire corrigées acceptable est paramétrable pour le pilote ecc(4). Si ce taux est dépassé, une alerte est générée en utilisant le mécanisme devctl(4).

Les informations des capteurs sont sinon visibles sous les arborescences sysctl hw.sensors et hw.dimminfo comme le montrent ces exemples:

hw.sensors.cpu5.temp0: 44.00 degC (node0 core1 temp), OK
hw.sensors.dimm0.ecc0: 0 (node0 chan0 DIMM0 ecc), OK
$ sysctl hw.dimminfo
hw.dimminfo.dimm0.node: 0
hw.dimminfo.dimm0.chan: 0
hw.dimminfo.dimm0.slot: 0
hw.dimminfo.dimm0.ecc_thresh: 10
hw.dimminfo.dimm1.node: 0
hw.dimminfo.dimm1.chan: 1
hw.dimminfo.dimm1.slot: 0
hw.dimminfo.dimm1.ecc_thresh: 10

Les pilotes ecc(4) et memtemp(4) gèrent les contrôleurs mémoire des familles de processeur Intel Xeon E3, E3v2, E3v3 et Intel Xeon E5v2 et E5v3, ainsi que les processeurs Intel core i3/i5/i7 Haswell.

Watchdogs

Le pilote ichwd(4) a été mis à jour pour gérer les chipsets Intel Coleto Creek (Xeon EP Ivy-Bridge), Lynx Point et Wildcat Point (processeurs utilisant le socket 1150)

Un nouveau pilote ipmi(4) a été ajouté et gère la fonctionnalité watchdog présente dans les systèmes de gestion IPMI.

Réseau

Protocoles

Fonctionnalités

La prise en charge du protocole SCTP (une alternative à UDP et TCP) a été supprimée. Le code datait du début des années 2000 et n'ayant reçu aucune maintenance, il commençait à poser problème pour l'évolution d'autres éléments de la pile réseau.
Le protocole SCTP n'ayant eu aucun utilisateur connu depuis 15 ans, son élimination n'a pas fait l'objet de débat.

La prise en charge des adresses IPV4 sur les sockets IPv6 a été supprimée.
Cela a grandement simplifié le code de gestion des protocoles IPv4 et IPv6 et éliminé de nombreux problèmes potentiels dus à la complexité de gestion de l'ancien système.
OpenBSD avait déjà rejeté la gestion des adresses IPv4 sur sockets IPv6 il y a de nombreuses années, principalement pour des raisons de sécurité.
Un draft IETF du regretté Itojun recommandait déjà de ne pas utiliser ce système depuis presque 12 ans.

Le Maximum Transmission Unit (MTU) est la taille maximale d'un paquet TCP qui peut circuler entre deux hôtes sans qu'il ne soit découpé en paquets plus petits. Pour des raisons de performance, il est souhaitable que les paquets transmis soient le plus proche de la taille maximale supportée par le réseau car fragmenter des paquets réduit les performances. Le Path MTU Discovery permet de vérifier dynamiquement la taille du MTU et de l'ajuster selon les cas pour éviter la fragmentation des paquets TCP par les routeurs. Ce mécanisme est disponible depuis longtemps mais il est maintenant activé par défaut pour le protocole TCP.

Performances et parallélisme

Le code de gestion du réseau dans le noyau a une architecture plutôt inhabituelle. Pour chaque connexion, un hash symétrique est calculé en utilisant l’adresse source et l’adresse de destination. Ce hash permet de décider à quel processeur cette connexion appartient, tous les paquets étant traités par ce processeur, ce qui évite l'utilisation de verrous. Pour l'instant, seuls les protocoles UDP et TCP sur IPV4 utilisaient tous les cœurs.

Le code de gestion du protocole ICMP a été amélioré. En plus d'une amélioration de la vitesse de traitement brut de certains types datagrammes, de nombreuses fonctions sont maintenant capables de fonctionner de manière asynchrone et ne bloquent plus le thread principal de traitement des données réseau. Le code de gestion du protocole ICMP est maintenant capable de fonctionner en parallèle sur plusieurs processeurs.

Du travail a été commencé pour rendre le code de gestion des protocoles IPv6 et ALTQ capable de fonctionner en parallèle sur plusieurs processeurs. Le calcul d'un hash pour IPV6 est plus coûteux et n'était jusqu'à présent pas prioritaire. Toutes les connexions IPV6 sont pour l'instant gérées par le premier cœur mais cet état de fait devrait changer sous peu.

En plus de ces améliorations, de nombreuses corrections de bugs ont également eu lieu dans la pile TCP/IP et dans le code de gestion du protocole NFS.

Pilotes réseau

Le pilote alc(4) a été mis à jour depuis FreeBSD, apportant la gestion des cartes Atheros AR8161, AR8162, AR8171, AR8172 et Killer E2200

Le groupe de pilotes e1000 (em(4), emx et ig_hal) a été synchronisé avec les sources du pilote Intel em-7.4.2, apportant la prise en charge des puces réseau I218V.

Le sous-système wlan(4), ainsi que les pilotes iwn(4) et ath(4) ont été mis à jour depuis FreeBSD, ce qui devrait améliorer la qualité des connexions wifi.

Le pilote de(4) a été mis à jour vers la version FreeBSD r271849, ce qui lui permet de fonctionner maintenant avec plus de 4Go de RAM. Bien que les cartes réseau DEC Tulip soient maintenant extrêmement rares, ce matériel est souvent émulé par des systèmes de gestion de machines virtuelles tels que Qemu.

Nouveau pare-feu : ipfw3

Deux systèmes de parefeu réseau étaient jusqu'à présent disponibles. ipfw(8), mieux connu sous le nom de ipfw2, qui est le pare-feu traditionnel de FreeBSD. Il s'agit d'une réécriture d'un système plus vieux, ipfw, et disponible depuis FreeBSD 5. Plus tard, le pare-feu écrit pour OpenBSD, pf(4) a été adapté sous DragonFlyBSD. Ces deux pare-feux sont toujours disponibles et l'utilisateur peut choisir l'un ou l'autre en fonction de ses préférences.

Un nouveau pare-feu dérivé de ipfw(8) a été implémenté par Bill Yuan. Il a été décidé de le nommer ipfw3 pour éviter toute confusion avec ipfw2, la réécriture de ipfw(8) dans FreeBSD 5.0.

Les outils en espace utilisateur sont rétro-compatibles avec les versions précédentes mais le code noyau a été entièrement réécrit. Le but de cette réécriture est de rendre le code plus extensible et modulaire, ainsi que d'améliorer les performances sur les machines avec plusieurs processeurs. Comme la plupart des pare-feux modernes, ipfw3 est un pare-feu stateful qui conserve l'état des connexions pour éviter d'avoir à ré-évaluer les règles pour tous les paquets d'une même connexion.

Le code est organisés en deux classes de modules :

1. les modules de filtres :

   • le module de base fournit les fonctionnalités courantes d'un pare-feu. Il permet de sélectionner les paquets entrant ou sortant en fonction de leur interface, de leur provenance et de leur destination. Il supporte les tags de paquets, ainsi que des compteurs et la gestion des états de connexion.
   • le module layer2 permet de filtrer selon les adresses MAC source ou destination.
   • le module layer4 ajoute des fonctionnalités spécifiques aux protocoles de la couche application. Il permet de filtrer selon les drapeaux des paquets TCP, ou de l'identité (utilisateur et groupe) du processus possédant le socket de destination. L'utilisateur a aussi la possibilité d'écrire des filtres complexes en utilisant le langage BPF.

2. les modules d'action :

   • le module NAT ajoute le support de la translation d’adresse dans le noyau.
   • le module dummynet permet de spécifier des politiques de qualité de service (QoS), en limitant la bande passante, le nombre de connexions simultanées depuis une même adresse source, ou en utilisant des files à priorité.
   • le module table apporte la possibilité de créer des ensembles d’adresses ou de ports et d'utiliser cet ensemble dans une règle de filtrage à la place d'une adresse unique.
     

Divers

utimensat(2) et futimens(2) ont été ajoutés par Dimitris Papastamos.

L'appel système chflagsat(2) a été ajouté par Joris Giovannangeli.

Tous les pilotes possèdent maintenant une sous-arborescence sysctl(8) du type dev.foo.X. Lorsqu'elle existait, l'ancienne arborescence hw.fooX.y a été supprimée.
Ce changement permet d'obtenir une compatibilité parfaite avec les nouvelles versions de FreeBSD qui utilisent une arborescence sysctl(8) du type dev.foo.X.

L'économie d'énergie a été améliorée sur les systèmes avec processeurs Haswell tournants au ralenti (idle).

Un système de chiffrement automatique du swap a été mis en place, activé par l'option "crypt" de fstab.
Lorsque cette option est activée une clef de 256-bit est générée de manière aléatoire au boot et un périphérique chiffré mappé automatiquement au dessus de la partition de swap traditionnelle.

Le sous-système ACPICA a été mis à jour vers la version 20150515 d'Intel.

Espace utilisateur

Outils de développement

Le compilateur principal a été mis à jour vers la branche de maintenance de GCC 5.1.1 datée du 25 mai 2015. Il bénéficie ainsi de 5 semaines de corrections de bugs depuis la sortie de GCC 5.1 le 22 avril 2015.

Le compilateur secondaire a logiquement été remplacé par l'ancien compilateur principal, GCC 4.7.4 et l'ancien compilateur GCC 4.4 a été supprimé.

Deux nouvelles options ont fait leur apparition dans compilers.conf pour gérer des compilateurs non installés par défaut: clang36 et gcc6-devel.

Binutils 2.25 a remplacé la version 2.24, qui est maintenant fournie en tant que linker secondaire et l'ancienne version 2.22 a été supprimée.

Le groupe d'utilitaires binutils comporte deux linkers: le traditionnel GNU ld, et une nouvelle implémentation, gold (fichier ld.gold). Gold est désactivé car étant écrit en C++, il est beaucoup plus lent à compiler que ld et n'apporte pas d'avantages significatifs en utilisation par rapport à ce dernier.

Introduction de sshlockout(8)

sshlockout(8), un utilitaire permettant de bloquer temporairement le trafic SSH venant sous forme de tentative bruteforce de login, a été ajouté. En cas de tentative de login répétée, notamment avec un utilisateur inconnu du système, une règle est automatiquement ajoutée au firewall afin de bloquer l'IP responsable du trafic. L'utilitaire n'est toutefois pas encore jugé prêt à la production.

DMA remplace Sendmail en tant que MTA par défaut

DragonFly Mail Agent (DMA) remplace Sendmail comme MTA (Mail Transfer Agent) par défaut. DMA est inclus dans base depuis la version… 1.12 de DragonFly (2008) mais pour des raisons inconnues, il n'avait jusqu'alors pas remplacé Sendmail en tant que MTA par défaut. Cela étant désormais fait, Sendmail est retiré du système de base. Une page de wiki à propos de MTA a été écrite afin de guider les utilisateurs désirant malgré tout utiliser Sendmail ou encore ceux désirant un MTA bien plus complet que DMA (Postfix, OpenSMTPD, Sendmail). En effet, DMA est simple de conception et ne vise pas à remplir les fonctionnalités d'un MTA complet. Ainsi, il se contente d'accepter les courriels des MUA (Mails User Agents) locaux et de les délivrer, soit localement mais également à distance. TLS/SSL est pris en charge ainsi que l'authentification SMTP. Cependant, DMA n'écoute pas sur le port 25 pour des connexions entrantes, puisque tel n'est pas son but.

Il est à noter que DMA ne se limite pas à DragonFly BSD. Il est ainsi aussi disponible dans FreeBSD ou différentes distributions GNU/Linux telles Debian ou Mageia par exemple.

Bibliothèque mathématique

La biliothèque mathématique, libm, a été synchronisée avec FreeBSD et NetBSD afin d'ajouter des fonctions manquantes. Bien qu'il s'agissait d'obscures variantes de fonctions existantes, leur absence était gênante car elle empêchait GCC d'activer la prise en charge de la norme C99.

Symbol versioning

Le symbol versioning a été activé sur les bibliothèques z, ncurses, lzma, edit, archive, md et bz2.

Le symbol versioning permet de ne plus avoir à gérer des numéros de bibliothèques différents à chaque changement d'interface binaire.
A chaque fois qu'un changement d'API incompatible a lieu, la trace de l'ancienne interface est gardée dans les sources de la bibliothèque et l'ancienne interface binaire continue à être créée dans les nouvelles versions du fichier libxxx.so.y.

En pratique cela signifie que les anciens programmes binaires vont continuer à fonctionner avec toutes les nouvelles versions de la bibliothèque. Il n'y a plus besoin de partir à la recherche d'une libc.so.4 pour faire tourner un vieux programme sur un système n'ayant qu'une libc.so.6 par exemple.

Unicode

La prise en charge d'unicode a été améliorée dans libedit.
En janvier 2015, Baptiste Daroussin a synchronisé libedit de FreeBSD avec la dernière version de NetBSD. Après cela, il a ajouté des patches pour corriger la lecture de lignes dans un environnement unicode.
Concrètement, cela a permis à sh(1) de fonctionner dans un environnement UTF-8. Merci à Baptiste d'avoir pris le temps d'identifier ces patches pour le bénéfice de DragonFly.

Divers

date(1) bénéficie désormais de l'option -R afin d'afficher en format compatible avec la RFC2822 (qui est l'équivalent de "%a, %d %b %Y %T %z" avec LC_TIME=C).

patch(1) reçoit l'alias --dry-run, équivalent à -C pour une compatibilité accrue avec GNU patch, svn patch et FreeBSD patch.

Le flag -b a été ajouté à camcontrol(8) devlist afin d'afficher les bus existants et leurs sims parents.

tail(1) bénéficie désormais d'une option -q qui permet de supprimer les en-têtes des noms de fichiers.

powerd(8) a reçu de nombreuses corrections et améliorations telles qu'une nouvelle option pour désactiver le mode turbo ou pour contrôler le seuil limite de la charge processeur ou encore l'arrêt d'urgence en cas de charge batterie très faible.

Divers outils ont été mis à jour:

• OpenSSH 6.7p1
• file 5.22
• ftp 1.205 depuis NetBSD
• sh a été synchronisé avec FreeBSD
• mdocml 1.13.1
• byacc 2014-10-06
• less 471
• bmake 2014-11-11
• OpenSSL 1.0.1o

Divers

Chargeur d'amorçage en couleur

La représentation artistique de Fred, la libellule du menu de démarrage, a été améliorée. La ligne entre Fred et le menu a été supprimée et le dessin amélioré. Fred est maintenant affiché en couleur par défaut, avec un thème bleu.

Un système de détection de console série a été ajouté afin de laisser le bootloader en noir et blanc et de ne pas polluer la console avec des codes couleur ansi dans ce cas.

/usr intégré dans la racine

L'installeur ne crée plus de système de fichier /usr séparé.

Utiliser un système de fichier /usr distinct de / n'a plus vraiment de sens à notre époque: les binaires de / et /usr sont tous dynamiquement liés et font tous partie du même système DragonFly de base.

C'est en plus dangereux: avec un système de fichier /usr séparé, les binaires statiques de secours de /usr/share/initrd ne peuvent pas être utilisés sans monter /usr en premier lieu.
Et comme mount(8) est un binaire dynamique, /usr ne pouvait plus être monté dans certaines situations…

Slider, un outil pour naviguer dans l'historique de HAMMER

Slider est un logiciel développé par John Marino. Il dispose d’une interface curses et est écrit en Ada. Sa première version a été annoncée sur la liste de diffusion en décembre.

Slider permet de :

• naviguer parmi toutes les versions disponibles d’un fichier stocké dans l’historique d’HAMMER ;
• de visualiser les différences entre deux versions (si c’est un fichier texte) ;
• de restaurer une ancienne version du fichier ;
• de récupérer un fichier effacé.

S’il est lancé sur un répertoire existant, tous les fichiers supprimés et sous-répertoires restaurables seront recherchés dans l'historique de ce répertoire et il sera possible de les restaurer.

Slider est disponible via dports, avec une documentation.

Suppression des page info

Les outils GNU texinfo ainsi que toutes les pages de documentation au format texinfo ont été supprimées. Ces pages n'étaient disponibles que pour les outils GNU et la majorité des informations est accessible via les pages de manuel.

Gestionnaire de service svc

Un gestionnaire de service, svc(8) a été créé. Il permet de lancer et gérer des services de façon robuste, d'obtenir le statut, loguer les messages récents etc…

svc(8) permet de gérer des listes de groupes, des uid, de construire et faire tourner le programme voulu dans un environnement chroot ou jail. Il permet également de nettoyer les descripteurs de fichier, les sockets et les fichiers pid utilisés lorsque le processus fils prend fin.

svc(8) utilise pour cela le nouvel appel système procctl(), permettant de gérer les sous-processus lancés par un processus donné et de s'assurer qu'ils sont tous tués correctement. Le programme parent se comporte ainsi de la même façon qu'init(8) mais pour un sous-ensemble limité de processus et non pas tous les programmes tournant sur la machine.

procctl(2) a été conçu pour être compatible avec l'appel système de même nom de FreeBSD, en discussion avec des développeurs FreeBSD. Il est prévu que FreeBSD implémente un gestionnaire de service compatible dans l'avenir.

Notes de mise à jour

La mise à jour vers DragonFly BSD 4.2 se fait de la manière habituelle :

cd /usr/src
git fetch origin
git branch DragonFly_RELEASE_4_2 origin/DragonFly_RELEASE_4_2
git checkout DragonFly_RELEASE_4_2
make buildworld && make buildkernel && make installkernel && make installworld

À noter toutefois qu'avec la suppression de sendmail de base, une étape supplémentaire est nécessaire pour configurer le MTA avant de lancer make upgrade. Si aucun MTA avancé n'est nécessaire, ce qui devrait être le cas pour la plupart des utilisateurs, DMA est recommandé et cette commande suffit à la configuration de base:

cp /usr/src/libexec/dma/mailer-conf/mailer.conf.dma /etc/mail/mailer.conf

Suite à quoi, il convient encore de lancer:

make upgrade

et enfin:

reboot

Si le système a redémarré correctement, il est conseillé de faire une sauvegarde de l'initrd de secours via :

make rescue

Aller plus loin

• Site officiel (488 clics)
• Notes de version (118 clics)
• Annonce (22 clics)