À ma connaissance, il n'y en a pas. Il faut dire que la communauté anglophone étant déjà petite, ça laisse certainement peu de monde pour une communauté francophone.
L'essentiel se passe sur les ML et sur IRC.
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.
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. :)
Allez, juste pour le plaisir du troll et parce que c'est Lundi. Une petite dédicace venant de la FAQ de cassandra:
"In most cases, the capability of Java to gracefully handle garbage collection above 8GB quickly diminishes."
Puisque l'on parle de JVM et de gc, c'est curieux que ton lien ne parle pas également du "compressed Oops trick".
C'est un petit peu hors-sujet par rapport à la dépêche mais comme je trouve cela intéressant, je partage quand même. Pour résumer, il est en général déconseillé d'allouer plus de 32G à la JVM sous peine de souffrir d'une baisse drastique de performance (régression avec une heap de 50G par rapport à une heap de 30G par exemple).
Cela est dû au fait que la JVM utilise un trick: les pointeurs de référence ("Ordinary object pointers") sont de 32-bit jusqu'à cette "limite" de 32G. Comme ces pointeurs réfèrent des objets alignés à l'octet, ils référencent des offsets plutôt que des octets directement. Cela permet donc de référencer ~4mia d'objets plutôt que de byte. On arrive donc à référencer près de 32G au lieu de 4G avec des pointeurs de 32-bit. En revanche, passé cette limite, les pointeurs passent à une taille de 64-bit au lieu de 32-bit afin de pouvoir référencer l'entier de la heap allouée à la JVM. Comme la taille des pointeurs double, plus de ressources CPU/mémoire sont sollicitées d'où une régression de performance et dans les fait, on "perd" de la mémoire effective. Bien entendu, passé une certaine taille d'allocation de mémoire à la JVM, on les "récupère".
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.
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.
J'ai toujours dans ma TODO list de tester un peu Rust (au même titre que Haskell, Ada et Scala de manière plus sérieuse) mais je pense que ce langage n'a pas la simplicité pour soi, au contraire de Go, bien qu'il possède d'autres avantages (sur le papier en tout cas).
Quelqu'un qui a un peu d'expérience en programmation s'y retrouvera très vite en Go (il est possible d'être productif après une journée, et je parle selon mon expérience personnelle) tandis qu'il faut à mon avis plus de temps avec Rust (mais je ne peux pas confirmer de ma propre expérience pour ce cas).
Perso je trouve pas mal de code Go illisible / moche (c'est subjectif). Une fois habitué, c'est sûrement lisible, mais bon… :/ Exemple :
sig := <-sigs
Je pense que c'est plus une question d'habitude. Pour moi, cet extrait est parfaitement clair. Je concède cependant volontiers que Go n'a pas l'élégance de Ruby mais il n'en a pas moins une syntaxe claire et lisible.
Et même si je ne partage pas l'enthousiasme débordant du camarade du dessus, je pense que Go est un très bon langage qui s'apprend vite et permet d'être efficace avec relativement peu de lignes de code (notamment par le fait que la bibliothèque standard est très bien fournie) pour un langage qui se veut relativement bas niveau. Ses plus gros points forts sont, à mon sens, son approche de la concurrence, ses performances et sa simplicité.
Il semblerait qu'il y ait eu quelques pépins de mise en forme lors de la modération dans la partie notes de mises-à-jour. Un modérateur pourrait-il corriger?
Aussi, j'ai oublié de spécifier la date de release, qui est aujourd'hui même, avant de soumettre la dépêche. Un modérateur bienveillant pourrait-il l'ajouter en préambule ainsi qu'un lien vers l'annonce de Justin Sherrill ?
J'ai lu tout le thread mais une bonne partie est occupée par une digression sur des conseils pour quelqu'un qui se lance dans la programmation système en C. :P
Que faut-il retenir à propos de Theo selon toi ? Pour moi, avec un manque de contexte etc, j'ai un regard très neutre.
L'annonce de la version 1.0 ne date que d'environ 13 semaines (début décembre 2014). Et puis bon, aucune dépêche n'en avait encore parlé de ce fork. ;)
Avais-tu essayé tagutil ? À mon avis, cet outil n'a pas la reconnaissance qu'il devrait. Il gère évidemment l'Ogg via libvorbis, sinon je n'en parlerais pas, mais aussi FLAC via libFLAC et d'autres formats encore via TagLib.
Ce qui est sympa avec c'est qu'il est très facilement scriptable. De plus, il gère également le renommage des fichiers et il est lui aussi sous une licence sympa :)
Par contre, il ne gère pas les pochettes.
quel est l'usage principal de DragonFly ? on l'utilise plutôt sur un serveur, pour un PC ?
En tant que serveur. Ce n'est que récemment que les choses s'améliorent grandement pour ce qui est d'une utilisation desktop/laptop.
est-ce que les navigateurs type firefox y sont mis à jour rapidement ?
Oui. En revanche, Chromium ne fonctionne pas sous DragonFly (et j'entends dire qu'il pourrait même disparaitre de FreeBSD, upstream n'acceptant pas les patches nécessaires à FreeBSD et cela devient impossible à maintenir au point que le mainteneur serait prêt à jeter l'éponge). En fait, DragonFly utilise les dports, qui sont un overlay sur les ports FreeBSD (en gros, il s'agit de la collection de ports FreeBSD - les ports qui ne build pas sous DragonFly + des patches si nécessaires). Et du coup, cela amène à ta question suivante:
est-ce qu'il y a un système de gestion de paquet avec dépendances ? (type deb/rpm)
Oui. Au même titre que FreeBSD, pkg(8) est utilisé. pkg(8) fait tout ce que tu attends d'un gestionnaire de paquets moderne, eg: pkg upgrade, pkg install, pkg delete, pkg autoremove, pkg search, pkg info et même pkg audit si tu veux vérifier que tu n'utilises pas de paquets vulnérables. Tu devrais devoir trouver toutes les informations nécessaires en faisant une brève recherche. Pour info, à ce jour, il y a 21747 dports disponibles (c'est pkg stats qui me le dit).
C'est difficile de comparer ces trois là en particulier car ils sont très différents. Hammer est plutôt à rapprocher de btrfs ou zfs bien qu'il soit quand même très différent sur plusieurs points. Pour UFS, ça dépend encore de quelle version tu veux parler. Sur DragonFly par exemple, UFS n'est pas journalisé (et il n'est en général utilisé que pour /boot, hammer ne pouvant pas remplir ce rôle (ça sera corrigé avec hammer2)).
Il n'y a pas des points un peu plus précis que tu voudrais savoir en particulier?
EDIT: bon, d'autres ont été plus rapides que moi à répondre ^
Juste pour préciser: il n'y a pas d'environnement GUI par défaut (l'image ne se fait plus), donc ici il s'agit d'une configuration utilisateur.
Le thème GTK est Numix Holo, icônes Vibrancy-Dark-Aqua et Numix Holo également pour le thème du gestionnaire de fenêtre au cas où. ;)
n'est ce pas encore un peu root pour le tout venant ?
Je ne suis pas certain de comprendre ce que tu veux dire par là. Les mise-à-jour se font en root, oui. Si c'est de l'expérience "desktop" que tu veux parler, disons que Linux est encore loin devant. Il n'y a pas de gestion de la mise en veille par exemple et les touchpads synaptics sont en général vu comme des souris (pas de scroll par exemple) et ça ce sont des choses qui manquent cruellement sur les portables. En revanche, sur un ordinateur fixe ce n'est pas vraiment bloquant et l'expérience utilisateur commence à devenir intéressante, à condition d'avoir un GPU Intel ou AMD supporté (pour nvidia c'est mort tant que nouveau n'aura pas été porté).
Je m'étonne que ton seul moyen de comparaison soit de type visuel. L’œil est facilement trompé et de plus il est plutôt difficile de rester objectif.
Bref, cela aurait été pertinent d'utiliser quelques métriques tels que le PSNR ou SSIM bien que ces méthodes aient aussi leurs défauts. VQMT te permet de les calculer, ainsi que d'autres, et fournit les résultats dans des fichiers CSV. Il prend en paramètre la vidéo original en YUV et comme deuxième paramètre, la vidéo que tu auras encodé puis re-décodé.
Sinon, comme cela a déjà été relevé, il y a beaucoup de paramètres à prendre en compte pour que la comparaison vaille la peine. Je veux dire par là que cela devient extrêmement complexe étant donné le nombre de paramètres et configurations possibles, trop complexe sans doute pour un simple journal LinuxFR. Par exemple, avoir le même intervalle entre les I-frames semble essentiel mais cela ne suffit pas. Il faudrait faire des tests avec différents GOP (Group Of Pictures) (tout en sachant que plus tu as d'I-frames, plus tu fais tomber le bitrate car une I-frame requière plus de ressources pour l'encodage qu'une P-frame ou B-frame). Mais encore, jouer sur les I-frames n'est vraiment utile que si tu veux tester le random access de tes vidéos.
D'autres aspects sont à considérer. Par exemple, la valeur du QP (Quality Parameter). C'est le jour et la nuit entre une valeur de 0 (lossless) ou une valeur élevée (40 et plus) (le range habituellement utilisé se situe ente 18 et 28 en général, 18 étant considéré visuellement lossless). Tu peux aussi jouer sur l'encoder level, l'encoding profile, l'utilisation ou non de B-frames, l'ordre de placement de tes frames dans un GOP, etc. C'est tout un sujet :)
Bref, ma conclusion est que ton journal est intéressant mais que d'après ton protocole de test, il est impossible de désigner un vainqueur de manière objective.
J'imagine qu'il parle plutôt d'un flag dans les meta-données qui précise la raison d'installation du paquet (directement ou en tant que dépendance d'un autre paquet).
# Malheureusement non
Posté par Rolinh (site web personnel) . En réponse au message Communauté Française DragonFly - BSD. Évalué à 2.
Salut,
À ma connaissance, il n'y en a pas. Il faut dire que la communauté anglophone étant déjà petite, ça laisse certainement peu de monde pour une communauté francophone.
L'essentiel se passe sur les ML et sur IRC.
[^] # Re: NVMe from scratch
Posté par Rolinh (site web personnel) . En réponse à la dépêche DragonFly BSD 4.6 et 4.6.1. É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: Des interruptions sur GPU?
Posté par Rolinh (site web personnel) . En réponse à la dépêche DragonFly BSD 4.6 et 4.6.1. Évalué à 2.
Il s'agit d'une coquille évidemment. Si la modération passe par là, ça serait gentil d'enlever ce mot en trop qui s'est glissé dans le texte.
[^] # Re: Benchmark?
Posté par Rolinh (site web personnel) . En réponse à la dépêche DragonFly BSD 4.6 et 4.6.1. É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 Rolinh (site web personnel) . En réponse à la dépêche DragonFly BSD 4.6 et 4.6.1. É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: Destructeurs
Posté par Rolinh (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 6.
Puisque l'on parle de JVM et de gc, c'est curieux que ton lien ne parle pas également du "compressed Oops trick".
C'est un petit peu hors-sujet par rapport à la dépêche mais comme je trouve cela intéressant, je partage quand même. Pour résumer, il est en général déconseillé d'allouer plus de 32G à la JVM sous peine de souffrir d'une baisse drastique de performance (régression avec une heap de 50G par rapport à une heap de 30G par exemple).
Cela est dû au fait que la JVM utilise un trick: les pointeurs de référence ("Ordinary object pointers") sont de 32-bit jusqu'à cette "limite" de 32G. Comme ces pointeurs réfèrent des objets alignés à l'octet, ils référencent des offsets plutôt que des octets directement. Cela permet donc de référencer ~4mia d'objets plutôt que de byte. On arrive donc à référencer près de 32G au lieu de 4G avec des pointeurs de 32-bit. En revanche, passé cette limite, les pointeurs passent à une taille de 64-bit au lieu de 32-bit afin de pouvoir référencer l'entier de la heap allouée à la JVM. Comme la taille des pointeurs double, plus de ressources CPU/mémoire sont sollicitées d'où une régression de performance et dans les fait, on "perd" de la mémoire effective. Bien entendu, passé une certaine taille d'allocation de mémoire à la JVM, on les "récupère".
[^] # Re: FreeBSD vs. DragonFlyBSD
Posté par Rolinh (site web personnel) . En réponse à la dépêche DragonFly BSD 4.4. É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 Rolinh (site web personnel) . En réponse à la dépêche DragonFly BSD 4.4. É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: Golang !!
Posté par Rolinh (site web personnel) . En réponse au sondage Quel langage utilisez-vous le plus au quotidien ?. Évalué à 4.
J'ai toujours dans ma TODO list de tester un peu Rust (au même titre que Haskell, Ada et Scala de manière plus sérieuse) mais je pense que ce langage n'a pas la simplicité pour soi, au contraire de Go, bien qu'il possède d'autres avantages (sur le papier en tout cas).
Quelqu'un qui a un peu d'expérience en programmation s'y retrouvera très vite en Go (il est possible d'être productif après une journée, et je parle selon mon expérience personnelle) tandis qu'il faut à mon avis plus de temps avec Rust (mais je ne peux pas confirmer de ma propre expérience pour ce cas).
[^] # Re: Golang !!
Posté par Rolinh (site web personnel) . En réponse au sondage Quel langage utilisez-vous le plus au quotidien ?. Évalué à 3.
Je pense que c'est plus une question d'habitude. Pour moi, cet extrait est parfaitement clair. Je concède cependant volontiers que Go n'a pas l'élégance de Ruby mais il n'en a pas moins une syntaxe claire et lisible.
Et même si je ne partage pas l'enthousiasme débordant du camarade du dessus, je pense que Go est un très bon langage qui s'apprend vite et permet d'être efficace avec relativement peu de lignes de code (notamment par le fait que la bibliothèque standard est très bien fournie) pour un langage qui se veut relativement bas niveau. Ses plus gros points forts sont, à mon sens, son approche de la concurrence, ses performances et sa simplicité.
[^] # Re: Mise en forme de l'article (et typos pour les suivants ;) )
Posté par Rolinh (site web personnel) . En réponse à la dépêche DragonFly BSD 4.2. Évalué à 1.
Merci pour la date. La mise en forme a été corrigée maintenant à ce que je vois.
# Mise en forme de l'article (et typos pour les suivants ;) )
Posté par Rolinh (site web personnel) . En réponse à la dépêche DragonFly BSD 4.2. Évalué à 2.
Il semblerait qu'il y ait eu quelques pépins de mise en forme lors de la modération dans la partie notes de mises-à-jour. Un modérateur pourrait-il corriger?
Aussi, j'ai oublié de spécifier la date de release, qui est aujourd'hui même, avant de soumettre la dépêche. Un modérateur bienveillant pourrait-il l'ajouter en préambule ainsi qu'un lien vers l'annonce de Justin Sherrill ?
[^] # Re: Coquille
Posté par Rolinh (site web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.
Aussi:
"a été optimisé"
[^] # Re: Coquille
Posté par Rolinh (site web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.
Il manque "temps" ici, non?
[^] # Re: Intéressant mais sûrement peu d’intérêt
Posté par Rolinh (site web personnel) . En réponse au journal NuTyX, une distribution atypique . Évalué à 6.
Je ne connais pas NuTyX mais d'après le journal, en tout cas:
Cette distribution semble proche de CRUX sur bien des points (et CRUX était une inspiration pour Arch Linux).
[^] # Re: Cette polémique n'est pas toute jeune...
Posté par Rolinh (site web personnel) . En réponse à la dépêche Bitrig, un récent fork d'OpenBSD. Évalué à 2.
J'ai lu tout le thread mais une bonne partie est occupée par une digression sur des conseils pour quelqu'un qui se lance dans la programmation système en C. :P
Que faut-il retenir à propos de Theo selon toi ? Pour moi, avec un manque de contexte etc, j'ai un regard très neutre.
[^] # Re: 2 ans et 38 semaines :)
Posté par Rolinh (site web personnel) . En réponse à la dépêche Bitrig, un récent fork d'OpenBSD. Évalué à 10.
L'annonce de la version 1.0 ne date que d'environ 13 semaines (début décembre 2014). Et puis bon, aucune dépêche n'en avait encore parlé de ce fork. ;)
# Tagutil
Posté par Rolinh (site web personnel) . En réponse au journal Tagger efficacement son Ogg-thèque. Évalué à 2.
Avais-tu essayé tagutil ? À mon avis, cet outil n'a pas la reconnaissance qu'il devrait. Il gère évidemment l'Ogg via libvorbis, sinon je n'en parlerais pas, mais aussi FLAC via libFLAC et d'autres formats encore via TagLib.
Ce qui est sympa avec c'est qu'il est très facilement scriptable. De plus, il gère également le renommage des fichiers et il est lui aussi sous une licence sympa :)
Par contre, il ne gère pas les pochettes.
[^] # Re: ..
Posté par Rolinh (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.19. Évalué à 3.
Il y a un 'e' en trop dans le titre du paragraphe.
# Docker c'est bien mais...
Posté par Rolinh (site web personnel) . En réponse au journal PEPS : Une nouvelle solution de messagerie (et plus) pour Linux. Évalué à 6.
Et quand on n'utilise pas Linux ? FreeBSD ou DragonFly BSD par exemple ?
Je ne vois rien de documenté pour une installation plus "classique".
Ah, et la licence en format HTML dans les sources c'est curieux. D'ailleurs, pourquoi pas une licence OSI approved ?
[^] # Re: allez courage
Posté par Rolinh (site web personnel) . En réponse à la dépêche DragonFly BSD 4.0. Évalué à 5.
En tant que serveur. Ce n'est que récemment que les choses s'améliorent grandement pour ce qui est d'une utilisation desktop/laptop.
Oui. En revanche, Chromium ne fonctionne pas sous DragonFly (et j'entends dire qu'il pourrait même disparaitre de FreeBSD, upstream n'acceptant pas les patches nécessaires à FreeBSD et cela devient impossible à maintenir au point que le mainteneur serait prêt à jeter l'éponge). En fait, DragonFly utilise les dports, qui sont un overlay sur les ports FreeBSD (en gros, il s'agit de la collection de ports FreeBSD - les ports qui ne build pas sous DragonFly + des patches si nécessaires). Et du coup, cela amène à ta question suivante:
Oui. Au même titre que FreeBSD, pkg(8) est utilisé.
pkg(8)fait tout ce que tu attends d'un gestionnaire de paquets moderne, eg:pkg upgrade,pkg install,pkg delete,pkg autoremove,pkg search,pkg infoet mêmepkg auditsi tu veux vérifier que tu n'utilises pas de paquets vulnérables. Tu devrais devoir trouver toutes les informations nécessaires en faisant une brève recherche. Pour info, à ce jour, il y a 21747 dports disponibles (c'estpkg statsqui me le dit).[^] # Re: Hammer
Posté par Rolinh (site web personnel) . En réponse à la dépêche DragonFly BSD 4.0. Évalué à 6. Dernière modification le 27 novembre 2014 à 13:17.
C'est difficile de comparer ces trois là en particulier car ils sont très différents. Hammer est plutôt à rapprocher de btrfs ou zfs bien qu'il soit quand même très différent sur plusieurs points. Pour UFS, ça dépend encore de quelle version tu veux parler. Sur DragonFly par exemple, UFS n'est pas journalisé (et il n'est en général utilisé que pour /boot, hammer ne pouvant pas remplir ce rôle (ça sera corrigé avec hammer2)).
Il n'y a pas des points un peu plus précis que tu voudrais savoir en particulier?
EDIT: bon, d'autres ont été plus rapides que moi à répondre ^
[^] # Re: mmhhh comme cela semble tentant
Posté par Rolinh (site web personnel) . En réponse à la dépêche DragonFly BSD 4.0. Évalué à 3.
Juste pour préciser: il n'y a pas d'environnement GUI par défaut (l'image ne se fait plus), donc ici il s'agit d'une configuration utilisateur.
Le thème GTK est Numix Holo, icônes Vibrancy-Dark-Aqua et Numix Holo également pour le thème du gestionnaire de fenêtre au cas où. ;)
Je ne suis pas certain de comprendre ce que tu veux dire par là. Les mise-à-jour se font en root, oui. Si c'est de l'expérience "desktop" que tu veux parler, disons que Linux est encore loin devant. Il n'y a pas de gestion de la mise en veille par exemple et les touchpads synaptics sont en général vu comme des souris (pas de scroll par exemple) et ça ce sont des choses qui manquent cruellement sur les portables. En revanche, sur un ordinateur fixe ce n'est pas vraiment bloquant et l'expérience utilisateur commence à devenir intéressante, à condition d'avoir un GPU Intel ou AMD supporté (pour nvidia c'est mort tant que nouveau n'aura pas été porté).
# Cadeau
Posté par Rolinh (site web personnel) . En réponse au journal HEVC/VP9 : x265 vs libvpx. Évalué à 8.
Je m'étonne que ton seul moyen de comparaison soit de type visuel. L’œil est facilement trompé et de plus il est plutôt difficile de rester objectif.
Bref, cela aurait été pertinent d'utiliser quelques métriques tels que le PSNR ou SSIM bien que ces méthodes aient aussi leurs défauts. VQMT te permet de les calculer, ainsi que d'autres, et fournit les résultats dans des fichiers CSV. Il prend en paramètre la vidéo original en YUV et comme deuxième paramètre, la vidéo que tu auras encodé puis re-décodé.
Sinon, comme cela a déjà été relevé, il y a beaucoup de paramètres à prendre en compte pour que la comparaison vaille la peine. Je veux dire par là que cela devient extrêmement complexe étant donné le nombre de paramètres et configurations possibles, trop complexe sans doute pour un simple journal LinuxFR. Par exemple, avoir le même intervalle entre les I-frames semble essentiel mais cela ne suffit pas. Il faudrait faire des tests avec différents GOP (Group Of Pictures) (tout en sachant que plus tu as d'I-frames, plus tu fais tomber le bitrate car une I-frame requière plus de ressources pour l'encodage qu'une P-frame ou B-frame). Mais encore, jouer sur les I-frames n'est vraiment utile que si tu veux tester le random access de tes vidéos.
D'autres aspects sont à considérer. Par exemple, la valeur du QP (Quality Parameter). C'est le jour et la nuit entre une valeur de 0 (lossless) ou une valeur élevée (40 et plus) (le range habituellement utilisé se situe ente 18 et 28 en général, 18 étant considéré visuellement lossless). Tu peux aussi jouer sur l'encoder level, l'encoding profile, l'utilisation ou non de B-frames, l'ordre de placement de tes frames dans un GOP, etc. C'est tout un sujet :)
Bref, ma conclusion est que ton journal est intéressant mais que d'après ton protocole de test, il est impossible de désigner un vainqueur de manière objective.
[^] # Re: Gestionnaires de paquets
Posté par Rolinh (site web personnel) . En réponse à la dépêche openSUSE 13.2 : nouvelle version du caméléon disponible !. Évalué à 2.
J'imagine qu'il parle plutôt d'un flag dans les meta-données qui précise la raison d'installation du paquet (directement ou en tant que dépendance d'un autre paquet).