Sortie de Linux 3.13

Posté par Martin Peres (site web personnel) le 20 janvier 2014 à 16:21. Édité par Davy Defaud, Jarvis, Romain Perier, Yves Bourguignon, Siosm, yogitetradim, Benoît Sibaud, ZeroHeure, jlh, antistress, Jiehong, claudex, JPEC, ariasuni, palm123, Mali, Sylvhem, jcr83 et Dreamkey. Modéré par patrick_g. Licence CC By‑SA.

Étiquettes :

130

jan.

2014

La sortie de la version stable 3.13 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org. Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche.

Sommaire

La phase de test

RC-1

La version RC-1 a été annoncée par Linus le 22 novembre, avec 2 jours d’avance :

Donc, vous avez eu une semaine supplémentaire pour préparer vos demandes d’intégration, et si vous aviez l’intention de les envoyer durant les deux derniers jours en pensant que je fermerais la fenêtre de fusion le dimanche comme d’habitude, je ne peux que me moquer de vous et vous traiter de tous les noms. Parce que vos excuses ne m’intéressent pas. J’ai averti les gens à ce sujet dans les notes de la version 3.12. Comme prévu, quelques personnes y ont échappé de justesse aujourd’hui. Vous vous reconnaîtrez.

S’il y a des demandes d’intégration que j’ai ratées (en raison des filtres à pourriel ou ne correspondant pas à mes habitudes de recherche normales), et si vous pensez que vous avez envoyé votre demande d’intégration dans les temps et que ça été oublié, prévenez‐moi — parce que je n’ai rien en attente à ma connaissance, mais des erreurs peuvent arriver.

En parlant d’erreurs… Je suppose que c’était une erreur d’avoir cette semaine supplémentaire avant l’ouverture de la fenêtre de fusion, et j’aurais probablement dû faire un 3.12-RC8 à la place. Parce que les statistiques de linux-next ont l’air suspectes, et nous avons eu des trucs supplémentaires à ce moment‐là et pas seulement durant la première semaine. Il est clair que les gens ont considéré que « nous allons avoir une semaine supplémentaire dans la fenêtre de fusion » et extrapolé un peu trop. Enfin, bon. Vivre et apprendre.

Quoi qu’il en soit, mise à part cette petite bizarrerie, il s’agissait d’une fenêtre de fusion assez normale. À propos de la taille du correctif, c’est assez habituel : ~ 55 % de pilotes, 18 % de code d’architecture, 9 % de mises à jour réseau, et le reste est réparti (systèmes de fichiers, en‐têtes, outils, documentation). Au niveau fonctionnalités, les trucs les plus importants sont probablement les nftables et le multi‐queue block layer, mais en fonction de vos centres d’intérêt, vous pourrez trouver toutes les mises à jour incrémentielles intéressantes dans les différents domaines. Il y a quelques impairs par‐ci, par‐là (gestion du mode LE du PowerPC…).

Allez‐y et testez, et commencez à m’envoyer des corrections de régression. Et, vraiment, si vous ne m’avez pas envoyé votre demande de « pull » dans les temps, ne vous plaignez pas. Parce que personne n’aimera un pleurnichard.

Le résumé de la fusion suit. Le vrai rapport est trop gros pour être lisible, comme toujours pour une version RC1.

Linus

RC-2

La version RC-2 a été annoncée par Linus le 29 novembre :

Nous sommes revenus à un calendrier hebdomadaire normal, bien que j’envisage d’éventuellement le décaler pour une sortie de version dominicale. En attendant, c’est Noël tous les vendredis ! Ou, peut‐être, de manière plus appropriée, eu égard à la date, Hanoucca.

Bref, tout semble normal pour une -rc2. Rien d’extrêmement alarmant, de nombreuses petites corrections éparses et les statistiques semblent également normales (un peu plus de la moitié concernant les pilotes, le reste est pour un tiers des mises à jour d’architectures, un tiers de documentation et un tiers de divers — systèmes de fichiers, noyau, crypto…).

Rien de particulier ne se distingue. Si la -rc1 vous faisait trop peur pour être testée, allez‐y maintenant. C’est sans problème.

Linus

RC-3

La version RC-3 a été annoncée par Linus le 6 décembre :

Je suis encore sur une planification de sorties le vendredi, bien que j’espère que cela change bientôt — la raison pour laquelle je n’ai pas laissé traîner cette sortie jusqu’à dimanche est qu’elle est déjà assez importante, et j’attendrai que les choses commencent à se calmer.

Ce qui devrait vraiment arriver à ce point. Oh, oh. Je vais commencer à engueuler les gens qui m’envoient des trucs qui ne sont pas opportuns, comme nous avons déjà bien entamé les RC.

Cela dit, ce n’est pas comme si cette RC3 était devenue énorme et ingérable, ou que quelque chose de particulièrement effrayant était arrivé. J’aurais aimé qu’elle soit plus petite, mais c’est toujours comme ça. Et rien de particulièrement déplaisant ne se démarque ici.

Le plus gros des changements est pour les pilotes (réseau, SCSI, son et crypto…) et des choses pour ARM DT, mais aussi les trucs habituels comme les mises à jour d’architectures (PA-RISC, plus ARM, x86), des systèmes de fichiers et du réseau.

Lâchez‐vous,

Linus

RC-4

La version RC-4 a été annoncée par Linus le 15 décembre :

J’ai retardé de deux jours la sortie pour revenir au cycle normal de sorties le dimanche, mais je ne suis pas entièrement satisfait du résultat. Les choses ne se calment pas comme elles le devraient, la -rc4 est plus grosse que les précédentes -rc. Et je ne pense pas que ce soit seulement dû aux deux jours supplémentaires.

De toutes façons, ce que cela veut dire en pratique, c’est que je vais devenir très ronchon vis‐à‐vis de quiconque m’envoyant d’inutiles merdes. Si ce n’est ni une régression, ni marqué pour la version stable, alors ne vous donnez même pas la peine de me l’envoyer. Car vous seriez traité de tous les noms, si vous ne suivez pas ces règles simples. ¿ Comprende ?

Bref, le gros des changements pour la -rc4 concerne les pilotes (notamment réseau et graphiques, mais il y a aussi de l’USB, les entrées et des mises à jour pilotes de media). À côté de cela, se trouvent les mises à jour usuelles d’architectures (principalement ARM) et les moins classiques mises à jour SELinux. Également au niveau du réseau, des ajouts çà et là pour une meilleure mesure. Le résumé des modifications n’est pas très concis, mais il a été ajouté pour votre bon plaisir.

Évidemment, nous allons vers les vacances et j’espère vraiment que cela calmera aussi les choses pour les RC à venir…

Linus

RC-5

La version RC-5 a été annoncée par Linus le 22 décembre :

Ho, ho, ho,

Noël est presque arrivé et la -rc5 est la dernière RC avant que la plupart d’entre nous ne se gorgent dans l’insensibilité ; ou pleurent dans nos bières solitaires ; ou sortent pour la nourriture chinoise ; ou ce que vous arrivez à faire.

Les choses semblent se calmer lentement, et je m’attends à ce que la semaine prochaine soit encore plus calme pour des raisons évidentes. Cela pourrait aussi être un bon moment pour dire que même si les choses continuent de se calmer, je pense que nous irons au moins jusqu’à la -rc8, puisque la LCA est assez tôt cette année, et que je n’ouvrirai pas la fenêtre de fusion pour le 3.14 avant d’être rentré de ces voyages.

De toute façon, à propos de la rc5 : environ 40 % de pilotes (graphiques, réseau, son, divers-un-peu-de-tout), 15 % de mises à jour d’architectures (cette fois, principalement du PowerPC), 10 % de systèmes de fichiers (Ceph/CIFS), 10 % de documentation, et le reste de « divers » incluant quelques corrections du cœur du noyau (ordonnanceur) et de la gestion de mémoire (NUMA). Rien de vraiment excitant ne ressort. Les bogues sur lesquels je suis intervenu étaient suffisamment subtils et inusuels pour que je ne ressente aucune alerte « drapeau rouge », comme je le voulais justement. Ce sont les bogues « Comment cela a pu seulement passer les tests superficiels ? » qui me rendent inquiet, et si ceux‐ci existaient, les gens seraient honteux et silencieux à propos d’eux. ;)

Ainsi, malgré mon intention de faire traîner un peu la RC, il n’y a l’air d’avoir aucune raison technique réelle pour le faire, du moins jusqu’à présent. Tout se passe bien, donc, s’il vous plaît, sautez le pas et aidez à tester,

Linus

RC-6

La version RC-6 a été annoncée par Linus le 29 décembre :

Comme prévu, les choses ont été calmes durant cette semaine de vacances. Donc, diverses petites mises à jour aléatoires : pilotes (Infiniband, graphiques, cpufreq, libata, blocs), quelques petites corrections sur les systèmes de fichiers (ext4/JDB2), et quelques trucs sur les systèmes monopuces ARM. Minis corrections sur x86, percpu et cgroup.

Rien que vous n’auriez normalement seulement remarqué, juste 81 relativement petits commits.

Linus

RC-7

La version RC-7 a été annoncée par Linus le 4 janvier :

D’habitude, je fais ce genre de chose depuis l’aéroport lors de mon trajet de retour, mais puisque j’ai eu à réinstaller mon portable, j’ai eu peur et j’ai préféré le faire avant de partir, juste pour être sûr que tout soit bien installé sur le portable. Et, devinez quoi, la fois où je décide d’être prudent, tout a marché sans une égratignure…

Bref, les choses ont été calmes et, si je n’étais en déplacement, ceci aurait été sans doute la dernière -rc. Rien ne justifie de retarder la sortie, même si il y a quelques correctifs en cours de discussion et de filtrage par les mainteneurs. Mais au lieu de faire une vraie 3.13 le week‐end prochain, je serai sur la route et n’ouvrirai décidément pas de fenêtre d’intégration. À la place, je ferai donc une RC8 la semaine prochaine, utile ou pas.

Et, qui sait, peut‐être que quelque chose de critique apparaîtra au fur et à mesure que les gens émergeront lentement de leur coma alimentaire suite aux vacances. Mais, pour l’instant, j’ai l’impression que les choses vont bien.

Dans cette RC, la moitié des mises à jour sont liées au réseau (à la fois des pilotes et du cœur) et le reste est un mélange d’autres pilotes (graphiques, entrées, cœur PCI et aussi d’autres correctifs épars) et des mises à jour d’architectures (s390 et PowerPC, ARM). Et encore des choses diverses (CIFS et GFS2, quelques trucs mm d’Andrew, etc.).

Mais, tout ceci est assez petit.

Le résumé suit. Allez‐y, testez.

Linus

RC-8

La version RC-8 a été annoncée par Linus le 12 janvier :

Autre semaine, autre RC. Et c’est bien ainsi.

La RC8 c’est l’habituel mélange avec « deux tiers de pilotes, un tiers divers », « divers » étant des mises à jour d’architectures (ARM et PA-RISC, cette fois‐ci) surtout dans le réseau. D’ailleurs, une grande partie des modifications de pilotes sont des pilotes réseau.

Mais rien de particulièrement effrayant. La partie la plus effrayante de cette version est la lenteur de mon réseau. Le correctif est encore en cours de téléchargement, mais ça devrait être fait d’une minute à l’autre. Ou peut‐être une demi‐heure. Peu importe. Les répertoires git ont été mis à jour depuis des heures, c’est juste les archives tar et les correctifs (et cette annonce de version) qui ont été retardés par la mauvaise qualité du réseau.

Espérons que les choses vont rester calmes, et que je pourrai finaliser le 3.13 la semaine prochaine quand je rentrerai à la maison. Mais, pour que tout fonctionne bien, les gars, nous devons tester. OK ?

Linus

Les nouveautés

Arch

CPU

Ces dernières années les supercalculateurs ont dépassé le nombre de 4 000 cœurs de calcul, le nombre de processeurs maximum se voit donc augmenté de 4 096 à 8 192.

La présentation de la topologie matérielle au démarrage du noyau a également subi un petit lifting. Avant, le système nous présentait les informations sous cette forme :
smpboot: Booting Node 0, Processors #1 #2 #3 OK smpboot: Booting Node 1, Processors #4 #5 #6 #7 OK smpboot: Booting Node 2, Processors #8 #9 #10 #11 OK smpboot: Booting Node 3, Processors #12 #13 #14 #15 OK Brought up 16 CPUs

Dès cette version, ces mêmes informations seront affichées de cette manière :
x86: Booting SMP configuration: .... node #0, CPUs: #1 #2 #3 .... node #1, CPUs: #4 #5 #6 #7 .... node #2, CPUs: #8 #9 #10 #11 .... node #3, CPUs: #12 #13 #14 #15 x86: Booted up 4 nodes, 16 CPUs"

Logging / Debug

Perf

Dans cette version, le système de compilation de l’outil perf se voit amélioré. Désormais, la phase de compilation nécessite beaucoup moins d’étapes de la part de l’utilisateur.
cd tools/perf make install

De plus, celle‐ci s’exécute beaucoup plus rapidement car le système de compilation détecte le nombre de cœurs à la volée et lance une compilation en parallèle en conséquence.

Pour mémoire, perf est un outil de profilage dans Linux qui permet de superviser facilement les compteurs de performance. Les compteurs de performance sont des registres spéciaux dans le processeur qui permettent de compter les événements matériels qui ont lieu lorsque vous exécutez du code : le nombre de défauts de cache, le nombre d’instructions exécutées, les prédictions de branchements correctes ou incorrectes, etc.

CPER

La prise en charge de CPER (UEFI Common Platform Error Record) ou également appelé enhanced MCA logging, disponible dans les derniers processeurs Xeon, a été ajoutée.

Ces dernières années, le nombre de transistors dans les micro‐processeurs et les chipsets mémoire a augmenté très rapidement. Le matériel est de plus en plus miniaturisé et contient de plus en plus de transistors. Ceci, avec la possibilité d’être touché par un rayon cosmique, augmente donc les risques de corruption de données. De plus, la défaillance matérielle reste toujours possible. Les puces électroniques modernes peuvent corriger certaines de ces erreurs par elles‐mêmes (sommes de contrôle ECC), mais il est parfois nécessaire que le système d’exploitation soit notifié de ce genre de problème, car le matériel ne peut pas le corriger lui‐même.

C’est pour cette raison que les processeurs modernes mettent à disposition un mécanisme appelé MCA (Machine Check Architecture) qui permet, entre autres, au processeur de notifier le noyau des erreurs matérielles telles que les erreurs ECC, erreurs de parités, erreurs de caches, etc. Ce mécanisme est à base de registres spéciaux, dit MSR (Machine Specific Registers), afin de stocker les informations sur les erreurs rencontrées et de permettre au système de les traiter. Malheureusement les MSR sont extrêmement dépendants de l’architecture, sont limités en taille et sont parfois très difficiles à interpréter.

CPER est une technologie d’enregistrement d’erreurs MCA gérée par le micrologiciel UEFI. C’est maintenant le micrologiciel qui va directement collecter les messages d’erreurs, les interpréter et les projeter en mémoire physique afin que le système d’exploitation puisse les analyser. Ceci va permettre, entre autres, de disposer d’un système de vérification d’architecture beaucoup plus portable, plus facile à maintenir et beaucoup plus riche en termes de rapports d’erreurs.

Pour plus d’information, je vous invite à lire l’article Machine check handling on Linux et le white paper d’Intel sur le MCA avancé dans les processeurs Xeon.

Ktap

L’outil ktap a presque été intégré dans cette version. Une première fusion avait été faite avant d’être retirée, jugeant que la procédure de revue n’avait pas été respectée et que certaines rectifications devraient être faites avant que cela ne se produise. Son auteur a d’ailleurs dit qu’il était prêt à les faire. Peut‐être une fusion dans la 3.14 ?

ktap est un outil de débogage et de traçage dynamique. Il s’agit d’une machine virtuelle Lua embarquée dans le noyau Linux qui vient s’interfacer avec les outils de traçage existants. L’un de ses avantages est sa capacité à pouvoir injecter un script Lua de débogage directement dans le noyau, sans avoir à compiler quoi que ce soit, et de permettre de créer des routines de débogage sophistiquées simplement et rapidement.

Earlyprintk avec UEFI

La gestion du earlyprintk pour UEFI vient d’être ajoutée. Ceci permet d’envoyer des messages d’événements par le biais de la fonction printk() du noyau beaucoup plus tôt, en déléguant l’affichage au tampon de trame vidéo (framebuffer) d’UEFI durant le début de la phase de démarrage. Utiliser le tampon de trame VESA n’étant pas possible sur les systèmes UEFI, il était donc nécessaire d’utiliser un lien série matériel pour pouvoir déboguer le noyau avant que le pilote graphique ne soit chargé. Les liens série matériels étant de plus en plus rares sur les ordinateurs récents, cette fonctionnalité donc est la bienvenue.

printk() est une fonction dans le noyau, comme printf(), mais qui permet d’envoyer des messages avec différents niveaux de criticités dans la console du noyau. Console dont vous pouvez ensuite retrouver le contenu à l’aide de la commande dmesg.

Lockdep

La prise en charge de seqcount/seqlocks a été ajoutée à lockdep.

Lockdep est le validateur de verrouillage du noyau, c’est un outil de débogage extrêmement utile. Il permet, en ajoutant un petite surcouche de code autour de chaque structure de donnée bloquante (verrou tournant, sémaphore, etc.), de savoir lorsqu’un verrou est pris ou relâché ou collecte des informations critiques, comme lorsqu’un processeur gère une interruption après avoir pris un verrou. Il permet également de détecter les cycles. Depuis son introduction en 2006, il a permis de supprimer énormément de bogues et d’interblocages (deadlocks) dans le système. La prise en charge dans cette version a d’ailleurs permis de corriger quelques bogues.

Ordonnanceurs et minuteurs

Équilibrage NUMA automatique

Dans cette version, la gestion des politiques d’ordonnancement pour les architectures NUMA a été améliorée. Il est maintenant possible de placer un processus à côté de sa mémoire, ou encore de demander au système de placer deux processus qui partagent une page mémoire dans un même nœud. Des appels systèmes sysctl() ont été ajoutés afin de pouvoir activer et désactiver ces politiques d’ordonnancement (cf. modification de documentation).

NUMA (Non Uniform Memory Access) est un système d’architecture sur les machines multi‐cœurs contemporaines qui permet de regrouper les cœurs de calcul par nœud. Les différentes zones mémoires sont ensuite séparées et accédées par différents bus placés respectivement sur chacun des nœuds. Ainsi, dans les systèmes disposant de beaucoup de cœurs, cela évite d’avoir un goulet d’étranglement sur le bus mémoire et d’impacter les performances de temps d’accès mémoire. L’impact visible de cette technique est que chaque cœur a une zone mémoire qui lui est directement attachée et qui est la plus performante.
De ce fait, en fonction de la zone mémoire à laquelle un processus accède, sa mémoire locale ou la mémoire distante, ses performances en seront changées en conséquence. Il est donc important qu’un système d’exploitation tienne compte de cette topologie matérielle afin de placer un processus en cours d’exécution sur le bon nœud en fonction de la partie de la mémoire à laquelle il accède.

Pour plus de détails, vous pouvez consulter cet article de LWN.

Consommation énergétique et ACPI

La nouveauté principale liée à la gestion d’énergie est l’ajout de l’infrastructure de limitation de consommation. Celle‐ci a pour objectif de limiter et de pouvoir répartir la consommation énergétique entre de multiples matériels.

