Debian-facile

Je pense qu'on s'est mal compris

Effectivement, modifier vraiment les fichiers sur le disque à chaque changement du presse-papier serait gênant, pour les raisons que tu mentionnes (et dans un tmpfs, beh, ça nécessite de monter un tmpfs quelque part, ce qui est déjà un pré-requis) ; mais également parce qu'un tel comportement ne suivrait pas la logique de fonctionnement du truc : il faudrait aller requêter les données du presse-papier immédiatement à chaque changement pour créer les fichiers, et pour une appli comme Firefox qui propose plein de formats pour une même image, ça peut faire pas mal de cpu/mémoire à utiliser pour strictement rien.

C'est précisément pour ça que je parlais d'en faire un outil utilisant FUSE, qui permet de monter un système de fichiers virtuel. Quand tu utilises sshfs/curlftpfs, tu ne fous pas en RAM tout le contenu du disque distant : tu montes un truc qui ne va aller lister les fichiers/lire leur contenu sur le disque distant qu'au moment où tu interagiras avec (plus ou moins, je ne connais pas trop les détails de ce côté). Le principe serait ici exactement le même : interroger le presse-papier en temps réel au moment où on essaye de lire/lister les fichiers.

Je t'invite à relire le premier paragraphe de mon post d'ouverture : il n'y a aucune garantie que ça ait un réel intérêt, c'est juste que je trouve que le truc devrait exister juste pour le principe

En l'occurrence, le seul et unique objectif d'un tel outil serait de permettre d'interagir avec le presse-papier en utilisant les outils de manipulation de fichiers habituels (ls/vim/etc.), de la même manière que le seul et unique objectif des autres outils FUSE est de permettre d'interagir avec d'autres trucs en utilisant les outils de manipulation de fichiers habituels.

Ceci dit, ça pourrait permettre d'interagir un peu mieux (et plus facilement) avec le presse-papier en ligne de commande (et donc pour certains scripts, pour automatiser des trucs, tout ça), dans la mesure où les seuls outils tous faits que je connais pour ça sont assez limités (seul le texte est géré et/ou il n'est pas possible de choisir une sélection arbitraire). Typiquement, certains programmes de gestion d'images (entre autres) en ligne de commande te balancent le résultat vers la sortie standard, charge à toi de le rediriger vers le fichier que tu veux : un tel outil permettrait, plutôt que d'envoyer ça vers un « vrai » fichier, de l'envoyer vers un presse-papier pour ensuite le coller dans un éditeur d'images graphique sans transiter par le disque. Par exemple.

Quand une application est fermée, un événement X est généré pour signaler que la sélection choisie est maintenant libre, et les données ne sont plus disponibles. Si ces données sont toujours disponibles chez toi, c'est parce que tu as un programme qui tourne qui les a récupéré au préalable et « prend le relai » automatiquement après cet événement. Plusieurs environnements de bureau fournissent un outil de ce style (ce n'est pas franchement dur à coder, 'faut dire), mais c'est généralement limité au format texte et à la selection CLIPBOARD, comme le fait remarquer vv222.

D'ailleurs, on pourrait tout à fait prévoir une option à cet outil qui permettrait de prendre le relai de cette façon (mais je pense qu'il serait plus intéressant de laisser ça comme une option, dans la mesure où, comme dit plus haut, ça nécessite de récupérer toutes les données du presse-papier à chaque changement et non plus seulement au moment où elles sont interrogées, donc c'est légèrement plus gourmand, surtout si on gère autre chose que le simple texte).

Mon post aura donc au moins servi à un truc

Je connaissais le truc de modifier le fichier en root, et ça marche bien, mais il faut les droits root :-)

cyrille : Oh, oui, avec xrandr ça marche, tiens. Bizarre que ça ne marche pas avec xbacklight, dans ce cas (je crois que les deux n'utilisent pas la même bibli pour parler avec X, ceci dit).

Beh je vais peut-être juste laisser tomber xbacklight, dans ce cas. À terme, je comptais de toute façon surtout utiliser un outil que je me suis codé en Python pour ça, mais ça fait partie des trucs pas prioritaires à remettre en place donc je n'avais pas encore vérifié en me disant que si ça ne marchait pas avec xbacklight, c'est que c'était mort. Mais de mon côté, c'est a priori l'extension randr que j'utilise, donc si ça tourne avec xrandr, ça devrait aller.

(Ah, et au fait, pour une raison qui m'échappe (peut-être parce que j'ai redémarré entre temps), il semble que light marche, maintenant. Donc merci de nouveau à manon ^^)


Bref, ça semble bon ou en passe de l'être pour l'écran. Si vous avez des idées pour le clavier, je prends :-)

Pour le rétroéclairage clavier, si je me fie à ce que j'ai lu ça et là, il faudrait une entrée avec du kbd::

En d'autres termes, avant même de savoir si ce que tu remarques est spécifique ou pas à ta situation et dans laquelle des deux catégories sus-mentionnées ça se trouve (puisque c'était l'objet de ton post de te renseigner à ce sujet), tu sembles nous poser comme hypothèse indépassable non seulement qu'il s'agit d'un bug, mais que ce bug est dû à un mauvais sens des priorités de la part des développeurs (ce qui est assez rare, en vrai).

