DragonFly BSD 4.0

60
26
nov.
2014
DragonFly BSD

Après 3 RC, DragonFly BSD 4.0 a été annoncée par Justin Sherril. Elle est disponible au téléchargement en version finale depuis le 26 novembre 2014. Cette version comprend notamment la prise en charge des GPU de la famille Haswell ainsi que le support d'OpenGL et un nouveau générateur de nombres pseudo-aléatoires pour /dev/random. Plus d'informations se trouvent dans la suite de la dépêche.

dragonflybsd

Sommaire

DragonFly BSD Xfce
DragonFly BSD 4.1 (version de développement) tournant sur un portable Thinkpad T420 avec environnement X et Xfce, via le pilote i915. Hammer est utilisé en tant que système de fichier principal.

Noyau

Ajout de /dev/upmap et /dev/kpmap

Les fichiers spéciaux de périphériques /dev/upmap et /dev/kpmap ont été ajoutés. Ces deux périphériques projetables en mémoire avec mmap(2) permettent d'accéder à un espace mémoire partagé par processus ou global au noyau. L'objectif ici est de permettre l'obtention d'information de manière plus efficace qu'en passant par un appel système plus coûteux. Le fonctionnement est différent de VDSO sous Linux mais le but identique : éviter des appels systèmes. Alors que /dev/upmap est accessible en écriture et permet un mappage par processus utilisateur, /dev/kpmap est en lecture seule et peut être utilisé pour le mappage par CPU au niveau du noyau.

Le but initial était de répondre au même besoin que la fonctionnalité INHERIT_ZERO introduite par OpenBSD pour régler les problèmes liés aux générateurs de nombres pseudo-aléatoires en espace utilisateur. En effet, la bibliothèque de génération de nombres aléatoires conserve une amorce d'entropie dans un tableau, qui est utilisée comme état du générateur. Mais quand le processus forke, il faut réinitialiser cet état en obtenant de l'entropie auprès du noyau pour éviter que les nombres générés par le processus fils soient les mêmes que ceux générés par le processus parent, sinon cela pourrait mener à des failles de sécurité dans les logiciels utilisant le genérateur.

L'idée naïve consiste à conserver le numéro de processus (PID) de la dernière réinitialisation, et d'utiliser getpid() pour détecter un fork. Toutefois, comme les PID peuvent être réutilisés, il existe une petite (mal)chance en cas de double fork pour que le générateur ne soit pas réinitialisé. INHERIT_ZERO permet d'indiquer au noyau que des pages mémoires doivent être remplacées par des zéros lors d'un appel de fork. Mais cette solution n'a pas été jugée satisfaisante car elle introduit de la complexité dans le sous-système de gestion de la mémoire virtuelle pour une utilisation très limitée. À la place, la page umap contient un compteur qui est incrémenté à chaque fois que le processus fork. Ainsi, en comparant la valeur du compteur conservée dans l'état du générateur avec la valeur courante, il est possible de décider s'il faut le réinitialiser.

Ce mécanisme est en outre plus général et les 4 Kio de la page umap sont utilisés pour d'autres données. getpid(2), setproctitle(3) et clock_gettime(2) ont été adaptés pour tirer profit de cette nouveauté. Dans les faits, lorsque plus de 10 appels sont effectués sur l'une de ces fonctions, la prise en charge de upmap/kpmap est activée et les informations demandées sont obtenues via une projection en mémoire plutôt que via des appels système. Cela contribue grandement à réduire l'overhead de ces appels. À noter toutefois que gettimeofday(2) reste quant à lui un appel système, et devrait normalement le rester afin de pouvoir produire une valeur temporelle plus précise. Il est donc préférable, question performance, d'utiliser clock_gettime() plutôt que gettimeofday() lorsqu'un haut niveau de précision n'est pas nécessaire.

Ajout de reapctl(2) procctl(2)

L'appel système reapctl(2) a été ajouté par Matt Dillon, puis finalement renommé en procctl(2), afin de permettre de gérer le processus de contrôle des sous-processus.

