pseudonymous a écrit 72 commentaires

Je parlais de ceux qui défilent bras tendu, le tatouage honteux face caméra (quand ils ne sont pas masqués, sinon, c'est la fête du clip, comme le 09/05 dernier), organisent des guet-apens avec la complicité des femmonazies, ou encore affichent des punishers et de thin blue lines sur leurs uniformes.

Mais en termes de biscotte, j'aurais qualifié votre illustration de "biscotte inhumaine" plutôt. Ou mettre à la place la fraude vide de bard-est-pas-là.

Aucun logiciel ne peut être garanti fiable à 100 %.
Ajoutons que le matériel peut aussi être bugué (vieille réf moisie : le FDIV bug des Pentium du milieu des années 90).
Résultat : des accidents et des morts potentiels.

NB: ça fait longtemps que je code, j'ai entendu parlé de méthode de preuve, mais je n'en ai jamais vu. Quelqu'un peut faire un retour d'expérience là-dessus ?
Mon intuition, c'est que même si ça se pratique, c'est très peu répandu et très coûteux; et donc, rarement appliqué, même là où ce serait nécessaire.

Ce n'est quasiment jamais deux fois le même numéro d'appelant.
J'aimerais bien comprendre comment l'usurpation peut perdurer.
Et pourquoi les opérateurs la laisse possible.
J'imagine mal un opérateur (Free, Orange, SFR, …) ne pas savoir qu'un appelant usurpe un numéro.
Et que font les CNIL et ARCEP ?

(vraies interrogations et question. J'ai déjà recherché un peu d'infos y'a un moment. Rien de solide n'en est ressorti)

des idées non exprimées

Pardon ?
Des saluts nazis, des tatouages nazis, jusqu'aux ratonnades et aux meurtres, ce ne sont pas des idées exprimées ?

Assez d'accord avec ces règles 4) et 5).

J'ai vu ici des posts et commentaires abondamment moinsés ou carrément supprimés sur des sujets nettement moins tendus qu'ici.
Avec pour explication quelque chose du style : "pas de ça ici, on cause Linux, technique, informatique, etc".

J'ai posé une question simple et sans agressivité. J'espère que le modérateur en question en conviendra.

Votre "réponse" me laisse dubitatif et inquiet.

bien-pensants

Je me trompe si je dis qu'il y a beaucoup de négativité ou de mépris dans votre expression ?

Mon éducation ne m'a peut-être pas enseigné le droit. Mais ça fait longtemps que je fais la distinction entre droit et justice.

Et cette même éducation sans droit n'a aucun problème à résumer les choses ainsi :

• racistes, antisémites, islamophobes, homophobes, -phobes, fachos, nazis : ce sont les méchants
• anti- : ce sont les gentils

C'est ça que vous appelez être "bien-pensants" ?

Laisser la parole aux premiers, ou pire, les mettre en avant, c'est nous faire retourner 100 ans en arrière.
Et j'ai peur que ce soit déjà le cas. Vous êtes du camp de "ceux qu'on est venu chercher" ou de celui de "ceux qui vont chercher" ?

On peut discuter méthode, mais face aux méchants, il faudrait encore avoir une seconde joue à tendre quand la première aura déjà reçu leur "message".

Et j'ai peur d'avoir à faire comme JBK, mais pour une autre raison. Même naturalisée française, ma femme est née à 10000 km d'ici.
Comme je ne suis pas gaulé comme un nazi ou un CRS, je ne me sens pas de terminer le travail de mes grands-parents, qui, je l'espère, étaient considérés comme des terroristes durant la Seconde Guerre mondiale. J'ai un grand-père qui est mort en 1942 dans des circonstances que ni ma grand-mère, ni ma mère n'ont jamais vraiment éclairci.
Je suis donc bien content que des antifas s'en chargent à ma place.

En ce moment, ceux qui mettent un signe égal entre la gauche et l'extrême droite auront une bien mauvaise place dans les livres d'histoire. En espérant que ce ne soit pas bolloré qui les écrive.

modérer au-delà de la loi c'est compliqué

Elle dit quoi, la loi ?
Moi, j'en suis resté à : leurs soi-disant "idées, opinions" sont des délits.
Donc la conclusion est simple : ban.

J'ai raté un truc ?

Il y en a qui ont des solutions plus vigoureuses, mais il paraît que c'est pas bien.

Darmanin a prouvé par le passé qu'il pouvait accéder à des requêtes si elles étaient formulées d'une autre manière.
Je ne dis pas que Mme Kempf doit s'y abaisser, et même le contraire.
Je rappelle des faits qu'il a lui même admis.

Quant à quitter la France, comme je l'ai lu dans d'autres commentaires, ce serait probablement un problème plus pour la famille Kempf que pour l'autre, là. Je ne sais pas, je n'ai aucun lien, ni de près, ni de loin, avec la famille Kempf.

Par contre, je suis curieux de découvrir quels procédés JBK pourrait mettre en œuvre pour "punir les méchants" …

J'ai lu ça entre 1988 et 1990. Plus probablement en 1989 ou 1990.
J'ai une mémoire plutôt visuelle, mais pas au niveau de Lisbeth Salander ! Dommage, j'aurais pu reconnaitre la couverture.
Il est aussi possible que le numéro particulier que j'ai évoqué soit plus vieux, et qu'il faisait parti d'un lot de magazines en anglais, plus anciens, à disposition dans la salle du prof d'anglais comme si c'état une salle d'attente !
J'ai récupéré 1988, 1989 et 1990 sur cette autre archive, mais je n'ai toujours pas retrouvé le numéro en question, zut …
J'ai peur de pas lâcher l'affaire tant que je n'aurai pas mis le clic dessus !

Souvenirs émus.
J'ai acheté quelques numéros à cette période-là, ainsi que du Linux Journal.
Couvertures typiques et reconnaissables de loin.

Avec un pote, on lisait ça en cours d'anglais à l'IUT (ça va, petite pièce, petit groupe, le prof a vite compris qu'on pouvait suivre et répondre correctement tout en faisant autre chose en parallèle …).

Je me rappelle particulièrement l'article qui décrivait l'invention de la révolution dans le domaine du stockage : en 3D avec du laser dans des cristaux !
Ça en est où ça au fait ?…

Ce lobby, ne serait-ce pas la FNSEA ? Le groupe Avril ? Oh mince, on trouve le même type aux commandes des deux, et qui pousse pour le MERCOSUR, puisqu'il a des "usines" dans au moins un pays d'Amérique du Sud.

J'ai failli écrire un avis nuancé, mais la nuance n'est l'apanage ni des pros, ni des contre X.
Un vendredi en plus.

Alors oui, observons un peu en retrait.

Réponse de normand …

Mais plus sérieusement, deux approches ayant chacune leurs avantages :

• au-dessous : il est possible d'utiliser deux breadboards et d'enficher la carte d'éval, lorsqu'elle est large, à cheval sur les deux. Les composants et autres circuits peuvent être solidement enfichés autour, dans les breadboards.
• au-dessus : pas besoin de sortir les breadboards, il suffit de quelques jumper cables. Ça fonctionne aussi avec les connecteurs au-dessous. Mais dans un cas comme dans l'autre, c'est moins stable, plus susceptible aux mauvais contacts et aux déconnexions intempestives.

Non non, ne me remerciez pas pour ces non-réponses extrêmement non tranchées … ;-)

OK, tout à fait possible.
Je repense à des paramétrages qui sont désactivés la plupart du temps de nos jours :

• XON / XOFF
• RTS / CTS

S'il est possible de configurer la console uboot pour utiliser l'un ou l'autre, de même que l'outil côté PC, la communication pourrait être mise en pause quand le buffer de réception est plein ?
C'est le genre de chose dont j'avais oublié l'existence depuis de nombreuses (dizaines d') années, tellement la fiabilité et la rapidité de traitement prédominent. Sauf dans ce cas.

