DragonFly BSD 4.4

Posté par . Édité par Rolinh, Benoît Sibaud, Lucas, palm123, Pierre Jarillon et eggman. Modéré par Xavier Claude. Licence CC by-sa
Tags :
38
21
déc.
2015
DragonFly BSD

Le 7 décembre dernier, Justin Sherill a officiellement annoncé la disponibilité de DragonFly BSD 4.4 en version finale (et non le 4 décembre, comme annoncé ailleurs…). Comme cela est le cas depuis quelques versions, la pile DRM a subi de profonds changements améliorant grandement la prise en charge des GPU Intel et AMD. La pile réseau, elle, a été revue afin d’en améliorer (encore) les performances. Autre point majeur : une revue en profondeur de la prise en charge des locales et collation en fonction de celles-ci. De plus amples détails se trouvent dans la suite de la dépêche.

Sommaire

Noyau

En bref

  • Amélioration de l'économie d'énergie CPU ;
  • Ajout d'un nouveau pilote corepower(4), contribution de Imre Vadász ;
  • Réduction de la contention lors de l'allocation de fichiers ;
  • Réduction de la contention kqueue ;
  • ACPICA mis à jour vers 20151124 ;
  • Suppression de l'ordonnanceur disque dsched, connu pour comporter de nombreux bugs depuis des années qui n'ont jamais été corrigés, et qui avait des problèmes avec les SSDs ;
  • Changement des algorithmes de gestion de situations mémoires basses et du tueur OOM.
  • La suppression de code prévu pour gérer l'architecture i386 (32-bit) est presque finie grâce à un sacré nombre de commits de Sascha Wildner

Pilotes graphiques

L'affichage DRM de la console est maintenant activé par défaut. Les terminaux virtuels ne devraient plus afficher d'écran noir après l'activation du mode graphique sous X.Org.
Le système traditionnel de terminaux virtuels utilisé depuis les années 1990 s'attendait à parler à un adaptateur d'affichage compatible VGA, mais depuis la mise en place de la gestion des modes d'affichage dans le noyau (KMS), les adaptateurs d'affichage sont laissés dans leur mode de fonctionnement natif et ne peuvent plus gérer le mode texte 80x25 caractères traditionnel une fois initialisés en mode graphique.
Passer d'un environnement X11 à un terminal texte avec ctrl-alt-f1 par exemple affichait juste ainsi un écran noir.
Le nouveau système de console permet d'afficher à nouveau des caractères texte tout en restant en mode graphique et sans changer la résolution de l'écran.

Le pilote drm/i915 était auparavant basé sur Linux 3.14 et a été mis à jour vers Linux 3.18. Il inclut également quelques correctifs de bugs basés sur Linux 3.19.

Les changements principaux sont :

  • Une grande amélioration du support pour les GPUs Broadwell :
    • L'accéleration est maintenant complètement opérationelle,
    • Le cache eDRAM L4 géant est maintenant activé quand il est présent (certaines puces Broadwell ont un cache L4 de 128MB),
    • Les commandes GPU peuvent maintenant être soumises via un nouveau mécanisme execlist ;
  • Les GPUs Valleyview / Baytrail (SOCs Atom 22nm) sont maintenant pris en charge ;
  • Ajout de la prise en charge des GPUs Cherryview (SOCs Atom 14nm, non testé) ;
  • Travail préparatoire pour pouvoir gérer les GPUs de la famille Skylake ;
  • Amélioration de la gestion de l'énergie en fonctionnement ;
  • La technologie Panel Self-Refresh (PSR) est maintenant activée par défaut sur les familles de GPU Haswell et Broadwell, ce qui contribue à diminuer encore plus la consommation d'énergie.

Comme d'habitude, ces changements majeurs s'accompagnent de corrections de bugs et d'améliorations de performances diverses pour la plupart des générations de GPU.

Le pilote drm/radeon était quant à lui auparavant basé sur Linux 3.11 et a été mis à niveau vers Linux 3.18 par Rimvydas Jasinskas.
Les capteurs de température sont maintenant gérés.

