Sortie de la version DragonFly 3.4

Posté par . Édité par Nÿco, Loïc Blot, Benoît Sibaud, patrick_g et Nicolas Casanova. Modéré par patrick_g. Licence CC by-sa
Tags : aucun
34
30
avr.
2013
DragonFly BSD

DragonFly BSD est un système d'exploitation BSD de type Unix. Après 1500 commits par 23 committers pendant 6 mois de développement, la version 3.4 apporte son lot de nouveautés, avec un nouveau système de gestion des paquets et des performances améliorées.

DragonFly BSD

Sommaire

Espace utilisateur

Logiciels tiers

Jusqu'à présent, il était possible d'installer des logiciels tiers grâce au système pkgsrc. Principalement développé par et pour le système d'exploitation NetBSD, ce système de gestion de paquets sources qui a pour but d'être portable est disponible pour de nombreux OS, comme GNU/Linux, divers BSD, Solaris ou Minix.

Le principal mainteneur de pkgsrc pour dragonfly a décidé de porter un autre système de gestion des paquets qui convenait mieux à ses attentes. DragonFly BSD 3.4 est donc livré avec pkgsrc ainsi qu'avec DPorts. DPorts est une adaptation du système de ports de FreeBSD pour le faire fonctionner sur DragonFly. Uniquement les paquets pouvant être compilés sur dragonfly y sont présent. DPorts est fortement lié au gestionnaire de paquets binaires pkgng développé pour les ports FreeBSD. Il est donc possible d'installer des logiciels en les compilant ou depuis un dépôt binaire, et de mélanger les deux méthodes si par exemple les options par défaut des paquets binaires ne conviennent pas. Actuellement, il y a plus de 19000 paquets binaires disponibles, dont xfce ou KDE 4.10.

Il faut noter que pkgsrc et Dports ne peuvent en théorie pas être utilisés en même temps, pour éviter les conflits, en particulier entre les bibliothèques partagées. Un tutoriel sur l'utilisation simple des ports est disponible, pour une utilisation avancée, on peut se référer à la documentation FreeBSD.

Compilateur par défaut

Lors de la version 3.2, GCC 4.7 avait été introduit dans le système de base. Cependant, c'était toujours GCC 4.4 qui était utilisé par défaut. C'est maintenant GCC 4.7 qui remplit le rôle de compilateur par défaut. GCC 4.7 introduit diverses améliorations, comme les Link Time Optimizations (LTO). De plus, le support d'OpenMP, une API pour la programmation concurrente et parallèle en C/C++, a été ajouté pour GCC 4.7 sur DragonFly. Toutefois, GCC 4.4 est toujours la version par défaut pour DPorts le temps que certains problèmes de compilation soient réglés.

Divers

Comme à chaque version, une partie des outils a reçu des mises à jours ou des améliorations provenant de divers autres BSD, souvent depuis FreeBSD, et les logiciels et bibliothèques tiers distribués dans le système de base ont été mis à jour. De plus, l'implémentation de make utilisée par le système de base est désormais bmake, une version portable dérivée du make de NetBSD. Il est aussi maintenant possible de choisir l'addresse MAC et le numéros de série des interfaces virtuelles et des disques associés aux vkernels. Pour rappel, un vkernel permet l'exécution d'un noyau DragonFly en espace utilisateur, permettant ainsi de déboguer/développer rapidement un noyau sans avoir à redémarrer la machine.

Noyau

Advanced Vector Extensions (AVX)

Le support du jeu d'instructions AVX, permettant de faire du calcul vectoriel sur les nouveaux processeurs Intel et AMD a été ajouté au noyau pour l'architecture x86_64. Les programmes en espace utilisateur peuvent désormais en tirer partie si le compilateur utilisé supporte ce jeu d'instruction (ce qui est le cas de GCC 4.7).

Poudriere : quand le noyau fait BOOM

Poudriere est un outil permettant de compiler à la volée des paquets et de les tester, le tout dans des jails et en parallèle. L'utilisation intensive de poudriere sur DragonFly a permis de mettre en évidence plusieurs points de contention dans différentes parties du noyau lors d'une utilisation massivement parallèle, notamment sur un système opteron à 48 cœurs, ce qui a permis d'améliorer le passage à l'échelle du noyau.

Ces améliorations concernent par exemple la gestion du swap, le système de fichier en mémoire tmpfs, la mémoire virtuelle et les syscalls fork/exec ou la résolution des noms de fichier.

