Aefron a écrit 755 commentaires

Certes, il y a mieux à ce niveau (qui peut de toute façon dire faire mieux que Gentoo avec ses gentoo.org, gentoo-wiki.com et gentoo-portage.com ? )...

... mais c'est quoi, un vrai site internet ? Un truc avec des css touffues ?

Un truc tellement graphico-kikoolol qu'il utilise abondamment la transparence sans définir la couleur de fond (genre, le site de Mandriva, exquis, quand on a un fond noir par défaut... et encore, je ne parle pas du mélange de la Free et de la One dans le même répertoire, sur les miroirs... ça m'a fait drôle, d'installer fglrx sans m'en rendre compte, alors que je n'avais obtenu le lien du dépôt qu'en cliquant sur "j'veux du libre !" [oui, j'ai clické trop vite... mais à ce moment-là, fallait pas me demander "libre ou pas"]) ?

Un truc avec un wiki bourré de "chez moi j'ai fait ça, et ça aussi, même si ça n'a rien à voir, et si ça ne marche pas chez toi, fais sudo" (ahemmm... est-il vraiment besoin de préciser) ?

Au moins, le site de Debian permet de faire une recherche sur les paquets disponibles... si déjà toutes les distros (sur le site d'OpenSuse, j'ai au mieux un listing à-la-rache des DVD, sans info sur les dépendances, chez Mandriva je n'ai pas trouvé, chez Fedora non plus) pouvaient en faire autant... franchement, je suis accro du "deb:", raccourci web de recherche, dans Konqueror, sur les paquets Debian.

... et puis, il y a de très bonnes choses sur son wiki, comme le howto sur RandR 1.2, du XStrikeForce... Mieux vaut qualité ou quantité (note bien que j'ai exclus Gentoo de la discussion volontairement... évidemment, elle a les deux) ?

Bon, après, il y a un peu trop de rose à mon goût sur le site de Debian... oui, ça, OK... moi non plus, je n'aime pas le rose.

... 15 ans... 15 ans... va nous les briser pour avoir son scooter...

Mais ce que je m'en fous du débat rpm vs deb...

... très sincèrement, je fais de temps en temps des deb, et je n'ai pas eu le temps de me mettre aux rpm avant d'être saoulé par Fedora (pas que pour la gestion de paquets, même si packagekit, entre moults autres, a explosé au bout de quelques jours ; mais là n'est pas la question).

... reste que ce qui m'a ennuyé sur la gestion des paquets, c'est que yum ne gère pas les dépendances à la désinstallation. Tu peux dire ce que tu veux, c'est quelque chose qui manque, alors qu'il est chez d'autres (BSDs, Debian, ...)...

... et quand on vient de chez les autres et qu'on s'est habitué à ce "confort" (autant pour certaines utilisations, oui, limite, je m'en fous, autant, vu que j'utilise aussi des distros très instables, même si très fiables, comme Sid, qui ont des mises à jour énormes à faire pour peu que je les délaisse un poil, ce n'est vraiment pas du luxe que de ne pas vouloir d'inutilités sur ma machine... ça marche aussi si elle sert de conteneur à des dizaines d'autres, qu'il va falloir gérer aussi), il y a un manque. Et ce n'est pas à toi de me dire si c'en est un ou pas : c'est à moi que ça manque. Ce que je fais de mes machines, c'est quand même avant tout moi, que ça regarde... Voir à ne pas confondre les fanatiques.

C'est quand même dingue d'être de mauvaise foi au point de vouloir faire passer des pratiques à bloat pour une feature... Si j'utilise quelque chose qui a un gestionnaire de paquets qui prétend gérer les dépendances, je m'attends à ce qu'il fasse le boulot en entier, pas à moitié - d'autant que ça existe et que c'est répandu.

Admettre que c'est un manque n'est pas la mort, tout au contraire... la preuve, Mandriva va s'y mettre.



> Du côté de deb on a des fanatiques aveugles, du côté de rpm des pragmatiques ennuyeux. J'ai choisi mon camp.

Celui des fanatiques ennuyeux ?

> Mais pourquoi dis-tu que les serveurs ne tiendraient pas la charge ?

Parce que le système est déjà au taquet... cf les excellents liens sur le blog de Dan Kaminsky, donnés par Matthieu C ci-dessous (qui changent de la "merde de taureau" usuelle comme quoi "c'est trop génial, tout le monde a patché, on est trop saikioure").

... si la bande passante et le reste des ressources des serveurs root n'est pas dimensionnée pour encaisser le double de paquets, avec du statefull en prime, c'est de toute façon mort pour le moment. Pas plus TCP que DNSSEC ne sont alors implémentables en l'état...

C'est moche... mais on ne fait pas bouger les DNS root (et tout ce qui est derrière... toutes les boxes diverses et avariées ont-elles les moyens d'encaisser du DNSSEC de manière confortable ? Je n'en sais rien...) comme ça... déjà que c'est la merde pour ne serait-ce que savoir qui a le droit d'en avoir un sur son territoire... et ça prendra encore beaucoup de temps avant d'avoir quelque chose de propre à ce niveau, aussi capital qu'il soit...

M'enfin, le gros net mondial "sekioure", ce n'est pas comme si des gens sérieux croyaient que les homo sapiens (voire sapiens) étaient déjà arrivés à le mettre en place... ... ... si ?

> Ce n'est pas une limitation de RPM

Tout à fait... sauf qu'aucune des distros à base de RPM que j'ai essayées n'implémente la désinstallation automatique des dépendances inutiles ; il me semble que Mandriva va s'y mettre, pour sa prochaine version, à la rentrée - d'autres sont sûrement en train de le faire...

... mais quand on l'habitude que le bloat soit automatiquement désinstallé, c'est une vraie plaie que d'utiliser yum & cie...

Alors, certes, a priori, aucun rapport avec RPM (c'est plutôt au niveau du gestionnaire de paquets, de gérer ce qu'il fait à ce niveau)... mais c'est quand même une habitude tenace dans le "clan RPM"...



Sinon, non, ce n'est pas faisable avec yum-utils... ce machin ne fait que te lister les paquets qui ne dépendent d'aucun autre : pour les librairies, il est simple de trouver l'intrus (d'autant qu'il me semble qu'on peut filtrer pour n'afficher qu'elles, avec package-cleanup)...

... sauf que les dépendances ne sont pas forcément des librairies... et là, c'est le bordel pour savoir quels paquets tu as installé manuellement, lesquels sont venus en tant que dépendances, et lesquels étaient là avant que tu ne commences à installer quoi que ce soit...

Ce que fait package-cleanup, c'est du niveau du vieux deborphan... mais c'est à peine un ersatz de ce qu'on peut attendre d'une gestion des dépendances à la désinstallation.

Oui, enfin, pas grand chose d'étonnant, vu ce qu'ils ont lâché comme traffic sur le résolveur DNS.



Le problème est déjà inhérent à l'utilisation, pour quelque chose d'aussi crucial que la résolution de noms, d'un truc comme UDP, qui ne va garantir en rien que c'est bien la bonne personne qui nous répond ; surtout si les vilain-méchants sont en train de faire un DDOS sur le serveur qui a autorité à nous répondre, sur internet (typiquement, le serveur DNS du FAI) et le mettent à genoux...

Bon, on a quand même des contre-mesures... comme le TXID, qui va donner un numéro à la demande d'un nom à un serveur, et n'accepter que la réponse contenant ce numéro... sauf que 16 bits de contre-mesure, ça devient un peu léger, vu les vitesses des connexion actuelles, ainsi que l'ardeur et l'astuce que prennent les attaques...

... alors, pour donner du mou, tout le monde est plus ou moins passé aux ports sources aléatoires : en gros, on va changer le port par lequel on fait une demande à chacune d'elles, et de manière crytpologiquement aléatoire, ie, pas une simple incrémentation ou toujours le même port. Il devient alors plus difficile de deviner comment envoyer une fausse-bonne réponse à notre résolveur. Et zou, 16 bits en plus pour deviner comment créer une réponse plausible.

En gros, on essaye de ne pas écouter n'importe quoi, n'importe comment, mais sans authentification, et sur UDP : une technique de renard, certes, mais de renard galeux...



Maintenant, c'est un problème d'échelle : pour avoir une bonne contre-mesure, il faut avoir assez d'entropie pour rendre moins prédictible le forgeage d'une réponse, qu'il soit déraisonnable d'espérer empoisonner le cache... bon, maintenant, tout le monde essaye de faire sur 32 bits... youpi. Mais forcément, avec une connexion énorme sur laquelle écouter les réponses de tout et n'importe quoi, les 32 bits, ils deviennent faiblards... rien de bien neuf sous le soleil.

Après, surtout si on a une grosse connexion comme ça, on commence peut-être par filtrer les adresses auxquelles le resolver-cache est autorisé à poser des questions et recevoir des réponses, plutôt que d'autoriser n'importe qui à lui répondre n'importe quoi.

... et un jour, on pourra peut-être espérer avoir un accès authentifiant aux DNS externes auxquels on donne autorité... m'enfin, d'ici à ce que DNSSEC se généralise partout, vu qu'il semble qu'il faille déjà saluer l'ensemble de l'industrie pour avoir quand même mis 6 mois après de nouvelles méthodes bien plus dangereuses d'empoisonnement de cache, avant de rajouter 16 bits d'entropie à un truc bancal qui menaçait de plus en plus de se casser la gueule, on a le temps de voir passer quelques gros orages... Gare à toi, Tata Jeanine...

Ou alors, ils vont nous faire un truc du genre de ce qu'ils font avec les serveurs SMTP : on ne pourra contacter que les serveurs DNS de nos FAI... au passage, ça permettrait de faire un petit low-kick-balayette aux crypto-communistes qui se servent d'autres DNS pour passer outre les restrictions bienveillantes des autorités, même si ça n'empêcherait toujours pas de passer par Tor et de demander à l'exit-node de faire la résolution de nom lui-même...

Sans le "autoremove", ce n'est plus vraiment apt-get ; bon, tu me diras, les gestionnaires de paquets des machins de chez RedHat ne gèrent déjà pas ça, alors, le gérer pour les deb...

... et puis bon, c'est aptitude, la tendance actuelle...

D'où le problème... c'est paradoxal, de ne pas avoir le droit de manifester pour les droits de l'homme, dans un pays où la loi semble confirmer que c'est autorisé... parce que du coup, ce serait à se demander s'il ne vaudrait pas mieux manifester devant l'ambassade de France... en France...

... qu'est-ce qui s'en rapprocherait le plus ? Une préfecture ou un siège patronal ? ... damnaide ; c'est que c'est bien protégé aussi, ces conneries-là...



Au crédit de la Chine, pour se faire l'avocat du diable, ils ont au moins l'air de faire semblant de faire quelques efforts, malgré les répressions, la censure, les exécutions, les emprisonnements arbitraires et j'en passe (d'ailleurs, si on réunissait 1,3 milliards "d'occidentaux", s'il y en avait une définition claire et que c'était possible, on en trouverait à coup sûr chez qui au moins une de ces mignoneries aurait lieu)...

Mao est quand même mort depuis long, la bande des quatre a été jugée depuis long, et le grand bond en avant (sic) est aussi fini depuis long... Tian'anmen, cela fait presque 20 ans...

Il m'est arrivé de discuter quelques fois de leur pays avec des Chinois (dont un collègue de bureau, qui a un temps porté un pin's avec un dollar, mais qui a arrêté depuis), et aucun ne semblait être dupe non plus des graves problèmes qui y sont liés (sans nécessairement avoir le même avis que moi sur certaines choses)... mais tous m'ont dit avoir ressenti un progrès sur ces questions depuis leur jeunesse (tout en étant conscient que, pour venir en Europe, ils ne font certainement pas partie des plus défavorisés). A compter l'inertie du bousin qu'est ce pays, quand même...

... l'inertie... vu l'évolution que prend la mise en pratique des principes humanistes, en notre contrée, c'est le truc flippant, l'inertie... quand on en a moins, tout devient possible 'achement plus vite ...



[humour, je précise] Ah oui, sinon, le truc "marrant" : il est en flash, le site de RSF, même pour le texte... cocace, pour des défenseurs de la liberté de la presse... [/humour, je précise]

Autant cette BD est très sympa (comme son "Shenzhen", d'ailleurs), autant je ne suis pas sûr (attention : bougre de litote) qu'on y découvre la Corée du Nord...

... à la limite, ce qu'on autorise les visiteurs "professionnels" à en découvrir (et ce n'est déjà pas forcément jouasse)...

C'est un émulateur de terminal "à la Quake", ie qui est transparent (enfin, translucent) qui apparaît sur un bord de l'écran (en haut, par défaut), quand on en a besoin, et qui est caché le reste du temps...

... par contre, la dernière fois que je l'ai essayé (il y a quelques mois, sur une Debian testing), je l'ai quand même trouvé horrible et s'intégrant très difficilement dans le reste (une espèce de truc à skin, pour certains éléments... j'ai horreur des machins qui réinventent l'apparence des contrôles : ça s'intègre toujours très mal)... dommage, j'adore le concept, que j'avais d'ailleurs implémenté dans ma conf FVWM, via un rxvt (ou mrxvt, je ne sais plus), fut un temps.