Pour comprendre la raison du renommage, un bref historique est nécessaire. Baptiste Daroussin, membre de la core team FreeBSD et peut-être plus connu sous le pseudonyme Bapt (notamment sur LinuxFr.org), ne souhaitant pas réinventer la roue était venu demander sur le canal IRC du projet DragonFly si un équivalent des contrats Solaris existait déjà chez DragonFly. Matt Dillon ne connaissant pas les contrats Solaris, une discussion à la fois technique et sur la raison de la demande s'en est suivie, suite à quoi il proposa d'implémenter tout cela selon la discussion. « Cela me prendra 4 bonnes heures à écrire » avait-il dit, mais voilà que 2 heures plus tard, le code était poussé dans master. Pour la petite histoire, Markus Pfeiffer estimait la charge à environ 2 jours de travail pour lui, alors que Baptiste Daroussin pensait pouvoir implémenter cela en 1 mois ! Pour citer Justin Sherrill, qui s'occupe des versions de DragonFly, « Dillon is a special case : he sneezes and accidentally writes a program », que l'on pourrait traduire par « Dillon est un cas spécial : il éternue et écrit un programme accidentellement ».

Le renommage est donc intervenu par la suite, afin d'harmoniser les API de FreeBSD et DragonFly, alors que Bapt s'occupait d'intégrer cela dans FreeBSD et qu'après discussions avec d'autres développeurs FreeBSD, il a été choisi d’intégrer cela a procctl(2), apparu dans FreeBSD 10 et créé justement afin de fournir un appel système permettant de gérer les processus.

Afin d'expliquer cela, il faut savoir que sous Unix, chaque processus possède un processus père. Quand il se termine, c'est ce processus père qui va examiner son code de retour par une opération nommée reap. C'est le rôle des appels systèmes wait(2), waitpid(2), etc. Si le processus fils est toujours vivant quand le processus père termine, un nouveau père est désigné : il s'agit en général du pid 1, init. C'est ainsi que fonctionnent les démons, qui sont détachés et rattachés à init.

L'appel système procctl(2) permet de désigner le processus courant comme le processus auquel chaque descendant va être réattaché si son parent meurt avant lui. Il fonctionne récursivement, et peut être utilisé par un processus non privilégié. Il est à noter que linux possède déjà une fonctionnalité similaire en utilisant prctl depuis linux 3.4.

À terme, cette fonctionnalité pourra être utilisée pour implémenter un mécanisme similaire aux cgroups utilisés par systemd pour surveiller les démons. Le système d'init pourra lancer un processus de contrôle pour chaque démon (ce qui est très léger en ressources, d'autant plus que le code est partagé en mémoire) et designer ce processus comme le "pid 1" du sous-groupe des processus lancés par le démon. Ainsi, il est impossible que le démon échappe au contrôle d'init ; si le processus de contrôle est tué, tous les fils de celui-ci le seront aussi. De même, si le démon crash, le processus de contrôle sera en mesure de le détecter (avec l'appel système wait(2)) et de relancer le service ou de notifier l'utilisateur. Le travail pour intégrer ces mécanismes avec rcNG est en cours.

L'ajout de procctl(2) permet un début d'implémentation de svc(8), un gestionnaire de service. Celui-ci permettra donc, à terme, de créer, surveiller et gérer un environnement simple et d'exécuter une commande dans cet environnement.

Augmentation de la limite du nombre de CPU

DragonFly prend désormais en charge des systèmes possédant jusqu'à 256 CPU. La précédente limite était de 63 avec DragonFly 3.8. Des tests ont été effectués jusqu’à 255 CPU via QEMU.

Pilotes graphiques

François Tigeot a apporté de nombreuses améliorations à la pile DRM concernant le pilote i915. La plus notable est certainement l'ajout de la gestion des GPU des processeurs de la série Haswell. On note également la prise en charge de kqueue dans /dev/drm suite à un patch de Imre Vadasz qui permet notamment à OpenGL de fonctionner. Il est donc désormais possible de jouer a OpenArena ou encore Supertuxkart!

De nombreuses corrections de bugs ont été apportées au pilote drm/radeon et à son gestionnaire de mémoire ttm.