Charge CPU lors d'une utilisation de poudrière

Ce graphique illustre les avancées obtenues. Il représente la charge CPU lors deux exécutions de ~12h de poudrière sur la machine opteron de 48 cœurs. La première partie est une exécution avec un noyau récent, similaire au noyau 3.4, et la deuxième partie avec un noyau plus proche du noyau 3.2. Le noyau récent permet d'utiliser beaucoup mieux le temps CPU alors que le noyau 3.2 est sujet à des problèmes de contention qui limitent l'utilisation CPU. Le temps de compilation des 19000 paquets de DPorts sur l'opteron a été amélioré de plus de 60 %.

tmpfs

Le système de fichier en RAM tmpfs a été fortement amélioré. L'utilisation du MPLOCK a été supprimée, et tmpfs fonctionne désormais avec un verrou par point de montage. D'autres améliorations et corrections de bugs ont conduit à une amélioration drastique des performances de tmpf (presque 100%), comme le montre ce PDF.

Réseau

Comme d'habitude, la pile réseau et les pilotes ont fait l'objet d'une multitude de commits. Ces commits ont permis une amélioration des performances réseau, notamment via l'utilisation de files multiples, et de diminuer la latence. L'exemple le plus concret est sur le pilote igb(4) (Intel 10G) dont l'original plafonnait à 1.5 Gbit/sec et le nouveau à 8.9 Gbit/sec

Quand le noyau a fini de traiter un paquet, le pilote le place dans la file de transmission de la carte réseau pour qu'il soit traité par celle ci. Toutefois, un nombre croissant de cartes réseau modernes supporte plusieurs files de transmission. Elles sont désormais gérées par le noyau et les pilotes igb(4), emx(4), bce(4).

Ce travail, ainsi que diverses optimisations, améliore fortement les performances du forwarding de paquets, comme détaillé dans ce mail.

Projet

Distribution

DragonFly est disponible sous forme d'iso et d'img disque bootables, ainsi que d'image disque bootable contnenant un environnement graphique et quelques logiciels pré-installés.

Google Summer of Code