TEAD, c'est quand même moins percutant que DTC... pfff... tout fout le camp...

> ah bon?

Ah, mais ils peuvent chercher dans plus de pages et trouver moins de choses intéressantes...

... oui, je sais, je -->[]

Je sais bien... c'est pour ça que je marchais sur des oeufs en parlant de "signal numérique pulsé" (et pas "d'ondes pulsées", hein)...

... pour bien insister sur le caractère non continu du signal numérique qui serait en cause dans les lésions dues à ces appareils...

Si tu avais l'occasion de faire un petit test, juste pour voir s'il y a une différence flagrante en débit, sur chaque ensemble de bandes de fréquences que permet ta carte, ne te gêne pas pour en faire un journal...

... je sais bien que la norme n'est pas finalisée, qu'elle sera implémentée très diversement, tout-ça... mais à chaque fois que j'ai cherché des choses sur le point où on en était avec ça dans le libre, je suis tombé sur des "on y travaille", sans vraiment arriver à voir où ça en était concrètement...

... parce que le 802.11g, c'est vraiment lent, lent, lent... ça marche, mais bon...

Sauf qu'apparemment, ce qui provoquerait des lésions n'est pas tant l'échauffement, mais le fait qu'on utilise ces ondes à hautes fréquences pour y pulser du numérique beaucoup plus lentement...

