Vous n'êtes pas identifié(e).
Cette obsession anti-Google
Soit dit en passant, on ne parle pas d'un comportement actif qui bouffe un certain temps quotidien, hein. On parle d'un critère de choix qui se manifeste au moment de choisir un navigateur web, ce qui n'est a priori pas une chose qu'on fait particulièrement souvent (à la limite il s'agit d'un point à vérifier au moment où on apprend l'existence d'un autre logiciel pour voir si il nous va ou pas, exactement comme on peut vérifier s'il est libre ou non, s'il est compatible avec notre machine, s'il est accessible, etc.)
Présenter le fait d'avoir ce critère dans notre liste de trucs à vérifier comme une « obsession », là comme ça, désolé, ça me semble un peu du même niveau qu'un fumeur qui se plaindrait d'une « obsession anti-tabac » parce que les autres gens ont juste autre chose à faire que de sentir ses clopes.
D'autant que,
à condition qu'elle s'accompagne de la même obsession pour toutes les entreprises qui ont les mêmes intentions : Amazon, Apple, Microsoft, Netflix, Uber, AirB'n'B, EASports, UbiSoft, etc, sans parler d'Ali Baba ou de Yandex et à notre petite échelle européenne des chaînes de télévision (privées comme publiques) et des journaux en ligne qui sont pour la plupart des régies publicitaires déguisées (y compris les ex-respectables comme Le Monde ou Libération).
D'une part, je doute fortement que la plupart des gens ici soient particulièrement fan des autres entreprises citées, j'irais même jusqu'à dire au contraire, mais d'autre part et surtout, ce n'est en l'occurrence pas une question d'intentions, mais de potentiel de nuisance.
Tout discours critique des GAFAM un minimum construit t'expliquera que ce ne sont pas les GAFAM en eux-mêmes qui sont visées parce que ces entreprises seraient spécialement pire que les autres en elles-mêmes, mais que c'est leur modèle qui est problématique et qu'on parle d'elles en priorité parce que ce sont celles qui, sur ce modèle, sont présentement en position de force.
Évidemment qu'il faut s'opposer à Amazon, Microsoft et les autres dans leurs secteurs d'activité ; mais ici, il est question du choix d'un navigateur Web, et donc c'est à la société qui menace le plus le Web qu'on s'intéresse. Étant donné que tous les navigateurs, à part Firefox et sa poignée de forks dont les parts d'utilisation sont de plus en plus anecdotiques, reposent sur un fonctionnement décidé par Google, ça signifie simplement que Google décide de comment le Web fonctionne, et que le jour où il a envie de faire disparaître quelque chose, il n'a qu'une mise à jour à propager pour ça. C'est un pouvoir particulièrement plus important, dans ce domaine d'activité, que ce que n'importe quel autre acteur peut avoir.
C'est un pouvoir que même Microsoft, au plus fort de l'hégémonie de son Internet Explorer, n'avait pas réussi à atteindre à ce point, et maintenant Google a même réussi le tour de force de faire en sorte que même eux abandonnent leur pouvoir de décision sur l'évolution du Web. Quand la situation ressemble à ça, qualifier le fait de s'en inquiéter au moment de choisir un navigateur d'« obsession », désolé mais ça devient vraiment problématique.
Je suis intéressé de retour si tu prend le temps de tester, j'entends les noms passer mais je les ai pas essayé (préférant passer par des trucs natifs debian).
J'aimerais vraiment bien qu'un d'entre eux se retrouve empaqueté dans les dépôts. Ceci dit, je suis pour l'instant sur une assez vieille version de Firefox elle-même plus dans les dépôts (principalement parce que j'ai eu la flemme de refaire toute la personnalisation après qu'une MàJ ait encore tout cassée), donc je pourrais aussi tester d'autres trucs autrement. Donc merci pour les liens, si j'essaye je ferai un retour.
Sinon, je rejoins globalement les avis déjà exprimés, dans le paysage actuel, on a hélas à peu près que Firefox qui ne soit pas un faux-nez de Chrome·ium, donc malgré ses défauts, ça reste le seul choix à peu près viable. Il y a d'autres projets, cependant, mais ça ne risque pas de donner grand chose d'utilisable avant un moment…
par
donc ajouter « .decode() » à la toute fin en plus de l'ajout du « b » (ou faire dans l'autre sens, ajouter le « .decode() » avant et donc laisser le rstrip tranquille, mais je vais au plus simple par rapport à ce que j'avais dit ci-dessus) pour que les valeurs soient bien enregistrées comme des str et que donc le retour au thème initial fonctionne.
doit être remplacé par
pour passer de PyGTK à PyGI et de GTK 2 à GTK 3, comme mentionné ci-dessus.
D'autre part, entre Python 2 et Python 3, il y a notamment eu un changement sur la gestion des chaînes de caractères (on est passé de unicode/str à str/bytes), ce qui implique un léger changement sur les lignes 38 à 44 : pour chacune de ces lignes, il faut remplacer le
situé à la fin par
(donc juste ajouter un « b » juste avant le début de la chaîne de caractères), et c'est le seul souci bloquant pour lancer le script.
Ensuite, comme je disais, GTK râle un peu parce que plusieurs appels de fonctions sont dépréciés (notamment le constructeur avec des paramètres positionnels plutôt que par mots-clefs), mais visiblement ça marche tel quel en GTK 3, donc on peut parfaitement envisager de laisser le truc tel quel et de se poser davantage de questions au moment de l'éventuel passage à GTK 4.
Par contre, j'ai testé en ayant récupéré uniquement le fichier du script, sans le reste à côté, donc j'ai eu des symboles d'images cassés à cause des images, j'imagine que ça s'arrange tout seul en récupérant tout le dépôt, et quand je tente de cliquer sur un bouton, j'ai des messages d'erreurs en console à propos de l'inexistence du répertoire ~/.config/Terminal, donc il y a probablement des choses qui ont changé dans la conf' entre l'environnement d'origine du script et celui du liveUSB dont je me suis servi, ça vous serez sans doute plus calés que moi pour gérer !
Deux petites remarques en plus en vitesse : déjà, le code n'a pas trop l'air de respecter PEP8, perso ça ne me dérange pas outre mesure, mais de vrais devs Python pourraient râler et ensuite, l'en-tête du fichier est un peu moche avec des trucs inutiles dedans :
Perso j'utilise habituellement ça :
et ça marche très bien en étant (à mon sens, en tout cas) plus lisible.
Ça ira comme retour ? Hésitez pas à demander si besoin de plus.
(Bien qu'utilisant quelques outils venant d'Xfce et ayant donc xfconf-query d'installé, je n'utilise pas l'environnement complet, c'est peut-être pour ça qu'il me manque des choses par rapport à la situation visée).
Il y a de la doc spécifique sur ce que le script va chercher ailleurs et dans quel but ? (Vu le nom de la propriété, je suppose que c'est la police de caractères utilisée par le thème, qui chez moi est dans le fichier gtkrc et ne nécessite pas ce genre de manips…)
Ça fait longtemps que j’ai pour projet de bosser sur un système inspiré des USE flags de Gentoo et intégré aux outils de construction et gestion de paquets de Debian (apt, dpkg-deb, debuild, etc.), mais jusqu’ici ça n’a pas dépassé le stade de l’idée lumineuse sans rien de concret ensuite
Pour le coup, s'il y avait une alternative à utiliser à la place, ce serait théoriquement possible que les deux fournissent un même paquet virtuel et qu'il n'y ait qu'à échanger, non ?
La question étant de savoir ce qu'il y a comme alternative à utiliser, maintenant que le moteur de Firefox ne peut plus être utilisé que dans Firefox… Dans GTK, il y a encore la possibilité d'utiliser WebKit, mais si c'est déprécié côté Qt, c'est gênant…
edit: on peut tout faire en tmpfs.
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.
Et puis, soit j'ai pas tout compris, soit je ne vois pas trop l'intérêt ni le coté "userfriendly".
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.
Comment ça se passe quand l'application est fermée ? Visiblement les données collées restent disponibles, alors que l'application n'est plus là pour les envoyer.
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).
Avec l’explication d’Elzen, je comprends mieux ce comportement qui me perturbait jusqu’ici.
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::
Ne pas oublier que si le prestataire fournit une presta "gratuite" c'est que d'une façon ou d'une autre vous êtes le produit !
Assez ironique à dire sur un forum d'entre-aide gratuite autour d'un système diffusé gratuitement et contenant des tas de logiciels eux-mêmes tout autant gratuits. Ça fait un fameux tas de prestations dont tu n'es pourtant pas spécialement le produit
Je préfère cette façon de présenter les choses, perso.
Au lieu de jouer avec la position du bouton "Rechercher" (qui me perturbe à chaque fois que je passe d'une machine à l'autre...), ils auraient mieux fait de se concentrer sur le cœur de l'outil, hein.
Moi, ça me fait penser à la grenouille qui voulait se faire aussi grosse que le bœuf…
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 :
Si je me barre personne ne remontera les problèmes, qui vont s'accumuler, jusqu'à ce qu'un jour… Je vous laisse imaginer.
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
Et pour le problème d'apt, tu as une idée technique ?
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 :
Je n'ai pas suivi ton lien, j'ai d'autres choses sur le gaz, désolé.
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.
Donc on fait plutôt comme ça :
mv /etc/apt/sources.list.d/debmultimedia.list /etc/apt/sources.list.d/debmultimedia.list.save
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 :
Le répertoire /etc/apt/sources.list.d permet de spécifier des sources de paquets dans des fichiers distincts. Deux formats de fichiers différents sont permis comme cela est décrit dans les deux sections suivantes. Les noms de fichier doivent se terminer par .list ou par .sources selon le format fourni. Ils ne peuvent contenir que des lettres (a-z et A-Z), des chiffres (0-9), des caractères de soulignement (_), des tirets (-) et des points (.). Dans le cas contraire, APT affichera un avertissement indiquant qu'il a ignoré un fichier si celui-ci ne correspond par à un motif défini dans Dir::Ignore-Files-Silently (les fichiers correspondant à cette variable de configuration étant, eux, ignorés silencieusement).
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.