Réseau

La couche réseau a, une fois de plus, été l’œuvre d'un travail en profondeur par Sepherosa Ziehau. On peut noter notamment l'implémentation en mode asynchrone de pru_attach pour TCP et UDP et pru_connect pour UDP, ce qui permet de soutenir des charges de travail encore plus élevées.

Un pilote iwm(4) a été ajouté pour la gestion des cartes Wifi 802.11ac Intel AC 3160, AC 7260 et AC 7265.
Le pilote re(4) a été modifié pour prendre en charge les puces réseau Realtek 8168H.

Parmi les nombreuses améliorations dans la gestion du réseau apportées par DragonFly 4.4, on peut noter également:

  • Une fenêtre TCP plus large par défaut, ce qui permet d'obtenir de meilleurs taux de transfert avec des connections à latence élevées
  • Les valeurs nmbcluster sont maintenant ajustables à la volée, ce qui est utile pour la gestion de trafic réseau ayant besoin de performances extrêmes
  • Certains éléments de la pile IPv6 ont été synchronisés avec FreeBSD; rtadvd(8) et rtadvctl(8) ont été importés depuis FreeBSD 10.
  • Les performances de l'appel système socket(2) ont été améliorées pour les connexions TCP et UDP
  • L'appel système accept(4) a été ajouté
  • La gestion des flags SOCK_CLOEXEC and SOCK_NONBLOCK pour les appels système socket(2) et accept4(2) a été ajouté
  • Import d'une version améliorée de ipfw depuis FreeBSD, appelée ipfw3 dans DragonFly.

Systèmes de fichiers et stockage

Gestion des périphériques

Tomohiro Kusumi a apporté de nombreuses corrections de bugs au pilote de disques virtuels dm(4).
Il a également ajouté des cibles dm-flakey et dm-delay afin de simuler des erreurs disques et des latences élevées. Ces nouvelles fonctionnalités seront très utile pour améliorer la tolérance aux pannes et la robustesse des systèmes de fichier HAMMER et HAMMER2.

HAMMER

Tout comme pour la précédente version de DragonFly, Tomohiro Kusumi a procédé à un grand nettoyage du code de HAMMER. En fait, le nombre de ses commits sur ce système de fichier en font même le contributeur principal à DragonFly en terme de nombre de commits pour cette version (plus de 300)!
Son travail s'étend de simples corrections de commentaires dans les sources ou de page de manuel à de corrections plus importantes, du refactoring ou des améliorations de performances voir de la suppression de code obsolète.
On peut noter notamment l'ajout de fonctions relatives aux statistiques sur les zones.

HAMMER2

Hammer2 gère maintenant les points de montage racine et la déduplication à la volée. Des systèmes de fichier Hammer2 peuvent être créés pour tester sur une machine unique.
La récupération de l'espace disque libéré n'est toujours pas automatique et le système de fichier peut se retrouver dans un état non récupérable si l'espace libre vient à manquer.
Comme toutes les opérations sont du type copy-on-write, des mécanismes additionnels sont nécessaires pour rectifier une situation où il n'y a plus d'espace libre.

L'option WANT_HAMMER2 a besoin d'être ajoutée dans /etc/make.conf et le système d'exploitation recompilé afin que le code Hammer2 soit activé.

Hammer2 est toujours expérimental et il est recommandé de ne pas l'utiliser sauf avec des données qui peuvent être perdues sans dommage. Le format de stockage physique des données va continuer à changer de manière incompatible.

Le travail a généralement progressé, avec le frontend essentiellement stable et passant la plupart des stress tests pour systèmes de fichier.
Une solution pour le problème des liens durs (concernant le renommage de répertoires faisant partie du chemin pour arriver à un lien dur) a été mise en place. La cible physique du lien dur était précédemment stockée dans le répertoire parent le plus commun de tous les liens durs. Maintenant, la cible du lien dur est placée encore plus haut dans l'arborescence des répertoires, dans le répertoire le plus commun ayant le chflag 'xlink' activé. Les renommages à travers les points xlink ne sont pas autorisés.

