> Mais une question quand même, avec TOR, on peut "héberger" un site de manière anonyme ?
Ouaip, via un "hidden service" (serveur caché) [1] ;)
Par contre, de ce point de vue, faudra faire gaffe à IPv6 : si quelque chose dans le serveur (un message d'erreur ou quelque chose de ce genre) recrache son adresse, et que celle-ci n'est pas une adresse non routable publiquement (ce sera toujours possible en IPv6, bien sûr... mais avec la pléthore d'adresses dispo, il sera tentant pour beaucoup de ne pas s'emmerder avec des proxies & co, et d'allouer une adresse publique à toutes les machines [ce que je n'ai aucune intention particulière de faire, quand mon tour viendra]), des informations sur la location IP du serveur pourront fuiter...
C'est ce que je fais maintenant : mes HDD externes en ext3 (1To en FAT32, l'idée de faire du checkdisk souvent me faisait un peu perler du front), et un liveCD dans la pochette de transport de chaque HDD...
... et ça me va à la perfection. De toute façon, chez moi, il n'y a que des OS libres (ce qu'il y a de plus en plus en dehors de chez moi, d'ailleurs)... et si les gens chez qui je vais ne sont pas interopérables avec les technos libres, et surtout, ne sont pas prêts à un reboot (alors que bon, en général, ils ont l'habitude :p), bah tant pis : c'est comme le flash - je m'en fous ; le rapport gain/perte est bien mieux comme ça pour moi.
> quelqu'un d'assez informé pour choisir WPA ou WPA-2 sera aussi suffisamment informé pour activer le mode routeur
Oh, ça dépend... perso, les modes routeurs de la plupart des boîtes FAI, ils me saoulent d'une force !
... moi qui demande généralement à une box de tout renvoyer vers un routeur (rapide, non bloaté et propre... à moi, où aux gens qui me demandent d'en installer un), si je pouvais simplement désactiver cette saloperie de mode routeur sur les livebox (putains de boîtes sagem !) ou les neufbox (du grand art : on ne peut même pas NATer de 1 à 65535 sans se prendre la tête : certains ports sont réservés, peut-être pour la TV et le tel)... bon, les freebox, ça, ça va, c'est facile à bridger...
Les seuls intérêts que je vois aux boîtes FAI, ce sont le tel et la TV : sauf que je ne me sers ni de l'un, ni de l'autre ; et c'est pour ça que j'ai mes routeurs derrière un simple modem ADSL2+ (qui me fait entre autres gagner 10-15ms de ping, le tout bootant et se connectant beaucoup plus vite que l'immonde livebox, et le tout étant sous mon contrôle).
> puisque tu n'est pas identifiable, internet n'a pas accès à toi
Au niveau IP, si... ce qui manque, c'est le reverse DNS (IP fixe, ou pas - ça ne change rien sur le fond)...
... ce qui montre bien que le filtrage des IP qui ont un reverse non délégué par le FAI au client (ie les reverse en blabla.abo.blabla.truc) est un emplâtre sur une jambe de bois...
... puisque cette "pratique" repose sur le simple décret, majoritaire, que "les connexions des particuliers n'ont pas à faire tourner des serveurs"...
Dire qu'on ne peut pas laisser les particuliers émettre des mails parce qu'ils n'ont pas de reverse DNS propre, c'est présenter les choses sous un drôle d'ordre... S'ils n'ont pas de reverse DNS propre, c'est justement parce que les FAI ne semblent majoritairement pas intéressés par l'utilisation de serveurs sur les lignes à bas-coût (et encore... par exemple, les neurones fumeux de chez Orange ont décidé de ne même pas donner la délégation du reverse sur les forfaits pro... apparemment, ils arguent que ce n'est pas gérable pour les particuliers - ça fait peur).
> l'annuaire peut déjà centraliser les utilisateurs et les groupes
J'imagine que je vais devoir modifier le schéma pour ajouter les infos dont j'ai besoin, et c'est ce qui me fait un peu peur (pas beaucoup d'expérience LDAP)... mais j'en ai un peu marre de définir mes variables et classes CFEngine dans des fichiers textes, et j'ai de plus en plus besoin de quelque chose comme un annuaire (a priori, ça me paraît plus adapté qu'un MySQL ou assimilé)...
Par contre, pas grand monde n'a l'air de faire ça (en tout cas, avec CFEngine... Puppet inclue de quoi gérer une conf centralisée dans LDAP ; mais trop de choses me gênent par ailleurs dans Puppet)...
> Cela sort toutefois du cadre de LemonLDAP::NG
Certes : LemonLDAP::NG est néanmoins une raison de plus de me repencher sur LDAP... et je dois avouer que son concept est séduisant.
> la phase d'authentification [...] peut être effectuée [...] par [...] tout [...] méthode d'authentification disponible dans Apache2
> De plus, toutes les applications Web utilisant des protections Apache (par exemple par htaccess) sont nativement compatibles
Donc, si j'ai bien compris, ça permet (outre le SSO) d'unifier les méthodes d'identification web, quelles qu'elles soient entre LemonLDAP::NG et le serveur sur lequel on souhaite s'authentifier ? Par exemple, forcer l'utilisation d'un certificat de smartcard pour accéder à un service à la base "protégé" par htaccess... Intéressant.
D'autant que suis justement en train de me repencher sur LDAP - j'avais arrêté de le tester il y a un moment en me disant que le faible nombre d'utilisateurs que j'ai inhibait ses bénéfices, mais en fait, vu le nombre de machines que je finis par avoir avec les conteneurs OpenVZ/Vserver, j'ai maintenant dans l'idée de m'en servir comme base de données que mon CFengine maître utiliserait pour personnaliser les fichiers qu'il exporte aux clients, en faisant gaffe à gérer le cas d'indisponibilité du LDAP, et afin de répartir les données dans le réseau sans forcément les dupliquer à leur définition.
Par exemple, savoir sur quelles machines tourne quoi et à partir desquelles autres elles peuvent être jointes est utile pour configurer iptables sur les routeurs, pour configurer les serveurs, _et_ pour configurer les clients - or tant que le CFengine maître est le seul à connaître toutes ces données, rangées proprement dans une base de données LDAP, les ACL LDAP ne deviennent pas trop un enfer (par rapport à si je déléguais la recherche aux clients CFEngine)...
... pour ce qui est des ACL CFEngine, ie les "grant" du cfservd.conf, je pense "simplement" essayer de les fabriquer à partir des FDQN des hôtes (en créant autant de répertoires exportés que d'hôtes, et où seront personnalisés des fichiers de conf génériques, en fonction de certaines classes, assignées dans l'annuraire), et de LDAP...
Je n'ai pas encore trop réfléchi à comment bénéficier, au passage, de LDAP pour les authentifications (vu que ce n'est pas mon but initial), mais j'ai dans l'idée que je n'aurai pas trop de mal à trouver une place dans cet ensemble à LemonLDAP, entre autres.
... néanmoins, les logs de X.org sont asynchrones par défaut (ie ils ne sont pas écrits dès que quelque chose arrive, mais un peu après, en groupe, pour éviter de bouffer des perfs... je sais qu'il y a une option pour activer les logs synchrones, pour diagnostiquer quand on ne peut même plus joindre la machine par SSH, genre, X.org qui fait "hard-locker" le noyau, mais je ne m'en souviens plus). Aussi, attends un peu qu'ils aient le temps d'être écrits, en croisant les doigts pour qu'il y ait assez de temps CPU pour le faire dans des délais raisonnables.
Posté par Aefron .
En réponse au message dual head.
Évalué à 5.
Il y a de gros problèmes avec le multi-board (ie multi-cartes... je donne le terme anglophone pour pointer vers celui qui donnera le plus de résultats sur les ML - sinon [1] et [2]) depuis RandR 1.2 (X.org 7.2).
À la base, pour l'instant, la section ServerLayout n'est plus censée être utilisée... et xinerama non plus : toute la gestion du multi-écran est censée passer par RandR, qui ne prend pas en compte le multi-cartes pour l'instant (ie, quand c'est marche, c'est un heureux hasard ; je ne connais pas le driver Sis, mais s'il ne supporte pas RandR, ça pourrait expliquer que ça passe, avec quelques étrangetés - chez moi, avec plusieurs Radeon, ça plante au lancement ; et l'Intel intégrée sur une de mes mobos ne peut pas marcher en même temps que le port PCI-E, ce qui a jusqu'ici négativement conclu les essais qui m'intéressaient).
Pour le multi-X.org (ce qui est censé permettre le ServerLayout), il paraît que RedHat va travailler dessus pour Fedora 11 ou 12... Par contre, je ne sais pas si ça marchera avec plusieurs cartes dès le début (le multi-cartes, ça doit venir avec les GPU objects, qui doivent arriver avec une lointaine et future version de RandR... et il n'y aura pas besoin de multi-cartes pour implémenter le multi-X.org, puisque ça pourra se faire sur deux sorties d'une même carte, et sera par exemple extrêmement utile pour les HTPC et autres écrans dédiés aux medias).
Malheureusement, il reste beaucoup de boulot sur le multi-écran moderne et avancé dans X.org... et il y a sur cette route beaucoup de régressions par rapport à l'ancienne manière de faire, tout à la main, compliquée, mais où beaucoup de choses étaient possibles (même si ça supposait que Xv, DRI, et cie ne marchaient plus forcément).
Sinon, avec plusieurs écrans, sur plusieurs machines, mais pour un même bureau : DMX... il paraît qu'il a bien progressé, et c'est sur la liste des choses que je dois trifouiller.
Bof... pour l'instant, de toute façon, la plupart des clients ne feront pas la différence, et ne mettront surtout pas de message particulier, en cas d'échec de vérification des signatures, ou même simplement d'absence de signatures...
D'autant que les zones non signées, c'est tout sauf ce qui manque...
DNSSEC, pourquoi pas, mais c'est loin d'être prêt (quid de la distribution des clés ? quid du dernier saut jusqu'au résolveur du client ? quid de la notification au client que les signatures ne sont pas dispo ou fausses ?)... alors, parler de son adoption...
Pas que je ne me lamente pas du pathos du DNS actuel... mais les choses ne sont pas finalisées au niveau des serveurs, et encore moins au niveau des clients... m'est avis qu'on n'est malheureusement pas prêt de profiter un service de noms sécurisé (même localement)...
Et ne serait-ce que pour router du gigabit, et même le filtrer en stateful, y a intérêt d'être accroché à son slip...
Ce n'est pas avec du malheureux MIPS à quelques centaines de MHz et assimilés qu'on va le faire (déjà que le filtrage du réseau local à 100MBps stresse bien un WRT54G)...
Non, 100MBps, ça le ferait déjà bien (tant que ce serait illimité, symétrique, IPv6 à base de /48 alloués, et avec DNS inverses dans ip6.arpa comme on veut pour toutes les adresses :p).
Tout à fait : mais c'est un peu galère chez moi - plancher (oui, ce serait entre l'étage et le rez de chaussée) réhaussé et lino...
... ni évident à percer, ni à reboucher :(
Bon, de toute façon, je ne suis plus dans ce logement pour très longtemps, et il faut quand même avouer qu'il y a eu de gros progrès dans le wifi libre depuis les quelques années où j'en utilise (la carte du HTPC fonctionne bien avec ath5k, et j'ai réussi à avoir une pas trop mauvaise connexion avec b43 pour l'AP... j'attends que les kernels récents soient patchés pour Mips sous OpenWRT pour espérer avoir quelque chose d'utilisable, et me débarrasser du dernier logiciel proprio qui tourne sur mes CPU... et si en plus on peut espérer à terme un firmware, c'est Byzance).
Bon, après, si le 802.11n pouvait se finaliser, et qu'on en ait un support libre, alors là :)
Hum, je n'ai pas encore essayé de mettre ça en place, mais ça pourrait être très utile chez moi...
Mon HTPC est connecté au serveur NFS par wifi (pas le choix : locataire, donc pas de trous pour faire passer du RJ45). Il est aussi en dual-screen avec un petit LCD qui permet par exemple de chercher sur le web dans le salon.
Avec du QOS, je pourrais m'assurer qu'une recherche sur le web ne bouffe pas la bande passante nécessaire aux videos...
J'imagine que ça pourrait aussi être utile avec les VAP (Point d'Accès Virtuels), en permettant de favoriser certains SSID par rapport aux autres...
Avec la ridicule bande passante du 802.11g, ce serait tout sauf du luxe, et ça fait un moment que j'y pense.
C'était pour bien marquer la différence entre le réseau du site (quoi que soit le site... parce que si on commence à ergoter là-dessus aussi :p), et les subdivisions (pas forcément d'un même espace IP autre que 0.0.0.0/0, en IPv4, certes) qui en seront faites ;)
Oui, enfin, si tu mets un serveur ou quoi que ce soit de critique sur le même sous-réseau que tes invités, tu cherches le bâton pour te faire battre...
... ça revient à ce que je disais quand je parlais de travail de cochon ; et ça, ça incombe à l'admin.
Si tu alloues un sous-réseau pour les machines dont tu n'es pas maître, n'importe qui pourra s'y configurer l'adresse de quelque serveur que ce soit en dehors de ce sous-réseau, ça coincera au niveau d'un routeur entre ce sous-réseau et tes autres, et il n'arrivera pas à avoir une connexion IP qui-va-bien.
Au pire, l'emmerdeur pourra prendre une adresse déjà allouée à un autre invité, et "perturber" le sous-réseau que tu leur aura alloué... le reste du réseau ira très bien quand même. Après, si les invités qui se font emmerder utilisent des services mal sécurisés pour faire des choses confidentielles, qui plus est sur un réseau auquel ils n'ont aucune raison de faire confiance, et que des informations à eux fuient, ça leur fera la bite, et leur fera prendre de bonnes habitudes...
Quant au cas où le sous-réseau est utilisé par de multiples personnes, que les machines sont maîtrisées, et qu'on craint qu'un glandu se serve de NM pour s'allouer une IP fixe et foutre la merde... bah, les machines étant maîtrisées, on n'installe pas NM, et il faut alors être root pour toucher à la conf réseau de la machine... et hop.
N'en reste pas moins qu'en tout point de cette situation, le problème de sécurité est humain (admin ou invités)... mais avec NM ou pas pour gérer les IP fixes, les emmerdeurs pourront quand même s'en configurer une s'ils se ramènent avec leur machine (et dans le cas contraire, ce n'est pas aux utilisateurs de toucher à la conf IP - aussi, quelque chose qui le leur permet n'a rien à y foutre) ; ce qui n'est pas un problème si le réseau est conçu proprement.
La confiance, contrairement à la stabilité, de toute façon, c'est subjectif. J'ai pleinement confiance en Sid pour être, par exemple, bien plus fiable et fonctionnelle que, par exemple, les trucs de chez Canonical... jamais eu de souci avec depuis loooonnnngtemps.
La fonctionnalité, c'est par contre relatif : ça dépend de ce qu'on cherche. Mais je suis d'accord sur le fait que c'est plus objectif que la notion de fiabilité.
Sur le fond, ce que j'estime être non corrélé à la stabilité, c'est aussi bien la fiabilité que la fonctionnalité. Pour passer outre l'exemple qui implique une documentation en ligne, plus généralement, si j'installe une Debian Stable sur une machine que je ne connais pas, je sais que je cours le risque que ça ne supporte pas tout ce dont il y a besoin : il risque de manquer des fonctionnalités, et je ne m'y fie donc pas.
Avec Testing, et Sid, j'ai la plus grande confiance quant à ce que ça ne parte pas en sucette, tout en m'apportant les fonctionnalités désirées. Et l'expérience m'a prouvé que j'avais raison de faire comme ça : j'utilise Sid (station de travail et portable) et Testing (HTPC) au quotidien, j'ai installé plein de Testing à plein de monde (sauf quelques cas particuliers où, puisque ce sera moi qui maintiendra la machine, j'ai mis de la Debian Stable), et il est rarissime qu'on me demande de l'aide (et en général, ce n'est pas pour grand chose).
> à quoi ça sert de déclarer des bugs qui ne seront probablement jamais corrigés ?
Ça sert à ceux qui n'arrivent pas à faire quelque chose : une fois le bug rapporté, il y a une trace qu'ils ne sont pas les seuls dans cette galère.
Ça sert aussi aux mainteneurs à être au courant de problèmes, et les pousse à se renseigner sur l'état du bug chez les développeurs du projet en amont... voire, à leur transmettre.
Souvent, un bug est marqué en "won't fix" (ne sera pas résolu) ; mais en lisant la discussion sur le rapport, on trouve souvent un "réglé dans telle ou telle version", ce qui est de première utilité aux utilisateurs et administrateurs.
C'est peut-être de la bureaucratie que de rapporter des bugs pour des distros figées, mais c'est tout sauf inutile.
> 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.
Bah, ce n'est pas tant Fedora que je critique (encore que s'ils embarquent un NM sans IP fixe, c'est mort pour l'installation par le réseau sur le segment de LAN que j'utilise usuellement, et qui n'a strictement aucun besoin de DHCP - bon, de toute, façon, après avoir testé F9 il y a quelques mois, j'en suis venu à penser que Fedora n'est pas une distrib pour moi : même si j'aime bien la tester dans un qemulator, je ne l'installerais plus sur une machine non virtuelle) que NM.
En fait, je trouve pour le moins incongru d'avoir développé avec le DHCP en premier, alors que l'utilisation des IP fixes me paraît un cas plus élémentaire. Si les IP fixes sont gérées, au moins, ça marche pour tout le monde - avec DHCP, bah non, faut un démon ou un relai DHCP, donc un truc en plus. Je veux bien que NM soit fait pour gérer le réseau en userland, et que ceux qui ont le plus de mal à le faire soit ceux qui utilisent DHCP, probablement même sans en avoir conscience, mais à mon avis, cet ordre de développement revient à mettre la charrue avant les bœufs.
Du coup, je fais avec ifplugd, les pre/post-up/down, guessnet, et cie, et ça marche très bien... mais je n'ai pas de jolie GUI pour montrer la puissance de la configuration réseau aux gens.
Après, je n'ai rien contre faciliter la configuration de Linux, via NM, ou RandR... c'est plutôt la manière de s'y prendre, en ignorant, voire en cassant, la configuration basique (merci RandR : depuis lui, plus de multi-GPU, donc plus de tri-écran... et je connais des gens qui ne se mettront pas à Linux tant que le multi-head ne marchera pas... d'autant que RandR et le multi-écran non cloné, ça nécessite encore la plupart du temps de rajouter une ligne "Virtual" dans le xorg.conf, donc, grandr est mignon, mais de toute façon pas adapté pour de nombreux usages).
J'estime que c'est une manière de s'y prendre à-la-bling-bling : ça marche plus facilement, mais il ne faut pas trop gratter le vernis... j'ai vraiment du mal avec cette manière de faire.
> si tu t'aventures en dehors de ce qui à été testé et éprouvé, tu t'éloigne d'un système fiable
Non : l'état des paquets est tout autant stable, donc il y aurait grand mal à s'éloigner d'un système stable en en utilisant un... par contre, il pourra être plus difficile d'en faire une utilisation fiable.
Avec le même exemple de X.org 7.1 : tu apprends sur le Net que X.org (sans précision) fait du branchage d'écran à chaud. À partir de la 7.2, certes, c'est vrai, et tu peux te fier à cette information pour être exacte, et à X.org pour brancher tes écrans à chaud. Mais pas de chance : pas avec la 7.1. Tu ne peux pas te fier à cette dernière pour gérer le branchage à chaud : dans ce cas particulier, elle n'est pas fiable, bien que stable.
En revanche, si tu veux brancher deux GPU, tu ne peux pas te fier à X.org>7.2 pour le faire (à compter n'utiliser que des pilotes libres), mais avec les versions antérieures (du moins, celles que j'ai connues ces quelques dernières années), si tu n'as pas besoin de DRI, elles seront fiables dans cette utilisation.
> tu confonds l'adaptabilité fonctionnelle et la fiabilité fonctionnelle
Dans le cas de Sid, et dans un cadre d'utilisation en clickodrome, oui, clairement : c'est ainsi parce qu'elle est plutôt à jour que je la trouve fiable pour cet usage.
Si je me sers de Etch pour ça, par contre, je vais gueuler que l'imprimante de ma mère ne fonctionne pas, que la 3D sur ma X800XL est lente comme la mort, qu'il n'y a pas kdesudo, qu'il n'y a pas ath5k et que je dois installer madwifi sur mon HTPC, ...
En revanche, pour mes serveurs, je préfère Etch, qui ne me force pas à télécharger des centaines de Mio par semaine (voire par jour)... même s'il y a des bugs qui me gênent, ils sont généralement moins fonctionnellement critiques pour un serveur, et je suis prêt à faire avec pour gagner la stabilité, qui apporte la facilité à maintenir les machines.
Ainsi, je me fie à Debian Stable pour les serveurs, et à Debian Sid pour les clickodromes (et, si : j'y place une grande confiance, car l'expérience m'a prouvé que je pouvais clairement le faire). L'une est stable, l'autre pas du tout.
Maintenant, pour rebondir sur l'adjectif "fonctionnel" pris tout seul, je le trouve bien adapté pour remplacer "fiable" dans mon explication précédente.
> La gravité est fiable : je lui fait confiance pour être encore là et pareil à elle même demain matin, même si elle n'est pas toujours des plus commode.
Oui : mais c'est aussi parce qu'elle est stable à une certaine distance de la grosse masse qui fait qu'on la subit, tant que cette grosse masse reste intacte. Donc, là encore, on parle de quelque chose de stable _et_ fiable (et même fiable parce que stable).
> Si ton système est stable, tu ne risque pas d'avoir de mauvaises surprises la prochaine fois que tu l'utilises (ni de bonnes d'ailleurs).
Si : mettons que tu lises sur le Net que tu peux brancher à chaud un moniteur sous X.org... tu essayes, mais pas de bol : tu es sous Etch, et tu peux te brosser.
Dès que tu veux faire quelque chose de nouveau avec du stable, tu cours vers les mauvaises surprises, car il y a de bonnes chances que ça n'y soient pas fiable.
> un système fiable fonctionne (bien ou moins bien)
Je veux bien...
> fonctionne toujours et fonctionne toujours de la même manière.
Bah non : ça, tu peux uniquement le dire avec assurance d'un système stable. Pour un système que tu juges fiable (parce que tu as confiance en lui, comme tu le soulignais), tout ce que tu peux dire, c'est qu'il a toujours fonctionné comme tu le voulais, ou au moins, assez pour que tu lui fasses confiance...
... mais pas forcément de la même manière : pour ce qui est du clickodrome, je trouve Sid bien plus fiable que toutes les autres saveurs de Debian, parce que l'expérience m'a appris que c'est celle qui fonctionne le mieux pour l'usage que j'en ai (pour les pilotes, les utilitaires comme kdesudo et cie ; par contre, pour le tri-écran, Etch est bien plus fiable). Pourtant, il y a, hors période de freeze de Testing, beaucoup de changements.
Ce que tu décris, c'est stable _et_ fiable, ce qui ne va pas toujours nécessairement de pair.
... et la raison pour laquelle je ne l'utilise toujours pas, y compris sur mon portable.
Bon, c'était censé être résolu dans sa 0.7, mais vu que c'est ce que semble embarquer cette distro, il y a de quoi en douter... dommage, le concept est pourtant sympa.
> comment peut-on qualifier de stable une distribution contenant beaucoup plus de bogues critiques que la version testing ?
Indice : en apprenant ce que signifie "stable"...
stable!=fiable
"Stable" signifie que les paquets ne sont plus censés bouger, (hors mises à jour de sécurité, sous Debian).
"Fiable" signifie que ça marche bien.
De toute évidence, quand quelque chose est figé (ie "stable"), au fur et à mesure, les gens veulent faire des nouvelles choses, peut-être pas implémentées, ou moins bien, que dans des versions plus récentes : la fiabilité de la version figée n'est alors pas meilleure (par contre, c'est 'achement plus facile à administrer : on installe, et tout marche à l'identique pendant des années).
Exemple : X.org sous Etch est un ante-diluvien 7.1, avec des vieux drivers moisis (même s'il permet, au moins, de gérer le tri-écran, ce qui ne marche plus depuis X.org 7.2...).
Il n'y a donc a priori pas de corrélation entre "stable" et "fiable"... ce sont des choses très différentes, a priori.
Maintenant, la plupart des gens parlent de l'état de stabilité de la fiabilité quand ils parlent de stabilité...
Si on veut troller sur cet abus de langage, ma théorie est que cette expression doit venir de gens qui utilisent des systèmes qui peuvent se casser la gueule d'un seul coup, sans plus prévenir que pour une quelconque raison tangible, et qui passent le temps entre deux crashs à se dire "jusqu'ici, tout va bien ; pour l'instant, ça ne se casse pas la gueule ; c'est stable".
NB : Lenny est peut-être sortie, mais elle est toujours Testing, et pas Stable (à ce moment, Squeeze et toute les suivantes sont déjà sorties). Se taper une Sid qui est peu ou prou figée étant déjà un peu chiant (d'autant que ça commence à bien laguer derrière ce qui se fait), ce ne serait pas du luxe d'éviter de se coltiner aussi des annonces bidons comme le titre de ce journal...
[^] # Re: RE:
Posté par Aefron . En réponse au journal IPv6 et anonymat. Évalué à 2.
[^] # Re: RE:
Posté par Aefron . En réponse au journal IPv6 et anonymat. Évalué à 3.
Ouaip, via un "hidden service" (serveur caché) [1] ;)
Par contre, de ce point de vue, faudra faire gaffe à IPv6 : si quelque chose dans le serveur (un message d'erreur ou quelque chose de ce genre) recrache son adresse, et que celle-ci n'est pas une adresse non routable publiquement (ce sera toujours possible en IPv6, bien sûr... mais avec la pléthore d'adresses dispo, il sera tentant pour beaucoup de ne pas s'emmerder avec des proxies & co, et d'allouer une adresse publique à toutes les machines [ce que je n'ai aucune intention particulière de faire, quand mon tour viendra]), des informations sur la location IP du serveur pourront fuiter...
[1] http://www.torproject.org/docs/tor-hidden-service.html.en
[^] # Re: Tant qu'à faire
Posté par Aefron . En réponse au journal Grosse flemme et file system.... Évalué à 2.
C'est ce que je fais maintenant : mes HDD externes en ext3 (1To en FAT32, l'idée de faire du checkdisk souvent me faisait un peu perler du front), et un liveCD dans la pochette de transport de chaque HDD...
... et ça me va à la perfection. De toute façon, chez moi, il n'y a que des OS libres (ce qu'il y a de plus en plus en dehors de chez moi, d'ailleurs)... et si les gens chez qui je vais ne sont pas interopérables avec les technos libres, et surtout, ne sont pas prêts à un reboot (alors que bon, en général, ils ont l'habitude :p), bah tant pis : c'est comme le flash - je m'en fous ; le rapport gain/perte est bien mieux comme ça pour moi.
[^] # Re: IPv6 chez free ?
Posté par Aefron . En réponse à la dépêche L'IPv6 débarque chez FDN. Évalué à 3.
Oh, ça dépend... perso, les modes routeurs de la plupart des boîtes FAI, ils me saoulent d'une force !
... moi qui demande généralement à une box de tout renvoyer vers un routeur (rapide, non bloaté et propre... à moi, où aux gens qui me demandent d'en installer un), si je pouvais simplement désactiver cette saloperie de mode routeur sur les livebox (putains de boîtes sagem !) ou les neufbox (du grand art : on ne peut même pas NATer de 1 à 65535 sans se prendre la tête : certains ports sont réservés, peut-être pour la TV et le tel)... bon, les freebox, ça, ça va, c'est facile à bridger...
Les seuls intérêts que je vois aux boîtes FAI, ce sont le tel et la TV : sauf que je ne me sers ni de l'un, ni de l'autre ; et c'est pour ça que j'ai mes routeurs derrière un simple modem ADSL2+ (qui me fait entre autres gagner 10-15ms de ping, le tout bootant et se connectant beaucoup plus vite que l'immonde livebox, et le tout étant sous mon contrôle).
[^] # Re: Merciiiiiiiiiiiiiiiiiiii !
Posté par Aefron . En réponse à la dépêche L'IPv6 débarque chez FDN. Évalué à 3.
... et de la "dual-stack" où il faut ;)
[^] # Re: Tuer le spam à la racine!
Posté par Aefron . En réponse à la dépêche Reprise de Dspam par la communauté. Évalué à 5.
Au niveau IP, si... ce qui manque, c'est le reverse DNS (IP fixe, ou pas - ça ne change rien sur le fond)...
... ce qui montre bien que le filtrage des IP qui ont un reverse non délégué par le FAI au client (ie les reverse en blabla.abo.blabla.truc) est un emplâtre sur une jambe de bois...
... puisque cette "pratique" repose sur le simple décret, majoritaire, que "les connexions des particuliers n'ont pas à faire tourner des serveurs"...
Dire qu'on ne peut pas laisser les particuliers émettre des mails parce qu'ils n'ont pas de reverse DNS propre, c'est présenter les choses sous un drôle d'ordre... S'ils n'ont pas de reverse DNS propre, c'est justement parce que les FAI ne semblent majoritairement pas intéressés par l'utilisation de serveurs sur les lignes à bas-coût (et encore... par exemple, les neurones fumeux de chez Orange ont décidé de ne même pas donner la délégation du reverse sur les forfaits pro... apparemment, ils arguent que ce n'est pas gérable pour les particuliers - ça fait peur).
[^] # Re: Si j'ai bien compris...
Posté par Aefron . En réponse à la dépêche Sortie de LemonLDAP::NG 0.9.3. Évalué à 2.
J'imagine que je vais devoir modifier le schéma pour ajouter les infos dont j'ai besoin, et c'est ce qui me fait un peu peur (pas beaucoup d'expérience LDAP)... mais j'en ai un peu marre de définir mes variables et classes CFEngine dans des fichiers textes, et j'ai de plus en plus besoin de quelque chose comme un annuaire (a priori, ça me paraît plus adapté qu'un MySQL ou assimilé)...
Par contre, pas grand monde n'a l'air de faire ça (en tout cas, avec CFEngine... Puppet inclue de quoi gérer une conf centralisée dans LDAP ; mais trop de choses me gênent par ailleurs dans Puppet)...
> Cela sort toutefois du cadre de LemonLDAP::NG
Certes : LemonLDAP::NG est néanmoins une raison de plus de me repencher sur LDAP... et je dois avouer que son concept est séduisant.
[^] # Re: Tant qu'à faire
Posté par Aefron . En réponse au journal Grosse flemme et file system.... Évalué à 3.
# Si j'ai bien compris...
Posté par Aefron . En réponse à la dépêche Sortie de LemonLDAP::NG 0.9.3. Évalué à 2.
> De plus, toutes les applications Web utilisant des protections Apache (par exemple par htaccess) sont nativement compatibles
Donc, si j'ai bien compris, ça permet (outre le SSO) d'unifier les méthodes d'identification web, quelles qu'elles soient entre LemonLDAP::NG et le serveur sur lequel on souhaite s'authentifier ? Par exemple, forcer l'utilisation d'un certificat de smartcard pour accéder à un service à la base "protégé" par htaccess... Intéressant.
D'autant que suis justement en train de me repencher sur LDAP - j'avais arrêté de le tester il y a un moment en me disant que le faible nombre d'utilisateurs que j'ai inhibait ses bénéfices, mais en fait, vu le nombre de machines que je finis par avoir avec les conteneurs OpenVZ/Vserver, j'ai maintenant dans l'idée de m'en servir comme base de données que mon CFengine maître utiliserait pour personnaliser les fichiers qu'il exporte aux clients, en faisant gaffe à gérer le cas d'indisponibilité du LDAP, et afin de répartir les données dans le réseau sans forcément les dupliquer à leur définition.
Par exemple, savoir sur quelles machines tourne quoi et à partir desquelles autres elles peuvent être jointes est utile pour configurer iptables sur les routeurs, pour configurer les serveurs, _et_ pour configurer les clients - or tant que le CFengine maître est le seul à connaître toutes ces données, rangées proprement dans une base de données LDAP, les ACL LDAP ne deviennent pas trop un enfer (par rapport à si je déléguais la recherche aux clients CFEngine)...
... pour ce qui est des ACL CFEngine, ie les "grant" du cfservd.conf, je pense "simplement" essayer de les fabriquer à partir des FDQN des hôtes (en créant autant de répertoires exportés que d'hôtes, et où seront personnalisés des fichiers de conf génériques, en fonction de certaines classes, assignées dans l'annuraire), et de LDAP...
Je n'ai pas encore trop réfléchi à comment bénéficier, au passage, de LDAP pour les authentifications (vu que ce n'est pas mon but initial), mais j'ai dans l'idée que je n'aurai pas trop de mal à trouver une place dans cet ensemble à LemonLDAP, entre autres.
# Les logs
Posté par Aefron . En réponse au message Xorg : Extraction d'infos pour résolution de bug. Évalué à 5.
... néanmoins, les logs de X.org sont asynchrones par défaut (ie ils ne sont pas écrits dès que quelque chose arrive, mais un peu après, en groupe, pour éviter de bouffer des perfs... je sais qu'il y a une option pour activer les logs synchrones, pour diagnostiquer quand on ne peut même plus joindre la machine par SSH, genre, X.org qui fait "hard-locker" le noyau, mais je ne m'en souviens plus). Aussi, attends un peu qu'ils aient le temps d'être écrits, en croisant les doigts pour qu'il y ait assez de temps CPU pour le faire dans des délais raisonnables.
[^] # Re: upside-down
Posté par Aefron . En réponse au message dual head. Évalué à 5.
À la base, pour l'instant, la section ServerLayout n'est plus censée être utilisée... et xinerama non plus : toute la gestion du multi-écran est censée passer par RandR, qui ne prend pas en compte le multi-cartes pour l'instant (ie, quand c'est marche, c'est un heureux hasard ; je ne connais pas le driver Sis, mais s'il ne supporte pas RandR, ça pourrait expliquer que ça passe, avec quelques étrangetés - chez moi, avec plusieurs Radeon, ça plante au lancement ; et l'Intel intégrée sur une de mes mobos ne peut pas marcher en même temps que le port PCI-E, ce qui a jusqu'ici négativement conclu les essais qui m'intéressaient).
Pour le multi-X.org (ce qui est censé permettre le ServerLayout), il paraît que RedHat va travailler dessus pour Fedora 11 ou 12... Par contre, je ne sais pas si ça marchera avec plusieurs cartes dès le début (le multi-cartes, ça doit venir avec les GPU objects, qui doivent arriver avec une lointaine et future version de RandR... et il n'y aura pas besoin de multi-cartes pour implémenter le multi-X.org, puisque ça pourra se faire sur deux sorties d'une même carte, et sera par exemple extrêmement utile pour les HTPC et autres écrans dédiés aux medias).
Malheureusement, il reste beaucoup de boulot sur le multi-écran moderne et avancé dans X.org... et il y a sur cette route beaucoup de régressions par rapport à l'ancienne manière de faire, tout à la main, compliquée, mais où beaucoup de choses étaient possibles (même si ça supposait que Xv, DRI, et cie ne marchaient plus forcément).
Sinon, avec plusieurs écrans, sur plusieurs machines, mais pour un même bureau : DMX... il paraît qu'il a bien progressé, et c'est sur la liste des choses que je dois trifouiller.
[1] http://wiki.debian.org/XStrikeForce/HowToRandR12
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420419#27
[^] # Re: vendredi
Posté par Aefron . En réponse au journal Ubuntu dans le New York Times. Évalué à 2.
D'autant que les zones non signées, c'est tout sauf ce qui manque...
DNSSEC, pourquoi pas, mais c'est loin d'être prêt (quid de la distribution des clés ? quid du dernier saut jusqu'au résolveur du client ? quid de la notification au client que les signatures ne sont pas dispo ou fausses ?)... alors, parler de son adoption...
Pas que je ne me lamente pas du pathos du DNS actuel... mais les choses ne sont pas finalisées au niveau des serveurs, et encore moins au niveau des clients... m'est avis qu'on n'est malheureusement pas prêt de profiter un service de noms sécurisé (même localement)...
[^] # Re: vendredi
Posté par Aefron . En réponse au journal Ubuntu dans le New York Times. Évalué à 4.
Ce n'est pas avec du malheureux MIPS à quelques centaines de MHz et assimilés qu'on va le faire (déjà que le filtrage du réseau local à 100MBps stresse bien un WRT54G)...
Non, 100MBps, ça le ferait déjà bien (tant que ce serait illimité, symétrique, IPv6 à base de /48 alloués, et avec DNS inverses dans ip6.arpa comme on veut pour toutes les adresses :p).
[^] # Re: Presque complet....
Posté par Aefron . En réponse à la dépêche Publication d'un micrologiciel libre pour les cartes Broadcom 4306 et 4318. Évalué à 2.
... ni évident à percer, ni à reboucher :(
Bon, de toute façon, je ne suis plus dans ce logement pour très longtemps, et il faut quand même avouer qu'il y a eu de gros progrès dans le wifi libre depuis les quelques années où j'en utilise (la carte du HTPC fonctionne bien avec ath5k, et j'ai réussi à avoir une pas trop mauvaise connexion avec b43 pour l'AP... j'attends que les kernels récents soient patchés pour Mips sous OpenWRT pour espérer avoir quelque chose d'utilisable, et me débarrasser du dernier logiciel proprio qui tourne sur mes CPU... et si en plus on peut espérer à terme un firmware, c'est Byzance).
Bon, après, si le 802.11n pouvait se finaliser, et qu'on en ait un support libre, alors là :)
[^] # Re: Presque complet....
Posté par Aefron . En réponse à la dépêche Publication d'un micrologiciel libre pour les cartes Broadcom 4306 et 4318. Évalué à 5.
Mon HTPC est connecté au serveur NFS par wifi (pas le choix : locataire, donc pas de trous pour faire passer du RJ45). Il est aussi en dual-screen avec un petit LCD qui permet par exemple de chercher sur le web dans le salon.
Avec du QOS, je pourrais m'assurer qu'une recherche sur le web ne bouffe pas la bande passante nécessaire aux videos...
J'imagine que ça pourrait aussi être utile avec les VAP (Point d'Accès Virtuels), en permettant de favoriser certains SSID par rapport aux autres...
Avec la ridicule bande passante du 802.11g, ce serait tout sauf du luxe, et ça fait un moment que j'y pense.
[^] # Re: Problèmes réseau
Posté par Aefron . En réponse à la dépêche Test de Fedora 10 Cambridge. Évalué à 2.
[^] # Re: Problèmes réseau
Posté par Aefron . En réponse à la dépêche Test de Fedora 10 Cambridge. Évalué à 2.
... ça revient à ce que je disais quand je parlais de travail de cochon ; et ça, ça incombe à l'admin.
Si tu alloues un sous-réseau pour les machines dont tu n'es pas maître, n'importe qui pourra s'y configurer l'adresse de quelque serveur que ce soit en dehors de ce sous-réseau, ça coincera au niveau d'un routeur entre ce sous-réseau et tes autres, et il n'arrivera pas à avoir une connexion IP qui-va-bien.
Au pire, l'emmerdeur pourra prendre une adresse déjà allouée à un autre invité, et "perturber" le sous-réseau que tu leur aura alloué... le reste du réseau ira très bien quand même. Après, si les invités qui se font emmerder utilisent des services mal sécurisés pour faire des choses confidentielles, qui plus est sur un réseau auquel ils n'ont aucune raison de faire confiance, et que des informations à eux fuient, ça leur fera la bite, et leur fera prendre de bonnes habitudes...
Quant au cas où le sous-réseau est utilisé par de multiples personnes, que les machines sont maîtrisées, et qu'on craint qu'un glandu se serve de NM pour s'allouer une IP fixe et foutre la merde... bah, les machines étant maîtrisées, on n'installe pas NM, et il faut alors être root pour toucher à la conf réseau de la machine... et hop.
N'en reste pas moins qu'en tout point de cette situation, le problème de sécurité est humain (admin ou invités)... mais avec NM ou pas pour gérer les IP fixes, les emmerdeurs pourront quand même s'en configurer une s'ils se ramènent avec leur machine (et dans le cas contraire, ce n'est pas aux utilisateurs de toucher à la conf IP - aussi, quelque chose qui le leur permet n'a rien à y foutre) ; ce qui n'est pas un problème si le réseau est conçu proprement.
[^] # Re: Indice...
Posté par Aefron . En réponse au journal Debian lenny est sortie.... Évalué à 2.
La fonctionnalité, c'est par contre relatif : ça dépend de ce qu'on cherche. Mais je suis d'accord sur le fait que c'est plus objectif que la notion de fiabilité.
Sur le fond, ce que j'estime être non corrélé à la stabilité, c'est aussi bien la fiabilité que la fonctionnalité. Pour passer outre l'exemple qui implique une documentation en ligne, plus généralement, si j'installe une Debian Stable sur une machine que je ne connais pas, je sais que je cours le risque que ça ne supporte pas tout ce dont il y a besoin : il risque de manquer des fonctionnalités, et je ne m'y fie donc pas.
Avec Testing, et Sid, j'ai la plus grande confiance quant à ce que ça ne parte pas en sucette, tout en m'apportant les fonctionnalités désirées. Et l'expérience m'a prouvé que j'avais raison de faire comme ça : j'utilise Sid (station de travail et portable) et Testing (HTPC) au quotidien, j'ai installé plein de Testing à plein de monde (sauf quelques cas particuliers où, puisque ce sera moi qui maintiendra la machine, j'ai mis de la Debian Stable), et il est rarissime qu'on me demande de l'aide (et en général, ce n'est pas pour grand chose).
[^] # Re: Absurde.
Posté par Aefron . En réponse au journal Debian lenny est sortie.... Évalué à 9.
Ça sert à ceux qui n'arrivent pas à faire quelque chose : une fois le bug rapporté, il y a une trace qu'ils ne sont pas les seuls dans cette galère.
Ça sert aussi aux mainteneurs à être au courant de problèmes, et les pousse à se renseigner sur l'état du bug chez les développeurs du projet en amont... voire, à leur transmettre.
Souvent, un bug est marqué en "won't fix" (ne sera pas résolu) ; mais en lisant la discussion sur le rapport, on trouve souvent un "réglé dans telle ou telle version", ce qui est de première utilité aux utilisateurs et administrateurs.
C'est peut-être de la bureaucratie que de rapporter des bugs pour des distros figées, mais c'est tout sauf inutile.
[^] # 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.
[^] # Re: Problèmes réseau
Posté par Aefron . En réponse à la dépêche Test de Fedora 10 Cambridge. Évalué à 4.
En fait, je trouve pour le moins incongru d'avoir développé avec le DHCP en premier, alors que l'utilisation des IP fixes me paraît un cas plus élémentaire. Si les IP fixes sont gérées, au moins, ça marche pour tout le monde - avec DHCP, bah non, faut un démon ou un relai DHCP, donc un truc en plus. Je veux bien que NM soit fait pour gérer le réseau en userland, et que ceux qui ont le plus de mal à le faire soit ceux qui utilisent DHCP, probablement même sans en avoir conscience, mais à mon avis, cet ordre de développement revient à mettre la charrue avant les bœufs.
Du coup, je fais avec ifplugd, les pre/post-up/down, guessnet, et cie, et ça marche très bien... mais je n'ai pas de jolie GUI pour montrer la puissance de la configuration réseau aux gens.
Après, je n'ai rien contre faciliter la configuration de Linux, via NM, ou RandR... c'est plutôt la manière de s'y prendre, en ignorant, voire en cassant, la configuration basique (merci RandR : depuis lui, plus de multi-GPU, donc plus de tri-écran... et je connais des gens qui ne se mettront pas à Linux tant que le multi-head ne marchera pas... d'autant que RandR et le multi-écran non cloné, ça nécessite encore la plupart du temps de rajouter une ligne "Virtual" dans le xorg.conf, donc, grandr est mignon, mais de toute façon pas adapté pour de nombreux usages).
J'estime que c'est une manière de s'y prendre à-la-bling-bling : ça marche plus facilement, mais il ne faut pas trop gratter le vernis... j'ai vraiment du mal avec cette manière de faire.
[^] # Re: Indice...
Posté par Aefron . En réponse au journal Debian lenny est sortie.... Évalué à 2.
Non : l'état des paquets est tout autant stable, donc il y aurait grand mal à s'éloigner d'un système stable en en utilisant un... par contre, il pourra être plus difficile d'en faire une utilisation fiable.
Avec le même exemple de X.org 7.1 : tu apprends sur le Net que X.org (sans précision) fait du branchage d'écran à chaud. À partir de la 7.2, certes, c'est vrai, et tu peux te fier à cette information pour être exacte, et à X.org pour brancher tes écrans à chaud. Mais pas de chance : pas avec la 7.1. Tu ne peux pas te fier à cette dernière pour gérer le branchage à chaud : dans ce cas particulier, elle n'est pas fiable, bien que stable.
En revanche, si tu veux brancher deux GPU, tu ne peux pas te fier à X.org>7.2 pour le faire (à compter n'utiliser que des pilotes libres), mais avec les versions antérieures (du moins, celles que j'ai connues ces quelques dernières années), si tu n'as pas besoin de DRI, elles seront fiables dans cette utilisation.
> tu confonds l'adaptabilité fonctionnelle et la fiabilité fonctionnelle
Dans le cas de Sid, et dans un cadre d'utilisation en clickodrome, oui, clairement : c'est ainsi parce qu'elle est plutôt à jour que je la trouve fiable pour cet usage.
Si je me sers de Etch pour ça, par contre, je vais gueuler que l'imprimante de ma mère ne fonctionne pas, que la 3D sur ma X800XL est lente comme la mort, qu'il n'y a pas kdesudo, qu'il n'y a pas ath5k et que je dois installer madwifi sur mon HTPC, ...
En revanche, pour mes serveurs, je préfère Etch, qui ne me force pas à télécharger des centaines de Mio par semaine (voire par jour)... même s'il y a des bugs qui me gênent, ils sont généralement moins fonctionnellement critiques pour un serveur, et je suis prêt à faire avec pour gagner la stabilité, qui apporte la facilité à maintenir les machines.
Ainsi, je me fie à Debian Stable pour les serveurs, et à Debian Sid pour les clickodromes (et, si : j'y place une grande confiance, car l'expérience m'a prouvé que je pouvais clairement le faire). L'une est stable, l'autre pas du tout.
Maintenant, pour rebondir sur l'adjectif "fonctionnel" pris tout seul, je le trouve bien adapté pour remplacer "fiable" dans mon explication précédente.
> La gravité est fiable : je lui fait confiance pour être encore là et pareil à elle même demain matin, même si elle n'est pas toujours des plus commode.
Oui : mais c'est aussi parce qu'elle est stable à une certaine distance de la grosse masse qui fait qu'on la subit, tant que cette grosse masse reste intacte. Donc, là encore, on parle de quelque chose de stable _et_ fiable (et même fiable parce que stable).
Tout n'est pas comme ça pour autant.
[^] # Re: Indice...
Posté par Aefron . En réponse au journal Debian lenny est sortie.... Évalué à 4.
Si : mettons que tu lises sur le Net que tu peux brancher à chaud un moniteur sous X.org... tu essayes, mais pas de bol : tu es sous Etch, et tu peux te brosser.
Dès que tu veux faire quelque chose de nouveau avec du stable, tu cours vers les mauvaises surprises, car il y a de bonnes chances que ça n'y soient pas fiable.
> un système fiable fonctionne (bien ou moins bien)
Je veux bien...
> fonctionne toujours et fonctionne toujours de la même manière.
Bah non : ça, tu peux uniquement le dire avec assurance d'un système stable. Pour un système que tu juges fiable (parce que tu as confiance en lui, comme tu le soulignais), tout ce que tu peux dire, c'est qu'il a toujours fonctionné comme tu le voulais, ou au moins, assez pour que tu lui fasses confiance...
... mais pas forcément de la même manière : pour ce qui est du clickodrome, je trouve Sid bien plus fiable que toutes les autres saveurs de Debian, parce que l'expérience m'a appris que c'est celle qui fonctionne le mieux pour l'usage que j'en ai (pour les pilotes, les utilitaires comme kdesudo et cie ; par contre, pour le tri-écran, Etch est bien plus fiable). Pourtant, il y a, hors période de freeze de Testing, beaucoup de changements.
Ce que tu décris, c'est stable _et_ fiable, ce qui ne va pas toujours nécessairement de pair.
[^] # Re: Problèmes réseau
Posté par Aefron . En réponse à la dépêche Test de Fedora 10 Cambridge. Évalué à 2.
... et la raison pour laquelle je ne l'utilise toujours pas, y compris sur mon portable.
Bon, c'était censé être résolu dans sa 0.7, mais vu que c'est ce que semble embarquer cette distro, il y a de quoi en douter... dommage, le concept est pourtant sympa.
# Indice...
Posté par Aefron . En réponse au journal Debian lenny est sortie.... Évalué à 9.
Indice : en apprenant ce que signifie "stable"...
stable!=fiable
"Stable" signifie que les paquets ne sont plus censés bouger, (hors mises à jour de sécurité, sous Debian).
"Fiable" signifie que ça marche bien.
De toute évidence, quand quelque chose est figé (ie "stable"), au fur et à mesure, les gens veulent faire des nouvelles choses, peut-être pas implémentées, ou moins bien, que dans des versions plus récentes : la fiabilité de la version figée n'est alors pas meilleure (par contre, c'est 'achement plus facile à administrer : on installe, et tout marche à l'identique pendant des années).
Exemple : X.org sous Etch est un ante-diluvien 7.1, avec des vieux drivers moisis (même s'il permet, au moins, de gérer le tri-écran, ce qui ne marche plus depuis X.org 7.2...).
Il n'y a donc a priori pas de corrélation entre "stable" et "fiable"... ce sont des choses très différentes, a priori.
Maintenant, la plupart des gens parlent de l'état de stabilité de la fiabilité quand ils parlent de stabilité...
Si on veut troller sur cet abus de langage, ma théorie est que cette expression doit venir de gens qui utilisent des systèmes qui peuvent se casser la gueule d'un seul coup, sans plus prévenir que pour une quelconque raison tangible, et qui passent le temps entre deux crashs à se dire "jusqu'ici, tout va bien ; pour l'instant, ça ne se casse pas la gueule ; c'est stable".
NB : Lenny est peut-être sortie, mais elle est toujours Testing, et pas Stable (à ce moment, Squeeze et toute les suivantes sont déjà sorties). Se taper une Sid qui est peu ou prou figée étant déjà un peu chiant (d'autant que ça commence à bien laguer derrière ce qui se fait), ce ne serait pas du luxe d'éviter de se coltiner aussi des annonces bidons comme le titre de ce journal...