... et apparemment, ce serait ce signal numérique lentement pulsé que les cellules supporteraient mal ... enfin, plus mal que la même chose avec les champs "analogiques" qu'on bouffe depuis long (TV, radio, ... et même rayonnement solaire)...

Donc, oui, on savait que ça allait chauffer... mais pas de bol : il semble que ça n'ait rien à voir avec les problèmes sanitaires que ces appareils peuvent causer... Serges Karamazov, quoi : aucun lien, fils unique...

Ca faisait un moment que cette initiative de la stable-et-demi faisait parler d'elle, mais c'est une bonne nouvelle que ça se concrétise.

Par contre, si davantage de paquets apportant du nouveau support matériel pouvaient y être inclus, ce serait top...

... exemple : lcdproc ... en 0.4.5-1.1 dans Etch... et dans Lenny, jusqu'ici... mouais... et bien il y a de gros risques qu'il n'évolue pas de Etch à Lenny... Bon, soit : sauf que plein de LCD/OLED/..., qui se trouvent maintenant sur le marché, ne fonctionnent qu'avec un lcdproc>=5.0 (par exemple, mon OLED/récepteur IR IMON, loin d'être jeune, mais du plus bel effet sur mon HTPC... et il y en a plein d'autres)... si ça pouvait rejoindre Debian avant le successeur de Lenny, je ne cracherais pas dessus.