Le travail continue sur le backend, qui est l'endroit où toute la sophistication va se trouver. Le backend est maintenant threadé, avec un ou plusieurs threads par disque physique. Le frontend réplique et dispatche les requêtes, collecte les résultats et réalise les opérations de cluster comme la validation de quorum. Il est capable de détacher et annuler le reste d'une requête une fois que suffisamment de progrès a été accompli.
L'idée est que si un disque physique est bloqué, le problème ne se propage pas au frontend et le bloque à son tour. Ce travail est préliminaire mais le design a l'air solide jusqu'à présent.

Les fonctionnalités de clustering ne sont pas prêtes à être testées du tout pour l'instant.

Espace utilisateur

Chamboulement complet du système de locales

Les données pour toutes les catégories de locales (LC_CTYPE, LC_COLLATE, LC_TIME, LC_NUMERIC, LC_MONETARY, LC_MESSAGES) proviennent maintenant d'une seule source, le Unicode CLDR Project .

Plusieurs locales avec trois composants ont été introduites, comme zh_Hans_CN, zh_Hant_TW ou sr_cyrl_RS et certaines variantes utilisant des codages anciens comme ISO8859-1 éliminées.

Collation

DragonFly est le premier système BSD à prendre en charge proprement la collation pour les locales. Ceci signifie que les données sont triées en fonction des règles de la langue et du territoire sélectionnées.
Avant la version 4.4, les données étaient triées en fonction du standard POSIX, suivant l'ordre du jeu de caractères.

Les définitions de collation proviennent du projet CLDR (Unicode Common Locale Data Repository), version 27.01. Le format de collation, l'outil de génération et sa prise en charge dans la bibliothèque C sont issus du projet Illumos.

Comme cela est un but à long terme du projet FreeBSD, le code de collation de DragonFly a déjà été importé dans FreeBSD CURRENT et sera disponible pour la version 11.0.
Il y a eu une collaboration significative entre FreeBSD et DragonFly en ce qui concerne la découverte et la correction de bugs et des patches ont été remontés vers Illumos. Au final, nous avons une solution de gestion de locale pour trois plate-formes, ce qui fait une histoire FOSS positive (voir notamment le billet de Baptiste Daroussin sur son blog).

Bibliothèque TRE

La bibliothèque regex a été remplacée par la bibliothèque TRE, bien plus puissante et capable de gérer des chaines de caractères encodées en multi-octets.
DragonFly est le premier système d'exploitation *BSD à utiliser TRE après Mac OS X.

OpenLibm

La bibliothèque libm a été remplacée par OpenLibm, essentiellement issue du projet OpenBSD. Elle est développée par une équipe dédiée et est presque complète.
Quelques fonctions manquantes pour gérer complètement la norme C++11 ont été importées depuis NetBSD.
L'ancienne libm était un assemblage de code de différentes origines qu'il était difficile de maintenir.

Dports

Grâce au travail conséquent de John Marino et d'autres contributeurs, plus de 22'800 paquets sont disponibles via les DPorts. GitHub a notamment beaucoup été utilisé récemment par des utilisateurs de DragonFly afin de soumettre des correctifs permettant d'importer des ports qui ne compilaient autrefois pas (ou plus) sur DragonFly.

Éditeur de liens Gold

DragonFly utilise maintenant l'éditeur de liens Gold par défaut. L'ancien éditeur de liens "ld.bfd" est toujours disponible et peut être à nouveau utilisé moyennant quelques changements dans le fichier make.conf.

Version des symboles

De nombreuses bibliothèques avaient bénéficié du Symbol Versioning dans les versions précédentes de DragonFly. C'est maintenant au tour de la libc de bénéficier de cette technologie.
D'un point de vue pratique, ceci devrait permettre à des programmes binaires créés sous DragonFly 4.4 de continuer à pouvoir être executés pendant des années sous de nouvelles versions de DragonFly.

