J'ai un vieil ampli qui pèse un âne mort (2 x 60WRMS ce qui me suffit largement) avec un gros bouton de volume légèrement cranté. La bête a au moins 30 ans, je ne sais pas exactement vu que je l'ai acheté d'occasion. Pour l'ouvrir de temps en temps (pour faire les poussières), le crantage est purement mécanique et derrière ce sont de simples potards, … avec un "S", car 4 potards sur le même axe !
Je mets un coup de bombe aérosol spécial potard à chaque ouverture parce que si ça se met à crachouiller, ça ne doit pas être facile de trouver une pièce pareille.
Mais pour l'instant ça marche nickel, donc c'est comme une voiture, l'entretien compte beaucoup.
Niveau espace disque serveur et bande passante, ça vaudrait le coup de redimensionner les images trop grandes, quitte à mettre une case à cocher opt-out pour ne pas redimensionner si besoin spécial.
Par contre l'image de 3MO dans l'article sur taptempo fait vraiment ramer la liseuse (pour le coup j'ai cru qu'elle était plantée).
J'ai juste donné un lien vers les images brutes de fonderie issues du téléphone.
Je pensais que le linuxfr "pompait" les images à partir de l'URL et passait un coup de convert d'ImageMagick pour les remettre aux formats idoines et les stocker en local. Mais en fait non, c'est l'URL d'origine qui est utilisée dans la dépêche.
Du coup j'ai réduit les dimensions des images sur mon serveur pour que ça soit plus digeste.
En effet, le code n'est pas tip-top, c'est juste un petit truc vite fait, et je n'ai pas pris la peine de faire comme si c'était un programme de 20000 lignes.
Ca reste un petit code très basique et simple, ça se comprends sans s'arracher les cheveux.
Pour le tableau en puissance de 2, j'y avais songé, mais le TapTempo de base (fait précédemment dans plein d'autres langages) se base sur 5 taps, donc j'ai fait comme l'existant.
Utiliser une interruption est tout à fait faisable.
Je ne pense pas que le délai de 10ns puisse faire perdre un tap, car le changement d'état du bouton n'est pas aussi rapide, sauf à savoir cliquer plus de 100 fois par seconde sur le bouton, ce qui m'est pas mon cas, et donnerait d'ailleurs des tempos de dingues. 6000 BPM, ce n'est plus de la musique. En cliquant comme un fou, je n'arrive qu'à 600 BPM. A l'usage normal, tout fonctionne bien, pas de ratés, pas de tap non-pris en compte.
Pour un usage sur batterie/piles, il faudrait en effet initialiser une veille après les 3 secondes d'inactivité. C'est simple à faire, mais je n'ai pas voulu compliquer le code qui avait pour but de faire une simple présentation de l'univers Arduino. Si quelques personnes qui ne connaissaient pas s'y sont intéressés à la lecture de ce TapTempo, je suis comblé.
Pour les tests de performances, le GBF peut être remplacé par un autre arduino uno, tant qu'on y est. Mais on perd le test sur la partie mécanique (le bouton), d'où l'idée de faire un automate qui appuie physiquement sur le bouton, de manière bien plus régulière et plus rapide que je ne saurais le faire.
De ce TapTempo sur arduino me vient une autre idée d'usage détourné. Si j'ai le temps, je vais le mettre en oeuvre et en faire un journal.
Question naïve: pourquoi la conversion de forme casse-t-elle la signature ?
Ce n'est pas une question naïve, c'est une vraie question. Quand tu constates que tes mails ont des signatures PGP cassées ou sont rejetés parce que signatures DKIM invalides, et bien tu mets du temps à comprendre ce qui se passe. En tout cas j'ai mis du temps.
La conversion (8bit en 7bit ou l'inverse) casse la clé PGP parce que la conversion change le contenu du mail, donc le contenu ne correspond plus à la clé. Pareil pour DKIM, si on change l'encoding après signature, le contenu et la clé ne correspondront plus.
Alors certes, le serveur de destination ou le client de messagerie qui vérifie les signatures pourrait se dire : "la clé ne correspond pas, essayons de convertir le mail dans un autre encoding, recalculons la clé et vérifions". Mais il y a là trois points d'achoppement :
- vers quel encoding convertir pour tester ? On ne connait pas l'encoding de départ (ou intermédiaire, au moment de la signature), on doit donc tester tous les encodings possibles et imaginables ? C'est super lourd.
- une telle solution ne serait potentiellement exploitable que si tous les MTA et clients décident de le faire. Comme c'est lourd à faire, ce n'est pas gagné.
- Je réitère mon propos : un MTA (Mail Transfer Agent) ne devrait pas avoir à toucher au body d'un mail, uniquement au header. Donc une RFC qui dit que le MTA devrait réencoder un mail est déjà bancale à la base.
Le problème de base vient de la RFC qui dit que les mails en 8bit devraient (should) être convertis en 7bit (il existe plusieurs encodages en 7bits) avant signature DKIM. Du coup, on se retrouve avec : certains serveurs s'en foutent et signe les mails 8bit sans réencoder avant (c'est possible, rien de bloquant dans la façon de calculer la clé), d'autres réencodent en faisant péter l'éventuelle signature PGP, certains serveurs de vérification vont éventuellement accepter les 8bit et faire le calcul comme il faut alors que d'autres feront la conversion parce que c'est dit dans la RFC qu'il faut la faire.
C'est un merdier inextricable qui devrait faire cas d'école sur l'implication d'un seul mot foireux dans une RFC.
Réponse super claire, qui décrit d'ailleurs mieux le besoin que le titre du journal.
Du coup, le nom n'est peut-être pas très bien choisi, car en fait le cpu n'est pas forcément en idle, en fait la machine peut éventuellement être très occupée à faire mille et unes choses (envoyer 50000 mails, servir des pages web, …) que ça se déclencherait quand même, tant que tu n'es pas devant.
Comme je ne suis pas doué pour les noms, je ne peux pas aider. Donc au pire tu laisses comme ça, au mieux tu fais un concours/sondage pour trouver un nom parfait pour cet outil qui "exécute une tache que tu ne saurais voir".
Pourquoi être passé par DBUS pour savoir si le PC glande ?
Je ne critique pas du tout, ça marche comme ça en donnant un code très court et clair.
C'est juste par curiosité car je ne serais pas intuitivement passé par là, en grande partie parce que je n'y connais rien à DBUS (que je confonds toujours avec ce salopiot d'IBUS qui plante souvent). D'ailleurs, est-ce que DBUS est présent dans toutes les grandes distribs ? j'en sais même rien.
A l'ancienne, j'aurais juste consulté /proc/avg si c'est un idle global, et un peu creusé /proc/net/dev s'il avait fallu regarder les débits réseaux.
C'est super, je ne connaissais pas cette remise des prix.
Dans mon cas, je ne vais toutefois pas le réclamer, pour 3 raisons :
dans le cas d'un livre physique, l'envoi n'est juste pas possible. Je vis en Chine, et quand des gens en France m'envoient lettres ou colis, tout part dans /dev/null, je n'en vois jamais la couleur. Je ne sais pas comment ils font, peut-être qu'il y a des grands brûles-tout à la frontière… et ça ne date pas du coronavirus, c'était déjà comme ça avant. Le seul moyen de recevoir quelque chose de France, c'est par transporteur genre DHL, TNT, … avec le prix qui va bien (càd rien sous 80 euros l'envoi !) ;
la version électronique, qui n'est ni un pdf ni un epub, est seulement consultable sur le site de l'éditeur, c'est quand même super restrictif. Un livre technique, ça doit s'ouvrir en moins de 5 secondes parce qu'on se souvient d'un truc qu'il y a dedans et qu'on veut le retrouver vite-fait. Ca se stocke au chaud dans son disque dur sans être dépendant d'une connexion internet (qui peut difficilement être pire qu'en Chine), sans compte utilisateur à rentrer ou autres restrictions d'accès quelconques ;
je ne le mérite tout simplement pas. A l'origine, je voulais faire un journal, avec mes gros sabots, je me suis planté, j'ai envoyé ça dans l'espace de rédaction des dépêches (oui, faut le faire, je sais), et ça a donc fini en dépêche.
Bref, merci, vraiment, et continuez comme ça.
S'il est possible de transférer mon lot au septième de la liste, ça fera deux heureux.
Moi ce qui me chagrine, c'est qu'ils n'aient pas mis un "donc" ou "de ce fait" ou encore "Puisque …" entre le "vous avez choisi…" et le reste. Du coup il manque une relation explicite de cause à effet entre le refus des cookies et l'interdiction d'accès.
Formulés comme ça, ce sont 4 phrases dans trois paragraphes isolés n'ayant pas de rapports explicites entre eux, or l'implicite est toujours sujet à controverse.
Tu me diras, il suffit de voir la différence entre acceptation-cookie/accès et non-acceptation-cookies/non-accès, en s'assurant que rien d'autre ne perturbe l'expérience (que je n'ai pas faite car rien à battre du Monde).
Il n'y a pas l'air d'avoir de roulement à billes au niveau du maintien de l'axe, il doit donc probablement être fixe, et chaque roue semble avoir un roulement au niveau de l'engrenage. Les roues sont donc indépendantes et chacune à son moteur.
C'est pour aller tout droit que ça doit demander un réglage fin, dans ce genre de config, il y a toujours une roue qui tourne un chouia plus vite que l'autre.
C'est barré, ce virus atteint aussi le cerveau, visiblement. ;)
J'avoue que j'ai un peu de mal à saisir le but du jeu, mais vu que "Un agayon désigne en wallon un objet dont l'utilité n'est pas connue ou comprise", je me sens moins con.
Mettre un Raspberry Pi4 sur batterie, c'est osé au regard de sa consommation électrique.
Pour un robot avec caméra, je serais parti sur un ESP32-CAM qui consomme 20 fois moins (et coûte aussi 20 fois moins cher), quitte aussi à le coupler à un Arduino si les entrées/sorties manquent (vu que la caméra en phagocyte déjà un paquet).
N'empêche que c'est fun, et c'est bien le plus important.
C'est une autre façon de faire et qui fonctionnerait aussi. Il y a plein de façon de faire, c'est cool. Dans un programme plus gros, il faudrait faire attention que la fonction appelée par l'interruption soit la plus courte possible, car elle est bloquante.
Si on utilise une interruption, le attachInterrupt serait plutôt comme ça :
attachInterrupt(digitalPinToInterrupt(TAP_PIN), mesure, FALLING);
… car lorsqu'on presse le bouton, le pin 2 passe de HIGH à LOW.
L'Arduino Uno dispose bien d'interruptions qu'on pourrait utiliser pour le mettre en veille et le réveiller, histoire de gagner en consommation électrique.
Mais pendant la mesure (entre deux taps) on ne pourrait pas utiliser le "Power down mode" car il couperait aussi le timer (millis) dont on a besoin pour calculer le tempo. On ne pourrait utiliser que le "Power save mode" bien moins intéressant énergétiquement.
De plus, la carte Uno intègre le convertisseur USB/Serial qui ne se mettra pas en veille, ainsi que le régulateur 3.3V, la diode de présence de tension… au final, on ne gagnerait que quelques mA pour un code bien plus complexe.
Il serait par contre plus intéressant d'activer ce "Power down mode" après les 3s d'inactivité :
- on tape, pas de mise en veille ;
- on ne tape plus, affichage du "…." pendant quelques secondes, puis extinction du rétro-éclairage de l'écran et passage en veille du micro-contrôleur ;
- on retape -> interruption, réveil du micro-contrôleur, allumage de l'écran.
Je pense que lowtech n'a pas tout à fait la même signification en français et en anglais.
Ca ne doit pas vouloir dire qu'on peut le faire en frappant sur des cailloux, mais juste en n'utilisant que le minimum pour que ça fonctionne, pas de trucs surdimensionnés.
Mais quoi qu'il en soit, quand c'est possible, faire tourner un site web avec 2W de consommation, c'est mieux qu'avec 600W. Son serveur est à Barcelone, il y fait sans doute plus de soleil que dans le nord de la France, ça aide aussi.
Avoir des pages qui s'affiche en moins d'une seconde, c'est mieux que d'en attendre 5 ou plus.
Les images en mode dégradé, dans son contexte, n'est pas gênant, et donne même un style particulier (qu'on aime ou pas, les goûts et les couleurs…) au site.
Et puis bon, il fait ce qu'il veut après tout, c'est son site. Comme tu dis, l'idée est bonne.
De Chine, les accès aux serveurs étrangers sont fortement limités (serveurs blacklistés genre ceux de Google et Facebook, et le reste ultra-lent à décourager les plus patients), et au niveau national, le contenu du net est très surveillé et nettoyé.
D'ailleurs en chinois, le mot "censure" se dit 和谐 (héxié) et est le même que le mot "harmonieux". Du coup, sur les sites francophones de Chine, on utilise le mot "Harmonisé" pour parler d'un contenu (ou une personne) censuré.
- On entend plus parler de Robert dans le Hubei, qu'est-ce qu'il devient ?
- il s'est fait harmonisé.
- oh le con !
Bref, tout ça n'est pas nouveau, donc tout le monde est au courant. Par contre il y a une chose plus grave (si je puis dire) en Chine : les sites web disparaissent. Non pas qu'ils soient harmonisés, bien qu'il faille une autorisation du gouvernement pour ouvrir un site web, mais parce que les habitudes des chinois ont changées, ou on les a poussé à changer.
Tout passe par des apps, et principalement Wechat, qui est à l'origine une appli de chat, mais qui fait maintenant tout, mais vraiment tout. J'ai des amis chinois qui ne savent pas se servir d'un navigateur internet, ils n'en ont pas l'usage, tout se fait sur leur smartphone dans l'application qui va bien.
Bien sûr, ces applications s'appuyent sur les bases de l'internet, mais c'est invisible pour les utilisateurs.
Ma crainte, c'est que ce modèle chinois se répande partout dans le monde, et qu'au final on n'utilise plus que quelques apps gérées par des GAFAM chinois ou américains.
Oui, tout comme pour certains corses (ou la Catalogne en Espagne), la volonté d'indépendance d'une partie des Ouïghours est source de conflits, attentats, … mais je pense qu'il y a davantage. Le Xinjiang est chinois depuis 1911, il y a bien eu des tentatives pour se séparer de la Chine, mais globalement rien de sérieux depuis des années 50. (en passant, ce sont les Hui, minorité ethnique musulmane de Chine, qui ont ramené les Ouïghours dans le giron chinois dans les années 40).
Ce "davantage", pour le nommer clairement, c'est le terrorisme islamique.
Le gouvernement chinois est respectueux (oui, le qualificatif peut paraître inopportun) de la religion dans le sphère privée, par contre il n'est pas du tout laxiste quand ça touche la sphère publique, et encore moins quand ça touche le terrorisme. La Chine a une politique d'assimilation que ne renierait pas Eric Zemmour, et ne tolère absolument pas de troubles sur son territoire.
Donc que les Ouïghours soient surveillés de près, sans aucun doute. Que Huawei ait développé un logiciel de reconnaissance des Ouïghours, certainement. (aparté : il ne s'agit pas d'un logiciel qui dans l'absolu (sur faciès) reconnait un Ouïghours d'un autre citoyen. Il s'agit d'une reconnaissance par comparaison avec une base de données ; on est tous fichés en Chine).
Est-ce que des millions de Ouïghours sont enfermés dans des camps d'internement ou d'éducation ? Est-ce que les femmes Ouïghours sont stérilisées ? Est-ce qu'on les oblige à manger du porc et boire de l'alcool ? Moi j'en sais rien. Pour les camps, des millions … ça doit faire de sacrés gros camps. Et puis s'il y a des files spéciales Ouïghours dans les aéroports, ça veut au moins dire qu'ils peuvent prendre l'avion et voyager hors du Xinjiang, ce qui me paraît contradictoire avec un internement massif. Le gouvernement n'oblige pas non plus les autres musulmans (y compris issus de minorités) à manger du porc ou boire de l'alcool.
En ces temps de guerre sino-américaine (car c'est une guerre, pour sûr), il y a de la propagande des deux côtés, et il me paraît malvenu de prendre tout ce qui se dit dans les medias pour argent comptant.
La logique ne serait pas d'envoyer une erreur à l'utilisateur si son mail est en 8 bits signé et que le destinataire demande du 7bits ?
Ton MTA peut transmettre à un MTA qui va transmettre à un autre MTA, etc. Donc c'est impossible de savoir a priori si le MTA de destination accepte ou non le 8bit.
pendant que j'y pense thunderbird pourrait très bien encoder en 7bits dès qu'il signe le mail ça n'est pas très compliqué pour lui, il y a peut être un ticket la dessus
Franchement je ne sais pas si Thunderbird ne le fait pas déjà, je ne signe pas mes mails avec PGP (je sais, c'est pas bien). Il faudrait que tous les clients mail en fasse de même, pas seulement Thunderbird. Mais déjà sans signature PGP, thunderbird envoie des mails en 8bit, qui, suivant le MTA, sera signé avec DKIM en l'état, puis peut-être converti plus tard, et donc potentiellement rejeté (mis en spam, le plus souvent) à l'arrivée.
Il y a, au niveau mondial, une décision à prendre, et à faire appliquer partout, mais c'est sans doute utopique. Cette décision pourrait être :
- un MTA qui n'accepte pas les mails en 8bit, on envoie un avis de non-distribution (avec message clair sur la raison) à l'envoyeur, histoire de forcer la main sur la mise à jour de ce MTA (on utilise le 8bit depuis plus de 15 ans).
- On modifie la RFC en indiquant que les verificateurs DKIM se doivent de prendre en charge les mails en 8bit (mais là aussi il y aura des récalcitrants, on est reparti pour 15 ans).
L'alternative est d'abandonner le 8bit, ou DKIM … On est un peu dans un sac de noeuds.
A mon avis un MTA ne devrait pas avoir à toucher au Body d'un mail, seulement à l'entête, il ne devrait jamais y avoir besoin de faire des conversions d'encoding, en tout cas pas à ce niveau là.
J'ai du mal à suivre… cette option inaccessible aux mineurs non-accompagnés serait configurée par défaut avec une valeur qui invalide soit DKIM soit la signature GPG dans certains cas où tu signes un courriel ?
Thunderbird n'est pas le seul.
Historiquement les mails étaient encodés en 7 bits, l'encodage en 8bit a été ensuite déployé massivement car permettant de réduire les quantités de données à transmettre. Toutefois, même encore maintenent, quelques vieux serveurs SMTP ne gèrent pas encore le 8bit.
Ce support du 8bit peut (et non pas "doit") faire l'objet d'une déclaration en début de communication (EHLO).
Quand un serveur d'envoi fait face à un serveur qui ne prend pas en charge le 8bit, il doit convertir le mail en 7bit, ou base64, ou quoted-printable.
Là dessus est venu se greffer DKIM. Et la RFC 6376 indique bien que le serveur qui applique la signature DKIM devrait systématiquement convertir préalablement les mails 8bit en 7bit ou quoted-printable :
Some messages, particularly those using 8-bit characters, are subject
to modification during transit, notably conversion to 7-bit form.
Such conversions will break DKIM signatures. In order to minimize
the chances of such breakage, Signers SHOULD convert the message to a
suitable MIME content-transfer encoding such as quoted-printable or
base64 as described in [RFC2045] before signing.
Mais un mail signé qvec PGP ne peut pas être converti, pour les mêmes raisons qu'un mail signé avec DKIM ne pourra pas être converti plus loin dans la chaine de transmission.
Donc dans un monde parfait, les vieux serveurs ne supportant pas le 8bit sont au placard, et les serveurs contrôlant les signatures DKIM sont capables de vérifier la signature des mails en 8bit.
Mais on ne vit pas dans un monde parfait, donc il existe encore des vieux serveurs, et pire, beaucoup de serveurs vont invalider la signature DKIM d'un mail 8bit car il n'est pas censé être en 8bit.
Bref, c'est la merde.
L'utilisateur qui signe ses mails avec PGP et ayant connaissance de ce problème doit donc prendre soin d'envoyer ses mails dans un encoding autre que 8bit.
Mais les utilisateurs font ce au'ils veulent, en tant qu'admin, on en revient donc à faire le choix parmi :
- on ne convertit pas le mail PGP 8bit, on signe DKIM comme ça, et DKIM sera parfois rejeté (une fois sur deux, à la louche).
- on convertit comme un bourrin en pétant la signature PGP
- on s'arrache les cheveux à essayer d'implémenter des règles tordues dans son MTA, du genre :
si (PGP et 8bit) {
Pas de DKIM
} elseif (8bit pas PGP) {
convertit en 7bit et signe DKIM
} else {
signe DKIM seulement
}
Bon courage pour faire appliquer ça aux MTA les plus répandus (libres ou pas).
Conclusion, de nos jours, configurer un serveur SMTP n'est pas un chose facile.
Mon cher devnewt, on se retrouve ici sur un sujet non-technique, et tu fais preuve du même
manque de tolérance envers la façon de faire des autres, au moins tu es constant.
Que tu sois convaincu que les Ouïghours soient opprimés, c'est ton droit. Si tu as des preuves irréfutables, partage donc, sinon respecte au moins la diversité des opinions.
Etant donné l'état des relations sino-américaines, il n'est pas étonnant que ces deux mastodontes se tapent dessus dans les médias, à la guerre comme à la guerre, et le gouvernement chinois ne se gêne pas pour fustiger les américains dans ses médias et exacerber le nationalisme sur son territoire. Chacun est libre de croire ce qu'il lit dans les journaux ou entend à la télé, et de tout prendre pour argent comptant, … ou de douter.
Ce que j'ai dit, et qui est factuel, c'est que les Ouïghours sont une minorité parmi 54 autres, et musulmane parmi d'autres minorités musulmanes. Il est donc logique que le fait d'être une minorité ethnique et musulmane ne soit pas l'origine d'une oppression, cela sous-entend une question pour ceux qui pensent que l'oppression des Ouïghours existe : quels sont les raisons réelles de cette oppression ? (autre que quelques gars du PPC autour d'une table qui se disent "putain, on s'emmerde ! on irait pas opprimer les Ouïghours ?", "ha ouais, bonne idée")
A vous les studios !
Tu attises ma curiosité, dans quels cas tu envoies des courriels en "Content-transfer-encoding : 8bit" ? Est-ce un paramétrage par défaut des principaux serveurs ou client courriel ?
C'est au moins le cas de Thunderbird par défaut si des accents ou caractères spéciaux sont présents dans le message.
Pour qu'il arrête d'envoyer des mails en Content-transfer-encoding 8bit, j'ai du modifier (mon thunderbird est en anglais) :
- dans les Parameters -> Composition -> Send options -> Send messages as plain text if possible.
- puis dans Parametres -> General -> Config editor… -> mail.strictly_mime à true
Comme la rédaction et la signature PGP sont fait par le client avant l'envoi au serveur, le serveur ne peut ensuite convertir l'encoding sans faire péter la signature PGP.
Non, et en bon français raleur, je ne suis pas le dernier pour critiquer plein de choses en Chine (on peut longuement discuter du manque flagrant de déontologie des médecins par exemple). Je ne prends juste pas pour argent comptant ce qui se dit dans les médias car :
je n'y suis jamais allé, je ne connais personne (auquel j'aurai un minimum confiance) dans la région concernée, pas de sources fiables, et avec méfiance car expérience passée des Ricains ayant foutu le bordel au Tibet (qui fait que moi, citoyen français, je ne peux plus m'y rendre facilement).
L'oppression, peut-être qu'elle existe, je ne peux l'affirmer ou l'infirmer. Si elle existe, je dis seulement que ce n'est pas parce que c'est une minorité (même si ça fait sans doute plus vendeur dans les médias de dire qu'une minorité se fait opprimer), ni parce qu'ils sont musulmans.
Ce que je peux dire, c'est que dans certains aéroports (celui de Shanghai, si ma mémoire est bonne), lors du passage au contrôle à l'arrivée des vols domestiques, il y a les files d'attente, et dans un coin une file spéciale pour les Ouïghours. Je suppose donc qu'ils ont droit à "un traitement de faveur" avec fouille "approfondie" et questions du genre "T'es Ouïghours, qu'est-ce que tu viens foutre à Shanghai ?".
Faut aussi savoir qu'en Chine, quand le gouvernement décide de quelque chose (et encore plus si ça touche sa souveraineté nationale), ils mettent ensuite le paquet. Ils ne font pas dans la demi-mesure, ce n'est pas comme en France où le politique va faire passer une n-ième loi pour répondre à l'actualité du moment tout en sachant pertinemment que cette loi ne sera suivie d'aucun effet. En Chine, ils décident, et ils appliquent façon rouleau compresseur en y mettant les moyens financiers et humains, c'est aussi sans doute ça qui choque nos yeux d'occidentaux.
Et chapitre N+1 ce sera tous les non zaziatiques de type Han ?
En Chine, il y a 56 ethnies, et les Han sont largement majoritaires (93%). Toutefois les minorités sont en général mieux traitées que les Han par le gouvernement chinois. Par exemple : les étudiants ont des points supplémentaires pour postuler dans les universités, à l'époque de la politique de l'enfant unique, les minorités pouvaient déjà en avoir 2, priorité de reclassement pour les logements neufs…
Je vis en Chine, dans la province du Yunnan où les minorités ethniques sont nombreuses, je connais donc plein de chinois non-han (小数民族), et aucun ne se plaint d'être moins bien traité qu'un Han. Les relations entre Han et minorités sont très bonnes, les chinois sont plutôt fiers de leurs minorités ethniques.
Pour ce qui est des Ouïghours (env 9 millions sur 1.4 milliard), ils vivent dans la province du Xinjiang, ce n'est pas tout près, donc je n'ai pas d'infos sur ce qui s'y passe. Si oppression il y a, elle n'est cependant pas le fait que les Ouïghours soient une minorité ethnique, ni qu'ils soient musulmans d'ailleurs, puisque d'autres minorités ethniques sont également musulmanes et ça se passe très bien.
En effet, pour surveiller son serveur de mail, il faut en avoir un autre.
Un simple ESP8862 peut faire l'affaire, c'est d'ailleurs un super petit projet d'IOT.
Un microcontroleur wifi à quelques euros, il faut bien entendu développer une interface web pour les paramètres wifi et lister les serveurs à surveiller : IP ou nom d'hôte, port, type de service (mail, http, ssh, …), fréquence de vérification).
- Si un serveur / service est down : au choix allumer une led et aller sur l'interface web de l'IOT voir quel serveur est down, ou mieux afficher le problème sur un petit écran LCD/OLED, avec même une petite sirène d'alarme si besoin.
- une autre diode / affichage d'erreur si c'est le wifi/accès internet qui est down.
En veille (entre deux checks), la consommation est quasi-nulle (quelques mA sous 3.3V ou 5V), environ 80mA pendant le check (quelques secondes), et ça prend moins de place qu'un switch 4 ports.
Je crois que je vais me lancer, tiens.
# Entretenir son matos
Posté par xulops (site web personnel) . En réponse au journal Manifeste contre la roue codeuse. Évalué à 6.
J'ai un vieil ampli qui pèse un âne mort (2 x 60WRMS ce qui me suffit largement) avec un gros bouton de volume légèrement cranté. La bête a au moins 30 ans, je ne sais pas exactement vu que je l'ai acheté d'occasion. Pour l'ouvrir de temps en temps (pour faire les poussières), le crantage est purement mécanique et derrière ce sont de simples potards, … avec un "S", car 4 potards sur le même axe !
Je mets un coup de bombe aérosol spécial potard à chaque ouverture parce que si ça se met à crachouiller, ça ne doit pas être facile de trouver une pièce pareille.
Mais pour l'instant ça marche nickel, donc c'est comme une voiture, l'entretien compte beaucoup.
[^] # Re: Tea/vivlio/pocketbook HD plus
Posté par xulops (site web personnel) . En réponse au message Impossible de lire les journaux linuxfr avec ma liseuse kobo.. Évalué à 1.
Niveau espace disque serveur et bande passante, ça vaudrait le coup de redimensionner les images trop grandes, quitte à mettre une case à cocher opt-out pour ne pas redimensionner si besoin spécial.
[^] # Re: Tea/vivlio/pocketbook HD plus
Posté par xulops (site web personnel) . En réponse au message Impossible de lire les journaux linuxfr avec ma liseuse kobo.. Évalué à 2.
J'ai juste donné un lien vers les images brutes de fonderie issues du téléphone.
Je pensais que le linuxfr "pompait" les images à partir de l'URL et passait un coup de convert d'ImageMagick pour les remettre aux formats idoines et les stocker en local. Mais en fait non, c'est l'URL d'origine qui est utilisée dans la dépêche.
Du coup j'ai réduit les dimensions des images sur mon serveur pour que ça soit plus digeste.
[^] # Re: quelques commentaires.
Posté par xulops (site web personnel) . En réponse à la dépêche TapTempo pour Arduino Uno. Évalué à 2.
merci pour tes remarques.
En effet, le code n'est pas tip-top, c'est juste un petit truc vite fait, et je n'ai pas pris la peine de faire comme si c'était un programme de 20000 lignes.
Ca reste un petit code très basique et simple, ça se comprends sans s'arracher les cheveux.
Pour le tableau en puissance de 2, j'y avais songé, mais le TapTempo de base (fait précédemment dans plein d'autres langages) se base sur 5 taps, donc j'ai fait comme l'existant.
Utiliser une interruption est tout à fait faisable.
Je ne pense pas que le délai de 10ns puisse faire perdre un tap, car le changement d'état du bouton n'est pas aussi rapide, sauf à savoir cliquer plus de 100 fois par seconde sur le bouton, ce qui m'est pas mon cas, et donnerait d'ailleurs des tempos de dingues. 6000 BPM, ce n'est plus de la musique. En cliquant comme un fou, je n'arrive qu'à 600 BPM. A l'usage normal, tout fonctionne bien, pas de ratés, pas de tap non-pris en compte.
Pour un usage sur batterie/piles, il faudrait en effet initialiser une veille après les 3 secondes d'inactivité. C'est simple à faire, mais je n'ai pas voulu compliquer le code qui avait pour but de faire une simple présentation de l'univers Arduino. Si quelques personnes qui ne connaissaient pas s'y sont intéressés à la lecture de ce TapTempo, je suis comblé.
Pour les tests de performances, le GBF peut être remplacé par un autre arduino uno, tant qu'on y est. Mais on perd le test sur la partie mécanique (le bouton), d'où l'idée de faire un automate qui appuie physiquement sur le bouton, de manière bien plus régulière et plus rapide que je ne saurais le faire.
De ce TapTempo sur arduino me vient une autre idée d'usage détourné. Si j'ai le temps, je vais le mettre en oeuvre et en faire un journal.
[^] # Re: Autohébergement
Posté par xulops (site web personnel) . En réponse au journal Linux ne m'intéresse plus. Évalué à 3.
Ce n'est pas une question naïve, c'est une vraie question. Quand tu constates que tes mails ont des signatures PGP cassées ou sont rejetés parce que signatures DKIM invalides, et bien tu mets du temps à comprendre ce qui se passe. En tout cas j'ai mis du temps.
La conversion (8bit en 7bit ou l'inverse) casse la clé PGP parce que la conversion change le contenu du mail, donc le contenu ne correspond plus à la clé. Pareil pour DKIM, si on change l'encoding après signature, le contenu et la clé ne correspondront plus.
Alors certes, le serveur de destination ou le client de messagerie qui vérifie les signatures pourrait se dire : "la clé ne correspond pas, essayons de convertir le mail dans un autre encoding, recalculons la clé et vérifions". Mais il y a là trois points d'achoppement :
- vers quel encoding convertir pour tester ? On ne connait pas l'encoding de départ (ou intermédiaire, au moment de la signature), on doit donc tester tous les encodings possibles et imaginables ? C'est super lourd.
- une telle solution ne serait potentiellement exploitable que si tous les MTA et clients décident de le faire. Comme c'est lourd à faire, ce n'est pas gagné.
- Je réitère mon propos : un MTA (Mail Transfer Agent) ne devrait pas avoir à toucher au body d'un mail, uniquement au header. Donc une RFC qui dit que le MTA devrait réencoder un mail est déjà bancale à la base.
Le problème de base vient de la RFC qui dit que les mails en 8bit devraient (should) être convertis en 7bit (il existe plusieurs encodages en 7bits) avant signature DKIM. Du coup, on se retrouve avec : certains serveurs s'en foutent et signe les mails 8bit sans réencoder avant (c'est possible, rien de bloquant dans la façon de calculer la clé), d'autres réencodent en faisant péter l'éventuelle signature PGP, certains serveurs de vérification vont éventuellement accepter les 8bit et faire le calcul comme il faut alors que d'autres feront la conversion parce que c'est dit dans la RFC qu'il faut la faire.
C'est un merdier inextricable qui devrait faire cas d'école sur l'implication d'un seul mot foireux dans une RFC.
[^] # Re: Dbus ?
Posté par xulops (site web personnel) . En réponse au journal Idle Do, un script pour faire tourner des commandes quand l'ordinateur est inactif. Évalué à 4. Dernière modification le 05 janvier 2021 à 17:56.
Réponse super claire, qui décrit d'ailleurs mieux le besoin que le titre du journal.
Du coup, le nom n'est peut-être pas très bien choisi, car en fait le cpu n'est pas forcément en idle, en fait la machine peut éventuellement être très occupée à faire mille et unes choses (envoyer 50000 mails, servir des pages web, …) que ça se déclencherait quand même, tant que tu n'es pas devant.
Comme je ne suis pas doué pour les noms, je ne peux pas aider. Donc au pire tu laisses comme ça, au mieux tu fais un concours/sondage pour trouver un nom parfait pour cet outil qui "exécute une tache que tu ne saurais voir".
# Dbus ?
Posté par xulops (site web personnel) . En réponse au journal Idle Do, un script pour faire tourner des commandes quand l'ordinateur est inactif. Évalué à 6. Dernière modification le 04 janvier 2021 à 16:29.
Pourquoi être passé par DBUS pour savoir si le PC glande ?
Je ne critique pas du tout, ça marche comme ça en donnant un code très court et clair.
C'est juste par curiosité car je ne serais pas intuitivement passé par là, en grande partie parce que je n'y connais rien à DBUS (que je confonds toujours avec ce salopiot d'IBUS qui plante souvent). D'ailleurs, est-ce que DBUS est présent dans toutes les grandes distribs ? j'en sais même rien.
A l'ancienne, j'aurais juste consulté /proc/avg si c'est un idle global, et un peu creusé /proc/net/dev s'il avait fallu regarder les débits réseaux.
# Merci
Posté par xulops (site web personnel) . En réponse au journal [Message de service] Gagnants des meilleures contributions de décembre 2020. Évalué à 4. Dernière modification le 03 janvier 2021 à 16:34.
C'est super, je ne connaissais pas cette remise des prix.
Dans mon cas, je ne vais toutefois pas le réclamer, pour 3 raisons :
dans le cas d'un livre physique, l'envoi n'est juste pas possible. Je vis en Chine, et quand des gens en France m'envoient lettres ou colis, tout part dans /dev/null, je n'en vois jamais la couleur. Je ne sais pas comment ils font, peut-être qu'il y a des grands brûles-tout à la frontière… et ça ne date pas du coronavirus, c'était déjà comme ça avant. Le seul moyen de recevoir quelque chose de France, c'est par transporteur genre DHL, TNT, … avec le prix qui va bien (càd rien sous 80 euros l'envoi !) ;
la version électronique, qui n'est ni un pdf ni un epub, est seulement consultable sur le site de l'éditeur, c'est quand même super restrictif. Un livre technique, ça doit s'ouvrir en moins de 5 secondes parce qu'on se souvient d'un truc qu'il y a dedans et qu'on veut le retrouver vite-fait. Ca se stocke au chaud dans son disque dur sans être dépendant d'une connexion internet (qui peut difficilement être pire qu'en Chine), sans compte utilisateur à rentrer ou autres restrictions d'accès quelconques ;
je ne le mérite tout simplement pas. A l'origine, je voulais faire un journal, avec mes gros sabots, je me suis planté, j'ai envoyé ça dans l'espace de rédaction des dépêches (oui, faut le faire, je sais), et ça a donc fini en dépêche.
Bref, merci, vraiment, et continuez comme ça.
S'il est possible de transférer mon lot au septième de la liste, ça fera deux heureux.
[^] # Re: "Pourquoi voyez-vous ce message ?"
Posté par xulops (site web personnel) . En réponse au journal Le Monde, vous voulez bien respecter le RGPD (spécifiquement la partie consentement) ?. Évalué à 4.
Moi ce qui me chagrine, c'est qu'ils n'aient pas mis un "donc" ou "de ce fait" ou encore "Puisque …" entre le "vous avez choisi…" et le reste. Du coup il manque une relation explicite de cause à effet entre le refus des cookies et l'interdiction d'accès.
Formulés comme ça, ce sont 4 phrases dans trois paragraphes isolés n'ayant pas de rapports explicites entre eux, or l'implicite est toujours sujet à controverse.
Tu me diras, il suffit de voir la différence entre acceptation-cookie/accès et non-acceptation-cookies/non-accès, en s'assurant que rien d'autre ne perturbe l'expérience (que je n'ai pas faite car rien à battre du Monde).
[^] # Re: direction
Posté par xulops (site web personnel) . En réponse au journal Un ami a la carte. Évalué à 3.
Il n'y a pas l'air d'avoir de roulement à billes au niveau du maintien de l'axe, il doit donc probablement être fixe, et chaque roue semble avoir un roulement au niveau de l'engrenage. Les roues sont donc indépendantes et chacune à son moteur.
C'est pour aller tout droit que ça doit demander un réglage fin, dans ce genre de config, il y a toujours une roue qui tourne un chouia plus vite que l'autre.
# Barré
Posté par xulops (site web personnel) . En réponse au journal Un ami a la carte. Évalué à 7. Dernière modification le 26 décembre 2020 à 18:29.
C'est barré, ce virus atteint aussi le cerveau, visiblement. ;)
J'avoue que j'ai un peu de mal à saisir le but du jeu, mais vu que "Un agayon désigne en wallon un objet dont l'utilité n'est pas connue ou comprise", je me sens moins con.
Mettre un Raspberry Pi4 sur batterie, c'est osé au regard de sa consommation électrique.
Pour un robot avec caméra, je serais parti sur un ESP32-CAM qui consomme 20 fois moins (et coûte aussi 20 fois moins cher), quitte aussi à le coupler à un Arduino si les entrées/sorties manquent (vu que la caméra en phagocyte déjà un paquet).
N'empêche que c'est fun, et c'est bien le plus important.
[^] # Re: Tableau
Posté par xulops (site web personnel) . En réponse à la dépêche TapTempo pour Arduino Uno. Évalué à 1.
Tu as raison, avec ou sans le = {0}, le programme compilé fait la même taille et les valeurs du tableau fraîchement créé sont à zéro.
Confirmation sur StackExchange
[^] # Re: Intéressant !
Posté par xulops (site web personnel) . En réponse à la dépêche TapTempo pour Arduino Uno. Évalué à 3.
C'est une autre façon de faire et qui fonctionnerait aussi. Il y a plein de façon de faire, c'est cool. Dans un programme plus gros, il faudrait faire attention que la fonction appelée par l'interruption soit la plus courte possible, car elle est bloquante.
Si on utilise une interruption, le attachInterrupt serait plutôt comme ça :
attachInterrupt(digitalPinToInterrupt(TAP_PIN), mesure, FALLING);
… car lorsqu'on presse le bouton, le pin 2 passe de HIGH à LOW.
[^] # Re: Intéressant !
Posté par xulops (site web personnel) . En réponse à la dépêche TapTempo pour Arduino Uno. Évalué à 4.
L'Arduino Uno dispose bien d'interruptions qu'on pourrait utiliser pour le mettre en veille et le réveiller, histoire de gagner en consommation électrique.
Mais pendant la mesure (entre deux taps) on ne pourrait pas utiliser le "Power down mode" car il couperait aussi le timer (millis) dont on a besoin pour calculer le tempo. On ne pourrait utiliser que le "Power save mode" bien moins intéressant énergétiquement.
De plus, la carte Uno intègre le convertisseur USB/Serial qui ne se mettra pas en veille, ainsi que le régulateur 3.3V, la diode de présence de tension… au final, on ne gagnerait que quelques mA pour un code bien plus complexe.
Il serait par contre plus intéressant d'activer ce "Power down mode" après les 3s d'inactivité :
- on tape, pas de mise en veille ;
- on ne tape plus, affichage du "…." pendant quelques secondes, puis extinction du rétro-éclairage de l'écran et passage en veille du micro-contrôleur ;
- on retape -> interruption, réveil du micro-contrôleur, allumage de l'écran.
[^] # Re: Tableau
Posté par xulops (site web personnel) . En réponse à la dépêche TapTempo pour Arduino Uno. Évalué à 4.
Super, ça fait passer le code compilé à 4068 octets, donc 24 octets de gagnés.
[^] # Re: ah bon, un A20 c'est lowtech?
Posté par xulops (site web personnel) . En réponse au lien lowtech magazine: comment construire un site web low-tech. Évalué à 5.
Je pense que lowtech n'a pas tout à fait la même signification en français et en anglais.
Ca ne doit pas vouloir dire qu'on peut le faire en frappant sur des cailloux, mais juste en n'utilisant que le minimum pour que ça fonctionne, pas de trucs surdimensionnés.
Mais quoi qu'il en soit, quand c'est possible, faire tourner un site web avec 2W de consommation, c'est mieux qu'avec 600W. Son serveur est à Barcelone, il y fait sans doute plus de soleil que dans le nord de la France, ça aide aussi.
Avoir des pages qui s'affiche en moins d'une seconde, c'est mieux que d'en attendre 5 ou plus.
Les images en mode dégradé, dans son contexte, n'est pas gênant, et donne même un style particulier (qu'on aime ou pas, les goûts et les couleurs…) au site.
Et puis bon, il fait ce qu'il veut après tout, c'est son site. Comme tu dis, l'idée est bonne.
# Pas que la grande muraille de Chine
Posté par xulops (site web personnel) . En réponse au sondage Craindre la balkanisation du Web…. Évalué à 10. Dernière modification le 16 décembre 2020 à 12:20.
De Chine, les accès aux serveurs étrangers sont fortement limités (serveurs blacklistés genre ceux de Google et Facebook, et le reste ultra-lent à décourager les plus patients), et au niveau national, le contenu du net est très surveillé et nettoyé.
D'ailleurs en chinois, le mot "censure" se dit 和谐 (héxié) et est le même que le mot "harmonieux". Du coup, sur les sites francophones de Chine, on utilise le mot "Harmonisé" pour parler d'un contenu (ou une personne) censuré.
- On entend plus parler de Robert dans le Hubei, qu'est-ce qu'il devient ?
- il s'est fait harmonisé.
- oh le con !
Bref, tout ça n'est pas nouveau, donc tout le monde est au courant. Par contre il y a une chose plus grave (si je puis dire) en Chine : les sites web disparaissent. Non pas qu'ils soient harmonisés, bien qu'il faille une autorisation du gouvernement pour ouvrir un site web, mais parce que les habitudes des chinois ont changées, ou on les a poussé à changer.
Tout passe par des apps, et principalement Wechat, qui est à l'origine une appli de chat, mais qui fait maintenant tout, mais vraiment tout. J'ai des amis chinois qui ne savent pas se servir d'un navigateur internet, ils n'en ont pas l'usage, tout se fait sur leur smartphone dans l'application qui va bien.
Bien sûr, ces applications s'appuyent sur les bases de l'internet, mais c'est invisible pour les utilisateurs.
Ma crainte, c'est que ce modèle chinois se répande partout dans le monde, et qu'au final on n'utilise plus que quelques apps gérées par des GAFAM chinois ou américains.
[^] # Re: Colonisation
Posté par xulops (site web personnel) . En réponse au lien Surveillance de masse - Huawei a testé une IA capable de reconnaître les Ouïghours. Évalué à -1.
Oui, tout comme pour certains corses (ou la Catalogne en Espagne), la volonté d'indépendance d'une partie des Ouïghours est source de conflits, attentats, … mais je pense qu'il y a davantage. Le Xinjiang est chinois depuis 1911, il y a bien eu des tentatives pour se séparer de la Chine, mais globalement rien de sérieux depuis des années 50. (en passant, ce sont les Hui, minorité ethnique musulmane de Chine, qui ont ramené les Ouïghours dans le giron chinois dans les années 40).
Ce "davantage", pour le nommer clairement, c'est le terrorisme islamique.
Le gouvernement chinois est respectueux (oui, le qualificatif peut paraître inopportun) de la religion dans le sphère privée, par contre il n'est pas du tout laxiste quand ça touche la sphère publique, et encore moins quand ça touche le terrorisme. La Chine a une politique d'assimilation que ne renierait pas Eric Zemmour, et ne tolère absolument pas de troubles sur son territoire.
Donc que les Ouïghours soient surveillés de près, sans aucun doute. Que Huawei ait développé un logiciel de reconnaissance des Ouïghours, certainement. (aparté : il ne s'agit pas d'un logiciel qui dans l'absolu (sur faciès) reconnait un Ouïghours d'un autre citoyen. Il s'agit d'une reconnaissance par comparaison avec une base de données ; on est tous fichés en Chine).
Est-ce que des millions de Ouïghours sont enfermés dans des camps d'internement ou d'éducation ? Est-ce que les femmes Ouïghours sont stérilisées ? Est-ce qu'on les oblige à manger du porc et boire de l'alcool ? Moi j'en sais rien. Pour les camps, des millions … ça doit faire de sacrés gros camps. Et puis s'il y a des files spéciales Ouïghours dans les aéroports, ça veut au moins dire qu'ils peuvent prendre l'avion et voyager hors du Xinjiang, ce qui me paraît contradictoire avec un internement massif. Le gouvernement n'oblige pas non plus les autres musulmans (y compris issus de minorités) à manger du porc ou boire de l'alcool.
En ces temps de guerre sino-américaine (car c'est une guerre, pour sûr), il y a de la propagande des deux côtés, et il me paraît malvenu de prendre tout ce qui se dit dans les medias pour argent comptant.
[^] # Re: Autohébergement
Posté par xulops (site web personnel) . En réponse au journal Linux ne m'intéresse plus. Évalué à 3.
Ton MTA peut transmettre à un MTA qui va transmettre à un autre MTA, etc. Donc c'est impossible de savoir a priori si le MTA de destination accepte ou non le 8bit.
Franchement je ne sais pas si Thunderbird ne le fait pas déjà, je ne signe pas mes mails avec PGP (je sais, c'est pas bien). Il faudrait que tous les clients mail en fasse de même, pas seulement Thunderbird. Mais déjà sans signature PGP, thunderbird envoie des mails en 8bit, qui, suivant le MTA, sera signé avec DKIM en l'état, puis peut-être converti plus tard, et donc potentiellement rejeté (mis en spam, le plus souvent) à l'arrivée.
Il y a, au niveau mondial, une décision à prendre, et à faire appliquer partout, mais c'est sans doute utopique. Cette décision pourrait être :
- un MTA qui n'accepte pas les mails en 8bit, on envoie un avis de non-distribution (avec message clair sur la raison) à l'envoyeur, histoire de forcer la main sur la mise à jour de ce MTA (on utilise le 8bit depuis plus de 15 ans).
- On modifie la RFC en indiquant que les verificateurs DKIM se doivent de prendre en charge les mails en 8bit (mais là aussi il y aura des récalcitrants, on est reparti pour 15 ans).
L'alternative est d'abandonner le 8bit, ou DKIM … On est un peu dans un sac de noeuds.
A mon avis un MTA ne devrait pas avoir à toucher au Body d'un mail, seulement à l'entête, il ne devrait jamais y avoir besoin de faire des conversions d'encoding, en tout cas pas à ce niveau là.
[^] # Re: Autohébergement
Posté par xulops (site web personnel) . En réponse au journal Linux ne m'intéresse plus. Évalué à 5.
Thunderbird n'est pas le seul.
Historiquement les mails étaient encodés en 7 bits, l'encodage en 8bit a été ensuite déployé massivement car permettant de réduire les quantités de données à transmettre. Toutefois, même encore maintenent, quelques vieux serveurs SMTP ne gèrent pas encore le 8bit.
Ce support du 8bit peut (et non pas "doit") faire l'objet d'une déclaration en début de communication (EHLO).
Quand un serveur d'envoi fait face à un serveur qui ne prend pas en charge le 8bit, il doit convertir le mail en 7bit, ou base64, ou quoted-printable.
Là dessus est venu se greffer DKIM. Et la RFC 6376 indique bien que le serveur qui applique la signature DKIM devrait systématiquement convertir préalablement les mails 8bit en 7bit ou quoted-printable :
Some messages, particularly those using 8-bit characters, are subject
to modification during transit, notably conversion to 7-bit form.
Such conversions will break DKIM signatures. In order to minimize
the chances of such breakage, Signers SHOULD convert the message to a
suitable MIME content-transfer encoding such as quoted-printable or
base64 as described in [RFC2045] before signing.
Mais un mail signé qvec PGP ne peut pas être converti, pour les mêmes raisons qu'un mail signé avec DKIM ne pourra pas être converti plus loin dans la chaine de transmission.
Donc dans un monde parfait, les vieux serveurs ne supportant pas le 8bit sont au placard, et les serveurs contrôlant les signatures DKIM sont capables de vérifier la signature des mails en 8bit.
Mais on ne vit pas dans un monde parfait, donc il existe encore des vieux serveurs, et pire, beaucoup de serveurs vont invalider la signature DKIM d'un mail 8bit car il n'est pas censé être en 8bit.
Bref, c'est la merde.
L'utilisateur qui signe ses mails avec PGP et ayant connaissance de ce problème doit donc prendre soin d'envoyer ses mails dans un encoding autre que 8bit.
Mais les utilisateurs font ce au'ils veulent, en tant qu'admin, on en revient donc à faire le choix parmi :
- on ne convertit pas le mail PGP 8bit, on signe DKIM comme ça, et DKIM sera parfois rejeté (une fois sur deux, à la louche).
- on convertit comme un bourrin en pétant la signature PGP
- on s'arrache les cheveux à essayer d'implémenter des règles tordues dans son MTA, du genre :
si (PGP et 8bit) {
Pas de DKIM
} elseif (8bit pas PGP) {
convertit en 7bit et signe DKIM
} else {
signe DKIM seulement
}
Bon courage pour faire appliquer ça aux MTA les plus répandus (libres ou pas).
Conclusion, de nos jours, configurer un serveur SMTP n'est pas un chose facile.
[^] # Re: Chapitre II
Posté par xulops (site web personnel) . En réponse au lien Surveillance de masse - Huawei a testé une IA capable de reconnaître les Ouïghours. Évalué à -1.
Mon cher devnewt, on se retrouve ici sur un sujet non-technique, et tu fais preuve du même
manque de tolérance envers la façon de faire des autres, au moins tu es constant.
Que tu sois convaincu que les Ouïghours soient opprimés, c'est ton droit. Si tu as des preuves irréfutables, partage donc, sinon respecte au moins la diversité des opinions.
Etant donné l'état des relations sino-américaines, il n'est pas étonnant que ces deux mastodontes se tapent dessus dans les médias, à la guerre comme à la guerre, et le gouvernement chinois ne se gêne pas pour fustiger les américains dans ses médias et exacerber le nationalisme sur son territoire. Chacun est libre de croire ce qu'il lit dans les journaux ou entend à la télé, et de tout prendre pour argent comptant, … ou de douter.
Ce que j'ai dit, et qui est factuel, c'est que les Ouïghours sont une minorité parmi 54 autres, et musulmane parmi d'autres minorités musulmanes. Il est donc logique que le fait d'être une minorité ethnique et musulmane ne soit pas l'origine d'une oppression, cela sous-entend une question pour ceux qui pensent que l'oppression des Ouïghours existe : quels sont les raisons réelles de cette oppression ? (autre que quelques gars du PPC autour d'une table qui se disent "putain, on s'emmerde ! on irait pas opprimer les Ouïghours ?", "ha ouais, bonne idée")
A vous les studios !
[^] # Re: Autohébergement
Posté par xulops (site web personnel) . En réponse au journal Linux ne m'intéresse plus. Évalué à 3.
C'est au moins le cas de Thunderbird par défaut si des accents ou caractères spéciaux sont présents dans le message.
Pour qu'il arrête d'envoyer des mails en Content-transfer-encoding 8bit, j'ai du modifier (mon thunderbird est en anglais) :
- dans les Parameters -> Composition -> Send options -> Send messages as plain text if possible.
- puis dans Parametres -> General -> Config editor… -> mail.strictly_mime à true
Comme la rédaction et la signature PGP sont fait par le client avant l'envoi au serveur, le serveur ne peut ensuite convertir l'encoding sans faire péter la signature PGP.
[^] # Re: Chapitre II
Posté par xulops (site web personnel) . En réponse au lien Surveillance de masse - Huawei a testé une IA capable de reconnaître les Ouïghours. Évalué à -1.
Non, et en bon français raleur, je ne suis pas le dernier pour critiquer plein de choses en Chine (on peut longuement discuter du manque flagrant de déontologie des médecins par exemple). Je ne prends juste pas pour argent comptant ce qui se dit dans les médias car :
je n'y suis jamais allé, je ne connais personne (auquel j'aurai un minimum confiance) dans la région concernée, pas de sources fiables, et avec méfiance car expérience passée des Ricains ayant foutu le bordel au Tibet (qui fait que moi, citoyen français, je ne peux plus m'y rendre facilement).
L'oppression, peut-être qu'elle existe, je ne peux l'affirmer ou l'infirmer. Si elle existe, je dis seulement que ce n'est pas parce que c'est une minorité (même si ça fait sans doute plus vendeur dans les médias de dire qu'une minorité se fait opprimer), ni parce qu'ils sont musulmans.
Ce que je peux dire, c'est que dans certains aéroports (celui de Shanghai, si ma mémoire est bonne), lors du passage au contrôle à l'arrivée des vols domestiques, il y a les files d'attente, et dans un coin une file spéciale pour les Ouïghours. Je suppose donc qu'ils ont droit à "un traitement de faveur" avec fouille "approfondie" et questions du genre "T'es Ouïghours, qu'est-ce que tu viens foutre à Shanghai ?".
Faut aussi savoir qu'en Chine, quand le gouvernement décide de quelque chose (et encore plus si ça touche sa souveraineté nationale), ils mettent ensuite le paquet. Ils ne font pas dans la demi-mesure, ce n'est pas comme en France où le politique va faire passer une n-ième loi pour répondre à l'actualité du moment tout en sachant pertinemment que cette loi ne sera suivie d'aucun effet. En Chine, ils décident, et ils appliquent façon rouleau compresseur en y mettant les moyens financiers et humains, c'est aussi sans doute ça qui choque nos yeux d'occidentaux.
[^] # Re: Chapitre II
Posté par xulops (site web personnel) . En réponse au lien Surveillance de masse - Huawei a testé une IA capable de reconnaître les Ouïghours. Évalué à 0.
En Chine, il y a 56 ethnies, et les Han sont largement majoritaires (93%). Toutefois les minorités sont en général mieux traitées que les Han par le gouvernement chinois. Par exemple : les étudiants ont des points supplémentaires pour postuler dans les universités, à l'époque de la politique de l'enfant unique, les minorités pouvaient déjà en avoir 2, priorité de reclassement pour les logements neufs…
Je vis en Chine, dans la province du Yunnan où les minorités ethniques sont nombreuses, je connais donc plein de chinois non-han (小数民族), et aucun ne se plaint d'être moins bien traité qu'un Han. Les relations entre Han et minorités sont très bonnes, les chinois sont plutôt fiers de leurs minorités ethniques.
Pour ce qui est des Ouïghours (env 9 millions sur 1.4 milliard), ils vivent dans la province du Xinjiang, ce n'est pas tout près, donc je n'ai pas d'infos sur ce qui s'y passe. Si oppression il y a, elle n'est cependant pas le fait que les Ouïghours soient une minorité ethnique, ni qu'ils soient musulmans d'ailleurs, puisque d'autres minorités ethniques sont également musulmanes et ça se passe très bien.
[^] # Re: Surveillance externe
Posté par xulops (site web personnel) . En réponse au journal Héberger son serveur de mails, c'est nul. Évalué à 6.
Un simple ESP8862 peut faire l'affaire, c'est d'ailleurs un super petit projet d'IOT.
Un microcontroleur wifi à quelques euros, il faut bien entendu développer une interface web pour les paramètres wifi et lister les serveurs à surveiller : IP ou nom d'hôte, port, type de service (mail, http, ssh, …), fréquence de vérification).
- Si un serveur / service est down : au choix allumer une led et aller sur l'interface web de l'IOT voir quel serveur est down, ou mieux afficher le problème sur un petit écran LCD/OLED, avec même une petite sirène d'alarme si besoin.
- une autre diode / affichage d'erreur si c'est le wifi/accès internet qui est down.
En veille (entre deux checks), la consommation est quasi-nulle (quelques mA sous 3.3V ou 5V), environ 80mA pendant le check (quelques secondes), et ça prend moins de place qu'un switch 4 ports.
Je crois que je vais me lancer, tiens.