Pinaraf a écrit 3682 commentaires

C'est donc à l'init de faire ça, pas au noyau, et le seul système d'init gérant ça actuellement s'appelle systemd.

Rien ne prouve que ce patch sera inclus dans le noyau. Comme expliqué plus haut, ce patch fait quelque chose qui devrait peut être être fait par l'espace utilisateur et par des outils comme systemd ou autre.
Est-il nécessaire d'altérer le noyau pour cela ?
Lennart Pottering a prouvé qu'un équivalent est faisable très facilement avec quelques lignes dans le .bashrc : cela ne suffit-il pas à diminier l'intérêt de ce patch par rapport à une solution configurable plus finement ?

systemd n'a pas l'intention d'utiliser les cgroups, il les utilise, point.
Sur ma debian j'ai activé systemd, et maintenant la vie me sourit j'ai plein de cgroups :)
La commande systemd-cgls liste les cgroups utilisés sous forme d'arborescence.
En voici un court extrait :
├ 2 [kthreadd]
├ 3 [ksoftirqd/0]
├ 6 [migration/0]
(blabla noyau)
├ 16896 [kworker/u:2]
├ user
│ ├ root
│ │ └ 5c
│ │ ├ 3586 su
│ │ ├ 3588 bash
│ └ moi
│ └ 2c
│ ├ 2193 -:0
│ ├ 2716 /bin/sh /usr/bin/startkde
│ ├ 2747 /usr/bin/ssh-agent /usr/bin/ck-launch-session /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
│ ├ 2750 /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
(blabla mes processus)
└ systemd-1
├ 1 /bin/systemd
├ nfs-common.service
│ └ 15777 /sbin/rpc.statd
├ portmap.service
│ └ 15724 /sbin/portmap
├ kdm.service
│ ├ 1889 /usr/bin/kdm -config /var/run/kdm/kdmrc
│ ├ 1907 /usr/bin/X :0 vt7 -br -nolisten tcp -auth /var/run/xauth/A:0-QsrSzb
│ ├ 2697 dbus-launch --autolaunch 9d930b78559f3c00ceac5bb1478de8d9 --binary-syntax --close-stderr
│ └ 2698 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
(blabla les services système)

Les cgroups permettent/permettront de faire tout ce qu'on a dit de trop cool, mais par contre, j'avoue ne pas savoir les utiliser (même pas eu le temps de lire la doc).
Sur son blog, Lennart parle notamment des options OOMScoreAdjust, CPUSchedulingPolicy... dans les fichiers de configuration des services pour systemd. Ce qui apporte, il me semble, une flexibilité considérable.
Bien sûr, les plus malins diront "un double fork, et mon processus détaché sort du contrôle de systemd".... C'est pour ça que les cgroups sont utilisés : les enfants, même détachés, restent dans le cgroup.

Les cgroups sont utilisés intelligemment il me semble dans systemd, "l'init killer" développé par Lennart Poettering dont on a parlé quelques commentaires plus haut... Chaque service son group, chaque utilisateur son cgroup, et tout le monde est content... On peut ainsi limiter la RAM, le CPU, les IO d'un service, rendre prioritaire l'utilisateur ou les services du système...

En fait, chaque xterm va lancer un bash qui va arriver dans un groupe séparé.
Donc le make -j 64 est dans un groupe distinct du reste de l'interface, et voilà...
Le scheduleur, je suppose, va faire attention à ce que chaque groupe ait un bout "suffisant" de CPU pour son travail, alors que si tout le monde est dans un groupe, ben à cause du make -j 64, y'aura 64 + n processus voulant le processeur, et le scheduleur ne sait pas qui "favoriser" et donne autant que possible à chaque processus, tout simplement...

D'ailleurs, peut-on émuler le patch noyau avec des commandes shell ? Les cgroups peuvent être configuré avec un système de fichier virtuel.
systemd est parfaitement capable de faire ça il me semble.
D'ailleurs j'ai vu des discussions sur l'intérêt de ce patch si l'espace utilisateur ne peut pas faire tout plus finement...

Mais il serait bon de plutôt les comparer a un gpu Intel, dont les pilotes libres sont plus abouti (je n'ai pas d'intel, je spécule peu être...?)
Le soucis c'est que les IGP Intel sont par nature lents déjà, mais qu'en plus, les pilotes Linux sont deux à trois fois plus lents que les pilotes windows !
Par contre, en 2D, ils sont très bons.
Pour information, petit benchmark de Phoronix sur ce sujet :
http://www.phoronix.com/scan.php?page=news_item&px=ODIwM(...)
Aucun commentaire n'est nécessaire je pense...

