> D'après la description cela fait ce que tu recherche
Pas tout à fait : d'après la description, c'est l'équivalent de deborphan, ou rpm-find-leaves...
... sauf que, justement, je trouve ça trop archaïque : a priori, ça ne liste que ce qui n'est la dépendance de rien ; évidemment, ça pose problème quand on parle de dépendances autres que les librairies...
... parce que si on inclue les exécutables et les choses du genre, il va probablement nous en lister des tonnes qui ne sont pas des dépendances... ainsi, par défaut, le vieux deborphan ne s'occupe que des librairies. Sauf que les dépendances ne sont pas toujours des librairies (et puis, souvent, ce genre d'outils doit être exécuté plusieurs fois successives, pour arriver à tout détecter : un peu lourdingue). Sans parler des librairies qu'on a pu installer à la main, pour des choses qu'on a compilées : et bien là, sans pitié, elles seront listées.
L'équivalent de ce que je recherche, c'est plutôt l'option autoclean d'apt, ou aptitude... a priori, ça suppose de faire la différence entre ce qui est installé automatiquement, et ce qui est installé explicitement - mais ça, je pense que ça doit être intégré au gestionnaire de paquets, et à sa base de données. Un utilitaire externe qui tente de faire une tambouille, c'est malheureusement très loin d'être idéal.
> je voudrais bien voir la gueule de ta freebox quand ton blog prendra un peu de popularite
Bah oui... mais dire qu'on n'utilise pas sa connexion pour auto-héberger quoi que ce soit, parce qu'elle n'a pas assez de patate...
... ça élude le fait (je crois profondément que c'en est un) que les FAI ne veulent pas que trop de monde s'auto-héberge, et nous donnent de l'ADSL au lieu de SDSL...
Faut voir à ne pas se mordre la queue : on fait avec ce qu'on a ; et on n'a que ce qu'on nous fournit, en la matière.
C'est pour ça que j'ai mis des guillemets... je savais que c'était un truc un peu différent, mais je ne me souvenais plus du nom - merci pour le rappel.
> on peut avoir une bécane sans kmldonkey et n'utiliser que mldonkey-server à distance
C'est même fait pour ça... Le seul intérêt que j'aie à installer kmldonkey, c'est de me connecter à mon serveur mldonkey, tranquillement installé, tout seul, dans son conteneur (et bien entendu, ne tournant pas avec les droits root - je suis peut-être chiant, mais pas complètement idiot).
Je critiquais juste le choix de "packaging" de Debian en la matière, et en ai profité pour illustrer que la non désinstallation de la "dépendance" qu'est mldonkey-server pourrait être chiante (en fait, c'est un "Recommend"... alors que j'estime que ce devrait être un "Suggest", pour ne pas le voir installé par défaut sur les distros où les "Recommends" n'ont pas été désactivés, typiquement les machines à clickodrome)
> Je ne vois pas en quoi l'installation de encfs est un risque
Je le vois plus comme un risque en ce qu'on pourrait me demander ce que fout un truc pour gérer des partitions chiffrées, ou une appli P2P (pour mldonkey) sur ma machine... et me faire chier avec ça (pas mal de laptops disparaissent aux douanes d'aéroport... je ne pense pas qu'ils aillent jusqu'à vérifier ce qui est installé, mais sait-on jamais, avec ces zozos - bref, vivons heureux, vivons cachés ; la sécurité par l'obscurité ne se suffit jamais, mais il serait bête de s'en passer [sinon, autant balancer ses clés privées et cie])...
Pour moi, le risque est celui de la fuite d'informations quant à mes pratiques - ce qui suffit à me déranger.
> M'enfin, tu fais de l'"enculage de mouche".
Ah, mais, je ne le nie pas, hein. Je reste conscient que la désinstallation automatique des dépendances est "assez récente".
Mais je trouve ça ultra-utile quand même... et j'ai vraiment du mal à m'en passer. Clairement, c'est même le genre de trucs qui me ferait utiliser plus de distros différentes, si c'était plus répandu (CentOS a par exemple un long support [7 ans, je crois, non ?]... mais la gestion non-déterministe des dépendances à la désinstallation me rebute, quant à l'intégration avec mes scripts CFEngine ; je trouve ça trop limité, et pas vraiment gérable).
Bref, quand ça arrivera dans plus de distros, je serai dans les premiers à le saluer.
> on laisse ces paquets (soit disant inutiles) car ils ne gènent pas
Dans Debian, par exemple, tout ce qui est la base du système est marqué comme installé manuellement (au minimum, "aptitude search ~prequired"... il y a aussi les "~pimportant" et "~pstandard", dans une installation usuelle, mais ils ne sont pas indispensables au bon fonctionnement)... comme ça, pas de mauvaise surprise.
C'est "un peu" le pendant de la séparation système/ports chez BSD...
> gnome-desktop dépend de desktop-backgrounds. Mais si un utilisateur veut virer desktop-backgrounds
Ça, c'est l'affaire des mainteneurs... et leur choix...
Chez Debian, ils ont introduit les Recommends et Suggests, pour faciliter le travail de ceux qui ne veulent pas réfléchir, mais je ne suis pas fan du tout (mais je reconnais l'intérêt pour ceux qui veulent que ça "juste-marche")...
Bon, gérer ça, c'est lourd : complètement d'accord... mais la maintenance de paquets pour une distribution complète est lourde - rien de neuf sous le soleil.
> tu installes et désintalles plein de programmes. Mais ce n'est pas un usage courrant de GNU/Linux (sauf peut-être pour les moules dlfp)
Et comment tu testes des nouveaux paquets ? Dans une VM ? Et pour les trucs qui demandent un accès direct au matos ?
Et, franchement, l'installation frénétique de nouveaux paquets, je le vois tout le temps chez des utilisateurs pas trop expérimentés...
Toutes les machines ne sont pas des bouzins critiques en prod...
> Le quoi est : on s'en fout
Moui... un "quoi" teinté de "pourquoi"... ;) M'enfin, j'avais compris, en zieutant le bugzilla de RH (je n'arrive pas à retrouver la référence, mais le seul message de réponse était un "not a bug").
Comme je le disais, l'intérêt n'est pas que de gagner quelques Mio...
Le fait que les librairies restent (et en pratique, pas que les librairies, mais tout ce qui est dépendance... j'avais eu l'expérience de voir l'essentiel d'une appli de création de CD d'install Fedora rester malgré une désinstallation ; en fait, seul le "métapaquet" du groupe d'applis le permettant était désinstallé) peut en dire long sur ce qu'on fait de la machine.
Je ne connais pas l'état exact des dépendances pour kmldonkey sur d'autres distros (et je le cite uniquement à titre d'exemple), mais sous Debian, si on active les Recommends (ce dont je ne suis pas fan du tout), il fait venir mldonkey-server (ce que je trouve particulièrement idiot - mais c'est comme ça , heureusement, par défaut, il n'est pas lancé)... si les dépendances ne sont pas enlevées, en désinstallant kmldonkey, il reste mldonkey-server...
De même, si j'installe cryptkeeper, il me fait venir encfs comme dépendance...
Ce genre de choses, ça peut attirer la suspicion... et je n'ai pas envie de donner encore plus de raisons de me faire gratter mon laptop à la sortie de l'avion, juste parce qu'un jour, j'ai testé cryptkeeper ou kmldonkey.
C'est sans doute de la parano, mais je vois la non-désinstallation des dépendances comme une fuite d'informations privées... et je trouve qu'il y en a bien assez comme ça (je fais partie des gens qui adoreraient pouvoir activer un mode "je n'enregistre rien de privé" dans mon environnement de bureau : non ! Je refuse de stocker mes mots de passe, bookmarks, cache, mails et cie en local, sur mes stations à clickodrome - il y a bien assez de manières d'accéder à ça via un partage réseau sécurisé).
En outre, comme je le disais, si on laisse les dépendances s'accumuler, bonjour le bordel à l'autocomplétion (par exemple) dans /etc et /usr/share...
Sans parler de problèmes, fonctionnels ou sécuritaires, qui peuvent arriver quand on laisse les choses s'entasser... il me semble avoir déjà vu des applis supporter libgnutls et libssl en même temps, en se servant de l'une en priorité, quand les deux sont installées.
Si je veux n'en utiliser qu'une, parce qu'elle a tel ou tel avantage (genre, il me semble que gnutls ne supporte pas de gérer un répertoire de certificats, mais un seul certificat à la fois), ça peut causer un problème si ces libs sont présentes en même temps... au moins me faire perdre du temps, jusqu'à ce que je me rende compte de ce qui coince (autre exemple avec ces deux libs : les noms des méthodes de chiffrage ne sont pas les mêmes - me suis encore cassé les dents dessus ce weekend).
Il y a aussi qu'il est plus pratique de gérer ce qui est installé sur un parc de serveurs, quand la désinstallation des dépendances est déterministe.
En ce moment, je bidouille pas mal CFEngine, et j'apprécie de pouvoir spécifier clairement la liste de ce que je veux qui soit présent sur la machine : pour ce qui est des dépendances et des désinstallations, c'est transparent - je ne spécifie que les paquets que j'aurais installés manuellement... ainsi, si j'installe un truc juste pour voir, je sais que s'il n'est pas listé dans ce qui doit être présent, lui et tout ce qu'il aura fait venir sera nettoyé au prochain fetch de la configuration...
Par contre, si le système ne faisait aucune différence entre paquets demandés, et leurs dépendances, ce serait lourd... très lourd : je serais obligé de spécifier explicitement ce dont je ne veux pas, plutôt que de me contenter de dire ce que je veux (ou alors, inclure la liste des dépendances récursives dans la liste de ce que je veux, voire enlever la gestion des désinstallations de mes scripts... pfff... paye ta galère)...
Bref, gagner quelques Mio, en effet, m'en fous pas mal (et encore, il y a des cas particuliers - j'ai récemment testé de l'OpenVZ dans du Virtualbox, et j'ai eu des tas d'emmerdes parce que pas assez de secteurs dans les disques virtuels, par rapport aux quotas, même s'il y avait largement assez d'espace - j'avais installé plein de trucs, et je me demandais ce qui faisait que je ne pouvais me connecter en SSH dans le conteneur : en fait, la machine ne pouvait plus rien y écrire)... mais ce n'est pas pour ça que je veux une gestion rigoureuse des dépendances installées... ;)
Je sais que ça va contre les anciennes traditions... mais les traditions, ça évolue : et aujourd'hui, moult gestionnaires de paquets supportent ça (et même par défaut). Franchement, j'aimerais vraiment voir cette fonctionnalité supportée dans des distros comme CentOS, parce que, aujourd'hui, c'est peu ou prou tout ce qui m'empêche de les utiliser (comme je le disais, quand on a goûté à quelque chose d'aussi pratique, difficile de revenir en arrière).
Donc, si la seule raison est la tradition, qui demande de moins bonnes pratiques que ce qui se fait maintenant : pourquoi pas ? Que ce soit possible n'est censé empêcher personne de faire comme avant (au moins jusqu'à ce que ça devienne la nouvelle tradition)...
Si tu installes manuellement, tu te passes ipso facto du gestionnaire de paquets...
... donc, pour les dépendances tu es en slip : à toi de gérer ce qui doit et ne doit pas être là... et si tu remplaces une vérification attentive des dépendances utiles par la supposition que "jusqu'ici tout va bien" (alors qu'en fait, que les dépendances soient là n'est juste qu'un heureux concours de circonstance), j'aurais tendance à dire que tu mérites que ça te retombe dessus.
Avec Debian, par exemple, si je compile et installe manuellement quelque chose avec un "configure;make;make install", et qu'il me faut des dépendances, je les installe manuellement : de fait, si je retire quelque chose qui a aussi ces dépendances, vu qu'elles auront été installées manuellement (ou simplement marquées comme installées manuellement : on ne vas pas se prendre la tête si elles sont déjà là), elles ne seront pas retirées, hein...
Maintenant, gérer les dépendances à la main est chiant, et c'est pour ça qu'en ces situations, faire un paquet qui listera les besoins en dépendance, c'est infiniment plus propre.
Bon, après, chacun fait comme il veut : FreeBSD a pkg_deinstall, qui permet la désinstallation automatique des dépendances ; il me semble qu'OpenBSD ne l'a pas... on peut très bien donner le choix à ceux qui veulent crader leur système de ne pas désinstaller les dépendances.
Mais le faire est une bonne pratique... et que ce soit fait automatiquement, une bénédiction. Si je peux comprendre que c'est un changement auquel certains ne sont pas prêts, je ne comprends pas qu'on puisse refuser d'implémenter une chose aussi essentielle, et courante, dans les gestionnaires de paquets modernes.
> il faut un systeme 'pur': c'est a dire gerer uniquement avec les packages
Hein ? Par opposition à quoi ?
Un système où on a compilé des choses ?
D'une, on peut compiler pour faire un paquet (c'est même la manière propre de faire, dans quelque distro qui comprennen le concept de dépendance)... donc, là, les dépendances, ça se passe de la même manière que les paquets de la distro.
Et sinon, si on fait avec un make, et bien, on installe manuellement les dépendances, via des paquets, ou en les compilant aussi :
- dans le premier cas, ce sont des paquets installés manuellement (donc, pas de raison de les virer... et pour s'y retrouver, on regarde la base de donnée des paquets, et on voit qu'ils ont été installés manuellement, si celle-ci est capable de faire la différence entre installation manuelle ou automatique)...
- dans le deuxième cas, ça ne regarde pas le gestionnaire de paquets, puisqu'il n'y a pas eu de paquet...
J'ai déjà vu cette "raison" sur le bugzilla de RH... pour moi, c'est bidon. Qu'ils veuillent rester à une gestion arriérée des dépendances (éliminatoire, maintenant que j'ai goûté à une gestion complète), OK... mais ça n'est pas un argument, surtout quand tant d'autres le font.
Et comme je l'ai dit au-dessus, il y a des autres raisons (bien plus valables) que le gain de place...
Bref, pour moi, c'est un bug (et un très très gros)... prétendre que c'est une feature n'y change rien.
Pour Tor, tu peux chercher la liste directement sur leur site...
... pour le reste, je n'en sais rien : les moyens d'anonymats, il m'arrive d'en utiliser (et je fais tourner un relai Tor... tout autant que je suis de plus en plus intéressé par un tunnel Relakks, qu'il est fort probable que je me procure d'ici mars) - mais jamais de chercher à les filtrer ;)
Ah, mais, tant qu'ils ne me font pas signer de truc à la con, et qu'en cas de pépin, je suis couvert, moi, ça me va, la date de naissance...
... par contre, s'ils me reprochaient de ne pas avoir assez protégé ce qui est contenu dans mon état civil (c'est certes une information personnelle : mais certainement pas un secret), là, ça chierait - façon ebola dans leur face.
_Ils_ utilisent une solution merdeuse pour _se_ protéger : ils ont plutôt intérêt à assumer jusqu'au bout.
... je n'ai rien contre, pas plus que pour, les RPM (et ma question ne les concerne pas directement)...
Mais il y a un truc qui me gêne profondément avec tous les gestionnaires de paquets qui les utilisent, et que j'ai testés : la suppression des dépendances inutiles.
Genre, j'installe A, qui fait venir B (lui même faisant venir B1, B2, ... Bi, et ainsi de suite) et C. Puis j'installe A', qui fait venir C. Si j'enlève A, je voudrais qu'il enlève automatiquement B, et les dépendances que seul B utilise (B1, B2, ... Bi... et les dépendances que seuls eux utilisent), mais surtout pas C, ni A' (et je ne veux pas entendre parler de machins qui vont rechercher les libs qui ne sont des dépendances de rien... parce que même si je les enlève, il restera, encore, leurs dépendances ; et puis, ça ne résout pas le problème des dépendances qui ne sont pas des librairies : bref, ce n'est pas une solution, c'est de la bidouille, et encore...).
J'avais testé Mandriva, Suse et Fedora il y a à peu près un an, et aucune ne gérait ça. Mandriva parlait d'introduire une gestion des dépendances à la désinstallation, à l'époque, mais je n'ai rien trouvé quant à ce qu'il en est maintenant... donc quid ?
Quitte à le préciser, je ne cherche pas à troller, ou à descendre qui que ce soit : dans l'usage que j'en ai, il fait partie de mes _exigences_ d'avoir un déterminisme carré quant aux paquets installés (apt, aptitude, paludis, ... le permettent - pas moyen de revenir en arrière une fois que j'y ai goûté ; ne pas avoir ça est éliminatoire en ce qui me concerne)... je veux juste savoir ce qu'il en est : pas plus - pas la peine de monter sur des chevaux de quelque taille que ce soit, en m'expliquant comme il a déjà été fait que je dois "dire ce dont j'ai besoin, pour qu'on m'explique en quoi c'est inutile".
Ça l'est sans doute pour certains, mais je ne saurais m'en dispenser... fuite d'informations quant à mes pratiques (avec ça, facile de savoir que j'ai testé la création de CD d'install ou des méthodes de chiffrage sur mon laptop, par exemple), bordel dans /etc ou /usr/share, ... mes raisons sont multiples, et ce n'est pas le "pourquoi" qui m'intéresse dans ce post : juste le "quoi".
Ce sont les proxies ouverts à tout le monde... selon les pays dans lesquels ils sont, les utiliser rend le traçage de ce que tu fais plus difficile...
... par exemple, en Suède, on ne peut demander la correspondance d'une IP avec une personne que si ce qu'on a fait de la connexion est passible d'au moins deux ans de tôle (c'est là-dessus que ce base par exemple relakks, qui est plus un VPN qu'un proxy - m'enfin, c'est pour imager).
Cumule VPNs, proxies et darknets, et pour remonter à toi, ça va être un peu coton (pas infaisable, mais pas à la portée du premier grouillot venu).
Cependant, il y a des blacklists des IP de ces proxies, des IP des noeuds de sortie des darknets, etc (genre, à un moment, LDLC m'interdisait l'accès à leur site, alors que je n'étais qu'un relai Tor [même pas un noeud de sortie])...
> Voyons voir quel genre de bugs on peut trouver dans Unstable...
Bug de 2002... En deux ans de Sid, le truc le plus proche que j'ai vu est une mise à jour de grub, qui cassait le MBR : corrigée dans la journée (et puis, quand on est sous Sid, apt-listbugs n'est pas fait pour les chiens)... nul n'est parfait, mais mon expérience me dicte que ce genre de trucs est rarissime.
> Voyons ce que Debian lui-meme dit de unstable
Et si tu la connaissais un peu mieux, tu saurais que c'est la première du trio Stable/Testing/Unstable à voir les mises à jour des paquets... dont, ô surprise, les mises à jour de sécurité. Ça fait aussi que c'est la première dans laquelle rentrent des paquets avec des problèmes de sécu (c'est le principe : c'est celle par laquelle tout rentre)... maintenant, quand une faille ou chose du genre est identifiée, Sid est en général la première sur laquelle c'est résolu... bref, en pratique, cet avertissement n'est pas très représentatif des faits.
Quant aux problèmes de dépendances, c'est extrêmement rare, et s'il y a un problème, il y a juste à connaître la différence entre "aptitude safe-upgrade" et "aptitude full-upgrade" (le premier ne met à jour que ce qui ne nécessite d'enlever aucun paquet, le second, qui est censé se lancer à la suite, en ouvrant les mirettes, peut supprimer des choses, et requière un peu plus d'attention... maintenant, 99,9% des mises à jour se satisfont d'un simple safe-upgrade ; et en général, le full-upgrade ne fait rien de méchant, même sous Sid)...
Et puis, arrête ta fixette sur Unstable : si tu veux du très utilisable, Testing (que je n'ai jamais vue cassée) suffit déjà amplement (Stable, c'est même du hardcore-rock-utilisable, mais en effet : les choses y sont plus vieilles... et tu sais quoi ? C'est même le but !)... les seuls points à y surveiller sont la reconfiguration des choses mises à jour (exactement comme sous un OS redmondien sur lequel on met à jour ce qui est au-dessus du système... 'fin, "exactement : on a un gestionnaire de paquets pour nous y aider, quand même : et pas n'importe lequel - un des meilleurs), et les mises à jour de sécu (qui vont commencer à exister pour la prochaine Testing, quelque temps après la sortie de Lenny, la nouvelle stable)...
> Voila, je crois que ca dit tout
Oui : ça confirme que tu déblatères des inepties sans rien y connaître...
... autant j'apprécie certaines de tes interventions pondérées, autant, là, tu dis de la merde, et en aveugle : point.
Installe des Debian, apprends à les utiliser (pas très dur : je l'ai appris à plein de gens qui en avaient marre de leur truc redmondien, et qui voulaient autre chose - je n'ai pour ainsi dire jamais à repasser derrière eux ; ils gèrent leur Testing aux petits oignons, sans pourtant y connaître moult), et tu verras en quoi, sur ce coup, tu te lourdes en long, en large, et en travers.
Tout n'est pas parfait sous Linux ; je suis dans les premiers à le reconnaître... mais ce n'est pas en FUDant qu'on le démontre.
Ou alors, c'est ta banque qui n'y est pas encore passée...
Personnellement, depuis ~octobre/novembre (je crois), tous les sites sur lesquels j'achète finissent par m'afficher le biniouk 3day-sekioure (apparemment, c'est le serveur de ma banque qui gère cette page)...
... le premier ayant été un site italien, pour des lecteurs de smartcards...
> c'est pas le cas de Debian, car si tu veux des softs recents t'es oblige de passer en instable
Outre le fait que, rapport à ce que tu disais au-dessus, passer en Unstable ne fout absolument pas le moindre bordel dans le système (je ne dirais pas la même chose d'Experimental... m'enfin, il n'y a même pas tous les paquets, dans cette saveur), là, tu te plantes encore...
Bienvenue dans le merveilleux monde de l'apt-pinning : on peut installer juste des bouts d'Unstable dans Testing ou Stable, pour ce qui nous suffit... Et oui : c'est fou, ce qu'on peut faire, avec un gestionnaire de paquets (tout autant que c'est fou de ne même pas en avoir, ou alors, un ersatz, pour quelques correctifs)...
En plus, Testing va bientôt gagner un support de sécurité, donc, au prix d'un peu de maintenance en plus (gérer les changements dans les fichiers de conf... m'enfin, ce serait pareil pour les applis qu'on met par-dessus un os redmondien), il sera bientôt une pratique relativement saine d'avoir de la Testing sur un serveur (voire des bouts de Testing avec pinning, dans une Stable)...
Perso, je ne connais que très peu les OS redmondiens (la dernière fois que j'en ai installé un, ça remonte à 5 ans... et il ne doit m'arriver qu'une ou deux fois par an d'en utiliser)... du coup, j'évite d'en parler : ça m'évite au passage de raconter des inepties...
Mea culpa... je suis un âne : j'avais oublié le TLSCACertificateFile dans le slapd.conf (et donc, le serveur ne pouvait vérifier la signature du certificat du client... je ne l'avais mis que dans le ldap.conf, ce qui est inutile pour le serveur)... ldapsearch marche donc nickel sur Lenny avec gnutls, SASL, et des certificats clients...
... par contre, en effet, PowerDNS n'a pas l'air du tout de vouloir s'authentifier via SASL... j'arrive à lui faire charger un .ldaprc en spécifiant la valeur $HOME dans le script d'init (un peu goret, mais c'était juste pour voir), mais il semble se foutre éperduement de TLS_CERT, TLS_KEY et SASL_MECH...
Apparemment, il ne gère pas SASL, qui interdit le "bind" anonyme, mais qui n'implique pas davantage de spécifier un CN sur lequel "binder" (en tout cas, en "EXTERNAL" ; il y a juste un mapping à faire dans la conf du server entre le CN du certificat, et ce sur quoi on veut binder : ça ne regarde donc pas le client)... Et pour PowerDNS, il semble que le seul choix soit entre un "bind" anonyme, et un "bind" explicite, avec des mots de passe tout pourris...
Bref, j'ai avancé, mais c'est toujours la loose... Bon...
Nop... Orange, qui est au final ce qui marche le mieux dans mon petit village de cambrousse (saloperie de monopole sur les infrastructures en cuivre... quant au dégroupage, je peux l'attendre)...
... bon, ça marche bien (bon débits, bon ping, bonne disponibilité), mais pas d'IP fixe (ou hors de prix), pas de reverse (même si on paye une IP fixe la peau du zgeg... c'te honte !), ni plus d'IPv6 que de port 25...
... c'est un truc que toutes les banques se mettent à rajouter...
De ce que j'ai compris, ça permet à la banque de ne plus avoir à se retourner vers le commerçant en cas d'utilisation frauduleuse de la carte d'un client...
En gros, avant, en cas de magouille avec une CB d'un de ses comptes, une banque se retournait vers la banque du commerçant, puis celle-ci, vers le commerçant, qui finissait par avoir dans le baba l'objet envoyé ET l'argent perçu...
Maintenant, seule la banque du détenteur de la carte est responsable, et du coup, elle pose une "sécurité" en plus... vu qu'en cas de pépin, elle ne peut plus se retourner contre le vendeur (je trouve ça plutôt normal), elle veut "s'assurer" que le payeur est bien le détenteur de la carte...
Sauf que, la mienne, de banque, est d'une crétinerie franche, dans l'application de 3D Secure : le code en plus est ma date de naissance... ce que je ne qualifierais pas vraiment d'information personnelle secrète (grave au contraire !)... j'imagine qu'ils auraient pu filer un calculateur OTP, ou un truc du genre, mais non : à la société géniale, être nase, c'est une histoire de compétition, et on n'en a pas honte... Bon, par contre, pour l'instant, je n'ai rien eu à signer de nouveau.
M'enfin... Si d'autres banques semblent un peu moins légères dans cette affaire, d'après Wikipedia [1], si la mienne me demandait de prouver que le moyen d'authentification a été "utilisé frauduleusement", ça irait quand même assez vite : je leur répondrais que si j'avais eu à choisir une information secrète, je n'aurais certainement pas pris ma date de naissance, donnée qui traîne un peu partout (notamment sur mes papiers d'identités... dans le même portefeuille que ma CB... voire dans mon profil, sur des sites d'achat en ligne), et en haut du classement des mots de passe les plus crétins qui soient, avec le nom de son animal familier et autres conneries du genre "1234" ou "toto"... et que la faute incomberait intégralement, de fait, à la crasse de leur incurie. Et hop.
En même temps, le MX, c'est pour savoir où envoyer les mails... et mon port 25 est bloqué - pas d'IP fixe (donc galère pour les A, les MX et cie), et pas de port 25 : c'en est tristement cohérent...
... donc, pour les adresses@mon_domaine, je laisse mon registar (qui m'en "offre" 5, plus 1000 redirections) gérer, et je mets son MX pour mon domaine... et si je louais un serveur dans un datacenter pour mes mails, il aurait une IP fixe, donc ça irait aussi.
Ce qui ne m'empêche pas d'avoir un autre MX pour le sous-domaine dont je me sers chez moi (purement local, du point de vue DNS - du moins en tant que MX, car c'est aussi mon relai SMTP-AUTH vers celui de mon FAI, et donc : il est publiquement listé dans les machines de mon domaine, via un CNAME vers mon no-ip ; mais c'est tout)...
> Dans ta conf de bind au lieu de mettre une IP fixe tu mets une adresse no-ip ?
Dans le fichier de zones chez mon registar (Gandi), je déclare que les hôtes de mon domaine qui pointent vers chez moi sont des CNAME vers mon DNS no-ip, qui pointe par ailleurs sur (surprise !) mon IP... et hop.
Bon, l'idéal serait de pouvoir renseigner Gandi directement sur mon IP dynamique, via un client quelconque (comme ça, je pourrais avoir directement un A vers chez moi, au lieu d'un CNAME qui pointe vers un A)... mais Gandi ne le gère pas encore (ils avaient parlé de commencer à le gérer cette année, sur leur forum... à voir).
Ah : penser aussi à mettre un faible TTL (5 minutes pour moi... avec l'intervalle de 5 minutes avec lequel je checke contre no-ip, ça fait au pire 10 minutes d'indisponibilité à chaque changement d'IP)...
> Question subsidiaire : est-ce que no-ip casse les pieds comme dyndns à devoir cliquer sur un lien chaque mois pour garder un compte actif ?
Cliquer, non... mettre à jour l'enregistrement (utiliser le service, quoi), oui (je ne me souviens plus du délai jusqu'à expiration du nom, par contre). En outre, c'est bien plus fiable que dyndns, de ce que j'ai testé.
> « Pour moi la barre des tâches doit afficher le titre des fenêtres ».
Pour m'y retrouver, je préfère une miniature des bureaux... à vrai dire, le seul usage de la barre à tâches que j'ai, c'est de savoir quels fenêtres sont minimisées (elles sont grisées)...
En outre, même avec un 24" en 16/10 et une barre horizontale, vu tout ce que j'ouvre en même temps, il n'y aurait de toute façon pas assez de place sur une ligne, voire deux, pour lire complètement le titre de la fenêtre... aussi, avoir le détail de tout ce qui est marqué (d'autant que je peux l'avoir en passant la souris au-dessus de la tâche), m'en fous.
> Ta barre fait 72 pixels de large ? Pour du texte c'est trop peu
Pas quand on se fout d'y mettre des tartines... mon but n'est pas d'y lire du Flaubert...
> pour une barre sur le côté c'est beaucoup trop accessible
Ah, mais, c'est un des buts !
> ça prend une place monstre
Sur le côté, j'en ai _toujours_ assez... par contre, en hauteur, je n'en ai _jamais_ assez... donc, quitte à prendre de la place avec une barre, autant que ce soit où j'en ai le moins besoin...
Bref, je n'ai jamais compris ce truc des barres horizontales... j'ai du mal à voir plus inergonomique.
[^] # Re: Et sinon...
Posté par Aefron . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 2.
Pas tout à fait : d'après la description, c'est l'équivalent de deborphan, ou rpm-find-leaves...
... sauf que, justement, je trouve ça trop archaïque : a priori, ça ne liste que ce qui n'est la dépendance de rien ; évidemment, ça pose problème quand on parle de dépendances autres que les librairies...
... parce que si on inclue les exécutables et les choses du genre, il va probablement nous en lister des tonnes qui ne sont pas des dépendances... ainsi, par défaut, le vieux deborphan ne s'occupe que des librairies. Sauf que les dépendances ne sont pas toujours des librairies (et puis, souvent, ce genre d'outils doit être exécuté plusieurs fois successives, pour arriver à tout détecter : un peu lourdingue). Sans parler des librairies qu'on a pu installer à la main, pour des choses qu'on a compilées : et bien là, sans pitié, elles seront listées.
L'équivalent de ce que je recherche, c'est plutôt l'option autoclean d'apt, ou aptitude... a priori, ça suppose de faire la différence entre ce qui est installé automatiquement, et ce qui est installé explicitement - mais ça, je pense que ça doit être intégré au gestionnaire de paquets, et à sa base de données. Un utilitaire externe qui tente de faire une tambouille, c'est malheureusement très loin d'être idéal.
[^] # Re: Hey
Posté par Aefron . En réponse au journal en attendant le vendredi 13 février à 23h31 et 30s. Évalué à 10.
Et zéro ! Le Néant !
Ah, bah, forcément ! Les chiffres parlent d'eux même... Je me demande ce qu'en pensent Rael, les scientologues, les Petits Gris, et les Incas...
[^] # Re: rigolo
Posté par Aefron . En réponse au journal [HS] Stallman à propos du logiciel "privateur" vs privatif. Évalué à 4.
Soit "Justement !"...
... soit "Très souvent, autour des heures d'ouverture et de fermeture des bureaux"...
Pas facile, comme question.
[^] # Re: Auto hébergement
Posté par Aefron . En réponse au journal Tout le monde a intérêt à transformer Internet en Minitel. Évalué à 5.
Bah oui... mais dire qu'on n'utilise pas sa connexion pour auto-héberger quoi que ce soit, parce qu'elle n'a pas assez de patate...
... ça élude le fait (je crois profondément que c'en est un) que les FAI ne veulent pas que trop de monde s'auto-héberge, et nous donnent de l'ADSL au lieu de SDSL...
Faut voir à ne pas se mordre la queue : on fait avec ce qu'on a ; et on n'a que ce qu'on nous fournit, en la matière.
[^] # Re: Et sinon...
Posté par Aefron . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 2.
Et, ça supprime aussi les dépendances des dépendances (récursivité, quoi) ?
[^] # Re: Et sinon...
Posté par Aefron . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 2.
C'est pour ça que j'ai mis des guillemets... je savais que c'était un truc un peu différent, mais je ne me souvenais plus du nom - merci pour le rappel.
> on peut avoir une bécane sans kmldonkey et n'utiliser que mldonkey-server à distance
C'est même fait pour ça... Le seul intérêt que j'aie à installer kmldonkey, c'est de me connecter à mon serveur mldonkey, tranquillement installé, tout seul, dans son conteneur (et bien entendu, ne tournant pas avec les droits root - je suis peut-être chiant, mais pas complètement idiot).
Je critiquais juste le choix de "packaging" de Debian en la matière, et en ai profité pour illustrer que la non désinstallation de la "dépendance" qu'est mldonkey-server pourrait être chiante (en fait, c'est un "Recommend"... alors que j'estime que ce devrait être un "Suggest", pour ne pas le voir installé par défaut sur les distros où les "Recommends" n'ont pas été désactivés, typiquement les machines à clickodrome)
> Je ne vois pas en quoi l'installation de encfs est un risque
Je le vois plus comme un risque en ce qu'on pourrait me demander ce que fout un truc pour gérer des partitions chiffrées, ou une appli P2P (pour mldonkey) sur ma machine... et me faire chier avec ça (pas mal de laptops disparaissent aux douanes d'aéroport... je ne pense pas qu'ils aillent jusqu'à vérifier ce qui est installé, mais sait-on jamais, avec ces zozos - bref, vivons heureux, vivons cachés ; la sécurité par l'obscurité ne se suffit jamais, mais il serait bête de s'en passer [sinon, autant balancer ses clés privées et cie])...
Pour moi, le risque est celui de la fuite d'informations quant à mes pratiques - ce qui suffit à me déranger.
> M'enfin, tu fais de l'"enculage de mouche".
Ah, mais, je ne le nie pas, hein. Je reste conscient que la désinstallation automatique des dépendances est "assez récente".
Mais je trouve ça ultra-utile quand même... et j'ai vraiment du mal à m'en passer. Clairement, c'est même le genre de trucs qui me ferait utiliser plus de distros différentes, si c'était plus répandu (CentOS a par exemple un long support [7 ans, je crois, non ?]... mais la gestion non-déterministe des dépendances à la désinstallation me rebute, quant à l'intégration avec mes scripts CFEngine ; je trouve ça trop limité, et pas vraiment gérable).
Bref, quand ça arrivera dans plus de distros, je serai dans les premiers à le saluer.
[^] # Re: Et sinon...
Posté par Aefron . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 2.
Dans Debian, par exemple, tout ce qui est la base du système est marqué comme installé manuellement (au minimum, "aptitude search ~prequired"... il y a aussi les "~pimportant" et "~pstandard", dans une installation usuelle, mais ils ne sont pas indispensables au bon fonctionnement)... comme ça, pas de mauvaise surprise.
C'est "un peu" le pendant de la séparation système/ports chez BSD...
> gnome-desktop dépend de desktop-backgrounds. Mais si un utilisateur veut virer desktop-backgrounds
Ça, c'est l'affaire des mainteneurs... et leur choix...
Chez Debian, ils ont introduit les Recommends et Suggests, pour faciliter le travail de ceux qui ne veulent pas réfléchir, mais je ne suis pas fan du tout (mais je reconnais l'intérêt pour ceux qui veulent que ça "juste-marche")...
Bon, gérer ça, c'est lourd : complètement d'accord... mais la maintenance de paquets pour une distribution complète est lourde - rien de neuf sous le soleil.
> tu installes et désintalles plein de programmes. Mais ce n'est pas un usage courrant de GNU/Linux (sauf peut-être pour les moules dlfp)
Et comment tu testes des nouveaux paquets ? Dans une VM ? Et pour les trucs qui demandent un accès direct au matos ?
Et, franchement, l'installation frénétique de nouveaux paquets, je le vois tout le temps chez des utilisateurs pas trop expérimentés...
Toutes les machines ne sont pas des bouzins critiques en prod...
> Le quoi est : on s'en fout
Moui... un "quoi" teinté de "pourquoi"... ;) M'enfin, j'avais compris, en zieutant le bugzilla de RH (je n'arrive pas à retrouver la référence, mais le seul message de réponse était un "not a bug").
[^] # Re: Et sinon...
Posté par Aefron . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 2.
Le fait que les librairies restent (et en pratique, pas que les librairies, mais tout ce qui est dépendance... j'avais eu l'expérience de voir l'essentiel d'une appli de création de CD d'install Fedora rester malgré une désinstallation ; en fait, seul le "métapaquet" du groupe d'applis le permettant était désinstallé) peut en dire long sur ce qu'on fait de la machine.
Je ne connais pas l'état exact des dépendances pour kmldonkey sur d'autres distros (et je le cite uniquement à titre d'exemple), mais sous Debian, si on active les Recommends (ce dont je ne suis pas fan du tout), il fait venir mldonkey-server (ce que je trouve particulièrement idiot - mais c'est comme ça , heureusement, par défaut, il n'est pas lancé)... si les dépendances ne sont pas enlevées, en désinstallant kmldonkey, il reste mldonkey-server...
De même, si j'installe cryptkeeper, il me fait venir encfs comme dépendance...
Ce genre de choses, ça peut attirer la suspicion... et je n'ai pas envie de donner encore plus de raisons de me faire gratter mon laptop à la sortie de l'avion, juste parce qu'un jour, j'ai testé cryptkeeper ou kmldonkey.
C'est sans doute de la parano, mais je vois la non-désinstallation des dépendances comme une fuite d'informations privées... et je trouve qu'il y en a bien assez comme ça (je fais partie des gens qui adoreraient pouvoir activer un mode "je n'enregistre rien de privé" dans mon environnement de bureau : non ! Je refuse de stocker mes mots de passe, bookmarks, cache, mails et cie en local, sur mes stations à clickodrome - il y a bien assez de manières d'accéder à ça via un partage réseau sécurisé).
En outre, comme je le disais, si on laisse les dépendances s'accumuler, bonjour le bordel à l'autocomplétion (par exemple) dans /etc et /usr/share...
Sans parler de problèmes, fonctionnels ou sécuritaires, qui peuvent arriver quand on laisse les choses s'entasser... il me semble avoir déjà vu des applis supporter libgnutls et libssl en même temps, en se servant de l'une en priorité, quand les deux sont installées.
Si je veux n'en utiliser qu'une, parce qu'elle a tel ou tel avantage (genre, il me semble que gnutls ne supporte pas de gérer un répertoire de certificats, mais un seul certificat à la fois), ça peut causer un problème si ces libs sont présentes en même temps... au moins me faire perdre du temps, jusqu'à ce que je me rende compte de ce qui coince (autre exemple avec ces deux libs : les noms des méthodes de chiffrage ne sont pas les mêmes - me suis encore cassé les dents dessus ce weekend).
Il y a aussi qu'il est plus pratique de gérer ce qui est installé sur un parc de serveurs, quand la désinstallation des dépendances est déterministe.
En ce moment, je bidouille pas mal CFEngine, et j'apprécie de pouvoir spécifier clairement la liste de ce que je veux qui soit présent sur la machine : pour ce qui est des dépendances et des désinstallations, c'est transparent - je ne spécifie que les paquets que j'aurais installés manuellement... ainsi, si j'installe un truc juste pour voir, je sais que s'il n'est pas listé dans ce qui doit être présent, lui et tout ce qu'il aura fait venir sera nettoyé au prochain fetch de la configuration...
Par contre, si le système ne faisait aucune différence entre paquets demandés, et leurs dépendances, ce serait lourd... très lourd : je serais obligé de spécifier explicitement ce dont je ne veux pas, plutôt que de me contenter de dire ce que je veux (ou alors, inclure la liste des dépendances récursives dans la liste de ce que je veux, voire enlever la gestion des désinstallations de mes scripts... pfff... paye ta galère)...
Bref, gagner quelques Mio, en effet, m'en fous pas mal (et encore, il y a des cas particuliers - j'ai récemment testé de l'OpenVZ dans du Virtualbox, et j'ai eu des tas d'emmerdes parce que pas assez de secteurs dans les disques virtuels, par rapport aux quotas, même s'il y avait largement assez d'espace - j'avais installé plein de trucs, et je me demandais ce qui faisait que je ne pouvais me connecter en SSH dans le conteneur : en fait, la machine ne pouvait plus rien y écrire)... mais ce n'est pas pour ça que je veux une gestion rigoureuse des dépendances installées... ;)
Je sais que ça va contre les anciennes traditions... mais les traditions, ça évolue : et aujourd'hui, moult gestionnaires de paquets supportent ça (et même par défaut). Franchement, j'aimerais vraiment voir cette fonctionnalité supportée dans des distros comme CentOS, parce que, aujourd'hui, c'est peu ou prou tout ce qui m'empêche de les utiliser (comme je le disais, quand on a goûté à quelque chose d'aussi pratique, difficile de revenir en arrière).
Donc, si la seule raison est la tradition, qui demande de moins bonnes pratiques que ce qui se fait maintenant : pourquoi pas ? Que ce soit possible n'est censé empêcher personne de faire comme avant (au moins jusqu'à ce que ça devienne la nouvelle tradition)...
[^] # Re: Licence ?
Posté par Aefron . En réponse à la dépêche Une WebTV dédiée à l'open source et l'entreprise : le JT pilote. Évalué à 2.
... une offense de la communauté du libre... à... la communauté du libre ? :p
[^] # Re: Et sinon...
Posté par Aefron . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 3.
... donc, pour les dépendances tu es en slip : à toi de gérer ce qui doit et ne doit pas être là... et si tu remplaces une vérification attentive des dépendances utiles par la supposition que "jusqu'ici tout va bien" (alors qu'en fait, que les dépendances soient là n'est juste qu'un heureux concours de circonstance), j'aurais tendance à dire que tu mérites que ça te retombe dessus.
Avec Debian, par exemple, si je compile et installe manuellement quelque chose avec un "configure;make;make install", et qu'il me faut des dépendances, je les installe manuellement : de fait, si je retire quelque chose qui a aussi ces dépendances, vu qu'elles auront été installées manuellement (ou simplement marquées comme installées manuellement : on ne vas pas se prendre la tête si elles sont déjà là), elles ne seront pas retirées, hein...
Maintenant, gérer les dépendances à la main est chiant, et c'est pour ça qu'en ces situations, faire un paquet qui listera les besoins en dépendance, c'est infiniment plus propre.
Bon, après, chacun fait comme il veut : FreeBSD a pkg_deinstall, qui permet la désinstallation automatique des dépendances ; il me semble qu'OpenBSD ne l'a pas... on peut très bien donner le choix à ceux qui veulent crader leur système de ne pas désinstaller les dépendances.
Mais le faire est une bonne pratique... et que ce soit fait automatiquement, une bénédiction. Si je peux comprendre que c'est un changement auquel certains ne sont pas prêts, je ne comprends pas qu'on puisse refuser d'implémenter une chose aussi essentielle, et courante, dans les gestionnaires de paquets modernes.
[^] # Re: Et sinon...
Posté par Aefron . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 3.
Hein ? Par opposition à quoi ?
Un système où on a compilé des choses ?
D'une, on peut compiler pour faire un paquet (c'est même la manière propre de faire, dans quelque distro qui comprennen le concept de dépendance)... donc, là, les dépendances, ça se passe de la même manière que les paquets de la distro.
Et sinon, si on fait avec un make, et bien, on installe manuellement les dépendances, via des paquets, ou en les compilant aussi :
- dans le premier cas, ce sont des paquets installés manuellement (donc, pas de raison de les virer... et pour s'y retrouver, on regarde la base de donnée des paquets, et on voit qu'ils ont été installés manuellement, si celle-ci est capable de faire la différence entre installation manuelle ou automatique)...
- dans le deuxième cas, ça ne regarde pas le gestionnaire de paquets, puisqu'il n'y a pas eu de paquet...
J'ai déjà vu cette "raison" sur le bugzilla de RH... pour moi, c'est bidon. Qu'ils veuillent rester à une gestion arriérée des dépendances (éliminatoire, maintenant que j'ai goûté à une gestion complète), OK... mais ça n'est pas un argument, surtout quand tant d'autres le font.
Et comme je l'ai dit au-dessus, il y a des autres raisons (bien plus valables) que le gain de place...
Bref, pour moi, c'est un bug (et un très très gros)... prétendre que c'est une feature n'y change rien.
[^] # Re: 3D Secure
Posté par Aefron . En réponse au journal "MasterCard Secure Code" ou "Verified by Visa" ou comment ne plus assumer. Évalué à 3.
... pour le reste, je n'en sais rien : les moyens d'anonymats, il m'arrive d'en utiliser (et je fais tourner un relai Tor... tout autant que je suis de plus en plus intéressé par un tunnel Relakks, qu'il est fort probable que je me procure d'ici mars) - mais jamais de chercher à les filtrer ;)
[^] # Re: 3D Secure
Posté par Aefron . En réponse au journal "MasterCard Secure Code" ou "Verified by Visa" ou comment ne plus assumer. Évalué à 3.
... par contre, s'ils me reprochaient de ne pas avoir assez protégé ce qui est contenu dans mon état civil (c'est certes une information personnelle : mais certainement pas un secret), là, ça chierait - façon ebola dans leur face.
_Ils_ utilisent une solution merdeuse pour _se_ protéger : ils ont plutôt intérêt à assumer jusqu'au bout.
# Et sinon...
Posté par Aefron . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 6.
Mais il y a un truc qui me gêne profondément avec tous les gestionnaires de paquets qui les utilisent, et que j'ai testés : la suppression des dépendances inutiles.
Genre, j'installe A, qui fait venir B (lui même faisant venir B1, B2, ... Bi, et ainsi de suite) et C. Puis j'installe A', qui fait venir C. Si j'enlève A, je voudrais qu'il enlève automatiquement B, et les dépendances que seul B utilise (B1, B2, ... Bi... et les dépendances que seuls eux utilisent), mais surtout pas C, ni A' (et je ne veux pas entendre parler de machins qui vont rechercher les libs qui ne sont des dépendances de rien... parce que même si je les enlève, il restera, encore, leurs dépendances ; et puis, ça ne résout pas le problème des dépendances qui ne sont pas des librairies : bref, ce n'est pas une solution, c'est de la bidouille, et encore...).
J'avais testé Mandriva, Suse et Fedora il y a à peu près un an, et aucune ne gérait ça. Mandriva parlait d'introduire une gestion des dépendances à la désinstallation, à l'époque, mais je n'ai rien trouvé quant à ce qu'il en est maintenant... donc quid ?
Quitte à le préciser, je ne cherche pas à troller, ou à descendre qui que ce soit : dans l'usage que j'en ai, il fait partie de mes _exigences_ d'avoir un déterminisme carré quant aux paquets installés (apt, aptitude, paludis, ... le permettent - pas moyen de revenir en arrière une fois que j'y ai goûté ; ne pas avoir ça est éliminatoire en ce qui me concerne)... je veux juste savoir ce qu'il en est : pas plus - pas la peine de monter sur des chevaux de quelque taille que ce soit, en m'expliquant comme il a déjà été fait que je dois "dire ce dont j'ai besoin, pour qu'on m'explique en quoi c'est inutile".
Ça l'est sans doute pour certains, mais je ne saurais m'en dispenser... fuite d'informations quant à mes pratiques (avec ça, facile de savoir que j'ai testé la création de CD d'install ou des méthodes de chiffrage sur mon laptop, par exemple), bordel dans /etc ou /usr/share, ... mes raisons sont multiples, et ce n'est pas le "pourquoi" qui m'intéresse dans ce post : juste le "quoi".
[^] # Re: 3D Secure
Posté par Aefron . En réponse au journal "MasterCard Secure Code" ou "Verified by Visa" ou comment ne plus assumer. Évalué à 3.
... par exemple, en Suède, on ne peut demander la correspondance d'une IP avec une personne que si ce qu'on a fait de la connexion est passible d'au moins deux ans de tôle (c'est là-dessus que ce base par exemple relakks, qui est plus un VPN qu'un proxy - m'enfin, c'est pour imager).
Cumule VPNs, proxies et darknets, et pour remonter à toi, ça va être un peu coton (pas infaisable, mais pas à la portée du premier grouillot venu).
Cependant, il y a des blacklists des IP de ces proxies, des IP des noeuds de sortie des darknets, etc (genre, à un moment, LDLC m'interdisait l'accès à leur site, alors que je n'étais qu'un relai Tor [même pas un noeud de sortie])...
C'est le chat et la souris...
[^] # Re: Education Nationale
Posté par Aefron . En réponse au journal Un ver s'attaque à la Marine française. Évalué à 5.
Oui, enfin, confier 500 machines à un admin qui ne sait pas ce qu'il fait... peu importe le système... euh :p
[^] # Re: Education Nationale
Posté par Aefron . En réponse au journal Un ver s'attaque à la Marine française. Évalué à 3.
Bug de 2002... En deux ans de Sid, le truc le plus proche que j'ai vu est une mise à jour de grub, qui cassait le MBR : corrigée dans la journée (et puis, quand on est sous Sid, apt-listbugs n'est pas fait pour les chiens)... nul n'est parfait, mais mon expérience me dicte que ce genre de trucs est rarissime.
> Voyons ce que Debian lui-meme dit de unstable
Et si tu la connaissais un peu mieux, tu saurais que c'est la première du trio Stable/Testing/Unstable à voir les mises à jour des paquets... dont, ô surprise, les mises à jour de sécurité. Ça fait aussi que c'est la première dans laquelle rentrent des paquets avec des problèmes de sécu (c'est le principe : c'est celle par laquelle tout rentre)... maintenant, quand une faille ou chose du genre est identifiée, Sid est en général la première sur laquelle c'est résolu... bref, en pratique, cet avertissement n'est pas très représentatif des faits.
Quant aux problèmes de dépendances, c'est extrêmement rare, et s'il y a un problème, il y a juste à connaître la différence entre "aptitude safe-upgrade" et "aptitude full-upgrade" (le premier ne met à jour que ce qui ne nécessite d'enlever aucun paquet, le second, qui est censé se lancer à la suite, en ouvrant les mirettes, peut supprimer des choses, et requière un peu plus d'attention... maintenant, 99,9% des mises à jour se satisfont d'un simple safe-upgrade ; et en général, le full-upgrade ne fait rien de méchant, même sous Sid)...
Et puis, arrête ta fixette sur Unstable : si tu veux du très utilisable, Testing (que je n'ai jamais vue cassée) suffit déjà amplement (Stable, c'est même du hardcore-rock-utilisable, mais en effet : les choses y sont plus vieilles... et tu sais quoi ? C'est même le but !)... les seuls points à y surveiller sont la reconfiguration des choses mises à jour (exactement comme sous un OS redmondien sur lequel on met à jour ce qui est au-dessus du système... 'fin, "exactement : on a un gestionnaire de paquets pour nous y aider, quand même : et pas n'importe lequel - un des meilleurs), et les mises à jour de sécu (qui vont commencer à exister pour la prochaine Testing, quelque temps après la sortie de Lenny, la nouvelle stable)...
> Voila, je crois que ca dit tout
Oui : ça confirme que tu déblatères des inepties sans rien y connaître...
... autant j'apprécie certaines de tes interventions pondérées, autant, là, tu dis de la merde, et en aveugle : point.
Installe des Debian, apprends à les utiliser (pas très dur : je l'ai appris à plein de gens qui en avaient marre de leur truc redmondien, et qui voulaient autre chose - je n'ai pour ainsi dire jamais à repasser derrière eux ; ils gèrent leur Testing aux petits oignons, sans pourtant y connaître moult), et tu verras en quoi, sur ce coup, tu te lourdes en long, en large, et en travers.
Tout n'est pas parfait sous Linux ; je suis dans les premiers à le reconnaître... mais ce n'est pas en FUDant qu'on le démontre.
[^] # Re: Etudions toutes les possibilités
Posté par Aefron . En réponse au journal "MasterCard Secure Code" ou "Verified by Visa" ou comment ne plus assumer. Évalué à 2.
Personnellement, depuis ~octobre/novembre (je crois), tous les sites sur lesquels j'achète finissent par m'afficher le biniouk 3day-sekioure (apparemment, c'est le serveur de ma banque qui gère cette page)...
... le premier ayant été un site italien, pour des lecteurs de smartcards...
[^] # Re: Education Nationale
Posté par Aefron . En réponse au journal Un ver s'attaque à la Marine française. Évalué à 1.
Outre le fait que, rapport à ce que tu disais au-dessus, passer en Unstable ne fout absolument pas le moindre bordel dans le système (je ne dirais pas la même chose d'Experimental... m'enfin, il n'y a même pas tous les paquets, dans cette saveur), là, tu te plantes encore...
Bienvenue dans le merveilleux monde de l'apt-pinning : on peut installer juste des bouts d'Unstable dans Testing ou Stable, pour ce qui nous suffit... Et oui : c'est fou, ce qu'on peut faire, avec un gestionnaire de paquets (tout autant que c'est fou de ne même pas en avoir, ou alors, un ersatz, pour quelques correctifs)...
En plus, Testing va bientôt gagner un support de sécurité, donc, au prix d'un peu de maintenance en plus (gérer les changements dans les fichiers de conf... m'enfin, ce serait pareil pour les applis qu'on met par-dessus un os redmondien), il sera bientôt une pratique relativement saine d'avoir de la Testing sur un serveur (voire des bouts de Testing avec pinning, dans une Stable)...
Perso, je ne connais que très peu les OS redmondiens (la dernière fois que j'en ai installé un, ça remonte à 5 ans... et il ne doit m'arriver qu'une ou deux fois par an d'en utiliser)... du coup, j'évite d'en parler : ça m'évite au passage de raconter des inepties...
[^] # Re: En anglais...
Posté par Aefron . En réponse au message Client sur OpenLdap+SSL. Évalué à 2.
... par contre, en effet, PowerDNS n'a pas l'air du tout de vouloir s'authentifier via SASL... j'arrive à lui faire charger un .ldaprc en spécifiant la valeur $HOME dans le script d'init (un peu goret, mais c'était juste pour voir), mais il semble se foutre éperduement de TLS_CERT, TLS_KEY et SASL_MECH...
Apparemment, il ne gère pas SASL, qui interdit le "bind" anonyme, mais qui n'implique pas davantage de spécifier un CN sur lequel "binder" (en tout cas, en "EXTERNAL" ; il y a juste un mapping à faire dans la conf du server entre le CN du certificat, et ce sur quoi on veut binder : ça ne regarde donc pas le client)... Et pour PowerDNS, il semble que le seul choix soit entre un "bind" anonyme, et un "bind" explicite, avec des mots de passe tout pourris...
Bref, j'ai avancé, mais c'est toujours la loose... Bon...
[^] # Re: Auto hébergement
Posté par Aefron . En réponse au journal Tout le monde a intérêt à transformer Internet en Minitel. Évalué à 2.
... bon, ça marche bien (bon débits, bon ping, bonne disponibilité), mais pas d'IP fixe (ou hors de prix), pas de reverse (même si on paye une IP fixe la peau du zgeg... c'te honte !), ni plus d'IPv6 que de port 25...
# 3D Secure
Posté par Aefron . En réponse au journal "MasterCard Secure Code" ou "Verified by Visa" ou comment ne plus assumer. Évalué à 10.
De ce que j'ai compris, ça permet à la banque de ne plus avoir à se retourner vers le commerçant en cas d'utilisation frauduleuse de la carte d'un client...
En gros, avant, en cas de magouille avec une CB d'un de ses comptes, une banque se retournait vers la banque du commerçant, puis celle-ci, vers le commerçant, qui finissait par avoir dans le baba l'objet envoyé ET l'argent perçu...
Maintenant, seule la banque du détenteur de la carte est responsable, et du coup, elle pose une "sécurité" en plus... vu qu'en cas de pépin, elle ne peut plus se retourner contre le vendeur (je trouve ça plutôt normal), elle veut "s'assurer" que le payeur est bien le détenteur de la carte...
Sauf que, la mienne, de banque, est d'une crétinerie franche, dans l'application de 3D Secure : le code en plus est ma date de naissance... ce que je ne qualifierais pas vraiment d'information personnelle secrète (grave au contraire !)... j'imagine qu'ils auraient pu filer un calculateur OTP, ou un truc du genre, mais non : à la société géniale, être nase, c'est une histoire de compétition, et on n'en a pas honte... Bon, par contre, pour l'instant, je n'ai rien eu à signer de nouveau.
M'enfin... Si d'autres banques semblent un peu moins légères dans cette affaire, d'après Wikipedia [1], si la mienne me demandait de prouver que le moyen d'authentification a été "utilisé frauduleusement", ça irait quand même assez vite : je leur répondrais que si j'avais eu à choisir une information secrète, je n'aurais certainement pas pris ma date de naissance, donnée qui traîne un peu partout (notamment sur mes papiers d'identités... dans le même portefeuille que ma CB... voire dans mon profil, sur des sites d'achat en ligne), et en haut du classement des mots de passe les plus crétins qui soient, avec le nom de son animal familier et autres conneries du genre "1234" ou "toto"... et que la faute incomberait intégralement, de fait, à la crasse de leur incurie. Et hop.
[1] http://fr.wikipedia.org/wiki/3D_Secure
[^] # Re: Auto hébergement
Posté par Aefron . En réponse au journal Tout le monde a intérêt à transformer Internet en Minitel. Évalué à 2.
... donc, pour les adresses@mon_domaine, je laisse mon registar (qui m'en "offre" 5, plus 1000 redirections) gérer, et je mets son MX pour mon domaine... et si je louais un serveur dans un datacenter pour mes mails, il aurait une IP fixe, donc ça irait aussi.
Ce qui ne m'empêche pas d'avoir un autre MX pour le sous-domaine dont je me sers chez moi (purement local, du point de vue DNS - du moins en tant que MX, car c'est aussi mon relai SMTP-AUTH vers celui de mon FAI, et donc : il est publiquement listé dans les machines de mon domaine, via un CNAME vers mon no-ip ; mais c'est tout)...
[^] # Re: Auto hébergement
Posté par Aefron . En réponse au journal Tout le monde a intérêt à transformer Internet en Minitel. Évalué à 2.
Dans le fichier de zones chez mon registar (Gandi), je déclare que les hôtes de mon domaine qui pointent vers chez moi sont des CNAME vers mon DNS no-ip, qui pointe par ailleurs sur (surprise !) mon IP... et hop.
Bon, l'idéal serait de pouvoir renseigner Gandi directement sur mon IP dynamique, via un client quelconque (comme ça, je pourrais avoir directement un A vers chez moi, au lieu d'un CNAME qui pointe vers un A)... mais Gandi ne le gère pas encore (ils avaient parlé de commencer à le gérer cette année, sur leur forum... à voir).
Ah : penser aussi à mettre un faible TTL (5 minutes pour moi... avec l'intervalle de 5 minutes avec lequel je checke contre no-ip, ça fait au pire 10 minutes d'indisponibilité à chaque changement d'IP)...
> Question subsidiaire : est-ce que no-ip casse les pieds comme dyndns à devoir cliquer sur un lien chaque mois pour garder un compte actif ?
Cliquer, non... mettre à jour l'enregistrement (utiliser le service, quoi), oui (je ne me souviens plus du délai jusqu'à expiration du nom, par contre). En outre, c'est bien plus fiable que dyndns, de ce que j'ai testé.
[^] # Re: Gnome et innovation : une mauvaise blague!
Posté par Aefron . En réponse au journal KDE4 ressemble trop à windows seven. Évalué à 2.
Pour m'y retrouver, je préfère une miniature des bureaux... à vrai dire, le seul usage de la barre à tâches que j'ai, c'est de savoir quels fenêtres sont minimisées (elles sont grisées)...
En outre, même avec un 24" en 16/10 et une barre horizontale, vu tout ce que j'ouvre en même temps, il n'y aurait de toute façon pas assez de place sur une ligne, voire deux, pour lire complètement le titre de la fenêtre... aussi, avoir le détail de tout ce qui est marqué (d'autant que je peux l'avoir en passant la souris au-dessus de la tâche), m'en fous.
> Ta barre fait 72 pixels de large ? Pour du texte c'est trop peu
Pas quand on se fout d'y mettre des tartines... mon but n'est pas d'y lire du Flaubert...
> pour une barre sur le côté c'est beaucoup trop accessible
Ah, mais, c'est un des buts !
> ça prend une place monstre
Sur le côté, j'en ai _toujours_ assez... par contre, en hauteur, je n'en ai _jamais_ assez... donc, quitte à prendre de la place avec une barre, autant que ce soit où j'en ai le moins besoin...
Bref, je n'ai jamais compris ce truc des barres horizontales... j'ai du mal à voir plus inergonomique.