🚲 Tanguy Ortolo a écrit 12091 commentaires

Bien sûr, sauf que si le but est d'éviter de cliquer et bouger le pointeur avec les poignets sur le pavé tactile en utilisant le clavier, c'est précisément pour cela que syndaemon est fait.

Correction pour le titre : Ubuntu a dix ans. Du verbe avoir.

Avec un écran à haute résolution, les icônes seraient petites, mais les textes aussi grands. En effet, avec Xtf, les fontes correctement spécifiées ont une taille fixe en unité de longueur plutôt qu'en points d'écran.

☑ Une souris à 3 boutons

Mais une grosse, enfin, de taille normale, pas un truc minuscule comme on en trouve de plus en plus. Je ne parviens d'ailleurs pas à comprendre cette mode des souris minuscules, dont je trouve qu'elles se prennent mal en main. Officiellement, ce serait pour aller avec un ordinateur portable et gagner en poids à porter le tout, mais c'est parfaitement débile comme argument, le poids de la souris étant négligeable devant celui de l'ordinateur et de son transformateur électrique.

Et c'est aussi très, très con avec l'arrivée de nouveaux TLD privés, qui ont justement l'intérêt — entre autres — de permettre aux très riches d'avoir des sites Web dont l'adresse peut se réduire à un seul mot.

Je déteste les souris à plus de 3 boutons, car souvent, elles ne prennent pas en compte les gauchers, certaines trackball sont comme ça des fois.

Elles n'ont pas à prendre en compte les gauchers. Une souris, ça a des boutons numérotés, un point c'est tout : la tâche de les mappers à telle ou telle chose relève du logiciel. Avec X.Org, tu peux configurer ainsi ta souris pour inverser le comportement des boutons gauche et droite : Option "ButtonMapping" "3 2 1".

Par curiosité, les gauchers tiennent leur souris avec quelle main ?

Ça dépend des gens. J'ai l'impression que la plupart des gauchers utilisent la souris à droite, comme les droitiers — c'est ce que je fais en tout cas — mais certains la mettent à gauche ; parmi ceux-ci, certains inversent les boutons, d'autres non.

Eh bien, tu n'as pas dû chercher bien loin. La touche XF86PointerEnableKeys permet de passer le pavé numérique en contrôle du pointeur. Cette touche n'existe pas sur nos claviers, mais on peut la mapper sur ⇧ + ⇭ (Shift + Verr. Num.) avec l'option d'X.Org keypad:pointerkeys.

Il y a mieux, beaucoup mieux et plus simple : syndaemon, fourni avec X.Org.

On peut effectivement gagner en transparence mais on peut noter qu'il est déjà possible d'utiliser so>cat pour transformer une socket UNIX en une socket TCP,

Si tu es le seul à avoir accès à ces machines, pourquoi pas, mais sinon, mauvaise idée, parce qu'un socket TCP, tous les utilisateurs du système peuvent s'y connecter. Il serait sans doute plus judicieux d'utiliser socat, mais pour faire passer ça sur un descripteur de fichiers supplémentaire, si c'est possible.

Jusqu'à présent, on pouvait définir des tunnels de connexions TCP. Maintenant, on peut faire pareil avec des sockets Unix. Un socket Unix, c'est comme un socket réseau avec une adresse IP et un port, sauf que ça ne se passe pas sur le réseau mais en local, et qu'au lieu d'avoir une adresse et un port, c'est identifié par un fichier d'un type spécial (de type socket, pour être précis, évidemment). Ainsi, un logiciel peut se connecter sur, par exemple sur quelque chose comme /tmp/pulse/socket, où écoute un autre logiciel, pour y envoyer du son, que cet autre logiciel jouera sur la carte son, dans cet exemple.

Ah, je vois qu'on suit !

ssh et sshd intègrent le support pour transmettre (forward) les sockets UNIX. Un port TCP distant peut être connecté à une socket Unix local et réciproquement. De même, on peut connecter deux sockets Unix ! Cette fonctionnalité n'était possible jusqu'à présent que pour X-Window via l'option -X, elle ouvre de grand horizon dans l'usage distant d'un poste de travail.

Et pour les agents SSH via l'option -A.

Bon, ben pour moi, ce sera un double scotch alors. Faut s'adapter.

Absolument tous les sites qui affichent de la publicité le font pour se financer, aucun ne le fait parce que le bandeau coloré qui clignote hors de leur contrôle est joli.