Pour l’instant, cette gestion semble limitée à Intel et sa technologie RAPL (Running Average Power Limit). À la base de RAPL se trouve un système de calcul de consommation énergétique basé sur un modèle du processeur et une instrumentation matérielle pour connaître quels blocs sont actifs à quel moment. À partir de cette information, il est ensuite possible de réduire la fréquence moyenne reçue par le processeur en ne laissant passer, par exemple, que 80 % des tics d’horloge. Cette réduction de fréquence permet de réduire la consommation moyenne du processeur et peut être modulée de sorte que le processeur consomme exactement ce que le système d’exploitation lui a demandé de consommer. Cette technique est très efficace pour les petits ajustements et pour sa réactivité face aux pics de charge, mais est sous‐optimale car elle nécessite une tension d’alimentation supérieure à ce qui était vraiment nécessaire pour atteindre le même niveau de performance. La tension d’alimentation est le principal facteur derrière la fuite de courant des transistors (consommation statique). Cette consommation statique participe à hauteur d’environ 50 % de la consommation globale d’un processeur moderne. Une fois RAPL combiné avec le changement de niveau de performance reprogrammant le contrôleur de tension et les générateurs d’horloge, RAPL permet de limiter très rapidement la consommation pour respecter une consigne tout en gardant une efficience proche de l’optimal.
Intel utilise RAPL pour contrôler chaque cœur du processeur ainsi que la mémoire.

NVIDIA dispose d’un système équivalent depuis les GeForce 8, mais ne s’en est jamais servi. Des indices laissent à penser qu’il pourrait cependant s’en servir pour les Tegra K1. Nouveau ne peut pas vraiment s’en servir, car il faudrait calculer les paramètres du modèle matériel de la carte. C’est théoriquement possible, mais cela nécessite beaucoup de travail et du matériel spécialisé que l’équipe de Nouveau ne possède pas. Nouveau devrait cependant pouvoir utiliser un système plus lent à réagir sur les cartes équipées d’une sonde matérielle de consommation énergétique, lorsque le changement de fréquence dynamique sera géré. La gestion sera cependant réservée aux cartes de milieu et de haut de gamme Kepler.

Pour plus d’informations concernant cette infrastructure, vous pouvez consulter cette présentation hébergée par la Fondation Linux.

Le reste de la demande d’intégration concernant l’ACPI est majoritairement composé de correction de bogues et d’améliorations liées à cpufreq, l’implémentation du DVFS (Dynamic Voltage and Frequency Scaling, changement du voltage et de la fréquence en fonction de la charge) pour les processeurs.

Pilotes graphiques libres

Direct Rendering Manager (DRM)

Peu de nouveautés dans DRM pour cette nouvelle version. La principale est l’extension de l’interface pour autoriser les clients à activer et désactiver des capacités. Cette extension a directement été utilisée pour exposer la 3D stéréoscopique, quand les écrans la gèrent. Pour le reste, on trouve une gestion des fichiers sysfs plus résistante au chargement et déchargement des pilotes à chaud, une amélioration de la précision des horodatages des événements liés au scan out (balayage de sortie vidéo) et beaucoup de corrections de bogues.

Cette nouvelle version a été l’occasion de rappeler les règles pour l’apport de nouvelles fonctionnalités lorsque des modifications dans Linux, libdrm et Mesa 3D (implémentation OpenGL libre) sont nécessaires. Ce rappel à l’ordre a été lancé par Dave Airlie, mainteneur de sous‐système DRM, après qu’un développeur d’Intel ait effectué un commit dans libdrm avant que son correctif pour Linux n’ait été accepté. Ce commit a directement été annulé avec un court avertissement qui a été suivi par un courriel envoyé sur la liste de diffusion du projet Mesa 3D pour donner plus de détails. Une courte discussion a suivi, certaines personnes critiquant l’idée que libdrm n’ait pas de mainteneur, alors que d’autres trouvent que la situation actuelle est parfaite tant qu’une règle simple est respectée. Cette règle est que la prise en charge de cette fonctionnalité doit en premier lieu être ajoutée dans une branche officielle du noyau (au moins drm-next) avant de pouvoir ajouter la gestion pour cette fonctionnalité dans libdrm, puis dans Mesa 3D. C’est ce second choix qui a été retenu.

Adreno (pilote msm)

Le pilote écrit par Rob Clark, msm, pour les processeurs graphiques ARM Adreno, que l’on trouve dans tous les processeurs Snapdragon de Qualcomm, se voit doté d’une prise en charge pour les nœuds de rendu (render nodes), Prime et les plans d’affichage KMS.

Prime est l’implémentation libre de la technologie Optimus qui permet aux pilotes graphiques de pouvoir collaborer de façon à pouvoir effectuer le rendu d’une image sur un processeur graphique et l’afficher sur un autre.

Les plans d’affichage KMS (KMS planes) sont à la base de la composition matérielle (compositing). Chaque plan est une image RVBA (ou équivalent) qui sera fondue avec les autres plans matériellement, au lieu d’utiliser les shaders OpenGL. Cela permet d’augmenter les performances et/ou de diminuer la consommation énergétique.

Pour plus d’informations, vous pouvez regarder la demande d’intégration de Rob Clark.

AMD/ATI (pilote radeon)

Cette nouvelle version du pilote radeon pour les processeurs graphiques AMD/ATI active enfin par défaut le son pour les écrans HDMI. Elle ajoute aussi la gestion complète (gestion des modes d’affichage, décodage vidéo, gestion d’énergie) pour la famille de cartes Hawaii, dont les premières cartes sont sorties en octobre 2013.

Côté gestion d’énergie, cette nouvelle version apporte la gestion de la mise en veille complète des processeurs graphiques discrets qui ne sont pas utilisées dans une machine gérant le PowerXpress (équivalent d’AMD à la technologie Optimus de NVIDIA). Elle apporte aussi la gestion du DPM (Dynamic Power Management) à plus de cartes, et notamment aux familles Southern Islands et Hawaii.

Niveau performance, cette nouvelle version apporte un énorme gain de 500 à 750 %, suivant les tâches, sur les processeurs graphiques de la famille Southern Islands et Hawaii. La raison pour cette subite amélioration tient au fait que seul le premier moteur de shaders était activé. Ce problème a été diagnostiqué et corrigé par le développeur d’AMD Marek Olšák. Cette nouvelle version du pilote est donc plutôt bénéfique pour les utilisateurs de cartes graphiques AMD récentes.

Armada (pilote armada)

Un nouveau pilote a fait son apparition dans DRM afin de gérer les processeurs graphiques des systèmes mono‐puces Marvell Armada 510.

Ce pilote est extrêmement complet pour une première version, puisqu’il gère deux écrans LCD, les plans d’affichage KMS, le commutation de pages pour les tampons graphiques dédiés à l’affichage et Prime pour le partage de tampons graphiques entre clients et pilotes. Cependant, la fonctionnalité la plus importante est la gestion des tampons graphiques partagés par SHM, car ils permettent à Armada et au pilote libre etna_viv (vivante) de fournir une accélération graphique 3D libre.

D’après son développeur, bien que ce pilote soit à destination des Armada 510, la gestion de la série 610 devrait être facile à ajouter.

Intel (pilote i915)

Beaucoup de nouveautés chez Intel, avec notamment l’introduction officielle de la gestion des processeurs Broadwell qui devraient être disponibles à la vente au 3^e trimestre 2014. Cette prise en charge est pour l’instant cachée derrière une option de compilation, mais à moins que vous ne travailliez pour Intel, vous ne devriez pas en avoir besoin. Une prise en charge suffisante pour être utilisable arrivera dans Linux 3.14.

Une autre nouveauté est le début de la gestion du Display Serial Interface (DSI) de l’alliance Mobile Industry Processor Interface (MIPI). Ce nouveau type de communication a pour but de réduire le coût des systèmes mobiles embarquant des écrans. DSI est disponible sur le Raspberry Pi. Toujours côté affichage, une prise en charge basique des écrans 3D a été ajoutée. La prise en charge grand public devrait être disponible assez rapidement dans Wayland (ce qui permettra de voir les engrenages d’_eglgears_ tourner en véritable 3D !) et la gestion de la mise à jour atomique des sprites (pour le tatouage numérique) et du plan principal. Pour finir, le noyau exporte maintenant via debugfs le contrôle de redondance cyclique (CRC) des images après toutes les étapes de rendu (curseur, plans, sprites, correction de couleur et changement d’échelle). Cela va permettre d’automatiser des tests de rendu graphique. Un premier test sur les curseurs a déjà été écrit et a permis d’identifier et de résoudre plusieurs bogues.

Du côté de la gestion énergétique, Intel n’a pas chômé en retravaillant son code de gestion du power gating et en ajoutant notamment la gestion du SWSCI, une infrastructure de gestion d’énergie pour les processeurs graphiques intégrés Intel. Cette gestion est nécessaire majoritairement pour Haswell dont le code de référence ACPI est très dépendant de SWSCI. Intel a également apporté la gestion du boost / deboost logiciel qui devrait améliorer les performances et réduire la consommation dans les cas où la charge est relativement faible mais subit des forts pics d’activité, comme lors de la navigation sur le Web.

Une partie des correctifs nécessaires pour l’ajout du Per‐Process Graphic Translation Table (PPGTT) a aussi été intégrée dans cette version de Linux. Cela permet à différents processus graphiques de ne pas partager le même espace d’adressage graphique, ce qui devrait augmenter l’isolation entre les différentes applications. PPGTT sera disponible à terme sur les processeurs graphiques Ivy Bridge, Haswell, et Broadwell. Pour plus d’informations, vous pouvez consulter la série de corretifs associée.

NVIDIA (pilote nouveau)

Dans cette nouvelle version du noyau, le pilote communautaire pour cartes graphiques NVIDIA n’a pas reçu beaucoup d’améliorations visibles, si ce n’est l’ajout de la gestion des modes d’affichage pour les puces NV108/GK208. La gestion complète de la carte sera introduite dans la version 3.14 du noyau.

La prise en charge des interruptions MSI (Message Signaled Interrupts) a été activée par défaut afin de corriger des problèmes sur certaines nouvelles cartes pour lesquelles la méthode traditionnelle de gestion des interruptions n’était pas fiable. À l’inverse, avant cette version, plusieurs cartes ne géraient pas très bien les interruptions MSI, ce qui rendait le démarrage impossible. NVIDIA a été contacté afin d’avoir des informations sur un potentiel errata matériel. Entre‐temps, Ben Skeggs a investigué le problème et a trouvé par rétro‐ingénierie une solution pour les cartes problématiques connues. NVIDIA a confirmé la solution et a permis d’améliorer la gestion pour d’autres cartes qui n’étaient pas connues pour avoir de problèmes. L’équipe de Nouveau a ensuite découvert que les cartes nvaa et nvac géraient mal les interruptions MSI, elles ont donc été désactivées. Depuis, il n’y a plus eu de rapport de bogue sur ce sujet.

Du côté vidéo, la commutation de pages (page‐flipping) a été retravaillée pour corriger des bogues qui duraient depuis plusieurs versions. Nouveau devrait donc moins souffrir du problème de cisaillement (tearing). La gestion de PMPEG a aussi été améliorée pour prendre en charge les NV40 à NV44. Les NV10 ont également reçu la gestion des plans d’affichage KMS permettant de faire de la composition (compositing) matérielle.

Le gros du travail dans cette nouvelle version est lié à la gestion d’énergie, effectué par Ben Skeggs. Toute l’infrastructure a été repensée pour pouvoir prendre en charge le changement de fréquence dynamique, le clock gating et le power gating. Nouveau remplace maintenant le microcode du processeur concernant la gestion d’énergie PDAEMON/PPWR, ce qui veut dire que le pilote est maintenant responsable de la gestion du ventilateur sur Fermi. Ce microcode, écrit en assembleur Falcon/FµC, est un petit système d’exploitation temps réel qui permettra de décharger le processeur principal pour l’acquisition et le suivi de la charge de la carte, de la régulation du ventilateur et de la consommation.

Outre le réusinage du code, Ben Skeggs a aussi corrigé beaucoup de bogues dans le changement de fréquence des moteurs d’exécution et de la sélection de la tension d’alimentation. Le changement de fréquence de la mémoire a également reçu beaucoup de correctifs, bien que le résultat ne soit toujours pas utilisable et ne le sera probablement pas avant plusieurs versions du noyau pour la plupart des cartes.

Pour en finir avec la gestion d’énergie, la gestion complète du changement de fréquence manuel pour les nvaa/ac (ION) a ensuite été contribuée par Roy Spliet. Ces puces sont intégrées et n’ont donc pas de mémoire vidéo. Ce sont actuellement les seuls puces pour lesquelles le changement de fréquence est officiellement pris en charge. Une prochaine version apportera le changement de fréquence dynamique, mais aucun développeur ne travaille actuellement dessus pour les cartes n’intégrant pas PDAEMON/PPWR.

Poulsbo (pilote gma500)

Le pilote gma500 pour les processeurs graphiques basés sur les PowerVR SGX 535 (aussi connus sous le nom d’Intel Poulsbo) a reçu les modifications nécessaires pour fermer un bogue relatif à l’hibernation datant d’il y a plus d’un an.

Cette version apporte également la gestion de la SVDO aux Minnowboard (équivalentes aux Raspberry _Pi_, mais basées sur des processeurs Intel Atom et avec un connecteur SATA). SVDO (Serial Digital Video Out — sortie vidéo numérique série) est une technologie propriétaire d’Intel permettant d’ajouter des connexions VGA, DVI, SDTV, HDTV ou des récepteurs de télévision à travers un bus PCI express à 16 voies.

Tegra (pilotes host1x et tegra)

Le pilote pour la version embarquée des processeurs graphiques NVIDIA (Tegra), a été ré‐architecturé pour être découpé en deux sous‐parties : host1x et tegra.

host1x est un contrôleur DMA qui permet d’envoyer des commandes en asynchrone à différents composants graphiques et multimédias et de les faire se synchroniser grâce à l’utilisation de barrières (fences). Pour plus d’information, vous pouvez lire la documentation de NVIDIA à son sujet.

Le code Tegra est la partie qui effectue les calculs graphiques. Jusqu’à présent, la partie Tegra se trouvait avec host1x dans /drivers/gpu/host1x/. Elle a été déplacée dans /drivers/gpu/drm/tegra ce qui a permis de simplifier la procédure de démarrage de DRM.

La gestion du Tegra 114 a ensuite été ajoutée dans les deux sous‐parties. host1x a reçu les modifications nécessaires pour tenir compte d’un léger changement et de l’ajout d’un autre point de synchronisation. Tegra a, lui aussi, dû être légèrement modifié pour ajouter la gestion du contrôleur d’affichage et la prise en charge du HDMI.

Pour finir avec les nouveautés, la gestion de gr3d a finalement été fusionnée. Ce qui veut dire que toutes les pièces côté noyau sont présentes pour permettre l’accélération 3D dans l’espace utilisateur.

VMware (pilote vmwgfx)

Pour le processeur graphique virtuel des machines virtuelles VMware, la prise en charge de Prime a été ajoutée. Cette prise en charge n’est pas complète, car elle ne permet pas le partage de tampons graphiques entre différents pilotes. C’est cependant suffisant pour permettre de gérer DRI3.

Réseau

nftables

nftables est maintenant utilisable directement avec le dernier noyau. Vous pouvez consulter son pull request.

nftables est le successeur de iptables. Il permet de configurer le pare‐feu de Linux (netfilter). Rappelons que iptables et netfilter ont été développés en 2001 pour le noyau 2.4, et que iptables a peu évolué depuis. iptables a beaucoup de limitations au niveau fonctionnel et au niveau du code : problème de la mise à jour des règles, de duplications de code qui entraînent des problèmes pour sa maintenance et pour les utilisateurs. Ainsi, pas mal de changements ont été entrepris pour nftables afin de résoudre cela tout en fournissant une compatibilité pour les utilisateurs de iptables.

Son développement s’est fait en deux temps : le développement a commencé avec Patrick McHardy, le chef de projet de netfilter, en 2008 et s’est poursuivi jusqu’en 2009. Une version alpha du code a été présentée, malheureusement peu de monde a rejoint ce projet pour en finaliser le code. Le projet est alors resté en sommeil jusqu’en 2012 où son développement a repris grâce notamment à Pablo Neira Ayuso.

Pour plus de renseignements :

la présentation de lwn.net en 2009 : Un nouvel espoir ;
le blog d’Éric Leblond : nftables contre‐attaque ;
la présentation de lwn.net en 2013 : Le retour de nftables ;
un article en français d’Éric Leblond sur kernel-recipes.org ;
le site officiel de nftables.

En bref

TCP Fast Open, qui avait été ajouté dans Linux 3.7, est maintenant compilé par défaut ;
IPv6 : amélioration d’IPsec et ajout de GSO/TSO ;
mobilité : ajout de l’implémentation de la couche pour la communication en champ proche (Near Field Communication, NFC) utile, par exemple, pour les terminaux de paiement ;
haute disponibilité :
- amélioration de l’agrégation de liens (bonding) concernant le mode tourniquet (round‐robin) et concernant la possibilité de mettre en place les options mode et active_slave via l’interface standard Netlink,
- ajout de l’implémentation du protocole de redondance transparente de haute disponibilité (High-availability Seamless Redundancy, HSR). HSR fournit de la redondance de basculement instantané pour les réseaux Ethernet. Cela demande une topologie en anneau (chaque nœud ayant deux interfaces réseaux). Ce protocole est adapté pour les applications qui requièrent de la haute disponibilité avec un temps de réaction très court.

Pour plus d’information :

pour les anglophones : http://kernelnewbies.org/Linux_3.13#head-3806272543343678ae37671e93b46215b02853ce ;
pour les germanophones : http://www.heise.de/open/artikel/Kernel-Log-Was-3-13-bringt-2-Netzwerk-2066673.html.

Systèmes de fichiers

Une couche « multi‐file d’attente » (Multi‐Queue Block Layer) fait son apparition au sein du noyau. Celle‐ci est destinée à améliorer les opérations d’entrées‐sorties par unité de temps (IOPS), tout en réduisant la latence dans un système composé de multiples disques SSD et de plusieurs cœurs processeurs.

Le noyau devrait maintenant essayer de mieux répartir la charge pour chaque cœur processeur tout en autorisant plusieurs files d’attente matérielles. On attend une augmentation des opérations d’entrées‐sorties d’un facteur allant de 3,5 à 10, et une réduction de la latence d’un facteur 10 à 38.

Dans le même temps, il semblerait que certains systèmes de fichiers soient plus lents que dans la version 3.12 du noyau. La cause de cette régression reste, pour l’instant, inexpliquée.

Btrfs

Miao Xie a permis de nettoyer le code de Btrfs, tout en améliorant les performances du mécanisme d’écriture différée (write‐back).
Enfin, alors que Chris Mason (à l’origine de Btrfs lorsqu’il travaillait pour Oracle) quitte son actuel employeur, la société Fusion-io, pour aller travailler au sein de Facebook, Josef Bacik entre officiellement dans la liste des mainteneurs de Btrfs ; le travail de Chris Mason pour Btrfs ne changera quasiment pas.

F2FS

À côté des habituelles corrections de bogues, F2FS améliore son ramasse‐miettes et les procédures de son verrou global.

XFS & ext4

Le code d’ext4 est légèrement amélioré par quelques corrections de bogues tout en étant allégé. Quant à XFS, une partie de son code a été réusiné, et ses performances se sont améliorées.