Par un cycliste occasionnel et conducteur. Qui a failli devenir veuf début décembre, à cause "d'une voiture".

Un cycliste vs une voiture ou un camion.

Merde.
Juste merde à la fin.

Correction : "Il a été percuté par le conducteur d'une voiture".

Si on me le demande, je décrirai l'accident qui aurait pu coûter la vie à ma femme qui vélotaf aussi. Ceux qui connaissent le pont entre Ronchin et Lezennes, et la sortie du McDo comprendront tout de suite.

Pour ma part, je témoigne qu'il est impossible de nos jours de faire une seule sortie vélo (taf ou pas) sans être mis en danger par les motorisés au moins une fois.

Pour que quelque chose change, je pense que les solutions sont simples :

• arrêter de donner le permis à n'importe qui. Beaucoup de "A" s'asseyent sur les règles dès qu'ils ont le permis. Il faudrait engager la responsabilité des instructeurs et des examinateurs en cas d'accident dans les premiers mois après la délivrance du permis. Faire repasser le permis aux pires conducteurs. Et pourquoi pas un contrôle des connaissances, ne serait-ce que pour les rond-points et leur règle de la priorité à droite totalement ignorée par beaucoup.
• apprendre aux motorisés à tourner un volant. Malgré la direction assistée, démocratisée depuis quelques dizaines d'années, beaucoup trop de motorisés on la flemme de prendre un virage sur leur voie. Ça coupe à la corde, en roulant à gauche à tout-va. Y compris dans les rond-points qui comportent plusieurs voies.
• imposer aux responsables des aménagements cyclable l'usage de leur propres réalisations. Ça les fera réfléchir à deux fois pour les suivantes.
• le plus efficace serait d'imposer un stage vélo aux motorisés, pendant une semaine par exemple. Ceux qui seraient encore vivant à l'issue auraient le droit de reprendre le volant.

Ma dernière proposition vient de ma propre expérience. Quand j'ai commencé le vélotaf, j'ai réalisé à quel point j'étais un danger pour les cyclistes. J'ai drastiquement changé ma façon de conduire ensuite.

Est-ce que le port série ne serait pas sollicité à un débit trop élevé ?

Parce que j'ai tendance à pousser le bouchon toujours trop loin, ça m'arrive encore d'avoir des problèmes de communication entre PC <--> adaptateur USB/U(S)ART FTDI <--> MCU (STM32).
J'aime pousser au-delà de 115200 bps : 230400 quand ça n'est pas 460800.
Ma justification (discutable ?) étant que plus le débit est grand, moins l'usage de l'U(S)ART côté MCU n'a d'impact (le plus souvent, j'en fais une console de trace et de commande).
Mais le risque de mauvaise transmission n'est jamais loin à ces vitesses, particulièrement quand la quantité de texte est élevée. J'ai l(a mauvaise) habitude d'utiliser PuTTY, que ce soit contraint sous Windows, ou libre sous Linux.

Si cette piste semble plausible, et si le matériel est disponible, il faudrait contrôler la communication avec un analyseur logique.

Je n'ai jamais eu l'opportunité d'utiliser un Digilent.
Un Saleae oui; ils en font de très bons, mais très chers.
On trouve des semi-clones 8 voies au lieu des 16 généralement chez Saleae, apacher chez Jeff ou chez Jack (encore que, ça n'est plus lui le boss il me semble ?).
Pour les clones, le soft Saleae fonctionne aussi … Pas cool pour eux.
Mais l'alternative libre Sigrock / Pulseview les gère aussi.

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 ?