DragonFly BSD 3.6

Posté par . Édité par Rolinh, François Tigeot, Nils Ratusznik, Benoît Sibaud, Jiehong, Loïc Blot et antistress. Modéré par ZeroHeure. Licence CC by-sa
Tags :
54
3
déc.
2013
DragonFly BSD

La version 3.6 du système d'exploitation DragonFly BSD est désormais disponible, apportant notamment une amélioration considérable des performances pour les machines SMP. Les détails concernant cette version se trouvent dans la suite de la dépêche.

Sommaire

La liste des changements dans la suite de la dépêche n'est pas exhaustive mais essaye de donner un bon aperçu des développements qui ont eu lieu durant le dernier cycle. Pour la liste complète, allez voir les commits des tags 3.6.0rc et 3.6.0.

Noyau

Réseau

DragonFly 3.6 bénéficie d'un gros travail de la part de Sepherosa Ziehau sur les pilotes Ethernet pour le support des interruptions MSI-X et des queues multiples. Le simple fait de permettre au pilote mxge pour les adaptateurs Ethernet 10 Gigabit Myricom d'en bénéficier a fait augmenter ses performances en transmission de 150Mbps.

Les performances des appels non bloquants à connect() pour les connections tcp ont été améliorées. Le gain mesuré est de 16%.

SO_REUSPORT fait maintenant de la répartition de charge comme sous Linux et permet de distribuer la réception de données sur plusieurs sockets pouvant tourner chacun sur des threads différents. Nginx a été patché dans dports pour prendre en compte ce mécanisme et les premières mesures font apparaître une amélioration des performances de 33%.

Autres changements dans les pilotes Ethernet:

  • ajout du support des cartes Ethernet 10Gb/s Emulex OneConnect ;
  • mise à jour des pilotes Ethernet igb(4) et em(4) ;
  • activation de la fonctionnalité TSO pour les chipsets en PCI-Express gérés par le pilote em(4) ;
  • ajout du support de nombreux nouveaux chipsets realteks dans le pilote re(4).

On devrait aussi remarquer une amélioration de la stabilité et des performances de la table de routage sous des charges extrêmement élevées.

Vkernel

DragonFly possède un système de noyau virtuel nommé vkernel. Dans l'idée, le concept est plus ou moins similaire au UML (User Mode Linux) de Linux. Il s'agit donc d'un mécanisme de virtualisation permettant de faire tourner un noyau DragonFly en espace utilisateur. Ce système est très utile pour le développement du noyau puisqu'il permet de ne pas avoir à redémarrer la machine pour tester les changements apportés. Si vous voulez en savoir plus, je vous conseille de lire cet article qui est excellent bien que relativement daté.

Les vkernels bénéficient maintenant d'une accélération matérielle sur les processeurs Intel comportant la technologie de virtualisation EPT (Extended Page Tables). Ce travail a été principalement réalisé par Mihai Carabas dans le cadre d'un projet Google Summer of Code. Mihai avait déjà implémenté la détection des topologies coeurs/socket/threads pour les machines NUMA et SMP modernes l'an dernier. Des informations plus détaillées sont visibles dans le message de commit Vkernel/VMM.

DIRFS a été ajouté. Il s'agit d'un pseudo-système de fichiers spécifique aux vkernels qui permet de monter les dossiers de l'hôte directement dans le vkernel.

Améliorations SMP

L'utilisation de monster (un serveur AMD Opteron avec 48 cœurs) pour la compilation des paquets a permis d'améliorer la situation concernant les contentions pour les machines SMP. Pour citer Matt Dillon :

The jist of this work is that there is no longer virtually any
contention for most process-related activities, including heavy use
of fork and fork/exec in 'make', '/bin/sh', and other utilities.
Anything which forks and/or execs a lot (scripts, bulk builds, service
daemons, etc) will now run as close to optimally as it is possible to
run on a multi-core box.

In particular with the last change to the namecache code, our bulk
ports builds look pretty insane on monster (our 48-core opteron box).
Now during a bulk dports build, the load can pop up to 300 with concurrent
compiles and of that 300 there will be 295 non-contending "R"un state
processes and only 5 contending "D" state processes. And it all happens
with virtually NO IPI traffic between cpus.

I consider this a fairly major milestone for the project. We aren't
finished, but this is a major leap in our ability to fully utilize the
resources on larger multi-core systems.