Sécurité

Audit

Les processus disposant de la capacité CAP_AUDIT_CONTROL pourront remettre à zéro (en fait -1, la valeur signifiant indéfini) le loginuid. Une fois que les outils de création de conteneurs (systemd-nspawn, LXC, libvirt-lxc) auront été modifiés, cela permettra aux conteneurs de fonctionner correctement avec le système d’audit, ne nécessitant donc plus de le désactiver au démarrage. Correctis : 1, 2.

Pour mieux comprendre ce changement, il faut revoir l’historique de loginuid. L’infrastructure d’audit permet, entre autres, de suivre les utilisateurs et les processus qu’ils lancent une fois qu’ils sont identifiés sur un système. Pour cela, l’UID utilisé lors de l’authentification est stocké (loginuid dans la structure task_struct) de façon indépendante de l’UID courant. Cela permet de suivre les utilisateurs même s’ils changent d’utilisateur ou passent en root avec sudo, par exemple. Cette opération de stockage du loginuid doit être effectuée par le programme responsable de l’authentification d’un utilisateur sur un système. On utilise pour cela un module pam spécifique : pam_loginuid.so.

Au démarrage, les processus n’ont pas de loginuid défini (-1). Avant le noyau 3.3, il fallait disposer de la capacité CAP_AUDIT_CONTROL pour pouvoir changer le loginuid. Il était nécessaire d’autoriser ces changements même si un loginuid valide était déjà défini, car sinon un administrateur relançant le démon sshd propagerait son loguinuid à tous les utilisateurs se connectant via ssh.

Mais ce n’est pas vraiment le comportement idéal, puisque l’on voudrait pouvoir définir ce loginuid uniquement lors de l’authentification et ne plus autoriser aucune modification. Le noyau 3.3 introduit l’option AUDIT_LOGINUID_IMMUTABLE, qui autorise n’importe quel processus à définir initialement son loginuid sans avoir besoin de droits particuliers et empêche ensuite tout changement. Ceci est possible uniquement sur les systèmes utilisant systemd, car l’utilisateur ne lance ou relance plus lui‐même les services mais demande à systemd de le faire. Le démon sshd aura donc un loginuid non défini (hérité de systemd) et pourra le définir pour un utilisateur à la connexion. Si un administrateur lance un démon sshd à la main, le loginuid ne sera pas changé et l’on pourra donc tracer l’origine de ce démon.

Mais cette situation pose de nouveaux problèmes avec les conteneurs. En effet, cette fois, les conteneurs sont lancés par un utilisateur, donc le loginuid est déjà défini, et les processus à l’intérieur du conteneur ne prenaient pas en compte cette situation. Les deux correctifs mentionnés ajoutent donc une interface qui contourne ce problème.

L’option AUDIT_LOGINUID_IMMUTABLE a aussi été retirée (commit), car jugée pas assez flexible. Une nouvelle option la remplace pour bloquer le changement de loginuid à partir de l’espace utilisateur.

IMA

Il est maintenant possible de signer les fichiers avec des algorithmes de hachage différents suivant l’importance accordée à l’intégrité du contenu par exemple. Pour ajouter cette fonctionnalité, il a été nécessaire, de modifier la gestion des modèles IMA qui décrivent l’organisation des données dans l’attribut de sécurité IMA.

KEYS

Modification des espaces de noms utilisateur (user namespace) pour pouvoir avoir un trousseau de clés, stocké dans le noyau, distinct pour chaque espace de noms. Le trousseau de clés noyau fonctionne comme un cache et permet, entre autres, de stocker des clés de façon sûre et persistante jusqu’à leur expiration, même si l’utilisateur se déconnecte. Ce cache est particulièrement utile pour les tâches récurrentes cron et Kerberos.

Ces clés peuvent maintenant être de taille plus importante (potentiellement illimitée) et être échangées (swapped) sur le disque dur.

Random

Suite à une analyse de la fonction chargée du mixage des sources d’entropie, une modification a été effectuée pour l’améliorer légèrement. Pour rappel, le noyau n’utilise pas directement les sources d’entropie dont il dispose pour générer des nombres aléatoires. Il mélange diverses sources pour s’assurer qu’une mauvaise source ne vienne pas réduire l’entropie finale obtenue. Cet article sur le blog de Cloudflare détaille le processus dans le noyau.

Le fonctionnement de /dev/random a été en partie revu : l’entropie est moins gaspillée, mieux estimée et les performances sont améliorées. Les architectures non x86 bénéficient de l’utilisation d’un registre qui ne peut pas être utilisé pour la mesure précise du temps mais qui peut apporter un peu d’entropie.

Le noyau affiche maintenant l’état d’initialisation de /dev/urandom et prévient s’il est utilisé avant qu’il soit initialisé correctement. Ceci est fait en prévision d’un possible futur changement de comportement : le blocage de /dev/urandom si l’initialisation n’est pas terminée.

D’autre modifications ont été effectuées pour /dev/urandom, elles sont détaillées dans ce courriel récapitulatif. Des améliorations diverses et l’ajout de la prise en charge de nouveaux générateurs de nombres aléatoires ont également été inclus (commit).

SELinux

Pour les systèmes de fichiers ne gérant pas les attributs étendus, un contexte SELinux est généré en fonction de la politique ou des options passées lors du montage. Une petite modification autorise maintenant le changement du contexte de sécurité d’un fichier lorsque celui‐ci est dans un système de fichiers racine en mémoire (ramfs).

La fonction chargée de la vérification de la validité de la partie multi‐niveau d’un label de sécurité (MLS) a été fortement optimisée.

Il a été ajouté une capacité pour la politique de sécurité indiquant que les opérations réseau devront toujours être vérifiées par SELinux, même si les règles adéquates de filtrage et marquage des paquets ne sont pas chargées dans netfilter. Cela permet de protéger le système si les règles de filtrage ne peuvent pas être chargées à cause d’une erreur ou si elles sont vidées par un programme malicieux. La partie correspondante en espace utilisateur a déjà été intégrée l’année dernière.

SMACK

Un nouveau mode d’accès a été introduit pour différencier la pose d’un verrou sur un fichier d’une opération d’écriture. En effet, la pose d’un verrou en lecture sur un fichier ne nécessite pas d’avoir les droits d’écriture sur celui‐ci, juste les droits de lecture. Ainsi, deux programmes pourraient potentiellement discuter par l’intermédiaire d’un fichier dont ils ont tous les deux seulement accès en lecture. C’est un canal d’information caché, et typiquement le genre de situation que l’on souhaite éliminer dans le cadre d’un contrôle d’accès obligatoire. SMACK nécessitait donc d’avoir les droits en écriture (avec les labels SMACK, pas juste le DAC) pour pouvoir poser des verrous en lecture, ce qui cassait le comportement de nombreux programmes puisque c’était une situation inattendue (et la solution n’était pas acceptable d’un point de vue sécurité). Pour résoudre ce problème, le mode d’accès lock permet de poser des verrous en lecture, et il faut avoir l’accès write pour les poser aussi en écriture. Cela évite donc de donner trop de droits à un processus sur certains fichiers.

Le crochet (hook LSM) lié à ptrace a été précédemment séparé pour permettre un contrôle plus fin des opérations effectuées. SMACK n’en profitait pas totalement, c’est maintenant corrigé.

x86

Le noyau et l’espace utilisateur échangent couramment des données. Pour des raisons d’intégrité du noyau, il est important de vérifier que seules les données voulues par le noyau sont copiées en espace noyau. Pour des raisons de confidentialité, il est aussi important de vérifier que seules les données dont l’espace utilisateur a besoin sont rendues accessible à celui‐ci. Pour ces raisons, le noyau a des tests pour vérifier les bornes des opérations de copie depuis et vers l’espace utilisateur. Jusqu’à présent, ces opérations étaient vérifiées statiquement, à la compilation. Ces tests étaient cependant pleins de faux positifs dans le cas où la taille des données copiées était dynamique, surtout lorsque l’option DEBUG_STRICT_USER_COPY_CHECKS était activée. Pour résoudre ce problème, les tests pour les tailles dynamiques ont été déportés à l’exécution.

Virtualisation

Hyper-V

La partie du pilote Hyper-V (l’hyperviseur de Windows) voit l’ajout d’un pilote de clavier.

KVM

Pour KVM, il y a un peu plus de changements, il est désormais possible d’avoir la virtualisation qui utilise l’émulation et l’hyperviseur en même temps sur le même noyau. Pour les processeurs Intel, la virtualisation imbriquée s’améliore et ARM gère les transparent huge pages, une amélioration du overcommit et la prise en charge des invités « gros boutistes ».

Il y a aussi une nouvelle interface pour connecter KVM à l’aide des VFIO, ce qui permet aux utilisateurs des NoSnoop PCI transactions d’avoir un invité qui peut exécuter les instructions WBINVD, utiles notamment pour les pilotes NVIDIA sur Windows.

Xen

Dans cette version, Xen a reçu beaucoup de corrections de bogues et deux fonctionnalités majeures. La première est un système de traçabilité qui a été ajouté au pilote Xen SWIOTLB. La seconde est la prise en charge de la traduction d’adresse d’une machine physique vers une machine virtuelle, et inversement, sur les processeurs ARM 32 et 64 bits. Cela permet aux machines virtuelles de programmer des transferts DMA depuis des périphériques réels sur les systèmes sans IOMMU.

Pour plus d’informations, vous pouvez consulter la demande d’intégration de Xen.

Le bilan en chiffres

En ce qui concerne les statistiques du cycle de développement du noyau 3.13, le site LWN.net a publié son traditionnel article récapitulatif.

En nombre de modifications, on se situe, avec 12 122 correctifs, au‐dessus de la version 3.12 (10 966 correctifs) et de la version 3.11 (10 893 correctifs), selon les chiffres du site www.remword.com. C’est un chiffre anormalement élevé, seuls trois noyaux ont fait mieux (2.6.25, 3.8 et 3.10). L’augmentation du nombre de développeurs différents est cependant plus faible, elle s’établit pour cette version à 1 412 contre 1 374 pour la version précédente, et 1 306 pour l’antépénultième.

Les contributeurs les plus prolifiques de ce cycle sont Sachin Kamat, auteur de 361 modifications et Jingoo Han, à l’origine de 323 modifications, grâce à leur travail de nettoyage du sous‐système des pilotes. Ils sont suivis par Marcel Holtmann, 225 modifications, pour son travail sur la pile Bluetooth. Viresh Kumar loupe le podium de peu avec 169 modifications pour son travail sur le sous‐système cpufreq, tandis que H. Hartley Sweeten finit avec 150 modifications, après son développement sur les pilotes d’entrées‐sorties industrielles et les pilotes audio.

Au moins 217 entreprises ont contribué à l’élaboration de cette version. Le podium est partagé par Intel (1 428 modifications), Linaro (1 166) et Red Hat (1 082). Notons que les contributeurs sans affiliations représentent 1 323 modifications, ce qui les place entre Intel et Linaro.

Appel aux volontaires

Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :

	Mainteneur	Contributeur(s)
La phase de test	Aucun	Jarvis, antistress, yogitetradim, Yves Bourguignon, Peck, sinma, jlh, jcr83
Arch	Romain Perier	Martin Peres (ACPI)
Pilotes graphiques libres	Martin Peres	aucun
Réseau	aucun	Jarvis
Systèmes de fichiers	Jiehong	antistress
Sécurité	Timothée Ravier	Martin Peres
Virtualisation	Xavier Claude	Martin Peres (Xen)
Édition générale	aucun	Martin Peres, Jarvis, Yves Bourguignon, jlh

Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps. Si vous aimez ces dépêches et suivez l’évolution technique du noyau dans une partie, veuillez contribuer votre expertise au reste de la communauté. C’est un travail important et très gratifiant, qui permet aussi de s’améliorer. Essayons d’augmenter la couverture sur les modifications du noyau !

De plus, comme vous pouvez le voir, certaines parties n’ont pas de mainteneur (phase de test, réseau, édition générale). Un mainteneur est une personne qui est responsable de la qualité de sa partie et qui suis le développement de versions en versions. Ça vous intéresse ? Faites partie de l’équipe à long terme !

Actuellement, la partie « phase de test » reçoit la majorité des contributeurs, alors que les autres parties sont parfois le travail d’une personne unique. Nous espérons que l’ajout de cette catégorie permet de remercier plus spécifiquement les contributeurs et les motivera à se dépasser dans le futur, pour le bien de tous, eux y compris.

Aller plus loin

Noyaux précédents (432 clics)
Site officiel du noyau Linux (315 clics)
Le détail des nouveautés sur kernelnewbies.org (660 clics)
The Linux 3.13 Kernel Has Many Improvements (339 clics)

# Excellente dépêche

Posté par Atem18 (site web personnel) le 20 janvier 2014 à 16:46. Évalué à 10.

Merci à tous les contributeurs, les dépêche du noyau sont toujours au top. Je voulais aider pour la partie réseau, néanmoins, j'ai oublié. Je ne sais pas si quelqu'un s'est encore proposé pour le rôle de mainteneur, donc à moins que quelqu'un de plus compétent veuille prendre le poste, je le veux bien.
- [^] # Re: Excellente dépêche
  
  Posté par Martin Peres (site web personnel) le 20 janvier 2014 à 16:50. Évalué à 4.
  
  C'est noté! Mais la meilleure façon de pas se faire voler la place est de ne pas oublier dans 3 semaines de venir faire un tour dans l'espace de rédaction ;)
  - [^] # Re: Excellente dépêche
    
    Posté par Atem18 (site web personnel) le 20 janvier 2014 à 17:00. Évalué à 5.
    
    C'est noté! Mais la meilleure façon de pas se faire voler la place est de ne pas oublier dans 3 semaines de venir faire un tour dans l'espace de rédaction ;)
    
    Oui, c'est pas faux. Il est vrai que j'ai plus passé mon temps à troller dans les journaux. :(
    - [^] # Re: Excellente dépêche
      
      Posté par Martin Peres (site web personnel) le 21 janvier 2014 à 13:40. Évalué à 2.
      
      Oui, c'est pas faux. Il est vrai que j'ai plus passé mon temps à troller dans les journaux. :(
      
      Tu peux commencer le travail dès maintenant ;) https://linuxfr.org/redaction/news/sortie-de-linux-3-14
      - [^] # Re: Excellente dépêche
        
        Posté par Atem18 (site web personnel) le 21 janvier 2014 à 15:24. Évalué à 1.
        
        Tu peux commencer le travail dès maintenant ;) https://linuxfr.org/redaction/news/sortie-de-linux-3-14
        
        Ouais, tkt, j'ai vu ça ce matin. ;)
        
        Sinon, je me suis abonné à une mailing-list du noyau qui parle de network, donc on verra bien. :)
- [^] # Re: Excellente dépêche
  
  Posté par Ely le 20 janvier 2014 à 17:03. Évalué à 9.
  
  Il n'y a en effet que sur linuxfr qu'on trouve des récapitulatifs kernel de cette qualité. Bravo aux contributeurs :) .
  - [^] # Re: Excellente dépêche
    
    Posté par Xaapyks le 20 janvier 2014 à 17:37. Évalué à 9.
    
    http://kernelnewbies.org/Linux_3.13
    - [^] # Re: Excellente dépêche
      
      Posté par netchaiev le 20 janvier 2014 à 23:19. Évalué à 10.
      
      Ok le site est intéressant mais l'avantage ici c'est en français .Et pour les fainéants comme moi qui évitent les montées en surcharge de leur "cpu corporelle" en essayant de traduire à la volée , les dépêches LinuxFR sur les versions Noyau sont un bon compromis pour se tenir au jus des évolutions détaillées et compréhensibles du noyau sans toutefois être un "kernel Gourou" anglophone.
      - [^] # Re: Excellente dépêche
        
        Posté par PolePosition le 22 janvier 2014 à 14:40. Évalué à 2.
        
        Hi,
        
        Voici une petite faute de conjugaison :
        
        "Un premier test sur les curseurs a déjà était écrit "
        =>
        "Un premier test sur les curseurs a déjà été écrit "
        
        [^] # Re: Excellente dépêche
        
        Posté par Benoît Sibaud (site web personnel) le 22 janvier 2014 à 19:00. Évalué à 3.
        
        Corrigé, merci.
        
        [^] # Re: Excellente dépêche
        
        Posté par antistress (site web personnel) le 23 janvier 2014 à 01:32. Évalué à 3.
        
        Salut, la tribune a l'air désertée, je reposte ici :
        2014-01-21 00:49:02 antistress et aussi "C'est un chiffre anormalement élevé puisqu'il n'a eu que 3 noyaux qui ont fait mieux" > "il n'y a eu que", ou mieux : "seuls 3 noyaux"
        2014-01-21 00:45:24 antistress je note une coquille dans la dépêche du noyau "En ce qui concerne les statistiques du cycle de développement du noyau 3.12" > 3.13
        
        [^] # Re: Excellente dépêche
        
        Posté par Benoît Sibaud (site web personnel) le 23 janvier 2014 à 09:12. Évalué à 4.
        
        Corrigé, merci. Une fois publiée, personne ne retourne lire la tribune de modération de cette dépêche (sauf à avoir besoin d'éditer la dépêche et encore…) et aucune notification de nouveau commentaire de cette tribune n'existe. Les meilleurs endroits pour signaler une typo reste donc la tribune principale de modération (ou de rédaction à la rigueur), et les commentaires de la dépêche.
        
        [^] # Re: Excellente dépêche
        
        Posté par antistress (site web personnel) le 23 janvier 2014 à 10:21. Évalué à 3.
        
        Merci.
        Oui, je parlais bien de la tribune de rédaction https://linuxfr.org/redaction
# i915 ?

Posté par jseb le 20 janvier 2014 à 17:08. Évalué à 3.
Quelqu'un pourrait m'expliquer quelle est la partie du pilote i915 qui est prise en charge par le noyau ?

En effet, sur ma Arch (et je suppose pour toutes les distribs), c'est un paquet à part:
```
$ pacman -Ss i915
extra/xf86-video-intel 2.99.907-2 (xorg-drivers xorg) [installed: 2.21.15-1]
    X.org Intel i810/i830/i915/945G/G965+ video drivers
```
Ce paquet prend manifestement en charge ce qui est spécifique à X.org, mais tout ça me semble bien imbriqué, et j'ai du mal à voir ce qui devrait être spécifiquement dans le noyau. Les parties qui ont besoin de tourner en privilégié pour avoir accès aux registres de la carte ?

Merci.

Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
- [^] # Re: i915 ?
  
  Posté par Martin Peres (site web personnel) le 20 janvier 2014 à 17:18. Évalué à 10.
  
  Quelqu'un pourrait m'expliquer quelle est la partie du pilote i915 qui est prise en charge par le noyau ?
  
  Normalement, le noyau est responsable de faire l'envoi de commandes à la carte (batch de commandes à exécuter en asynchrone). Il est aussi responsable de la gestion de la mémoire graphique, des écrans et des primitives de synchronisation. C'est ce qu'on appelle généralement le KMS (Kernel modesetting).
  
  Ensuite, les drivers xf86-video-* sont fait pour que X puisse parler au kernel pour faire son rendu. Il sert aussi à l'accélération vidéo (XV) et 2D (EXA, SNA, UXA, glamor).
  
  Dans le cas d'intel, ils supportent le mode KMS (comme les autres cartes) mais ils supportent aussi le mode legacy, l'UMS (Userspace modesetting). Dans ce mode, X a besoin de tourner en root pour accéder aux registres et faire le travail qui doit normalement être fait par le noyau, en plus de faire le travail habituel des drivers xf86-video-*.
  
  C'est plus clair?
  - [^] # Re: i915 ?
    
    Posté par jseb le 20 janvier 2014 à 20:20. Évalué à 1.
    
    Merci d'avoir répondu.
    
    En effet, c'est plus clair.
    Je ne savais pas que les drivers xf86-video-* tournaient en userland. Je les ai toujours imaginés avec des privilèges sur le matériel.
    
    Il me semble d'ailleurs qu'avec ms-windows, les drivers tournaient dans l'espace noyau (en ring0), au moins jusqu'à Vista.
    
    Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
    - [^] # Re: i915 ?
      
      Posté par antistress (site web personnel) le 21 janvier 2014 à 18:14. Évalué à 3.
      
      Tu peux aussi aller voir https://fr.wikipedia.org/wiki/Pile_graphique_Linux
# Merci

Posté par Narann (site web personnel) le 20 janvier 2014 à 17:33. Évalué à 3.

Encore un grand merci a tous les contributeurs pour ces dépêches que je prends beaucoup de plaisir a lire! :)
# Prime et bumblebee