À ce stade, une telle remarque est totalement prématurée et ne peut avoir comme effet que de mettre tes interlocuteurs dans de mauvaises dispositions (et spoiler : si tu te renseignes un minimum sur l'histoire de la gestion de paquets sous Debian, tu verras que tu as très mal cerné leur sens des priorités, le « cœur de l'outil » ayant été largement plus soigné, et par beaucoup plus de gens, que l'interface graphique que tu utilises –d'ailleurs, tu ne précises même pas de laquelle il s'agit).

(Oh, et, soit dit en passant : ce serait quand même bien que tu relises un peu la fable de la grenouille, parce qu'elle ne porte absolument pas sur le fait de se focaliser sur quelque chose au détriment du reste, hein. D'ailleurs, le système de gestion de paquets sous Debian étant historiquement le premier du genre, on se demande un peu qui serait censé être le bœuf ici, mais bref.)


Croutons te répond donc en te fournissant une explication au problème : une histoire de versionnage. Ce qui tend donc à laisser entendre que, dans notre alternative, on est plus près du second cas (quelque chose que tu n'as pas compris dans la logique de fonctionnement du programme, à savoir qu'on peut à la fois dépendre d'une version d'un paquet et en casser une autre) que du premier, bien qu'on puisse considérer qu'il y ait un souci d(e manque d)'affichage qui puisse éventuellement relever du bug, ce que Croutons souligne au passage.

Or c'est sur ce seul point que tu sembles embrayer dans le post suivant, dans lequel tu continues manifestement sur le même travers : tu repères un truc que tu n'arrives pas à comprendre dans les descriptions des paquets, en partant du principe que ce sont forcément les gens qui ont rédigé ça qui ont fait n'importe quoi, et en l'exprimant d'ailleurs d'une manière qui aurait été assez peu respectueuse même si ça avait été le cas, ce qui ne l'était pas.

(À vue de nez, ce qui te paraît incohérent est une bête histoire de fork toute simple comme on en croise des centaines dans le logiciel libre : poppler est basé à l'origine sur du code venu de xpdf, mais, étant maintenant plus avancé que ce code d'origine, les devs d'xpdf ont décidé de reprendre le code de poppler plutôt que de continuer à maintenir leur code d'origine, ce qui est parfaitement compréhensible dans les extraits que tu cites, à condition de les lire sans tes présupposés méprisants.)

Suite à ce message (et surtout à de très nombreux autres partageant les mêmes travers), vv222 intervient en te faisant remarquer qu'étant donné l'ampleur de tes préjugés envers le développement de Debian, n'importe quel système qui ne soit pas Debian, fut-ce Windows, te conviendrait sans doute bien mieux, ce qui est une réaction d'agacement fort compréhensible vu ce qui précède.

Et là, tu nous commet la perle suivante :

Tu sembles donc partir du principe que tu es le seul susceptible de remonter de tels problèmes (ça va, les chevilles ? Note que ça pourrait quand même être vrai, ceci dit… mais à la condition que ces « problèmes » ne soient des problèmes que pour toi. Auquel cas le fait que tu ne sois pas là pour les remonter signifierait simplement qu'ils n'existeraient plus.), et que tu fais là un travail essentiel.

Mais à qui remontes-tu ces problèmes, au juste ? Accompagnes-tu tes messages ici de rapports de bugs adressés aux mainteneurs Debian ? Si oui, j'espère sincèrement pour eux que tu le fais de manière beaucoup moins agressive. Et si non, qu'est-ce que venir râler sur un forum d'utilisateurs dans des formes qui ne permettent pas grand chose de concret, et surtout pas de remonter jusqu'aux gens qui seraient en mesure d'intervenir, pourrait-il avoir d'aussi salutaire ?

Littéralement tout ce que cette phrase montre, c'est que ton égo est assez surdimensionné, ce qui, quelque part, explique peut-être ta tendance à partir du principe que, si quelque chose te paraît ne pas aller, c'est que le reste du monde est trop con pour avoir bossé convenablement, et ne peut en aucun cas venir du fait que tu n'aurais pas compris quelque chose.

Mais ce n'est pas tout : tu arrives également à conclure le même post par

Ce qui est juste totalement incohérent vis-à-vis de ce qui précède : tout au plus, en admettant qu'il y ait un problème dans ce que tu as rapporté (ce qui, encore une fois, est tout sauf évident à ce stade), ce problème
– n'est pas lié spécifiquement à apt, mais plutôt à l'interface graphique (toujours non précisée, ce qui n'aide pas à proposer des solutions) que tu utilisais,
– et porte sur les informations qui sont, ou pas, rapportées par cette interface, donc sont de nature rédactionnelles et absolument pas techniques.

En d'autres termes, en trois posts, tu remarques que tu ne comprends pas quelque chose, tu exposes ton mécontentement de manière passablement injurieuse, puis tu reproches aux gens de ne pas avoir répondu à des questions que tu n'as manifestement pas posées. On peut difficilement dire que c'est de la faute de vv222 que ce topic part en vrille…


Mais continuons. Après ça, intervient David5647 avec une réponse qui semble assez pertinente : puisque tu sembles mécontent du fonctionnement de l'outil que tu utilises (toujours non-précisé à ce stade), il te propose d'en essayer un autre, qui fait environ le même job, mais le fait d'une manière différente, qui pourrait éventuellement satisfaire tes frustrations sur le fonctionnement de l'autre. En l'état, on aurait difficilement pu faire mieux.

…mais ce n'est manifestement pas ce que tu souhaitais entendre, puisque tu lui rétorques aussitôt que sa réponse n'a rien à voir avec le sujet. Ah. Eùh. Mais c'est quoi le sujet, alors ? Parce qu'il était précisément en train de t'apporter la seule réponse technique qui aurait pu t'aider en l'état, là…

Bref, et tu nous conclues donc (après avoir, enfin, précisé que c'était Synaptic que tu utilises, ce qui veut dire que ta râlerie à propos d'apt plus haut était elle-même hors sujet, vu que Synaptic n'est pas apt…) par cette merveilleuse remarque :

Tu demandes de l'aide, on tente de t'en apporter malgré les formes très décourageantes que tu y mets, et tu trouves quand même le moyen de répondre d'un air snob que tu as mieux à faire que d'essayer de suivre les conseils.


La suite de ce topic n'est que la suite logique de ta façon d'intervenir : ça part en vrille, parce que ça ne pouvait pas faire mieux vu la constance avec laquelle tu as fait vriller les propos.

Donc, en l'espèce, la seule réponse raisonnable semble être celle-ci : ni rien, ni personne d'autre que toi ne peut être susceptible de régler le problème que tu nous exposes ici, parce que ce problème se situe exclusivement dans ta tête. Le seul et unique problème, quoi que Synaptic mentionne ou ne mentionne pas à propos de poppler, xpdf, et leurs dépendances, c'est que tu sembles avoir décidé, à propos de sujets que tu ne maîtrises manifestement pas le moins du monde, que tu savais tout mieux que tout le monde et que les gens qui ont passé une partie non-négligeable de leur vie à essayer de faire marcher tout ça avaient fait n'importe quoi, ce qui ne peut pas aboutir à autre chose qu'à te faire passer pour quelqu'un d'à la fois ignorant, agressif et méprisant.

Il existe donc deux issues possibles : soit tu arrives à prendre conscience de ce problème et tu fais des efforts pour y travailler, auquel cas tes interlocuteurs ici pourront t'expliquer sereinement ce que tu n'as pas compris quand tu n'arrives pas à comprendre quelque chose, et t'aider à faire remonter efficacement les problèmes dans les quelques cas où tu repéreras effectivement de vrais problèmes existant ailleurs que dans ta tête, soit, comme vv222 le suggérait, tu vas voir ailleurs, avec si possible (dans ton intérêt, mais bon, après, ça, ça te regarde) un autre système dont la logique de fonctionnement te conviendra mieux. Cette seconde issue risquant fort de se produire de force si tu persistes à n'opter de ton plein gré pour aucune des deux.

En faisant ça, tu laisses le fichier au même endroit, tu ne fais qu'en changer l'extension. Il se trouve que apt tient compte de l'extension pour savoir comment il lit un fichier donné, donc pour le coup ça le désactiverait bien ; mais c'est une mauvaise habitude à prendre, dans la mesure où d'autres répertoires *.d/ du même type sont lus inconditionnellement, et que donc changer le nom des fichiers en les laissant à l'intérieur ne change rien à la situation.

Qui plus est, si je m'en réfère au man :

Ajouter un avertissement pour un fichier qui, effectivement, n'a aucune raison de rester là et pourrait être refait sans grande difficulté dans le cas très improbable où on voudrait le récupérer plus tard, ça me paraît un tantinet peu utile.

Sauf erreur de ma part (parce que j'n'ai pas la prétention d'avoir la science infuse non plus ^^), ni l'un, ni l'autre. Ce n'est pas une requête DNS. Ça renvoie le glue record, qui est configuré côté registraire, indépendamment de la configuration du serveur DNS (pour faire une requête DNS, la commande appropriée est dig⁽¹⁾).

…qui n'ont rien à voir dans l'affaire

C'est bien à toi de le reconnaître. Et donc, si ça pouvait être possible qu'à l'avenir, tu sois un peu moins péremptoire quand on te reprend sur des trucs qui ne sont pas ta spécialité, je pense que tout le monde y gagnerait


(1) D'ailleurs, tant qu'à préciser, je relève aussi ça d'un précédent post :

ping n'est pas fait pour ça (Bon, il se trouve qu'il te donne effectivement le résultat de sa requête DNS avant de commencer à pinguer, et donc on peut s'en servir pour ça, m'enfin, de la même manière qu'on peut utiliser cat dans tellement de cas inappropriés qu'on a inventé le sigle « UUOC » (pour Useless Use Of Cat)). Si ce que tu veux, c'est simplement connaître l'IP associée à un nom de domaine, la commande adaptée, c'est dig, qui a le bon goût de ne pas envoyer de requête vers cette IP ensuite.