Le pilote drm/i915 est maintenant basé sur l'implémentation de Linux 3.8.13 et non plus celle de FreeBSD. De nombreuses interfaces de programmation et structures de données Linux ont été implémentées dans le noyau DragonFly afin de pouvoir réutiliser sans modification le plus de code possible du pilote i915 Linux.

Les pilotes drm suivants ont été supprimés : mach64, mga, r128, savage, sis et tdfx. Ils servaient à accélérer certaines opérations OpenGL sur d'anciens GPU datant des années 1990 à début 2000. La bibliothèque Mesa ayant abandonné leur prise en charge en 2011, ces pilotes n'avaient plus d'utilité.

Réseau

Sepherosa Ziehau a écrit un outil permettant de tester le taux de requêtes/réponse UDP. Parmi les conséquences directes, les améliorations de performances concernant UDP. À titre d'exemple, une augmentation de performance d'environ 19 % a été observée pour des requêtes et réponses UDP de 18 octets avec un Intel Core i7-3770 et une carte 10 Gigabit/s Ethernet Intel 82599ES (1,34 millions de transactions par seconde, contre 1,12 millions sans le patch).

Par ailleurs, le pilote urndis(4) a été importé depuis FreeBSD. Il permet de bénéficier de l'USB tethering ; cela signifie donc qu'un appareil disposant du partage de connexion via USB, tel un smartphone sous Android par exemple, peut être utilisé comme une carte réseau.

Le pilote if_lagg(4) a été porté depuis FreeBSD. Il permet notamment d’agréger plusieurs interfaces réseau sous la forme d'une seule interface en fournissant un mécanisme de répartition de charge entre les différents membres du groupe, ou d'avoir une interface maîtresse et des interfaces de secours qui seront utilisées automatiquement en cas de problème sur l'interface active. Il contient aussi une mise en œuvre du protocole IEEE 802.3ad (LACP), qui permet d'utiliser les mécanismes précédemment décrits en coopération avec des interfaces distantes, comme par exemple un commutateur.

Packet Filter (pf)

La majeure partie du pare-feu Packet Filter peut désormais opérer de manière parallèle.

Pilotes RAID

Le pilote mrsas(4) a été ajouté. Il permet la prise en charge des cartes RAID LSI Thunderbolt et de modèles plus récents (Invader et Fury).

Crypto

Alex Hornung a ajouté l'algorithme ChaCha, une variante améliorée du chiffrement de flux Salsa20, utilisé notamment pour BLAKE, l'un des cinq finalistes du concours du NIST pour élire l'algorithme SHA-3. ChaCha a été ajouté dans le but d'être utilisé pour le nouveau générateur de nombres pseudo-aléatoires (CSPRNG) basé sur Fortuna.
Un nouveau paramètre sysctl a d'ailleurs été ajouté afin de pouvoir choisir le générateur utilisé pour /dev/random. 3 modes sont ainsi possibles :

  1. csprng, afin d'utiliser Fortuna ;
  2. ibaa, pour utiliser l'ancien générateur IBAA ;
  3. mixed, valeur par défaut, où les sorties des deux générateurs sont agrégées (par un XOR).

Espace utilisateur

Mises à jour diverses

Plusieurs outils ont été mis à jour dans le système de base :

Ajout de rcreload

Zachary Crownover a ajouté rcreload à rcrun(8), ce qui permet de recharger la configuration d'un démon sans le redémarrer.

Import de service(8)

Depuis la première version de DragonFly, rcrun(8) est utilisé afin de gérer les scripts rc. Cependant, service(8) a été importé depuis FreeBSD, afin que les administrateurs système habitués à cet outil répandu le retrouvent également sur DragonFly.

Divers

Abandon de i386

Comme annoncé lors de la sortie de la précédente version, il n'existe désormais plus de version 32 bits de DragonFly BSD. Cela signifie qu'aucune image 32 bits n'est désormais générée et qu'aucun effort ne sera fait pour maintenir les anciennes fonctionnalités ou rendre compatibles les nouvelles fonctionnalités avec l'architecture i386. Pour rappel, plus aucun paquet binaire n'était créé pour l'architecture i386 depuis DragonFly BSD 3.8 et celle-ci ne bénéficiait déjà plus de certaines fonctionnalités présentes dans la version 64 bits, notamment en ce qui concerne la gestion de la mémoire pour les pilotes graphiques.