Le module pour faire marcher ce petit machin (lirc_imon) a beau être fourni comme il faut dans LIRC (enfin, sous forme d'un paquet source ; mais en faisant un petit coup de dpkg-reconfigure et de m-a, la compilation des modules qu'il faut s'automatise bien), il faut un démon plus récent pour profiter de l'écran, et pas seulement du récepteur IR... Bon, jusqu'ici, je l'ai compilé comme un grand (sous Etch), puis, je suis passé en Sid (par fainéantise)...



Enfin, ça permettra toujours d'installer une Etch sur une machine avec une mobo récente sans galérer avec les contrôleurs disques et ce genre de bazar de base, et en ayant un kernel supporté selon les standards de "stable"... ce qui est déjà d'une utilité remarquable.

... mais, sans vouloir descendre cette bonne initiative de stable-et-demi, au contraire, en voulant la critiquer constructivement, ce serait vraiment bien de voir tous les paquets apportant le support de nouveau matos rejoindre une stable-et-demi (après tout, ils font bien venir X.org, ce qui est bel et bon, X.org 7.1 étant plutôt très lent en opengl sur mon LCD Full-HD, avec une X800 à drivers libres... pourquoi pas tout ce qui relève du nouveau support ? Après tout, c'est quoi, des trucs comme lcdproc à côté du masto-clicko-donte ? )...

Ah, sympa, ça... j'ignorais complètement ; faudra que j'essaye avec une Atheros, si le dossier existe...

... là, sur mon laptop, avec une IPW2200BG sur une Sid, je n'ai pas la classe ieee80211, dans /sys.

Mais si ça commence à être géré, c'est du tout bon.

Il me semble qu'il faut aussi un support matériel dans les puces, pour ça, et que pour l'heure, seules les cartes Intel "récentes" et les Atheros le supportent (de ce que j'ai cru comprendre des discussions sur FreeBSD)...

... par contre, je n'ai encore rien lu sur l'intégration de ça dans la pile wifi de Linux (même si j'imagine bien que c'est prévu)... du coup, si quelqu'un a du concret là-dessus, je suis vraiment preneur d'infos ;)

Sans vouloir casser l'ambiance, mais plutôt relativiser, attention quand même : Atheros a dit vouloir terminer le driver avec la communauté... ie, il n'est vraiment pas fini.

... parce qu'en outre, ath9k ne supporte que le mode "station", ie "client" (ath5k supporte aussi le mode ad-hoc)... mais du coup, pas de point d'accès avec ce driver avant un petit moment... à voir pour le promiscuous aussi.

Pareil pour le 802.11n : ça supporte les chipsets 802.11n, mais probablement pas encore la norme ou plutôt la pré-norme (ça, ça aurait plutôt sa place dans la pile wifi de Linux : aucune idée d'où ça en est, d'ailleurs ; on m'a dit que ça commençait à être commité chez FreeBSD, pour la version qui devrait plus ou moins sortir dans un an, ie FreeBSD 8, mais je n'en sais pas plus que ça) ... ces chipsets 802.11n risquent donc encore de marcher longtemps à 2Mio/s au taquet, avec le vent dans le dos. Bon, c'est sûr : c'est infiniment mieux que rien.

Cela dit, il faut relativiser - toutes les cartes 802.11n ne supporteront a priori pas les mêmes plages de fréquences : Atheros fabrique du pre-N b/g/n, a/n et a/b/g/n - selon ce qu'on aura, ça promet un joyeux bordel quand on commencera à jouer avec ça ; faut pas rêver : avec du b/g/n (~2,4GHz), on ne se connectera pas à de l'a/n (~5GHz)... et selon ce qu'on aura, et ce sur quoi on voudra se connecter, débit, distance et résistance aux obstacles ne seront pas du tout du même tonneau.

Enfin, la caractéristique la plus intéressante de ces chipsets : les "Virtual Access Points", qui permettent de virtualiser la carte en plusieurs autres, chacune avec son chiffrement distinct... bah, ce n'est pas dans la pile wifi de Linux ni dans le driver, pour l'instant (il semble que ça commence à être intégré dans la pile wifi de FreeBSD, mais il est à noter que tous les chipsets wifi ne le supporteront a priori pas)...

Donc, oui, c'est une bonne nouvelle (dans la continuité des voeux d'Atheros à être supporté sous Linux), et au sujet de laquelle je me réjouis... mais ce n'est vraiment qu'un début... et je ne suis pas non plus arrivé à savoir si les chipsets étaient documentés ou pas (ils disent vouloir travailler avec la communauté, et ont certes embauché du monde juste pour ath5k et ath9k, mais écrire un driver ne fait pas tout).

Vu que personne ne semble être foutu de savoir si ce que j'ai dit est pertinent ou pas (moi non plus, sur le fond... je n'ai plus que de vieilles réminiscences de cette langue étrange), pas sûr qu'il n'y ait que lui qui se sente accablé...