En voici une traduction approximative :

Ces modifications suppriment presque tous les points de contention pour les opérations liées aux processus, notamment l'usage important de fork et de fork/exec dans 'make' et '/bin/sh', ainsi que dans d'autres outils.
Tout ce qui utilise un grand nombre de forks et/ou d'execs (les scripts, la compilation d'un grand nombre de paquets, les daemons, etc) s'exécute maintenant de la manière la plus optimale possible sur une machine à plusieurs cœurs.

En particulier, grâce au dernier changement dans le code du cache des noms de fichiers, la compilation de l'ensemble des ports est vraiment impressionnante sur monster (notre machine 48 cœurs à base de processeurs opteron). Désormais, durant une compilation, la charge peut culminer à 300 avec des compilations concurrentes, et parmi ces 300 processus, il y a 295 processus à l'état "R" (running) sans contention, et simplement 5 processus bloqués sur un point de contention à l'état "D". Et tout cela avec quasiment aucun traffic d'IPI entre les cpus.

Je considère cela comme une étape assez importante du projet. Nous n'avons pas fini, mais c'est un progrès majeur vers notre objectif d'utiliser entièrement les ressources des plus gros systèmes multi-cœurs.

Pour les détails, référez-vous aux messages de Matt Dillon sur la liste de diffusion ici et .

Vidéo

Le sous-système drm du noyau a été mis à jour et comporte maintenant des pilotes i915/kms et radeon/kms ainsi que leurs gestionnaires mémoire associés. Il est désormais possible d'utiliser directement une grande partie des chipsets graphiques intégrés Intel avec Xorg à condition que l'on utilise un système DragonFly 64-bit. Ceci a été rendu en grande partie possible par le travail réalisé par les dévelopeurs FreeBSD sur ces pilotes. Le code a été également amélioré grâce à l'import de routines OpenBSD et une synchronisation partielle avec l'implémentation drm de Linux 3.8.

Le support radeon/kms est considéré encore trop jeune pour être activé par défaut dans les pilotes Xorg. Il faut installer à la main une version plus récente de xf86-video-ati pour l'utiliser.

liens

i915 drm avec kms :

Import du gestionnaire de mémoire ttm : http://lists.dragonflybsd.org/pipermail/commits/2013-August/130607.html.

Import du pilote radeon KMS depuis FreeBSD : http://lists.dragonflybsd.org/pipermail/commits/2013-October/198282.html.

Mémoire

Quelques changements ont eu lieu dans la collecte des statistiques d'utilisation de la mémoire. De plus, les erreurs ECC remontées par le contrôleur mémoire des processeurs Xeon E3 Ivy-Bridge et Haswell sont désormais gérées par le noyau.

Hammer2

Le développement du nouveau système de fichier Hammer2 se poursuit, essentiellement effectué par Matt Dillon. Le code de dé-allocation des blocs inutilisés n'est toujours pas présent, ce qui empêche toute utilisation réelle du FS. Hammer2 continue cependant à être stabilisé et depuis le mois de novembre, il peut survivre à la compilation de l'ensemble des ports avec poudrière.

Lors du Google Summer Of Code, la prise en charge de la compression à la volée des fichiers a été ajoutée. Les algorithmes ZLIB et LZ4 sont gérés, et la prise en charge de la compression peut être configurée par PFS (pseudo filesystem). Quelques tests ont été conduits et ont permis de mettre en évidence que la compression a un coût acceptable, et parfois peut augmenter les perfomances, non seulement en lecture mais aussi en écriture.

Hammer2 peut maintenant être utilisé pour le boot, ce que ne permettait pas Hammer.

Divers

Si vous utilisez DragonFlyBSD sur une machine à processeur Cyrix, attention : certaines options spécifiques à ces puces ont été retirées. On notera aussi la présence d'un nouveau timer, plus de précisions ici et .

Le code flush/sync du système de fichiers a été amélioré, encore une fois pour améliorer le passage à l'échelle. Au lieu de parcourir la liste de tous les vnodes, la structure de données représentant un "fichier" dans le noyau pour trouver ceux qui nécessitent un flush vers le disque, le code maintient une liste des vnodes dans l'état "dirty", c'est-à-dire ceux qui doivent être synchronisés avec le disque. Sachant que le nombre de vnodes peut atteindre plusieurs millions sur un gros système, cette modification améliore grandement les performances de sync.