GNOME 3.x et Cinnamon débarquent

Les paquets pour les environnements de bureau GNOME 3.14 et Cinnamon 2.2 sont arrivés dans les dépôts. John Marino a en effet pu faire les ajustements nécessaires afin que ces environnements compilent. Pour rappel, Gnome 2 n'avait jamais compilé dans son intégralité sur DragonFly. En revanche, il reste certainement pas mal de boulot pour que ces environnements de bureaux soient pleinement utilisables. À noter que ces changements suivent ceux survenus dans les ports FreeBSD puisque les dports de DragonFly en dérivent.

Xfce et mate restent, et certainement pour un moment encore, les DE à privilégier pour une bonne expérience utilisateur.

Rust porté sous DragonFly BSD

Le langage de programmation Rust a été porté sous DragonFly BSD par Michael Neumann. Il détaille dans un article de blog le procédé qu'il a utilisé. Ce travail pourrait, selon lui, être intéressant afin de porter Rust vers d'autres BSD, notamment OpenBSD et NetBSD (Rust est déjà disponible pour FreeBSD). La difficulté du portage vient du fait que le compilateur Rust est écrit en… Rust et qu'il faut donc par conséquent passer par quelques étapes de cross-compilation depuis un système disposant déjà de Rust (Michael Neumann a utilisé Linux).

FreePascal est désormais disponible

On aurait tendance à croire que le langage Pascal, apparu pour la première fois en 1970 et mis au point par Niklaus Wirth, est devenu une relique du passé. Pourtant, un utilisateur de DragonFly semblait avoir désespérément besoin d'un compilateur pour ce langage. John Marino a réussi à porter le compilateur FreePascal sur DragonFly. Cela permet donc aux ports dépendants du compilateur fpc d'être finalement disponibles.

DragonFly se prépare a clang

DragonFly intègre deux compilateurs dans base. Pour le moment, les deux compilateurs sont GCC 4.4 et 4.7. GCC 4.4 n'étant plus vraiment utile, il est prévu de le remplacer par clang, probablement en version 3.5, pour la prochaine version de DragonFly. John Marino et Matt Dillon ont donc commencé un travail dans ce sens, afin de s'assurer que world et kernel compilent sans histoires avec clang.

Notes de mise à jour

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

cd /usr/src
git fetch origin
git branch DragonFly_RELEASE_4_0 origin/DragonFly_RELEASE_4_0
git checkout DragonFly_RELEASE_4_0
make buildworld && make buildkernel && make installkernel && make installworld && make upgrade
reboot

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

make rescue