DragonFly a été accepté comme organisation pour la 5e année consécutive, et participera donc au GSoC 2013.

  • # Très bonne dépêche, mais un Modo est-il passé par là ?

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

    Ça fait plaisir de voir une dépêche sur DragonFly BSD !

    Cependant, je me demande si elle a vraiment été relue par les modérateurs, car elle contient pas mal de fôtes qui passent quand on est fatigué…

  • # Pkgng ? Pkgin ?

    Posté par . Évalué à  2 .

    C'est quand même très étonnant. Pkgin est jeune, et il se retrouve déjà abandonné au profil de Pkgng ?
    Pkgng est censé remplacer pkg dans FreeBSD, mais leurs repos sont fermés depuis presque 6 mois.
    On a l'impression que sous *BSD (abus de langage, je sais) on ne sait pas trop comment gérer ces satanés logiciels tiers…

    • [^] # Re: Pkgng ? Pkgin ?

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

      Je présume que tu parles du repo.

      J'utilise tous les jours pkgng, qui référence mes ports compilés sur l'ensemble de mes FreeBSD 9.1 (une vingtaine de serveurs) et c'est une vraie petite merveille. Plein de petites fonctionnalités intéressantes, même si ca utilise sqlite (et qu'on doive le compiler pour l'utiliser)

      Le fait que DragonFly passe sur pkgng est une bonne nouvelle. Ils ont en équipe plus restreinte que FreeBSD et ca leur fait une chose de moins à maintenir, l'arbre de ports étant lourd et long à gérer.

      CNRS & UNIX-Experience

      • [^] # Re: Pkgng ? Pkgin ?

        Posté par (page perso) . Évalué à  2 . Dernière modification : le 30/04/13 à 19:04

        Notons que sqlite est intégré dans pkgng, ça n'utilise pas de port à part et ce pour l'intégration dans le système de base.

        Love, bépo.

      • [^] # Re: Pkgng ? Pkgin ?

        Posté par . Évalué à  3 .

        Le fait que DragonFly passe sur pkgng est une bonne nouvelle. Ils ont en équipe plus restreinte que FreeBSD et ca leur fait une chose de moins à maintenir, l'arbre de ports étant lourd et long à gérer.

        Pas d'accord.
        pkgsrc est fait pour être portable, pas les ports FreeBSD et donc ils sont obligés de maintenir des patches (DPorts). Avec pkgsrc, en théorie il n'y a rien à maintenir.

        D'après le HowTo de DPorts, c'est expérimental, espérons qu'ils garderont pkgsrc/pkgin.

        • [^] # Re: Pkgng ? Pkgin ?

          Posté par . Évalué à  1 .

          Bon je me suis un peu trop affolé, je pense pas que pkgsrc sera remplacé :

          http://lists.dragonflybsd.org/pipermail/users/2013-January/053067.html

          "We are still actively participating in pkgsrc. DPorts is simply an additional option for users."

          • [^] # Re: Pkgng ? Pkgin ?

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

            Discutant avec l'un des participants du projet, qui m'a parlé de la machine qui compile en chaîne les dports sur poudrière, je sais qu'ils sont chauds pour les dports. Depuis janvier je ne sais pas exactement quel est leur dessein mais les dports attireraient des FreeBSD user comme moi :)

            CNRS & UNIX-Experience

            • [^] # Re: Pkgng ? Pkgin ?

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

              les dports attireraient des FreeBSD user comme moi

              Tu pourrais expliquer pourquoi ? Dans ma maigre expérience BSDiste, j'ai toujours considéré que les ports de FreeBSD étaient plus ou moins la même chose que le pkgsrc de NetBSD, du coup je ne comprends pas bien l'intérêt de Dports.

              • [^] # Re: Pkgng ? Pkgin ?

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

                Une simplicité d'utilisation, une finesse de configuration et de gestion au quotidien (de mon point de vue), après je n'ai pas d'expérience sur NetBSD, et pkgsrc m'a toujours paru moins intéressant en terme de configuration

                CNRS & UNIX-Experience

    • [^] # Re: Pkgng ? Pkgin ?

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

      Ça n'a rien d'étonnant, pkgin c'est pour pkgsrc, et ça fonctionne au dessus des pkg_tools.
      pkgng c'est pour les ports FreeBSD (ici DPorts) et ça remplace les pkg_* tools. Les repos binaires pour pkgng sont fermés depuis 6 mois, parce que l'on a décidé de reconstruire toute la chaine de distribution de packages et ça ne se fait pas en 2 jours (avec tous pleins de trucs fashion et tout).

      En attendant PC-BSD propose des repos binaries pour FreeBSD 9.1 qui fonctionnent très bien et http://mirror.exonetric.net/pub/pkgng/README.txt propose des paquets binaires pour toutes les versions supportées (8, 9 et 10) pour i386 et amd64.

      Sous BSD on sait très bien gérer ces logiciels tiers, pkgng utilise toujours la même infra (les ports) pour la construction de packages, pour l'utilisateur final, il y a peu de changement de passer de pkg_install (tous les vieux pkg_) a pkgng si il utilisait les ports.

  • # Procédé d'upgrade propre inexistant

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

    Il faut noter que DragonFlyBSD ne dispose pas de système d'upgrade, contrairement à FreeBSD (freebsd-update), ou OpenBSD (via le CD d'installation). Il faut télécharger les sources, compiler puis installer (et prier ? :p).

    Le plus long est le premier fetch du repository. Je vous donne ma méthode d'upgrade:

    cd /usr
    make src-create
    cd /usr/src
    git branch DragonFly_RELEASE_3_4 origin/DragonFly_RELEASE_3_4
    git checkout DragonFly_RELEASE_3_4
    make buildworld -j4
    make installworld
    make buildkernel -j4
    make installkernel
    
    

    CNRS & UNIX-Experience

    • [^] # Re: Procédé d'upgrade propre inexistant

      Posté par . Évalué à  3 .

      Tu cites le cas d'une mise à jour d'une version à une autre.
      Mais que se passe-t-il si on souhaite juste corriger une faille dans un composant ?

      A ma connaissance freebsd-update gère cela.

      Mais sur les autres *BSD ça n'existe pas. Il faut télécharger le code source à jour et compiler. Ou alors attendre la prochaine release. Bon il semble que sur OpenBSD il n'y ait jamais de faille.

      Il fut un temps où j'avais un serveur tournant à 500Mhz avec 256MB de ram. Et la compilation du world et kernel de freebsd (version 9.0) prenait 22 heures !

      • [^] # Re: Procédé d'upgrade propre inexistant

        Posté par . Évalué à  1 .

        Il fut un temps où j'avais un serveur tournant à 500Mhz avec 256MB de ram. Et la compilation du world et kernel de freebsd (version 9.0) prenait 22 heures !

        Typiquement le genre de machine sur lequel on ne veut pas compiler un noyau. D’autant qu’il s’agit d’un serveur, donc installer un compilateur dessus est une hérésie ! Mais, oui la cross-compilation des BSD a toujours été quelque peu difficile à mettre en place.

        • [^] # Re: Procédé d'upgrade propre inexistant

          Posté par . Évalué à  -1 .

          Typiquement le genre de machine sur lequel on ne veut pas compiler un noyau.

          Pas sûr, j'ai le même genre de machines, et linux 3.8 avec juste les pilotes (modules) qu'il faut prend 3 heures, et non 22.

          • [^] # Re: Procédé d'upgrade propre inexistant

            Posté par . Évalué à  4 .

            En même temps tu compares une compilation du noyau Linux à un make kernel & world. Tu m'étonnes que c'est plus long. Les versions de gcc peuvent pas mal jouer aussi.

            D'une manière générale, il a dit serveur. Quelque soit la puissance de ta machine, en général c'est pas une très bonne idée de faire des compiles (ou une autre tâche longue qui bouffe de l'IO & CPU) sur de la prod. Ca serait con d'exploser ton SLA, un service ou la machine…

            • [^] # Re: Procédé d'upgrade propre inexistant

              Posté par . Évalué à  -2 .

              En même temps tu compares une compilation du noyau Linux à un make kernel & world.

              Non. Relis bien. Ce que j'ai cité parlait uniquement d'un noyau (kernel).

              Quant au reste : Oh really ? :p

        • [^] # Re: Procédé d'upgrade propre inexistant

          Posté par . Évalué à  2 .

          En pratique dans le cas de DragonFly, il me semble qu'il te suffit de partager /usr/obj/src/ et de faire uniquement

          make installkernel
          make installworld

          sur les machines clientes.

          Pour le partage, tu peux utiliser NFS, ou alors les mirror-stream de HAMMER pour répliquer le PFS HAMMER vers les machines clientes.

        • [^] # Re: Procédé d'upgrade propre inexistant

          Posté par . Évalué à  3 .

          Salut,

          Mais, oui la cross-compilation des BSD a toujours été quelque peu difficile à mettre en place.

          Comment ça?
          Sous NetBSD, l'OS se cross-compile très bien avec build.sh :) .

      • [^] # Re: Procédé d'upgrade propre inexistant

        Posté par . Évalué à  1 .

        C'est très simple, il suffit d'utiliser git.

        git pull
        make quickworld
        make buildkernel

        puis d'installer. Pour info, j'ai un atom simple coeur, et la compilation avce quickworld prend ~2h. En pratique, sur un i7 ou un cpu récent, un quickworld prend 10 minutes en fonction des bibliothèques mises à jour, ça peut être plus.

    • [^] # Re: Procédé d'upgrade propre inexistant

      Posté par . Évalué à  3 .

      Il faut télécharger les sources, compiler puis installer (et prier ? :p).

      Prier n'est pas nécessaire en général, un buildworld à partir d'une release vers une release échoue très très rarement.

      FreeBSD a commencé à mettre en place des mises à jours binaires pour le noyau et la base, je crois.

      • [^] # Re: Procédé d'upgrade propre inexistant

        Posté par (page perso) . Évalué à  1 . Dernière modification : le 02/05/13 à 18:00

        Ils n'ont pas commencé, ils l'ont fait, c'est la commande freebsd-update qui existe au moins depuis FreeBSD 8.0. Elle met à jour les binaires mais également les sources kernel+world dans /usr/src

        CNRS & UNIX-Experience

  • # Intérêt réel des BSD ?

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

    Bonsoir. Mon titre peut paraître un appel au troll, mais il n'en est rien.

    J'aime les logiciels libres et pour moi, la licence BSD offre plus de liberté que la GPL. Cependant, une licence ne fait pas tout et même si le monde BSD me fait du pied, j'avoue n'avoir jamais trouvé une réelle utilité à m'y mettre. Car il faut bien l'avouer, je ne crois pas à ma connaissance que BSD à quelque chose de plus que Linux. Il parait qu'il y a les "jails" mais j'avoue ne pas en voir vraiment l’intérêt.

    Si un BSDistes pouvait éclairer ma lanterne et me donner l'envie de me mettre à étudier ce système, je lui en serais redevable.

    Librement.

    • [^] # Re: Intérêt réel des BSD ?

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

      Si un BSDistes pouvait éclairer ma lanterne et me donner l'envie de me mettre à étudier ce système, je lui en serais redevable.

      Y a énormément de documentation et les mêmes logiciels que sous "linux". Une nouvelle release d'OpenBSD sort demain, c'est extrêmement bien fait. Puis tu peux chanter devans les copains. Pour le reste, à partir du moment ou tu sais lire une documentation, que ce soit Free, Open, Net, Dragon, c'est une histoire de goûts. Tu les feras tous de toute façon :-p

    • [^] # Re: Intérêt réel des BSD ?

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

      Sommaire

      Eh bien que dire, en fait on va dire sur Linux touche à tout et que chaque distribution BSD se spécialise plutôt. En terme d'hyperviseur le choix est vite fait, aucun ne sait y faire. FreeBSD 10 devrait intégrer le BHyvE on verra ce que ca donne mais déjà que KVM peine à rentrer en entreprise alors le BHyvE j'y crois moyen.

      FreeBSD

      Une merveille en terme de services. Un arbre de ports qui permet de personnaliser à l'extrême en compilant ses programmes et ainsi avoir d'excellentes performances tout en privilégiant la légèreté et la simplicité.
      L'ensemble de la configuration système (services + réseau) se fait dans le fichier /etc/rc.conf, c'est très agréable, un petit screen du fichier /etc/rc.conf de ma VM Z-Eye par exemple:

      Freebsd-rc.conf

      Le kernel BSD est très stable, je n'ai jamais eu de kernel panic en 2 ans d'utilisation, les upgrades système ne cassent pas les paquets et il est possible de rester sur la version 8 et de bénéficier des logiciels récents grâce aux ports, on n'est pas bloqués (sauf longtemps plus tard, lorsque certaines librairies systèmes sont incompatibles avec les ports, c'est souvent le signe d'un système non maintenu).

      Un autre bénéfice le système de fichiers ZFS qui permet de faire du raid simple,double,triple parité avec déduplication de blocs, sans contrôleur RAID (nécessite en contrepartie un peu de CPU et RAM). Dernier bénéfice l'excellent PF (malheureusement pas dans sa dernière version)

      Le système est facile à prendre en main, il faut juste retenir 4 choses: portsnap (pour gérer l'arbre de ports), freebsd-update (pour mettre à jour la distrib, que ce soit d'une version mineure à une autre ou une majeure), /etc/rc.conf et pour finir make (install clean|config)

      Inconvénient:
      peut être pas assez utilisée ? :)

      OpenBSD

      Le meilleur système d'exploitation libre en terme de réseau et sécurité. Une distribution légère en terme de RAM (1.5Mo si vous mettez 2 getty, sans services), qui possède de manière intégrée tout ce qu'il faut pour faire du réseau
      - déploiement: dhcpd, named, radvd
      - routage: routage ipv4/ipv6 optimisé, domaines de routages, ripd, openOSPFd (ipv4 + ipv6, qui est maintenu par la team), openBGPd (ipv4+ipv6, lui aussi maintenu par la team)
      - sécurité: Packet Filter dans une version optimisée et à jour (ce sont les mainteneurs), un pare-feu qui a le mérite d'être maintenable et d'être extrêmement rapide. Il peut également faire un très bon load balancer sur la couche de niveau 4 OSI
      - CARP: la version la plus évoluée de carp (qui est développée par eux à l'origine), avec le mode master/multi-slave mais également le loadbalancing IP/ARP

      Les points à retenir:
      un système très simple, extrêmement robuste axé sécurité et réseau, qui fera un excellent routeur/firewall de bordure mais également un très bon routeur interne. (si vous êtes en 10G privilégiez des cartes utilisant le driver ixgb/ixgbe)

      Inconvénients:
      la team a la même philosophie que Debian en matière de libre ce qui pềche niveau drivers (la broadcom 5720 des derniers serveurs Dell ne sera intégrée que dans OpenBSD 5.3, enfin c'est du Broadcom on devrait boycotter).
      Des paquets qui peuvent être trop anciens parfois (squid 2.7 quand tu nous tiens).

      DragonFlyBSD

      Un fork de FreeBSD qui monte. Une excellente distribution en terme de performances NFS grâce au système de fichiers Hammer. Elle est très intéressante pour faire tourner des bases postgreSQL mais également faire cluster de fichier NFS (en master/slave).

      Le système de fichiers Hammer, qu'on ne présente plus, un excellent système de fichiers qui permet de récupérer les fichiers et retourner en arrière sur les noeuds, qui se gère par une notion de PFS (pseudo file system), dont chacun peut avoir un quota, et chaque PFS peut être répliqué sur 1 ou plusieurs serveurs slaves, en parallèle ou en cascade. Le système de fichiers est transactionnel, ce qui permet comme une DB d'aller d'un point A à une point C et retourner vers B ensuite, ou s'y arrêter en chemin.
      La réplication est transactionnelle et se passe via SSH (=> chiffrement de la réplication), et peut être faite de manière discontinue (je l'utilise par exemple pour sauvegarder les données de mon serveur mail 1 fois par semaine. Le dimanche j'allume une VM DragonFly montant un DD externe, je lance la réplication et il récupère le delta de la semaine).

      Hammer2 qui devrait arriver cette année promet d'être intéressant également, puisqu'il permettra du multimaster, et donc on pourra s'amuser à loadbalancer les serveurs NFS :D

      Les points à retenir:
      Excellentes performances NFS, un des meilleurs FS libres actuels, de très bonnes performances pour PostGreSQL. Se gère comme FreeBSD en terme de services.

      Inconvénients:
      Un team peut être pas assez grande pour leurs ambitions ? Un installeur archaïque. Pas de méthode d'upgrade sans devoir compiler la distribution

      CNRS & UNIX-Experience

      • [^] # Re: Intérêt réel des BSD ?

        Posté par (page perso) . Évalué à  2 . Dernière modification : le 30/04/13 à 22:35

        J'oubliais NetBSD,
        réservée au monde de l'embarqué elle suit son chemin, mais peine face à Linux, qui depuis quelques années envahit ses plates bandes.

        et j'ajouterais également qu'OpenBGPd fonctionne à merveille avec les BGP propriétaires CISCO et Alcatel (expérience de cette année), et qu'openOSPF fonctionne parfaitement avec l'OSPF CISCO

        CNRS & UNIX-Experience

        • [^] # Re: Intérêt réel des BSD ?

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

          Si je puis me permettre, comme techniquement tout est dit à peu près, le jour où tu souhaites te lancer dans un BSD, vérifie bien que le système répondra à tes attentes (typiquement faire du desktop avec OpenBSD sera plus contraignant qu'avec FreeBSD [et en ce qui concerne NetBSD ou DragonFly, jamais essayé donc je n'en ferai pas mention]) et qu'il est compatible avec ton matériel, dans le cas où tu voudrais une installation en dur.

          Abandonne tout désire de faire tourner FreeBSD sur des cartes intel. Ah non non non, ça n'est pas parce que le pilote existe qu'il suffit à ce que tout se passe bien, d'ailleurs La page de ce pilote fait mention de quelques limitations.

          Pour le reste, les BSD je trouve ça sexy mais quand on vient d'un monde GNU/Linux, il faut arrêter de penser GNU/Linux ;)

          Love, bépo.

          • [^] # Re: Intérêt réel des BSD ?

            Posté par . Évalué à  3 .

            FreeBSD pour les cartes Intel c'est pour la version 10 non ?
            Quand leur Kernel-Mode-Setting sera activé par défaut et pourra supporter le pilote.
            Cette version 10 elle troue le cul sur papier : virtualisation, kms, pkgng par défaut…

            • [^] # Re: Intérêt réel des BSD ?

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

              Ben le pilote et KMS ont été importé dans la branche stable, mais c'est inutilisable. Mieux vaut encore le pilote Vesa.

              Love, bépo.

              • [^] # Re: Intérêt réel des BSD ?

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

                Qu'est ce qui est inutilisable je l'utlise tous les jours sur des 9.1-RELEASE, 9-STABLE et 10-CURRENT ça marche très je n'ai rien eu a déplorer. En quoi VESA est mieux?

            • [^] # Re: Intérêt réel des BSD ?

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

              tu oublies la réécriture de portsnap qui ne fait plus un spam tous les 10 paquets à l'écran :p et le support du Raspberry PI, la compilation du kernel et du userland avec clang par défaut

              CNRS & UNIX-Experience

        • [^] # Re: Intérêt réel des BSD ?

          Posté par . Évalué à  9 .

          NetBSD, réservée au monde de l'embarqué

          Le premier OS du monde à tourner en AMD64 natif était NetBSD. Ce n'est pas exactement de l'embarqué :-)

          • [^] # Re: Intérêt réel des BSD ?

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

            effectivement leur but est la portabilité et la légèreté, mais personnellement faire un serveur NetBSD n'a d'intérêt que sur des petites architectures, il n'est pas suffisant axé performances et services

            CNRS & UNIX-Experience

            • [^] # Re: Intérêt réel des BSD ?

              Posté par . Évalué à  4 . Dernière modification : le 01/05/13 à 22:01

              Salut,

              un serveur NetBSD n'a d'intérêt que sur des petites architectures, il n'est pas suffisant axé performances et services

              Ce n'est pas un poil exagéré, non? ;)

              Il est vrai que la taille du projet n'est pas la même que celle de FreeBSD et que probablement le rythme de développement n'est pas aussi rapide, mais le projet reste "compétitif".

              D'une part, comme souligné, il supporte un grand nombre d'archi. et effectivement les paramètres par défauts sont l'ensemble commun à toutes les archis (allant de l'embarqué jusqu'aux serveurs de prod.), mais je pense qu'une fois optimisé, l'OS fournit des perf. qui ne sont pas à rougir.

              D'autre part, par exemple, NetBSD est assez avancé concernant la virtualisation et ce n'est donc pas seulement pour les cartes de l'embarqué. Par exemple:
              * On peut s'en convaincre avec Xen. NetBSD supporte Xen depuis longtemps (et maintenant les outils Xen supportent dorénavant NetBSD depuis la 4.2). Un Dom0, un DomU en SMP, un driver balloon pour l'allocation dynamique de mémoire . Comparativement, par exemple à Linux et au regard de la taille du projet, c'est très bon: comparatifs au XenSummit, support natif de Xen 4.2 dans NetBSD
              * Un driver pour les outils vmware: vmt

              Bien sûr, il y a des choses à améliorer, mais NetBSD reste, il me semble, un bon projet pour des services.

      • [^] # Re: Intérêt réel des BSD ?

        Posté par . Évalué à  6 .

        Excellente présentation, mais tu as oublié de citer les jails qui sont un excellent point pour FreeBSD.
        Très simple à gérer, et intégré à l'OS. Des outils comme ezjail sont juste merveilleux.
        Si vous trouvez que LXC c'est de la magie noire qui ne sort jamais de logs quand ça marche pas, essayez les jails sur FreeBSD !

      • [^] # Re: Intérêt réel des BSD ?

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

        Merci à toi pour ce résumé. Donc si j'ai bien compris, FreeBSD, c'est pour le desktop. Voilà pourquoi PC-BSD se base dessus. OpenBSD, c'est pour les serveurs avec des services réseaux.

        • [^] # Re: Intérêt réel des BSD ?

          Posté par . Évalué à  4 .

          Non, il est plus correct de dire que FreeBSD est le mieux taillé pour les desktop (logiciels beaucoup plus à jour et meilleur support matériel). En revanche il est très bon dans les rôles de serveur (notamment pour les jails).
          OpenBSD est axé sécurité et simplicité.
          NetBSD c'est la portabilité.

          • [^] # Re: Intérêt réel des BSD ?

            Posté par (page perso) . Évalué à  1 . Dernière modification : le 02/05/13 à 18:05

            Je ne parlais pas de desktop mais uniquement de serveurs et services. Pour le desktop si les drivers X11 avancent FreeBSD suit. Un gros soucis c'est les outils genre NetworkManager qui ne marchent pas sous BSD, donc allez hop à la main la gestion wifi :p (peut être wicd ?).

            En résumé:
            - NetBSD: portabilité & embarqué
            - FreeBSD: services & performances
            - OpenBSD: sécurité & réseau
            - DragonFlyBSD: Clusters de fichiers & DB

            Après, comme Linux tend vers Wayland, il faudra que BSD suive, il y a déjà des développeurs fous qui ont commencé à le porter sur FreeBSD, mais à mon avis on a encore le temps.

            CNRS & UNIX-Experience

  • # Mauvais lien poudriere

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

Suivre le flux des commentaires

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