Ça dépend de la définition que tu prends pour la publicité. En ce moment, ce que j'appelle une publicité pour la Quadrature du Net est affichée en page d'accueil de DLFP, mais je doute que ça rapporte un centime à LinuxFr.

Le transfert de son avec pulseaudio, c'est… de la mémoire partagée :).

Euh, non.

Avec X11 y a pas le son, et y a besoin d'un plus gros tuyaux, mais qu'est ce que ça marche bien !

Maintenant qu'on peut faire du transfert de PulseAudio par SSH, si. Et pour les imprimantes, on pourrait faire pareil si les clients CUPS pouvaient utiliser une variable d'environnement pour déterminer où trouver le serveur CUPS, mais ça n'a malheureusement pas l'air d'être le cas.

Psi non ?

Le transfert de socket est dans la dernière version de ssh qui est sorti la semaine dernière ;-)

Ah tiens, curieux, la dernière fois que j'avais parlé de ça, sur IRC ou sur ML, je ne sais plus, on m'avait répondu que pour X ils n'avaient pas vraiment le choix mais que même ça, ils auraient préféré l'éviter.

Bref, c'est chouette, ça permettra de pouvoir faire des trucs comme du transfert de son avec PulseAudio par exemple.

C'est à peu près ce que fait SpamAssassin il me semble.

En revanche, mauvaise idée de qualifier des messages en fonction de la présence ou de l'absence de nom DNS inverse pour l'adresse IP d'où ils proviennent, pour une raison simple : ça ne donne aucune information sur l'utilisateur de cette adresse IP (ça ne dépend pas de lui mais de son fournisseur d'accès) et encore moins sur le message lui-même. C'est, au mieux, un moyen statistique aussi pertinent que de mettre une note négative aux messages rédigés en anglais : c'est le cas de pas mal de spam, mais c'est tout ce qu'on peut dire de cette caractéristique, en revanche il y a des messages corrects qui sont dans cette langue, et des spams qui sont dans une autre langue..

Oui mais c'est de la fusion. C'est propre la fusion.

D'ailleurs, les sources énergies fossiles, c'est à dire renouvelables très lentement, sont également issues de la transformation de l'énergie produire par ce même réacteur thermo-nucléaire.

pour passer à la vitesse supérieure ou entrer dans le 21e siècle

Il faut qu'il atteigne les quatre-vingt-huit miles à l'heure, pour pouvoir entrer dans le 21e siècle.

par contre le canal de données c’est de la mémoire partagée

Ah. C'est mort alors, cette idée-là, dommage…

À noter également, que le déport d'affichage X11 par SSH n'utilise pas la « transparence » réseau d'X11, puisque, pour les clients X11 comme pour le serveur, toutes les requêtes ont lieu sur socket Unix.

Ceci m'amène à la question suivante : si avec Wayland, la communication entre le serveur Wayland et les clients Wayland se fait par socket Unix (je n'arrive pas à imaginer comment il pourrait en être autrement), faire du déport d'affichage par réseau pourrait se faire de la même façon, avec SSH ou autre chose transférant tout ça par réseau pour exposer sur un autre poste un socket Wayland utilisable ?

Oui, entre autres. ssh -X, ça fait plusieurs choses en fait :

1. ça transfère le socket du serveur X du poste client SSH /tmp/.X11-unix/X$n, où $n est le numéro du $DISPLAY sur un socket créé pour l'occasion sur le poste serveur SSH sous le nom /tmp/.X11-unix/X$m, où $m est un numéro choisi pour ne pas créer de collision ;
2. ça exporte dans le shell distant la variable DISPLAY=:$m ;
3. ça exporte dans le shell distant le cookie d'identification X11, avec xauth (pas envie de détailler ça, vous pouvez regarder les pages de manuel et regarder ce que donne xauth list sur les deux postes).

Ainsi :

• les logiciels clients X lancés dans le shell distant essaieront de causer avec le serveur X correspondant à ce DISPLAY=:$m, c'est à dire un serveur prétendument local au poste serveur SSH, accessible sur le socket Unix /tmp/.X11-unix/X$m ;
• leurs requêtes à ce socket Unix sont transférés par SSH au socket Unix du serveur X du poste client SSH /tmp/.X11-unix/X$n ;
• ces requêtes sont donc traitées par le serveur X du poste client SSH.

À noter que, si OpenSSH est capable de faire des transferts de ports TCP et UDP arbitraires, il est en revanche codé pour ne pouvoir transférer en matière de sockets Unix que ceux dont le chemin correspond à ceux utilisés dans le cadre du système X11.