François Tigeot a écrit 19 commentaires

Il est possible que le pilote usb pour ce modèle particulier de portable ait un problème, une erreur d'entrée/sortie ce n'est pas anodin.
Le channel IRC ou les mailing-lists du projet devraient te permettre de trouver des gens qui s'y connaissent dans ce genre de problématique si tu es toujours motivé pour utiliser DragonFly sur ce portable un de ces jours.

En premier lieu les performances.

Le pilote nvme DragonFly a été conçu pour fonctionner de manière optimale en environnement multi-processeur/multi-coeur dès le début. Les queues de traitement des requêtes et les interruptions sont réparties de la meilleure manière possible entre les différents processeurs du système, sans intermédiaire. Ceci permet de soutenir un nombre d'entrées/sorties par seconde très important avec une faible latence.

En comparaison, le pilote FreeBSD utilise le sous-système cam(4), qui date d'une autre époque où il était exceptionnel qu'un ordinateur ait plus d'un seul coeur. Le simple fait d'utiliser cette couche intermédiaire aurait empêché d'exploiter à fond les ressources processeur disponibles et aurait limité très fortement les performances maximales possibles.

Un bénéfice secondaire est que le pilote DragonFly contient moins de lignes de code que celui de FreeBSD et qu'il sera sans doute plus facile de le maintenir par la suite.

Si on regarde bien, une grande partie des tests de l'article cité consiste en fait à comparer des compilateurs différents et n'a aucun rapport direct avec les fonctions d'un système d'exploitation.
Je pense que ce qu'on peut reprocher le plus aux benchmarks de Phoronix c'est qu'ils ne correspondent pas du tout à ce qui est annoncé. Cela n'a pas l'air d'être de la mauvaise foi mais plutôt un manque de connaissances techniques et de recul de la part de leur auteur. En gros, Michael Larabel n'a aucune idée de ce qu'il fait vraiment.

L'un des buts du projet DragonFly est d'avoir un système de fichier qui fonctionne en cluster multi-maitre sur plusieurs machines.
Certains choix initiaux de conception de HAMMER ont malheureusement rendu cela impossible et HAMMER est limité à de la réplication à la volée avec un système de fichier maitre et un ou plusieurs esclaves.

Avec l'expérience, Matt Dillon a donc décidé de recommencer l'écriture d'un nouveau système de fichier qui puisse cette fois-ci fonctionner avec du stockage réparti sur plusieurs hotes. A terme, HAMMER2 devrait être à la fois plus simple et plus puissant que HAMMER.

Merci Carl!

DragonFly est tout à fait utilisable sur un portable, je le fais tous les jours.

Les puces graphiques Intel jusqu'à la génération Broadwell fonctionnent presque parfaitement: Le dessin 2D, la vidéo et la 3D bénéficient de l'accélération matérielle.

La gestion de l'énergie s'est énormèment améliorée dans le pilote i915, ce qui fait que sur mon portable Core 2 le simple fait d'activer le mode graphique augmente la durée de vie de la batterie d'un tiers.

Un des grands changements par rapport aux versions 1 et 2 vient aussi de la manière d'installer des logiciels. Maintenant il y a des paquets binaires gérés par pkgng et on peut juste faire pkg install pour installer facilement un programme.
Je pense que d'un point de vue utilisateur les versions récentes de FreeBSD et DragonFly sont maintenant très proches; à mon humble avis, la principale différence se situe maintenant au niveau des systèmes de fichier: ZFS dans un cas, HAMMER de l'autre.

Sur des serveurs, je n'ai eu aucun problème pour faire passer des scientifiques de Debian à DragonFly, une mini formation d'une heure a suffit.

Merci Martin! Je devrais définitivement passer au FOSDEM cette année ;-)

DragonFly utilise exactement le même système de binaires statiques générés par crunchgen(1).

Ils se trouvent dans /usr/share/initrd et aussi dans un ramdisk de secours qui peut être sélectionné lors du boot du système.

Mais ces binaires ne sont là que pour réparer un problème grave et ne sont pas utilisés pour le fonctionnement habituel du système. A part OpenBSD, je ne connais aucun système d'exploitation qui utilise encore des binaires statiques pour son fonctionnement normal en 2015.

Il y a une erreur dans la dépêche ici: ld.gold est bien construit, mais uniquement en phase finale de la construction du système de base.

La construction du système de base par make buildworld se fait en plusieurs étapes, l'une d'elle étant la création d'outils temporaires de cross-développement (étape CTOOLS pour ceux qui veulent regarder le code source).

Cette étape est nécessaire pour obtenir des binaires finaux indépendants de la version de départ des outils de développement utilisés.

C'est uniquement lors de cette étape temporaire que ld.gold n'est pas construit.

Tu ne vas pas pouvoir installer grand chose alors, parce qu'à part OpenBSD je ne connais pas beaucoup d'OS qui fonctionnent encore avec des binaires statiques.

La décision de passer à des binaires dynamiques a été prise pour pouvoir utiliser nss/ldap comme (presque) tout le monde. Contrairement à d'autres projets, DragonFly n'a pas assez de développeurs pour se permettre de réinventer la roue.

