Pour le sources.list, oui, je le connais (le wiki d'OpenVZ est d'ailleurs très bien)...
Le souci, c'est que je voulais me faire un CD d'installation customisé de Debian qui m'installe déjà tout ce qu'il me faut, y compris le kernel et les utilitaires packagés par Thorsten...
... or debian-cd/simple-cdd ne gèrent que les composants main, contrib, et non-free (c'est hardcodé dans debian-cd : pas le choix)... et du coup, le composant openvz, bah, pas moyen de l'inclure comme ça...
Je pourrais faire avec FAI, mais je ne le connais pas bien, il n'est à la base pas prévu pour faire de CD (même si je sais très bien que ça se fait), et surtout, il n'est pas spécialement prévu pour l'interactivité (je veux au moins choisir mes paramètres réseau, et le HDD à formater... plus quelques autres binioucs, si je me mets à packager des conteneurs pour les installer)... Je pourrais aussi télécharger les .deb à la mimine, mais je perdrais par exemple l'avantage d'installer directement linux-image-openvz-2.6-686, et il faudrait mettre la référence exacte de la révision du kernel à la main...
Du coup, je vais pour l'instant au plus simple, et je pars plutôt sur http://download.openvz.org/debian (seulement du kernel, et pas avec le fichier de config Debian, comme les fza de Thorsten... l'enfin, pour le moment, tant pis) que vers http://download.openvz.org/debian-systs (qui est un miroir de celui que tu donnes, par les gars de chez OpenVZ)... d'autant que j'ai essayé de trouver une adresse mail pour joindre Thorsten, et je me suis même inscrit sur le forum OpenVZ pour lui envoyer un message privé : en vain ; il ne les accepte pas... bon, j'ai quand même fini par trouver son mail en fouillant un peu : faudra que je pense à le contacter... En attendant, mon CD d'installation d'une Debian OpenVZée marche bien quand même.
A priori, les efforts se concentrent sur l'ajout dans le noyau de patches pouvant génériquement servir aux solutions de virtualisation/conteneurs, plutôt que l'intégration de solutions complètes, pour l'instant...
... une solution complète sera probablement intégrée à terme, mais pour l'instant, comme le dit patrick_g, l'heure est à un "long travail visant à masquer toutes les ressources globales du noyau (systèmes de fichiers, identifiants des processus, interfaces réseaux etc.) derrière une couche d'abstraction afin de pouvoir gérer des conteneurs séparés".
Chacun y vient petit à petit, comme chez FreeBSD, avec la virtualisation de la pile réseau [1]
D'ailleurs, à ce titre, les développeurs de solutions de conteneurs participent à patcher le noyau petit à petit, en tout cas, chez OpenVZ [2] (j'imagine qu'ils le font aussi chez VServer), que je découvre après 6 mois de VServer, que je trouvais déjà très bien, mais qui est bien moins polyvalent au niveau réseau :
- VServer isole des interfaces de l'hôte, en les faisant discuter via le loopback, ce qui empêche de laisser le loopback grand ouvert, si on veut firewaller entre les conteneurs, et ce qui empêche aussi d'avoir un loopback dans le conteneur (on est forcé de rechercher toutes les occurences de 127.0.0.1 et de les remplacer par du localhost, qu'on a manuellement fait correspondre à l'adresse IP du conteneur... voire de forcer manuellement les services sur cette adresse)...
- OpenVZ virtualise le dialogue réseau en faisant intervenir une interface virtuelle qui permet de réaliser le routage entre les conteneurs, qui disposent donc d'un loopback à eux... a priori, ils sont chacun sur un /32 en point à point avec l'interface virtuelle, mais on peut leur donner un peu plus de capacités, pour qu'ils aient leurs propres iptables, routes, qu'on puisse les bridger avec le reste, par exemple pour mettre une sonde d'IDS en promiscuous, qu'ils puissent avoir du broadcast, et même qu'ils gèrent une interface réseau physique, sans que l'hôte n'y ait accès, voire même, qu'ils aillent jusqu'à router eux-aussi...
... sur ce point OpenVZ roxorise des famille-ours ! Dommage que le kernel binaire et l'outil de migration (enfin, ça, encore... faut avoir assez de machines, pour ça... mais c'est assez classe à voir [3]) ne soient pas directement packagés dans Debian... et que le miroir des kernels fza soit dans un composant "openvz" bizarre (et pas dans un "main"), ce qui fait qu'on ne peut pas l'inclure via debian-cd/simple-cdd...
En tout cas, si on n'a pas besoin de faire tourner plusieurs kernels, les conteneurs, c'est génial.
Bah, comme je disais : chacun son truc... moi, vivre en couple, ça ne me tente pas - mais alors, vraiment pas, du tout... je préfère le concept d'amantes : je me lasse bien moins vite... d'ailleurs, j'ai même vraiment le besoin de me retrouver seul, chez moi, pénard, assez souvent.
... et puis, pour moi, le physique, entre autres, a vraiment de l'importance, ne serait-ce que sur la première attirance lors de la rencontre - il y a des physiques sur lesquels je craque typiquement (ie, une forte inclinaison : ni plus, ni moins), et d'autres tout à l'inverse... mais encore une fois, chacun son truc : le seul qui soit vraiment débile, c'est l'invocation d'une quelconque normalité, ce qui sous-tend à une universalité, dans les goûts.
Et puis, tant que les gens se sentent bien comme ils sont, sans venir chercher des poux aux autres, ils peuvent bien faire ce qu'ils veulent, et avoir l'allure qu'ils veulent : c'est vraiment dans les derniers de mes soucis...
... on parle de laquelle, normalité ? Celle à l'état naturel, où on va avoir moins tendance à grossir et plus à se muscler ? Celle de ceux qui préfèrent les grosses ? Celle de ceux qui préfèrent les maigres ? Celle de ceux qui préfèrent les grandes ou celle de ceux qui préfèrent les petites ? Celle des médecins, ou celle des croque-morts ?
Non, mais franchement : chacun son truc... qu'est-ce qu'on en a à foutre, de la normalité en matière de goûts : personnellement, je préfère les filles très minces (mes potes disent maigres), plutôt petites (alors que je suis plutôt grand, ie >1,90m... les petites, c'est bien, c'est plus maniable :) ), brunes plutôt que blondes, et beaucoup plus avec des petites fesses qu'avec des gros nichons... et alors ? Si je compare avec mon entourage, j'aurais plutôt tendance à ne pas être dans la norme... et bien tant mieux : ça en fait plus, juste pour moi, comme j'aime bien !
Euh... pour le deuxième, on peut écrire des machines physiques en java ?
En fait, puisque c'est du P2P, chaque utilisateur connecté au réseau fait office de client (il va pomper des trucs ailleurs) et de serveur (des gens d'ailleurs viennent y pomper des trucs)...
... et comme c'est du P2P de nouvelle génération, pas le moindre serveur centralisé (comme ceux où on met le torrent à l'origine, ou les serveurs de recherche d'emule&cie, qui ne sont utiles que quand un réseau décentralisé parallèle comme Kad n'a pas encore bootstrapé)...
Et si on veut se simplifier la vie avec le firewalling et la bande passante, on met ça sur une machine, sans clickodrome tant qu'à faire, qui fera serveur de proxy Freenet pour son réseau local... comme on peut le faire pour mldonkey, amule et tous les autres...
Bon, après, Freenet, c'est rigolo, mais c'est encore lent, c'est en java (et je n'ai pas encore opensdk dans le conteneur où j'ai Freenet : vivement Lenny, ou le backport, si Lenny venait à tarder), et surtout, le mode de mise à jour est horrible (peu de distros le distribuent, et il me semble qu'ils n'ont pas particulièrement l'intention d'être distribués tant qu'ils ne considèrent pas eux-mêmes Freenet comme plus mature) - du coup, avant, c'était via un script à-la-rache, et maintenant, c'est carrément via Freenet : bof (m'enfin, dans un conteneur, au moins, le risque est ipso facto un minimum contenu)...
Cela dit, ça a le mérite d'exister et de se développer : comme Tor et GnuNet, d'ailleurs.
D'autant que certains trucs sont prévus pour fonctionner avec un export de l'affichage...
... parce que bon... configurer mon Mythbackend sans exporter le clickodrome, soit ça me force à avoir un X.org complet dans un des conteneurs de l'un de mes serveurs (beurrrk), soit à mettre les mains dans une base mysql (beurrrk)...
D'autant qu'il y a quelques mois (et même encore maintenant), le driver libre pour les X1xxx, il était tout sauf prêt à être utilisé...
... en outre, le mode vesa, il y a mieux, mais ça dépanne bien : je connais au moins deux personnes qui s'en servent, pour cause de trop de problèmes avec le(s) driver(s) libre(s), et aussi par refus d'utiliser le blob... [ahemmm] : ils ont des nvidia...
Perso, je fais peu de 3D (essentiellement : MythTV), mais je fais du multi-écran partout, et depuis longtemps : et je ne suis pas près de prendre autre chose que de l'ATI à driver libres (on verra quand Intel sortira du GPU en cartes à brancher)...
Euh... faudra me dire comment tu fais l'interconnexion entre des sites très distants, et même, comment tu finis par ête relié à internet, si tu te passes complètement d'eux...
... autant il est stupide de pousser à ne pas partager sa connexion (d'ailleurs, si quelque chose l'empêche, ce seraient plus les conditions d'abonnement que la loi... cette dernière étant juste assez vicieuse pour fortement décourager les hotspots ouverts, ce qui est crétin, certes, certes), autant tomber sur un hotspot quand on a besoin du net est pratique, autant il est résolument irréaliste de croire qu'on va remplacer les backbones des FAI par des millions de fonera...
... entre un kibboutz avec mes voisins, lent, limité (vu le nombre de protagonistes), avec une architecture réseau tenant du château de cartes bricolé à-la-rache, et internet, le choix est vite vu.
> Concernant ta borne wifi tu peut par exemple lui mettre une horloge qui coupe le courant pendant la nuit ou toutes autre période ou il est peut probable que tu utilises ta connexion.
C'est là que je me dis qu'avec une Squeezebox (version 2) en guise de radio-réveil wifi (pour cause de location... sinon, elle serait bien sûr en ethernet), je suis quand même un gros geek...
... même quand je dors, je ne peux pas couper le wifi, vu que j'aime bien savoir l'heure quand je me réveille, même avant que le réveil ne se soit manifesté... et que j'ai besoin du wifi pour ça...
Bah quoi ? C'est ultra-kitsch, et dans le genre, il y a du brio : drapeau sudiste omniprésent, contrebande de whisky par défiance envers l'état oppressant, au motif que ce dernier est plus jeune que la tradition de l'alambic chez les Dukes, tatasses en short ras-la-fouffe (les plus attirantes pour tous les protagonistes semblant nécessairement être des cousines), flics débiles à souhait, vieux obèses, à la limite de l'impotence...
Certainement que c'est une oeuvre ! Un monument, même...
Bah, des TV 16/9, ça fait plus de dix ans que j'en ai...
... et mon format préféré, c'est 4:3 pour les émissions nativement en 4:3 et 16:9 pour les émissions en 16:9...
Sorti de ça, je m'en fous... mais si tu croppes comme un fou pour faire croire que le 4:3 est nativement 16:9, tu fous en l'air le cadrage : les têtes des protagonistes sont coupées ou le plan est incomplet... sans compter la perte de résolution verticale qui devra être davantage scalée... bref, c'est vraiment du très grand n'importe quoi, de faire ça.
Franchement, ça ne me viendrait pas à l'idée de regarder une émission nativement 4:3 en zoomant... oui, dans ce cas, je préfère largement le ratio d'affichage 4:3. Le 16;9 pour le 16:9, quitte à bousiller l'image quand ça n'en est pas (et ça arrive très souvent : plein de films sont plus larges que le 16:9, et beaucoup de choses intéressantes, même si pas forcément neuves, sont en 4:3), c'est parfaitement ridicule.
J'en connais aussi des comme ça... J'ai l'impression qu'ils veulent rentabiliser chaque pixel acheté, ou un truc du genre...
... pourtant, même un gamin de deux ans est censé comprendre que "Non ! un rectangle ne s'habitue pas à être un carré, pas plus qu'un rond un triangle, ou autres choses élémentaires"... je crois même que les chimpanzés y arrivent très bien aussi...
C'est désolant... d'autant plus que c'est très loin de ne concerner que des vieux qui n'y voient plus goutte, ou qui ont connu la guerre, les privations, et n'aiment pas gâcher... non, franchement, je ne comprend pas...
> D'autant plus que sur la plupart des téléviseurs, le format d'émission est automatiquement reconnu et une transformation adaptée est appliquée.
Mouais... si j'ai bien vu certaines TV y arriver proprement, je serais loin d'être aussi catégorique quant à dire que ça concerne la plupart...
C'est d'aileurs l'une des raisons pour lesquelles je me sers de MythTV (bon, pas que je regarde moult le broadcast... le peu que j'en vois, soit je voulais l'enregistrer et ça se fait automatiquement, soit ça me gave au bout de deux minutes, l'un n'excluant pas l'autre) plutôt que du tuner intégré à mes TV (dont l'une est pourtant très récente, TNT, HDMI 1.3, full-hd, tout-ça)... bon, certes, c'est aussi pour avoir de meilleurs désentrelacements et upscales... mais niveau détection du format, plein de TV, et encore plus de tuners TNT séparés, sont assez minables.
Ce qui est très mauvais, c'est aussi l'underscan... quand ces glands ne font pas comme les massacreurs sous acides de chez nrj12 qui détruisent de vieux monuments comme "Shérif, fais-moi peur" ou "Ulysse 31" en rognant comme des possédés, sans davantage la moindre notion de professionalisme que d'éthique, ou de respect des oeuvres, ils ne trouvent rien de mieux à faire que de numériser les vieilles bandes video, surtout sans se faire chier, sans le moindre cropping, et donc, avec des barres noires et des pointillés blancs clignotants (grande spécialité de nt1 et tmc)...
M'enfin, bon : le boulot propre, ce n'est pas comme s'ils semblaient en avoir quoi que ce soit à foutre... il n'y a qu'à voir les transcodages de porcs, avec des tonnes d'artefacts, qu'ils arrivent à nous sortir...
On pourrait se demander si la prochaine arrivée de TV en HD (enfin, 720p ou 1080i, faut pas trop en demander) aurait des chances d'améliorer les choses... mais quand on voit déjà le boulot de truie qu'ils font en 576p, il n'y a pas de raison : le pire est toujours à craindre...
D'un autre côté, ils n'ont pas oublié de mettre des garde-fous au garde-fou de la présomption d'innocence...
... si on ne donne pas ses clés, a priori, ce n'est toujours pas le HDD qui pourrait prouver notre culpabilité quant à la tipiakerie (hardi, matelot !), et le bénéfice du doute pourrait au moins nous bénéficier...
... sauf que du coup, obstruction à la justice, éventuellement avec la préméditation comme facteur aggravant, si on a délibérément mis des clés qui ne peuvent servir qu'une fois : et paf... on prend pour autre chose.
Non, vivons heureux, vivons cachés : tor, gnunet, freenet, newsgroups ssl, ... autant risquer le moins possible d'avoir à prouver son innocence à des gens aux méthodes assez éberluantes pour confier la justice à des milices privées et nous proposer de leur donner un HDD pour se disculper (comme si un HDD pouvait faire ça... c'est aussi idiot et futile que de chercher à assurer que l'utilisation d'une adresse IP correspond à une personne physique et pas à une autre...)...
Et c'est pour ça que tu en charcles 80% (sûrement plus, même... un bootstrap de Debian, c'est dans les 120Mio, ou 50Mio en tar.gz... bon, je ne connais pas plus que ça la distro dérivée, et encore moins en version serveur, mais j'imagine quand même que ça doit être relativement sans trop de sucre), en prenant une version extrêmement allégée, notamment, sans le NM qui te fait tant défaut ?
Les distros peuvent parfois faire des choix discutables, ce n'est toujours pas la cohérence qui t'étouffe non plus...
On peut toujours utiliser une partoche pour ce qu'on chiffrer, sur une machine tout le temps allumée (j'ai personnellement un serveur avec mldonkey, tor et freenet), comme pour un /tmp ou un swap, avec une clé aléatoire générée au montage.
Avec un petit onduleur qui-va-bien, et avec une distro qui ne fait que patcher le kernel quand il y a un problème de sécu, ça laisse au moins quelques mois pendant lesquels on n'a pas à démonter la partoche : ça laisse de la marge d'action.
Si on a un doute, qu'on psychote, ou quelque chose du genre, on démonte la partition, qu'on ne sera pas plus en mesure que n'importe qui de déchiffrer, puisque seule la machine connaissait la passhrase et qu'elle n'a pas été stockée de manière permanente.
Bon, après, si on leur donne un HDD chiffré en leur disant qu'on ne connaît ipso facto pas la clé, ça a beau être de bonne guerre, je subodore comme quoi ils suspecteront qu'on se fout de leurs gueules... nous aussi.
Bah non... moi, le client dhcp dans la base minimale, il me saoule...
La base minimale, sous Debian, ce sont les paquets taggués en "required" et en "important" (aptitude search ~prequired ~pimportant) - c'est ce qu'on obtient par défaut en debootstrapant ; or debootstraper, ça sert typiquement à chrooter ou à créer un conteneur (OpenVZ, VServer, ...), et je ne vois déjà pas l'intérêt d'y avoir un client DHCP. Et encore moins un truc qui va tester si une interface tout ce qu'il y a de plus virtuelle est branchée (si ça a un sens)...
Maintenant, quand on installe via netinstall, si on ne déselectionne rien (enfin, je parle en mode "expert"... je ne me souviens plus de si on nous le demande ou pas par défaut), les paquets taggués en "standard" (aptitude search ~pstandard) sont installés - et je verrais allègrement plus le client DHCP là-dedans. Après, à la limite, je veux bien que ifplugd puisse y être à sa place aussi. Ce qui est vraiment une base minimale, ça se discute encore (si on y inclue les "standard" ou pas, voire les "important" ou pas, pour le debootstrap de Lenny, qui le permet - mais là, c'est couillu : même pas d'aptitude, juste dpkg, par exemple).
Si tu veux vraiment savoir pourquoi ça n'y est pas, ou si tu estimes que c'est un bug, rien ne t'empêche de le signaler - si le mainteneur est de ton avis, ou pas, tu pourras en discuter avec lui. Sauf que comme les paquets "standard" sont installés par défaut si on ne spécifie pas explicitement le contraire, faudra te montrer convaincant, chasse-au-bloat-inside ; cela dit, les dépendances de ifplugd ne sont pas monstrueuses : tu sais ce qu'il te reste à faire, si tu veux être plus constructif qu'en vociférant...
> La corruption c'est quand tu veux passer au-delà des lois en influençant quelqu'un qui a du pouvoir
Quand je parlais de corruption, c'était au sens général, pour qualifier ce qui corrompt : ie qui dénature... la corruption n'est pas toujours monétaire. Donner quelque chose à quelqu'un pour faire quelque chose qu'il n'aurait pas fait sans ça, c'est une forme de corruption...
Se servir d'un objet d'une manière totalement différente de ce pourquoi il a été conçu, par exemple, se servir de modems sagems pour faire de l'analyse de Fourier, c'est aussi de la corruption...
Pas pour autant que les deux choses sont directement comparables en pratique ;)
> Ca, ça me gène un peu, parce que ça veut dire qu'essayer d'avoir des fonds de manière plus "légale" devient inutile, et ça affaiblit le modèle d'une société basée sur l'éthique
Si le don est anonyme, justement, il me semble que c'est toujours quelque chose que, dans le doute, on ne peut pas reprocher...
Ce n'est pas non plus comme si la "cosa nostra" déclarait officiellement être parrain du libre...
En même temps, si le mécène reste anonyme et donne des fonds sans contrepartie directement intéressée, ça me paraît un peu osé de suspecter une volonté de corruption...
... l'argent, les richesses, ce ne sont pas forcément en elles qu'elles sont sales - à la limite, d'où elles viennent, certes, éventuellement ; ce à quoi on les destine aussi... Ca dépend aussi des sensibilités : certains considèreront que l'argent est propre quand il est simplement issu du circuit légal (alors que, bon...), d'autres quand il hérite d'une certaine éthique économique, morale, comportementale ou autre, etc ...
Par exemple, Shuttleworth doit une bonne partie de sa fortune à la revente de Thawte... rien de sulfureux là-dedans (à part si l'on considère la revente de ce qui vient de la bulle des nouvelles technologies, avant son éclatement, comme sulfureuse) ; a contrario de ce qu'on peut penser de la relative agressivité du fork de Debian, de l'appel à la débauche de devs opensuse et cie... qui sont une autre question que le simple fait que Shuttleworth soit un "salaud-de-riche"...
Maintenant, si on peut faire des choses crades avec de l'argent propre (genre, crozemarie avec l'argent des dons de l'ARC), j'imagine qu'on peut faire l'inverse : même si l'argent était sale, si on peut faire des choses bénéfiques à tous avec, c'est toujours mieux, même si ce n'est pas idéalement vertueux, que de le voir réinvesti dans des choses éventuellement nuisibles, non ?
Personnellement, si j'avais de gros fonds, je les ferais fructifier (j'éviterais pour ma part de le faire dans monsanto et consorts, certes), et j'en ferais profiter ce qui m'est cher, ie en grande part le libre, sans la moindre contrepartie formulée... là, c'est ce qui se passe : où est le mal ? S'il y en a, il me semble qu'il est tout en dehors de cette affaire de dons...
Le libre est une forme d'art, et l'art a aussi besoin des mécènes, qui ne doivent pas nécessairement être confondus avec les corrupteurs...
> Il me semblait que c'était les dépendances des paquets qui était "testing".
Hmmm... je ne vois pas trop ce que tu veux dire...
Sous Debian, en tout cas :
- stable ne bouge pas, à part pour les bugs critiques, la sécu, et récemment pour les paquets volatiles (nouveau sous-dépôt permettant par exemple d'avoir des bases clamav à jour) ;
- unstable bouge tout le temps (et je la trouve vraiment "stable" pour quelque chose du genre - NB les guillemets à "stable");
- testing bouge quand ça n'introduit pas plus de bugs critiques que le paquet qui existe dans stable et que ses dépendances ont migré ou migrent en même temps, ou quand le maintien d'un paquet dans testing provoquerait des problèmes de dépendances... auquel dernier cas, le paquet est (a priori temporairement) éjecté, comme ça a longtemps été le cas avec VLC, comme ça l'est encore pour Ardour, ou comme ça l'était il y a environ une semaine, pour gtk-qt-engine ; et personnellement, je trouve que c'est le plus saoulant dans testing (même si ça se comprend bien), et c'est d'ailleurs ce qui me fait utiliser des Sid.
> Juste un truc pas très clair : pour vserver et openvz, le cpu doit supporter la virtualisation ou pas ? Comme j'ai un vieux cpu...
Ca, c'est l'intérêt principal, pour moi : mes serveurs sont des Athlon XP de récup, sans moult RAM (512Mo max), et sans instructions spécifiques à la virtualisation...
... et c'est bien pour ça que j'utilise VServer (depuis 6 mois, sans le moindre soucis : rock-stable de chez rock-stable... et pourtant, j'y fais fonctionner de l'imprimante et du scanner USB, ainsi que des cartes TV, ce qui suppose un peu de configuration pour que les conteneurs y aient accès - ie démasquage de périphs, voire ajout de gestion de capacités du noyau au conteneur), et que je me suis mis récemment à tester OpenVZ (jusqu'ici, dans un Qemu, qui me permet déjà de m'amuser avec la virtualisation complète du réseau, ce qui est excellent, puisqu'il semble vraiment qu'on puisse tout faire comme dans un vrai, plutôt que la simple isolation qui passe par le loopback, comme dans VServer).
Autre intérêt de taille, ne pas avoir à se saouler avec du CFS et cie pour partager des données entre les conteneurs : un bind mount (pas encore de possibilité de les faire en read-only, sous Etch, puisque je crois que c'est arrivé avec le kernel 2.6.24 ou 2.6.25), et zou : le conteneur à accès aux données que l'on veut.
Par contre, pas de choses comme des serveurs NFS en plein kernel (de toute façon, l'hôte a plutôt intérêt à être minimal) - ce qui n'empêche pas d'utiliser un serveur NFS en userland, dans un conteneur, s'il est suffisant, selon l'utilisation (ce qui tombe bien : c'est mon cas ;) ).
VServer est officiellement supporté par Debian (les paquets binaires du kernel patché et les outils sont dispos dans les dépôts officiels) - par contre, la doc est parfois un peu dure à trouver.
OpenVZ est maintenu par ceux qui font Virtuozzo (ils fournissent un miroir Debian avec les kernels binaires et les outils qui vont bien, même si les sources du patch et quelques outils existent déjà dans Debian) - le wiki est prolifique (pas forcément trop orienté Debian, puisqu'ils se concentrent sur les distros à RPM... m'enfin, ça ne change pas grand chose), le forum assez vivant : bref, là par contre, niveau doc, ça me paraît mieux. Niveau fonctionnalités (quotas, virtualisation et non simple isolaton du réseau, avec des possbilités de fous [pour moi, jusqu'ici utilisateur de VServer], comme d'avoir accès au broadcast dans le conteneur, de l'interface réseau physiquement gérée par le conteneur sans même que l'hôte n'y ait accès, bridging et routage avancés, conteneur pouvant être bridgé et écouter en promiscuous, par exemple, pour y mettre une sonde d'IDS, IPv6 [apparemment], iptables dans le conteneur, migration de conteneur sans interruption de service...) aussi... A noter qu'ils semblent plutôt travailler en bonne intelligence avec upstream, pour le kernel : pour le 2.6.26-rc1, 299 patches [1] sur les quelques 7500 de la release-candidate [2], soit environ 4% des patches upstream commités par l'équipe d'OpenVZ, essentiellement sur les namespaces, dans le cadre de l'intégration dans le noyau des fonctions qui lui permettront nativement d'embarquer de quoi compartimenter. Voilà qui mérite un "Kudos, OpenVZ ! Kudos !". Si toutes les boîtes qui bénéficient du libre, quand bien même elles proposent un truc proprio à côté, faisaient comme eux...
Si on n'a pas besoin de faire tourner des kernels différents, voire pire, si on ne peut pas le faire en accélérant matériellement (ce qui est faisable, mais lourd), et si on n'a pas trop de RAM à dépenser dans de la virtualisation complète, les conteneurs, c'est de la bombe : mangez-en ! Faudrait d'ailleurs que je fasse un journal quand j'aurai installé de l'OpenVZ sur des serveurs physiques, parce qu'aussi excellent qu'il ait l'air, niveau infos/publicité/... sur DLFP, c'est maigre [3].
Attends ; tu veux une distrib "serveur" (à compter qu'on parle de la même chose : un truc qui t'installe une base minimale, à partir de laquelle tu te construis le système qui te plaît - typiquement, une Debian en netinstall sans rien rajouter, ou une Gentoo avec le livecd minimal en suivant le guide officiel)... si c'est pour les mêmes raisons que c'est ce que j'utilise, faut assumer au moins deux secondes : ton lego ne te convient pas ? Tu n'as qu'à retrousser tes manches, gougler, manner, expérimenter et apprendre - sinon, tu aurais pris un playmobil. Chacun sont truc : perso, l'une des raisons qui font que je pars toujours d'une base minimale, c'est que je trouve ça plus facile à maîtriser (il faut que je comprenne pour maîtriser ; que ça juste-marche ne me suffit pas), et que le premier à qui j'ai à m'en prendre si ce que je rajoute par-dessus ne me convient pas, c'est moi - ça m'incite à me bouger plutôt qu'à gueuler sur les autres...
D'autant que ce que tu veux existe : si tu te contentes de DHCP (pour l'instant... m'enfin, ça, au moins, ça couvre les besoins de l'utilisateur Lambda qui n'y connait rien en réseau, et qui a déjà eu du mal à faire fonctionner sa box fai qu'il n'a pourtant qu'à brancher), tu as NM, dispo par défaut dans, je pense, toutes les distros en mode click-click-suivant, et installable sur toutes les autres ; si tu veux te faire ta tambouille parce que tu es un gros geek qui alterne entre les réseaux DHCP, les IP fixes, qui veut que du NFS soit monté ici mais pas là, qui branche et débranche câbles et antennes à tour de bras en dansant nu et en sacrifiant un capriné, et cie, tu as les pre/post-up/down, ifplugd, guessnet et cie (mais il faudra suer un minimum de sang et d'eau... ce qui n'est pas grave, partant du postulat que tu es un gros geek si tu fais ça, puisque sinon, tu aurais NM)...
Maintenant, autant je veux bien admettre que le DHCP sans gestion du hotplug, ça me paraît un peu ballot, autant devoir se trimballer ifplugd et/ou consorts dans les paquets d'une base minimale, ça ne me tente pas trop... déjà que le tag en "important" de dhcp3-client dans Debian me paraît limite (je le verrais davantage en "standard"), s'il faut commencer à en bouffer encore plus, pour considérer que le roaming, où on se branche et se débranche à foison, est un cas par défaut, qu'il faut intégrer dans la base, quitte à la bloater et à se retrouver avec des serveurs qui embarquent NM... parce que bon, NM, quand il sera davantage fini, il sera assez ultime, je pense, dans le genre - maintenant, paye tes dépendances. Non, à choisir, j'éjecte le client DHCP de la base minimale.
En même temps, ta grand-mère installe des versions serveurs de Linux ?
Ou c'est toi qui lui fais, pour avoir un truc aux oignons (j'installe et maintient bien de la Debian stable sur le PC de ma mère), mais tu ne fais le boulot de fignolage qu'à moitié ?
Non, parce que les pages de manuel, ça existe, et ça explique plutôt bien... genre "man interfaces", où on peut apprendre qu'une interface en auto (gérée par le ifup, donc entre autres par les scripts de démarrage), ce n'est pas la même chose qu'une interface qui autorise le hotplug (bon, là, faut aller à la page de manuel de ifup, qui indique que l'on peut faire ça avec hotplug, déprécié maintenant, et ifplugd, ce qu'il est conseillé d'utiliser)...
Maintenant, est-ce qu'un serveur en DHCP qui autorise le branchage à chaud est vraiment ce qu'on rencontre le plus quand on installe un serveur ? Bof, j'aurais plutôt tendance à mettre un serveur en IP fixe quand c'est possible (ça n'engage que moi), et à tout inspecter minutieusement si j'y activais des services comme DHCP (et donc, à activer encore un truc en plus si je voulais le hotplug par DHCP), ou du OSPF que j'ai bien envie de tester sur des OpenVZ (je suis curieux de savoir comment se comporterait un quagga, ou assimilé, dans un conteneur, qui servirait de gateway physique à la machine)...
... et de même, pour ta grand-mère... si tu ne veux vraiment pas te saouler, tu lui proposes un truc qui embarque NM, et qui va se contenter de choper un bail DHCP (tant que la version 0.7 n'est pas sortie), tout seul, et gérer le hotplug, tout seul, sans rien configurer comme un barbu, vu qu'il ne s'occupe que des cartes non gérées par le /etc/network/interfaces (ou qui y sont en auto et DHCP)...
Bon, pour ne pas être de mauvaise foi, je veux bien qu'on puisse regretter qu'à partir du moment où DHCP est activé, ifplugd et consorts ne le soient pas... c'est vrai que c'est un comportement auquel on pourrait s'attendre ; sauf que ça ajoute encore à gérer un truc (bazar, cathédrale, tout-ça) : le nommé ifplugd, ou networkmanager... Et après,lequel forcerait-on à utiliser par défaut (j'ai un peu de mal avec l'idée de NM sur un serveur... déjà que dhcp et ifplugd, bof) ? Est-ce que des gens se servent de DHCP sans hotplug ? ... c'est entre autres pour éviter d'avoir à me poser la question que je n'utilise pas de DHCP pour mes serveurs (et en pratique, d'ailleurs, nulle part chez moi) : toujours un truc de moins à gérer (et deux, d'ailleurs, avec le hotplug) - moins de bazar.
... ou Debian stable en plus d'autres choses... testing, ça veut dire ce que ça veut dire : ça peut casser - même si en général, je n'ai rien vu de bien méchant, pour qui a l'habitude de mettre les mains dans le camboui... le plus ennuyeux sous testing, c'est l'évacuation ,fut-ce temporaire, de paquets dont la version de stable ne peut plus convenir, mais dont la version unstable n'est pas encore releasable...
Après, si tu peux te permettre d'avoir une machine en plus pour faire un serveur, et y mettre ce qui ne doit pas casser, c'est quand même top...
Avec une Debian stable ou autres distros qui ne bougent pas pendant une longue période (selon ses affinités), voire, avec des conteneurs (mes deux Cups, encre et laser, en Debian stable, sont sur un hôte vserver, en Debian stable aussi, aux "côtés" de mythtv, de slimserver, de sane, d'un SSHd qui sert à faire du SSHFS et d'un NFS userland... et c'est tellement stable que j'ai envie de le secouer pour passer tout ça sous openvz que je découvre et dont je trouve la virtualisation réseau et la migration en live d'un invité super cools), ça permet d'avoir une base très stable, et de faire ses conneries ailleurs (toutes mes workstations sont en sid, en ce moment, pour diverses raisons... et ça me va très bien)...
Sous Linux, le problème pour M'sieur Toutl'monde ne me paraît pas forcément tant être networkmanager que les drivers dont beaucoup sont encore très jeunes...
La nouvelle pile wifi n'est pas là depuis si longtemps, et pas mal de drivers libres, qui feront fonctionner nativement de plus en plus de cartes, sont encore jeunes... comme ath, par exemple. Il me semble que ce ne soit toujours pas la joie non plus avec ce qui vient de broadcom, mais les WRT54G m'ont vacciné pour un bon moment quant à réessayer de toucher à ce qui vient de chez eux, de toute façon.
Enfin, voilà, pour moi, de ce que j'ai vu, le plus gros problème avec le wifi, sous Linux, ce sont encore les drivers, souvent encore blobés, ou avec des firmwares non distribuables, ainsi que les frameworks pour les gérer (ce que nous a apporté la nouvelle pile wifi : plus besoin que chacun réinvente complètement son WPA et cie de son côté)... M'enfin, ça y travaille moult, comme partout dans le libre, aussi bien chez OpenBSD qui commence à implémenter WPA (PSK seulement, pour l'instant... pas que ce soit plus sékioure que du VPN, mais de quoi faire du VPN n'est pas embarqué partout, pas plus que tout ce qui a une antenne n'a un port ethernet sur lequel se rabattre), ou FreeBSD (qui commence à introduire des fonctions bougrement intéressantes, comme les VAP avec les drivers libres, pour faire plusieurs points d'accès distincts sur une seule carte, ou ce qu'il est possible de supporter dans 802.11n, même s'il n'y a pas encore de pilote pour ça... vivement la 7.1 ou la 8.0, d'ailleurs : ô oui : vivement ! Je vois bien un petit gros routeur/gateway/firewall/AP/... sous FreeBSD, que je découvre agréablement ces temps-ci, après avoir essayé d'autres Linux que de la Debian, et être promptement revenu aux sources, chez moi).
Après, certes : network-manager est très jeune aussi... il ne permet même pas de gérer les adresses statiques - je crois que ça doit venir pour la 7.0 qui devrait sortir bientôt, et qui je crois même à été pré-intégrée dans suse... D'ailleurs, c'est pour ça que je ne m'en sers pas encore, préférant une tambouille-maison à base de /etc/network/interfaces, de ifplugd pour le roaming, avec IP fixe pour chez moi, et de mignoneries geekesques dans le genre...
Maintenant, pour ce qui est des connexions faisant intervenir DHCP, ça marche plutôt pas mal depuis un moment. En tout cas sur ma Sid, dans "/usr/share/doc/network-manager/README.Debian", on peut lire (traduction libre) :
"Seuls les périphériques *non* listés dans /etc/network/interfaces ou qui y ont été configurés avec "auto" et "dhcp" (avec aucune autre option) sont gérés par NM.
Ainsi, vous pouvez définir une configuration personnalisée (statique) pour un périphérique, et NM n'essaiera pas de passer outre ce réglage."
Et honnêtement, c'est exactement comme ça qu'il se comporte sur ma machine : "DHCP et auto dans le "interfaces" ou "pas configuré dans le interfaces", c'est lui qui gère, sinon, c'est à la mimine de bout en bout. Bon, après, je ne sais pas si ça marche comme ça partout - mais au moins, sur mon laptop, quand je m'en sers, surtout pour tester, je sais exactement quand c'est lui, et quand c'est moi, qui gère... et sinon, il me semble aussi être tombé sur un /var/log/NetworkManager.log ou quelque chose comme ça sur une Fedora ou une Suse (je ne sais plus très bien), pour debuguer ; mais après, je l'ai dit : je ne touche pas du NM tous les jours, donc je ne garantis rien...
Cela dit, je suis bien tenté par l'essai de la 0.7, avec les IP fixes... le module VPN me tente également... s'il pouvait reconnaître les réseaux sur lesquels il est (avec du ping sur une adresse, ou une connexion à une certaine adresse MAC, à la ifplugd), et qu'on pouvait lancer des pre/post-up/down (peut-être que c'est déjà possible, en fait... je ne le connais pas assez pour ça, le manque d'adresses fixes me faisant trop défaut ), je m'en servirais vraiment en remplacement de mes scripts de barbu, et sans le moindre remord.
Nonobstant, sorti de ça, pour revenir sur les 3h pour installer un linux, je ne vois pas en quoi ça justifierait de nous forcer à acheter une licence de ouin-ouin. Ca veut dire quoi, ça ? Que si ce n'est pas accessible à un expert quelconque, ça impliquerait forcément que je suis trop con pour avoir le droit de m'en contenter ou d'essayer ? Et comme je serais irrévocablement, unilatéralement, forcément un con, il serait bien normal qu'on décide à ma place ce qui est bon pour moi, et que je me fasse mettre en étant forcé d'acheter un truc que, en l'occurence, pourtant, je n'utiliserai pas (j'interprète ce qu'ils disent, hein... je ne vois pas de problème à ne pas savoir, ou à ne pas vouloir savoir ; mais le message de darty me paraît clairement être du tonneau de "t'es trop con, de toute façon : mange tmon foin") ? Eh bien... Qu'est-ce que ce serait si ce n'était pas dans mon intérêt ?
[^] # Re: Virtualisation?
Posté par Aefron . En réponse à la dépêche Sortie du noyau Linux 2.6.26. Évalué à 2.
Le souci, c'est que je voulais me faire un CD d'installation customisé de Debian qui m'installe déjà tout ce qu'il me faut, y compris le kernel et les utilitaires packagés par Thorsten...
... or debian-cd/simple-cdd ne gèrent que les composants main, contrib, et non-free (c'est hardcodé dans debian-cd : pas le choix)... et du coup, le composant openvz, bah, pas moyen de l'inclure comme ça...
Je pourrais faire avec FAI, mais je ne le connais pas bien, il n'est à la base pas prévu pour faire de CD (même si je sais très bien que ça se fait), et surtout, il n'est pas spécialement prévu pour l'interactivité (je veux au moins choisir mes paramètres réseau, et le HDD à formater... plus quelques autres binioucs, si je me mets à packager des conteneurs pour les installer)... Je pourrais aussi télécharger les .deb à la mimine, mais je perdrais par exemple l'avantage d'installer directement linux-image-openvz-2.6-686, et il faudrait mettre la référence exacte de la révision du kernel à la main...
Du coup, je vais pour l'instant au plus simple, et je pars plutôt sur http://download.openvz.org/debian (seulement du kernel, et pas avec le fichier de config Debian, comme les fza de Thorsten... l'enfin, pour le moment, tant pis) que vers http://download.openvz.org/debian-systs (qui est un miroir de celui que tu donnes, par les gars de chez OpenVZ)... d'autant que j'ai essayé de trouver une adresse mail pour joindre Thorsten, et je me suis même inscrit sur le forum OpenVZ pour lui envoyer un message privé : en vain ; il ne les accepte pas... bon, j'ai quand même fini par trouver son mail en fouillant un peu : faudra que je pense à le contacter... En attendant, mon CD d'installation d'une Debian OpenVZée marche bien quand même.
[^] # Re: Virtualisation?
Posté par Aefron . En réponse à la dépêche Sortie du noyau Linux 2.6.26. Évalué à 5.
... une solution complète sera probablement intégrée à terme, mais pour l'instant, comme le dit patrick_g, l'heure est à un "long travail visant à masquer toutes les ressources globales du noyau (systèmes de fichiers, identifiants des processus, interfaces réseaux etc.) derrière une couche d'abstraction afin de pouvoir gérer des conteneurs séparés".
Chacun y vient petit à petit, comme chez FreeBSD, avec la virtualisation de la pile réseau [1]
D'ailleurs, à ce titre, les développeurs de solutions de conteneurs participent à patcher le noyau petit à petit, en tout cas, chez OpenVZ [2] (j'imagine qu'ils le font aussi chez VServer), que je découvre après 6 mois de VServer, que je trouvais déjà très bien, mais qui est bien moins polyvalent au niveau réseau :
- VServer isole des interfaces de l'hôte, en les faisant discuter via le loopback, ce qui empêche de laisser le loopback grand ouvert, si on veut firewaller entre les conteneurs, et ce qui empêche aussi d'avoir un loopback dans le conteneur (on est forcé de rechercher toutes les occurences de 127.0.0.1 et de les remplacer par du localhost, qu'on a manuellement fait correspondre à l'adresse IP du conteneur... voire de forcer manuellement les services sur cette adresse)...
- OpenVZ virtualise le dialogue réseau en faisant intervenir une interface virtuelle qui permet de réaliser le routage entre les conteneurs, qui disposent donc d'un loopback à eux... a priori, ils sont chacun sur un /32 en point à point avec l'interface virtuelle, mais on peut leur donner un peu plus de capacités, pour qu'ils aient leurs propres iptables, routes, qu'on puisse les bridger avec le reste, par exemple pour mettre une sonde d'IDS en promiscuous, qu'ils puissent avoir du broadcast, et même qu'ils gèrent une interface réseau physique, sans que l'hôte n'y ait accès, voire même, qu'ils aillent jusqu'à router eux-aussi...
... sur ce point OpenVZ roxorise des famille-ours ! Dommage que le kernel binaire et l'outil de migration (enfin, ça, encore... faut avoir assez de machines, pour ça... mais c'est assez classe à voir [3]) ne soient pas directement packagés dans Debian... et que le miroir des kernels fza soit dans un composant "openvz" bizarre (et pas dans un "main"), ce qui fait qu'on ne peut pas l'inclure via debian-cd/simple-cdd...
En tout cas, si on n'a pas besoin de faire tourner plusieurs kernels, les conteneurs, c'est génial.
[1] http://imunes.tel.fer.hr/virtnet/
[2] http://community.livejournal.com/openvz/22369.html
[3] http://www.montanalinux.org/openvz-live-migration-demo.html
[^] # Re: UNE FEMME TAILLE 42 N'EST PAS RONDE, ELLE EST NORMAL !
Posté par Aefron . En réponse au journal toi aussi participe à un casting d'obeses taille 42. Évalué à 2.
... et puis, pour moi, le physique, entre autres, a vraiment de l'importance, ne serait-ce que sur la première attirance lors de la rencontre - il y a des physiques sur lesquels je craque typiquement (ie, une forte inclinaison : ni plus, ni moins), et d'autres tout à l'inverse... mais encore une fois, chacun son truc : le seul qui soit vraiment débile, c'est l'invocation d'une quelconque normalité, ce qui sous-tend à une universalité, dans les goûts.
Bon, après, j'aime bien les filles très minces, que certains qualifient de maigres (typiquement, quand mes potes disent qu'elles n'ont "pas de cul", moi, je trouve justement qu'elles ont des "petits culs", et ça me plaît généralement beaucoup) - mais bon, il y a de l'excès là-dessus aussi, hein... toutes les filles très minces ne sont pas non plus des anorexiques décharnées et maladives : il y a aussi des sportives (hmmmm... les danseuses), des tempéraments (perso, je fais plus de 1,90m, et seulement 80kg... je peux bouffer tout ce que je veux, sucre, viande, sauces, et j'en bouffe tout le temps : bah, je suis longiligne quand même - sans avoir de ténia, je précise... et il y a des filles qui sont comme ça aussi - hmmmm, certaines filles de l'est), des carrures ("I'm not fat, I'm big-boned" ©Eric Cartman... bon OK, mauvais exemple - mais il y a des filles qui ont le bassin et le reste plutôt large [avant, on disait qu'elles avaient le physique pour enfanter], naturellement ; d'autre pas - et forcément, ça joue sur la quantité de trucs qu'on peut accrocher dessus)...
Et puis, tant que les gens se sentent bien comme ils sont, sans venir chercher des poux aux autres, ils peuvent bien faire ce qu'ils veulent, et avoir l'allure qu'ils veulent : c'est vraiment dans les derniers de mes soucis...
[^] # Re: UNE FEMME TAILLE 42 N'EST PAS RONDE, ELLE EST NORMAL !
Posté par Aefron . En réponse au journal toi aussi participe à un casting d'obeses taille 42. Évalué à 1.
... on parle de laquelle, normalité ? Celle à l'état naturel, où on va avoir moins tendance à grossir et plus à se muscler ? Celle de ceux qui préfèrent les grosses ? Celle de ceux qui préfèrent les maigres ? Celle de ceux qui préfèrent les grandes ou celle de ceux qui préfèrent les petites ? Celle des médecins, ou celle des croque-morts ?
Non, mais franchement : chacun son truc... qu'est-ce qu'on en a à foutre, de la normalité en matière de goûts : personnellement, je préfère les filles très minces (mes potes disent maigres), plutôt petites (alors que je suis plutôt grand, ie >1,90m... les petites, c'est bien, c'est plus maniable :) ), brunes plutôt que blondes, et beaucoup plus avec des petites fesses qu'avec des gros nichons... et alors ? Si je compare avec mon entourage, j'aurais plutôt tendance à ne pas être dans la norme... et bien tant mieux : ça en fait plus, juste pour moi, comme j'aime bien !
[^] # Re: Freenet
Posté par Aefron . En réponse au journal Le p2p n'est pas obligatoirement illégal .... Évalué à 3.
En fait, puisque c'est du P2P, chaque utilisateur connecté au réseau fait office de client (il va pomper des trucs ailleurs) et de serveur (des gens d'ailleurs viennent y pomper des trucs)...
... et comme c'est du P2P de nouvelle génération, pas le moindre serveur centralisé (comme ceux où on met le torrent à l'origine, ou les serveurs de recherche d'emule&cie, qui ne sont utiles que quand un réseau décentralisé parallèle comme Kad n'a pas encore bootstrapé)...
Et si on veut se simplifier la vie avec le firewalling et la bande passante, on met ça sur une machine, sans clickodrome tant qu'à faire, qui fera serveur de proxy Freenet pour son réseau local... comme on peut le faire pour mldonkey, amule et tous les autres...
Bon, après, Freenet, c'est rigolo, mais c'est encore lent, c'est en java (et je n'ai pas encore opensdk dans le conteneur où j'ai Freenet : vivement Lenny, ou le backport, si Lenny venait à tarder), et surtout, le mode de mise à jour est horrible (peu de distros le distribuent, et il me semble qu'ils n'ont pas particulièrement l'intention d'être distribués tant qu'ils ne considèrent pas eux-mêmes Freenet comme plus mature) - du coup, avant, c'était via un script à-la-rache, et maintenant, c'est carrément via Freenet : bof (m'enfin, dans un conteneur, au moins, le risque est ipso facto un minimum contenu)...
Cela dit, ça a le mérite d'exister et de se développer : comme Tor et GnuNet, d'ailleurs.
[^] # Re: 42 normal ?
Posté par Aefron . En réponse au journal toi aussi participe à un casting d'obeses taille 42. Évalué à 4.
En effet, ça, c'est de la tension artérielle... gaffe à pas en foutre partout quand ça pètera...
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par Aefron . En réponse à la dépêche Interface graphique fonctionnelle : encore un effort pour l'open source. Évalué à 2.
... parce que bon... configurer mon Mythbackend sans exporter le clickodrome, soit ça me force à avoir un X.org complet dans un des conteneurs de l'un de mes serveurs (beurrrk), soit à mettre les mains dans une base mysql (beurrrk)...
[^] # Re: PPC _not_ pwned
Posté par Aefron . En réponse à la dépêche Interface graphique fonctionnelle : encore un effort pour l'open source. Évalué à 3.
... en outre, le mode vesa, il y a mieux, mais ça dépanne bien : je connais au moins deux personnes qui s'en servent, pour cause de trop de problèmes avec le(s) driver(s) libre(s), et aussi par refus d'utiliser le blob... [ahemmm] : ils ont des nvidia...
... et sinon, UT2003 sur une X800XL à drivers libres (pas essayé sur ma 9600m, vu que j'évite ce genre de trucs qui font chauffer les ordis portables... mais comme elle a tendance à être mieux supporté que les X800, et que je connais quelqu'un qui fait tourner ça sur une 9800... bon, après, ça dépend de la résolution et des détails), chezmoiçamarche© (enfin, quand j'avais testé, ce qui remonte un peu)...
Perso, je fais peu de 3D (essentiellement : MythTV), mais je fais du multi-écran partout, et depuis longtemps : et je ne suis pas près de prendre autre chose que de l'ATI à driver libres (on verra quand Intel sortira du GPU en cartes à brancher)...
[^] # Re: L'original
Posté par Aefron . En réponse au journal Hadopi : l'abonné pourra fournir son disque dur comme preuve !. Évalué à 2.
... autant il est stupide de pousser à ne pas partager sa connexion (d'ailleurs, si quelque chose l'empêche, ce seraient plus les conditions d'abonnement que la loi... cette dernière étant juste assez vicieuse pour fortement décourager les hotspots ouverts, ce qui est crétin, certes, certes), autant tomber sur un hotspot quand on a besoin du net est pratique, autant il est résolument irréaliste de croire qu'on va remplacer les backbones des FAI par des millions de fonera...
... entre un kibboutz avec mes voisins, lent, limité (vu le nombre de protagonistes), avec une architecture réseau tenant du château de cartes bricolé à-la-rache, et internet, le choix est vite vu.
[^] # Re: Les impacts du Wifi
Posté par Aefron . En réponse au journal Going full VOIP ?. Évalué à 2.
C'est là que je me dis qu'avec une Squeezebox (version 2) en guise de radio-réveil wifi (pour cause de location... sinon, elle serait bien sûr en ethernet), je suis quand même un gros geek...
... même quand je dors, je ne peux pas couper le wifi, vu que j'aime bien savoir l'heure quand je me réveille, même avant que le réveil ne se soit manifesté... et que j'ai besoin du wifi pour ça...
[^] # Re: Croping, underscan, artefacts : le grand massacre...
Posté par Aefron . En réponse au journal 4/3 16/9 panscan letterbox .... Évalué à 9.
Certainement que c'est une oeuvre ! Un monument, même...
[^] # Re: Où est le problème ?
Posté par Aefron . En réponse au journal 4/3 16/9 panscan letterbox .... Évalué à 6.
... et mon format préféré, c'est 4:3 pour les émissions nativement en 4:3 et 16:9 pour les émissions en 16:9...
Sorti de ça, je m'en fous... mais si tu croppes comme un fou pour faire croire que le 4:3 est nativement 16:9, tu fous en l'air le cadrage : les têtes des protagonistes sont coupées ou le plan est incomplet... sans compter la perte de résolution verticale qui devra être davantage scalée... bref, c'est vraiment du très grand n'importe quoi, de faire ça.
Franchement, ça ne me viendrait pas à l'idée de regarder une émission nativement 4:3 en zoomant... oui, dans ce cas, je préfère largement le ratio d'affichage 4:3. Le 16;9 pour le 16:9, quitte à bousiller l'image quand ça n'en est pas (et ça arrive très souvent : plein de films sont plus larges que le 16:9, et beaucoup de choses intéressantes, même si pas forcément neuves, sont en 4:3), c'est parfaitement ridicule.
[^] # Re: Pour faire vendre des télés
Posté par Aefron . En réponse au journal 4/3 16/9 panscan letterbox .... Évalué à 10.
... pourtant, même un gamin de deux ans est censé comprendre que "Non ! un rectangle ne s'habitue pas à être un carré, pas plus qu'un rond un triangle, ou autres choses élémentaires"... je crois même que les chimpanzés y arrivent très bien aussi...
C'est désolant... d'autant plus que c'est très loin de ne concerner que des vieux qui n'y voient plus goutte, ou qui ont connu la guerre, les privations, et n'aiment pas gâcher... non, franchement, je ne comprend pas...
# Croping, underscan, artefacts : le grand massacre...
Posté par Aefron . En réponse au journal 4/3 16/9 panscan letterbox .... Évalué à 10.
Mouais... si j'ai bien vu certaines TV y arriver proprement, je serais loin d'être aussi catégorique quant à dire que ça concerne la plupart...
C'est d'aileurs l'une des raisons pour lesquelles je me sers de MythTV (bon, pas que je regarde moult le broadcast... le peu que j'en vois, soit je voulais l'enregistrer et ça se fait automatiquement, soit ça me gave au bout de deux minutes, l'un n'excluant pas l'autre) plutôt que du tuner intégré à mes TV (dont l'une est pourtant très récente, TNT, HDMI 1.3, full-hd, tout-ça)... bon, certes, c'est aussi pour avoir de meilleurs désentrelacements et upscales... mais niveau détection du format, plein de TV, et encore plus de tuners TNT séparés, sont assez minables.
Ce qui est très mauvais, c'est aussi l'underscan... quand ces glands ne font pas comme les massacreurs sous acides de chez nrj12 qui détruisent de vieux monuments comme "Shérif, fais-moi peur" ou "Ulysse 31" en rognant comme des possédés, sans davantage la moindre notion de professionalisme que d'éthique, ou de respect des oeuvres, ils ne trouvent rien de mieux à faire que de numériser les vieilles bandes video, surtout sans se faire chier, sans le moindre cropping, et donc, avec des barres noires et des pointillés blancs clignotants (grande spécialité de nt1 et tmc)...
M'enfin, bon : le boulot propre, ce n'est pas comme s'ils semblaient en avoir quoi que ce soit à foutre... il n'y a qu'à voir les transcodages de porcs, avec des tonnes d'artefacts, qu'ils arrivent à nous sortir...
On pourrait se demander si la prochaine arrivée de TV en HD (enfin, 720p ou 1080i, faut pas trop en demander) aurait des chances d'améliorer les choses... mais quand on voit déjà le boulot de truie qu'ils font en 576p, il n'y a pas de raison : le pire est toujours à craindre...
[^] # Re: Vie privée
Posté par Aefron . En réponse au journal Hadopi : l'abonné pourra fournir son disque dur comme preuve !. Évalué à 3.
... si on ne donne pas ses clés, a priori, ce n'est toujours pas le HDD qui pourrait prouver notre culpabilité quant à la tipiakerie (hardi, matelot !), et le bénéfice du doute pourrait au moins nous bénéficier...
... sauf que du coup, obstruction à la justice, éventuellement avec la préméditation comme facteur aggravant, si on a délibérément mis des clés qui ne peuvent servir qu'une fois : et paf... on prend pour autre chose.
Non, vivons heureux, vivons cachés : tor, gnunet, freenet, newsgroups ssl, ... autant risquer le moins possible d'avoir à prouver son innocence à des gens aux méthodes assez éberluantes pour confier la justice à des milices privées et nous proposer de leur donner un HDD pour se disculper (comme si un HDD pouvait faire ça... c'est aussi idiot et futile que de chercher à assurer que l'utilisation d'une adresse IP correspond à une personne physique et pas à une autre...)...
[^] # Re: Matériel supporté
Posté par Aefron . En réponse au journal [Darty] Putain de wifi. Évalué à 2.
Les distros peuvent parfois faire des choix discutables, ce n'est toujours pas la cohérence qui t'étouffe non plus...
[^] # Re: Vie privée
Posté par Aefron . En réponse au journal Hadopi : l'abonné pourra fournir son disque dur comme preuve !. Évalué à 5.
On peut toujours utiliser une partoche pour ce qu'on chiffrer, sur une machine tout le temps allumée (j'ai personnellement un serveur avec mldonkey, tor et freenet), comme pour un /tmp ou un swap, avec une clé aléatoire générée au montage.
Avec un petit onduleur qui-va-bien, et avec une distro qui ne fait que patcher le kernel quand il y a un problème de sécu, ça laisse au moins quelques mois pendant lesquels on n'a pas à démonter la partoche : ça laisse de la marge d'action.
Si on a un doute, qu'on psychote, ou quelque chose du genre, on démonte la partition, qu'on ne sera pas plus en mesure que n'importe qui de déchiffrer, puisque seule la machine connaissait la passhrase et qu'elle n'a pas été stockée de manière permanente.
Bon, après, si on leur donne un HDD chiffré en leur disant qu'on ne connaît ipso facto pas la clé, ça a beau être de bonne guerre, je subodore comme quoi ils suspecteront qu'on se fout de leurs gueules... nous aussi.
[^] # Re: Matériel supporté
Posté par Aefron . En réponse au journal [Darty] Putain de wifi. Évalué à 2.
Bah non... moi, le client dhcp dans la base minimale, il me saoule...
La base minimale, sous Debian, ce sont les paquets taggués en "required" et en "important" (aptitude search ~prequired ~pimportant) - c'est ce qu'on obtient par défaut en debootstrapant ; or debootstraper, ça sert typiquement à chrooter ou à créer un conteneur (OpenVZ, VServer, ...), et je ne vois déjà pas l'intérêt d'y avoir un client DHCP. Et encore moins un truc qui va tester si une interface tout ce qu'il y a de plus virtuelle est branchée (si ça a un sens)...
Maintenant, quand on installe via netinstall, si on ne déselectionne rien (enfin, je parle en mode "expert"... je ne me souviens plus de si on nous le demande ou pas par défaut), les paquets taggués en "standard" (aptitude search ~pstandard) sont installés - et je verrais allègrement plus le client DHCP là-dedans. Après, à la limite, je veux bien que ifplugd puisse y être à sa place aussi. Ce qui est vraiment une base minimale, ça se discute encore (si on y inclue les "standard" ou pas, voire les "important" ou pas, pour le debootstrap de Lenny, qui le permet - mais là, c'est couillu : même pas d'aptitude, juste dpkg, par exemple).
Si tu veux vraiment savoir pourquoi ça n'y est pas, ou si tu estimes que c'est un bug, rien ne t'empêche de le signaler - si le mainteneur est de ton avis, ou pas, tu pourras en discuter avec lui. Sauf que comme les paquets "standard" sont installés par défaut si on ne spécifie pas explicitement le contraire, faudra te montrer convaincant, chasse-au-bloat-inside ; cela dit, les dépendances de ifplugd ne sont pas monstrueuses : tu sais ce qu'il te reste à faire, si tu veux être plus constructif qu'en vociférant...
[^] # Re: Un mécène masqué ?
Posté par Aefron . En réponse à la dépêche 336 ordinateurs serveurs offerts aux communautés du logiciel libre. Évalué à 2.
Quand je parlais de corruption, c'était au sens général, pour qualifier ce qui corrompt : ie qui dénature... la corruption n'est pas toujours monétaire. Donner quelque chose à quelqu'un pour faire quelque chose qu'il n'aurait pas fait sans ça, c'est une forme de corruption...
Se servir d'un objet d'une manière totalement différente de ce pourquoi il a été conçu, par exemple, se servir de modems sagems pour faire de l'analyse de Fourier, c'est aussi de la corruption...
Pas pour autant que les deux choses sont directement comparables en pratique ;)
> Ca, ça me gène un peu, parce que ça veut dire qu'essayer d'avoir des fonds de manière plus "légale" devient inutile, et ça affaiblit le modèle d'une société basée sur l'éthique
Si le don est anonyme, justement, il me semble que c'est toujours quelque chose que, dans le doute, on ne peut pas reprocher...
Ce n'est pas non plus comme si la "cosa nostra" déclarait officiellement être parrain du libre...
[^] # Re: Un mécène masqué ?
Posté par Aefron . En réponse à la dépêche 336 ordinateurs serveurs offerts aux communautés du logiciel libre. Évalué à 10.
... l'argent, les richesses, ce ne sont pas forcément en elles qu'elles sont sales - à la limite, d'où elles viennent, certes, éventuellement ; ce à quoi on les destine aussi... Ca dépend aussi des sensibilités : certains considèreront que l'argent est propre quand il est simplement issu du circuit légal (alors que, bon...), d'autres quand il hérite d'une certaine éthique économique, morale, comportementale ou autre, etc ...
Par exemple, Shuttleworth doit une bonne partie de sa fortune à la revente de Thawte... rien de sulfureux là-dedans (à part si l'on considère la revente de ce qui vient de la bulle des nouvelles technologies, avant son éclatement, comme sulfureuse) ; a contrario de ce qu'on peut penser de la relative agressivité du fork de Debian, de l'appel à la débauche de devs opensuse et cie... qui sont une autre question que le simple fait que Shuttleworth soit un "salaud-de-riche"...
Maintenant, si on peut faire des choses crades avec de l'argent propre (genre, crozemarie avec l'argent des dons de l'ARC), j'imagine qu'on peut faire l'inverse : même si l'argent était sale, si on peut faire des choses bénéfiques à tous avec, c'est toujours mieux, même si ce n'est pas idéalement vertueux, que de le voir réinvesti dans des choses éventuellement nuisibles, non ?
Personnellement, si j'avais de gros fonds, je les ferais fructifier (j'éviterais pour ma part de le faire dans monsanto et consorts, certes), et j'en ferais profiter ce qui m'est cher, ie en grande part le libre, sans la moindre contrepartie formulée... là, c'est ce qui se passe : où est le mal ? S'il y en a, il me semble qu'il est tout en dehors de cette affaire de dons...
Le libre est une forme d'art, et l'art a aussi besoin des mécènes, qui ne doivent pas nécessairement être confondus avec les corrupteurs...
[^] # Re: Ca marche, ça marche plus
Posté par Aefron . En réponse au journal [Darty] Putain de wifi. Évalué à 4.
Hmmm... je ne vois pas trop ce que tu veux dire...
Sous Debian, en tout cas :
- stable ne bouge pas, à part pour les bugs critiques, la sécu, et récemment pour les paquets volatiles (nouveau sous-dépôt permettant par exemple d'avoir des bases clamav à jour) ;
- unstable bouge tout le temps (et je la trouve vraiment "stable" pour quelque chose du genre - NB les guillemets à "stable");
- testing bouge quand ça n'introduit pas plus de bugs critiques que le paquet qui existe dans stable et que ses dépendances ont migré ou migrent en même temps, ou quand le maintien d'un paquet dans testing provoquerait des problèmes de dépendances... auquel dernier cas, le paquet est (a priori temporairement) éjecté, comme ça a longtemps été le cas avec VLC, comme ça l'est encore pour Ardour, ou comme ça l'était il y a environ une semaine, pour gtk-qt-engine ; et personnellement, je trouve que c'est le plus saoulant dans testing (même si ça se comprend bien), et c'est d'ailleurs ce qui me fait utiliser des Sid.
> Juste un truc pas très clair : pour vserver et openvz, le cpu doit supporter la virtualisation ou pas ? Comme j'ai un vieux cpu...
Ca, c'est l'intérêt principal, pour moi : mes serveurs sont des Athlon XP de récup, sans moult RAM (512Mo max), et sans instructions spécifiques à la virtualisation...
... et c'est bien pour ça que j'utilise VServer (depuis 6 mois, sans le moindre soucis : rock-stable de chez rock-stable... et pourtant, j'y fais fonctionner de l'imprimante et du scanner USB, ainsi que des cartes TV, ce qui suppose un peu de configuration pour que les conteneurs y aient accès - ie démasquage de périphs, voire ajout de gestion de capacités du noyau au conteneur), et que je me suis mis récemment à tester OpenVZ (jusqu'ici, dans un Qemu, qui me permet déjà de m'amuser avec la virtualisation complète du réseau, ce qui est excellent, puisqu'il semble vraiment qu'on puisse tout faire comme dans un vrai, plutôt que la simple isolation qui passe par le loopback, comme dans VServer).
Autre intérêt de taille, ne pas avoir à se saouler avec du CFS et cie pour partager des données entre les conteneurs : un bind mount (pas encore de possibilité de les faire en read-only, sous Etch, puisque je crois que c'est arrivé avec le kernel 2.6.24 ou 2.6.25), et zou : le conteneur à accès aux données que l'on veut.
Par contre, pas de choses comme des serveurs NFS en plein kernel (de toute façon, l'hôte a plutôt intérêt à être minimal) - ce qui n'empêche pas d'utiliser un serveur NFS en userland, dans un conteneur, s'il est suffisant, selon l'utilisation (ce qui tombe bien : c'est mon cas ;) ).
VServer est officiellement supporté par Debian (les paquets binaires du kernel patché et les outils sont dispos dans les dépôts officiels) - par contre, la doc est parfois un peu dure à trouver.
OpenVZ est maintenu par ceux qui font Virtuozzo (ils fournissent un miroir Debian avec les kernels binaires et les outils qui vont bien, même si les sources du patch et quelques outils existent déjà dans Debian) - le wiki est prolifique (pas forcément trop orienté Debian, puisqu'ils se concentrent sur les distros à RPM... m'enfin, ça ne change pas grand chose), le forum assez vivant : bref, là par contre, niveau doc, ça me paraît mieux. Niveau fonctionnalités (quotas, virtualisation et non simple isolaton du réseau, avec des possbilités de fous [pour moi, jusqu'ici utilisateur de VServer], comme d'avoir accès au broadcast dans le conteneur, de l'interface réseau physiquement gérée par le conteneur sans même que l'hôte n'y ait accès, bridging et routage avancés, conteneur pouvant être bridgé et écouter en promiscuous, par exemple, pour y mettre une sonde d'IDS, IPv6 [apparemment], iptables dans le conteneur, migration de conteneur sans interruption de service...) aussi... A noter qu'ils semblent plutôt travailler en bonne intelligence avec upstream, pour le kernel : pour le 2.6.26-rc1, 299 patches [1] sur les quelques 7500 de la release-candidate [2], soit environ 4% des patches upstream commités par l'équipe d'OpenVZ, essentiellement sur les namespaces, dans le cadre de l'intégration dans le noyau des fonctions qui lui permettront nativement d'embarquer de quoi compartimenter. Voilà qui mérite un "Kudos, OpenVZ ! Kudos !". Si toutes les boîtes qui bénéficient du libre, quand bien même elles proposent un truc proprio à côté, faisaient comme eux...
Si on n'a pas besoin de faire tourner des kernels différents, voire pire, si on ne peut pas le faire en accélérant matériellement (ce qui est faisable, mais lourd), et si on n'a pas trop de RAM à dépenser dans de la virtualisation complète, les conteneurs, c'est de la bombe : mangez-en ! Faudrait d'ailleurs que je fasse un journal quand j'aurai installé de l'OpenVZ sur des serveurs physiques, parce qu'aussi excellent qu'il ait l'air, niveau infos/publicité/... sur DLFP, c'est maigre [3].
[1] http://community.livejournal.com/openvz/22369.html
[2] http://kerneltrap.org/node/16101
[3] http://www.google.fr/custom?cof=AH%3Acenter%3BLP%3A1%3BLW%3A(...)
[^] # Re: Matériel supporté
Posté par Aefron . En réponse au journal [Darty] Putain de wifi. Évalué à 7.
D'autant que ce que tu veux existe : si tu te contentes de DHCP (pour l'instant... m'enfin, ça, au moins, ça couvre les besoins de l'utilisateur Lambda qui n'y connait rien en réseau, et qui a déjà eu du mal à faire fonctionner sa box fai qu'il n'a pourtant qu'à brancher), tu as NM, dispo par défaut dans, je pense, toutes les distros en mode click-click-suivant, et installable sur toutes les autres ; si tu veux te faire ta tambouille parce que tu es un gros geek qui alterne entre les réseaux DHCP, les IP fixes, qui veut que du NFS soit monté ici mais pas là, qui branche et débranche câbles et antennes à tour de bras en dansant nu et en sacrifiant un capriné, et cie, tu as les pre/post-up/down, ifplugd, guessnet et cie (mais il faudra suer un minimum de sang et d'eau... ce qui n'est pas grave, partant du postulat que tu es un gros geek si tu fais ça, puisque sinon, tu aurais NM)...
Maintenant, autant je veux bien admettre que le DHCP sans gestion du hotplug, ça me paraît un peu ballot, autant devoir se trimballer ifplugd et/ou consorts dans les paquets d'une base minimale, ça ne me tente pas trop... déjà que le tag en "important" de dhcp3-client dans Debian me paraît limite (je le verrais davantage en "standard"), s'il faut commencer à en bouffer encore plus, pour considérer que le roaming, où on se branche et se débranche à foison, est un cas par défaut, qu'il faut intégrer dans la base, quitte à la bloater et à se retrouver avec des serveurs qui embarquent NM... parce que bon, NM, quand il sera davantage fini, il sera assez ultime, je pense, dans le genre - maintenant, paye tes dépendances. Non, à choisir, j'éjecte le client DHCP de la base minimale.
[^] # Re: Matériel supporté
Posté par Aefron . En réponse au journal [Darty] Putain de wifi. Évalué à 3.
Ou c'est toi qui lui fais, pour avoir un truc aux oignons (j'installe et maintient bien de la Debian stable sur le PC de ma mère), mais tu ne fais le boulot de fignolage qu'à moitié ?
Non, parce que les pages de manuel, ça existe, et ça explique plutôt bien... genre "man interfaces", où on peut apprendre qu'une interface en auto (gérée par le ifup, donc entre autres par les scripts de démarrage), ce n'est pas la même chose qu'une interface qui autorise le hotplug (bon, là, faut aller à la page de manuel de ifup, qui indique que l'on peut faire ça avec hotplug, déprécié maintenant, et ifplugd, ce qu'il est conseillé d'utiliser)...
Maintenant, est-ce qu'un serveur en DHCP qui autorise le branchage à chaud est vraiment ce qu'on rencontre le plus quand on installe un serveur ? Bof, j'aurais plutôt tendance à mettre un serveur en IP fixe quand c'est possible (ça n'engage que moi), et à tout inspecter minutieusement si j'y activais des services comme DHCP (et donc, à activer encore un truc en plus si je voulais le hotplug par DHCP), ou du OSPF que j'ai bien envie de tester sur des OpenVZ (je suis curieux de savoir comment se comporterait un quagga, ou assimilé, dans un conteneur, qui servirait de gateway physique à la machine)...
... et de même, pour ta grand-mère... si tu ne veux vraiment pas te saouler, tu lui proposes un truc qui embarque NM, et qui va se contenter de choper un bail DHCP (tant que la version 0.7 n'est pas sortie), tout seul, et gérer le hotplug, tout seul, sans rien configurer comme un barbu, vu qu'il ne s'occupe que des cartes non gérées par le /etc/network/interfaces (ou qui y sont en auto et DHCP)...
Bon, pour ne pas être de mauvaise foi, je veux bien qu'on puisse regretter qu'à partir du moment où DHCP est activé, ifplugd et consorts ne le soient pas... c'est vrai que c'est un comportement auquel on pourrait s'attendre ; sauf que ça ajoute encore à gérer un truc (bazar, cathédrale, tout-ça) : le nommé ifplugd, ou networkmanager... Et après,lequel forcerait-on à utiliser par défaut (j'ai un peu de mal avec l'idée de NM sur un serveur... déjà que dhcp et ifplugd, bof) ? Est-ce que des gens se servent de DHCP sans hotplug ? ... c'est entre autres pour éviter d'avoir à me poser la question que je n'utilise pas de DHCP pour mes serveurs (et en pratique, d'ailleurs, nulle part chez moi) : toujours un truc de moins à gérer (et deux, d'ailleurs, avec le hotplug) - moins de bazar.
[^] # Re: Ca marche, ça marche plus
Posté par Aefron . En réponse au journal [Darty] Putain de wifi. Évalué à 2.
Après, si tu peux te permettre d'avoir une machine en plus pour faire un serveur, et y mettre ce qui ne doit pas casser, c'est quand même top...
Avec une Debian stable ou autres distros qui ne bougent pas pendant une longue période (selon ses affinités), voire, avec des conteneurs (mes deux Cups, encre et laser, en Debian stable, sont sur un hôte vserver, en Debian stable aussi, aux "côtés" de mythtv, de slimserver, de sane, d'un SSHd qui sert à faire du SSHFS et d'un NFS userland... et c'est tellement stable que j'ai envie de le secouer pour passer tout ça sous openvz que je découvre et dont je trouve la virtualisation réseau et la migration en live d'un invité super cools), ça permet d'avoir une base très stable, et de faire ses conneries ailleurs (toutes mes workstations sont en sid, en ce moment, pour diverses raisons... et ça me va très bien)...
[^] # Re: D'un autre côté
Posté par Aefron . En réponse au journal [Darty] Putain de wifi. Évalué à 8.
La nouvelle pile wifi n'est pas là depuis si longtemps, et pas mal de drivers libres, qui feront fonctionner nativement de plus en plus de cartes, sont encore jeunes... comme ath, par exemple. Il me semble que ce ne soit toujours pas la joie non plus avec ce qui vient de broadcom, mais les WRT54G m'ont vacciné pour un bon moment quant à réessayer de toucher à ce qui vient de chez eux, de toute façon.
Enfin, voilà, pour moi, de ce que j'ai vu, le plus gros problème avec le wifi, sous Linux, ce sont encore les drivers, souvent encore blobés, ou avec des firmwares non distribuables, ainsi que les frameworks pour les gérer (ce que nous a apporté la nouvelle pile wifi : plus besoin que chacun réinvente complètement son WPA et cie de son côté)... M'enfin, ça y travaille moult, comme partout dans le libre, aussi bien chez OpenBSD qui commence à implémenter WPA (PSK seulement, pour l'instant... pas que ce soit plus sékioure que du VPN, mais de quoi faire du VPN n'est pas embarqué partout, pas plus que tout ce qui a une antenne n'a un port ethernet sur lequel se rabattre), ou FreeBSD (qui commence à introduire des fonctions bougrement intéressantes, comme les VAP avec les drivers libres, pour faire plusieurs points d'accès distincts sur une seule carte, ou ce qu'il est possible de supporter dans 802.11n, même s'il n'y a pas encore de pilote pour ça... vivement la 7.1 ou la 8.0, d'ailleurs : ô oui : vivement ! Je vois bien un petit gros routeur/gateway/firewall/AP/... sous FreeBSD, que je découvre agréablement ces temps-ci, après avoir essayé d'autres Linux que de la Debian, et être promptement revenu aux sources, chez moi).
Après, certes : network-manager est très jeune aussi... il ne permet même pas de gérer les adresses statiques - je crois que ça doit venir pour la 7.0 qui devrait sortir bientôt, et qui je crois même à été pré-intégrée dans suse... D'ailleurs, c'est pour ça que je ne m'en sers pas encore, préférant une tambouille-maison à base de /etc/network/interfaces, de ifplugd pour le roaming, avec IP fixe pour chez moi, et de mignoneries geekesques dans le genre...
Maintenant, pour ce qui est des connexions faisant intervenir DHCP, ça marche plutôt pas mal depuis un moment. En tout cas sur ma Sid, dans "/usr/share/doc/network-manager/README.Debian", on peut lire (traduction libre) :
"Seuls les périphériques *non* listés dans /etc/network/interfaces ou qui y ont été configurés avec "auto" et "dhcp" (avec aucune autre option) sont gérés par NM.
Ainsi, vous pouvez définir une configuration personnalisée (statique) pour un périphérique, et NM n'essaiera pas de passer outre ce réglage."
Et honnêtement, c'est exactement comme ça qu'il se comporte sur ma machine : "DHCP et auto dans le "interfaces" ou "pas configuré dans le interfaces", c'est lui qui gère, sinon, c'est à la mimine de bout en bout. Bon, après, je ne sais pas si ça marche comme ça partout - mais au moins, sur mon laptop, quand je m'en sers, surtout pour tester, je sais exactement quand c'est lui, et quand c'est moi, qui gère... et sinon, il me semble aussi être tombé sur un /var/log/NetworkManager.log ou quelque chose comme ça sur une Fedora ou une Suse (je ne sais plus très bien), pour debuguer ; mais après, je l'ai dit : je ne touche pas du NM tous les jours, donc je ne garantis rien...
Cela dit, je suis bien tenté par l'essai de la 0.7, avec les IP fixes... le module VPN me tente également... s'il pouvait reconnaître les réseaux sur lesquels il est (avec du ping sur une adresse, ou une connexion à une certaine adresse MAC, à la ifplugd), et qu'on pouvait lancer des pre/post-up/down (peut-être que c'est déjà possible, en fait... je ne le connais pas assez pour ça, le manque d'adresses fixes me faisant trop défaut ), je m'en servirais vraiment en remplacement de mes scripts de barbu, et sans le moindre remord.
Nonobstant, sorti de ça, pour revenir sur les 3h pour installer un linux, je ne vois pas en quoi ça justifierait de nous forcer à acheter une licence de ouin-ouin. Ca veut dire quoi, ça ? Que si ce n'est pas accessible à un expert quelconque, ça impliquerait forcément que je suis trop con pour avoir le droit de m'en contenter ou d'essayer ? Et comme je serais irrévocablement, unilatéralement, forcément un con, il serait bien normal qu'on décide à ma place ce qui est bon pour moi, et que je me fasse mettre en étant forcé d'acheter un truc que, en l'occurence, pourtant, je n'utiliserai pas (j'interprète ce qu'ils disent, hein... je ne vois pas de problème à ne pas savoir, ou à ne pas vouloir savoir ; mais le message de darty me paraît clairement être du tonneau de "t'es trop con, de toute façon : mange tmon foin") ? Eh bien... Qu'est-ce que ce serait si ce n'était pas dans mon intérêt ?