Tu as tout à fait raison, oui.
Le support très avancé, et avec le niveau d'optimisation requis, de la 3D prendra vraiment très longtemps, et d'ici là, les technologies auront sûrement suffisamment évolué pour que des années de travail soient à nouveau requises pour atteindre le niveau requis...
Dans le cas du pilote nouveau, il faut noter qu'un fork de la partie 3D a été créé par une entreprise motivée par la réalisation d'un système très performant, plus performant que celui de nVidia, pour les G80 et supérieur. Reste à voir ce que cela donnera. Ils prévoient le support de l'OpenGL4 pour 2011/2012, ce qui, vu l'état actuel des choses, semble être un objectif bien difficile à atteindre.

Hoo une blague...
Petit rappel : les développeurs des pilotes libres n'ont jamais promis d'avoir les performances des pilotes propriétaires, et si ils approchent de 50% des perfs des pilotes propriétaires ça sera déjà un mini-exploit.
Les performances des pilotes propriétaires sont le fruit de plusieurs années d'optimisation, orientée par les nombreux jeux et logiciels qu'ils font tourner.
Par contre, là où ils peuvent briller, c'est sur le support de la 2D, le support de toutes les technologies présentes dans le serveur X...

nVidia ION 2, a priori non supporté sous Linux...

Déjà, comme dit avant, on perd beaucoup du charme des ARM.
De plus, la consommation électrique de l'Atom reste bien au dessus de la consommation d'un ARM.
Enfin, ces systèmes reposent sur une puce graphique intel renommée : le GMA 3150 est un i945 renommé et intégré au processeur. Et si tu veux faire un média center avec ça, aucune chance, les performances graphiques sont tout simplement ridicules.
Les ARM eux sont souvent fournis avec des puces graphiques bien plus performantes. Par contre, autre problème dans ce cas : trouver des pilotes fonctionnels... Ça c'est une autre histoire...

Ils ont peut être pas envie de mettre en place des tunnels si ils ont déjà leur technologie qui marche et qui est éprouvée.

Ça te traverse pas l'esprit qu'ils puissent avoir une raison technique de ne pas mettre d'IPv6 pour les non-dégroupés ? Au hasard, le fait qu'ils ne contrôlent pas le DSLAM et qu'ils puissent avoir des difficultés avec la mise en place du 6rd dans ces cas ?

Waaa, t'as des madames michu qui doivent manipuler des adresses IP maintenant ?

Même un lecteur de ce site peut se faire avoir : je n'avais jamais eu ou installé de livebox, un ami m'a demandé de lui installer... Game over, le windows XP a survécu moins de 5 minutes à l'accès direct à Internet...

Généralement dans un intranet, tu as les 2/3 premiers octets qui sont toujours les mêmes, donc pour retenir une machine, tu ne retiens que le dernier octet (oui, parce que nos normes de nomages sont encore plus compliqués que retenir une adresse IP).
Or, ça sera la même chose avec l'IPv6...
Par exemple, ma machine pourrait être 2a01:f45:2e57:b9d1::42, donc depuis une autre machine, je n'ai aussi que deux octets à retenir...

Premièrement sur la compatibilité IPv4/IPv6, ça aurait été trop dur dans la norme IPv6 de dire que les 2^32 adresses possibles sont en fait IPv4 ??? (ou un autre préfixe)
Hum, comment dire...
C'est presque le cas...
Je cite Wikipedia :

Hybrid dual-stack IPv6/IPv4 implementations support a special class of addresses, the IPv4-mapped IPv6 addresses. This address type has its first 80 bits set to zero and the next 16 set to one, while its last 32 bits are filled with the IPv4 address. These addresses are commonly represented in the standard IPv6 format, but having the last 32 bits written in the customary dot-decimal notation of IPv4; for example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128.

La survie d'un réseau viable devrait être suffisante comme raison, mais bon... (cf commentaire de glaborg pour la saturation du nombre de ports en cas de NAT massif : ma machine seule, en utilisation légère, consomme 17 ports... je ne fais pas de web massif, je déteste ça, mais si je lançais en plus des sites comme gmail, facebook ou d'autres bouffeurs de requêtes, je pourrais aisément dépasser les 30 si je ne me trompe pas...)
Le soucis, c'est que presque personne n'a le nécessaire pour tester et déployer de l'IPv6. L'internet est devenu un nid à fric, les vautours qui se le partagent ne permettent pas de faire d'expérience pour montrer l'utilité d'IPv6.

Sauf que dans une logique purement commerciale, tant qu'il n'y a pas l'IPv6, il n'y aura pas cette application. Rien ne sert de la réclamer à ce point quand tu affirmes que l'IPv6 ne sert à rien commercialement, c'est du dédoublement de personnalité que tu nous fais là.