USB

La nouvelle pile USB importée de FreeBSD continue à recevoir des améliorations. Toutefois, elle n'est toujours pas compilée par défaut car l'utilisation d'USB 3 n'est pas encore entièrement stabilisée.

Espace utilisateur

Synchronisation de code avec divers BSD

Import de mdocml

mdocml a été importé. Il s'agit d'une alternative à groff pour l'affichage des pages de manuel au format mdoc. Une fois que la majorité des erreurs de rendu auront été corrigées, il est prévu de remplacer GNU man(1) par le nouvel outil man(1) qui utilise mdocml au lieu de groff. À noter que les changements sur man apportés par DragonFly ont rapidement été adoptés par l'équipe de NetBSD. D'autres changements ont également été importés en retour dans OpenBSD. mdocml a également été intégré dans les sources de FreeBSD 10. Il est intéressant de voir que cet outil se trouve dans tous les principaux systèmes *BSD et que leurs équipes de développement collaborent en allant dans la même direction.

Synchronisation de locale/libiconv avec FreeBSD

Le support des locales dans la libc et de libiconv a été grandement amélioré. Le code actuel était un mélange de code venant de NetBSD et de code venant de FreeBSD. Une grande partie de la libc a été synchronisée avec FreeBSD, et le support des locales est désormais basé sur le code de FreeBSD. Par la même occasion, le support des wide chars a été amélioré. Libiconv fournit une interface à jour, ce qui permet d'activer un meilleur support de la localisation dans les logiciels tiers fournis par dports.

Ajout de la commande poweroff

La commande poweroff(8), qui n'était pas présente dans DragonFly mais présente depuis près de trois ans chez FreeBSD et bien connue dans le monde Linux, a été adoptée depuis les sources de FreeBSD. Il s'agit d'un équivalent à shutdown -p now ou halt -p.

Mise à jour de libedit

Libedit, une bibliothèque de gestion d’édition d'une ligne de commande similaire à GNU readline sous licence BSD a été mise à jour en version 2012-12-13.

Mise à jour de logiciels tiers

Mise à jour de less

less a été mis à jour vers la version 458, apportant son lot de corrections et de nouvelles fonctionnalités par rapport à la version 444 anciennement présente.

Mise à jour de gdb et kgdb

La version de gdb et kgdb inclue dans base a été mise à jour en version 7.6.1. En particulier, cela améliore un peu le débogage de vkernel.

Améliorations de systat

systat a vu l'ajout des options -netbw et -pftop.

Améliorations de df

L'outil df, bien connu des administrateurs systèmes, a vu l'ajout de l'option -T qui permet d'afficher les types de systèmes de fichiers associés aux partitions listées. De plus, df affiche maintenant les inodes de manière "human-readable" lorsque les options -h et -i sont utilisées conjointement.

Amélioration de killall

killall bénéficie désormais de l'option -T. Cette option tue tous les processus générés par le TTY appelant à l'exception du processus parent de killall. Ceci permet donc de tuer tous les processus du TTY courant sans tuer le shell courant.

Amélioration de dmesg

L'option -f permet désormais de récupérer les messages du noyau en continu

Dports et pkgng

Les dports sont maintenant compilés avec gcc 4.7 au lieu de gcc 4.4. La prochaine version de DragonFly abandonnera vraisemblablement ce dernier au profit de clang puisqu'à partir de la version 10.0 de FreeBSD les ports seront compilés avec, les dports étant issus de ces derniers.

Pour rappel, DragonFly 3.4 a introduit pkgng comme alternative à pkgsrc. Suite à l'enthousiasme des utilisateurs envers pkgng (en mai dernier, 98.55% des téléchargements de paquets concernaient les versions pkgng/dports) et les excellents résultats obtenus via l'import des ports FreeBSD, ce dernier est désormais officiellement adopté au dépend de pkgsrc, l'équipe n'ayant ni les ressources humaines ni matérielles pour maintenir les deux en parallèle. Par conséquent, si vous utilisez encore pkgsrc, il faudra obligatoirement migrer vers pkgng après une mise à jour depuis la 3.4.

