Mais elle n'est pas la GPLv3. L'histoire du « loophole » ne s'applique pas ici.
> et toutes les critiques contre la FSF
Tu a raison, débarrassons nous de cet infâme esprit critique. Sachons louer nos maitres sans trop réfléchir. Si c'est du Stallman, ça ne peut qu'être bon, ne cherchons pas plus loin.
> normal, le logiciel libre est un sujet politique
Le problème est de tenter de forcer les développeurs, ceux qui font le travail en somme, à suivre leur conception évolutive de ce que doit être un licence. Stallman est un control freak, un petit dictateur : il a su le montrer à d'autres occasions encore.
Un autre aspect de cette clause 13 que je trouve très mesquin et politique, c'est celui-ci :
« Notwithstanding any other provision of this License, you have permission to link any covered work with a work licensed under version 3 (or any later version published by the Free Software Foundation) of the GNU General Public License, and to convey the resulting combination. »
Ils auraient pu donner le droit de « linker » le logiciel avec du code sous « GPLv2 or any later version » ; le fait de spécifier le plancher à la v3 me semble une façon franchement mesquine de pousser leur agenda politique en faveur de la GPLv3, de forcer la main (exactement à la façon de http://lwn.net/Articles/176582/ ).
Tu a raison, et j'ai été un peut vite. Il faudrait dire « ton code sera _potentiellement_ sous une licence que tu n'a pas choisi ».
Concrètement, le problème se posera très probablement lorsqu'un mainteneur d'un logiciel acceptera un patch ajoutant du code « GPLv3 ou plus » (dans ce cas, l'ensemble du logiciel devient « GPLv3 ou plus »), ou lorsqu'un autre logiciel, sous v3, intègrera ton code dans son logiciel sous GPLv3 (ce code sera alors considéré « v3 », et tu ne pourra récupérer ses modifications qu'à condition de migrer ton projet en v3).
Des conflits potentiels de ce type se dessinent aujourd'hui. Par exemple : je lis régulièrement la mailing-list de busybox. L'initiateur de ce projet, Bruce Perens, avait choisi une licence "v2 ou plus", mais a quitté le projet depuis plus de 5 ans (et en pratique, on ne retrouve quasiment plus rien de son code initial dans le code actuel). Les développeurs actuels n'aiment pas du tout la v3 et ont voulu indiquer que l'ensemble du projet serait désormais "v2 only". C'est ce moment qu'a choisi Perens pour revenir sur les mailing-lists, non pas pour aider avec le code, mais pour indiquer qu'il s'opposait à cette décision. Il a d'abord tenté de convaincre les développeurs que leur décision était illégale, a échoué, et a finalement annoncé qu'il forkerait le busybox sous v3. Beaucoup de conflits, de développeurs actifs dégoutés ou ulcérés, certains ont abandonné le projet parce que la pression _politique_ de la FSF et de Perens leur tapait sur le système ...
Même pression politique ici : http://lwn.net/Articles/176582/ . La FSF interdit désormais les projets "v2 only" sur Savannah. Pression politique (au sens anglais « politic agenda ») sur les devs kernel et Linus en particulier (voir l'exemple récent dans le lien ci-dessous, http://kerneltrap.org/node/8382 ) où l'on tente (mais de quel droit ?), à répétition, de convaincre Linus de passer en v3 en arguant qu'il « n'a pas compris » (ce qui est gonflé). Ce forcing « politique » montre que la FSF, plutôt que de chercher le consensus pour la nouvelle GPL, ou de refléter et considérer les remarques des développeurs, les premiers concernés, tente de faire passer ses décisions et ses choix de force. La prudence s'impose, donc.
> Perso, je fais plus confiance à la FSF qu'aux licences proprio.
Ah, parce que c'est la seule alternative ? Ou c'est la vieille technique de rhétorique « si tu ne soutient pas tout les excès de notre leader jusqu'au bout, si tu ne t'engage pas aveuglément tu es contre lui » ?
On peut pourtant choisir la GPLv2 (ou une autre licence libre) sans signer un chèque en blanc à la FSF. Je n'aime pas plus le proprio que toi.
> On peut avoir le droit de penser que la FSF en entier vont retourner leurs vestes, mais je n'y crois pas
On peut aussi penser qu'ils pourraient, peut-être, peu à peu, s'engoncer dans une dérive dictatoriale, être de plus en plus politiques et de plus en plus déconnecté des problèmes concrets des développeurs du libre, ...
Je ne dit pas qu'ils en sont là actuellement, mais je crois que le risque existe. La GPLv2 définissait des règles de liberté qui concernaient le logiciel (comme dans Free Software Fundation). La GPLv3 ajoute notamment des règles aux fabriquant de hardware leur disant comment utiliser le code : ils ont étendu le domaine d'application de leur concept de « liberté » au matériel. Aussi religieusement stallmanien soit-tu, il serait naïf de penser que tu pourrai le suivre dans toute les choix possibles « d'imposer la liberté » s'il le faisait vraiment jusqu'au bout de sa conception de la liberté (la liberté s'arrète, toussa + la fin, les moyens, toussa).
Peut-être espère-tu, comme moi, qu'ils ne dépasseront pas les limites (qui les feraient basculer dans une attitude dictatoriale), peut même « croit » tu qu'il ne le dépasseront pas cette limite, mais penser qu'il ne faille absolument pas se prémunir contre un débordement relève du domaine de la religion.
Rob Landley raconte qu'il avait, un jour, prêté sa voiture à Stallman, et que ce dernier la garait dans une grande ville US sans la fermer à clef, par conviction idéologique...
« De toutes façon, licencié un soft en GPLvX only est très imprudent, puisque en cas de faille dans la licence, ca peut craindre grave. »
Licencier un soft en "GPLvX et plus" est très imprudent, puisqu'en cas de délire de RMS (ou son successeur à la tête de la FSF, ou de délire de la FSF complète), ton logiciel sera sous une licence que tu n'a pas choisi.
Même chose dans le cas où la FSF ajoute des restrictions qui ne correspondent pas à ta vision de la liberté. Ce qui est en passe d'arriver à beaucoup de gens, avec la GPLv3. Même si, par chance, tu approuve les nouvelles restrictions apportées de la GPLv3, qui te dit que tu ne fera pas partie des cocus pour la GPLv4 ?
"GPLvX et plus", c'est signer un chèque en blanc. À des gens que tu ne connais pas (RMS ne sera pas éternellement là). Choisir le "et plus", c'est un engagement religieux, une croyance : le choix d'une licence doit être à l'inverse fait avec prudence, vigilance, et en étant certain de savoir et comprendre ce que l'on choisit.
Elles sont seulement un peu moins intenses que pour le premier brouillon de la nouvelle GPL.
Je vous recommande chaudement de lire ce thread, qui date des deux derniers jours (13 et 14 juin 2007) en entier : http://kerneltrap.org/node/8382
Linus y donne expose très clairement son point de vue, et rejette efficacement le terme de "misunderstandings" qu'utilisait réthoriquement Esben Morgen pour balayer les critiques, au lieu de les prendre en compte.
« Le premier danger majeur que la GPLv3 bloquera est la tivoisation (néologisme voir l'affaire TiVo). »
Elle risque d'avoir du mal à bloquer ça, la GPLv3, dans la mesure ou le kernel restera plus que probablement sous GPLv2, ainsi que la glibc (et la ulibc) et que busybox. Bref, tout les softs qui concernent le monde de l'embarqué.
C'est ce qu'on obtient lorsqu'on pousse son agenda politique sans s'intéresser au point de vue de ceux qui font le boulot, les développeurs.
Pas de proco haut de gamme (ce n'est pas un pentium-m, hein, 600MHz seulement),
Tu a une source à ce sujet ?
Car le journal indique « processeur basse consommation (intel mobile A100 ou A110, soit 600 ou 800MHz) » (ainsi que cette source : [http://www.linuxdevices.com/news/NS9292516116.html])
Ce serait vraiment dommage que l'ordinateur n'utilise pas un processeur mobile : cela signifierai qu'on ne pourrai pas faire grand chose pour améliorer l'autonomie, un peut faible, de cet ordinateur (tandis qu'avec un processeur mobile, si le « 3h » indique l'autonomie sous Windows XP, alors on peut espérer 4 ou 5h avec un Linux bien ajusté).
Bref, le gros travail actuellement mené par les développeurs dri/xorg/kernel pour intégrer de nombreux composants (comme le modsetting, un nouveau gestionnaire de mémoire nommé TTM, la refonte de fbdev, ...) dans le noyau Linux permettra de corriger ce problème.
C'est un gros chantier cependant. Pour le moment il y a eu beaucoup de discussions entre les développeurs de drivers graphique, et seul le plan d'action (et une ébauche de code) a été soumis pour revue sur la LKML, même pas pour intégration dans -mm, (et Keith Packard ou Dave Airlie ou Eric Arnolt, je ne sait plus, considère qu'il faut tout ré-écrire).
Oui, le rétro-éclairage (backlight) et la luminosité (brightness, ps: je ne suis pas sûr que ce soit les traductions standards pour ces deux mots) sont parmi les plus gros consommateurs d'énergie sur les portables. Pavel Macek (développeur noyau chez SuSE) dit même « le plus gros consommateur » dans son étude [http://atrey.karlin.mff.cuni.cz/~pavel/swsusp/8hours.pdf].
Cela étant, ces deux aspects (backlight et brightness) sont censés être connus et automatiquement et adéquatement ajustés par le daemon acpi (et ses scripts de configuration /etc/acpi/*) selon que l'ordinateur est branché sur secteur ou pas, sur les distributions modernes. Et on est censé pouvoir lui faire confiance pour gérer ça au mieux. Si acpid ne fait pas ce travail de façon optimale sur ton ordinateur, ça mérite un rapport de bug.
Mais il est pertinent de rappeler que l'écran joue pour beaucoup sur la consommation électrique : ainsi ceux pour qui l'autonomie est un critère prioritaire devraient privilégier les ordinateurs avec de petits écrans (un exemple : Keith Packard obtient 7h d'autonomie sur son Panasonic R4 avec un écran 10 pouces).
Une petite question pour ceux qui ont déjà installé cette nouvelle Fedora. Pourriez-vous nous indiquer si le noyau supporte les options suivantes s'il vous plait ? :
CONFIG_HIGH_RES_TIMERS
CONFIG_TIMER_STATS
CONFIG_HPET
CONFIG_CPU_FREQ_GOV_ONDEMAND
CONFIG_USB_SUSPEND
CONFIG_SND_AC97_POWER_SAVE
CONFIG_ACPI_BATTERY
Pour le savoir il suffit normallement (si CONFIG_IKCONFIG_PROC est activé) de faire : zgrep $option /proc/config.gz (par ex. zgrep CONFIG_HPET /proc/config.gz).
Ou mieux : existe-t-il une URL pour télécharger le .config de Fedora ?
J'ai hésité à faire un journal sur le sujet, en janvier/février lorsque ce point était débattu (avec virulence !) sur la mailing-list du WHATWG.
L'idée (au départ, des développeurs d'Opéra) était d'avoir un remplaçant standard et libre pour l'utilisation « diffusion de vidéo » de Flash (assez à la mode en ce moment : voir youtube, dailymotion ou encore google video).
Mais, et ce fut très intéressant, les développeurs de Safari (le navigateur d'Apple) ont fait le forcing pour que le standard ne suggère pas (« should ») les formats/containeurs/codecs OGG / Vorbis / Theora. Évidement, beaucoup de participants à la m-l leur ont demandé plus d'explication (à ce point des développeurs de Itunes/Ipod sont arrivés ...) : la raison indiqué était ... le risque des brevets !
En effet les avocats d'Apple ont estimé que supporter ces formats libres était finalement plus risqué que de payer une bonne licence au MPEG-LA : il est possible qu'un brevet « dormant » attende, tapi dans l'ombre, qu'une société suffisamment riche diffuse des produits implémentant leur propriété intellectuelle pour attaquer. Et ces procès, perdus, coutent très cher. Un employé de Nokia participant à la m-l à confirmé : pour cette raison, Nokia ne souhaite pas déployer du ogg/vorbis/theora. On comprends à posterio l'absence de ces codecs dans les PDA Nokia N700 et N800, pourtant sous Linux.
Bref, ça me déprime : l'expansion des formats libres et ouverts et elle aussi minée à cause des brevets ! Et on n'est pas prêts de voir ce support optionnel « should » implémenté dans Safari ou Internet Explorer.
des distri qui soient en 2.6.21 ça ne coure pas les rues, non?
Certes, mais pour jouer, se faire un petit 2.6.21 (voir un 2.6.22-rc3) temporaire ne prends pas bien longtemps (et on peut encore plus rapidement revenir en arrière). Bénéfice secondaire, quand ta distrib passera au 2.6.22, le support de ton matériel par le noyau sera déjà testé (et les éventuels bugs, peut-être reportés) ;)
Sinon, la Fedora 7 vient de sortir, avec un noyau 2.6.21 (je ne sait pas si elle a CONFIG_TIMER_STATS activé par défaut) ...
Pour autant que je sache, c'est ce que font les outils qui extraient les sous-titres de DVD (au format vidéo mpeg-2) vers un format texte.
Il y a un bout de code pour ça dans les sources de mplayer (ça converti la vidéo en une suite d'images statiques, et passe gocr dessus).
Un logiciel userland qui sélectionne le « governor » CPU et qui bouffe lui-même plein d'énergie ? Tu peut le désinstaller je pense.
D'autant plus qu'Arjan est formel sur ce point : il n'y a aucune ambiguité, le governor le plus adapté pour les environnements Intel (donc y compris les macbooks), c'est « ondemand ». Les autres sont moins efficaces. Pour l'activer, fait ceci pour chaque CPU :
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
pour le reste c'est du noyau.
Oui mais c'est bien souvent le userland qui conduit le noyau à recevoir des interruptions USB et ATA (note : outre les réveils de la CPU, le fait de maintenir une activité sur ces bus les empêchent d'activer leurs propres modes d'économie d'énergie indépendants, tels que USB_SUSPEND, dont ils sont tout deux dotés).
Comme je disait plus haut, dans ton cas (usb_hcd_poll_rh_status et libata), je soupçonne "hald". Est-ce que ces lignes disparaissent si tu killall hald ?
De plus, toujours pour réduire les accès disques ou leur impact, tu peut activer le mode laptop si ce n'est pas déjà fait ( echo 5 > /proc/sys/vm/laptop_mode) et monter les partitions pour lesquelles tu ne t'intéresse pas au dates de dernier accès aux fichiers en "noatime". Bon, pour l'USB, il y a aussi un problème connu affectant les macbooks, qui fait que la gestion du clavier est très gourmande (mais un patch existe, peut-être même déjà intégré dans 2.6.22-rc3).
Combien de réveils par secondes et de Watt consommés si tu décharge le module wifi et applique ces astuces ? (ça m'intéresse beaucoup parce que j'envisage de me procurer un macbook aussi :).
Ah oui c'est bien dommage pour l'article Métaheuristique. (En partie) d'accord aussi avec la remarque sur l'évaluation parfois trop portée sur la forme, mais il faut tout de même reconnaître que ces articles sont très techniques (les fourmis aussi).
On a un peu moins de problème avec les articles sur le cinéma, par exemple (sujets assez abordables, et de nombreux participants au projet ciné).
As-tu pensé à signaler le vote AdQ aux projets Informatique et Mathématique ? je suppose que les experts sont là... En tout cas bravo pour le joli travail sur les algos !
Que peut-on faire, toi; moi et tous les autres afin d'atteindre un niveau de qualité suffisant ?
L'article est très agréable à lire, mais si tu cherche des idées d'améliorations, ... il y a toujours moyen ;)
J'ai seulement parcouru l'article en diagonale, mais un premier point qui m'a frappé : il faudrait ajouter des références pour les affirmations non triviales ou biographiques. Les évaluations lors des votes AdQ sont de plus en plus exigeantes sur ce point, et là, sans *aucune* référence, il aurait du mal à passer.
C'est peut-être un peu plus difficile pour un article d'informatique ou scientifique que pour un article, par exemple, d'histoire, d'économie ou une biographie, mais il est toujours possible de se baser sur les normes et les spécifications (au moins, ce sont des références _solides_ s'il en est !).
Ou bien par exemple :
« Jeremie Miller a commencé le projet en 1998 » [ à sourcer ].
Le bénéfice pour le rédacteur n'est pas à négliger : en cherchant à « sourcer » toutes ses affirmations, on s'apperçois toujours qu'on avait une vision trop approximative de certains aspects de son sujet. Et on devient nettement plus pointu ainsi.
Une autre limite, c'est peut-être un manque détails concernant la description technique du standard (synthèse des RFC concernées, etc.).
Pour ce dernier, on notera la relative abondance des notes de base de page (les « sources ») et en page de discussion, on relevera aussi l'excellente idée des auteurs de l'article : ils ont demandé à un spécialiste de leur sujet (en fait _le_ spécialiste) de le relire et le valider. Résultat, on a probablement le meilleur et le plus solide écrit en langue française sur l'algo des fourmis : le jeu en valait la chandelle, non ?
Le document date de deux ans, mais il est toujours très intéressant, et son auteur, Dominik Brodowski (qui est au passage développeur noyau de cpufreq) a vu très juste : il a parfaitement anticipé les évolutions du noyau dont on peut aujourd'hui profiter et les problématiques actuelles !
Le projet PowerTOP avance à un rythme effréné (et pour cause, Arjan y travaille à plein temps). Il y a eu 5 releases depuis la rédaction du journal (de la 1.0 on est aujourd'hui à la version 5) !
Quelques compléments d'infos donc :
* Avant que je journal soit « niouzifié », j'ai écrit d'autres compléments d'informations ici : http://linuxfr.org/comments/831869.html#831869
* Keith Packard, développeur d'Xorg, témoigne : « Avec PowerTOP, j'ai réussi à améliorer l'autonomie de mon portable Panasonic R4 de 4 heures à presque 7 heures » [http://www.linuxpowertop.org/success.php] Bref, attendez vous à des progrès sensibles !
* Le panel des suggestions proposées par l'outil s'étend maintenant à l'espace utilisateur. Il est désormais capable d'appliquer certaines des propositions lui-même, à la volée.
* L'affichage utilise désormais ncurses, et c'est plus confortable.
* PowerTOP est intégré dans les versions de développement de la plupart des distributions maintenant.
* Il est désormais traduit en français, et doté d'une page de manuel.
* Les développeurs de Gaim Pidgin ont déjà sorti une nouvelle version, 2.0.1 corrigeant les problèmes levés par PowerTOP. Bravo !
* L'astuce « Option "NoDRI" » indiquée pour le problème des drivers i915 fonctionne aussi pour les drivers radeon et fglrx
* Vous verrez peut-être "i8042" assez haut dans la liste des causes de réveils. Il s'agit du pilote clavier. Le problème est connu.
* Vous verrez peut-être aussi des choses comme "[interrupt] : ide1" (ou libata ou ide0 " alors que vous ne pensez pas utiliser les disques. C'est probablement hald qui les surveille (re-testez après avoir tué hald).
* Si l'une des applications les plus gourmandes sur votre système affiche des select() ou poll() en boucle lorsque vous faites "strace -tt -p $(pidof monapplication)", ce n'est probablement pas normal, les développeurs ont probablement choisi des timeout trop courts.
* Beaucoup de gens se demandent pourquoi ils ne voient pas les C-states C3 et C4 sur leur machine. 1) essayez après avoir débranché le cable d'alim (sur batterie, quoi). 2) tout les processeurs/BIOS ne supportent pas ces C-states (attention à la confusion : /proc/acpi/processor/*/power indique "max_cstate: C8", mais c'est seulement le nombre de C-states que supporte le noyau Linux, pas le nombre physiquement implémenté dans le matériel).
* On vois beaucoup de confusion au sujet de HPET sur la m-l de PowerTOP. Je vais donc essayer de préciser. HPET est une source d'évenements temporels (une « event source for timers ticks », pas une « clocksource ») alternative au traditionnel mais ancien PIT. PIT a une grosse limitation : il ne peut dormir plus de 26ms, et génère donc en conséquence une trentaine d'interruptions par secondes (symptôme : PowerTOP affiche quelque chose du genre : « ( 27.3) [interrupt] : extra timer interrupt »). HPET est théoriquement supporté par le matériel récent (mais pas toujours), mais il faut qu'il soit activé dans le noyau, et surtout, que le BIOS ne le masque pas (ce qui est très courant : les mauvaises langues disent que les fabriquants de portables le masquent parce que, n'étant pas supporté par WinXP, cela afficherai un point d'exclamation jaune dans le gestionnaire de périphérique de Windows). Sur le site de PowerTOP, on trouve une solution à ce problème : un patch noyau qui force l'activation d'HPET, nonobstant les indications du BIOS. Bref, il ne suffit pas d'avoir HPET dans le noyau pour qu'il soit actif sur votre système : pour le vérifier, grep "Clock Event Device" /proc/timer_list .
Un petite déception : très peut d'utilisateurs témoignent des problèmes qu'ils rencontrent (pourtant Arjan est très newbie friendly. Franchement) et n'indiquent pas leurs découvertes d'applications ou modules noyau les plus gourmands (condition sine qua non pour que le problème soit corrigé). À moins que les utilisateurs de PowerTOP soient tout simplement très peu nombreux.
Visiblement, beaucoup semblent penser que « quelqu'un l'a déjà fait, un autre développeur du logiciel gourmand foo doit probablement avoir utilisé powertop » (remarque que j'ai plusieurs fois reçu lorsque j'ai indiqué des problèmes découverts par PowerTOP à des développeurs).
En réalité, peu de projets sont avertis de ces problèmes, et on découvre chaque jour des applications pourtant extrêmement utilisées dont personne n'a reporté le comportement inadéquat. La possibilité d'identifier ces comportements facilement est très récente, et le champs très vaste, c'est une véritable forêt vierge. En conséquence il reste énormément d'environnements logiciels à défricher, énormément de low hanging fruits à ramasser, c'est très facile, alors venez vous amusez ! :)
« GCC 4.2 propose également des options pour rendre plus strict le contrôle du code lors de la compilation. En passant les options -fstrict-overflow et -Wstrict-overflow on peut maintenant se rendre compte d'erreurs du type débordement de la pile. »
En fait les options -(f|W)strict-overflow font des vérifications sur les débordements d'entiers, ce qui est carrément mieux vu qu'on avais déjà -Wstack-protector et -fstack-protector (+ des choses dans le noyau, dans la glibc, et le bit NX dans les processeurs récents) pour protéger la pile, et que les débordements d'entiers sont vraiment un type de bug fort à la mode dans les problèmes de sécurité depuis quelques temps :
« -fstrict-overflow tells the compiler that it may assume that the program follows the strict signed overflow semantics permitted for the language: for C and C++ this means that the compiler may assume that signed overflow does not occur. » [http://gcc.gnu.org/gcc-4.2/changes.html].
« Enfin powertop ne te sert à rien (sauf si tu veux regarder quelles appli consoment trop en vue de ne pas les utiliser sur un portable). Powertop n'est utile qu'avec les C-state. »
En fait, ça ne servira pas (ou peu) à améliorer la consommation d'énergie sur son desktop actuel. *MAIS* :
Repérer dès à présent les applications gourmandes dans son environnement logiciel favoris, les stracer, et envoyer des rapports de bugs permettra à termes d'améliorer la consommation d'énergie pour tout ceux qui utilisent ces logiciels sur un portable (y compris l'auteur du journal, s'il envisage ultérieurement d'utiliser un portable).
Donc non, on ne peut pas dire que ça ne sert à rien, en tout cas si on est prét à faire le (petit) travail de finition après avoir lancé powertop : rapporter les bugs. Au fait, sur ce point, si vous avez un doute, le canal IRC #powertop sur irc.oftc.net est très amical et Arjan (ou d'autres) saura vous aider à faire un bon bug report voir à patcher.
* « Après le patch :
interrupt : uhci_hcd:usb4, eth0, i915@pci:0000:00:02.0
cause en moyenne 50 réveils par seconde, l'autre ligne a disparu. »
As tu essayé en désactivant la 3D (fut-ce provisoirement, simplement pour vérifier la cause du problème) ? Pour cela il suffit de mettre « Option "NoDRI" » dans la section Device correspondant à la carte graphique (bon, et du coup, désactiver temporairement ton compiz, aussi).
Il y a un bug connu, qui affecte les drivers i915, ati, radeon et fglrx et qui cause une interruption par rafraichissement si le DRI est activé (donc si ton affichage est à 50Hz, ça fait 50 interuptions/seconde), et ce même lorsqu'on n'est pas en train de faire du rendu 3D (autrement dit : il suffit d'avoir le DRI actif pour que le bug se manifeste). Intel travaille sur le problème pour son chipset (je crois que c'est déjà patché dans xorg & le kernel de développement).
Aussi, sur la même IRQ : passe ton wifi en mode « économie d'énergie » :
iwpriv eth0 set_power 5
(+ si tu peut régler ton AP, réduire la fréquence d'envoi des beacons à 1 par seconde, par exemple).
Concernant le reste de tes "Top causes for wakeups:" :
* "interrupt : HDA Intel ", "interrupt : libata", "modprobe : usb_hcd_poll_rh_status" : ceux là sont très probablement causés par HAL (re-lance PowerTOP après avoir tué hald, pour vérifier).
* "(59.0) firefox-bin" : connu, bug reporté, un patch existe
* "Enable the CONFIG_SND_AC97_POWER_SAVE kernel configuration option" : bin oui, juste fait-le ;)
* "( 9.8) qjackctl : schedule_timeout " : là on a visiblement un beau bug. Ce programme est-il résident pendant longtemps en mémoire ? ta config de Jack n'est-elle pas trop tordue ? Ça mérite inspection (strace et bug report).
Cela dit : "C3 1.8ms (74.0%) 1.8ms" : ce n'est déjà pas trop mal, on a vu pire (mais vu les remarques plus haut, il y a quand même de la marge pour améliorer tout ça :).
* « Pas d'estimations ACPI de la consommation électrique disponible »
Soit tu utilise un ordinateur dont l'APCI ne fournit pas cette information (typiquement, un ordinateur non portable), soit ton portable est branché sur le secteur (dans ce cas, débranche l'alim et relance powertop lorsque tu es sur batterie).
* « Je trouve aussi le comportement de la première ligne très surprenant »
S'il n'est pas en train de lire de la musique, il y a clairement un bug dans xmms (ou un des modules d'extension de xmms que tu utilise). Là ça ressemble à un select() avec un timeout trop court. Peut tu faire un strace -p $(pidof xmms) stp ?
Il y a aussi une astuce pour contourner ce problème sur known.php :
cd /sys/devices/system/cpu/cpu0/cpufreq
cat ondemand/sampling_rate_max > ondemand/sampling_rate
(à faire pour chaque CPU).
Ces quatre là m'évoquent le problème (connu) d'hald qui polle les lecteurs de cdroms et autres périphériques de stockage de masse USB à intervalles réguliers. Essaie de tuer hald pour confirmer. Vérifie aussi que tu a bien CONFIG_USB_SUSPEND dans le noyau et que tu ne fait pas tourner pcscd.
Ça n'est pas normal. Même le curseur clignotant ne doit pas produire autant d'interuptions. Aurais tu quelque chose qui défile dans un terminal (un top, un tail, etc. ?).
Connu aussi, si je me souvient bien le problème vient d'une/des extensions/plugins. Essaie de désactiver temporairement le support des plugins python/perl/tcl, pour vérifier qu'ils sont bien les coupables.
* 5,0% ( 36,8) Xorg : do_setitimer (it_real_fn)
Peut être n'importe quoi (une autre application, un fond d'écran animé, ...). C'est une limitation : pour le moment PowerTOP ne permet pas de distinguer le travail que Xorg fait de son propre chef et ce qu'il fait à la demande d'un autre logiciel.
[^] # Re: Mwais...
Posté par herodiade . En réponse à la dépêche GNU Affero General Public License : la GPL des applications web. Évalué à -2.
Mais elle n'est pas la GPLv3. L'histoire du « loophole » ne s'applique pas ici.
> et toutes les critiques contre la FSF
Tu a raison, débarrassons nous de cet infâme esprit critique. Sachons louer nos maitres sans trop réfléchir. Si c'est du Stallman, ça ne peut qu'être bon, ne cherchons pas plus loin.
> normal, le logiciel libre est un sujet politique
Le problème est de tenter de forcer les développeurs, ceux qui font le travail en somme, à suivre leur conception évolutive de ce que doit être un licence. Stallman est un control freak, un petit dictateur : il a su le montrer à d'autres occasions encore.
[^] # Re: Mwais...
Posté par herodiade . En réponse à la dépêche GNU Affero General Public License : la GPL des applications web. Évalué à 3.
« Notwithstanding any other provision of this License, you have permission to link any covered work with a work licensed under version 3 (or any later version published by the Free Software Foundation) of the GNU General Public License, and to convey the resulting combination. »
Ils auraient pu donner le droit de « linker » le logiciel avec du code sous « GPLv2 or any later version » ; le fait de spécifier le plancher à la v3 me semble une façon franchement mesquine de pousser leur agenda politique en faveur de la GPLv3, de forcer la main (exactement à la façon de http://lwn.net/Articles/176582/ ).
[^] # Re: traduction
Posté par herodiade . En réponse au journal Le choix d'un maitre n'est pas la liberté. Évalué à 2.
Concrètement, le problème se posera très probablement lorsqu'un mainteneur d'un logiciel acceptera un patch ajoutant du code « GPLv3 ou plus » (dans ce cas, l'ensemble du logiciel devient « GPLv3 ou plus »), ou lorsqu'un autre logiciel, sous v3, intègrera ton code dans son logiciel sous GPLv3 (ce code sera alors considéré « v3 », et tu ne pourra récupérer ses modifications qu'à condition de migrer ton projet en v3).
Des conflits potentiels de ce type se dessinent aujourd'hui. Par exemple : je lis régulièrement la mailing-list de busybox. L'initiateur de ce projet, Bruce Perens, avait choisi une licence "v2 ou plus", mais a quitté le projet depuis plus de 5 ans (et en pratique, on ne retrouve quasiment plus rien de son code initial dans le code actuel). Les développeurs actuels n'aiment pas du tout la v3 et ont voulu indiquer que l'ensemble du projet serait désormais "v2 only". C'est ce moment qu'a choisi Perens pour revenir sur les mailing-lists, non pas pour aider avec le code, mais pour indiquer qu'il s'opposait à cette décision. Il a d'abord tenté de convaincre les développeurs que leur décision était illégale, a échoué, et a finalement annoncé qu'il forkerait le busybox sous v3. Beaucoup de conflits, de développeurs actifs dégoutés ou ulcérés, certains ont abandonné le projet parce que la pression _politique_ de la FSF et de Perens leur tapait sur le système ...
Même pression politique ici : http://lwn.net/Articles/176582/ . La FSF interdit désormais les projets "v2 only" sur Savannah. Pression politique (au sens anglais « politic agenda ») sur les devs kernel et Linus en particulier (voir l'exemple récent dans le lien ci-dessous, http://kerneltrap.org/node/8382 ) où l'on tente (mais de quel droit ?), à répétition, de convaincre Linus de passer en v3 en arguant qu'il « n'a pas compris » (ce qui est gonflé). Ce forcing « politique » montre que la FSF, plutôt que de chercher le consensus pour la nouvelle GPL, ou de refléter et considérer les remarques des développeurs, les premiers concernés, tente de faire passer ses décisions et ses choix de force. La prudence s'impose, donc.
[^] # Re: traduction
Posté par herodiade . En réponse au journal Le choix d'un maitre n'est pas la liberté. Évalué à 4.
Ah, parce que c'est la seule alternative ? Ou c'est la vieille technique de rhétorique « si tu ne soutient pas tout les excès de notre leader jusqu'au bout, si tu ne t'engage pas aveuglément tu es contre lui » ?
On peut pourtant choisir la GPLv2 (ou une autre licence libre) sans signer un chèque en blanc à la FSF. Je n'aime pas plus le proprio que toi.
> On peut avoir le droit de penser que la FSF en entier vont retourner leurs vestes, mais je n'y crois pas
On peut aussi penser qu'ils pourraient, peut-être, peu à peu, s'engoncer dans une dérive dictatoriale, être de plus en plus politiques et de plus en plus déconnecté des problèmes concrets des développeurs du libre, ...
Je ne dit pas qu'ils en sont là actuellement, mais je crois que le risque existe. La GPLv2 définissait des règles de liberté qui concernaient le logiciel (comme dans Free Software Fundation). La GPLv3 ajoute notamment des règles aux fabriquant de hardware leur disant comment utiliser le code : ils ont étendu le domaine d'application de leur concept de « liberté » au matériel. Aussi religieusement stallmanien soit-tu, il serait naïf de penser que tu pourrai le suivre dans toute les choix possibles « d'imposer la liberté » s'il le faisait vraiment jusqu'au bout de sa conception de la liberté (la liberté s'arrète, toussa + la fin, les moyens, toussa).
Peut-être espère-tu, comme moi, qu'ils ne dépasseront pas les limites (qui les feraient basculer dans une attitude dictatoriale), peut même « croit » tu qu'il ne le dépasseront pas cette limite, mais penser qu'il ne faille absolument pas se prémunir contre un débordement relève du domaine de la religion.
Rob Landley raconte qu'il avait, un jour, prêté sa voiture à Stallman, et que ce dernier la garait dans une grande ville US sans la fermer à clef, par conviction idéologique...
[^] # Re: traduction
Posté par herodiade . En réponse au journal Le choix d'un maitre n'est pas la liberté. Évalué à 5.
Licencier un soft en "GPLvX et plus" est très imprudent, puisqu'en cas de délire de RMS (ou son successeur à la tête de la FSF, ou de délire de la FSF complète), ton logiciel sera sous une licence que tu n'a pas choisi.
Même chose dans le cas où la FSF ajoute des restrictions qui ne correspondent pas à ta vision de la liberté. Ce qui est en passe d'arriver à beaucoup de gens, avec la GPLv3. Même si, par chance, tu approuve les nouvelles restrictions apportées de la GPLv3, qui te dit que tu ne fera pas partie des cocus pour la GPLv4 ?
"GPLvX et plus", c'est signer un chèque en blanc. À des gens que tu ne connais pas (RMS ne sera pas éternellement là). Choisir le "et plus", c'est un engagement religieux, une croyance : le choix d'une licence doit être à l'inverse fait avec prudence, vigilance, et en étant certain de savoir et comprendre ce que l'on choisit.
# Les réticences de Linus
Posté par herodiade . En réponse au journal Le choix d'un maitre n'est pas la liberté. Évalué à 3.
Elles sont seulement un peu moins intenses que pour le premier brouillon de la nouvelle GPL.
Je vous recommande chaudement de lire ce thread, qui date des deux derniers jours (13 et 14 juin 2007) en entier :
http://kerneltrap.org/node/8382
Linus y donne expose très clairement son point de vue, et rejette efficacement le terme de "misunderstandings" qu'utilisait réthoriquement Esben Morgen pour balayer les critiques, au lieu de les prendre en compte.
[^] # Re: traduction
Posté par herodiade . En réponse au journal Le choix d'un maitre n'est pas la liberté. Évalué à 3.
Elle risque d'avoir du mal à bloquer ça, la GPLv3, dans la mesure ou le kernel restera plus que probablement sous GPLv2, ainsi que la glibc (et la ulibc) et que busybox. Bref, tout les softs qui concernent le monde de l'embarqué.
C'est ce qu'on obtient lorsqu'on pousse son agenda politique sans s'intéresser au point de vue de ceux qui font le boulot, les développeurs.
[^] # Re: ça fait rêver
Posté par herodiade . En réponse au journal Asus EEE. Évalué à 2.
Tu a une source à ce sujet ?
Car le journal indique « processeur basse consommation (intel mobile A100 ou A110, soit 600 ou 800MHz) » (ainsi que cette source : [http://www.linuxdevices.com/news/NS9292516116.html])
Ce serait vraiment dommage que l'ordinateur n'utilise pas un processeur mobile : cela signifierai qu'on ne pourrai pas faire grand chose pour améliorer l'autonomie, un peut faible, de cet ordinateur (tandis qu'avec un processeur mobile, si le « 3h » indique l'autonomie sous Windows XP, alors on peut espérer 4 ou 5h avec un Linux bien ajusté).
# Flash lors du boot : ça sera corrigé (plus tard)
Posté par herodiade . En réponse au journal Xorg et Mac OS X. Évalué à 3.
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/(...)
Bref, le gros travail actuellement mené par les développeurs dri/xorg/kernel pour intégrer de nombreux composants (comme le modsetting, un nouveau gestionnaire de mémoire nommé TTM, la refonte de fbdev, ...) dans le noyau Linux permettra de corriger ce problème.
C'est un gros chantier cependant. Pour le moment il y a eu beaucoup de discussions entre les développeurs de drivers graphique, et seul le plan d'action (et une ébauche de code) a été soumis pour revue sur la LKML, même pas pour intégration dans -mm, (et Keith Packard ou Dave Airlie ou Eric Arnolt, je ne sait plus, considère qu'il faut tout ré-écrire).
[^] # Re: Demande d'info
Posté par herodiade . En réponse à la dépêche La version 7 de Fedora est sortie !. Évalué à 2.
Bon apparemment (si j'ai bien deviné comment les bouts de .config s'assemblent ;) ils y sont tous à l'exception de USB_SUSPEND.
Remarque : je vois aussi cet autre répertoire dans le CVS :
http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/F-7/configs(...)
(pour lequel USB_SUSPEND est activé). Ce ne serait pas plutôt ce dernier qui contiendrai les configs pour la Fedora 7 ?
[^] # Re: macbook
Posté par herodiade . En réponse au journal Utilisation de PowerTop. Évalué à 2.
Oui, le rétro-éclairage (backlight) et la luminosité (brightness, ps: je ne suis pas sûr que ce soit les traductions standards pour ces deux mots) sont parmi les plus gros consommateurs d'énergie sur les portables. Pavel Macek (développeur noyau chez SuSE) dit même « le plus gros consommateur » dans son étude [http://atrey.karlin.mff.cuni.cz/~pavel/swsusp/8hours.pdf].
Cela étant, ces deux aspects (backlight et brightness) sont censés être connus et automatiquement et adéquatement ajustés par le daemon acpi (et ses scripts de configuration /etc/acpi/*) selon que l'ordinateur est branché sur secteur ou pas, sur les distributions modernes. Et on est censé pouvoir lui faire confiance pour gérer ça au mieux. Si acpid ne fait pas ce travail de façon optimale sur ton ordinateur, ça mérite un rapport de bug.
Mais il est pertinent de rappeler que l'écran joue pour beaucoup sur la consommation électrique : ainsi ceux pour qui l'autonomie est un critère prioritaire devraient privilégier les ordinateurs avec de petits écrans (un exemple : Keith Packard obtient 7h d'autonomie sur son Panasonic R4 avec un écran 10 pouces).
# Demande d'info
Posté par herodiade . En réponse à la dépêche La version 7 de Fedora est sortie !. Évalué à 3.
CONFIG_HIGH_RES_TIMERS
CONFIG_TIMER_STATS
CONFIG_HPET
CONFIG_CPU_FREQ_GOV_ONDEMAND
CONFIG_USB_SUSPEND
CONFIG_SND_AC97_POWER_SAVE
CONFIG_ACPI_BATTERY
Pour le savoir il suffit normallement (si CONFIG_IKCONFIG_PROC est activé) de faire : zgrep $option /proc/config.gz (par ex. zgrep CONFIG_HPET /proc/config.gz).
Ou mieux : existe-t-il une URL pour télécharger le .config de Fedora ?
Merci d'avance.
[^] # Re: Précision
Posté par herodiade . En réponse au journal Firefox implémente la balise <video>. Évalué à 9.
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-Feb(...)
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-Mar(...)
Je n'ai pas noté les posts les plus croustillants sur le moment, mais en farfouillant 5mn sur la m-l on en trouve vites quelques uns :
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-Mar(...)
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-Mar(...)
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-Mar(...)
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-Mar(...)
etc.
Mais on y apprend tout de même que :
« It's not unprecedented in W3C; the SVG 1.2 WD requires support for Ogg Vorbis » :
http://www.w3.org/TR/2004/WD-SVG12-20041027/media.html
# Précision
Posté par herodiade . En réponse au journal Firefox implémente la balise <video>. Évalué à 10.
L'idée (au départ, des développeurs d'Opéra) était d'avoir un remplaçant standard et libre pour l'utilisation « diffusion de vidéo » de Flash (assez à la mode en ce moment : voir youtube, dailymotion ou encore google video).
Mais, et ce fut très intéressant, les développeurs de Safari (le navigateur d'Apple) ont fait le forcing pour que le standard ne suggère pas (« should ») les formats/containeurs/codecs OGG / Vorbis / Theora. Évidement, beaucoup de participants à la m-l leur ont demandé plus d'explication (à ce point des développeurs de Itunes/Ipod sont arrivés ...) : la raison indiqué était ... le risque des brevets !
En effet les avocats d'Apple ont estimé que supporter ces formats libres était finalement plus risqué que de payer une bonne licence au MPEG-LA : il est possible qu'un brevet « dormant » attende, tapi dans l'ombre, qu'une société suffisamment riche diffuse des produits implémentant leur propriété intellectuelle pour attaquer. Et ces procès, perdus, coutent très cher. Un employé de Nokia participant à la m-l à confirmé : pour cette raison, Nokia ne souhaite pas déployer du ogg/vorbis/theora. On comprends à posterio l'absence de ces codecs dans les PDA Nokia N700 et N800, pourtant sous Linux.
Bref, ça me déprime : l'expansion des formats libres et ouverts et elle aussi minée à cause des brevets ! Et on n'est pas prêts de voir ce support optionnel « should » implémenté dans Safari ou Internet Explorer.
[^] # Re: Autres compléments d'informations
Posté par herodiade . En réponse à la dépêche PowerTOP : Un outil pour réduire la consommation d'énergie sous GNU/Linux. Évalué à 2.
Certes, mais pour jouer, se faire un petit 2.6.21 (voir un 2.6.22-rc3) temporaire ne prends pas bien longtemps (et on peut encore plus rapidement revenir en arrière). Bénéfice secondaire, quand ta distrib passera au 2.6.22, le support de ton matériel par le noyau sera déjà testé (et les éventuels bugs, peut-être reportés) ;)
Sinon, la Fedora 7 vient de sortir, avec un noyau 2.6.21 (je ne sait pas si elle a CONFIG_TIMER_STATS activé par défaut) ...
[^] # Re: OCR & video
Posté par herodiade . En réponse à la dépêche État des lieux de la reconnaissance de caractères libre (OCR). Évalué à 2.
Il y a un bout de code pour ça dans les sources de mplayer (ça converti la vidéo en une suite d'images statiques, et passe gocr dessus).
[^] # Re: macbook
Posté par herodiade . En réponse au journal Utilisation de PowerTop. Évalué à 2.
Ah oui, 3515 wps, c'est dément !
On a un nouvel argument libriste : « ndiswrapper saimal, ça détruit la planète » ;).
( 10,0) cpufreq-set : cpufreq_governor_dbs (delayed_work_timer_fn)
Un logiciel userland qui sélectionne le « governor » CPU et qui bouffe lui-même plein d'énergie ? Tu peut le désinstaller je pense.
D'autant plus qu'Arjan est formel sur ce point : il n'y a aucune ambiguité, le governor le plus adapté pour les environnements Intel (donc y compris les macbooks), c'est « ondemand ». Les autres sont moins efficaces. Pour l'activer, fait ceci pour chaque CPU :
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
pour le reste c'est du noyau.
Oui mais c'est bien souvent le userland qui conduit le noyau à recevoir des interruptions USB et ATA (note : outre les réveils de la CPU, le fait de maintenir une activité sur ces bus les empêchent d'activer leurs propres modes d'économie d'énergie indépendants, tels que USB_SUSPEND, dont ils sont tout deux dotés).
Comme je disait plus haut, dans ton cas (usb_hcd_poll_rh_status et libata), je soupçonne "hald". Est-ce que ces lignes disparaissent si tu killall hald ?
De plus, toujours pour réduire les accès disques ou leur impact, tu peut activer le mode laptop si ce n'est pas déjà fait ( echo 5 > /proc/sys/vm/laptop_mode) et monter les partitions pour lesquelles tu ne t'intéresse pas au dates de dernier accès aux fichiers en "noatime". Bon, pour l'USB, il y a aussi un problème connu affectant les macbooks, qui fait que la gestion du clavier est très gourmande (mais un patch existe, peut-être même déjà intégré dans 2.6.22-rc3).
Combien de réveils par secondes et de Watt consommés si tu décharge le module wifi et applique ces astuces ? (ça m'intéresse beaucoup parce que j'envisage de me procurer un macbook aussi :).
[^] # Re: La quantité c'est bon ! Par exemple...
Posté par herodiade . En réponse à la dépêche 500 000 articles sur la Wikipédia francophone !. Évalué à 3.
On a un peu moins de problème avec les articles sur le cinéma, par exemple (sujets assez abordables, et de nombreux participants au projet ciné).
As-tu pensé à signaler le vote AdQ aux projets Informatique et Mathématique ? je suppose que les experts sont là... En tout cas bravo pour le joli travail sur les algos !
[^] # Re: La quantité c'est bon ! Par exemple...
Posté par herodiade . En réponse à la dépêche 500 000 articles sur la Wikipédia francophone !. Évalué à 9.
L'article est très agréable à lire, mais si tu cherche des idées d'améliorations, ... il y a toujours moyen ;)
J'ai seulement parcouru l'article en diagonale, mais un premier point qui m'a frappé : il faudrait ajouter des références pour les affirmations non triviales ou biographiques. Les évaluations lors des votes AdQ sont de plus en plus exigeantes sur ce point, et là, sans *aucune* référence, il aurait du mal à passer.
C'est peut-être un peu plus difficile pour un article d'informatique ou scientifique que pour un article, par exemple, d'histoire, d'économie ou une biographie, mais il est toujours possible de se baser sur les normes et les spécifications (au moins, ce sont des références _solides_ s'il en est !).
Ou bien par exemple :
« Jeremie Miller a commencé le projet en 1998 » [ à sourcer ].
Le bénéfice pour le rédacteur n'est pas à négliger : en cherchant à « sourcer » toutes ses affirmations, on s'apperçois toujours qu'on avait une vision trop approximative de certains aspects de son sujet. Et on devient nettement plus pointu ainsi.
Une autre limite, c'est peut-être un manque détails concernant la description technique du standard (synthèse des RFC concernées, etc.).
Un exemple d'article « informatique » (enfin, plus ou moins) promu AdQ il n'y a pas si longtemps :
http://fr.wikipedia.org/wiki/Algorithme_de_colonies_de_fourm(...)
Pour ce dernier, on notera la relative abondance des notes de base de page (les « sources ») et en page de discussion, on relevera aussi l'excellente idée des auteurs de l'article : ils ont demandé à un spécialiste de leur sujet (en fait _le_ spécialiste) de le relire et le valider. Résultat, on a probablement le meilleur et le plus solide écrit en langue française sur l'algo des fourmis : le jeu en valait la chandelle, non ?
[^] # Re: Autres compléments d'informations
Posté par herodiade . En réponse à la dépêche PowerTOP : Un outil pour réduire la consommation d'énergie sous GNU/Linux. Évalué à 4.
http://www.free-it.de/archiv/talks_2005/paper-11017/paper-11(...)
Le document date de deux ans, mais il est toujours très intéressant, et son auteur, Dominik Brodowski (qui est au passage développeur noyau de cpufreq) a vu très juste : il a parfaitement anticipé les évolutions du noyau dont on peut aujourd'hui profiter et les problématiques actuelles !
# Autres compléments d'informations
Posté par herodiade . En réponse à la dépêche PowerTOP : Un outil pour réduire la consommation d'énergie sous GNU/Linux. Évalué à 10.
Quelques compléments d'infos donc :
* Avant que je journal soit « niouzifié », j'ai écrit d'autres compléments d'informations ici : http://linuxfr.org/comments/831869.html#831869
* Keith Packard, développeur d'Xorg, témoigne : « Avec PowerTOP, j'ai réussi à améliorer l'autonomie de mon portable Panasonic R4 de 4 heures à presque 7 heures » [http://www.linuxpowertop.org/success.php] Bref, attendez vous à des progrès sensibles !
* Le panel des suggestions proposées par l'outil s'étend maintenant à l'espace utilisateur. Il est désormais capable d'appliquer certaines des propositions lui-même, à la volée.
* L'affichage utilise désormais ncurses, et c'est plus confortable.
* PowerTOP est intégré dans les versions de développement de la plupart des distributions maintenant.
* Il est désormais traduit en français, et doté d'une page de manuel.
* Les développeurs de Gaim Pidgin ont déjà sorti une nouvelle version, 2.0.1 corrigeant les problèmes levés par PowerTOP. Bravo !
* L'astuce « Option "NoDRI" » indiquée pour le problème des drivers i915 fonctionne aussi pour les drivers radeon et fglrx
* Vous verrez peut-être "i8042" assez haut dans la liste des causes de réveils. Il s'agit du pilote clavier. Le problème est connu.
* Vous verrez peut-être aussi des choses comme "[interrupt] : ide1" (ou libata ou ide0 " alors que vous ne pensez pas utiliser les disques. C'est probablement hald qui les surveille (re-testez après avoir tué hald).
* Si l'une des applications les plus gourmandes sur votre système affiche des select() ou poll() en boucle lorsque vous faites "strace -tt -p $(pidof monapplication)", ce n'est probablement pas normal, les développeurs ont probablement choisi des timeout trop courts.
* Beaucoup de gens se demandent pourquoi ils ne voient pas les C-states C3 et C4 sur leur machine. 1) essayez après avoir débranché le cable d'alim (sur batterie, quoi). 2) tout les processeurs/BIOS ne supportent pas ces C-states (attention à la confusion : /proc/acpi/processor/*/power indique "max_cstate: C8", mais c'est seulement le nombre de C-states que supporte le noyau Linux, pas le nombre physiquement implémenté dans le matériel).
* On vois beaucoup de confusion au sujet de HPET sur la m-l de PowerTOP. Je vais donc essayer de préciser. HPET est une source d'évenements temporels (une « event source for timers ticks », pas une « clocksource ») alternative au traditionnel mais ancien PIT. PIT a une grosse limitation : il ne peut dormir plus de 26ms, et génère donc en conséquence une trentaine d'interruptions par secondes (symptôme : PowerTOP affiche quelque chose du genre : « ( 27.3) [interrupt] : extra timer interrupt »). HPET est théoriquement supporté par le matériel récent (mais pas toujours), mais il faut qu'il soit activé dans le noyau, et surtout, que le BIOS ne le masque pas (ce qui est très courant : les mauvaises langues disent que les fabriquants de portables le masquent parce que, n'étant pas supporté par WinXP, cela afficherai un point d'exclamation jaune dans le gestionnaire de périphérique de Windows). Sur le site de PowerTOP, on trouve une solution à ce problème : un patch noyau qui force l'activation d'HPET, nonobstant les indications du BIOS. Bref, il ne suffit pas d'avoir HPET dans le noyau pour qu'il soit actif sur votre système : pour le vérifier, grep "Clock Event Device" /proc/timer_list .
Un petite déception : très peut d'utilisateurs témoignent des problèmes qu'ils rencontrent (pourtant Arjan est très newbie friendly. Franchement) et n'indiquent pas leurs découvertes d'applications ou modules noyau les plus gourmands (condition sine qua non pour que le problème soit corrigé). À moins que les utilisateurs de PowerTOP soient tout simplement très peu nombreux.
Visiblement, beaucoup semblent penser que « quelqu'un l'a déjà fait, un autre développeur du logiciel gourmand foo doit probablement avoir utilisé powertop » (remarque que j'ai plusieurs fois reçu lorsque j'ai indiqué des problèmes découverts par PowerTOP à des développeurs).
En réalité, peu de projets sont avertis de ces problèmes, et on découvre chaque jour des applications pourtant extrêmement utilisées dont personne n'a reporté le comportement inadéquat. La possibilité d'identifier ces comportements facilement est très récente, et le champs très vaste, c'est une véritable forêt vierge. En conséquence il reste énormément d'environnements logiciels à défricher, énormément de low hanging fruits à ramasser, c'est très facile, alors venez vous amusez ! :)
# strict-overflow
Posté par herodiade . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 2.
En fait les options -(f|W)strict-overflow font des vérifications sur les débordements d'entiers, ce qui est carrément mieux vu qu'on avais déjà -Wstack-protector et -fstack-protector (+ des choses dans le noyau, dans la glibc, et le bit NX dans les processeurs récents) pour protéger la pile, et que les débordements d'entiers sont vraiment un type de bug fort à la mode dans les problèmes de sécurité depuis quelques temps :
« -fstrict-overflow tells the compiler that it may assume that the program follows the strict signed overflow semantics permitted for the language: for C and C++ this means that the compiler may assume that signed overflow does not occur. » [http://gcc.gnu.org/gcc-4.2/changes.html].
[^] # Re: ...
Posté par herodiade . En réponse au journal Utilisation de PowerTop. Évalué à 3.
En fait, ça ne servira pas (ou peu) à améliorer la consommation d'énergie sur son desktop actuel. *MAIS* :
Repérer dès à présent les applications gourmandes dans son environnement logiciel favoris, les stracer, et envoyer des rapports de bugs permettra à termes d'améliorer la consommation d'énergie pour tout ceux qui utilisent ces logiciels sur un portable (y compris l'auteur du journal, s'il envisage ultérieurement d'utiliser un portable).
Donc non, on ne peut pas dire que ça ne sert à rien, en tout cas si on est prét à faire le (petit) travail de finition après avoir lancé powertop : rapporter les bugs. Au fait, sur ce point, si vous avez un doute, le canal IRC #powertop sur irc.oftc.net est très amical et Arjan (ou d'autres) saura vous aider à faire un bon bug report voir à patcher.
[^] # Re: macbook
Posté par herodiade . En réponse au journal Utilisation de PowerTop. Évalué à 4.
interrupt : uhci_hcd:usb4, eth0, i915@pci:0000:00:02.0
cause en moyenne 50 réveils par seconde, l'autre ligne a disparu. »
As tu essayé en désactivant la 3D (fut-ce provisoirement, simplement pour vérifier la cause du problème) ? Pour cela il suffit de mettre « Option "NoDRI" » dans la section Device correspondant à la carte graphique (bon, et du coup, désactiver temporairement ton compiz, aussi).
Il y a un bug connu, qui affecte les drivers i915, ati, radeon et fglrx et qui cause une interruption par rafraichissement si le DRI est activé (donc si ton affichage est à 50Hz, ça fait 50 interuptions/seconde), et ce même lorsqu'on n'est pas en train de faire du rendu 3D (autrement dit : il suffit d'avoir le DRI actif pour que le bug se manifeste). Intel travaille sur le problème pour son chipset (je crois que c'est déjà patché dans xorg & le kernel de développement).
Aussi, sur la même IRQ : passe ton wifi en mode « économie d'énergie » :
iwpriv eth0 set_power 5
(+ si tu peut régler ton AP, réduire la fréquence d'envoi des beacons à 1 par seconde, par exemple).
Concernant le reste de tes "Top causes for wakeups:" :
* "interrupt : HDA Intel ", "interrupt : libata", "modprobe : usb_hcd_poll_rh_status" : ceux là sont très probablement causés par HAL (re-lance PowerTOP après avoir tué hald, pour vérifier).
* "(59.0) firefox-bin" : connu, bug reporté, un patch existe
* "Enable the CONFIG_SND_AC97_POWER_SAVE kernel configuration option" : bin oui, juste fait-le ;)
* "( 9.8) qjackctl : schedule_timeout " : là on a visiblement un beau bug. Ce programme est-il résident pendant longtemps en mémoire ? ta config de Jack n'est-elle pas trop tordue ? Ça mérite inspection (strace et bug report).
Cela dit : "C3 1.8ms (74.0%) 1.8ms" : ce n'est déjà pas trop mal, on a vu pire (mais vu les remarques plus haut, il y a quand même de la marge pour améliorer tout ça :).
# Quelques explications
Posté par herodiade . En réponse au journal Utilisation de PowerTop. Évalué à 1.
Soit tu utilise un ordinateur dont l'APCI ne fournit pas cette information (typiquement, un ordinateur non portable), soit ton portable est branché sur le secteur (dans ce cas, débranche l'alim et relance powertop lorsque tu es sur batterie).
* « Je trouve aussi le comportement de la première ligne très surprenant »
Bug normallement corrigé dans le svn.
* 29,1% (215,4) firefox-bin : schedule_timeout (process_timeout)
Il y a un patch pour améliorer le comportement de firefox sur http://www.linuxpowertop.org/known.php . Quand au flash ...
* 27,0% (200,2) xmms : schedule_timeout (process_timeout)
S'il n'est pas en train de lire de la musique, il y a clairement un bug dans xmms (ou un des modules d'extension de xmms que tu utilise). Là ça ressemble à un select() avec un timeout trop court. Peut tu faire un strace -p $(pidof xmms) stp ?
* 3,5% (100,0) S06cpuspeed : queue_delayed_work_on (delayed_work_timer_fn)
Il y a aussi une astuce pour contourner ce problème sur known.php :
cd /sys/devices/system/cpu/cpu0/cpufreq
cat ondemand/sampling_rate_max > ondemand/sampling_rate
(à faire pour chaque CPU).
*
6,9% ( 50,8) : uhci_hcd:usb3, ehci_hcd:usb7
1,0% ( 7,6) : uhci_hcd:usb4, libata, libata, eth0
0,5% ( 3,6) : ide0, uhci_hcd:usb2
0,5% ( 4,0) <kernel module> : usb_hcd_poll_rh_status (rh_timer_func)
Ces quatre là m'évoquent le problème (connu) d'hald qui polle les lecteurs de cdroms et autres périphériques de stockage de masse USB à intervalles réguliers. Essaie de tuer hald pour confirmer. Vérifie aussi que tu a bien CONFIG_USB_SUSPEND dans le noyau et que tu ne fait pas tourner pcscd.
* 1,9% ( 14,2) mixer_applet2 : schedule_timeout (process_timeout)
Problème connu (cf. known.php)
* 1,3% ( 10,0) mono : schedule_timeout (process_timeout)
Beagled ?
* 1,7% ( 12,8) gnome-terminal : schedule_timeout (process_timeout)
Ça n'est pas normal. Même le curseur clignotant ne doit pas produire autant d'interuptions. Aurais tu quelque chose qui défile dans un terminal (un top, un tail, etc. ?).
* 2,9% ( 21,2) xchat : schedule_timeout (process_timeout)
Connu aussi, si je me souvient bien le problème vient d'une/des extensions/plugins. Essaie de désactiver temporairement le support des plugins python/perl/tcl, pour vérifier qu'ils sont bien les coupables.
* 5,0% ( 36,8) Xorg : do_setitimer (it_real_fn)
Peut être n'importe quoi (une autre application, un fond d'écran animé, ...). C'est une limitation : pour le moment PowerTOP ne permet pas de distinguer le travail que Xorg fait de son propre chef et ce qu'il fait à la demande d'un autre logiciel.