> Avec DHCP tu n'as pas de configuration à stocker. Avec une IP fixe, il faut stocker la configuration, faire une IHM, etc.
Sauf que comme tu le dis, NM a été fait pour le wifi en premier... or, pour le wifi, il faut stocker de la clé... donc, de quoi faire du stockage, c'est déjà là.
Quant aux IHM, ce n'est pas du ressort de NM, mais des surcouches graphiques à NM... NM n'a pas besoin de clickouille pour fonctionner.
> définir une adresse IP (trop dangereux ; problème de sécurité ; ça peut foutre le border sur le réseau)
Hein ? ... si on spécifie une adresse IP qui n'est pas sur le bon segment, bah, ça ne marche pas : point. Si ce que tu sous-entends est un réseau où le DHCP et les IP fixes peuvent être sur un même switch ou VLAN, et où on peut spécifier une adresse IP qui soit dans l'étendue du DHCP, là, c'est du travail de cochon, et c'est de toute façon du ressort de l'admin.
Maintenant, je comprends bien la démarche : simplifier les cas pour les utilisateurs qui ne s'y connaissent pas. Comme je l'ai dit, c'est quelque chose que je trouve très bien (quand ça marche : cette fin d'année dernière, j'ai installé une Lenny à un pote qui voulait voir - NM était incapable de choper un bail DHCP ; ça a très bien marché à la mimine dans /etc/network/interfaces ; j'ai renoncé à chercher à comprendre)...
Sauf que faire ça en gérant des cas très particuliers, en négligeant de gérer les cas les plus simples, juste pour se grouiller d'avoir un truc qui marchouille à-la-rache, j'estime que c'est faire les choses dans le mauvais ordre. Point.
> Il y a eu des régressions avec Xorg ces derniers temps
Ces dernières années, même. Ça fera deux ans le mois prochain que X.org 7.2 est sorti, et empêche de faire du multi-GPU (donc, du tri-écran) et du multi-serveurs X (de première utilité quand on veut dévouer un écran à l'affichage de videos, par exemple)... entre autres.
Les GPU objects sont censés résoudre le premier problème... ils sont annoncés tous les 6 mois... mais tout aussi souvent repoussés. Et j'imagine qu'on ne verra pas le retour de cette chose indispensable dans, par exemple, le graphisme ou la finance, avant encore des années. Je n'appelle plus ça avancer - pour note, les OS redmondiens savent aussi gérer ça depuis des éons...
Un cassage de 6 mois, bon, m'en fous, à la limite... mais deux, trois (au strict minimum, tel que c'est parti), quatre ans, ça commence à être lourd : résultat, avant, j'installais le GIT de X.org et je bugreportais beaucoup... maintenant, je ne le fais plus du tout, et je suis à la limite de m'en foutre.
D'autant que m'est avis que le branchage à chaud ne fonctionne toujours pas sans peine pour les utilisateurs qui ne connaissent pas l'édition manuelle des fichiers de conf, en dehors du mode clone, puisqu'il faut toujours rajouter un Virtual dans le xorg.conf pour le mode étendu.
Résultat : au bout de deux ans, tout est devenu galère pour tout le monde, sauf ceux qui utilisent le mode clone (euh... même en présentation, il y a des gens qui utilisent le mode clone ?)...
Pour le problème du multi-serveurs X et des galères de focus et cie, j'ai pu lire sur les mailing-lists de développement que ce devait être le boulot des environnements graphiques... j'aime autant ne même pas dire ce que je pense de cette impérieuse suggestion :|
Ce que je critique, ce n'est pas quelques régressions temporaires, mais des régressions très très longues, non fructueuses, et plus généralement, une démarche qui me semble consister à partir de cas trop particuliers, pour casser tous ceux qui le sont un peu moins. De mon point de vue d'utilisateur, qui n'en respecte pas moins le temps passé à développer, dussé-je le préciser, les problèmes ne sont ni pris dans le bon ordre, ni de la bonne manière... et _fait_ est que je ne m'en réjouis plus.
La philosophie UNIX a toujours été de partir sur des choses simples, avec des outils simples, qui faisaient bien leur travail. Et _fait_ est qu'on s'en éloigne (au bas mot) aujourd'hui... et ça non plus, je ne m'en réjouis pas.
[^] # Re: Problèmes réseau
Posté par Aefron . En réponse à la dépêche Test de Fedora 10 Cambridge. Évalué à 5.
Sauf que comme tu le dis, NM a été fait pour le wifi en premier... or, pour le wifi, il faut stocker de la clé... donc, de quoi faire du stockage, c'est déjà là.
Quant aux IHM, ce n'est pas du ressort de NM, mais des surcouches graphiques à NM... NM n'a pas besoin de clickouille pour fonctionner.
> définir une adresse IP (trop dangereux ; problème de sécurité ; ça peut foutre le border sur le réseau)
Hein ? ... si on spécifie une adresse IP qui n'est pas sur le bon segment, bah, ça ne marche pas : point. Si ce que tu sous-entends est un réseau où le DHCP et les IP fixes peuvent être sur un même switch ou VLAN, et où on peut spécifier une adresse IP qui soit dans l'étendue du DHCP, là, c'est du travail de cochon, et c'est de toute façon du ressort de l'admin.
Maintenant, je comprends bien la démarche : simplifier les cas pour les utilisateurs qui ne s'y connaissent pas. Comme je l'ai dit, c'est quelque chose que je trouve très bien (quand ça marche : cette fin d'année dernière, j'ai installé une Lenny à un pote qui voulait voir - NM était incapable de choper un bail DHCP ; ça a très bien marché à la mimine dans /etc/network/interfaces ; j'ai renoncé à chercher à comprendre)...
Sauf que faire ça en gérant des cas très particuliers, en négligeant de gérer les cas les plus simples, juste pour se grouiller d'avoir un truc qui marchouille à-la-rache, j'estime que c'est faire les choses dans le mauvais ordre. Point.
> Il y a eu des régressions avec Xorg ces derniers temps
Ces dernières années, même. Ça fera deux ans le mois prochain que X.org 7.2 est sorti, et empêche de faire du multi-GPU (donc, du tri-écran) et du multi-serveurs X (de première utilité quand on veut dévouer un écran à l'affichage de videos, par exemple)... entre autres.
Les GPU objects sont censés résoudre le premier problème... ils sont annoncés tous les 6 mois... mais tout aussi souvent repoussés. Et j'imagine qu'on ne verra pas le retour de cette chose indispensable dans, par exemple, le graphisme ou la finance, avant encore des années. Je n'appelle plus ça avancer - pour note, les OS redmondiens savent aussi gérer ça depuis des éons...
Un cassage de 6 mois, bon, m'en fous, à la limite... mais deux, trois (au strict minimum, tel que c'est parti), quatre ans, ça commence à être lourd : résultat, avant, j'installais le GIT de X.org et je bugreportais beaucoup... maintenant, je ne le fais plus du tout, et je suis à la limite de m'en foutre.
D'autant que m'est avis que le branchage à chaud ne fonctionne toujours pas sans peine pour les utilisateurs qui ne connaissent pas l'édition manuelle des fichiers de conf, en dehors du mode clone, puisqu'il faut toujours rajouter un Virtual dans le xorg.conf pour le mode étendu.
Résultat : au bout de deux ans, tout est devenu galère pour tout le monde, sauf ceux qui utilisent le mode clone (euh... même en présentation, il y a des gens qui utilisent le mode clone ?)...
Pour le problème du multi-serveurs X et des galères de focus et cie, j'ai pu lire sur les mailing-lists de développement que ce devait être le boulot des environnements graphiques... j'aime autant ne même pas dire ce que je pense de cette impérieuse suggestion :|
Ce que je critique, ce n'est pas quelques régressions temporaires, mais des régressions très très longues, non fructueuses, et plus généralement, une démarche qui me semble consister à partir de cas trop particuliers, pour casser tous ceux qui le sont un peu moins. De mon point de vue d'utilisateur, qui n'en respecte pas moins le temps passé à développer, dussé-je le préciser, les problèmes ne sont ni pris dans le bon ordre, ni de la bonne manière... et _fait_ est que je ne m'en réjouis plus.
La philosophie UNIX a toujours été de partir sur des choses simples, avec des outils simples, qui faisaient bien leur travail. Et _fait_ est qu'on s'en éloigne (au bas mot) aujourd'hui... et ça non plus, je ne m'en réjouis pas.