DragonFly est utilisable aussi bien en tant que serveur que poste de travail.

Personnellement j'ai une station fixe avec deux écrans, un sur une carte Radeon, l'autre sur le gpu intégré Ivy-Bridge. Il y a Firefox, LibreOffice, des xterms, mplayer pour voir des vidéos, etc…

Pour installer des logiciels, c'est comme sous Debian, à part qu'il faut taper pkg install blah au lieu de apt-get install blah . Le gestionnaire de paquets est l'excellent pkgng
Les paquets tiers sont mis à jour périodiquement mais passent par une étape de validation qui vérifie au minimum que la nouvelle version s'installe proprement. On garde temporairement l'ancienne si ce n'est pas le cas. En moyenne il y a une mise à jour importante des applications tous les un à deux mois.

Pour une utilisation serveur, c'est du bonheur. Les performances du système sont très satisfaisantes et le fait de pouvoir récupérer une ancienne version d'un fichier de configuration depuis un snapshot après avoir fait une mauvaise manipulation m'a sauvé la vie plusieurs fois.

Pour simplifier, UFS et ext2 sont à peu-près équivalent.

HAMMER et ext4 sont tous les deux journalisés et n'ont pas besoin de fsck après un arrêt brutal la comparaison s'arrête là: ext4 reste un système de fichier traditionnel assez basique.

HAMMER de son côté a des propriétés qui le rapprochent des systèmes de gestion de bases de données. Il garde ainsi l'historique des transactions disque: on peut voir l'état du système de fichier à un instant t, récupérer d'anciennes versions de fichiers, etc…
Par défaut, l'historique est consolidé en un snapshot par jour et seuls les 60 snapshots les plus récents sont gardés mais ceci est réglable.

Cette conservation des transactions permet de synchroniser plusieurs systèmes de fichiers entre eux, en maître-esclave. On peut le faire de manière ponctuelle, comme si on envoyait un snapshot zfs, mais aussi de manière continue, en temps réél, le tout à travers un réseau IP si besoin.

Il est possible également de dire à HAMMER de dédupliquer les données qu'il stocke, ce qu'il fait très bien et sans avoir besoin de ressources gigantesques: une machine avec 2Go de mémoire peut convenir.

La page de manuel est très fournie: http://leaf.dragonflybsd.org/cgi/web-man?command=hammer&section=5

UFS n’est pas journalisé sur DFB ?

Non, il est resté essentiellement non modifié depuis FreeBSD 4.

Il me semble avoir lu qu'on peut aussi utiliser UFS, quel est vraiment l'intérêt de HAMMER sur un ordinateur de bureau ?

