pseudonymous a écrit 56 commentaires

Yep, ça dépend des conseillers, et des coups de pression des politiques.
Au début : cool tranquille, parce qu'en tentative de création de startup avec un pote.
Changement de conseillère. Pas d'explication bien sûr.
Pas cool : en intro, et plusieurs fois ensuite, elle s'est plainte des 300 dossiers qu'elle avait à suivre (je ne vois pas pourquoi, j'ai entendu dire que d'autres en avaient 400 à 500), pression(s) (et je ne parle pas bière …), incitation pour deux séances avec la psy du travail. Première séance moyenne. Seconde séance : au final, c'est moi le problème. C'est cela, oui, c'est cela …
Je ne sais pas bien ce qui s'est passé, depuis quelques moi, c'est silence radio.
À part un mail suite à une discussion qui n'a jamais eu lieu …
Ah beh voilà ! On ne me l'a pas dit, mais comme je ne leur coûte plus rien en pépètes, nouveau changement de conseiller, c'est ChatGemini, euh, François ? Non, Claude ? Non, pas Grok ?…

Je viens de faire le ménage. Le moins que je puisse avouer, c'est qu'il y avait pas mal de trucs périmés dans mon fichier de règles udev !

Et au passage, ça m'a rappelé qu'on peut écrire des règles pour, par exemple, tous les ttyUSB d'un côté, et certain ttyUSB avec d'autres critères de filtrage.

Par exemple, avec :

KERNEL=="ttyUSB*", ATTRS{serial}=="FTY21UGB", SYMLINK+="ttyFTDI2"
KERNEL=="ttyUSB*", ATTRS{serial}=="FTY1T5FZ", SYMLINK+="ttyFTDI3"

j'obtiens /dev/ttyFTDI2 quand la puce FTDI avec le numéro de série FTY21UGB est détectée. Et /dev/ttyFTDI3 pour celle avec FTY1T5FZ.

Et j'ai aussi une règle plus générale :

KERNEL=="ttyUSB*", MODE="0660", GROUP="dialout"
KERNEL=="ttyACM*", MODE="0660", GROUP="dialout"

qui fixe les permissions et le groupe, quel que soit le ttyUSB ou ttyACM détecté.

Meuhnan ! Faut pas se laisser impressionner.
Il faut déjà écarter les lignes identiques à droite et à gauche, normale en blanc sur noir, signifiant qu'il n'y a pas de différence.
Et puis, petit à petit, se focaliser sur les autres lignes, et tenter de deviner si ce qui change peut avoir un impact sur le comportement quand le script est lancé par udev.
Le mot qui s'applique ici serait plutôt "fastidieux" non ?…

c'est dialout sur la plupart des distros

OK. Écrit de tête sans vérifier.

nope, a minima relancer la session.
Quand tu relances un shell / une fenêtre terminal, il hérite de la session en cours.