Posté par icefinger le 20 janvier 2014 à 17:59. Évalué à 6.

Bonjour à tous, et merci pour toutes ces dépêches sur le noyau que je lis toujours avec plaisir.
J'ai une question sur optimus, je cite

Prime est l'implémentation libre de la technologie Optimus qui permet aux drivers graphiques de pouvoir collaborer de façon à pouvoir effectuer le rendu d'une image sur un GPU et l'afficher sur un autre.

J'utilise actuellement bumblebee sous ma debian (pilote proprio). Prime est sensé le remplacé ? Il ne fonctionnera que pour nouveau ou aussi pour les pilotes proprio ?

Si quelqu'un connaît les réponses à ces questions, merci d'avance.
- [^] # Re: Prime et bumblebee
  
  Posté par 🚲 Tanguy Ortolo (site web personnel) le 20 janvier 2014 à 18:10. Évalué à 10. Dernière modification le 20 janvier 2014 à 18:10.
  https://wiki.archlinux.org/index.php/PRIME
  
  PRIME est fait pour remplacer, de façon plus propre, les systèmes comme bumblebee. Et au passage, remettre à leur place Nvidia, qui prétendaient à tort que X.Org n'était pas adapté et qu'aucune solution propre n'était possible.
  
  Ce ne sera à mon avis utilisable qu'avec les pilotes dont les développeurs sont assez dynamiques pour les avoir mis à jour pour cela, donc pas les pilotes propriétaires non. Ça va être une situation semblable à celle du multi-écran je pense :
  1. les pilotes propriétaires utilisent des techniques propriétaires pas très propres et pas du tout intégrées ;
  2. on met en place des techniques propres (XRandR) ;
  3. les pilotes libres sont très rapidement mis à jour pour cela ;
  4. les pilotes propriétaires traînent derrière et continuent à ne proposer que leurs techniques propriétaires ;
  5. des années après, les pilotes propriétaires rattrapent finalement leur retard et adoptent la technique standard.
  - [^] # Re: Prime et bumblebee
    
    Posté par claudex le 20 janvier 2014 à 19:44. Évalué à 4.
    
    Il me semble que justement le driver nvidia a des prémices du support de prime.
    
    « 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: Prime et bumblebee
      
      Posté par Martin Peres (site web personnel) le 20 janvier 2014 à 19:52. Évalué à 8.
      
      Il me semble que justement le driver nvidia a des prémices du support de prime.
      
      Plus que des prémices, c'est presque aussi bien que Nouveau, avec plus de performance. Voilà comment le configurer.
      
      Que ce soit Nouveau ou NVidia, y'a pas encore de support pour la synchronisation entre les GPUs. Les patchs pour ça existent (au moins pour Nouveau et Intel), c'est écrit par Maarten Lankhorst (employé par Canonical) mais personne veut faire de revue de code dessus apparemment, car ça touche à plein de choses que les développeurs n'aiment pas trop toucher (TTM en particulier).
      
      Tanguy: Justement, Nvidia supporte xrandr 1.4 ;)
  - [^] # Re: Prime et bumblebee
    
    Posté par Xaapyks le 21 janvier 2014 à 14:27. Évalué à 6.
    
    6- Entre temps un nouveau standard a émergé et les pilotes proprios sont de nouveau obsolètes
    - [^] # Re: Prime et bumblebee
      
      Posté par barmic le 21 janvier 2014 à 17:10. Évalué à -9.
      
      Super on utilise les « standards » pour se battre contre les logiciels propriétaires comme ceux-ci le font avec nous ! Yeah ! La libre concurrence des logiciels pronnée par certains libristes a bon dos. Maintenant le logiciel libre n'est pas bon par sa nature ouverte mais juste parce qu'on crée de l'incompatibilité plus vite que le concurrent (qu'est ce qu'on disait au sujet des tables DSDT déjà ?).
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Prime et bumblebee
  
  Posté par tuxicoman (site web personnel) le 20 janvier 2014 à 21:40. Évalué à 3.
  
  Est ce que prime a un rapport avec le paquet primus ou c'est 2 choses différentes ?
  - [^] # Re: Prime et bumblebee
    
    Posté par Martin Peres (site web personnel) le 20 janvier 2014 à 22:43. Évalué à 5.
    
    C'est 2 choses différentes. Prime est une implémentation concurrente à Primus/Bumblebee. C'est l'implémentation bas niveau qui apporte le plus de performance par design.
  - [^] # Re: Prime et bumblebee
    
    Posté par Adrien Dorsaz (site web personnel, Mastodon) le 20 janvier 2014 à 23:22. Évalué à 4.
    
    Non, ce n'est pas la même chose : primus est une alternative pour exécuter une application grâce à Bumblebee qui remplace optirun avec la commande primusrun (en gros, si je me rappelle bien, c'est un projet qui fait la même chose qu'optirun mais qui abandonne toute une partie client/serveur qu'optirun fournissait mais qui n'était pas nécessaire puisque tout était fait en local, ce qui permet un gain de performance).
    
    Prime est par contre un outil intégré directement à Xorg dans les versions assez récentes. La documentation est là pour Optimus.
# Encore un peu plus sur nftables

Posté par Florent Fourcot le 20 janvier 2014 à 18:40. Évalué à 7.

Une annonce sur quelques listes de diffusion.

À noter le numéro de version 0.099. L'annonce précise bien qu'ils se réservent le droit de modifier la grammaire ou d'autres choses pour la 0.1. Ça fait plaisir de le voir enfin dans le noyau, si ça prend ça peut révolutionner les pare-feux sous Linux.
# À propos de TCP Fast Open

Posté par Florent Fourcot le 20 janvier 2014 à 18:51. Évalué à 9.

TCP Fast Open qui avait été ajouté dans Linux 3.7 est maintenant compilé par défaut ;

C'est plus que compilé par défaut, c'est activé par défaut. À ma connaissance, cela a toujours été compilé. La différence désormais c'est qu'il faut explicitement changer la variable sysctl pour refuser d'utiliser TCP Fast Open.
# VM ou natif

Posté par Krunch (site web personnel) le 20 janvier 2014 à 19:09. Évalué à 8.

C'est amusant de voir le temps qu'il a fallu pour trouver un consensus sur la manière d'implémenter de l'instrumentation à la DTrace (qui fonctionne depuis 2005) dans Linux. Il me semble qu'au « début », l'idée d'embarquer une VM dans le noyau Linux (ce que Solaris/DTrace et ktap font) paraissait comme une hérésie. Du coup il y a SystemTap (1.0 en 2009 mais fonctionnel depuis plus longtemps) qui a fait ça en natif et ça n'a pas vraiment plu non plus à Linus. La boucle est donc bouclée. J'espère que ktap fourni(ra) au moins les même fonctionnalités que SystemTap.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# LLVM/CLANG

Posté par TsyMiroro MDG le 21 janvier 2014 à 09:37. Évalué à 4.

B!

J'y connais rien. Je voudrais comprendre, alors je pose des questions.

La compilation du noyau avec llvm/clang a-t-elle été testée? Avec quels résultats?
Est-ce que c'est envisagée/envisageable?
Quelles seraient les contraintes/problèmes? pour quels bénéfices?

