pseudonymous a écrit 75 commentaires

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 ?

À ce compte-là, ça devrait donner une hécatombe de managers dans les boîtes Mulliez !
Il y en a, des stakhanovistes du poyoponte pour présenter des objectifs comme si c'étaient des stratégies ! Et des champions de mercatos !
Pas que chez les Mulliez, certes.

Ah oui, my bad, désolé, j'ai trop vite survolé l'article, et cette phrase :

dans un environnement protégé exclusivement par le droit européen

[maintenant, je sais que je cause trop, et que je raconte trop ma vie … Mais là, ça m'fait plaisir, alors je me lache …]

Bon, après, je dois avouer que Microsoft part avec un score de confiance très négatif …
Et le spyware Windows 11 a plombé ce score à de multiples occasions.

Quant aux outils cités, je doute qu'on puisse avoir la certitude à 100 % de leur honnête fonctionnement.
Certes, j'ai entendu parler, il y a quelques années, de la possibilité de consulter le code source. Mais dans quelles conditions ? Et qu'est-ce qui prouve que les outils utilisés sont ceux dont on a pu lire le code ?

Je sais que, par défaut, j'ai une posture très cynique et négative. J'ai vu trop de fois que la possibilité de tricher était exploitée très vite.

Même par moi ! Comme ici : milieu-fin des 80s, plan "informatique pour tous", le prof d'allemand demande qui pourrait coder un logiciel de QCM. Je fonce et je code ça avec un pote (sur les LogAbax !).
Des séries de questions, chacune ayant 4 réponses possibles et 6 touches pour entrer la réponse. 6 ? Oui. 4 officielles, et 2 cachées, 1 pour avoir toujours faux, et une pour avoir toujours bon. C'est la seule fois où j'ai eu la moyenne en allemand …

Autre exemple plus sérieux de problème de confiance, parfois aveugle en la technologie.

Et à propos de la corruption, je pense qu'elle peut prendre différents aspects, plus ou moins graves et variés.
Exemple que je considère être de la corruption, ou quelque chose de proche : début des années 2000s, Bombardier signe pour plusieurs années la sous-traitance de son SI à CSC (700 millions de $ de mémoire). À Crespin, ça s'est traduit par le licenciement de toute l'équipe info, sauf 2 ou 3 personnes.
Quelques mois plus tard, on reçoit un mail de la compta : "… ça suffit … on ne remboursera plus les notes de frais pour les clés USB … mal faites … et en plus, il faut passer par le catalogue CSC maintenant …".
Ah ? Dit donc collègue, c'est combien dans ce catalogue pour une clé de x Mo ? Oui, Mo, début des 2000s j'ai dit !
Ah ? Tout ça ! Je compare avec les prix du marché. Wopinaize ! Aux alentours de deux fois plus cher !
Donc déjà, qui de sensé se livre pieds et poings liés à ce genre de boîte qui impose des tarifs prohibitifs ?
Ensuite, comme j'étais en fin de mission, je me suis permis de répondre au mail en fournissant cette comparaison. Un petit coup de pied dans la fourmilière avant de partir, et qui a fait un peu de bruit !
Quelques jours plus tard, quelqu'un m'a appelé pour me proposer un poste …
J'ai interprété ça comme ceci : "oh, j'ai trouvé un type qui n'a pas peur de rentrer dans le lard. Comme je suis dans le camp de ceux qui étaient opposés à l'adoption de CSC, c'est top, j'ai trouvé un bidasse pour aller au front à ma place !".
Donc, dans les hautes sphères, il y avait deux camps : ceux conscients que c'était aberrant et coûteux, et ceux qui … C'est sujet à interprétation, mais je n'ai clairement pas l'impression que ce soit le camp de la logique et des économies qui l'ait emporté.

Cf ce lien récent.

Quelles que puissent être les promesses de Microsoft, le CLOUD Act est plus puissant.

À ce niveau-là, on parle encore d'incompétence, ou de corruption ?

Il leur a fallu un rapport pour découvrir ce que tout le monde sait depuis longtemps ? Mazette, de l'argent bien dépensé.

Le problème se pose si on a quelque chose du genre dans le .h :

// Ze big boolette
#define true 0
#define false 1

// Le contrat dont j'ai demandé l'implémentation
class A
{
    public:
        ...
        // quiDependeDe est optionel, et prend une valeur par défaut
        // valeur qui embêtait l'implémenteur, d'où ze big boolette
        bool faireUnTruc(bool quiDependeDe = true);
        ...
};

Et dans le .cpp, faireUnTruc(...) retourne true ou false selon le sens du vent et l'âge du capitaine.

C'est à l'endroit où j'exploite le code sous-traité que se pose le problème :

    ...
    if( zeA.faireUnTruc(peuImporteMonBool) )
    {
        // Code exécuté si true, mais ...
    }else{
        // Code exécuté si false, mais ...
    }
    ...

faireUnTruc(...) peut renvoyer true, on peut même le debugger pas à pas et observer le return true.
Au retour, le test deviendra if( 0 ) et l'exécution partira dans le else, et quelques neurones partent dans le néant.

La première hypothèse qui vient quand on observe ça, c'est : ah, je suis dans l'une de ces rares situations où l'IDE a loupé des choses, oublié de recompiler certains morceaux de code, etc (réellement vécu, mais c'est une autre histoire). On vire tout le build, et on recompile, on re-debug pas à pas, et on grille à nouveau quelques neurones.

La seconde hypothèse, c'est : wow, le compilo est buggé ???

Et une demi-journée plus tard, on s'aperçoit que deux lignes ont été ajoutées, et que le compilo a encore raison …
Ensuite, on décroche son téléphone, et on gueule …

Pas certain qu'on ait couvert ce problème quand le projet AGC a démarré vers 2003, chez Bombardier à Crespin (racheté par Alstom des années plus tard).
Il s'agit des machines faisant office d'IHM pour les conducteurs des trains. Matériel Kontron et OS Linux fournis par une boîte belge qui se trouve (trouvait ?) à Wemmel à côté de Bruxelles (le nom m'échappe). Boîte rachetée par Kontron d'ailleurs.
Le problème n'a pas été couvert je pense. Mais je me rappelle vaguement des discussions sur le sujet … Peut-être que le contrat de maintenance s'arrêtait bien avant 2037 ! 34 ans de "vue au loin", c'est beaucoup, même dans le cadre de matériel ferroviaire, nan ?

J'vous ai raconté la fois où un gars de cette boîte belge a modifié un .h que je lui ai fourni, à considérer comme un contrat / une interface à implémenter ? Il a ajouté :

#define true 0
#define false 1

pour inverser un comportement par défaut qui l'embêtait.

Et moi de passer 1/2 journée dans un debugger pour comprendre pourquoi un if( <quelque chose qui revoit true> ) partait vers le else … À devenir fou …