Sinon, dans le doute, reboote :D (mais ya pas besoin d'aller jusque là)

Oh ? Ça fait vraiment trop longtemps que je n'ai pas été confronté à ça.

666

Effectivement, ça sent le souffre !
Je vais corriger ma méthode de bourrin …

En espérant que ce soit utile, je tente la publication :

OK, merci, je suis passé à côté de ça. J'ai un lourd passif de recherches infructueuses, même avant l'avènement de l'IA …

Je vais tenter ça avec mon auto-hébergé dans ces conditions.

Vu dans d'autres commentaires : avant de compiler un driver, j'ai loupé la détection effective de la puce CH, même si on a 340 d'un côté, et 341 de l'autre.

Effectivement, une inclusion de l'utilisateur dans le groupe dialup peut résoudre le problème, qui devrait ici se résumer à des permissions manquantes pour l'accès au /dev/tty... par un utilisateur normal.
Attention, selon le contexte, elle nécessite de relancer un shell, ou carrément toute la session graphique pour être prise en compte.

Une règle udev pourrait aussi faire appel à chmod pour modifier ces mêmes permissions. La première solution est peut-être plus simple et propre.

Pour la petite histoire, j'ai plus l'habitude des règles udev, mais avec des puces FTDI.
Ces dernières ont un gros avantage : elles présentent un numéro de série. Grâce à ce numéro, la règle udev peut créer un lien symbolique vers le /etc/tty... "du moment".
Je dis "du moment" parce qu'il arrive que lors du boot, par hasard, ou parce que le port USB a changé, ou parce que l'USB a été, est et restera l'USB …
Il peut arriver donc que l'ordre de détection des périphériques change. Et donc, une puce peut se voir attribuer /dev/ttyUSB2 à un moment, et /dev/ttyUSB0 à un autre.
Avec une règle udev basée sur ce numéro de série, un lien symbolique totalement arbitraire et libre peut-être créé à chaque détection, par exemple /dev/ttyUSB-mon-device-a-moi-en-haut-a-gauche. Plus besoin de se poser la question du chiffre attribué au ttyUSB, il suffit d'utiliser le lien qui pointera toujours sur le bon ttyUSB.

Malheureusement, je n'ai encore jamais vu de puce CH ou Prolific (ou autre ?) présentant un tel numéro de série. Et les FTDI sont sensiblement plus chère que les autres …

J'ai copié les sorties des deux cas de figure pour les comparer avec vimdiff.
Je ne sais pas comment faire apparaître ce que j'ai sous les yeux ici, pas sans que ça ne devienne très confus.
Je constate de nombreuses différences entre les environnements, certaines pouvant expliquer les différences de comportement. À commencer par les export de DISPLAY et XAUTHORITY déjà mentionnés plusieurs fois qui sont absents au tout début de map-epson.sh.
Mais il y a beaucoup d'autres variables qui manquent dans le contexte udev et qui pourraient expliquer la différence de comportement.
Je ne suis certain de rien, mais ça pourrait être aussi simple que quelques variables liées à la langue (exemple au hasard : LANGUAGE=fr_FR), de la même manière que ça pourrait être beaucoup plus subtil.

Question annexe au passage : existe-t-il une solution officielle pour linuxfr.org pour stocker et intégrer des images dans les posts ? Je n'ai pas trouvé la réponse sur le site (wiki inclus). J'ai moyennement envie de publier ça sur mon serveur auto-hébergé.

Je vois

/bin/sh: 1: gcc-13: not found

Sur ma Debian 13 (Trixie), plusieurs versions sont disponibles, la dernière étant la 14. Les versions 10, 12 et 14 sont installées.

Peut-être est-il possible d'installer la version 13 de votre distribution pour satisfaire le processus de compilation ?

J'ai encore une vieille alarme qui communique par SMS, via un forfait Free 2 €.
Afin d'éviter les surprises, je viens de désactiver tout ce qui concerne la data. C'était resté actif par bête oubli.
Ceci dit … C'est en sursis, si j'ai bien suivi. La 2G étant appelée à disparaître, je vais bientôt (?) me retrouver avec un bout de plastique à 2 € / mois.
Le problème, c'est que les alternatives qui fonctionnent purement en local et sans abonnement au fabricant et/ou à de la télésurveillance, ça ne se fait plus des masses …

Oui, c'est ça qu'il faut tenter.
Et encore une fois, en ajoutant les export si nécessaires.

Parce que ça commence à être noyé dans la masse de commentaires, je rappelle aussi qu'en dernier recours et pour éliminer tout doute, il faudrait lancer set > unFichierSet.txt et/ou env > unFichierEnv.txt, une fois à partir d'une ligne de commande normale, et une autre à partir du script lancé par su.
En changeant les noms de fichiers pour pouvoir les comparer bien sûr (ex: unFichierSetSession.txt et unFichierSetSu.txt).
Seule cette comparaison permettra de déterminer les variables d'environnement qui existent, ou pas, dans chacun des contextes.
Moi, j'ai l'habitude de faire ça avec diff, vimdiff ou gvimdiff, mais il existe à coup sûr des utilitaires plus "user friendly" (peut-être kdiff3 ou kdiff3-qt par exemple).

Il faut bien détacher / décomposer. Diviser pour mieux régner …
En écrivant

su - prn -c "whoami : $(whoami) >> /tmp/test.log"

le shell interprète immédiatement

$(whoami)

en tant que root, même si tout le reste se fait en tant que prn.
Il faut écrire des scripts à part, et ne mettre que le lancement du premier script dans la commande lancée par udev.

Autre réponse à part pour insister aussi sur les su et autre moyen de changer l'utilisateur qui exécute le script.
Si la règle udev lance des commandes ou un script qui persiste à s'exécuter en tant que root, c'est que su ou autre ne sont pas exploités correctement.

Petit exemple écrit vite fait.

Deux scripts appartenant à root, exécutable par tous :

# l script*.sh
-rwxr-xr-x 1 root root 104 2026/01/09-14:38:23 script1.sh*
-rwxr-xr-x 1 root root  46 2026/01/09-14:38:27 script2.sh*

Contenu du premier :

# cat script1.sh
#!/bin/bash

echo "Script 1: I am $(whoami), about to launch script2.sh"
su - totof -c /tmp/script2.sh

Et du second :

# cat script2.sh
#!/bin/bash

echo "Script 2: I am $(whoami)"

Exécution directe du second script par root :

# ./script2.sh
Script 2: I am root

Exécution indirecte du second en passant par le premier, toujours par root :

# ./script1.sh
Script 1: I am root, about to launch script2.sh
Script 2: I am totof

Ici, grace à su - totof ..., on "devient" totof avant l'exécution de script2.sh.

Bien compris, pas de soucis, à votre rythme.

DISPLAY=:0 ou export DISPLAY=:0 ?
Désolé d'insister, mais le export est capital. En son absence, toutes les commandes à droite du premier | n'en auront pas connaissance.

Le export DISPLAY=:0 est-il inclus dans le script xinput | ... ?
Idem pour export XAUTHORITY=/home/prn/.Xauthority si nécessaire.

Au-delà de ça, via la règle udev, si whoami retourne root, c'est que le changement d'utilisateur n'est pas opéré correctement. Il faut peut-être tenter de décomposer en deux scripts :

• le premier, lancé par udev de la façon la plus simple qui soit possible, lance le second script par l'une des méthodes de changement d'utilisateur (su ou autre)
• le second script effectue les logs de vérification (whoami, etc), fait les export puis lance xinput | ...

Si le second script n'est toujours pas lancé en tant que prn, il y a un problème qui m'échappe.

En complément, il faudrait peut-être utiliser les commandes set et/ou env, redirigées dans des logs à comparer avec les mêmes commandes lancées à la main dans une session normale. Il y aura peut-être d'autres différences significatives, en plus de DISPLAY et XAUTHORITY.

La session de l'utilisateur prn était-elle lancée ?

RTFM, ou plus exactement, man su

SU(1)                                                  User Commands                                                 SU(1)

NAME
       su - run a command with substitute user and group ID

SYNOPSIS
       su [options] [-] [user [argument...]]

DESCRIPTION
       su allows commands to be run with a substitute user and group ID.
...

Les différences de comportement peuvent provenir de l'environnement (cf commande set ou env).
Quid de la commande su - <utilisateur final> pour lancer le script ?

On est en Xorg ou Wayland ici ?

Si c'est Xorg, il faut peut-être ajouter le export DISPLAY=:0 dont je parlais dans mon autre commentaire.
Pour Wayland, aucune idée.

Le répertoire exact est /etc/udev/rules.d/.

Voici le premier sujet que j'ai trouvé sur comment lancer un script dans ces circonstances.

Après, comme mentionné dans d'autres commentaires, il faut voir si le fait que le script soit lancé en tant que root pose un problème.
Et dans ce cas, peut-être que la solution tourne autour de :

• setuid / chmod / etc : faire en sorte que le script appartienne à l'utilisateur "normal" et qu'à chaque lancement par root, une bascule s'opère vers cet utilisateur via le bon paramétrage des permissions
• su et le paramètre -c pour lancer le script

Il sera peut-être nécessaire d'ajouter export DISPLAY=:0 dans le script.

Notez que je n'ai aucune expérience avec Wayland, je ne sais pas si cette solution peut fonctionner dans ce contexte.

Pour la petite histoire, sur mon PC pas si vieux que ça (2021, Zyzen 5950X + 3090FE), avec une installation toute fraiche de Debian 12, ou plus tard, de Debian 13, le tout premier login KDE / Plasma + Wayland se termine toujours par 95 % d'utilisation CPU, que ce soit avec les drivers nouveau, propriétaire nVidia issus des repos Debian, ou propriétaire nVidia issus du site nVidia. À chaque fois, je dois basculer vers Xorg.

Sur un portable âgé d'une quinzaine d'année, donné aux voisins. Je ne me rappelle plus ce que c'est comme processeur.

Lent au démarrage, mais sa Debian arrivé à faire tourner Chrome et quelques onglets pour le mail, Facebook, la banque …

Tout ce qu'ils demandaient, pour remplacer leur précédent modèle Thompson à 200 € qu'ils m'avait demandé de requinquer, et dont la courbure du clavier, sous la pression de la batterie gonflée, m'a poussé à leur dire : "euh, nan, je ne le démarre pas, j'ai pas envie qu'il me pète à la gueule. Et je vous conseille d'aller le refiler à un SAV qui saura le mettre dans un container sécurisé".

c'est quoi le lien ?

Avez-vous regardé la vidéo ?

Qu'apportent les points de vue de Peter Thiel (CIO paypal on va dire), Alex Karp (CIO Palantir), Jensen Huang (CIO nVidia) ?

J'ai raté un truc ou bien la réponse est dans la question ?

plateforme douteuse comme youtube

Ça n'est pas moi qui l'ai choisie. Et si c'était aussi douteux (je ne suggère pas que YT soit parfait, très loin de là), jamais ce genre de vidéo ne serait publié.
Ce n'est pas faute de tentatives, comme pour cette longue enquête retirée pendant environ un mois.

25:34 - Pre-Crime Arrests

Après, si vous ne vous sentez pas concerné par votre observation par les "précogs" de Palantir via la DGSI, pourquoi pas.

Enquête de Gamers Nexus (GNCA) sur le sujet et plus.

Pour continuer sur le HS :

• je suis assez âgé pour avoir entendu cette chanson étant gamin. De nombreuses fois, sur RTL, quand ma mère espérait être appelée pour "la valise".
• j'étais trop jeune pour en mesurer la portée.
• plus tard, quand j'ai commencé à avoir des goûts (et des couleurs …) musicaux, j'en ai exclu les "chanson des (de mes) vieux".
• et ici, hors contexte, zéro référence, je me suis demandé d'où sortaient ces paroles. Jamais je n'aurais fait le lien avec Souchon tout seul.

OK, pardon, j'avais pas du tout, mais alors pas du tout la réf, désolé.

Ça ne serait pas raciste ça ?
Un avis de la modération ?