On tombe sur un problème plus global : qui paie pour internet, qui le gère ? Qui a ou aura le courage de faire avancer techniquement le réseau ?
C'est amusant de voir dans le monde de l'informatique, réputé pourtant pour sa rapidité de changement, une telle réticence. Quoi qu'on en dise, quelque chose est nécessaire pour fournir un accès Internet sur toutes les machines de la planète. L'IPv4, avec le NAT, ne le permet déjà plus finalement : on se retrouve obligés de faire l'équilibre avec les ports pour permettre l'accès à N services derrière une IP publique. Mais bien sûr, avec l'ADSL, l'envie de faire de l'hébergement chez soi est vite freinée par la réalité d'un débit montant minable. Mais quid de la fibre ? Que se passera-t-il quand les gens comprendront le potentiel d'un système vraiment décentralisé, hors de tout noeud central, où l'on pourra partager des données avec son voisin, ses amis ou sa famille ? Là, l'IPv4 deviendra un énorme frein.
Un tel service n'existe pas aujourd'hui, donc l'IPv6 ne sert à rien ? Et si c'était l'inverse ? Et si, à cause du manque d'IPv6, un tel service n'existait pas ? Pourquoi les anti-IPv6 prennent-ils toujours le problème dans ce sens et ne veulent-ils pas admettre la moindre opportunité dans un ajout de l'IPv6 ?

Configurer le NAT en IPv4 est d'une pénibilité bien supérieure sur les freebox : il faut mettre en place des attributions fixes des IP par adresse MAC, mettre en place les N redirections de ports, et redémarrer la freebox (ce n'est pas quelque chose que je suis capable d'expliquer par téléphone à un noob). Ho, bien sûr, N machines à accéder en SSH = N ports différents à router pour lutter contre ce soucis.
Configurer l'IPv6 ? Cocher une case, redémarrer la freebox.

Ho, c'est la faute à la freebox ?

Prenons la livebox. Hi hi, dois-je en dire plus ? Comment tu fais du NAT avec un machin qui, du jour au lendemain, oublie l'IP attribuée à l'imprimante réseau et casse donc la configuration d'impression des 3 machines du réseau ? Et l'interface de la livebox est insupportable. Mais hélas, chez eux, point d'IPv6, donc je suis effectivement bien emmerdé dans ce cas. Au passage, quand j'utilisais encore une livebox, impossible de router du port 4242 vers le port 22 par exemple, il fallait configurer sur la machine pour que sshd écoute le port 4242. Super pratique.

Par contre, je n'ai jamais touché à une neufbox.


Donc non, pour le grand public, le NAT est également la chienlit à configurer. Pour le grand public, l'IPv6 devrait être systématiquement activé parce que ça n'apporte qu'une simplicité de configuration accrue.
Sinon, pour en revenir au troll initial, à savoir un problème de performances : en quoi est-ce la faute d'IPv6 ? Si l'IPv6 ralentit Firefox, c'est Firefox qui est en tort, pas l'IPv6 !

Ha, pardon, je pensais pas devoir argumenter l'évidence...
Pour ma part, j'active l'IPv6 sur les freebox de mes amis qui souhaitent que je les dépanne à distance : je leur mets ma clé publique SSH, j'active SSH avec authentification par clé et je note sur ma machine l'IPv6 de leur machine pour un dépannage sans aucune prise de tête avec le NAT.
Autre fonctionnalité que j'ai déjà utilisé : de l'échange de fichiers directement entre machines avec des amis.
Une autre ? L'hébergement de sites ou de démos sur ma machine, avec un enregistrement AAAA dans un DNS.

Bien sûr, au plus l'IPv6 se fera désactiver sans raison valable, au plus ce sera difficile d'argumenter en sa faveur. Ça s'appelle un cercle vicieux, et il est vrai qu'il faut un minimum de courage et de raisonnement pour lutter contre.

Sauf que ce n'est pas forcément mis en place. Sauf erreur, une Freebox en IPv6 laisse tout passer.
En IPv4, par défaut, une freebox n'est pas en mode routeur et laisse également tout passer hein...

Pour info, l'infrastructure fibre de free (contrairement à l'immonde infrastructure fibre d'orange, basée sur le même système que pour l'ADSL, avec déco régulière, IP dynamique et utilisation du PPP) fournit de l'IPv6 nativement, sans utilisation de tunnels... C'est juste impossible pour eux de remplacer tous les DSLAM par des équipements compatibles IPv6...

Si, mais cela serait surprenant.
Les offres en question ont malheureusement disparu du site LDLC (!!), mais il me semblait qu'elles partageaient le même chipset. Or, si l'IGP est externe au CPU, il est dans le chipset. D'où un petit problème de cohérence, non ?
Et dans tous les cas, si l'IGP est externe au CPU, omettre de le mentionner dans la liste du matériel est une erreur...

P.S: j'ai bien précisé dans mon commentaire que l'autre hypothèse était un IGP externe hein, optimus pourrait peut-être même marcher avec un GPU Intel ou AMD qui sait...