En même temps, un MTA, si tu fais une installation sans toucher à rien, et donc en laissant les paquets tagués en "standard" ("aptitude search ~pstandard"), tu as probablement Exim4, comme MTA (d'ailleurs, même si je n'installe de taskseleries sur aucune de mes machines, chacune a son Exim, qui relaie au central)...

... et pour le configurer, "dpkg-reconfigure exim4-config" est ton ami : en deux coups de cuiller à pot (quelques questions en ncurse), hop, tu as un MTA fonctionnel, rapport à ce que tu veux en faire (on peut dire ce qu'on veut de la présence d'un gros MTA par défaut, au moins, il y a eu de l'effort sur la facilité à le configurer)...



Ca, c'est pour les machines sans clickodrome... pour celles avec, il y a reportbug-ng (ou gnome-reportbug, pour les gens qui ont des goûts étranges)... et là, pas besoin de MTA : un MUA suffit.



Maintenant, certes, si on pouvait soumettre les bugs Debian sans avoir à gérer un mail localement, via de la page web, ce serait classe quand même.

Oui, enfin, là, ce n'est pas aux logiciels qu'il manque quelque chose...

... c'est surtout qu'il faut quelqu'un capable de lire ta langue, pour corriger le bug que tu signales... parce que bon, si tu veux qu'on ouvre les rapports de bugs dans la langue de son choix, quitte à ce que personne d'intéressé ne puisse les lire... euh... c'est techniquement très faisable, mais comment dire ?

Tu proposes juste de déplacer le problème, là... parce que si tu ne peux pas écrire de rapports en anglais, qui te dit que les devs du projet parlent français ? Ca revient strictement au même, ce que tu proposes...

> c'est juste des "chez moi j'ai fait ça."

T'as oublié le grand classique : "si ça ne marche pas, fais sudo"... du grand art : si tu ne comprends plus où tu en es et ce que tu fais, agis avec les droits root...

Clairement, Krita est la petite bête qui monte...

... certes il y a encore des problèmes : par exemple, je n'arrive pas à ouvrir des gros projets Gimp (plein de calques, plein de pixels) avec lui...

Il y a certes aussi beaucoup moins de plugins que pour Gimp... après, on peut aussi parler de l'état de certains plugins de Gimp : genre, le filtre "flammes", pour faire des "fractales artistiques" - au-dessus de 2500x2500 (à peu près), il segfaulte depuis des années... et ne semble plus être maintenu depuis des années non plus (alors qu'il est génial ce filtre... damned)...

Maintenant, sorti de ça, j'aime beaucoup Krita... déjà, il est en QT (et ça, çaylebien)... par exemple, aussi, lui, au moins, il a les dossiers de calques (ce qui fait que je trouve Gimp, à défaut d'inutilisable, d'une lourdeur agaçante, quand on travaille des image avec au moins une dizaine de calques)... et je pense d'ailleurs vraiment, à terme, abandonner Gimp pour Krita.

Par contre, j'aimerais bien savoir ce que Krita a "d'expérimental, impraticable, inutilisable"... des arguments seraient donnés encore, je voudrais bien... mais là, c'est vraiment au ras des pâquerettes, comme troll.

Et pour marquer l'antériorité de son incompréhension (oui, parce que maintenant, ça va, il a compris), vis à vis de l'explication de la blague, on ne devrait pas plutôt utiliser le plus-que-parfait (plusquamperfekt) ?

Genre : "Ich hatte nicht verstanden" ...

Et puis, tant qu'on en est à Papa-Schultzer, pourquoi "Ah sooo" et pas "Ach sooo" ?