DragonFly BSD 4.6 et 4.6.1

40
24
oct.
2016
DragonFly BSD

DragonFly BSD 4.6.1 est disponible depuis le 17 octobre 2016. Il s’agit d‘une version mineure comportant principalement des corrections de bogues. Cette dépêche se focalise sur les nouveautés de la branche 4.6 en général.

Justin Sherill a annoncé la version 4.6 de DragonFly BSD le 2 août 2016. Cette version contient des mises à jour qui raviront les utilisateurs de processeurs graphique Intel et Radeon, un tout nouveau contrôleur NVMe, une prise en charge préliminaire de l’EFI, mais également des améliorations de performance SMP et réseau lors de charges importantes.

Sommaire

Noyau

Systèmes de fichiers et stockage

HAMMER

HAMMER utilise désormais l’option noatime par défaut.

HAMMER2

HAMMER2 est toujours en développement et donc pas encore finalisé. Cependant, un travail important sur HAMMER2 a été effectué ces derniers mois afin d’améliorer la stabilité ainsi que les performances en environnement SMP.

Nouveau pilote NVMe

DragonFly BSD bénéficie désormais d’un tout nouveau pilote NVMe (SSDs PCIe). Ce pilote a été implémenté de zéro par Matthew Dillon à partir de la spécification NVM Express 1.2a. Le pilote utilise toutes les fonctionnalités de concurrence offertes par la puce et se charge de distribuer des files d’attente et les interruptions sur plusieurs processeurs afin de maximiser les performances. Matt a publié les résultats de quelques tests. On en retiendra qu’il a été possible de tirer profit au maximum de trois SSD NVMe sur la machine de test tout en ayant passablement de ressources encore disponibles. En termes de chiffres, les tests ont atteint environ 1,05 MIOPS @4K et 6,5 Gio/s @32K (lecture aléatoire de partitions remplies par urandom) avec un serveur de test (deux Xeon E5-2620v4) restant au repos à 78 % dans le test d’entrées‐sorties par seconde et 72 % dans le test de bande passante.

Le pilote n’est toutefois pas inclus dans le noyau par défaut. Il faut donc charger le module si vous voulez en bénéficier.

Il faut noter également que le travail sur le pilote NVMe a également permis d’améliorer les performances SMP de DragonFly qui étaient déjà excellentes. Le sous‐système de cache tampon et d’autres sous‐systèmes liés aux entrées‐sorties ont été optimisés par une réduction des conflits de verrous et de la surcharge liée à l’IPI.

Réseau

La pile réseau a subi une mise à jour importante. Le travail a été effectué de concert par Matthew Dillon, Imre Vadasz et Adrian Chadd. Ce dernier est un développeur FreeBSD et il en a donc profité pour récupérer quelques corrections effectuées çà et là par l’équipe de DragonFly BSD pour FreeBSD (la pile Wi‐Fi de DragonFly BSD est en effet essentiellement dérivée de celle de FreeBSD).

En vrac, on peut citer :

Pile graphique

Comme à l’accoutumée, cette version de DragonFly bénéficie d’un important travail de François Tigeot sur la pile graphique et notamment drm/i915 pour la gestion des processeurs graphiques Intel. Elle a d’abord été mise à jour pour atteindre la parité avec Linux 4.0, puis 4.1, 4.2, 4.3 et finalement 4.4.

Concrètement, ces mises à jour apportent la prise en charge des processeurs graphiques Skylake et Broxton (nouveau système monopuce Atom). Tous les processeurs graphiques Intel vendus jusqu’en août 2016 sont pris en charge.

Le pilote drm/i915 a bénéficié de nombreuses corrections de bogues et est globalement plus stable sur toutes les familles de processeurs graphiques prises en charge. En particulier, certains plantages matériels de vieux jeux de puces sur des machines Core 2 ou Atom d’avant 2012 devraient maintenant être récupérables.
La gestion des sorties vidéo a été améliorée. Certains moniteurs HDMI qui réagissaient plus lentement que ce qui était prévu dans la norme devraient maintenant pouvoir fonctionner sans problème. De nombreux soucis de jeunesse ont également été corrigés pour la prise en charge des liens DisplayPort.

Les performances ont aussi été augmentées et une meilleure gestion des fréquences du processeur graphique permet d’améliorer l’expérience utilisateur pour différents types de tâches sur les processeurs des générations Haswell et Broadwell.

Rimvydas Jasinskas a également amélioré le pilote drm/radeon, afin de rajouter la prise en charge des processeurs graphiques de la famille Bonaire.

Espace utilisateur

Paquets

Grâce au travail de contributeurs et principalement John Marino et Rimvydas Jasinskas, plus de 24 000 paquets sont désormais disponibles pour DragonFly BSD, à compiler via les dports ou à installer via pkg(8).

EFI

DragonFly BSD peut désormais être démarré via l’EFI. Cependant, cela reste préliminaire dès lors que l’installateur ne le prend pas encore en charge.

Divers

Nouveaux développeurs

L’équipe de DragonFly BSD est restreinte. C’est donc toujours un plaisir d’accueillir de nouveaux développeurs. C’est ainsi que Rimvydas Jasinskas est le dernier programmeur en date à avoir obtenu son « commit bit ». Il a effectué un travail important tout au long du cycle de développement, notamment en réparant de nombreux dports, mais aussi en aidant François Tigeot dans son travail sur la pile graphique.

