benoar a écrit 4238 commentaires

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 ...

Bah, pas forcément, je ne suis pas sûr que le kernel flush tous les caches "sales" avant un S2RAM. C'est à vérifier.

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.

Changer une urne : on peut demander à n'importe quel demeuré de la surveiller. Ou même demander à plusieurs.

Pour surveiller un bit, par contre ...

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".

Bah, ça inciterait peut-être plus les gens à gueuler et à demander à ce qu'ils filent les specs ...

Je comprend ta déception ...

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.

Bon, je n'ai jamais fait de dépêche, mais je tempère l'engouement des libristes depuis quelques temps pourtant ...
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 !

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.

Tiens, je corrige une faute que j'ai fait : les messages router advertisement sont multicast, les neighbour discovery j'en suis pas sûr.

Sinon, ça marche bien avec la première ligne que t'as indiqué ?

En effet, c'est si simple que je n'y avait pas pensé.
Par contre ta deuxième règle est vachement plus laxiste, elle va toucher tout partout ...

J'ai fait quelques recherches et je suis tombé sur (entre autres) ça :
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 ...

Je dirais : d'abord à la distro si tu n'es pas sûr d'où il vient, soit directement chez KDE si tu es à peu près sûr que c'est indépendant de la distro.

Je ne connais pas vraiment Kubuntu, mais vu ce que j'en ai entendu sur son intégration de KDE, peut-être vaudrait-il mieux d'abord poster ça chez Kubuntu (certains projets en ont marre d'avoir à se taper des bugs qui viennent de modifs des distros).

1) Où as-tu vu qu'il était multi-point ? Je ne le lis nulle part ...
2) 300€ un 19" aujourd'hui, soit c'est du haut de gamme, soit tu t'es fait arnaquer

Faut arrêter avec les calculs de coût de l'électricité : ta box consomme autant, sauf qu'elle n'héberge rien du tout ...

discussion ...

C'est avouable mais ridicule. Bon après, même si le ridicule ne tue pas, certains essayent tout de même de l'éviter.

ca te diras peut-etre quel routeur est defecteux
C'est facile de dire "défectueux" quand c'est réellement "on veut pas peerer avec eux" ...