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.
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.
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.
Aller plus loin
- Site officiel (228 clics)
- Notes de version 3.4 (42 clics)
- Téléchargement (58 clics)
# Très bonne dépêche, mais un Modo est-il passé par là ?
Posté par Jiehong (site web personnel) . É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é…
[^] # Re: Très bonne dépêche, mais un Modo est-il passé par là ?
Posté par claudex . Évalué à 4.
Les modérateurs sont aussi fatigués sans doute.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Très bonne dépêche, mais un Modo est-il passé par là ?
Posté par Naha (site web personnel) . Évalué à 7.
Ce serait bien si l'un d'entre eux pouvait corriger cet affreux anglicisme (l'auteur a bien sûr voulu dire intensive).
[^] # Re: Très bonne dépêche, mais un Modo est-il passé par là ?
Posté par Loïc Blot (site web personnel) . Évalué à 3.
oups pardon c'est moi même qui ai fait cette faute, je devais être fatigué, je voulais dire intensive :p
Veepee & UNIX-Experience
[^] # Re: Très bonne dépêche, mais un Modo est-il passé par là ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Corrigé, merci.
# Pkgng ? Pkgin ?
Posté par MTux . É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 Loïc Blot (site web personnel) . É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.
Veepee & UNIX-Experience
[^] # Re: Pkgng ? Pkgin ?
Posté par Anonyme . Évalué à 2. Dernière modification le 30 avril 2013 à 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.
[^] # Re: Pkgng ? Pkgin ?
Posté par trucmachin973 . Évalué à 3.
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 trucmachin973 . É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 Loïc Blot (site web personnel) . É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 :)
Veepee & UNIX-Experience
[^] # Re: Pkgng ? Pkgin ?
Posté par Naha (site web personnel) . Évalué à 3.
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 Loïc Blot (site web personnel) . É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
Veepee & UNIX-Experience
[^] # Re: Pkgng ? Pkgin ?
Posté par Bapt (site web personnel) . É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 Loïc Blot (site web personnel) . É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:
Veepee & UNIX-Experience
[^] # Re: Procédé d'upgrade propre inexistant
Posté par MTux . É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 neil . Évalué à 1.
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 xcomcmdr . Évalué à -1.
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.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Procédé d'upgrade propre inexistant
Posté par ckyl . É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 xcomcmdr . Évalué à -2.
Non. Relis bien. Ce que j'ai cité parlait uniquement d'un noyau (kernel).
Quant au reste : Oh really ? :p
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Procédé d'upgrade propre inexistant
Posté par Enj0lras . É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 wolowizard . Évalué à 3.
Salut,
Comment ça?
Sous NetBSD, l'OS se cross-compile très bien avec build.sh :) .
[^] # Re: Procédé d'upgrade propre inexistant
Posté par Enj0lras . É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 Loïc Blot (site web personnel) . Évalué à 1.
De même, sur mes 3 VM dual core, le téléchargement de git + process tel que je l'ai décrit plus haut m'a pris 3h (processeur 2.8Ghz)
Veepee & UNIX-Experience
[^] # Re: Procédé d'upgrade propre inexistant
Posté par Enj0lras . Évalué à 3.
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 Loïc Blot (site web personnel) . Évalué à 1. Dernière modification le 02 mai 2013 à 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
Veepee & UNIX-Experience
# Intérêt réel des BSD ?
Posté par Atem18 (site web personnel) . É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 damien . Évalué à 1.
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 Loïc Blot (site web personnel) . É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:
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
Veepee & UNIX-Experience
[^] # Re: Intérêt réel des BSD ?
Posté par Loïc Blot (site web personnel) . Évalué à 2. Dernière modification le 30 avril 2013 à 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
Veepee & UNIX-Experience
[^] # Re: Intérêt réel des BSD ?
Posté par Anonyme . É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 ;)
[^] # Re: Intérêt réel des BSD ?
Posté par MTux . É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 Anonyme . Évalué à 1.
Ben le pilote et KMS ont été importé dans la branche stable, mais c'est inutilisable. Mieux vaut encore le pilote Vesa.
[^] # Re: Intérêt réel des BSD ?
Posté par Bapt (site web personnel) . É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 Loïc Blot (site web personnel) . É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
Veepee & UNIX-Experience
[^] # Re: Intérêt réel des BSD ?
Posté par Kerro . Évalué à 9.
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 Loïc Blot (site web personnel) . É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
Veepee & UNIX-Experience
[^] # Re: Intérêt réel des BSD ?
Posté par wolowizard . Évalué à 4. Dernière modification le 01 mai 2013 à 22:01.
Salut,
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 MTux . É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 Anonyme . Évalué à 1.
Il y a un outil semblable aux cgroups avec les jails ?
[^] # Re: Intérêt réel des BSD ?
Posté par MTux . Évalué à 5.
Quelqu'un utilise les cgroups en dehors de fedora ?
[^] # Re: Intérêt réel des BSD ?
Posté par Anonyme . Évalué à 2.
Je suis sous Fedora :D
[^] # Re: Intérêt réel des BSD ?
Posté par Loïc Blot (site web personnel) . Évalué à 1.
Tu as raison, je ne les utilise jamais, mais il faut que je m'y mette depuis le temps que tout le monde m'en parle :p
Veepee & UNIX-Experience
[^] # Re: Intérêt réel des BSD ?
Posté par Atem18 (site web personnel) . É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 MTux . É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 Loïc Blot (site web personnel) . Évalué à 1. Dernière modification le 02 mai 2013 à 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
fousqui ont commencé à le porter sur FreeBSD, mais à mon avis on a encore le temps.Veepee & UNIX-Experience
# Mauvais lien poudriere
Posté par Bapt (site web personnel) . Évalué à 4.
Le lien poudriere pointe sur http://en.wikipedia.org/wiki/Advanced_Vector_Extensions au lieu de pointer sur https://fossil.etoilebsd.net/poudriere
[^] # Re: Mauvais lien poudriere
Posté par patrick_g (site web personnel) . Évalué à 3.
C'est corrigé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.