Ce cycle de développement a également vu Bill Yuan obtenir son « commit bit ». Bill a surtout travaillé sur ipfw3 comme pare‐feu alternatif.

Un nouvel outil pour les (d)ports : synth

John Marino, qui est à l’origine des dports et très actif dans son maintien, a créé un nouvel outil pour la compilation des dports : synth. Cet outil peut être utilisé tant pour créer des paquets à partir des dports de DragonFly, que des ports de FreeBSD. Il se veut une alternative à portupgrade et  portmaster et, dans une certaine mesure, à poudriere.

Aller plus loin

  • # Benchmark?

    Posté par  (site web personnel) . Évalué à -2.

    La dernière fois que j'ai vu un benchmark BSD vs Linux sur phoronix, les performances des BSD été à la traîne. Et maintenant?

    Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

    • [^] # Re: Benchmark?

      Posté par  (site web personnel) . Évalué à 7.

      Les performances de quel sous-système? Les performances de DragonFly BSD sont de manière générale très bonnes (en tout cas pour l'usage que j'en fais et de ce que les gens rapportent sur le channel IRC de DragonFly BSD). De toute façon, les performances ne sont de loin pas le seul facteur à prendre en compte lors du choix d'un OS. Et pour ce que je pense des benchmarks de Phoronix, je préfère me taire. :)

      • [^] # Re: Benchmark?

        Posté par  . Évalué à 3. Dernière modification le 24 octobre 2016 à 16:35.

        C'est donc toi l'utilisateur de Dragonflybsd !
        Je n'arrive pas à retrouver la source, mais dflybsd se défendait bien en benchmark Postgresql.

        • [^] # Re: Benchmark?

          Posté par  (site web personnel) . Évalué à 3.

          On n'est pas nombreux mais je ne suis pas seul quand même. :-)

          Pour le benchmark PostgreSQL, je pense que tu fais référence à celui de François Tigeot lors de la PGCon 2014?

          • [^] # Re: Benchmark?

            Posté par  . Évalué à 2.

            On en avait parlé sur Linuxfr, mais en attendant je suis preneur de tes retours d'expérience sur dflybsd.
            Parce qu'à part Hammer, je ne lui trouve aucun attrait par rapport à FreeBSD.

            • [^] # Re: Benchmark?

              Posté par  (site web personnel) . Évalué à 5.

              Parce qu'à part Hammer, je ne lui trouve aucun attrait par rapport à FreeBSD.

              C'est surtout Hammer2 qui devrait entrer en concurrence avec ZFS.

              • Construction basée sur des blocs en «copy-on-write».
              • plusieurs racines,
              • compression et chiffrement à un plus haut niveau que Hammer1

              De fait, le premier point change beaucoup de choses.
              - Hammer1 était construit au dessus d'un arbre -

              Surtout Hammer2 promet de réduire l'empreinte mémoire, ce qui reste le gros inconvénient de ZFS.

              Il faudrait une dépêche dédiée à Hammer2. :)

    • [^] # Re: Benchmark?

      Posté par  . Évalué à 2.

      Je viens de demander à Google : http://www.phoronix.com/scan.php?page=article&item=pcbsd-103-bench&num=1
      Ce n'est pas très tranché, mais en gros l'unique BSD testé est plus performant que la moitié des Linux testés. Aucune distribution Linux ne le devance sur plus de 75% des tests. Donc « à la traîne » ne convient pas.

      • [^] # Re: Benchmark?

        Posté par  . Évalué à 8.

        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.

  • # Des interruptions sur GPU?

    Posté par  . Évalué à 3.

    DragonFly BSD bénéficie désormais d’un tout nouveau pilote NVMe (SSDs PCIe). Ce pilote a été implémenté de zéro par Matthew Dillon à partir de la spécification NVM Express 1.2a. Le pilote utilise toutes les fonctionnalités de concurrence offertes par la puce et se charge de distribuer des files d’attente et les interruptions sur plusieurs processeurs graphiques afin de maximiser les performances.

    Traiter une interruption sur un GPU, ce serait un beau tour de force, mais je ne suis pas certain que ce soit vraiment ce que fasse le driver ni que ce soit vraiment utile…

  • # NVMe from scratch

    Posté par  (site web personnel) . Évalué à 2.

    Ce qui m'intrique, c'est la volonté d'avoir implémenté le driver NVMe from scratch alors que FreeBSD en a un. Je me demande s'il y a des raisons à cela ?

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: NVMe from scratch

      Posté par  (site web personnel) . Évalué à 5.

      Oui il y en a évidemment. Dillon a mentionné le fait qu'il aurait passé probablement autant de temps à porter un driver que d'en écrire un "from scratch", les specs étant apparemment plutôt simples. Une autre raison est de pouvoir l'optimiser au maximum pour DragonFly. J'ai aussi vu passer quelques phrases à propos de la qualité du pilote FreeBSD qui est du "vendor code" pas forcément de très bien écrit.

    • [^] # Re: NVMe from scratch

      Posté par  . Évalué à 5.

      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.

  • # gestion des supports USB (clef)

    Posté par  . Évalué à 1.

    Bonjour.

    Cet article m'a donné envie d'installer (pour la deuxième fois de ma vie !) DragonFlyBSD sur mon portable Lenovo thinkPad X200s (que est compatible avec les *BSD). Il faut savoir que sur ce même portable, j'utilise au quotidien OpenBSD -current (et aussi un système FreeBSD RELEASE mais moins souvent en ce moment je l'admets). Par conséquent, sans trop de surprises, ce portable semble bien reconnu et exploité par DragonFlyBSD.

    Néanmois, j'ai un souci. J'essaie de monter une clef USB.

    Après l'avoir connectée, la commande dmesg me retourne

    ugen3.2: <Verbatim> at usbus3
    umass0: <Verbatim STORE N GO, class 0/0, rev 2.00/1.00, addr 2> on usbus3
    da8 at umass-sim0 bus 0 target 0 lun 0
    da8: <Verbatim STORE N GO 1.0> Removable Direct Access SCSI-2 device
    da8: 40.000MB/s transfers
    da8: 7651MB (15669248 512 byte sectors: 255H 63S/T 975C)

    Lorsque je regarde dans /dev/, j'ai effectivement le fichier lié à ma clef à savoir da8 mais contrairement à FreeBSD, il n'existe pas de fichier du type da8s1 pour monter la clef. Pas grave, j'ai tenté à l'arrache (en root).

    (1) Un premier essai lorsque l'unique partition de la clef était formatée en vfat32 :

    # mount -t msdos /dev/da8 /mnt

    (2) Un deuxième essai après avoir formaté l'unique partition de cette clef en ext3 (à l'aide de fdisk de mon système Debian)

    # mount -t ext2fs /dev/da8 /mnt

    Dans les deux cas, le shell me retourne que le montage n'est pas possible (ce qui ne me surprend pas en fait !).

    Retour donné par le shell dans le cas de la clef formatée en ext3 :

    mount_ext2fs: /dev/da8: Input/output error

    Une idée ?

    Autre fait étrange : Pour l'instant du moins, le noyau de cet OS ne reconnaît qu'un core sur les deux de mon Core 2 Duo ?! Néanmoins, je pense que je ne vais pas tarder à aller voir du côté de /boot/loader.conf ou alors est-ce peut-être lié au fait que le noyau utilisé n'est pas la version MP ?!

    ps : Message envoyé de DragonFlyBSD 4.6.1 (arch : amd64) ! :)

    • [^] # Re: gestion des supports USB (clef)

      Posté par  . Évalué à 3.

      Salut.

      Je viens de régler les deux problèmes évoqués ci-dessus (supports USB + SMP pris en charge correctement)… En effet, je suis revenu sur OpenBSD -current ! :)

      • [^] # Re: gestion des supports USB (clef)

        Posté par  . Évalué à 2.

        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.

        • [^] # Re: gestion des supports USB (clef)

          Posté par  . Évalué à 7.

          Bonjour et merci pour l'information ! :)

          Voici ma motivation : Je vais être honnête. J'ai installé DragonFly BSD par curiosité pour une utilisation de type Desktop. (Cet aspect m'a toujours intéressé, du moins dans un premier temps, avec un nouvel OS.) Je vais donner mon point de vue sur ce DragonFly BSD (pour exploiter un poste de travail donc) et ce en ne l'ayant utilisé que sur une après-midi. Par conséquent, cet avis est un plus de l'ordre du ressenti ! Autrement dit, je ne cherche pas à troller. Loin de là ! Par contre, je vais naturellement essayer de comparer DragonFly BSD RELEASE à un système FreeBSD RELEASE (architecture : amd64) mais aussi à un système OpenBSD -current (architecture : amd64) que j'utilise actuellement quotidiennement.

          Prérequis : L'installation de DragonFly BSD a été une installation chiffrée.
          Objectif : Installer un système DragonFly BSD (Mate) sur un poste de travail.

          (1) Installation chiffrée

          Le chiffrement n'a pas pu se faire sur la totalité du disque. (Le système de fichiers « /boot » n'a pas été chiffré.) Peut-être est-ce lié au système de fichiers HAMMER et/ou à LVM ? En fait, je n'ai pas bien compris quel était le rôle de LVM au sein de DragonFly BSD. Il me semblait que HAMMER était un « clone BSD » de ZFS mais cela ne semble pas être le cas. Sinon comment expliquer la présence LVM ?

          À titre de comparaison, une installation chiffrée avec FreeBSD/ZFS ou OpenBSD/UFS permet de chiffrer tout le disque.

          (2) Parefeu pf

          Sur les trois systèmes, le parefeu pf est utilisable. Par contre, la version de pf la plus récente est celle d'OpenBSD. Et pour cause !

          (3) Architectures gérées

          DragonFly BSD RELEASE existe uniquement en version x86_64. (La version « embarquée » de wine l'est aussi.) La version x86_64 de FreeBSD RELEASE permet (encore) la gestion des logiciels construits pour une architecture x86 (y compris par le biais de wine pour les logiciels créés pour un système Windows de Microsoft). Quant à OpenBSD, ce système ne permet pas d'utiliser wine et, depuis peu, ne permet plus d'émuler un noyau linux.

          Sur tous ces derniers aspects, FreeBSD RELEASE est le plus polyvalent des trois systèmes.

          (4) Couche graphique

          Tout fonctionne assez bien (voire très bien) sur les trois systèmes. À noter que l'environnement Mate n'existe pas sur OpenBSD. Cependant, l'environnement Xfce en version 4.12* est présent pour le remplacer. La localisation en français de l'environnement graphique (y compris les terminaux de type Xterm) est plus simple à mettre en place sur OpenBSD. En effet, avec les systèmes FreeBSD et DragonFly BSD, j'ai dû générer puis configurer le fichier xorg.conf (ce qui n'est pas le cas d'OpenBSD). Par contre, OpenBSD/Xfce -current plante parfois (liés aux logiciels comme LibreOffice, Mozilla Firefox, Thunar, …). Toutefois, il ne faut pas perdre de vue qu'OpenBSD -current est un système d'exploitation en développement constant. Compte tenu de ce simple fait, OpenBSD -current est assez stable !! Sur ce plan, FreeBSD/Mate RELEASE n'a jamais planté sur le même portable. Quant à DragonFly BSD RELEASE, hier, tout a bien fonctionné… mis à part un petit souci avec la fermeture du logiciel FrozenBubble qui a occasionné un changement de résolution (800 sur 600) mais rien de bien « méchant ».

          (5) Gestionnaire des paquets binaires (logiciels tierce partie)

          D'un côté « pkg » sur FreeBSD/DragonFly et de l'autre « pkg_add » pour OpenBSD. Les deux gestionnaires de paquets fonctionnent très bien. Il est cependant à noter que la séparation nette entre le couple noyau/base et les logiciels tierce partie est moins « nette » sur OpenBSD !! En effet, sur OpenBSD -current, les mises à jour du couple noyau/base et celles des logiciels tierce partie sont, de fait, liées. De plus, l'arborescence /usr/local/etc/ n'existe pas sur OpenBSD. Tous les fichiers de configuration sont situés dans /etc/. Étrange d'ailleurs ?!

          (6) Suites bureautiques

          La suite Office « LibreOffice » est livrée en version 5* sur les trois systèmes.

          Sur les trois, la version de LibreOffice la plus récente (5.2* contre 5.0* pour les deux autres BSD) est celle d'OpenBSD -current mais, pour ma part, ce n'est pas très gênant.

          (7) Navigateurs Web

          Dans les trois cas, le navigateur Mozilla Firefox est proposé dans une version 49*.

          Ce que je n'ai pas pu tester avec le système DragonFly BSD : (Je n'ai donc pas d'avis sur ces sujets.)

          (1) Les mises à jour du couple noyau/base

          Pour DragonFly BSD : Il me semble qu'il faut recompiler les sources à la « main ».

          Pour FreeBSD -RELEASE : Les mises à jour (binaires) s'effectuent via le logiciel freebsd-update.

          Pour OpenBSD :

          • pour -release/-stable : Il faut compiler les sources à la « main » ;
          • pour -current : Il faut redémarrer la machine sur un noyau « bsd.rd » (bien « choisi » pour avoir une synchronisation éventuelle avec les logiciels tierce partie) afin d'« écraser » l'ancien système de base par le nouveau (mise à jour « full » binaires).

          (2) Le système de fichiers HAMMER (LVM ?)

          Je ne peux donc pas le comparer au système de fichier ZFS (que je connais un peu). Toujours est-il qu'en utilisation Desktop, tout a été transparent. Cela ne m'a pas frappé. Je n'ai rien à dire sur ce point. En mémoire vive, ce système de fichiers ne semble ni plus lourd ni moins lourd que ZFS (à machine égale). Quant à OpenBSD, il s'agit du système de fichiers UFS qui de toute façon plus léger mais plus vieux aussi.

          (3) Le(s) compilateur(s) lié(s) au langage C

          (4) Vitualisation native (type « KVM » avec un noyau linux)

          Pour FreeBSD RELEASE : Bhyve
          Pour OpenBSD -current : vmm/vmd
          Pour DragonFly BSD RELEASE : ?

          Ma conclusion (temporaire) :

          Je trouve le système d'exploitation DragonFly BSD intéressant en tant que système d'exploitation pouvant gérer un poste de travail mais il est objectivement encore jeune pour une telle utilisation (notamment en comparaison de son « père » FreeBSD qui lui est fait de l'ombre). Néanmoins je pense que cet OS a un avenir et du potentiel sur mon poste travail. Pour le vérifier, je compte désormais le tester régulièrement. Mais, mon portable restera exploité par OpenBSD -current qui est certes un système d'exploitation plus simple (plus "kiss"), plus léger et qui m'apporte entière satisfaction… pour l'instant. ;-)

          Voilà l'avis d'un simple utilisateur.

          • [^] # Re: gestion des supports USB (clef)

            Posté par  . Évalué à 3. Dernière modification le 26 octobre 2016 à 23:44.

            Pour OpenBSD -current : vmm/vmd

            Actuellement ça ne supporte pas un autre OS qu'OpenBSD, ce qui limite un peu son utilité.

            Pour DragonFly BSD RELEASE : ?

            Il n'y a pas non plus de virtualisateur de machine accéléré. Par contre il y a le choix entre un VKERNEL (~~ UML) et les jails.

            [LVM / ZFS]

            LVM est là car quelqu'un à décidé de le porter, c'est plus un "accident" qu'une décision de design de l'OS. En ce qui concerne les capacités raid de HAMMER1/2, ça n'a pas l'air d'être une priorité ni de faire partie du design. Il y a moyen d'étendre un volume sur plusieurs périphériques, mais (corrigez moi si je me trompe) il n'y a pas de mécanisme de protection*, de redondance ou de réparation (donc à éviter je dirais) ou alors il faut s'appuyer sur une solution en dehors de HAMMER de type LVM ou matérielle. L'idée est de s'appuyer sur les mirroirs+snapshots sur un FS différent pour s'occuper de la partie redondance. Certes, ça rend difficile la création de système de fichiers très larges et c'est peut-être plus compliqué à administrer, mais dans la majorité des cas ça ne devrait pas être un obstacle (AMHA).

            *: de protection répartie j'entends. Il y a un CRC data/metadata (manque juste un outil pour le scrub… en attendant tar fait l'affaire)

          • [^] # Re: gestion des supports USB (clef)

            Posté par  . Évalué à 1.

            De plus, l'arborescence /usr/local/etc/ n'existe pas sur OpenBSD. Tous les fichiers de configuration sont situés dans /etc/. Étrange d'ailleurs ?!

            C'est faux. Si tu installes un logiciel tiers, sa configuration aura des chances de se retrouver dans /var/nom-du-programme/etc/. C'est le cas pour NSD, heimdal, unbound…

            • [^] # Re: gestion des supports USB (clef)

              Posté par  . Évalué à 3.

              C'est un programme chrooté, n'est-ce pas ?

              • [^] # Re: gestion des supports USB (clef)

                Posté par  . Évalué à 1.

                Oui. Je suppose qu'il n'y a pas vraiment d'intérêt à séparer les autres fichiers de configuration par rapport à ceux déjà présents dans /etc.

            • [^] # Re: gestion des supports USB (clef)

              Posté par  . Évalué à 2.

              Je ne sais pas pour NSD mais je confirme que les fichiers de configuration de slim et de conky ne sont pas dans /usr/local/etc/ (qui n'existe pas je le répète) mais dans /etc/.

              Mais je vais aller tout de même aller vérifier dans /var/slim/etc/ et /var/conky/etc/… si ces répertoires existent. Si c'est le cas, je trouverais cela étrange de copier des fichiers de configuration de "bêtes" logiciels tierce partie (comme slim ou conky) dans /var/ ?! Non ?

              J'y vais et je vous tiens au courant !!

            • [^] # Re: gestion des supports USB (clef)

              Posté par  . Évalué à 2.

              Je viens de regarder sur l'une de mes machines virtuelles exploitées par un système OpenBSD -current (noyau/base uniquement et pas de logiciels tierces partie donc). Les services nsd et unbound font (nativement) partie de la base du système OpenBSD par conséquent ce n'est pas étonnant que leurs fichiers de configuration se situent dans /var/. Par contre, je n'ai pas vu heimdall. Allez… je vais voir sur mon système OpenBSD -current Desktop qui exploite mon portable. :)

            • [^] # Re: gestion des supports USB (clef)

              Posté par  . Évalué à 2.

              Bon je viens de vérifier sur mon portable exploité par OpenBSD -current. Comme nous pouvions le prévoir, aucun fichier de configuration lié aux logiciels tierce partie (installés via le gestionnaire pkg_add donc) n'apparait dans l'arborescence /var/ (et encore moins dans celle /usr/local/etc qui n'existe pas !). Je pense que je vais envoyer un message sur ce sujet sur misc (par curiosité car cela m'intrigue tout de même). Avec un peu de chance (ou pas ?), Theo me répondra. ;-)

            • [^] # Re: gestion des supports USB (clef)

              Posté par  . Évalué à 3.

              Voici les réponses sur misc@ sur la question de la séparation stricte système de base et logiciels tierce partie :

              https://marc.info/?t=147759953400009&r=1&w=2

              Pour résumer :

              (1) Le fait de centraliser globalement tous les fichiers de configuration dans l'arborescence "/etc" a été décidé au début du projet.
              (2) Mis à part la simplicité pour l'administrateur de pouvoir gérer (globalement) tous ces fichiers au même endroit, il n'y a pas de liens forts avec la sécurité (si ce n'est que cela contribue à la sécurité d'un système).
              (3) Un intervenant a mis en avant qu'il existait des philosophies différentes selon les BSD ce à quoi Theo de Raadt a répondu (ce ne sont pas les propos exacts mais je retranscris son idée) : "No religion" !

              • [^] # Re: gestion des supports USB (clef)

                Posté par  (site web personnel) . Évalué à 2.

                OpenBSD ne sépare pas les fichiers de configuration à tout prix comme indiqué sur la liste de diffusion.
                Par contre, comme pour unbound et nsd, quand on peut faire tourner un service dans un chroot avec un utilisateur dédié, c'est ce qui est réalisé. Et ça c'est quand même imparable.
                Je dis ça, je n'ai aucune idée de la façon de procéder des autres distros…

  • # Beau travaille pour la pile graphique

    Posté par  . Évalué à 2.

    Beau travaille pour la pile graphique ! Moi qui utilise FreeBSD et OpenBSD, Skylake n'est pas supporté et donc je travaille avec un écran en moins.
    Ça prouve une certains qualité de travail pour un OS plutôt méconnu par rapport à ses cousins *BSD.

  • # Cas d'utilisation ?

    Posté par  (site web personnel) . Évalué à 7.

    Autant prévenir d'avance : je ne cherche pas le troll et ma question est purement de bonne fois !

    Je n'ai pas beaucoup d'expérience avec les bsd (freeBSD installé sur mon portable et utilisé pendant 1mois quand j'étais étudiant "pour voir") et je ne vois pas beaucoup d'intérêt aux BSD par rapport à linux: le support matériel et la correction des bugs/ajout de features ne peut pas suivre le rythme (communauté beaucoup plus petite, aucun support d'entreprises commerciales).
    Au final les seuls avantages des BSD à ma connaissance sont que pf est vachement mieux que iptable et que openbsd est fourni durci de base.

    Du coup ça ne fait pas très lourd, et ça pose donc des questions:
    - pourquoi pf n'a pas été porté sous linux ? (Ou au moins son interface user)
    - une openBSD est elle vraiment plus sécurisé qu'un linux ? Si oui pourquoi Google&co continue à faire tourner linux pour leurs serveurs ?
    - pourquoi on a 4 versions de BSD ? De ce que je sais y'a eu pas mal de forks plus ou moins cordiaux…
    - qui utilisent ces 4 BSD, pourquoi (ils ont un cas d'utilisation différents chacun ?) et surtout pourquoi ne pas utiliser linux à la place ?
    - est-ce que ces os sont plutôt dans une logique de recherche plutôt que de production comme haiku ou plan9 ?

    Je le répète, je ne cherche pas à dire que BSD est un os de hypsters ("I was doing sockets before it was cool") sans intérêt mais plutôt à comprendre comment et pourquoi 4 OS arrivent à sortir des versions à rythme régulier alors que le marché des OS libres est totalement contrôlé par linux.

    • [^] # Re: Cas d'utilisation ?

      Posté par  . Évalué à 2. Dernière modification le 06 novembre 2016 à 12:06.

      La faible consommation en ressources, le principe KISS, l’aspect
      bien pensé et propre à configurer, la possibilité d’utiliser des
      paquets binaires ou de concocter une compilation aux petits oignons,
      tous ces paramètres qui ont fait le succès d’Archlinux et Manjaro,
      se retrouvent dans le monde BSD.

      Le support commercial est plus discret que sous linux, mais il n’en
      est pas moins présent. Je ne connais malheureusement pas la Libellule,
      mais pour la Free :

      List of products based on FreeBSD
      Who uses FreeBSD ?

      On voit même passer des commits sponsorisés par µSoft dans les sources.
      Un coup de :

      svn log | grep Sponsored | less

      dans /usr/src est instructif.

    • [^] # Re: Cas d'utilisation ?

      Posté par  (site web personnel) . Évalué à 4.

      je ne vois pas beaucoup d'intérêt aux BSD par rapport à linux:

      Dites-vous que l'on peut arguer de l'inverse.
      Je ne vois pas d'intérêt à Linux par rapport aux BSD.
      Sans doute, parce que mon parcours est différent: j'ai connu les BSD avant les Linux.

      le support matériel

      Linux supporte seulement plus de "matériel". c'est loin d'être optimal.
      D'ailleurs, Linux supporte-t-il plus de plate-formes que netBSD ?

      et la correction des bugs/ajout de features ne peut pas suivre le rythme

      Le rythme de … ?
      Et j'ai en tête, sous les Linux «modernes« un ajout de bugs en corrigeant des «features».

      (communauté beaucoup plus petite, aucun support d'entreprises commerciales).

      «aucun» !?

      Au final les seuls avantages des BSD à ma connaissance sont que pf est vachement mieux que iptable

      Ainsi que la pile réseau, openSSH, libreSSL, les jails, bhyve, ZFS, capsicum …

      […] Si oui pourquoi Google&co continue à faire tourner linux pour leurs serveurs ?

      Vous savez, vous, ce que Google, Facebook, Whatsapp, NetFlix, Yahoo, Sony … utilise sur toute sa gamme de serveurs ?

      • pourquoi on a 4 versions de BSD ? De ce que je sais y'a eu pas mal de forks plus ou moins cordiaux…

      Oui, querelles d'égo au départ, maquillées en divergences de cap et/ou techniques.
      Au sujet de DFly, il s'agit bien d'une divergence technique au sujet de la gestion des threads et d'une manière plus générale du SMP.

      • qui utilisent ces 4 BSD, pourquoi (ils ont un cas d'utilisation différents chacun ?)

      Routeurs, bidules réseaux, serveurs WEB, console de jeux …
      https://en.wikipedia.org/wiki/List_of_products_based_on_FreeBSD

      et surtout pourquoi ne pas utiliser linux à la place ?

      La question est biaisée. Pourquoi utiliserait-on du linux ?

      • est-ce que ces os sont plutôt dans une logique de recherche plutôt que de production comme haiku ou plan9 ?

      Non.

      • [^] # Re: Cas d'utilisation ?

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        Et à tout ça, on pourrait aussi ajouter la question de la licence.

        • [^] # Re: Cas d'utilisation ?

          Posté par  (site web personnel) . Évalué à -2.

          Houla, il faut en garder un peu sous le coude, pour la dépêche de FreeBSD 11 !

          Je ne doute pas que les:

          je suis pas un troll,
          seulement, je me renseigne amicalement sur les BSD ( que je ne connais pas)
          qui sont trop à la ramasse avec leur support matériel antédiluvien,
          leur communauté ridicule et leur technos qui suivent pas l'rythme des bugs
          de linux.

          sauteront sur l'occasion pour en remettre une couche pour nous expliquer que tout ça, c'est la faute à la licence.


          J'y connais rien et ce n'est pas une raison valable
          pour ne pas pouvoir raconter n'importe quoi.

          • [^] # Re: Cas d'utilisation ?

            Posté par  (site web personnel) . Évalué à 10.

            J'étais parti pour ignorer ton premier post, ou plutôt apprécier le fond en passant outre de la forme ;-)

            Si je viens sur LinuxFR c'est pour apprendre des choses et échanger, une dépêche sur BSD c'est le moment idéal pour en apprendre plus.

            Si une personne que ne connais pas Linux vient demander pourquoi l'utiliser alors que Windows est ultra majoritaire (en tout cas de son point de vu, dans sa vie il ne côtoie pas de serveurs et ne se doute pas que Linux tourne dans sa poche), on va le traiter de gros troll ?

            J'ai mis DEUX putains de disclaimer, au début et à la fin de mon post, j'ai cherché à être le plus neutre possible (je reconnais, je n'aurai pas dû mettre "aucun support d'entreprises commerciales" mais "pas de support commercial à ma connaissance"), j'aurai dû faire quoi de plus ? Fermer ma gueule et rester un ignare ?

            • [^] # Re: Cas d'utilisation ?

              Posté par  . Évalué à -3. Dernière modification le 07 novembre 2016 à 17:00.

              En tout cas, moi j'utiliserai pas BSD*… ;-)

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Cas d'utilisation ?

        Posté par  . Évalué à 6.

        est-ce que ces os sont plutôt dans une logique de recherche plutôt que de production comme haiku ou plan9 ?

        Non.

        En faisant l'impasse sur le côté historique (rappelons que BSD fut développé dans une université), ces systèmes entretiennent néanmoins des relations privilégiées avec le milieu académique. Ils servent de terreau fertile à la recherche "pure", et cela peut découler en des avancées technologique directement utilisables dont capsicum (que vous avez justement mentionné) est un parfait exemple.

        Par rapport à la question originale, il me semble que vouloir opposer une "logique de recherche" à une logique de production n'est pas nécessairement très pertinent dans toute industrie (qui par définition est technologique), et certainement pas dans le cas de l'informatique. (Btw haiku a plus à voir avec le côté hobbie-iste que celui de la recherche et le problème de plan9 était AMHA que UNIX avait déjà trop bien réussi, pas qu'il soit issu d'un département de R&D ou qu'il ne soit pas apte à être utilisé en "production").

        • [^] # Re: Cas d'utilisation ?

          Posté par  (site web personnel, Mastodon) . Évalué à 1.

          Pour Haiku, il y a eu quelques projets de recherches à l'université d'Aukland, en particulier sur l'interface graphique. Cela a été intégré dans Haiku avec Stack&Tile et Auckland Layout Manager.

      • [^] # Re: Cas d'utilisation ?

        Posté par  . Évalué à 6. Dernière modification le 09 novembre 2016 à 11:54.

        Je ne vois pas d'intérêt à Linux par rapport aux BSD.

        Docker, systemd, KVM, apt-get, ext4, le support matériel…

        Il y a quelques années encore FreeBSD avant de l'avance (je pense aux jails + zfs + nanobsd) mais l'écart se réduit.

        • [^] # Re: Cas d'utilisation ?

          Posté par  . Évalué à 6. Dernière modification le 09 novembre 2016 à 13:57.

          Ah, mais :

          • pkgng est très bien, fluide, syntaxe claire, assez riche en
            fonctionnalités. Peut-être pas aussi complexe qu’apt, mais il fait
            le boulot

          • le système rc de la free gère les relations entre services. Même
            commentaire final que pour apt.

          • ext4 est bien, solide et tout, mais pourquoi vouloir ext4 quand on
            peut mettre du ufs ou du zfs ?

          • docker ? Voir ici : FreeBSD Wiki : Docker

          J’ai mis à neuf un vieux coucou depuis quelques semaines en installant une free dessus,
          et jusqu’ici j’ai bien du mal à trouver un truc qui ne fonctionne pas … et c’est léger,
          à faire pâlir un papillon.

          ah si, le plugin python pour neovim, qui râle de ne pas trouver
          /usr/bin/gcc. Mais je finirai sûrement pas trouver une solution
          (à part créer un lien symbolique).

          • [^] # Re: Cas d'utilisation ?

            Posté par  . Évalué à 3.

            Bon, impossible d’éditer le post précédent, donc je complète ici :

            kvm ? voir : Linux KVM on FreeBSD

            Ne parlons pas de Handbook : BHyve

            • [^] # Re: Cas d'utilisation ?

              Posté par  . Évalué à 3.

              Je suis utilisateur convaincu de bhyve, à travers iohyve, mais ça reste moins souple que KVM pour le moment. Par exemple ça a l'air assez compliqué de démarrer une VM avec un Bios ou de l'uefi (il y a un micro code à télécharger + des manip) alors que c'est out-the-box sur Kvm.

          • [^] # Re: Cas d'utilisation ?

            Posté par  . Évalué à 5.

            pkgng est très bien, fluide, syntaxe claire, assez riche en
            fonctionnalités. Peut-être pas aussi complexe qu’apt, mais il fait
            le boulot

            pkgng est bien, oui, en revanche par expérience j'ai toujours eu des soucis avec les paquets au bout de quelques mises à jour. C'est visiblement du à l'aspect rolling release ou peut-être à un manque de QA quand il n'y a pas assez de mainteneurs.

            le système rc de la free gère les relations entre services. Même
            commentaire final que pour apt.

            Écrire un service systemd est carrément plus simple je trouve :)

            ext4 est bien, solide et tout, mais pourquoi vouloir ext4 quand on
            peut mettre du ufs ou du zfs ?

            ufs sur freebsd marche bien, en revanche sur netbsd et openbsd c'est une catastrophe en terme de performances.
            quant à zfs c'est un peu overkill pour un usage quotidien, et ça demande beaucoup de ram.

            docker ? Voir ici : FreeBSD Wiki : Docker

            J'avoue être sur le cul.

            • [^] # Re: Cas d'utilisation ?

              Posté par  (site web personnel) . Évalué à 6.

              pkgng est bien, oui, en revanche par expérience j'ai toujours eu des soucis avec les paquets au bout de quelques mises à jour. > C'est visiblement du à l'aspect rolling release ou peut-être à un manque de QA quand il n'y a pas assez de mainteneurs.

              Je suis preneur des bugs reports :)

              • [^] # Re: Cas d'utilisation ?

                Posté par  . Évalué à 2.

                pkgng est bien, y'a rien à dire, le problème c'est les paquets eux-même, et ça on y peut pas grand chose malheureusement.
                Bon boulot :)

              • [^] # Re: Cas d'utilisation ?

                Posté par  . Évalué à 1. Dernière modification le 14 novembre 2016 à 14:29.

                Qu'en est-il de la gestion des options ? Est-ce qu'il est possible de faire quelque chose pour mélanger le repo officiel avec des builds customisée ? Où bien on est de-facto contraint à rebuilder tout ce que dont on est succeptible d'utiliser ?

                (J'avais eu la chance de te poser la question en 2014 mais je ne me souviens plus de ta réponse, et peut-être que ça a évolué depuis… Quoi qu'il en soit, merci d'avance )

                • [^] # Re: Cas d'utilisation ?

                  Posté par  (site web personnel) . Évalué à 2.

                  les options sont présentées, la gestion des options s'arrête là pour le moment. Oui on peut mélanger les build perso et les build officiel il faut juste faire attention, beaucoup de fonctionnalités sont prévues a ce niveau et non encore implémentées.

                  Désolé ce n'est pas hyper clair comme réponse :)

            • [^] # Re: Cas d'utilisation ?

              Posté par  . Évalué à 4.

              quant à zfs c'est un peu overkill pour un usage quotidien, et ça demande beaucoup de ram.

              la mémoire utilisée par trueos version server dans une machine virtuelle
              qemu fraîchement installée disposant de 2G de RAM :

              41 M Active, 172 M Wired

              Et ZFS est abondamment utilisé. Il paraît que zfs peut utiliser beaucoup
              de cache, mais le libère à la demande.

              • [^] # Re: Cas d'utilisation ?

                Posté par  (site web personnel) . Évalué à 5.

                Il paraît que zfs peut utiliser beaucoup
                de cache, mais le libère à la demande.

                Oui, si on ne le bride pas avec unvfs.zfs.arc_max="xxxM" dans loader.conf. Sinon, il va remplir son ARC jusqu'à ne laisser qu'un 1G de mémoire physique (vm.kmem_size) ou la moitié, si vous avez moins de 2Go.

                Mais c'est un réglage parmi d'autre. ZFS est configurable en de nombreux points pour l’adapter à votre situation. Par exemple, en activant ou désactivant certaines fonctions comme le prefetch ( désactivé de toute façon sous 4Go) ou en activant et réglant le cache de second niveau, L2ARC, sur un disque SSD.

                A lire dans la doc de FreeBSD, ZFS, advanced.

                Mais, je le déconseille toutefois sur une architecture 32bits. Là, il faut vraiment le régler au plus fin.


                Et ZFS, ce n'est pas grand chose comparé à l'usage courant d'un Desktop aujourd'hui, qui réclame 16Go de RAM pour afficher 50 onglets pleins de javascript, multimédia etc. dans un butineur Web.

    • [^] # Re: Cas d'utilisation ?

      Posté par  (site web personnel) . Évalué à 5.

      +1
      Je me suis posé les mêmes questions

    • [^] # Re: Cas d'utilisation ?

      Posté par  (site web personnel) . Évalué à 7.

      je ne vois pas beaucoup d'intérêt aux BSD par rapport à linux

      La question est mal posée. Comment maintenir sa prod entre la divulgation d'un zéro day et la sortie du correctif ?

      1 - serrer les fesses
      2 - profiter que le libre nous offre plusieurs systèmes de bonne facture pour gérer tranquillement la situation

      La diversité c'est la vie. Avoir plusieurs systèmes prêts pour la production permet d'avoir une segmentation intéressante de son parc et ainsi limiter l'impact des failles.

Suivre le flux des commentaires

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