D'après ce que j'ai cru comprendre cela apportera au moins une chose : une meilleure écriture du code.
Il ne s'agit pas de meilleure lisibilité ou meilleures performances mais mais de respect du langage c.
Est-ce vrai?
- [^] # Re: LLVM/CLANG
  
  Posté par khivapia le 21 janvier 2014 à 09:54. Évalué à 9.
  
  ça a été testé (https://lwn.net/Articles/441018/ ), ça compile pas trop mal mais il y a des patches pour certains sous-systèmes, ça permet de profiter des "conseils" de LLVM/clang pour améliorer le code et d'une manière générale ça devrait permettre de profiter de tous les avantages d'utiliser deux compilateurs (amélioration de la qualité).
  
  Cela dit, historiquement Linux n'est prévu pour être compilé que par GCC et utilise pour des questions de performances bon nombre d'extensions spécifiques à GCC, du coup c'est un boulot compliqué.
  
  Il y avait eu des essais avec le compilateur d'Intel également.
- [^] # Re: LLVM/CLANG
  
  Posté par claudex le 21 janvier 2014 à 10:24. Évalué à 4.
  
  Linux dépend d'extensions particulières de GCC, certaines sont implémentées dans Clang mais pas toutes, du coup ce n'est pas tout à fait possible de le compiler. Même si une grande partie du code est compilable avec Clang.
  
  « 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
# Nvidia

Posté par défense le 21 janvier 2014 à 09:45. Évalué à 1.

NVIDIA dispose d'un système équivalent depuis les Geforce 8 mais ne s'en est jamais servi. […] Nouveau ne peut pas vraiment s'en servir car il faudrait calculer les paramètres du modèle matériel de la carte. C'est théoriquement possible mais ça nécessite beaucoup de travail et du matériel spécialisé que l'équipe de Nouveau n'a pas. Nouveau devrait cependant pouvoir utiliser un système plus lent à réagir sur les cartes équipée d'une sonde matérielle de consommation énergétique lorsque le changement de fréquence dynamique sera géré. La gestion sera cependant réservée aux cartes milieu et haut de gamme Kepler.
- [^] # Re: Nvidia
  
  Posté par Martin Peres (site web personnel) le 21 janvier 2014 à 11:18. Évalué à 5.
  
  Ça sort d'où ça? Ils ont fait le design matériel mais n'ont jamais eu besoin de cette capacité vu que le reclocking lent est suffisant pour eux. Pourquoi ils devraient passer du temps à configurer leur modèle matériel si ça leur sert à rien au final?
  
  C'est pas comme si ils avaient les infos et voulaient pas nous les donner… Ils ont fait des tests avec la nv50 et ils ont arrêté ensuite. Comme je disais dans la news, Tegra K1 pour utiliser cette fonctionnalité.
# DRM/Lien

Posté par défense le 21 janvier 2014 à 09:53. Évalué à 6.

Ce rappel à l'ordre a été lancé par Dave Airlie, mainteneur DRM, après qu'un développeur Intel ait commité dans libdrm avant que son patch pour Linux n'ait été accepté. Ce commit a directement été annulé

Les deux liens pointent vers la même url.

Le bon lien : commité
- [^] # Re: DRM/Lien
  
  Posté par Benoît Sibaud (site web personnel) le 21 janvier 2014 à 10:05. Évalué à 4.
  
  Corrigé, merci.
# bof ?

Posté par Nicolas Boulay (site web personnel) le 21 janvier 2014 à 10:48. Évalué à 1.

C'est moi, ou il n'y a rien de bien sympa pour l'utilisateur desktop normal. Il y en a que pour les serveurs, on dirait. Et que l'on rame toujours un peu pour rattraper le retard de la 3D, mais c'est tout.

A quand de vrai fonctionnalité pour l'utilisateur classique ? Je pensais à une vrai migration de processus entre 2 machines par exemple, c'est pas classique mais cela serait intéressant pour ceux qui ont un fixe et un portable. btrfs semble complexe à manipuler.

Bref, c'est pas franchement sexy.

"La première sécurité est la liberté"
- [^] # Re: bof ?
  
  Posté par claudex le 21 janvier 2014 à 10:56. Évalué à 6.
  
  Tu parles d'un truc comme http://criu.org/Main_Page ?
  
  « 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: bof ?
    
    Posté par Nicolas Boulay (site web personnel) le 21 janvier 2014 à 13:20. Évalué à -6.
    
    Oui, mais c'est un peu mort non ?
    
    "La première sécurité est la liberté"
    - [^] # Re: bof ?
      
      Posté par claudex le 21 janvier 2014 à 13:58. Évalué à 10.
      
      criu-1.1-rc2.tar.bz2
      Released: 20 Jan 2014
      
      Pour un projet qui a sorti une version hier, c'est un peu violent comme remarque non ?
      
      « 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: bof ?
        
        Posté par Nicolas Boulay (site web personnel) le 21 janvier 2014 à 14:00. Évalué à 0.
        
        oups, mal lu.
        
        "La première sécurité est la liberté"
      - [^] # Re: bof ?
        
        Posté par défense le 21 janvier 2014 à 17:04. Évalué à 5.
        
        Pour un projet qui a sorti une version hier, c'est un peu violent comme remarque non ?
        
        On est au 21e siècle. À l'heure d'Internet. Je dirais même plus à l'heure de twitter et firefox.
        
        Il faut sortir une nouvelle version toutes les heures. Pas besoin de faire grand chose. Juste corriger une typo, et releaser.
        
        Si tu n'as pas releasé dans la journée, tu es has been !
- [^] # Re: bof ?
  
  Posté par cedric le 21 janvier 2014 à 10:57. Évalué à 2.
  
  Desktop is dead ?
- [^] # Re: bof ?
  
  Posté par patrick_g (site web personnel) le 21 janvier 2014 à 11:54. Évalué à 10.
  
  C'est moi, ou il n'y a rien de bien sympa pour l'utilisateur desktop normal
  
  Et le support de 8192 CPU alors ?
  Bon sinon pour être sérieux je pense que le boulot effectué sur Multi-Queue Block Layer va, à moyen terme, être utile à tous les détenteurs de SSD très rapides. Ces joujoux ne sont pas réservés aux serveurs, de nombreux utilisateurs desktop vont donc en voir les bénéfices quand les pilotes seront adaptés.
  
  Et puis, même si un noyau n'a pas de grosse nouveauté desktop, il reste les milliers de petites améliorations incrémentales.
- [^] # Re: bof ?
  
  Posté par Martin Peres (site web personnel) le 21 janvier 2014 à 13:03. Évalué à 10.
  
  C'est moi, ou il n'y a rien de bien sympa pour l'utilisateur desktop normal.
  
  Tu oublies les améliorations sur la pile graphique et la gestion d'énergie? C'est là que le combat continue pour le desktop normal.
  - [^] # Re: bof ?
    
    Posté par Nicolas Boulay (site web personnel) le 21 janvier 2014 à 13:21. Évalué à -6.
    
    la gestion d'énergie, c'est uniquement pour les portables, il s'agit de gagner 1h grand maximum.
    
    La 3D, c'est pour combler le retard, et sinon on a le driver proprio d'Nvidia ou le driver qui marche d'intel.
    
    "La première sécurité est la liberté"
    - [^] # Re: bof ?
      
      Posté par LupusMic (site web personnel, Mastodon) le 21 janvier 2014 à 13:25. Évalué à 8.
      
      C'est aussi agréable de pouvoir alléger la facture d'électricité. Tout le monde ne vit pas dans un pays avec de l'électricité nucléaire peu chère.
      - [^] # Re: bof ?
        
        Posté par Nicolas Boulay (site web personnel) le 21 janvier 2014 à 13:35. Évalué à -3.
        
        Il s'agit de quelques whatt sur des machines fixes qui mangent plus de 100W.
        
        "La première sécurité est la liberté"
        
        [^] # Re: bof ?
        
        Posté par LupusMic (site web personnel, Mastodon) le 21 janvier 2014 à 15:30. Évalué à 0.
        
        Oui, des économies de bout de chandelles. Mais c'est déjà bien plus important que ce que prétendent économiser tout ceux qui débranchent leurs chargeurs inutilisés.
        
        [^] # Re: bof ?
        
        Posté par lolop (site web personnel) le 21 janvier 2014 à 21:27. Évalué à 9.
        
        quelques whatt sur des machines fixes qui mangent plus de 100W.
        
        × combien de machines ?
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: bof ?
        
        Posté par symoon le 22 janvier 2014 à 01:00. Évalué à 5.
        
        Il s'agit de quelques whatt sur des machines fixes qui mangent plus de 100W.
        
        What ?
        Ouatte ?
        Watt ?
      - [^] # Re: bof ?
        
        Posté par jihele le 23 janvier 2014 à 08:59. Évalué à 2.
        
        Tout le monde ne vit pas dans un pays avec de l'électricité nucléaire peu chère.
        
        [Hors-sujet]
        
        Le nucléaire, c'est cher, mais le coût est caché (externalisé) donc on a l'impression que c'est pas cher.
        
        [^] # Re: bof ?
        
        Posté par cedric le 23 janvier 2014 à 10:11. Évalué à 2.
        
        Peux-tu etres plus precis, parce que les cout caches des energies, c'est un peu le cas de toute. Il n'y a pas de source d'energie qu'on achete a un prix non subventionne.
        
        [^] # Re: bof ?
        
        Posté par lolop (site web personnel) le 23 janvier 2014 à 13:01. Évalué à 4.
        
        Une part de financement de la recherche par les programmes de recherche militaires.
        Une part actuellement non couverte sur le démantèlement des centrales et le stockage sur très longue période des déchets.
        
        Tu trouveras probablement sur le net des estimations du coût démantèlement + stockage.
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: bof ?
        
        Posté par cedric le 23 janvier 2014 à 14:07. Évalué à 8.
        
        Je peux reprendre exactement les même critères et les appliquer aux petrole, gaz, charbon et photovoltaique… l'énergie propre n'existe pas, quand au coût,il ne reflète jamais que l'effort humain estimé a l'instant t.
        
        [^] # Re: bof ?
        
        Posté par Nicolas Boulay (site web personnel) le 23 janvier 2014 à 14:56. Évalué à 3.
        
        Tu imagines forcément que c'est très inférieur, mais personne ne sait encore comment enlever les fondations d'une éolienne. Ils ont pourtant seulement 20 ans de durée de vie pas 60.
        
        La dernière central au charbon d'EDF à mis 10 ans à être démantelé (Vaire sur marne).
        
        Il y a 100G€ pour démanteler les centrales, c'est sans doute sous estimé. Mais pourquoi avoir arrêter les surgénérateurs, et ne pas avoir commencer la filière au thorium ?
        
        "La première sécurité est la liberté"
        
        [^] # Re: bof ?
        
        Posté par Zylabon le 23 janvier 2014 à 15:05. Évalué à 2.
        
        Tu imagines forcément que c'est très inférieur, mais personne ne sait encore comment enlever les fondations d'une éolienne. Ils ont pourtant seulement 20 ans de durée de vie pas 60.
        
        Ça ressemble du bon gros FUD…
        
        Please do not feed the trolls
        
        [^] # Re: bof ?
        
        Posté par KiKouN le 23 janvier 2014 à 17:15. Évalué à 10.
        
        Pas du tout, j'ai vu construire les fondations d'éoliennes ( pour l'un de nos concurrents qui plus est ) ainsi que tout les restes dans mon village natal.
        
        Les fondations se finnissent 3 4 mètres sous le niveau du sol et l'éolienne est vissée dessus. Le but étant qu'une fois l'éolienne en fin de vie. On enléve le mat et on rebouche le trou en laissant la fondation. L'agriculteur peut alors labourer sans crainte.
        
        Bon les fondations sont en béton armés. On peut trouvé bien pire dans les sols de nos jours. J'imagine les archéologues dans mille ans découvrant ces reliques.
        
        [^] # Re: bof ?
        
        Posté par Zylabon le 23 janvier 2014 à 18:42. Évalué à 5. Dernière modification le 23 janvier 2014 à 18:45.
        
        Donc la fondation est parfaitement capable de survivre à l'éolienne, évidement, si on ne réutilise pas ce que l'on peut l'impact environnemental augmente.
        
        Je trouve ça léger comme argument pour mettre en avant le coût écologique des éoliennes.
        
        ajout : Surtout si c'est pour dire que le nucléaire finalement c'est pas si polluant que ça « regardez le grand trou plein de béton ! mais comment on va faire ? ». Je veux dire que dors et déjà, les générations futures seront heureuses de tomber sur des fondations d'éolienne, sauf s'il les lestent avec des déchets nucléaires.
        
        Please do not feed the trolls
        
        [^] # Re: bof ?
        
        Posté par KiKouN le 24 janvier 2014 à 08:15. Évalué à 3.
        
        Je ne mets pas en doute qu'une centrale nucléaire revient bien plus chère à démanteler même en comparant avec la quantité d’électricité produite.
        
        Je voulais juste dire que ce n'est pas un FUD. Il y aura bien des blocs de béton sous nous pied une fois l'éolienne à terre. Après des blocs de béton, on en laisse trainer partout ( bunker et port de fortune de la 2ième guerre mondiale, tunnel hors service, on injecte même du beton pour boucher des fissures à leur construction, … )
        
        [^] # Re: bof ?
        
        Posté par Sytoka Modon (site web personnel) le 25 janvier 2014 à 09:07. Évalué à 2.
        
        Et il faut voir la quantité de bentonite injecté dans les montagnes pour chaque barrage…
        
        [^] # Re: bof ?
        
        Posté par Tonton Th (Mastodon) le 25 janvier 2014 à 18:40. Évalué à 4.
        
        Il y aura bien des blocs de béton sous nous pied une fois l'éolienne à terre.
        
        Question idiote : pourquoi on ne remet pas une éolienne neuve sur le bloc de béton ?
        
        [^] # Re: bof ?
        
        Posté par Sytoka Modon (site web personnel) le 26 janvier 2014 à 00:20. Évalué à 7.
        
        Les éoliennes sont de plus en plus puissantes et hautes -> fondations plus importantes.
        
        Avec le temps, les fondations peuvent s'être fissurée, avoir vieillis… Pas facile de savoir si l'acier est toujours bon dedans. C'est ainsi qu'il est très rare dans les remontées mécanique de ré-utiliser les anciens socles d'il y a 30 ans. Cependant, je pense que les blocs de béton actuels sont bien plus robuste et conçus pour une durée de vie bien plus longue.
        
        [^] # Re: bof ?
        
        Posté par deasy le 27 janvier 2014 à 03:28. Évalué à 5.
        
        Moi je dirais plutôt pourquoi ne sont elles pas conçues de manière modulaire avec une facilité pour changer le générateur à l'intérieur quand celui ci est usé ou changer ses pièces usées…parce que passer à l'étape démontage après usure ça me fait penser à un sérieux soucis de conception.
        
        [^] # Re: bof ?
        
        Posté par Kerro le 27 janvier 2014 à 16:00. Évalué à 4.
        
        J'imagine que le choix est :
        - acheter un peu moins cher, et poubelle dans 20 ans
        - acheter un peu plus cher, et repayer 75% du prix dans 20 ans… si on utilise toujours l'éolien
        
        Car les fondations et le mât coûtent à mon avis bien moins que la partie active.
        
        [^] # Re: bof ?
        
        Posté par claudex le 27 janvier 2014 à 18:31. Évalué à 7.
        
        acheter un peu plus cher, et repayer 75% du prix dans 20 ans… si on utilise toujours l'éolien
        
        Et si on est toujours au même dimensionnement. Parce que peut-être qu'on peut faire des éolienne 3 fois plus grande dans 20 ans.
        
        « 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: bof ?
        
        Posté par LupusMic (site web personnel, Mastodon) le 27 janvier 2014 à 18:34. Évalué à 1.
        
        La tension ne serait que plus importante (puisque plus de surface efficace), et la base en béton insuffisante.
        
        [^] # Re: bof ?
        
        Posté par claudex le 27 janvier 2014 à 18:36. Évalué à 4.
        
        Oui, c'est pour ça que je dis qu'on ne peut pas garder.
        
        « 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: bof ?
        
        Posté par lolop (site web personnel) le 30 janvier 2014 à 19:16. Évalué à 4.
        
        Parce que peut-être qu'on peut faire des éolienne 3 fois plus grande dans 20 ans.
        
        Non. La limitation actuelle est liée à la vitesse du bout des pales et ses effets sur les pales et au niveau du bruit, et le calcul 2*pi*R n'aura a priori pas changé dans 20 ans.
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: bof ?
        
        Posté par Sytoka Modon (site web personnel) le 30 janvier 2014 à 20:21. Évalué à 3.
        
        On évoque des éoliennes ayant 175m de haut avec des pales de 150… La machine peut être plus haute que celles d'aujourd'hui. Il suffit 'juste' qu'elle tourne moins vite. En effet, on est limité par la vitesse en bout de pale. Il y a aussi une limitation en puissance à terre mais c'est une règle qui à mon avis n'est pas écrite dans le marbre.
        
        A noter qu'il y a plein de progrès à faire sur le sujet. Par exemple, les éoliennes laissent passer tout les pics de vents. Bref, pour ceux qui ont des idées, il y a matière à mouler ;-)
        
        [^] # Re: bof ?
        
        Posté par deasy le 30 janvier 2014 à 22:33. Évalué à 1.
        
        Du réseau…
        
        J'ai un champ d'éolienne à coté de chez moi.
        
        Il n'est pas rare qu'une ou deux ne s'est pas orientée vers le vent correctement contrairement aux autres. Et donc ne tourne pas du tout.
        
        Je pense qu'il faudrait les rendre moins individuelle…par exemple sur celles ici vu ce qu'elles font je pense qu'elles ont chacune indépendamment leur système de mesure du sens du vent.
        
        [^] # Re: bof ?
        
        Posté par claudex le 30 janvier 2014 à 23:16. Évalué à 7.
        
        Je me demande si les éoliennes mal orientées ne le sont pas fait exprès. Parce qu'elles sont en maintenance/panne ou qu'on n'a pas besoin de toute la puissance du champ.
        
        « 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: bof ?
        
        Posté par Renault (site web personnel) le 31 janvier 2014 à 00:43. Évalué à 5.
        
        C'est possible.
        L'autre problème, c'est quand des éoliennes trop proches sont en fonctionnement, elles créent des perturbations dans l'écoulement du flux d'air qui réduit grandement l'efficacité des voisines. Le fait de changer l'angle d'approche peut permettre d'éviter qu'elles fonctionnent toutes en même temps et occuper une surface plus petite (car sinon il faut les espacer pour limiter les perturbations).
        
        Et plus on agrandie une éolienne, plus on est confronté à ce problème de manière large. D'autant qu'il n'est pas dit que économiquement 1 grande éolienne soit plus rentable que deux ou trois plus petites.
        
        [^] # Re: bof ?
        
        Posté par Sytoka Modon (site web personnel) le 31 janvier 2014 à 17:52. Évalué à 3.
        
        Plus une éolienne est grande, moins elle est près du sol. Le vent est meilleur en hauteur… La dynamo est aussi un élément important. Les aimants coûtent cher (terre rare). L'effet d'échelle a tendance à faire de plus en plus grand. Aujourd'hui, on est limité par la réglementation et non par la technique.
        
        [^] # Re: bof ?
        
        Posté par Renault (site web personnel) le 31 janvier 2014 à 17:59. Évalué à 1.
        
        Meilleur vent selon quel critère, vitesse, stabilité, direction ?
        Car une éolienne ne doit pas subir un vent trop fort qui la casserait (au delà de 80 km/h de mémoire). Plus tu vas en hauteur, plus le vent est fort et turbulent.
        Il y a la question de la direction, est-ce que la direction du vent en altitude est stable ou ça change souvent ? L'orientation de l'éolienne doit faire face au vent dominant de la région…
        
        Bref, je n'en suis pas intimement convaincus.
        
        [^] # Re: bof ?
        
        Posté par Sytoka Modon (site web personnel) le 31 janvier 2014 à 18:22. Évalué à 3.
        
        Je n'ai pas de données asse précise pour répondre. Les grandes éoliennes passent au dessus des forêts et son moins sensibles à la couche limite liée au sol. Quand aux perturbations, proche du sol, elles doivent être pas mal ! Bref, il vaudrait voir avec un modèle pour trancher ;-)
        
        Dans tous les cas, en mer, les éoliennes sont en moyenne deux fois plus efficace (deux fois plus de vent en heure annuelle).
        
        [^] # Re: bof ?
        
        Posté par windu.2b le 01 février 2014 à 08:42. Évalué à 3.
        
        Je ne connais pas la vitesse maximale supportée, mais quand on voit qu'on va mettre des éoliennes en mer, j'ai un doute sur les 80km/h…
        
        Plus tu vas en hauteur, plus le vent est régulier car il ne subit pas de perturbations dus aux bâtiments (c'est pour ça que le petit éolien est critiqué sur son efficacité). Ce qui est un avantage évident car l'éolienne ne passe pas son temps à tourner sur elle-même et à forcer sur le mat.
        
        [^] # Re: bof ?
        
        Posté par oao le 04 février 2014 à 17:24. Évalué à 2.
        
        On peut toujours imaginer des extrémités de pâles supersoniques. C'est le cas, si je ne m'abuse, du Tigre.
        
        NB : pourquoi j'ai cette image qui apparait que je prévisualise ?
        
        [^] # Re: bof ?
        
        Posté par Sytoka Modon (site web personnel) le 30 janvier 2014 à 08:08. Évalué à 3.
        
        Attention, le génie civil coûte une fortune ! Tranchée pour les câbles, foreuse, étude du sous sol. Je n'ai pas les tarifs mais je ne serais pas étonné que 50% du prix soit invisible ;-)
        
        [^] # Re: bof ?
        
        Posté par deasy le 30 janvier 2014 à 22:31. Évalué à 1.
        
        Bien ce qu'il me semblait…je doutes que rien que le prix de l'énorme fondation qui est faite soit négligeable.
        
        [^] # Re: bof ?
        
        Posté par LupusMic (site web personnel, Mastodon) le 27 janvier 2014 à 18:38. Évalué à 5.
        
        C'est peut-être aussi infaisable. J'étais une fois tombé sur un épisodes des constructeurs de l'extrême qui concernait l'installation d'une éolienne dans une petite ville étatsunienne. Ben déjà pour installer le rotor, c'est tout un bordel, alors le remplacer, je n'ose imaginer.
        
        N'oublie pas que tout ne peut pas être modulaire. Pour des raisons physiques, certaines constructions doivent être définitives. Regarde les chaussées dans nos villes : ce serait formidable de pouvoir soulever un trottoir en appuyant un bouton pour changer une canalisation ou installer la fibre, mais le coût et la maintenance de telles installations pourraient se révéler peu intéressant.
        
        [^] # Re: bof ?
        
        Posté par lolop (site web personnel) le 23 janvier 2014 à 19:53. Évalué à 1.
        
        Pour une centrale nucléaire tu augmentes très légèrement l'épaisseur des fondations, éventuellement tu y intègres d'autres matériaux, et surtout tu rends le tout radioactif¹ et donc impossible à simplement mettre en gravats sous une route ou dans un remblais.
        
        ¹ donc nocif pour un être vivant pour ceux qui n'auraient pas compris
        
        http://www.asn.fr/index.php/S-informer/Dossiers/La-gestion-des-dechets-radioactifs
        
        http://blog.lefigaro.fr/green-business/2013/06/le-demantelement-nucleaire-un-marche-davenir.html
        ==> juste le démantèlement, estimé par la cour des comptes à 20 milliards d'euros pour nos 58 centrales.
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: bof ?
        
        Posté par windu.2b le 24 janvier 2014 à 08:47. Évalué à 9.
        
        On enléve le mat et on rebouche le trou en laissant la fondation.
        
        Qu'on enlève l'éolienne (parce qu'elle est arrivée en fin de vie), je peux le comprendre. Mais pourquoi n'en remettrait-on pas une autre, neuve, à la place ?
        
        [^] # Re: bof ?
        
        Posté par Alex le 24 janvier 2014 à 15:41. Évalué à 6.
        
        Parce que l'éolienne ne sera plus du tout une source d'énergie interessante ?
        parce que le betton a vieilli et est trop dégradé pour remettre une éolienne, que ça couterait plus cher de réparer que de construire un autre bloc de béton a coté ?
        
        [^] # Re: bof ?
        
        Posté par Sytoka Modon (site web personnel) le 25 janvier 2014 à 09:09. Évalué à 3.
        
        On voit que le béton se dégrade au final assez rapidement sans rien faire ;-) C'est un peu la différence avec le nucléaire, les durée et la dangerosité n'est pas du tout la même. Un bloc de béton sous terre est il réellement dangereux ?
        
        [^] # Re: bof ?
        
        Posté par Alex le 25 janvier 2014 à 14:55. Évalué à 4.
        
        Un bloc de béton sous terre est il réellement dangereux ?
        
        Honnêtement j'en sais rien, intuitivement je dirais que c'est beaucoup mieux que le nucléaire
        Néanmoins ça me pose tout de même problème: l'éolien terrestre ne me semble pas vraiment d'avenir, et sur plusieurs générations je ne sais pas comment tout ce béton peut influencé l'écosystème… en même temps cest surement moins pire que nos villes
        
        [^] # Re: bof ?
        
        Posté par Sytoka Modon (site web personnel) le 25 janvier 2014 à 17:19. Évalué à 4.
        
        cest surement moins pire que nos villes
        
        L'éolien en mer a un rendement quasi double, il est évident qu'il faille mettre les hélices au large dès que cela est possible techniquement. En plus, avec des éoliennes flottantes, il n'y a au fond que les câbles d'ancrage et un gros bloc de béton. Facile à déplacer si jamais il le faut ! Quand aux éoliennes sur les crêtes, ce sont rarement des terres cultivables…
        
        Au sujet des fondations, je n'ai pas de chiffre sous la main mais cela me semble négligeable pas rapport aux barrages, voire à toutes les routes que l'on construit (et les ponts) !
        
        [^] # Re: bof ?
        
        Posté par Zylabon le 25 janvier 2014 à 18:03. Évalué à 3.
        
        Il y a des gens qui font des trucs très cool avec des cerfs-volants. Ça permet récupérer l'énergie très haut dans le ciel, avec une infrastructure au sol bien plus restreinte.
        
        Please do not feed the trolls
        
        [^] # Re: bof ?
        
        Posté par lolop (site web personnel) le 23 janvier 2014 à 20:04. Évalué à 2.
        
        Mais pourquoi avoir arrêter les surgénérateurs
        
        Peut-être parce que personne n'a réussi à faire fonctionner correctement un surgénérateur de forte puissance (et de risque élevé).
        
        http://www.dissident-media.org/infonucleaire/surgenerateur.html
        
        Le devenir des sept surgénérateurs qui ont été construits est assez révélateur.
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: bof ?
        
        Posté par Sytoka Modon (site web personnel) le 25 janvier 2014 à 09:24. Évalué à 8.
        
        Les surgénérateurs comme superphénix sont basés sur une mauvaise idée : le refroidissement au sodium liquide. Le CEA essaye de nous faire croire que la technologie est maîtrisé. C'est une folie de faire un circuit de transfert de chaleur avec du sodium, beaucoup trop dangereux. On a l'impression que le CEA n'a rien retenu des accidents graves…
        
        Il y a une technologie très prometteuse qui résoudrait notre problème électrique pour au moins un millénaire, le temps de mettre au point la fusion, c'est le réacteur au sel fondus. C'est pas un gouffre financier hypothétique comme ITER ou SuperPhénix, les risques sont /a priori/ bien plus limités et les problèmes techniques qui restent à résoudre (passage à un vrai réacteur fonctionnel) bien plus à notre portée qu'ITER par exemple (dont on ne sais toujours pas comment on va récupérer les calories !). Mais le projet est porté par des chercheur du CNRS et ce n'est pas du tout un projet assumée par les pontes du CEA qui ont tous été formé à l'école Phénix ! A noter que le sel fondus n'a pas /a priori/ d'intérêt militaire…
        
        http://fr.wikipedia.org/wiki/R%C3%A9acteur_nucl%C3%A9aire_%C3%A0_sels_fondus
        
        [^] # Re: bof ?
        
        Posté par Nicolas Boulay (site web personnel) le 27 janvier 2014 à 10:44. Évalué à 2.
        
        C'est les réacteurs au thorium.
        
        Mais coté transfert de chaleur, on a bien des circuits de transfert de chaleur avec de l'hydrogène, dans les génératrices de centrale nucléaire (quand tu produits, 1600MW, 2% de perte dans l’alternateur, cela fait pas mal de calorie à évacuer).
        
        "La première sécurité est la liberté"
        
        [^] # Re: bof ?
        
        Posté par windu.2b le 24 janvier 2014 à 08:46. Évalué à 5.
        
        Le coût du démantèlement avait été estimé par la commission PEON… dans les années 70 !
        La seule centrale qu'on a commencé à démanteler, celle de Brennilis en Bretagne (70MW de puissance, seulement) a déjà coûté 482M€, soit 20 fois l'estimation (et on n'a pas encore attaqué la partie la plus ardue : le réacteur proprement dit) !.
        
        Quant aux 100G€, il me semblait qu'EDF avait provisionné moins mais, de toute façon, la Cour des comptes avait dit que le montant annoncé par EDF était très inférieur (proportionnellement au nombre de réacteurs concernés) à ce que provisionnaient la Grande-Bretagne et l'Allemagne.
        
        [^] # Re: bof ?
        
        Posté par jnanar (site web personnel) le 24 janvier 2014 à 11:19. Évalué à 1.
        
        L'article français est incomplet. Le réacteur de Mol en Belgique a été complètement démantelé. Le prix du démantèlement n'est pas indiqué mais il sera possible d'aller peut-être poser directement la question.
        
        [^] # Re: bof ?
        
        Posté par Philip Marlowe le 27 janvier 2014 à 14:08. Évalué à 4. Dernière modification le 27 janvier 2014 à 14:11.
        
        Un problème avec les provisions pour démantèlement, c'est que ces grosses sommes d'argent sont diablement tentatrices en temps de disette budgétaire. Je ne parle même pas des tentations au sein même d'EDF dans le cas où cette entreprise aurait des difficultés financières graves. Il me semble qu'il y ait déjà eu quelques tentatives d'attaque en piqué sur les provisions d'EDF. Un autre problème est la manière dont ces provisions sont stockées. L'argent est quelque chose de plus facile à stocker que l'énergie, au moins sur le moyen terme, mais est tout de même exposé, par la manière même dont il est investi. Ce n'est pas à l'abri des krachs.
        
        Et c'est bien là tout le souci du nucléaire, qui nécessite de maîtriser non seulement le présent mais aussi l'avenir, et même un avenir éloigné. Penser à la durée de vie du plutonium.
        
        [^] # Re: bof ?
        
        Posté par Alex le 27 janvier 2014 à 19:49. Évalué à 3.
        
        mais est tout de même exposé, par la manière même dont il est investi.
        
        tu tombes juste
        http://www.agoravox.fr/actualites/economie/article/quand-edf-joue-en-bourse-avec-l-56076
        
        [^] # Re: bof ?
        
        Posté par Sytoka Modon (site web personnel) le 30 janvier 2014 à 08:16. Évalué à 7.
        
        Contrairement à une idée reçu, l'argent ne se stocke pas ! C'est une des raisons de l'arnaque des retraites par capitalisation ! Ce sont toujours les travailleurs à l'instant t qui payent les retraites du jour. La seule chose qu'apporte la capitalisation par rapport à la répartition, c'est que cela joue en bourse, donc plus de risque donc patrons des sociétés très très bien payés… De plus, on ne joue pas au niveau d'un pays mais au niveau mondial. On ponctionne donc les pays voisins, en gros, les africains et les asiatiques payent nos retraites. Dégueulasse !
        
        Comment voulez-vous stocker de l'argent sur 50 à 70 ans au niveau des centrales nucléaires ? Au niveau national, on est loin d'une somme négligeable. Avec 50 centrales, on fabrique quasiment toute l'électricité française. On voit bien que ce n'est pas un système à mettre en bourse mais bien à laisser à la répartition -> nationalisation…
        
        [^] # Re: bof ?
        
        Posté par Nicolas Boulay (site web personnel) le 30 janvier 2014 à 11:56. Évalué à 2.
        
        Je pense que les pays africains serait enchanté que les fonds de pensions américains viennent chez eux, investir dans leur société. Je ne vois pas de mal à ça.
        
        Le problème est la gestion du fond, si tout est placé uniquement en action Enron, et que celle-ci s'effondre, l'épargnant perd tout.
        
        "La première sécurité est la liberté"
        
        [^] # Re: bof ?
        
        Posté par barmic le 30 janvier 2014 à 13:47. Évalué à 1.
        
        Tu introduit un biais. Enron ou n'importe quoi d'autre, le problème est le même, l'investissement peut ne plus avoir de valeur du jour au lendemain (une situation politique mauvaise, un choix qui finalement n'est pas gagnant,…). Le moins pire c'est probablement de diversifier, mais ça ne garantie rien et un crash reste un crash.
        
        C'est quoi ça ?
        
        C'est déclenché par quoi ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: bof ?
        
        Posté par barmic le 30 janvier 2014 à 14:45. Évalué à 1.
        
        Je me réponds pour dire que cette image apparaît pour les grands fils de discussion (long en temps ou en profondeur ou un peu des deux ?).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: bof ?
        
        Posté par oao le 04 février 2014 à 17:32. Évalué à 1. Dernière modification le 04 février 2014 à 17:33.
        
        L'argent ne se stocke effectivement pas, il s'investit, et se multiplie alors. Il y a certes un risque, mais en moyenne on gagne. C'est encore plus vrai sur de grandes périodes de temps, tu auras peut-être une crise où tu perdras 75% de ton magot, mais si tu fais de bons rendements la plupart du temps tu auras au final plus. La clé est de se diversifier, pour ne pas tout perdre d'un coup.
        
        Le capital et le travail ne s'opposent pas, ils sont complémentaires. Sans l'un, l'autre ne sert à rien. Plus il y a de l'un, plus l'autre est efficace. La retraite par capitalisation permet d'accroitre la quantité de capital, donc l'efficacité du travail, et donc, à moyen terme, les salaires.
        
        Enfin il y a une bien une manière bourrine de stocker de la valeur, c'est d'acheter des biens rares, comme les terres, les métaux précieux, les oeuvres d'art, etc. Mais c'est moins bien pour la société car cela ne crée pas de nouvelle valeur.
        
        Cela dit le problème de la tentation du magot est effectivement majeur pour le nucléaire, comme pour les retraites par capitalisation. En France, on en a d'ailleurs un bon exemple, avec Pétain qui avait fait main basse sur les caisses de retraites, et instauré la retraite par répartition pour la paix sociale immédiate.
    - [^] # Re: bof ?
      
      Posté par Martin Peres (site web personnel) le 21 janvier 2014 à 13:54. Évalué à 10. Dernière modification le 21 janvier 2014 à 13:56.
      la gestion d'énergie, c'est uniquement pour les portables, il s'agit de gagner 1h grand maximum.
      
      Sur mon laptop, toujours des cas sans rien faire:
      
      Pas de gestion d'énergie (3.0?, sans laptop mode): 24W
      
      Pas de gestion d'énergie (3.11, sans bbswitch): 18W
      
      Gestion d'énergie sur le 3.13: 10.5W
      
      Gestion d'énergie optimale (3.7? avec bbswitch): 7.5W
      
      Multiplier par 3 l'autonomie, c'est pas "gagner une heure".
      
      Sur les desktop, rien que sur une carte graphique, je peux économiser environ 30W en sélectionnant la bonne tension et en faisant du clock et power gating.
      
      La 3D, c'est pour combler le retard, et sinon on a le driver proprio d'Nvidia ou le driver qui marche d'intel.
      
      Combler le retard est différent de s'améliorer? Faut pas être aussi pessimiste ;)
      - [^] # Re: bof ?
        
        Posté par Albert_ le 21 janvier 2014 à 14:26. Évalué à 5.
        
        Sur les desktop, rien que sur une carte graphique, je peux économiser environ 30W en sélectionnant la bonne tension et en faisant du clock et power gating.
        
        Je peux te poser la question de si c'est faisable par tout le monde sans y aller a gros coup de modification dans /sys/? Parceque sans interface graphique c'est un peu comme btrfs et les snapshots, cela va avoir du mal a se democratiser (ie etre sur le desktop).
        
        Au passage, la gestion d'energie c'est le probleme numero 1 sur les serveurs aujourd'hui donc les amleiorations sont clairement les bienvenus pour le desktop mais, et ce n'est pas une critique loin de la, c'est encore plus une problematique pour les fermes de computing.
        
        [^] # Re: bof ?
        
        Posté par Martin Peres (site web personnel) le 21 janvier 2014 à 15:13. Évalué à 9.
        
        Pas encore Albert. Mais quand ça sera fini, l'utilisateur n'aura rien à faire. Ça sera pareil que le DPM d'AMD.
        
        [^] # Re: bof ?
        
        Posté par Albert_ le 21 janvier 2014 à 15:18. Évalué à 3.
        
        Ok, par contre le DPM d'amd c'est bien joli mais il faut faire attention a quelle carte on a… Hier j'ai tente de rebooter mon portable sur la carte ATI (R600) et bien c'est la cata et le systeme a pas vraiment apprecia de voir un truc a plus de 100 degre celsius… Bon c'est ma faute je n'avais pas vu que pour ces cartes il fallait mettre le dpm a la mano mais bon ca augure rien de bon tout ca :)
        
        Je vais retenter avec dpm on ce soir et voir si prime fonctionne cela serait cool mais j'ai comme un doute que cela fonctionne. Je suis de plus en plus persuade que ati c'est vraiment de la merde niveau chaleur (en tout cas sur portable).
        
        [^] # Re: bof ?
        
        Posté par Martin Peres (site web personnel) le 21 janvier 2014 à 15:26. Évalué à 10.
        
        La gestion d'énergie, c'est le truc le plus complexe que tu puisses faire dans un pilote, mais c'est nécessaire!
        
        J'en discutais avec des ingénieurs NVIDIA à l'XDC. Il parait que plus de 50% du temps du travail pour faire marcher une nouvelle carte (bring up) est liée à ça. Les timings sont de plus en plus serrés du coup la moindre erreur défonce tout. La partie dans le pilote est simple comparé au matériel, mais c'est très dépendant du chipset et quand tu dois ajouter le support pour 10 ans de cartes, c'est pas facile!
        
        Si tu as des problèmes avec le DPM, je te conseille de soumettre un rapport de bug.
        
        [^] # Re: bof ?
        
        Posté par Albert_ le 21 janvier 2014 à 15:49. Évalué à 3.
        
        Je me suis mal exprime, Je ne dis pas que c'est simple, je me doute que si c'est un peu dans les derniers trucs qui sont implemente pour une utilisation de tout les jours c'est que cela n'est pas simple et que un truc mal fait peux casser beaucoup de chose.
        
        Je ne parle pas de Nvidia (je n'ai pas sur un portable) mais entre ATI et Intel je prefere de tres tres tres loin une Intel car niveau perf ca change que dalle (pour mon usage de joueur occasionel :) ), les ati chauffe beaucoup (quelque soit le systeme) alors que les intels c'est super stable a ce niveau la. Apres, un des jeux que j'ai recupere sur GOG ne fonctionne pas avec l'intel (je vois la souris mais le reste est tout noir) alors que ca fonctionne avec l'ATI mais comme celle la ne peux fonctionner que quelques minutes elle est desactive dans le bios :)
        
        [^] # Re: bof ?
        
        Posté par Martin Peres (site web personnel) le 21 janvier 2014 à 16:13. Évalué à 7.
        
        Yep, Intel est vachement efficient énergétiquement. Mais ils ont aussi une équipe qui est au moins 3 fois la taille de celle d'AMD! Et ils ont le droit d'utiliser la doc interne directement, sans attendre la revue par le service légal. AMD va s'améliorer, mais il attendra jamais les perf actuelles. Intel risque de se dégrader pour les tâches légères par contre car leur matériel se complexifie. Le temps nous le dira!
        
        [^] # Re: bof ?
        
        Posté par antistress (site web personnel) le 21 janvier 2014 à 18:23. Évalué à 5.
        
        Pour Intel il y a Powertop
        mais chez moi quand je change les paramètres comme suggéré et que j'y retourne au bout de quelques jours, certains sont de nouveau à changer… (ex : Enable SATA link power Managmenet for hostX, Runtime PM for PCI Device Y)
        
        Sinon je ne suis jamais le conseil sur "Autosuspend for USB device Optical USB Mouse [Logitech]" parce que ma souris met alors du temps à redémarrer quand je la lâche et c'est juste insupportable
        
        [^] # Re: bof ?
        
        Posté par antistress (site web personnel) le 21 janvier 2014 à 19:02. Évalué à 4.
        
        Tiens, je viens de tester, après un simple redémarrage, ces valeurs sont de nouveau mauvaises :
        
        Bad VM writeback timeout
        Bad NMI watchdog should be turned off
        Bad Enable Audio codec power management
        Bad Enable SATA link power Managmenet for host4
        Bad Enable SATA link power Managmenet for host5
        Bad Enable SATA link power Managmenet for host2
        Bad Enable SATA link power Managmenet for host3
        Bad Enable SATA link power Managmenet for host0
        Bad Enable SATA link power Managmenet for host1
        Bad Autosuspend for USB device USB Keyboard [CHESEN]
        Bad Runtime PM for PCI Device Intel Corporation Xeon E3-1200 v2/3rd
        Bad Runtime PM for PCI Device Intel Corporation 7 Series/C210 Serie
        Bad Runtime PM for PCI Device Intel Corporation 7 Series/C210 Serie
        Bad Runtime PM for PCI Device Intel Corporation 7 Series/C210 Serie
        Bad Runtime PM for PCI Device ASMedia Technology Inc. ASM1083/1085
        Bad Runtime PM for PCI Device Realtek Semiconductor Co., Ltd. RTL81
        Bad Runtime PM for PCI Device Intel Corporation 7 Series/C210 Serie
        Bad Runtime PM for PCI Device Intel Corporation 7 Series/C210 Serie
        Bad Runtime PM for PCI Device Intel Corporation 82801 PCI Bridge
        Bad Runtime PM for PCI Device Intel Corporation H77 Express Chipset
        Bad Runtime PM for PCI Device Intel Corporation 7 Series/C210 Serie
        Bad Runtime PM for PCI Device Intel Corporation 7 Series/C210 Serie
        Bad Runtime PM for PCI Device Intel Corporation 7 Series/C210 Serie
        Bad Runtime PM for PCI Device Intel Corporation Xeon E3-1200 v2/3rd
        Bad Runtime PM for PCI Device Intel Corporation 7 Series/C210 Serie
        Bad Wake-on-lan status for device eth0
        
        [^] # Re: bof ?
        
        Posté par Zylabon le 21 janvier 2014 à 19:16. Évalué à 4.
        
        Pour pas mal d'options (toutes ?) tu dois pouvoir les rendre persistantes en les mettant dans sysctl.conf
        
        Please do not feed the trolls
        
        [^] # Re: bof ?
        
        Posté par Kioob (site web personnel) le 21 janvier 2014 à 21:13. Évalué à 4.
        
        D'ailleurs dans powertop, quand tu changes une des options de la section «tunables», il t'affiche la commande à utiliser.
        
        Par exemple moi là j'ai «Enable Audio codec power management» qui est actuellement en «Bad», je me place dessus, je presse [Entrée], et il m'affiche en haut :
        >> echo 1 > '/sys/module/snd_hda_intel/parameters/power_save';
        
        Que je peux ensuite placer dans un script maison (ou dans /etc/sysfs.conf & /etc/sysfs.d/ sous Debian, avec le paquet sysfsutils). Évidemment, si tout ça pouvait être automatique ce serait mieux, mais en attendant j'ai :
        
        kioob@boolette:~$ cat /etc/sysctl.d/power.conf # généré via tips de powertop vm.dirty_writeback_centisecs = 1500 kernel.nmi_watchdog = 0
        
        ainsi que :
        
        kioob@boolette:~$ cat /etc/sysfs.d/power.conf # généré via tips de powertop module/snd_hda_intel/parameters/power_save = 1 # 1394a Controller bus/pci/devices/0000:04:03.0/power/control = auto # en supposant qu'il s'agisse de RTL8187_Wireless bus/usb/devices/7-3/power/control = auto # Logitech USB Keyboard ? bus/usb/devices/6-2/power/control = auto # Logitech USB Receiver (mouse) ? bus/usb/devices/4-1/power/control = auto
        
        À noter également que si je change de port pour un des équipements USB, il faut revoir la conf… pas hyper pratique, mais ça fonctionne.
        
        alf.life
        
        [^] # Re: bof ?
        
        Posté par antistress (site web personnel) le 21 janvier 2014 à 21:17. Évalué à 2.
        
        mais sais-tu pourquoi le réglage via Powertop n'est pas persistant ?
        
        [^] # Re: bof ?
        
        Posté par Kioob (site web personnel) le 21 janvier 2014 à 21:35. Évalué à 2.
        
        Et bien il ne fait que modifier un réglage à chaud. Ce réglage est perdu lors d'un reboot, lorsqu'un autre soft vient le modifier, ou encore lorsque tu débranches/rebranches le périphérique.
        
        alf.life
        
        [^] # Re: bof ?
        
        Posté par antistress (site web personnel) le 21 janvier 2014 à 21:51. Évalué à 2.
        
        quand je pense qu'il demande les droits d'admin pourtant o_O
        
        [^] # Re: bof ?
        
        Posté par claudex le 21 janvier 2014 à 22:06. Évalué à 6.
        
        C'est normal, ce sont des opérations sensible, mais ce n'est pas pour ça qu'il les écrit dans un fichier.
        
        « 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: bof ?
        
        Posté par antistress (site web personnel) le 22 janvier 2014 à 17:53. Évalué à 6.
        
        Power top is not intended to be used as a tuner, it is used as a analysis tools.
        If you find that the tunings are desired, you should work with the distribution to have them included, or make the necessary changes locally yourself.
        
        [^] # Re: bof ?
        
        Posté par Sufflope (site web personnel) le 21 janvier 2014 à 21:36. Évalué à 3.
        
        Parce que la commande sysctl ne fait que des changements non persistants ?
        
        [^] # Re: bof ?
        
        Posté par défense le 22 janvier 2014 à 11:50. Évalué à 5.
        
        D'ailleurs dans powertop, quand tu changes une des options de la section «tunables», il t'affiche la commande à utiliser.
        
        En plus simple, tu peux aussi générer un fichier html (avec l'option --html) puis copier les conseils dans un fichier de conf.
        
        Bon, ça reste moins pratique qu'une option permettant de rendre persistant les changements, comme souhaté par antistress (et moi également) - un genre de -w, comme avec hwclock par exemple - mais c'est déjà plus simple pour traiter en masse.
        
        [^] # Re: bof ?
        
        Posté par fredoche le 22 janvier 2014 à 13:47. Évalué à 4.
        
        sous Fedora tu peux les rendre persistante avec tuned et un scriptpowertop2tuned.
        C'est un truc genre
        - powertop2tuned monprofil --enable -f (ça créé une conf dans /etc/tuned/monprofil)
        - tuned -p monprofil, qui démarre tuned et choisit le profil en argument, et positionne une conf persistante pour le choix du profil.
        - systemctl start tuned.service pour voir si ça marche toujours.
        - puis systemctl enable tuned.service quand tout est ok.
        
        Après j'ai pas encore trouvé d'interface pour changer ça à la volée depuis l'interface graphique… Un jour peut être :)
        
        [^] # Re: bof ?
        
        Posté par antistress (site web personnel) le 22 janvier 2014 à 17:55. Évalué à 2.
        
        Je relirais ton msg à tête reposée ça m’intéresse de creuser la question merci
    - [^] # Re: bof ?
      
      Posté par Zenitram (site web personnel) le 22 janvier 2014 à 08:24. Évalué à 10.
      
      c'est uniquement pour les portables,
      
      "uniquement", tu l'arrêtes à combien de pourcents de part de marché?
      Parce que les portables, c'est un peu la grosse majorité du marché aujourd'hui.
      
      il s'agit de gagner 1h grand maximum.
      
      Plus. Et on s'en fou, c'est toujours 1 heure de gagnée. Désolé, mais quand je perd 1 heure de batterie avec un OS, je le dégage du portable, il n'est pas adapté (pas mal de monde utilise 90% du temps le portable come un fixe, mais quand ce monde a besoin de bouger, il veut son autonomie. Les MacBook ont une sacré autonomie, et j'en vois plein dans les trains, bars… Sans prise électrique, pendant des heures).
      
      Tu demandais des fonctions pour le bureau? Ben c'est exactement ça!
      - [^] # Re: bof ?
        
        Posté par Kioob (site web personnel) le 22 janvier 2014 à 09:09. Évalué à 4.
        
        Seulement 1 heure ? Je ne sais pas ce qui coince sur mon «ultrabook» (un ASUS Zenbook), mais vendu pour 9H d'autonomie, j'ai du mal à dépasser les 4H sous Linux.
        En trifouillant beaucoup beaucoup powertop, et en réglant la luminosité de l'écran directement via /sys/, j'arrive à grimper à 6H, et encore.
        
        Je n'ai pas souvenir avoir eu un tel écart entre données constructeur et autonomie constatée sous Linux, par le passé.
        
        Bref, tout progrès dans le domaine me semble très positive pour le desktop oui.
        
        alf.life
        
        [^] # Re: bof ?
        
        Posté par cedric le 22 janvier 2014 à 10:12. Évalué à 8.
        
        Ton gestionnaire de fenetre et sa configuration ont aussi un impact important. De meme que les logiciels que tu utilisent. Ainsi si tu utilises Enlightenment, je te conseille d'utiliser le backend software, il permet de gagner sur mon PC 1h d'autonomie par rapport au backend OpenGL. La raison est assez simple. Quand tu fais de l'OpenGL, tu demarres un CPU supplementaire qui va consommer de l'energie. Hors le rendu OpenGL n'est pas aussi optimal que le rendu software, car on est oblige de mettre a jour tout l'ecran au lieu de juste ce qui a change. Ainsi quand tu as un curseur qui clignote a l'ecran, tu consommes toute la puissance de ta carte graphique a faire le rafraichissement de 90% de l'ecran qui ne sert a rien.
        
        Je n'ai jamais pris le temps de faire un benchmark et une comparaison avec toutes les configurations possible de tous les desktop (J'ai pas envie de les installer sur mon PC pour commencer). Mais ce que je viens de dire doit etre vrai pour tous les composite managers.
        
        Sinon apres il y a aussi d'autres trucs, genre si tu as une puce d'acceleration video qui ne marche que sous Windows, celle-ci est pris en compte dans les tests de batterie et diminue la consomation. Ce qui n'est probablement pas le cas sous Linux. De plus, je ne sais pas si ils prennent en compte dans leur mesure l'utilisation permanente de site web comme GMail ou Facebook qui sont des vrais pompes a batterie (De maniere general, un navigateur web c'est pas une bonne idee de l'utiliser si on veut de la batterie).
        
        Oh et pour info, avec toutes les bonnes options et la bonne configuration logiciel, j'ai une heure de batterie supplementaire que ce qui est annonce par le constructeur sous Windows…
        
        [^] # Re: bof ?
        
        Posté par Albert_ le 22 janvier 2014 à 10:36. Évalué à 3.
        
        Mais ce que je viens de dire doit etre vrai pour tous les composite managers.
        
        J'ai peut etre rien compris et j'ai lu en diagonal mais on dirait que pour kwin il est plutot conseille l'inverse.
        
        http://blog.martin-graesslin.com/blog/2011/10/power-saving-and-desktop-effects/
        
        [^] # Re: bof ?
        
        Posté par cedric le 22 janvier 2014 à 11:07. Évalué à 4.
        
        KWin n'a pas a ma connaissance de compositing software :-) Je parlerais bien d'un mode dans lequel KWin fairait tout de meme les effets de compositing, mais en software au lieu de GPU.
        
        Ainsi tu as tous les benefices du rendu en compositing pour sauvegarder la batterie, comme limiter le nombre d'update a un framerate maximal. Mais tu ne payes pas les exces de OpenGL qui force le redraw complet de l'ecran (typique quand tu n'as qu'un curseur qui clignote a l'ecran).
        
        Et ce dont parle bien Martin dans cet article, c'est de desactiver le compositing completement et de s'appuyer sur X. Et ca je peux te dire, qu'il a raison. Tu n'as pas envie de laisser faire X de nos jours pour gerer le rendu a l'ecran (C'est une des raisons pour lesquels on se dirige vers Wayland).
        
        Bon apres, il y a des trucs qui seraient assez sympa et qu'on ne fait pas dans Enlightenment, c'est de faire un switch de profile quand on passe sur batterie pour automatiquement changer le nombre de FPS et passer en rendu software. Pour l'instant, ca, c'est a faire a la main.
        
        [^] # Re: bof ?
        
        Posté par Albert_ le 22 janvier 2014 à 11:11. Évalué à 4. Dernière modification le 22 janvier 2014 à 11:12.
        
        KWin n'a pas a ma connaissance de compositing software :-) Je parlerais bien d'un mode dans lequel KWin fairait tout de meme les effets de compositing, mais en software au lieu de GPU.
        
        Question debile (je n'ai vraiment aucune idee sur le sujet): XRender c'est pas du composite software?
        
        [^] # Re: bof ?
        
        Posté par cedric le 23 janvier 2014 à 03:56. Évalué à 5.
        
        Xrender, c'est de la p….. de m…. ! Et je suis serieux sur ce sujet, on aurait du l'abandonner il y a des annees deja ! Ca utilise une acceleration 2D fournit par le driver de X utilise. Techniquement depuis que ca existe, il n'y a jamais eu un seul driver qui l'implemente avec des performances correct (J'entend par la qui soit juste a la hauteur des performances du rendu en software sur CPU).
        
        En fait ca a toujours ete un ordre de grandeur plus lent que le rendu software dans les EFL, c'est pour ca qu'on en a abandonne le support. Sans compter que les deformations arbitraire ne sont pas possible et donc limite grandement ses possibilites. Ce fut une perte de temps. Il y aurait mieux valu travailler plus sur OpenGL pour en ameliorer ses performances et son adequation avec le rendu 2D. Au moins, c'est une erreur qui ne se reproduira pas avec Wayland !
        
        [^] # Re: bof ?
        
        Posté par barmic le 23 janvier 2014 à 08:42. Évalué à 4.
        
        On avait eu un très bon journal qui expliquait ça : En finir avec la lourderur de KDE.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: bof ?
        
        Posté par ariasuni le 23 janvier 2014 à 22:35. Évalué à 2.
        
        Perso j’ai jamais vraiment constaté de différence entre «Native» et «Raster».
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: bof ?
        
        Posté par deasy le 27 janvier 2014 à 03:55. Évalué à 2.
        
        ha bon ? et bien c'est un problème lié à ce qu'on a sur Linux car chez la concurrence utiliser un "bureau 3d" permet de consommer moins sur la batterie que du rendu 2d effectué en grande partie sur cpu(voir montée d'une utilisation cpu avec un bête déplacement de fenêtre en 2d et la consommation qui va avec)
        
        En fait cela charge le gpu au lieu du cpu et consomme nettement moins car le gpu fait ça bien plus facilement.
        
        [^] # Re: bof ?
        
        Posté par cedric le 01 février 2014 à 12:08. Évalué à 4.
        
        De quelle concurrence tu parles ?!? Je n'en connais aucune avec un début de performance 2d descente !
        
        Si tu as fais un peu d'opengl et de 2d, et que tu as essaye d'optimiser tout ça… tu auras découvert que ceux ci ne sont pas adapté du tout pour cette tâche et qu'on les contorscionne excessivement pour arriver a quelque chose !
        
        Ah sinon,sur un autre Linux, Android, ils ont effectivement le même "problème" , le mode sauver de la batterie force le passage en rendu cpu… et je parie que sur iphone, ils font de même. Faudrais que je passe un peu de temps un jour a détailler pourquoi le cpu est plus efficace …
        
        [^] # Re: bof ?
        
        Posté par ariasuni le 01 février 2014 à 14:27. Évalué à 4.
        
        Faudrais que je passe un peu de temps un jour a détailler pourquoi le cpu est plus efficace …
        
        Tu nous fais un journal?
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: bof ?
        
        Posté par deasy le 02 février 2014 à 04:27. Évalué à 3. Dernière modification le 02 février 2014 à 04:31.
        
        Que le cpu est plus efficace pour faire du rendu c'est de la foutaise…
        
        par ailleurs déplace une fenêtre sur n'importe quel os au point qui permet un rendu 2d ou composite, le composite consommera toujours moins de jus.
        
        Quand à la différence de consommation entre 2d et composite au repos il n'y en a pas ou tellement peu que ça n'est pas visible sur mon wattmètre.
        
        Par contre la différence de consommation entre un déplacement de fenêtre rendu cpu et rendu composite sur le gpu elle se voit.
        
        Et le gpu gagne haut la main autant en performance qu'en consommation.
        
        [^] # Re: bof ?
        
        Posté par cedric le 02 février 2014 à 06:37. Évalué à 3.
        
        Tu ne donnes aucune information concernant ce que tu tests… de plus, tu mélanges composite et rendu 2d. Ça n'a aucun rapport ! Donc je me répète, mais faire du rendu composite via le cpu est la plus part du temps plus performant en terme de consommation. Si tu parles de passer par x et non par un compositeur cpu, clairement x n'est plus compétitif et c'est pourquoi on se dirige vers wayland.
        
        Maintenant, une liste des choses ou un gpu n'est pas bon. Mettre a jour une partie de l'écran,genre le curseur qui clignote. Ou la mise a jour du contenu d'une fenêtre qui n'a pas été rendu sur le gpu (genre un film). Ça suffira comme exemple. Et ce serait bien que tu sois plus précis dans tes termes…
        
        [^] # Re: bof ?
        
        Posté par claudex le 02 février 2014 à 10:28. Évalué à 6.
        
        Ou la mise a jour du contenu d'une fenêtre qui n'a pas été rendu sur le gpu (genre un film)
        
        Pourquoi le film n'a pas été rendu sur le GPU alors qu'il y a des fonctionnalités dans les GPU pour ça ?
        
        « 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: bof ?
        
        Posté par cedric le 02 février 2014 à 10:44. Évalué à 4.
        
        Alors en general, l'acceleration materiel se limite au support d'un plan hardware specifique, overlay (ce qui permet d'eviter la mise a jour de l'ecran). Ce qui va avec cet overlay, c'est le support de la convertion hw de YUV->RGB. Pas vraiment de quoi casser trois pattes a un canard. Les fonctionnalites plus avance comme presenter par la va api et consort sont rarement configure et se limite a quelques codec (mpeg2 et h264 en general). Ce qui fait que statistiquement, ce n'est pas quelques choses sur lequel il faut compter.
        
        [^] # Re: bof ?
        
        Posté par Shuba le 02 février 2014 à 12:41. Évalué à 2.
        
        Est-ce que beaucoup de lecteurs savent exploiter la va-api d'ailleurs? Et est-ce que tous les drivers graphiques l'exposent?
        
        [^] # Re: bof ?
        
        Posté par claudex le 02 février 2014 à 14:20. Évalué à 6.
        
        Du côté des lecteurs, il me semble que mplayer, vlc et xbmc le gère. Par contre, au niveau des pilotes libres, il y a le driver d'Intel et le driver radeon ne propose que du VDPAU.
        
        « 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: bof ?
        
        Posté par Martin Peres (site web personnel) le 03 février 2014 à 19:26. Évalué à 6.
        
        Nouveau supporte VDPAU sur toutes les geforce 8+.
        
        [^] # Re: bof ?
        
        Posté par claudex le 03 février 2014 à 22:08. Évalué à 3.
        
        Bonne nouvelle, j'étais complètement passé à côté.
        
        « 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: bof ?
        
        Posté par deasy le 23 février 2014 à 14:18. Évalué à 1. Dernière modification le 23 février 2014 à 14:19.
        
        J'ai fait le test en raster qui il me semble est un rendu opengl sur cpu avec kwin.
        
        ça a l'air plus fluide et ça consomme un peu moins donc c'est vrai, le cpu s'en sort mieux.
- [^] # Re: bof ?
  
  Posté par arnaudus le 21 janvier 2014 à 13:56. Évalué à 2.
  
  A quand de vrai fonctionnalité pour l'utilisateur classique
  
  Est-ce que l'utilisateur "classique" a besoin de nouvelles fonctionnalités dans le noyau? C'est une vraie question. On peut bien sûr économiser quelques watts ou gagner quelques cycles de processeurs, rendre le système un tout petit peu plus responsif, etc. Mais l'ordre de grandeur des gains est faible par rapport à de potentielles améliorations du côté des applications : l'optimisation kernel me permet de gagner 2% alors que la pessimisation LibreOffice me fait perdre 250%…
  
  À part sur les performances des drivers (qui ne sont pas, philosophiquement, des composants d'un noyau d'OS), on ne peut attendre d'un noyau que des améliorations à la marge de la stabilité ou des performances…
  - [^] # Re: bof ?
    
    Posté par Nicolas Boulay (site web personnel) le 21 janvier 2014 à 14:09. Évalué à 2.
    
    fonctionnalité != vitesse
    
    Il y a encore des soucis sous linux : la gestion des binaires non issue de la distribution est un cauchemar. Le démarrage n'est pas encore foudroyant. Ou en est le support des écrans tactiles et du multitouch ? opencl c'est pour quand ? Les fonctionnalités de check point de btrfs dans un navigateur de fichier, cela existe ? Quand est-ce que copy() fera parti de vfs pour faire du copy-on-write sur les fichiers, et faire une copie en local NFS sans passer par un client ? A quand la gestion sous forme de cache de SSD, avec l'OS qui gère l'espace SSD mais dispose aussi d'un HD pour la grosse capacité ?
    
    "La première sécurité est la liberté"
    - [^] # Re: bof ?
      
      Posté par claudex le 21 janvier 2014 à 14:13. Évalué à 10.
      
      la gestion des binaires non issue de la distribution est un cauchemar
      
      Quel est le rapport avec le noyau
      
      Le démarrage n'est pas encore foudroyant
      
      La partie noyau est plutôt rapide, c'est au niveau du pid 1 que ça prend du temps et le noyau ne peut pas faire grande chose.
      
      Ou en est le support des écrans tactiles et du multitouch ?
      
      Du côté noyau, ça marche (cf. les mobiles et tablettes).
      
      opencl c'est pour quand ?
      
      C'est du WiP http://xorg.freedesktop.org/wiki/RadeonFeature/
      
      Les fonctionnalités de check point de btrfs dans un navigateur de fichier, cela existe ?
      
      Quel est le rapport avec le noyau ?
      
      A quand la gestion sous forme de cache de SSD, avec l'OS qui gère l'espace SSD mais dispose aussi d'un HD pour la grosse capacité ?
      
      C'est possible (voir la dépêche du noyau précédent).
      
      « 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: bof ?
        
        Posté par Nicolas Boulay (site web personnel) le 22 janvier 2014 à 10:14. Évalué à 1.
        
        Si une fonctionnalité existe dans le noyau mais qu'il n'existe pas d'outils pour l'utiliser, c'est comme si elle n'existait pas.
        
        "Quel est le rapport avec le noyau"
        
        C'est plus le rapport avec la communauté linux, il y a aussi des défis téchniques. Par exemple, il y a des études pour mettre en commun les pages mémoires identiques, ce qui est commun si les binaires utilisés sont compilés statiquement, ce qui est bien plus facile pour un binaire à utiliser sur plusieurs distribution.
        
        "La partie noyau est plutôt rapide, c'est au niveau du pid 1 que ça prend du temps et le noyau ne peut pas faire grande chose."
        
        Il y a des démarrages de drivers assez lent. Concernant la démarrage de la suite, la mise en cache peut être une idée. On peut aussi imaginer avoir un moyen de faire un réveil non pas depuis la dernière extinction, mais depuis le dernier démarrage valide (il me semble que les caméscopes Sony démarre comme ça).
        
        "La première sécurité est la liberté"
  - [^] # Re: bof ?
    
    Posté par Lutin le 21 janvier 2014 à 14:21. Évalué à 4.
    
    On peut penser au "200 lines miracle kernel patch".
    - [^] # Re: bof ?
      
      Posté par xcomcmdr le 21 janvier 2014 à 15:59. Évalué à 3. Dernière modification le 21 janvier 2014 à 16:00.
      
      Tu veux dire le ck patchset refusé, et ensuite repris par quelqu'un d'autre, et qui a ensuite été mergé ? ;-)
      
      Dans le même genre, il y a le "nouveau" ck patch set, aussi connu sous le nom de BFS (qui remplace le scheduler de processus actuel) et le BFQ I/O scheduler
      
      Quant à savoir pourquoi ce n'est pas intégré :
      - CK ne veut pas entendre parler du intégration au kernel officiel, vu son expérience précédente
      - + d'autres réponses
      
      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
      - [^] # Re: bof ?
        
        Posté par xcomcmdr le 21 janvier 2014 à 16:10. Évalué à 1.
        
        Pour ma part je suis revenu au kernel officiel depuis que linux-ck ne fonctionne plus chez moi. Sur mon ancien ordi (ASUS x71SL) ça ne fonctionnait plus après 3.10 - bloquage après chargement de l'image initrd -.
        
        Sur mon nouveau (ASUS N56-VV) ça fait un kernel panic de toutes façons au démarrage. Même avec la config par défaut pour la compilation du kernel - la même que pour le paquet core/linux -, la seule différence étant qu'on compile et active le BFS (sinon ça n'a aucun intérêt).
        
        De toutes façons, je n'ai plus les problèmes qui m'avait fait installer linux-ck (bureau qui se fige lors de grosses et pas si grosses I/O sur le HDD, surtout).
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
      - [^] # Re: bof ?
        
        Posté par Lutin le 21 janvier 2014 à 16:12. Évalué à 4.
        
        Le premier.
        
        J'ai été très pressé d'avoir ça dans mon noyau, avant de me rendre compte que je n'avais pas grand chose à compiler, et encore moins de choses nécessitant un -j64.
      - [^] # Re: bof ?
        
        Posté par ariasuni le 21 janvier 2014 à 16:42. Évalué à 2.
        
        Tiens, il ne supporte pas les cgroups. Je comprenais pas pourquoi j'avais un mot d'erreur en console lors de l'extinction de la machine.
        
        Ça expliquerais aussi peut-être pourquoi cups.socket ne fonctionne pas chez moi.
        
        Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: bof ?
    
    Posté par lolop (site web personnel) le 21 janvier 2014 à 21:34. Évalué à 10.
    
    Sauf que là c'est une dépêche sur le noyau et les développeurs qui bossent dessus, ils ne bossent pas sur LibreOffice — soit parce que leur employeur leur donne du boulot sur le noyau, soit parce que ce qui les intéresse techniquement c'est le noyau du système (mais ils peuvent avoir des occupations par ailleurs, par exemple un logiciel pour la plongée :-)
    
    Est-ce qu'il manque des développeurs sur LibreOffice, très probablement. Manque de motivation, ticket d'entrée élevé… je rêve d'un financement par l'État pour une participation au développement afin d'ajouter dans LibreOffice (et autres) ce dont il a besoin, au lieu de payer et repayer des licences bureautique à une grosse société des états unis d'amérique.
    
    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
  - [^] # Re: bof ?
    
    Posté par cedric le 22 janvier 2014 à 03:03. Évalué à 10.
    
    Je vois au moins deux choses qu'ils manquent aujourd'hui au noyau Linux et sur lesquels personnes ne travaillent a ma connaissance.
    
    La premiere chose, c'est la collaboration user-space/kernel space quand le systeme est sous pression memoire. Typiquement le comportement actuel est de ne jamais marquer une page memoire comme etant libere dans une application, mais de se baser sur le fait que si une page n'est plus utilise, on peut la swapper. Resultat on copie globalement des pages inutiles dans la swap… et cela impact les performances. Il serait nettement plus malin de pouvoir marquer des pages memoires comme sans importance pour l'user space de maniere a ce que le kernel puisse les jeter. Pour cela, il y a un patch actuellement en developpement, mais pas encore upstream. Meme si cela ameliorerait la situation, il resterait le cas ou tout le systeme commence a etre short niveau memoire. A ce moment la, les applications pourraient, de maniere cooperative, vider leur cache si elles ne sont pas active. Enfin en derniere recour, elle pourrait decider de s'arreter completement avant que l'OOM ne decide de les tuer, plutot que de faire un arret a l'arrache. Pour ces deux derniers cas, il n'y a pas a ma connaissance de travaux upstream sur le sujet (Android a une implementation partielle de ce genre d'idee).
    
    Le deuxieme endroit qui necessite des ameliorations, c'est le scheduling. Le noyau est completement aveugle a ce qui va se passer dans l'espace utilisateur. Il joue au devinette en esperant que ce qui s'est passe dans le passe va se repeter a court terme. C'est un peu domage, car les applications, elles savent ce qu'elles vont faire. Or dans un systeme moderne, le scheduling est devenu tres complique. Frequence et nombre de coeur actif variable. Characteristique des coeurs differentes. Difference de bande passante memoire, IO et CPU tres grande. Ce qui rend le boulot d'un scheduler assez impossible. Android a un scheduler un peu different maintenant, au lieu d'ajuster au fur et a mesure la charge, facon TCP, il fait un gros burst des qu'on lui en demande un petit peu et redescend progressivement (en frequence et coeur). Cela permet d'avoir une reactivite plus grande aux actions de l'utilisateurs. Mais cela n'est pas forcement optimal d'un point de vue energie. A quoi cela peut-il servir de demarrer un nouveau coeur, si on a une tache qui va etre bloque par les IO.
    
    La solution est "assez" simple, il faut que l'espace utilisateur donne l'information au kernel. Si le kernel peut savoir qu'il a des taches IO bound, memory bound ou CPU bound, il a alors une information nettement plus pertinente sur le futur et peux demarrer de maniere efficace avec la bonne frequence les coeurs qui sont necessaire avec une meilleur probabilite de reussite. Cela necessite de modifier la libc pour exposer un nouvel attribut sur les threads et aussi les process. Ensuite la majorite des operations sont maintenant fait par des toolkits comme Qt, les EFL voir meme la SDL et cela limite donc les endroit a modifier pour prendre avantage d'une telle solution.
    
    Voila, juste une petite liste d'idee de chose qui pourrait etre ameliore niveau user space et aurait un impact direct sur l'utilisation de tous les jours de ton PC. Avoir une machine plus reactive meme quand elle est charge et qui tire meilleur partie de sa batterie et de ses processeurs, ca serait pas mal comme amelioration, non ?
    - [^] # Re: bof ?
      
      Posté par Martin Peres (site web personnel) le 22 janvier 2014 à 03:19. Évalué à 8.
      
      La premiere chose, c'est la collaboration user-space/kernel space quand le systeme est sous pression memoire.
      
      Yep, je suis d'accord! Comme tu dis, Android a quelque chose et ça va venir dans le noyau.
      
      Le deuxieme endroit qui nécessite des ameliorations, c'est le scheduling.
      
      Ne pas confondre prise de décision sur la disponibilité des ressources (qui est une prise de décision sur la gestion d'énergie, basée sur les compteurs de performances) avec le scheduling. Le scheduling est là pour partager les ressources disponibles, la prise de décision sur combien d'unité de calculs à charger est indépendante de ça.
      
      Perso, je pense pas que demander aux applis ce qu'elles ont besoin soit pertinent. Surtout que le hw évolue. Les systèmes coopératifs, ça marche que si tu contrôles tous les programmes. Même Apple a laissé tombé ça!
      - [^] # Re: bof ?
        
        Posté par cedric le 22 janvier 2014 à 03:56. Évalué à 7.
        
        Desole de faire un gros tas de toutes les decisions de scheduling en mettant dedans aussi la prise de decision sur les ressources a rendre disponible pour les applications (puisque c'est globalement l'idee derriere allumer/eteindre et regler la frequence des differents coeurs). Mais bon, d'un point de vue user-space, c'est la meme problematique :-)
        
        Aujourd'hui, le noyau est aveugle. Il n'a aucune idee de ce qu'une tache va potentiellement faire dans le futur. Des IO ? Des acces memoire ? Une utilisation intensive du CPU ? Cela a directement un impact sur les performances, la reactivite et la consomation batterie. Il y a deja des cooperations entre l'user space et le noyau, c'est juste une de plus. Bien entendu le kernel ne vas pas baser ses decisions uniquement sur ces hints sans ajuster un peu a posteriori ses decisions, mais si le systeme coopere, c'est nettement plus malin. Si un toolkit fait du rendu graphique, il va pouvoir assez facilement indiquer quel thread va etre CPU ou memory bound dans le futur. Ce que le kernel ne pourra jamais savoir ou que lorsque ce sera trop tard.
        
        Ce n'est pas du cooperatif au sens de je relache le CPU quand j'ai fini de faire mes betises, mais du cooperatif au sens des hints qu'on met sur une page lors d'un mmap. L'idee est d'aider le noyau a prendre la bonne decision. Ca ne sert a rien d'allumer 4 coeurs pour 4 taches IO bound, par contre si elles sont CPU bound, ca serait une tres bonne idee de le faire tout de suite, et pas quand elles seront presque fini…
        
        [^] # Re: bof ?
        
        Posté par Martin Peres (site web personnel) le 22 janvier 2014 à 16:47. Évalué à 6.
        
        Pour la mémoire volatile, y'a la v10 d'un patchset qui est sorti le 2 janvier 2014. Des gens bossent dessus.
        
        Sinon, pour l'ordonnanceur, ça va t'apporter quoi de connaitre ces infos de ce que l'application PENSE qu'elle va avoir comme problème (oui, ça veut dire qu'elle doit soit utiliser les compteurs de performance et apprendre de ses expériences précédentes, soit elle doit avoir un modèle de performance du matériel sur lequel elle s'exécute)?
        
        Comme tu peux le voir, ce que tu demandes n'a pas vraiment de sens. À la limite, elle pourrait connaitre le nombre d'appels mémoire à faire et d'instructions à exécuter, mais comme elle a aucune idée de la topologie matérielle (NUMA) et de l'état des caches, elle pourra pas trop avoir une idée du temps qu'elle va mettre ou de ce qui sera le bottleneck.
        
        [^] # Re: bof ?
        
        Posté par Nicolas Boulay (site web personnel) le 22 janvier 2014 à 17:04. Évalué à 2.
        
        Je suis d'accord que l'information va vieillir avec l'amélioration du hardware, mais avec les mise à jour hebdomadaire, cela ne sera pas un problème.
        
        L'idée est de dire au noyau : cpu bound, memory bound, ou io bound. Cela permet de faire des réglages différents sur les différentes affectations (baisse de fréquence cpu ou bus mémoire, par exemple).
        
        "La première sécurité est la liberté"
        
        [^] # Re: bof ?
        
        Posté par Martin Peres (site web personnel) le 22 janvier 2014 à 18:00. Évalué à 9. Dernière modification le 22 janvier 2014 à 18:00.
        
        Je crois que tu sous-estimes à quel point c'est dur de prédire combien de CPU tu vas utiliser sur une machine pour exécuter une tâche.
        
        Le noyau se rendra bien vite compte que la machine est IO/CPU/memory bound avec les compteurs de performance, il pourra faire les modifications nécessaire à ce moment là.
        
        [^] # Re: bof ?
        
        Posté par cedric le 23 janvier 2014 à 03:51. Évalué à 10.
        
        Je bosses sur les EFL, toolkit graphique, on fonctionne avec un systeme pour l'instant avec uniquement 2 threads la majorite du temps (main loop et thread de rendu). Le fait est qu'il y a un certain nombre de probleme observable avec le "scheduler" actuel.
        
        Ainsi lorsque l'utilisateur n'a pas interagit avec la machine pendant quelques secondes et se met a faire une action importante (cas normal de je lis ce qui est a l'ecran avant de passer a un autre ecran), on se retrouve a avoir un enorme frame drop du fait que tous les coeurs sont globalement au repos, et qu'ils sont incapable d'accelerer instantanement tous en meme temps. Si on force a la frequence maximum et tous les coeurs allumes, il n'y a pas de souci. Or le toolkit sait quand il va rendre une frame, il sait dire a ce moment la qu'il va etre dans un premier temps CPU bound sur la traverse du scene graph et le calcul de ce qui doit etre dessine avant d'avoir un mix de CPU et memory bound en fonction des operations de rendu qu'il va faire (en GL, ca sera majoritairement du memory bound et on a un interet a avoir les deux threads schedule sur deux coeurs differents pour qu'ils puissent beneficier de tout le L1 possible).
        
        Et bien entendu quand le CPU est enfin completement reveille, il est trop tard. L'animation est fini et tout ce qu'il a appris du passe est juste plus d'actualite ! On se retrouve donc dans une situation ou tous les coeurs sont enfin allume et la frequence au maximum, mais on n'a plus rien a faire. Echec total du scheduler et utilisateur ayant l'impression d'avoir un hardware incapable de gerer son application.
        
        D'ou l'interet de permettre a l'user space de dire au kernel ce qu'il se passe. On sait ce qui va se passer, on sait combien de temps notre animation va durer. De plus, si on avait une telle infrastructure, ca vaudrait le cout d'augmenter le nombre de thread en les specialisant encore plus. On pourrait tirer clairement mieux parti du hardware si le kernel et l'user space communique un peu plus. Il ne faut pas oublier qu'un toolkit moderne fournit toutes les primitives d'acces aux systemes graphiques et IO ainsi qu'une certaine abstraction des threads. Il est donc possible que dans la majorite des cas, le fait de juste integrer ces hints dans le toolkit soit suffisant pour avoir un benefice notable.
        
        L'alternative moins elegante est celle d'Android. Elle consiste a toujours refuser le dialogue avec l'user space et a faire un scheduling ou on boost le CPU au moment d'une phase interactive. Je ne trouve pas cette solution elegante, car le systeme va faire une pointe de consomation d'energie qui n'est probablement pas necessaire (et plus on aura de coeurs, plus cette pointe risque d'etre surdimensionne).
        
        [^] # Re: bof ?
        
        Posté par fmaz fmaz le 23 janvier 2014 à 11:51. Évalué à 3.
        
        Si ce genre de chose existait, ne serait-il pas très simple pour un programme méchant pas bô de forcer le noyau à faire n'importe quoi ?
        
        [^] # Re: bof ?
        
        Posté par cedric le 23 janvier 2014 à 14:02. Évalué à 10.
        
        Suffit de faire une bête boucle infini dans plusieurs thread pour obtenir le même résultat.
        
        [^] # Re: bof ?
        
        Posté par turanga leela le 26 janvier 2014 à 14:54. Évalué à 2.
        
        peut-être un travail intéressant pour le futur kdbus ?
# Honte

Posté par antistress (site web personnel) le 21 janvier 2014 à 18:26. Évalué à 7.

J'ai honte de voir mon nom cité je n'ai rien fait cette fois à part encourager les autres dans le bandeau de discussion !
- [^] # Re: Honte
  
  Posté par navaati le 21 janvier 2014 à 22:53. Évalué à 8.
  
  Bah, tu les a déstressés, ça compte.
  
  (->[])
# technique

Posté par Thom (site web personnel) le 21 janvier 2014 à 20:45. Évalué à 9.

Il n'y a vraiment plus aucun intérêt à être sur LinuxFr pour des articles techniques. ;)

Merci pour la dépêche.

La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
# Armada

Posté par antistress (site web personnel) le 21 janvier 2014 à 21:24. Évalué à 2.

Peut-on avoir des liens pour approfondir l'info sur le pilote 2d armada (qui le développe d'ailleurs ? De mémoire Vivante Corp avait publié il y a quelques temps un pilote libre partiel : la partie noyau seulement, sous licence GPL, mais rien concernant le pilote en espace utilisateur) et dans quelle mesure cela peut aider le pilote 3d communautaire ? Je ne vois aucune mention sur le blogue de Wladimir J. van der Laan (à l’œuvre sur le pilote 3D). Merci !
- [^] # Re: Armada
  
  Posté par antistress (site web personnel) le 21 janvier 2014 à 22:28. Évalué à 1.
  
  Source (je grasse) :
  
  Wladimir J. van der Laan (etna_viv): Vivante did not release their full driver as open source. The kernel component is available as open source (GPL) however the user space components which consist of the GLES(2) implementations and a HAL library are not. These, however, contain the bulk of the driver logic. My work was to painstakingly find out and document the state bits, command stream, and shader ISA by studying how these blobs work by examining and manipulating command stream dumps. And now I am working on using this information to build a Gallium driver.
  
  http://blog.emmanueldeloget.com/index.php?post/2013/01/12/Open-source-drivers-for-SoC-GPUs#c2102
  
  Wladimir J. van der Laan (etna_viv): The starting point of my development was a rooted Rockchip 2918 tablet a friend gave me. I wanted to hack on it, and when I first started playing with android rendering internals, I hoped it'd have any of Mali, Adreno, etc GPU. But it turned to be this (new to me) Vivante GPU. As there was no project making open source drivers for those yet I thought it'd be fun to see how far I'd get. I also wanted to do some experiments with binary static analysis and symbolic execution to automatically map GL state to HW state.
  In contrary to the userspace, the kernel driver is GPLed, which is great and I found various instances of the GPL drivers in SoC kernel trees. Unfortunately at first, none exactly matched the interface of my device. It took some puzzling with fields to get that part right, but it helped me along greatly in understanding the hw and kernel interface.
  After a month or so I found out that there were some more things already out there. There is the (defunct) gcx project which was working on an accelerated 2D driver, and some TI OMAP documentation about the 2D hardware. Nothing about 3D, though (that's the same as with many other GPU vendors). This did help me fill in some gaps in the command stream format as the 2D and 3D pipe share the same DMA interface.
  
  http://blog.emmanueldeloget.com/index.php?post/2013/03/08/The-SoC-GPU-driver-interview
- [^] # Re: Armada
  
  Posté par Martin Peres (site web personnel) le 22 janvier 2014 à 00:51. Évalué à 2.
  
  Ce pilote a été écrit par Russel King. C'est un pilote communautaire qui n'a rien à voir avec le pilote officiel.
  
  Maintenant, le driver libre Vivante, et_naviv, peut utiliser ce driver directement pour afficher ses images, probablement sans recopie (si Armada, le CPU et Vivante partagent la même mémoire et que les IOMMUs sont programmées relativement pareil.
  
  Vu que Wladimir a l'air de vouloir faire un driver gallium, ça veut dire qu'on devrait bientôt un support totalement upstream et libre sur certains SoC! C'est super cool :)
  - [^] # Re: Armada
    
    Posté par antistress (site web personnel) le 22 janvier 2014 à 00:56. Évalué à 2.
    
    et par rapport à ce pilote 2d libre pondu par Vivante cité ci-dessus, tu as des infos ? Il est caduc ou est utilisé du coup ?
    - [^] # Re: Armada
      
      Posté par Martin Peres (site web personnel) le 22 janvier 2014 à 01:04. Évalué à 1.
      
      No idea! Comme dit plus bas, j'ai vraiment peu d'expérience là dessus. Déjà, je fais de mon mieux pour écrire dessus dans les dépêches! Maintenant que j'y fais plus attention, j'espère apprendre des choses et pouvoir vous répondre ;)
# tegra, ça me grate

Posté par antistress (site web personnel) le 21 janvier 2014 à 22:41. Évalué à 2.

Le pilote pour la version embarquée des GPU NVIDIA (Tegra), a été ré-architecturé pour être découpé en deux sous-parties, host1x et tegra.

Dans mon souvenir, suite notamment il me semble à des discussion précédentes avec mupuf, le pilote pour les GeForce ULP (Ultra Low Power) qui équipent les SoC ARM Tegra s'appelle grate ? C'est plus Erik Faye-Lund alias kusma qui opère dessus ?

je m'y perd un peu, du coup ! Au final quel est le pilote DRM et quel est le pilote 3D ? C'est linux 3.8 qui introduit le pilote 2D pour Tegra et linux 3.10 qui introduit le pilote 2D avec KMS pour Tegra ?
- [^] # Re: tegra, ça me grate
  
  Posté par antistress (site web personnel) le 22 janvier 2014 à 00:58. Évalué à 2.
  
  (c'est pour tenir à jour https://fr.wikipedia.org/wiki/Pile_graphique_Linux#C.C5.93urs_graphiques_.C3.A9quipant_les_syst.C3.A8mes_sur_une_puce)
- [^] # Re: tegra, ça me grate
  
  Posté par Martin Peres (site web personnel) le 22 janvier 2014 à 01:00. Évalué à 2.
  
  Oula, on avait parlé de ça ensemble? Je dois perdre la mémoire.
  
  Bon, je crois que tu te mélanges en effet bien les pinceaux. Quand je dis que le support de la 2D et de la 3D est possible, ça veut dire que le noyau est capable d'initialiser le ou les blocs nécessaire pour faire marcher le tout. Ensuite, il est capable de récupérer les commandes générées par le userspace et les envoyer à la carte, vers le bon moteur (chez NVIDIA, c'est le hw qui se charge de ça).
  
  Je ne sais pas pourquoi la 2D et la 3D sont séparés, probablement pour des questions d'économies d'énergie. Le moteur ayant plein de transistors et n'étant pas optimisé pour le rendu 2D.
  
  Quoi qu'il en soit, le projet grate est un driver gallium qui permet de générer des commandes à envoyer aux processeurs Tegra. Et pour ça, il a besoin de pouvoir communiquer avec le driver en espace noyau (drm/tegra). Ce driver est écrit par kusma, semble t'il. Ça fait un moment que je le vois plus sur #nouveau et j'avoue que j'ai pas trop prêté attention aux pilotes graphiques ARM jusqu'en Septembre ou j'avais demandé à Rob Clark si il pouvait pas faire un récapitulatif pour l'XDC2013. Voilà la présentation avec la vidéo.
  - [^] # Re: tegra, ça me grate
    
    Posté par antistress (site web personnel) le 22 janvier 2014 à 01:21. Évalué à 2.
    
    Cool, je vais voir ça merci Martin!
# nftables vs pf

Posté par siwoti le 26 janvier 2014 à 20:37. Évalué à 6.

Nftables a certes l'air d'apporter énormément d'améliorations par rapport à iptables mais reste quand même un cran en dessous de pf.

Pourquoi ils ne portent tout simplement pas pf sur linux ? Est-ce compliqué/impossible techniquement ? Une histoire d'ego ("si je porte pf ça veut dire que BSD est mieux") ?
- [^] # Re: nftables vs pf
  
  Posté par claudex le 26 janvier 2014 à 21:36. Évalué à 4.
  
  C'est sans doute compliqué mais à mon avis, le principal problème, c'est de garder la compatibilité avec l'existant, et ça, c'est peut-être impossible
  
  « 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: nftables vs pf
    
    Posté par Krunch (site web personnel) le 26 janvier 2014 à 23:02. Évalué à 3.
    
    Le gros intérêt de passer à pf à mon avis ça serait justement de casser la compatibilité dans le sens où ça introduit une syntaxe quand même vachement plus utilisable (et documentée).
    
    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
    - [^] # Re: nftables vs pf
      
      Posté par claudex le 26 janvier 2014 à 23:05. Évalué à 5.
      
      Mais on ne peut pas laisser tomber toutes les configurations actuelles qui marchent, il faut donc soit une couche de compatibilité qui ne va pas être simple à mettre en place, soit deux pare-feux incompatibles dans le noyau, je doute que ça plaise aux développeurs.
      
      « 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: nftables vs pf
      
      Posté par barmic le 27 janvier 2014 à 00:01. Évalué à 6.
      
      Une bonne partie de l'intérêt de nftables ne réside pas dans la syntaxe de la commande, mais dans ce qui est fait derrière notamment du point de vu des performances. On avait un journal là dessus https://linuxfr.org/users/switcher/journaux/nftables-successeur-diptables (il y a peut être des choses fausses dans la syntaxe, ça a 5 ans maintenant)
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Suivre le flux des commentaires

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