Cette dernière étape était auparavant réalisée lors de make installworld, mais cela pouvant poser des problèmes avec le chargement du module noyau vn, cette étape a été dissociée et le module vn est désormais inclus dans le noyau.

  • # Merci pour cette dépêche !

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

    Bravo pour cette dépêche riche en explications ! Ça rappelle les annonces du noyau Linux qui sont très agréables à lire.

  • # Contrats Solaris

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

    Matt Dillon ne connaissant pas les contrats Solaris

    Et alors, au final, c'est quoi les contrats Solaris ? C'est juste un appel reapctl ou il y a plus ?

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Hammer

    Posté par . Évalué à 1.

    N'étant pas très au goût du jour sur ce domaine et n'ayant pas trouvé d'informations claires sur ce sujet, quelqu'un de compétent pourrait-t-il donner plus d'informations sur comment se comparent Hammer, UFS et ext4 ?

    • [^] # Re: Hammer

      Posté par . Évalué à 3.

      Tu as de la doc’ sur HAMMER ici (ça parle aussi de HAMMER 2 qui est en chemin)

      Pour la comparaison, je laisse ça à d‘autres.

    • [^] # Re: Hammer

      Posté par . Évalué à 9.

      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

      • [^] # Re: Hammer

        Posté par . Évalué à 4.

        Si je me rappelle bien, HAMMER a un design plus proche de btrfs, ou même ZFS de mon point de vue a 10000m de haut. Maintenant ces systèmes de fichiers ont des détails d’implémentation différents: comment sont stockées les inodes, etc.
        Il me semble que c'est un B-Tree (voire un B+-Tree?) avec du Copy-On-Write. Je ne suis pas un expert de l'algorithmique des bases de données, alors ce que je dis est a prendre avec des pincettes.

        Il est donc très bon pour la concurrence d’accès: readers et writers ne se marchent pas sur les pieds.
        Il permet des fonctionnalités très synaptiques comme les snapshots a chaud, etc.

    • [^] # Re: Hammer

      Posté par (page perso) . Évalué à 6. Dernière modification le 27/11/14 à 13:17.

      C'est difficile de comparer ces trois là en particulier car ils sont très différents. Hammer est plutôt à rapprocher de btrfs ou zfs bien qu'il soit quand même très différent sur plusieurs points. Pour UFS, ça dépend encore de quelle version tu veux parler. Sur DragonFly par exemple, UFS n'est pas journalisé (et il n'est en général utilisé que pour /boot, hammer ne pouvant pas remplir ce rôle (ça sera corrigé avec hammer2)).
      Il n'y a pas des points un peu plus précis que tu voudrais savoir en particulier?

      EDIT: bon, d'autres ont été plus rapides que moi à répondre ^

  • # 2h???

    Posté par . Évalué à 2.

    « Cela me prendra 4 bonnes heures à écrire » avait-il dit, mais voilà que 2 heures plus tard, le code était poussé dans master. Pour la petite histoire, Markus Pfeiffer estimait la charge à environ 2 jours de travail pour lui, alors que Baptiste Daroussin pensait pouvoir implémenter cela en 1 mois !

    Il n'y a que moi que cela choque?

    Il est toujours difficile d'estimer le travail à faire. Mais entre 1 mois et 2j, ça sent l'enfumage quand même quelque part.

    Ensuite, je veux bien croire que Dillon bosse vite, mais faire tout en 2h alors qu'on a estimé 2j il y a pas un problème? C'est juste un proof of concept (preuve de concept) codée à l'arrache sur un coin de table?

    • [^] # Re: 2h???

      Posté par . Évalué à 4.

      Il a éternué, cela peut arriver à tout le monde : )

    • [^] # Re: 2h???

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

      mon 1 mois c'était une manière de dire je n'ai aucune idée de combien de temps ça me prendrai vue que je n'ai jamais touché à cette partie du kernel, et que introduire une regression là dedans ça fait mal.

      Pour info pour avoir un truc qui fait la même chose il m'a au final fallu 3 ou 4 jours (tests compris) :) (mais la version finale dans freebsd ne sera pas la mienne un autre dev a pondu beaucoup mieux.)

      Après évalué le temps sur passé sur quelque choses alors que l'on ne bosse pas dessus a plein temps c'est dur, les 3 ou 4 jours ce résume je pense au finale a quelques heures :)

      • [^] # Re: 2h???

        Posté par . Évalué à 4.

        Après, évaluer le temps à passer sur quelque choses alors que l'on ne bosse pas dessus a plein temps: c'est dur

        OK. J'ai mal vu, et je croyais qu'il s'agissait de 3 devs kernels DragonFly qui parlaient estimation. Donc je comprends mieux le 1 mois du coup :)
        Et effectivement, celui qui est dedans tout le temps comme Dillon, peux coder en 2h (enfin faut être doué quand même) un truc qui prendrait 2j à un autre.

      • [^] # Re: 2h???

        Posté par . Évalué à 1.

        L'appel système reapctl(2) a été ajouté par Matt Dillon, puis finalement renommé en procctl(2), afin de permettre de gérer le processus de contrôle des sous-processus.

        Ah ! Je comprends mieux maintenant ;-)

  • # mmhhh comme cela semble tentant

    Posté par . Évalué à 1.

    Juste pour dire que j'ai trouvé ce petit imprimé écran vachement jolie, que j'aurais presque envie d'y passer, mais que je me pose une question à la lecture de la commande d'update,

    n'est ce pas encore un peu root pour le tout venant ?

    • [^] # Re: mmhhh comme cela semble tentant

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

      Juste pour préciser: il n'y a pas d'environnement GUI par défaut (l'image ne se fait plus), donc ici il s'agit d'une configuration utilisateur.
      Le thème GTK est Numix Holo, icônes Vibrancy-Dark-Aqua et Numix Holo également pour le thème du gestionnaire de fenêtre au cas où. ;)

      n'est ce pas encore un peu root pour le tout venant ?

      Je ne suis pas certain de comprendre ce que tu veux dire par là. Les mise-à-jour se font en root, oui. Si c'est de l'expérience "desktop" que tu veux parler, disons que Linux est encore loin devant. Il n'y a pas de gestion de la mise en veille par exemple et les touchpads synaptics sont en général vu comme des souris (pas de scroll par exemple) et ça ce sont des choses qui manquent cruellement sur les portables. En revanche, sur un ordinateur fixe ce n'est pas vraiment bloquant et l'expérience utilisateur commence à devenir intéressante, à condition d'avoir un GPU Intel ou AMD supporté (pour nvidia c'est mort tant que nouveau n'aura pas été porté).

    • [^] # Re: mmhhh comme cela semble tentant

      Posté par . Évalué à 6.

      C'est vrai que c'est un peu root pour le tout venant, installer dfly sur un desktop ça marche, de mieux en mieux, mais c'est quand même loin d'un ubuntu. Et ça marchera plus ou moins bien selon ton matos. Pour ce qui est de l'upgrade, faut dire que tu dois faire ça au plus 2 ou 3 fois par an. Et il y a moyen de bricoler sans compiler à la main, en téléchargant une .img et en copiant les fichiers sur ton disque dur.

      Si tu es intéressé par l'installation de xfce sur dfly, j'ai écrit un journal à ce sujet :

      http://linuxfr.org/users/enj0lras/journaux/installe-une-libellule-dans-ton-bureau

  • # allez courage

    Posté par (page perso) . Évalué à -1.

    En lisant les modifications j'ai l'impression de voire linux en retournant 10 ans en arrière,
    (tuxracer …)
    mais bon ça fait plaisir de voire que ça bouge, et si le pinguin continue ses conneries d'évolutions trop "propriétaires", il va falloir que j'essaie ça !

    petites questions en passant :
    quel est l'usage principal de DragonFly ? on l'utilise plutôt sur un serveur, pour un PC ?,
    est-ce que les navigateurs type firefox y sont mis à jour rapidement ?,
    et enfin, est-ce qu'il y a un système de gestion de paquet avec dépendances ? (type deb/rpm), la dernière fois j'ai testé, ce n'était pas encore le cas…

    • [^] # Re: allez courage

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

      quel est l'usage principal de DragonFly ? on l'utilise plutôt sur un serveur, pour un PC ?

      En tant que serveur. Ce n'est que récemment que les choses s'améliorent grandement pour ce qui est d'une utilisation desktop/laptop.

      est-ce que les navigateurs type firefox y sont mis à jour rapidement ?

      Oui. En revanche, Chromium ne fonctionne pas sous DragonFly (et j'entends dire qu'il pourrait même disparaitre de FreeBSD, upstream n'acceptant pas les patches nécessaires à FreeBSD et cela devient impossible à maintenir au point que le mainteneur serait prêt à jeter l'éponge). En fait, DragonFly utilise les dports, qui sont un overlay sur les ports FreeBSD (en gros, il s'agit de la collection de ports FreeBSD - les ports qui ne build pas sous DragonFly + des patches si nécessaires). Et du coup, cela amène à ta question suivante:

      est-ce qu'il y a un système de gestion de paquet avec dépendances ? (type deb/rpm)

      Oui. Au même titre que FreeBSD, pkg(8) est utilisé. pkg(8) fait tout ce que tu attends d'un gestionnaire de paquets moderne, eg: pkg upgrade, pkg install, pkg delete, pkg autoremove, pkg search, pkg info et même pkg audit si tu veux vérifier que tu n'utilises pas de paquets vulnérables. Tu devrais devoir trouver toutes les informations nécessaires en faisant une brève recherche. Pour info, à ce jour, il y a 21747 dports disponibles (c'est pkg stats qui me le dit).

    • [^] # Re: allez courage

      Posté par . Évalué à 6.

      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.

Suivre le flux des commentaires

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