Évolutions des logiciels intégrés dans le système de base

  • Ajout de tcpdrop(8)
  • Ajout de libexecinfo (depuis FreeBSD)
  • nvi a été mis à jour en version 2.1.3
  • iconv a été synchronisé depuis FreeBSD
  • OpenSSL a été mis à jour en version 1.0.1q
  • xz a été mis à jour vers la version 5.2.2. Cette version apporte notamment la prise en charge du multithreading pour la phase de compression.
  • libedit a été mis à jour vers la version 2015-03-25
  • grep a été mis à jour vers la version 2.22
  • tcsh a été mis à jour vers la version 6.19.00
  • libdialog a été mis à jour vers la version v1.2-20150920
  • (tn)ftp a été mis à jour vers la version "10 OCT 2015"
  • binutils a été mis à jour vers la version 2.25.1
  • gcc a été mis à jour vers la version 5.2.1
  • localedef a été ajouté, en provenance d'Illumos, afin de remplacer mklocale et colldef qui ont logiquement été retiré.
  • patch(1): suppression des fonctionnalités d'auto-checkout RCS et SCCS. Message de commit.
  • hostapd a été retiré de base. Une version récente est évidemment disponible via les dports.

Divers

Améliorations du bootloader

L'évolution générale de la taille des modules noyau ces dernières années a fini par causer des problèmes de manque de mémoire pour le bootloader; les symptômes étaient souvent une impossibilité d'utiliser une image mémoire initrd pour démarrer sur un disque chiffré ou en mode single user.

Afin de corriger ce problème une bonne fois pour toutes, le bootloader utilise maintenant une zone mémoire de 1Mo située en mémoire haute et non plus dans une zone mémoire gérée par le BIOS.

Status de Clang

Le dport Clang fonctionne presque parfaitement sous DragonFly mais n'est pas encore capable de construire le bootloader. Clang n'est donc pas pour le moment supporté de manière officielle.
John Marino a pour intention de faire de Clang l'un des deux compilateurs intégrés dans DragonFly une fois que les problèmes empêchant la création du bootloader seront réglés.

DragonFly est toujours fourni avec deux compilateurs, qui sont actuellement gcc-4.7.x et gcc-5.2.1, gcc-5.2.1 étant le compilateur utilisé par défaut.

Technologies de gestion d'énergie