On peut remarquer au passage que DragonFly a eu des dépôts de paquets pkgng officiels bien avant FreeBSD. Les dépôts de FreeBSD ne sont arrivés que fin octobre 2013 (voir dépêche FreeBSD Miroirs pkgng disponibles !) alors que ceux de DragonFly étaient déjà présents pour la version 3.4, sortie en avril de cette même année.

La migration vers pkgng rend facilement installable un nombre plus importants de paquets. En effet, là où pkgsrc proposait l'installation d'environ 10 000 paquets, pkgng en propose désormais plus de 20 000.
À noter que, à la manière de ce qui est fait chez FreeBSD, les paquets sont également installables via les dports par le biais d'une compilation manuelle. Cela permet de choisir des options différentes de celles par défaut pour les paquets et l'installation par ce biais permet naturellement de les gérer via pkgng une fois installés.

Si vous n'avez pas encore les dports, il existe trois moyens simples pour les obtenir:
cd /usr
1) make dports-create: cela a pour effet de cloner l'entier du dépôt dports depuis Github dans /usr/dports.
2) make dports-create-shallow: le dépôt est cloné sans l'historique. Le dépôt peut néanmoins être mis à jour depuis /usr/dports (cd /usr/dports && git pull).
3) make dports-download: télécharge un tarball du dépôt et le décompresse dans /usr/dports.

Si vous rencontrez un problèmes avec un dport ou si vous souhaitez fournir un patch (pour, par exemple, corriger un port qui compile sous FreeBSD mais pas sous DragonFly ;) ), il faudra passer par le tracker de Github.

GSOC

D'autres projets ont été développés lors du google summer of code, mais n'ont pas encore été importés dans la branche principale et sont en cours de stabilisation.

Checkpoints pour les vkernel

DragonFly supporte un système de checkpoint, qui permet de sérialiser l'état d'un processus sur le disque (à l'aide d'un core dump) et de le restaurer par la suite. Pawel Dziepak a mis à jour cette fonctionnalité pour qu'elle fonctionne correctement avec les applications à plusieurs threads, puis pour qu'elle fonctionne avec les vkernels.

Implémentation de System V IPC en espace utilisateur

Grigore Larisa a créé un démon fournissant l'API sysvipc en espace utilisateur pouvant remplacer l'implémentation du noyau. Elle a posté des tests de performances réalisés avec pgbenchs, qui semblent assez prometteurs.

Notes de mise à jour

La procédure de mise à jour depuis la version 3.4 diffère légèrement de la procédure habituelle. En effet, un redémarrage de la machine est nécessaire avant d'appliquer un make upgrade.
Voici donc les commandes à appliquer pour la mise à jour (avec les droits root):

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

