Tous les PCs consomment éteint : comment tu veux qu'ils réagissent à un simple bouton poussoir pour l'allumage, sinon ? (perso j'ai pas mesuré mais j'ai vu dans des tests que ma 780G intégrée de chez AMD c'est 7/8W éteint)
Bon, peut-être qu'il vérifie que ton bail a pas expiré. Enfin bon, moi je ne trouve pas ça si crade, les baux super-courts avec des changements d'IP fréquents pour moi c'est signe d'un réseau bof-bof (OK, sur les réseaux à gros "turn-over" peut-être pas ...) et ce n'est pas le plus commun.
Ça a été discuté dans les commentaires, et c'est bien un mec d'Intel.
Par contre ça ne l'empêche pas de filer que des arguments fallacieux (pour rester poli).
Je ne suis pas sûr pour OS X, mais il me semble par exemple qu'il ne refait pas de demande au DHCP. Ça va plus vite.
Sous linux, network-manager va refaire un tour complet au DHCP, blah blah, ça prend du temps. Je me rappelle sur mon ancien iBook sous Debian, lors de la sortie de veille où on voit d'abord la console, le wifi se reconnectait en moins d'une seconde. Mais n-m faisait exprès de déco, de reco et de renouveler le bail DHCP ... ce qui prend beaucoup plus de temps.
Bon, après, chez moi, j'ai vachement plus vite une IPv6 qu'une v4, c'est peut-être une autre piste ...
Je dirais que c'est plus facile d'optimiser le temps de démarrage que d'arriver à convaincre tous les constructeurs de matos de faire leur boulot correctement et qu'ils nous filent les specs pour mettre en veille / réveiller leurs périphériques.
C'est dommage mais c'est comme ça. (je pense que si peu de personne demandent du suspend to ram, c'est parce qu'elles n'ont jamais pu le tester correctement. Quand on y a goûté, par contre, ça manque vraiment sur les machines qui ne l'ont pas)
Attention, ne mélange pas le S2RAM avec les modes "basse consommation" des périphériques que tu cites : pendant un S2RAM, le CPU ne tourne pas et ne peut pas analyser les évènements qui lui arrive. Bref, la puce de gestion d'énergie le réveille sur une interruption (genre, appuyer sur un bouton, voire recevoir certaines trames ethernet si ta carte réseau est pas trop con). Quand ton ordi "dort" comme ça, seule la RAM est raffraîchie, tout le reste est éteint.
Pour la plupart des périphériques embarqués, c'est un mode de basse consommation pour le CPU, mais il est toujours un petit peu actif.
Le suspend-to-ram c'est vraiment bien si t'as une bonne machine. Sur un ancien iBook, il tenait la semaine comme ça, donc largement de quoi utiliser cette fonctionnalité comme bon te semble.
Après, en cas de batterie vide, bah, ça fait comme une brusque coupure de courant pour ton OS, quoi ...
Il me semble que les range a-z et A-Z sont déjà "internationalisés" si on utilise une version un peu moderne des regexps. Et les classes alpha sont très biens définies en unicode.
D'après un article en allemand : http://translate.google.com/translate?u=http%3A%2F%2Fwww.net(...)
C'était avec un nouveau driver (quoique j'ai peut-être lu ça dans l'autre article), plus récent, et avec des MàJ qui devraient arriver dans le 2.6.32 ...
Alors, traduction selon moi : on aura peut-être un DRI mis à jour en libre, mais à mon avis on peut toujours aller se la mettre pour avoir des specs ou un driver libre.
Quant aux perfs, c'est pas non plus transcendant de faire tourner Quake 3 (qui a 10 ans, quand même). Pour référence, regardez ce qu'on fait sur iPhone : c'est le même chip ...
ceci dit, pour nvidia, on a également vu les devs passer sur du code libre, pour par exemple les pilotes forcedeth ( d'abord pilote proprio, puis pilote en RE, puis nvidia qui abandonne le pilote proprio pour aider le driver forcedeth directement ).
Ho, que c'est mignon. Ils sortent de la merde en barre, des mecs font bénévolement du reverse-engineering et écrivent un driver libre mieux que ceux de NVidia, au début ils se font ignorer, puis au bout d'un moment NVidia dit "bon ok, on arrête de faire de la merde et on switch sur votre driver". Comment doit-on prendre ce genre d'attitude ? Doit-on dire "ho merci grand NVidia pour ta grande générosité" ? Ou alors essayer de leur gueuler dessus pour leur faire comprendre que ce n'était pas la bonne manière de faire, et qu'ils sont en train de faire pareil avec leurs CGs ?
En fait, c'est juste un problème de pouvoir/domination : il y a ceux qui aiment bien se prendre des coups du moment qu'ils ont leur susucre de temps en temps, et ceux qui n'acceptent pas ce rapport de force.
Un matériel _doit_ être vendu avec ses spécifications. "période".
Les puces que vend ImgTech sont des "bonnes" puces pour l'embarqué : un bon compromis performances / consommation (ça ne vaut rien en performance pure face à un AMD ou NVidia, hein). C'est aussi quasiment les seuls sur ce segment (pour tout dire, je ne leur connait aucun concurrent).
Pour le pilote, je ne pense pas avoir dit qu'ils ne le développaient pas ... au contraire ! Je pense que ImgTech vend un driver source à ceux qui signent des NDA, pour très cher et s'ils vendent beaucoup de puces. Ils ont un gros partenariat (selon moi) avec TI pour vendre leur puce en tant que solution graphique de la plateforme OMAP, c'est pour ça qu'on en retrouve partout (en plus d'Apple avec son iPhone).
Pour le N8x0, c'était un cas spécial : les kits OMAP sont vendus avec tout ou rien (matériellement), et Nokia ne voulait pas de carte graphique : ils n'ont simplement pas eu de driver. La bête n'a jamais été vendue avec dans ses specs "carte graphique 3D". Bon, pour un libriste, ça semble dommage de laisser dormir une telle puce ...
En tous cas, selon moi, les perspectives de libération sont très minces : ImgTech est quasi-seul dans ce segment (si quelqu'un avait des références d'autres constructeurs plus coopératifs, ça m'intéresserait) et vend plein de puce sans que trop de libristes ne l'ait encore fait chier. Bref, comme je l'ai déjà dit avant, la 3D dans l'embarqué est sur un encore plus mauvais chemin que la 3D sur le desktop (en libre, hein).
Oui il l'est toujours, c'est le pilote nv. Sauf que toutes les améliorations depuis se sont faites de manière obfusquées, donc tu as le choix entre un driver clair mais qui ne supporte pas les cartes de moins de 5 ans, ou un driver obfusqué (on peut dire qu'il est "libre", c'est la licence qu'il y a dessus, mais vu qu'on peut rien en faire ... d'ailleurs la FSF a fait quelque chose là-dessus avec la GPLv3 je crois, en disant que le code devait être sous sa forme "originale") qui supporte les nouvelles cartes.
Reste à prier pour que ce jour-là ils préfèrent ouvrir leurs drivers plutot que de laisser sur la paille leurs utilisateurs.
Pour rappel, quand même, le jour où ils ont arrêté de développer le driver libre NVidia (il y a longtemps, hein, c'était encore XFree86, et ça ne gérait que la 2D) ils ont obfusqué le code ... (et demandé aux mainteneurs de laisser leur patch obfusquant le code tel quel ; leurs quelques contributions futures, genre pour ajouter des PCI-id et mettre à jour des petits bouts de code, ce sont ensuite toujours faites par des patchs obfusqués). Ça donne une idée de comment ils traiteront les libristes dans le futur.
Je regarde depuis quelques temps les netbooks et autres tablettes embarquées, mais ce chipset, présent aussi bien sur x86 que sur ARM, m'a fait reculer à chaque fois.
Je parie 10 cacahuètes que ce sera une CC NC quelque chose et qu'il y aura encore un débat infini sur "ouai NC c'est pas libre mais quand même, t'as le droit de le copier gratuitement !".
Quelle que soit la "qualité" de la machine, un vote électronique sera toujours un déni de démocratie !
Je sais qu'on est sur un site de geeks, où certains pourront très bien comprendre ce qui se trame derrière les lignes de codes présentes dans ces machines. Mais avez-vous pensé à tous les autres gens qui doivent vous faire confiance là-dessus ?
De plus, qui vous dit que c'est bien ce code qui est dans la machine devant laquelle vous vous présentez ? Même si on la "charge" devant vous, qu'est-ce qui vous prouve qu'un programme existant / un changement électronique / whatever n'a pas modifié à l'avance son fonctionnement ?
Franchement, ce genre d'initiative ne fait que crédibiliser le vote électronique aux yeux d'un public qui ne comprend même pas les enjeux de base.
En gros, comme les requêtes du style neighbour discovery sont du multicast, elles ne sont pas "trackables" par conntrack. Elles ne sont donc pas prises en compte par ta règle avec --state ...
[^] # Re: Petite question...
Posté par benoar . En réponse au journal TuxRadar : Comparaison de la vitesse de démarrage de Vista, Windows 7, Ubuntu 9.04 et 9.10. Évalué à 3.
[^] # Re: use awk, Luke...
Posté par benoar . En réponse au message nom et taille dans fichier texte. Évalué à 2.
[^] # Re: lsusb donne donc
Posté par benoar . En réponse au message recherche pilote pour lecteur/graveur externe. Évalué à 4.
[^] # Re: Ha.
Posté par benoar . En réponse au journal TuxRadar : Comparaison de la vitesse de démarrage de Vista, Windows 7, Ubuntu 9.04 et 9.10. Évalué à 2.
[^] # Re: A propos de moblin/Poulsbo
Posté par benoar . En réponse à la dépêche Intel ne maintient plus le pilote Linux Poulsbo depuis un an et demi. Évalué à 2.
Par contre ça ne l'empêche pas de filer que des arguments fallacieux (pour rester poli).
[^] # Re: C'est pas faute d'avoir prévenu
Posté par benoar . En réponse à la dépêche Intel ne maintient plus le pilote Linux Poulsbo depuis un an et demi. Évalué à 2.
[^] # Re: Ha.
Posté par benoar . En réponse au journal TuxRadar : Comparaison de la vitesse de démarrage de Vista, Windows 7, Ubuntu 9.04 et 9.10. Évalué à 2.
Sous linux, network-manager va refaire un tour complet au DHCP, blah blah, ça prend du temps. Je me rappelle sur mon ancien iBook sous Debian, lors de la sortie de veille où on voit d'abord la console, le wifi se reconnectait en moins d'une seconde. Mais n-m faisait exprès de déco, de reco et de renouveler le bail DHCP ... ce qui prend beaucoup plus de temps.
Bon, après, chez moi, j'ai vachement plus vite une IPv6 qu'une v4, c'est peut-être une autre piste ...
[^] # Re: Petite question...
Posté par benoar . En réponse au journal TuxRadar : Comparaison de la vitesse de démarrage de Vista, Windows 7, Ubuntu 9.04 et 9.10. Évalué à 4.
[^] # Re: Petite question...
Posté par benoar . En réponse au journal TuxRadar : Comparaison de la vitesse de démarrage de Vista, Windows 7, Ubuntu 9.04 et 9.10. Évalué à 6.
C'est dommage mais c'est comme ça. (je pense que si peu de personne demandent du suspend to ram, c'est parce qu'elles n'ont jamais pu le tester correctement. Quand on y a goûté, par contre, ça manque vraiment sur les machines qui ne l'ont pas)
[^] # Re: Petite question...
Posté par benoar . En réponse au journal TuxRadar : Comparaison de la vitesse de démarrage de Vista, Windows 7, Ubuntu 9.04 et 9.10. Évalué à 2.
Pour la plupart des périphériques embarqués, c'est un mode de basse consommation pour le CPU, mais il est toujours un petit peu actif.
[^] # Re: Petite question...
Posté par benoar . En réponse au journal TuxRadar : Comparaison de la vitesse de démarrage de Vista, Windows 7, Ubuntu 9.04 et 9.10. Évalué à 4.
Après, en cas de batterie vide, bah, ça fait comme une brusque coupure de courant pour ton OS, quoi ...
[^] # Re: Cauchemar de regexps
Posté par benoar . En réponse au journal L'internationalisation des adresses internet. Évalué à 2.
[^] # Re: Ce n'est pas le problème !
Posté par benoar . En réponse au journal Concours de hackage de machines à vote électronique. Évalué à 3.
Pour surveiller un bit, par contre ...
[^] # Re: Un petit lien qui pourrait vous remonter le moral
Posté par benoar . En réponse à la dépêche Intel ne maintient plus le pilote Linux Poulsbo depuis un an et demi. Évalué à 4.
C'était avec un nouveau driver (quoique j'ai peut-être lu ça dans l'autre article), plus récent, et avec des MàJ qui devraient arriver dans le 2.6.32 ...
Alors, traduction selon moi : on aura peut-être un DRI mis à jour en libre, mais à mon avis on peut toujours aller se la mettre pour avoir des specs ou un driver libre.
Quant aux perfs, c'est pas non plus transcendant de faire tourner Quake 3 (qui a 10 ans, quand même). Pour référence, regardez ce qu'on fait sur iPhone : c'est le même chip ...
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par benoar . En réponse à la dépêche Intel ne maintient plus le pilote Linux Poulsbo depuis un an et demi. Évalué à 9.
Ho, que c'est mignon. Ils sortent de la merde en barre, des mecs font bénévolement du reverse-engineering et écrivent un driver libre mieux que ceux de NVidia, au début ils se font ignorer, puis au bout d'un moment NVidia dit "bon ok, on arrête de faire de la merde et on switch sur votre driver". Comment doit-on prendre ce genre d'attitude ? Doit-on dire "ho merci grand NVidia pour ta grande générosité" ? Ou alors essayer de leur gueuler dessus pour leur faire comprendre que ce n'était pas la bonne manière de faire, et qu'ils sont en train de faire pareil avec leurs CGs ?
En fait, c'est juste un problème de pouvoir/domination : il y a ceux qui aiment bien se prendre des coups du moment qu'ils ont leur susucre de temps en temps, et ceux qui n'acceptent pas ce rapport de force.
Un matériel _doit_ être vendu avec ses spécifications. "période".
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par benoar . En réponse à la dépêche Intel ne maintient plus le pilote Linux Poulsbo depuis un an et demi. Évalué à 3.
[^] # Re: C'est pas faute d'avoir prévenu
Posté par benoar . En réponse à la dépêche Intel ne maintient plus le pilote Linux Poulsbo depuis un an et demi. Évalué à 4.
Les puces que vend ImgTech sont des "bonnes" puces pour l'embarqué : un bon compromis performances / consommation (ça ne vaut rien en performance pure face à un AMD ou NVidia, hein). C'est aussi quasiment les seuls sur ce segment (pour tout dire, je ne leur connait aucun concurrent).
Pour le pilote, je ne pense pas avoir dit qu'ils ne le développaient pas ... au contraire ! Je pense que ImgTech vend un driver source à ceux qui signent des NDA, pour très cher et s'ils vendent beaucoup de puces. Ils ont un gros partenariat (selon moi) avec TI pour vendre leur puce en tant que solution graphique de la plateforme OMAP, c'est pour ça qu'on en retrouve partout (en plus d'Apple avec son iPhone).
Pour le N8x0, c'était un cas spécial : les kits OMAP sont vendus avec tout ou rien (matériellement), et Nokia ne voulait pas de carte graphique : ils n'ont simplement pas eu de driver. La bête n'a jamais été vendue avec dans ses specs "carte graphique 3D". Bon, pour un libriste, ça semble dommage de laisser dormir une telle puce ...
En tous cas, selon moi, les perspectives de libération sont très minces : ImgTech est quasi-seul dans ce segment (si quelqu'un avait des références d'autres constructeurs plus coopératifs, ça m'intéresserait) et vend plein de puce sans que trop de libristes ne l'ait encore fait chier. Bref, comme je l'ai déjà dit avant, la 3D dans l'embarqué est sur un encore plus mauvais chemin que la 3D sur le desktop (en libre, hein).
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par benoar . En réponse à la dépêche Intel ne maintient plus le pilote Linux Poulsbo depuis un an et demi. Évalué à 7.
[^] # Re: Chantons les louanges des pilotes propriétaires
Posté par benoar . En réponse à la dépêche Intel ne maintient plus le pilote Linux Poulsbo depuis un an et demi. Évalué à 10.
Pour rappel, quand même, le jour où ils ont arrêté de développer le driver libre NVidia (il y a longtemps, hein, c'était encore XFree86, et ça ne gérait que la 2D) ils ont obfusqué le code ... (et demandé aux mainteneurs de laisser leur patch obfusquant le code tel quel ; leurs quelques contributions futures, genre pour ajouter des PCI-id et mettre à jour des petits bouts de code, ce sont ensuite toujours faites par des patchs obfusqués). Ça donne une idée de comment ils traiteront les libristes dans le futur.
# C'est pas faute d'avoir prévenu
Posté par benoar . En réponse à la dépêche Intel ne maintient plus le pilote Linux Poulsbo depuis un an et demi. Évalué à 7.
https://linuxfr.org//comments/969276.html#969276
https://linuxfr.org//comments/1062046.html#1062046
https://linuxfr.org//comments/1046786.html#1046786
https://linuxfr.org//comments/936039.html#936039
https://linuxfr.org//comments/1013123.html#1013123
https://linuxfr.org//comments/1061391.html#1061391
Je regarde depuis quelques temps les netbooks et autres tablettes embarquées, mais ce chipset, présent aussi bien sur x86 que sur ARM, m'a fait reculer à chaque fois.
Bref, faites attention !
[^] # Re: Francis Lalanne
Posté par benoar . En réponse à la dépêche OxyRadio arrive sur 4 millons de Freebox. Évalué à 2.
# Ce n'est pas le problème !
Posté par benoar . En réponse au journal Concours de hackage de machines à vote électronique. Évalué à 7.
Je sais qu'on est sur un site de geeks, où certains pourront très bien comprendre ce qui se trame derrière les lignes de codes présentes dans ces machines. Mais avez-vous pensé à tous les autres gens qui doivent vous faire confiance là-dessus ?
De plus, qui vous dit que c'est bien ce code qui est dans la machine devant laquelle vous vous présentez ? Même si on la "charge" devant vous, qu'est-ce qui vous prouve qu'un programme existant / un changement électronique / whatever n'a pas modifié à l'avance son fonctionnement ?
Franchement, ce genre d'initiative ne fait que crédibiliser le vote électronique aux yeux d'un public qui ne comprend même pas les enjeux de base.
[^] # Re: tcpdump
Posté par benoar . En réponse au message ip6tables, laisser passer radvd. Évalué à 2.
Sinon, ça marche bien avec la première ligne que t'as indiqué ?
[^] # Re: tcpdump
Posté par benoar . En réponse au message ip6tables, laisser passer radvd. Évalué à 1.
Par contre ta deuxième règle est vachement plus laxiste, elle va toucher tout partout ...
[^] # Re: tcpdump
Posté par benoar . En réponse au message ip6tables, laisser passer radvd. Évalué à 4.
http://marc.info/?l=netfilter&m=120729439902733&w=2
http://marc.info/?l=netfilter-devel&m=122587864120868&am(...)
http://marc.info/?l=netfilter-devel&m=123306823804829&am(...)
En gros, comme les requêtes du style neighbour discovery sont du multicast, elles ne sont pas "trackables" par conntrack. Elles ne sont donc pas prises en compte par ta règle avec --state ...