DragonFly possède maintenant de nombreuses technologies de gestion d'énergie. Sepherosa Ziehau en a fait un résumé dans ce mail

  • # Felicitations!

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

    Bravo Francois pour ton travail à la fois de développement et de rédaction de cette dépêche! Au plaisir de te recroiser (FOSDEM et/ou XDC)!

  • # FreeBSD vs. DragonFlyBSD

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

    J'avais essayé deux fois DragonFlyBSD. Une fois à ses débuts (version 1 quelque chose) et une autre fois avec la version 2. Bien que techniquement supérieur à FreeBSD sur le papier, je l'ai trouvé bien contraignant pour un usage quotidien chez soi comparé à FreeBSD.
    Comment se positionne t'il maintenant ? Peut on l'utiliser sur son PC portable par exemple ou vaut il mieux préférer son alter-ego FreeBSD ?

    • [^] # Re: FreeBSD vs. DragonFlyBSD

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

      Je n'ai rejoins le bateau que depuis la version 3.4 mais je pense qu'il y a eu bien du chemin depuis les versions 1 et 2. Je l'utilise comme OS principal sur mon laptop (un Thinkpad Sandy bridge) depuis un petit moment maintenant. J'ai également une installation sur un Desktop Haswell. Grâce en bonne partie au travail de François Tigeot, si tu possèdes un GPU Intel ou AMD, côté graphique ça devrait même mieux passer que FreeBSD vu qu'on a ~ l'équivalent de ce qui était pris en charge avec le noyau Linux 3.18. Le son ne devrait également pas être un problème et pour ce qui est réseau, si c'est pris en charge par FreeBSD, ça devrait l'être par DragonFly BSD également (et si un driver existe chez FreeBSD mais pas dans DragonFly, il suffit d'en faire part dans la channel IRC pour que quelqu'un porte le driver rapidement ;) ).
      Question paquets, il y a de quoi faire avec les dports et pkg(8). Seuls quelques paquets sont manquants par rapport aux ports FreeBSD. Après, la communauté étant nettement plus petite que celle de FreeBSD, il n'est pas impossible que certains de ces ports comportent quelques bugs mais globalement, pour mon utilisation, je n'ai aucun problème.
      Ah, autre chose: pas de prise en charge de la mise en veille ou hibernation.

      • [^] # Re: FreeBSD vs. DragonFlyBSD

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

        Ok merci. J'ai un Thinkpad aussi (à côté d'un Asus G74S pour le boulot). Je testerai un de ces jours mais dans une VM (sinon je vais me faire incendier par ma femme si je change encore une fois d'OS sur la machine !)

    • [^] # Re: FreeBSD vs. DragonFlyBSD

      Posté par . Évalué à 5.

      DragonFly est tout à fait utilisable sur un portable, je le fais tous les jours.

      Les puces graphiques Intel jusqu'à la génération Broadwell fonctionnent presque parfaitement: Le dessin 2D, la vidéo et la 3D bénéficient de l'accélération matérielle.

      La gestion de l'énergie s'est énormèment améliorée dans le pilote i915, ce qui fait que sur mon portable Core 2 le simple fait d'activer le mode graphique augmente la durée de vie de la batterie d'un tiers.

      Un des grands changements par rapport aux versions 1 et 2 vient aussi de la manière d'installer des logiciels. Maintenant il y a des paquets binaires gérés par pkgng et on peut juste faire pkg install pour installer facilement un programme.
      Je pense que d'un point de vue utilisateur les versions récentes de FreeBSD et DragonFly sont maintenant très proches; à mon humble avis, la principale différence se situe maintenant au niveau des systèmes de fichier: ZFS dans un cas, HAMMER de l'autre.

      Sur des serveurs, je n'ai eu aucun problème pour faire passer des scientifiques de Debian à DragonFly, une mini formation d'une heure a suffit.

    • [^] # Re: FreeBSD vs. DragonFlyBSD

      Posté par . Évalué à 3. Dernière modification le 22/12/15 à 22:30.

      J'ai toujours trouvé FreeBSD bien loin devant.

      C'est simple quand une nouveauté arrive sur Linux, elle débarque 6 mois après sur FreeBSD, puis 2 ans après sur les autres (dragonflybsd, netbsd, openbsd).

      Par exemple y'a toujours pas de système d'upgrade simple sur dragonflybsd, faut récupérer les sources et compiler.

      J'avoue que la lecture des features hammer2 donne envie mais là encore ça n'a pas grand chose de plus par rapport à zfs qui éclate tout que ce soit sur papier ou en vrai en prod.

      • [^] # Re: FreeBSD vs. DragonFlyBSD

        Posté par . Évalué à 2. Dernière modification le 23/12/15 à 09:31.

        Bonjour,

        effectivement, les nouveautés arrivent très vite sur Linux et FreeBSD.
        Après, il faut voir ce que les nouveautés apportent.

        Pour linux, les release sont très rapide.

        Les BSD prennent plus de temps pour faire les choses.
        Je pense que si FreeBSD bénéficie aussi rapidement de nouveautés, c'est dû à sa grande communauté.

        Si on regarde l'historique des projets, on s’aperçoit que certaines nouveautés on été introduites dans les autres BSD avant (pour DragonFly c'est la suppression du big lock kernel).

        Tout est relatif à l'utilisation qu'on en fait (desktop ou server).
        Quand on les utilise en server, on a moins besoin de "nouveautés" (je connais quelques entreprises dont leur server sont encore en Linux 2.6.x).

        Pour ZFS, c'est un système de fichiers éprouvé et qui a fait ses preuves.
        Hammer et Hammer 2 sont jeunes, il faut leurs laisser du temps.

        Par contre, les caractéristiques d'Hammer 2 sont "alléchantes" :-).

        • [^] # Re: FreeBSD vs. DragonFlyBSD

          Posté par . Évalué à 2.

          Désolé, de poser ces questions mais je suis Dragonfly de loin, depuis linuxfr.

          Pourquoi Dragonfly est-il toujours séparé de FreeBSD? Il me semblait qu'a l'origine, il y avait une différence de philosophie avec d'un d'un cote un Big Kernel Lock et une séparation en plus petits locks de l'autre cote. Mais il me semble que les deux font maintenant la même chose?

          J'avais retenu que Hammer devait être une sorte de ZFS avec snapshoting instantané, etc. Est-ce que Hammer est stable? Pourquoi avoir démarré Hammer 2 alors qu'hammer est a peine sec?

          • [^] # Re: FreeBSD vs. DragonFlyBSD

            Posté par . Évalué à 3.

            Bonjour,

            le fork de FreeBSD pour donner naissance à DragonFly est effectivement dû à l'origine au Big Kernel Lock.
            Mais depuis, le but à aussi évoluer.
            La réponse se trouve sur le site History :
            From a performance perspective DragonFly's only real competitor these days is Linux

            DragonFly BSD est très orienté cluster et architecture SMP (il y en a d'autres).

            Si on prenait un cas simple (mais pas forcément vrai :-) :
            - FreeBSD sur les servers classiques (email, HTTP…)
            - DragonFly BSD pour des servers Hadoop.

            Le système de fichier Hammer est stable.

            Ce qui a motivé la création de Hammer 2 :
            - refonte de l'architecture car Hammer,
            - Hammer ne peut fonctionner que sur DragonFly BSD. Hammer 2 sera portable

            C'est comme pourquoi il y a Angular JS 1.5.0 en préparation et Angular JS 2.0.0 en préparation en même temps :-)

          • [^] # Re: FreeBSD vs. DragonFlyBSD

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

            Le kernel DragonFly est aujourd'hui bien différent du kernel FreeBSD et les deux OS ont des approches très différentes du côté de l'implémentation SMP. Merger aujourd'hui DragonFly avec FreeBSD serait un énorme travail mais de toute façon cela n'aurait aucun sens.

            Sinon, oui, HAMMER est stable et cela depuis plusieurs années maintenant. HAMMER comporte quelques soucis qui ne peuvent être réglé suite à des choix de design initiaux. HAMMER2 est donc un nouveau système de fichier et non une réécriture de HAMMER et il est prévu qu'il comporte plus de fonctionnalités que HAMMER. Pour en citer quelques unes:
            - portabilité vers d'autres OS facilitée
            - writable snapshots (read-only avec HAMMER)
            - prise en charge du multi-master pour le côté clustering
            - copy-on-write, ce qui change drastiquement de l'implémentation via B-tree de HAMMER
            - prise en charge de plusieurs root
            - de nombreuses améliorations dans le design tirées de l'expérience d'avoir implémenté HAMMER
            - …

            Il y aurait beaucoup à dire. Si tu veux vraiment les détails, je te suggère de lire le design document de HAMMER2.

            • [^] # Re: FreeBSD vs. DragonFlyBSD

              Posté par . Évalué à 5.

              L'un des buts du projet DragonFly est d'avoir un système de fichier qui fonctionne en cluster multi-maitre sur plusieurs machines.
              Certains choix initiaux de conception de HAMMER ont malheureusement rendu cela impossible et HAMMER est limité à de la réplication à la volée avec un système de fichier maitre et un ou plusieurs esclaves.

              Avec l'expérience, Matt Dillon a donc décidé de recommencer l'écriture d'un nouveau système de fichier qui puisse cette fois-ci fonctionner avec du stockage réparti sur plusieurs hotes. A terme, HAMMER2 devrait être à la fois plus simple et plus puissant que HAMMER.

            • [^] # Re: FreeBSD vs. DragonFlyBSD

              Posté par . Évalué à 1.

              Merci!

          • [^] # Re: FreeBSD vs. DragonFlyBSD

            Posté par . Évalué à 2.

            Ouahou! J'ai bien fait de poser la question. Merci à tous les trois pour vos réponses complémentaires!

        • [^] # Re: FreeBSD vs. DragonFlyBSD

          Posté par . Évalué à 2.

          Par contre, les caractéristiques d'Hammer 2 sont "alléchantes" :-).

          Est-ce que Hammer 2 est intégrable dans le noyau Linux ou via fuse (au pire)?

      • [^] # Re: FreeBSD vs. DragonFlyBSD

        Posté par . Évalué à 1.

        "C'est simple quand une nouveauté arrive sur Linux, elle débarque 6 mois après sur FreeBSD, puis 2 ans après sur les autres (dragonflybsd, netbsd, openbsd)."

        C'est souvent vrai mais pas toujours (note : j apprécie beaucoup FreeBSD), le support Haswell est bien meilleur sous OpenBSD, DragonflyBSD est aussi devant pour ca, pas mal de techniques de mitigation de sécurité (ASLR par exemple) toujours pas intégré …

        • [^] # Re: FreeBSD vs. DragonFlyBSD

          Posté par . Évalué à 1.

          le support Haswell est bien meilleur sous OpenBSD

          Peux-tu expliquer sur quels points, stp?

          • [^] # Re: FreeBSD vs. DragonFlyBSD

            Posté par . Évalué à 2. Dernière modification le 26/12/15 à 12:18.

            J'ai teste avec meme hardware, Lenovo Yoga en l'occurence, sous FreeBSD mode vesa obligatoire :) alors que sous OpenBSD (branches CURRENT pour les deux) le driver intel idoine marche parfaitement. Un bref test sous supertuxkart a confirme l'ensemble. Ceci dit sous FreeBSD cela s'améliore plutôt bien dans le temps, au bureau mon desktop avec puce Intel marche bien depuis tout récemment (considérant que je recompile le système une fois par semaine a peu près).

            • [^] # Re: FreeBSD vs. DragonFlyBSD

              Posté par . Évalué à 1.

              Merci pour ta réponse et je me permet d'abuser, mais peux-tu partager ton expérience avec OpenBSD sur ce genre de laptop récent?
              Autonomie? Mise en veille? Touchpad? sortie video?

              Merci!

              • [^] # Re: FreeBSD vs. DragonFlyBSD

                Posté par . Évalué à 2.

                Bien … Tout ce que je peux dire, la gestion de l'ACPI est plutôt bonne sous OpenBSD, le système "reprend" bien après une hibernation, question autonomie la majorité du temps le laptop est sous secteur mais le peu de fois ou ca ne l était pas j'ai pu recompiler le système (activité assez consommatrice …) tout en utilisant le système sous XFCE pendant 3 heures a peu pres. La souris a peu près bien géré, le driver ceci dit ne détecte qu'un bouton. La sortie HD … ne peux pas tester :)

              • [^] # Re: FreeBSD vs. DragonFlyBSD

                Posté par . Évalué à 6.

                Hello,

                Je mets mon grain de sable (je précise que je suis un partisan inconditionnel d'OpenBSD). J'utilise OpenBSD (current) sur mon poste principal un Thinkpad X230. La mise en veille fonctionne parfaitement et l'autonomie sur ma 9 cellule est d'environ 5-6 heures. Concernant la partie video, je suis plutôt satisfait pour l'utilisation que j'en ai. Avec la sortie video HDMI, je visionne sans souci des mkv en Full HD ( à noter un suivi plutôt appliqué des releases MPV d'ailleurs). Pour moi, pour une utilisation desktop c'est donc au top, et si tu es un utilisateur Gnome (je tourne sur i3 perso), la version actuellement packagée en current est la 3.18.2 ! Petit bémol peut être concernant le WIFI, la prise en charge du 802.11n et ac n'est pas encore là (bien que le n soit testable en current depuis peu il me semble). Voilà voilà.

                "Whenever you find yourself on the side of the majority, it's time to pause and reflect."

Suivre le flux des commentaires

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