Le changement du numéro d'ABI demande une réinstallation de tous les paquets binaires (dports). Assurez-vous donc d'utiliser pkg clean afin de purger les anciens paquets du cache avant de procéder à leur mise à jour avec les commandes pkg update et pkg upgrade -f

  • # Youpi !

    Posté par . Évalué à 9.

    Alors que l'actu Linux est un peu fade, ça fait du bien de lire quelque chose d'excitant.
    C'est tout de même surprenant que pkgsrc et donc pkgin soient abandonnés si rapidement alors qu'ils ont été introduits très récemment.

    • [^] # Re: Youpi !

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

      Cela peut paraître surprenant mais comme c'est précisé dans la dépêche, il y a eu un véritable plébiscite des utilisateurs en faveur de pkgng. De plus, le nombre de paquets disponibles a plus que doublé ce qui est bénéfique d'un point de vue utilisateur.

      • [^] # Re: Youpi !

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

        Puisque j'ai du chercher de quoi on parlait:
        - pkgsrc est l'hisotrique gestionnaire de paquets des bsd.
        - pkgin est un gestionnaire moderne, créé par Imil pour NetBSD, et reposant sur le format et les outils de pkgsrc.
        - pkgng est un gestionnaire moderne, créé par bapt pour FreeBSD, ayant son propre format de paquet, et totalement indépendant de pkgsrc.

        Du coup, je m'interroge sur l'avenir de pkgin: ne risque-t-il pas d'être très isolé? NetBSD n'aurait-il pas intérêt à préférer pkgng à pkgin?

        • [^] # Re: Youpi !

          Posté par . Évalué à 10.

          • pkgsrc est l'hisotrique gestionnaire de paquets des bsd

          C'est peut être un peu exagéré de dire ça. Historiquement, sous BSD la gestion des paquets tiers se fait avec un arbre de ports. Chaque port est un Makefile, quelques métadonnées, et un des patchs éventuels. Pour installer un paquer, il suffit de faire make install dans le repertoire du port, ce qui va télécharger les sources et installer le logiciel à l'emplacement adéquat.

          Quand les divers BSD se sont séparés, ils ont hérité de ce système, mais ce système a évolué différement dans chacun des OS, un peu comme les systèmes de paquet sous GNU/Linux. pkgsrc est l'abre des ports chez NetBSD, celui de freeBSD et celui d'openBSD sont tout les deux appelés "ports", mais ils sont aussi différents.

          Un des attouts les plus revendiqués de pkgsrc est sa portabilité. Il fonctionne notament sur NetBSD, mais aussi GNU/Linux, Solaris, Minix, DragonFlyBSD, et sur diverses architectures. Il est donc loin d'être isolé. Toutefois, les ports FreeBSD commencent à évoluer dans cette direction durant ses évolutions récentes.

          Historiquement encore, des scripts ont été développés pour installer des paquets binaires, les vénérables pkg_add, pkg_radd, pkg_info. Ils sont eux aussi un peu différents pour tout les OS. Toutefois, ce système est assez primitif vis à vis de la gestion des dépendances et des mises à jour, ainsi que dans sont interface. Pour pallier aux divers problèmes de ces outils, des projets sont nés.

          pkgin est un gestionnaire de paquet binaires qui repose sur pkgsrc en effet, et qui utilise en fait les outils précédement cités si je ne dis pas de bétise, mais qui fournit une interface plus simple pour gérer des dépôts et des mises à jours.

          pkgng lui est un projet pour les ports FreeBSD, c'est pour ça qu'il est indépendant de pkgsrc. Sont but premier est de fournir des paquets binaires issus des ports FreeBSD. Mais, contrairement à pkgin, il ne se base pas sur les anciens outils pkg_add, pkg_radd etc. Par contre, les paquets binaires, qui ont leur propre format, sont générés et compilés à partir de l'abre des ports.

          Les approches sont différentes, peut être que pkgsrc aurait intérêt à passer à pkgng, mais mon impression est que pkgsrc est plus conservatif en ce moment que les ports freeBSD (une des raison qui ont motivées la personne qui a développée Dports, le portage semi automatique des ports FreeBSD vers DragonFly). Il est tout à fait possible d'adapter pkgng à pkgsrc, mais je ne connais pas la charge de travail nécéssaire pour le faire.

          De toute manière, l'effort principal de maintenance n'est pas au niveau de pkgng ou pkgin, il est dans la maintenance des ports, leur mises à jour pour mieux gérere les dépendances entre les paquets binaires ou les options de compilation pour les paquets binaires. Et du aux différences entre pkgsrc et les ports, le code ne peut pas vraiment être partagé entre les deux.

          • [^] # Re: Youpi !

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

            Un des attouts les plus revendiqués de pkgsrc est sa portabilité. Il fonctionne notament sur NetBSD, mais aussi GNU/Linux,

            J'avais essayé pkgsrc sur freebsd il y a quelques années, et c'était vraiment galère pour mettre en place. Au final en se renseignant on apprenait que c'était censé fonctionner sur freebsd, mais que dans les faits c'était pas le cas pour diverses raisons. Je ne sais pas si qqu'un a essayé sous linux, mais je crains que ça soit un peu pareil.

            « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

            • [^] # Re: Youpi !

              Posté par . Évalué à 1.

              Non, ça fonctionne sur freebsd ainsi que sur linux.

              Exemple de build sur free et linux:
              http://mail-index.netbsd.org/pkgsrc-bulk/2013/11/15/msg010107.html
              http://mail-index.netbsd.org/pkgsrc-bulk/2013/11/15/msg010108.html

              J'ai testé sur gentoo, free et net.
              Par contre le nombre de packages disponibles varie en fonction de l'archi. l'OS et suivant la disponibilité des mainteneurs.

              • [^] # Re: Youpi !

                Posté par . Évalué à 2.

                Le fait que ça marche ne veut pas dire que c'est utilisé.
                Je n'ai jamais vu quelqu'un utiliser pkgsrc sur sa distribution Linux.
                Le fait est que pkgsrc sera bel et bien isolé sur NetBSD.

                • [^] # Re: Youpi !

                  Posté par . Évalué à 2.

                  Personnellement, je l'utilise dans un cas bien précis. Pour installer des logiciels sur des machines où je ne suis pas administrateur. pkgsrc gère ça très bien, et c'est la meilleure solution que j'ai trouvé jusqu'a présent

                • [^] # Re: Youpi !

                  Posté par . Évalué à 2. Dernière modification le 06/12/13 à 10:59.

                  Je répondais à cette phrase:

                  Au final en se renseignant on apprenait que c'était censé fonctionner sur freebsd, mais que dans les faits c'était pas le cas pour diverses raisons

                  Ca marche.
                  Personnellement je l'utilise. Oui, ce n'est pas parfait et oui le nombre de paquets n'est pas aussi élevé que certains arbres; mais je n'ai pas à me prendre la tête, j'ai un seul type de gestion de paquets tiers à gérer.
                  Je trouve ça pas si mal et notamment comme signalé dans un autre commentaire en mode non privilégié et ça c'est royal lorsque que tu n'es pas admin d'une machine. Il y a bien le projet Gentoo Prefix qui tente la même logique mais ce n'est pas aussi "simple" que pkgsrc.

                  Il faudrait regarder mais il y a quelques temps, il y avait certaines distro linux qui l'utilisaient comme arbre de paquets tiers.
                  Il y a Joyent qui l'utilise comme dépôt de paquets tiers avec SmartOS. Pkgsrc n'est pas isolé sur NetBSD. Après chacun est libre de choisir sa solution mais pkgsrc ne se contente pas de marcher sur NetBSD, d'ailleurs il se veut être OS-agnostique ; en tout cas, il essaie.

          • [^] # Re: Youpi !

            Posté par . Évalué à 4.

            «Quand les divers BSD se sont séparés, ils ont hérité de ce système»

            Ben non. Les ports de FreeBSD ont été créés plusieurs années après la séparation Free/Net. Et dans le plus pur esprit BSD, pkgsrc tout comme les ports OpenBSD ont commencé comme des forks des ports FreeBSD, eux aussi ajoutés après coup, et ont vite divergé en fonction des objectifs respectifs de chacun des projets.

  • # ça bouge chez BSD

    Posté par . Évalué à 5. Dernière modification le 05/12/13 à 20:12.

    Je retrouve le plaisir perdu des dépêches du kernel linux dans ceux de DragonFly. Les changements ont l'air importants avec l'amélioration constante des perfs.

    Ça donne l'impression d'un projet qui bouge plus que la grosse machine linux.

    • [^] # Re: ça bouge chez BSD

      Posté par . Évalué à 4.

      Le fait que l'équipe soit réduite peut entrainer des changements plus simplement, mais il ne faut pas se leurrer, linux bénéficie d'un temps de développement complétement incomparable à DragonFlyBSD. Mais DragonFly essaye de pallier à ces problèmes en ne supportant qu'une seule architecture et en réutilisant au maximum les pilotes de FreeBSD.

      Mais je pense que ça a aussi ces effets bénéfiques. Par exemple, linux change très souvent ses API internes. Pour ce qui est d'un projet comme DragonFly, c'est juste inconcevable de modifier une API sans de bonne raison, et ça entraine surement plus de stabilité du code (pas au sens "moins de crash" mais au sens moins de changement des interfaces).

    • [^] # Re: ça bouge chez BSD

      Posté par . Évalué à 6.

      Ça donne l'impression d'un projet qui bouge plus que la grosse machine linux.

      C'est clair que quand tu pars de loin tu as plus de chemin à parcourir ;)

  • # Mise a jour

    Posté par . Évalué à 3.

    Il est un peu dommage d'avoir d'un coté pkgng très simple mais de l'autre une procédure de mise à jour de l'os qui passe toujours par la compilation du kernel et du world. Un outil similaire à freebsd-update serait génial.

    • [^] # Re: Mise a jour

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

      C'est une fonctionnalité souvent demandée et qui serait sans nul doute utilisée. Cela pourrait bien arriver prochainement, le sujet ayant souvent été abordé sur IRC récemment.

Suivre le flux des commentaires

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