• Pouvoir gérer un espace disque adapté aux machines actuelles. UFS ne permet pas vraiment de dépasser 1TB; il me semble que la limite théorique est 4TB mais on a des problèmes avant. HAMMER peut gérer 1 exabyte de données sur un seul volume (en gros 1 million de fois plus qu'UFS).
• Les performances. HAMMER traite les données par blocs de taille plus importante qu'UFS et effectue un maximum d'opérations en utilisant la mémoire vive comme cache. Les capacité mémoire des machines des années 80 (UFS date de 1983) ne permettaient pas de mettre en oeuvre les optimisations qu'HAMMER possède aujourd'hui.
• Pas besoin de faire de fsck après un arrêt brutal de la machine, HAMMER est journalisé.
• Vérification de l'intégrité des données par CRC

Il y a un gestionnaire de fenêtre par défaut installé sur Dragonfly-BSD ?

Il y a deux sortes d'images d'installation, dont une avec un environnement graphique mais que je ne trouve pas conviviale du tout (un vieux fvwm avec clavier qwerty codé en dur).

A mon humble avis, il vaut mieux utiliser une image non gui et ensuite installer le gestionnaire de fenêtre ou de bureau de son choix.

Ça doit être difficile de suivre les changements de Linux à ce niveau-là non? Surtout avec les différents systèmes qui ont l’air d’être très bas niveau. Quels sont les différences de performances avec Linux? Est-ce que Wayland tourne sous DragonFlyBSD grâce à ça?

Le gros problème c'est surtout que les piles drm non-Linux n'ont pas vraiment évolué depuis environ 10 ans. Je me trompe sans doute sur certains détails mais j'ai la désagréable impression qu'entre le moment où Eric Anholt est parti chez Intel et le réveil en catastrophe d'il y a un ou deux ans, personne ne s'est vraiment préoccupé des évolutions des drivers graphiques dans les noyaux *BSD.

Je n'ai aucune idée des différences de performance avec Linux; je suis déjà content de pouvoir continuer à afficher des graphiques en 2D sous Xorg. Le pilote i915 est plus rapide que xf86-video-vesa et c'est déjà pas mal.

A ma connaissance, nous n'avons pas encore ce qu'il faut pour faire tourner Wayland. De nombreuses mises à jour au niveau des logiciels utilisateur sont nécessaires, en particulier pour Mesa si je ne me trompes pas.
Il y a une équipe dédiée qui s'occupe de cela chez FreeBSD et qui fait un très bon travail, mais le retard accumulé est de plusieurs années.

Ce «etc», ça représente beaucoup de code? Qu’est-ce que du code concernant les quotes disques fout dans une suite bureautique? Parce que j’ai du mal à voir comment ça pourrait être utilisé… (passé à la trappe dans mon premier commentaire visiblement)

Le code inutile voir purement délirant dans LibreOffice était énorme; le logiciel a été conçu au départ dans les années 1980 et les couches n'ont cessé de s'empiler. Du temps de StarOffice ou OpenOffice, le management du projet avait interdit toute tentative de nettoyage ou ré-écriture et la dette technique ne cessait de s'accumuler.
Michael Meeks, le leader du projet LibreOffice, a donné de très bonne présentations à ce sujet lors des Fosdems 2011 et suivants, et qui doivent toujours être disponibles en vidéo.
Le problème de la gestion de quotas venait apparemment de l'époque où StarOffice essayait de réinventer le bureau Windows 95 (avec menu démarrer, gestionnaire de fichiers, et tout le reste) dans la suite bureautique…

Poudriere, l'outil de création de paquets en parallèle, stresse tellement le système d'exploitation et le matériel qu'on avait presque des kernel panics toutes les cinq minutes au début.

Tu aurais plus de détails sur ça? Je ne savais pas qu’on pouvait faire des kernel panic en poussant la machine à fond.

Afin d'aller le plus vite possible, Poudrière fonctionne par défaut en compilant un projet différent par coeur ou thread cpu disponible, le tout en parallèle.
Ceci fait énormément travailler le système d'exploitation qui doit gérer des milliers d'événements et d'appels systèmes intervenants de manière aléatoire au même moment. Le moindre sous-système qui n'est pas parfaitement verrouillé peut être source de bugs aux conséquences catastrophiques.

Bien que la version DragonFly de l'époque était capables d'obtenir sans problème des uptimes de plusieurs mois avec des charges de travail classique, faire tourner Poudrière a permis de découvrir des bugs qui n'avaient qu'une probabilité infinitésimale de se produire en temps normal.
Pour prendre l'exemple le plus frappant, il y avait une race-condition dans le sous-système tty. Afficher du texte au mauvais moment dans un terminal virtuel ou un xterm pouvait faire planter le noyau. Cela faisait des années que les gens affichaient du texte dans des terminaux et n'avaient jamais eu de problème, mais il était impossible de faire tourner Poudrière plus d'un quart d'heure sans tomber sur ce bug et obtenir un kernel panic.

C'est dommage, l'opinion argumentée d'un développeur *BSD sur systemd est certainement intéressante à connaître.

C'était la question piège et j'ai marché dedans.

Je pense que le reproche principal qu'on peut faire à systemd est que c'est quelque-chose qui s'éloigne complètement de l'esprit Unix:
- petits composants logiciels qui font une seule chose et la font bien
- communication entre ces composants pour obtenir des choses plus complexes
- utilisation de fichiers texte directement lisibles et modifiables par les utilisateurs

Systemd ne se contente pas d'être un remplaçant à init et de gérer le démarrage du système et des divers démons, il vise aussi à remplacer syslog, gérer automatiquement les devices dans /dev, etc…
Qui plus est, il fait cela en remplaçant des fichiers texte par des fichiers binaires qui ont ensuite besoin de programmes spéciaux pour être manipulés.

Fini les commandes tail -f /var/log/messages ou le grep dans maillog. Fini le débugage de scripts de démarrage avec vi. On se retrouve avec une usine à gaz qui met en l'air 30 ans de pratiques industrielles et je ne suis pas sûr qu'on gagne quelque-chose en échange.

J'ajoute quelques points importants pour la route:

• Meilleur support matériel serveur
  C'est stupide, mais une grande partie des distributions Linux est incapable de fournir une liste du matériel supporté. Je m'étais particulièrement pris la tête avec des gens de Redhat pour une histoire de carte RAID par exemple.
  Avec les systèmes *BSD, on a des listes de compatibilité bien précises, comme ici: Contrôleurs disques FreeBSD 9.1

• Stabilité système compatible avec des logiciels à jour
  Le système d'exploitation et les logiciels tiers sont bien séparés. Il est tout a fait possible de mettre à jour les logiciels applicatifs sans devoir tout chambouler dans le système de base.
  Installer et utiliser une version de Dovecot vieille de 15 jours sur un serveur installé il y a 2 ans et n'ayant que des mises à jour de sécurité minimales n'est pas un problème par exemple.

Je ne sais pas ce qui fait que FreeBSD n'a toujours pas redéployé de dépôt au moins semi-officiel, mais il n'y a pas ce problème sous DragonFly, chaque architecture a un peu plus de 20,000 paquets binaires disponibles.

pkg update
pkg install zsh
pkg upgrade
etc…

fonctionnent sans problème.
Rien n'empêche également d'utiliser Poudriere et de se faire ses propres dépôts privés.