xulops a écrit 303 commentaires

En 20 secondes de recherche sur Taobao, le "Amazon" chinois, ça se trouve pour moins de 25 euros livré, acceptant les différents formats de carte, avec wifi et lan.

La concurrence est rude.

Tu as le droit d'utiliser un tournevis pour planter un clou, mais c'est quand même mieux d'utiliser un marteau.

C'est quasi la situation des chinois (ceux sans VPN, c'est à dire la grosse majorité).

Vu que c'est un peu difficile en ce moment covid de venir en Chine pour tester par vous-même, cette extension peut donner un bon aperçu.
Dans mon quotidien l'accès :
- Google est bloqué (pas de moteur de recherche, pas de gmail, mais google translate fonctionne partiellement)
- facebook est complètement bloqué
- Microsoft, j'en sais rien, je n'en ai pas l'usage, donc jamais testé, mais je suppose qu'il y a moyen au moins de faire les mises à jour.

Est-ce que ça impacte la navigation sur d'autres sites ?
Non pour les sites chinois (évidemment) ; pour les sites étrangers à la Chine, c'est difficile à dire tellement c'est lent sans VPN, mais une utilisation de google analytics, une font ou un script js (genre jquery) hébergé par google ou encore un captcha google et c'est le drame : la page mouline jusqu'au time out.

Vous êtes passionné par le domaine du Libre, un brun communiquant, …

Vous ne seriez pas un brin hors la loi d'éjecter d'office un roux ou un blond, et les femmes par la même occasion ?

Je trouve l'analogie peu pertinente.
Dans le cas de l'alimentaire, on sait ce qui provoque la péremption : développement microbien, altération chimique des composés, voire des trucs juste marketing qui ne rendent pas le produit inconsommable mais juste invendable, comme le changement de couleur.
Tout cela est mesurable, reproductible, analysé en labo avec une marge de sécurité donnée, bref la date de péremption n'est pas donnée au hasard.
Il existe aussi un tas d'aliments sans date de péremption, genre les fruits et légumes.

Dans le cas d'un logiciel, il peut tourner avec des failles pendant des années sans que personne ne s'en rende compte, ou alors un hacker malin ou chanceux peut trouver une faille le lendemain de la sortie du soft. Rien de prédictible là dedans. Je me demande bien comment pourrait être calculé la date de péremption.

Les problèmes des mises à jour dans l'industrie sont souvent dus à des vieux softs qui ne sont plus maintenus (voire qui tournent uniquement sous de vieux OS, genre la graveuse qui n'a un pilote que sous win98), ou dont la migration vers une version plus récente (d'un ERP par exemple) coûte trop cher. Dans tous les cas les admins sont bien entendu parfaitement au courant, sauf que la décision "ça coûte trop cher" n'est généralement pas prise par les admins qui se taperont quand même toute la merde si le ratio bénéfice-risque qui était correct tant qu'une faille n'était pas exploitée devient tout à coup moins rentable.

Il existe déjà pleins d'outils pour gérer les contrats de maintenance, les dates de fin de support, etc. La comparaison avec une bouteille de lait dont on rajoute un euro au bout de trois mois pour décaler sa date de péremption trois mois plus tard a aussi ses limites.

Kunming, mais loin du centre-ville. Le Carrefour le plus proche est à 20 bornes, et ce n'est pas un grand 家乐福, le choix est plutôt limité. Donc faire 40 bornes pour payer là-bas un camembert aseptisé 10 fois le prix … faut vraiment le vouloir.

On peut certes trouver du fromage sur Taobao, surtout en provenance d'Australie, et à des prix encore corrects, mais quasiment que du Cheddar ou de la Mozzarella, des trucs sans bactéries vivantes. C'est déjà ça, mais un bon Maroilles ou une tome corse, c'est quand même autre chose (j'en salive).

Des fromages français, il y en a aussi sur Taobao, les classiques, mais bonjour les prix et la fraîcheur à l'arrivée, surtout en été. Un fromage qui a surchauffé trois ou quatre jours à 40° ou plus dans un camion en provenance de Ningbo (sans compter le temps et les conditions de transport entre la France et la Chine), tu manges ça et c'est au mieux deux jours bloqués aux toilettes. La chaîne du froid, ils ne connaissent pas.

J'ai le même soucis avec le beurre, j'en achète seulement en hiver et dans une boutique où les mottes de 500g sont emballées sous plastique étanche. Un séjour au frigo à l'arrivée et ça resolidifie en donnant une motte presque normale.

J'en avais fait un de A à Z il y a une quinzaine d'années, circuit conception maison sur ltspice avec win sous linux, push-pull d'EL84, mais pour guitare, donc en classe AB soit une quinzaine de W (peu importe l'impédance du HP si le transfo à la sortie adaptée). Je dois encore avoir le schéma dans un coin. L'ampli lui sert à un pote en France.

Pour guitare, la différence entre transistor et lampe est flagrante pour deux raisons :
- l'effet de pompage sur les condos HT de l'alim dont la tension s'écroule sous la demande lors de pics de puissance (les condos de filtrage sont volontairement sous-dimensionnés pour avoir cet effet, du coup il y a de la ronflette, mais c'est le cadet des soucis des guitaristes).
- la saturation / distorsion n'est pas du tout la même. Les saturations je devrais dire, puisque qu'il y en a principalement deux types avec les lampes : celle des lampes de preampli (12AX7 typiquement), et celles des tubes de puissance qui est plus intéressante je trouve, car elle mélange la saturation des tubes avec celle du transfo de sortie + pompage (j'ai du changer un transfo de sortie sur un VOC AC30 des années 60 car le gars avait joué si fort si longtemps que le transfo avait pris feu).

En hifi, ces différences n'existent pas, car les condos de filtrage sont sur-dimensionnés et on évite d'aller titiller les limites des tubes.

Si tu prévois de faire un ampli en classe A, il fera aussi chauffage en hiver. Double effet.

Tu as oublié les amplis encore plus vieux mais toujours très utilisés de nos jours : les amplis à lampes (ou à tubes).

Là on a l'alim qui fait 230V/50Hz -> transfo haute tension (et basse tension pour les filaments) -> redressage/filtrage (par diode ou lampe redresseuse)

Je trouve que les amplis à lampes sont de belles pièces, surtout les vieux amplis guitare. J'en ai réparé / recablé un bon paquet, y compris des monstres des années 60, et on sent à la fois le côté artisanal et méticuleux des constructions de l'époque.
Sans être audiophile, un ampli à lampes, ça sonne pas pareil.

laissez tomber, vous ne ferez jamais le poids.

A manger du gratin dauphinois tous les jours, il y a moyen de faire rapidement le poids … au sens propre.

C'est à peu près tout les pays sauf la France quoi :-)

Voila, en gros.

Dans les pays européens, on trouve encore assez facilement du fromage français, certes un peu plus cher, mais on peut survivre. Par exemple j'ai vécu un an en Suède profonde (bled au nord, pas Stockholm) et je trouvais tout de même quelques fromages français, et le bleu danois à peu près mangeable (faute de grives …)

Hors Europe… heu… c'est la misère fromagère.

… et va t'en trouver de la crème fraîche en Chine, le truc qui n'existe pas.
Rien que pour ça j'envisage le retour en France, et pour le fromage aussi, un pays sans fromage, mazette, je ne pensais pas que ça manquerait autant.

Sinon la recette universelle, ça dépanne toujours :

Dans un ampli de puissance, le plus important, c'est l'alimentation. Si c'est un ampli classe AB, c'est avec de gros tranfos, donc ça pèse lourd. Si c'est du classe D, c'est léger, mais cher (techno plus pointue à dev).

Pour l'ampli que tu cites, l'alim n'est pas incluse, et les caractéristiques annoncées sont clairement fantaisistes.
Le truc est censé te sortir 2x100W (en oubliant bien de dire de quels watts il s'agit) en consommant maxi 24V x 3A, soit 72W électrique.
Je ne dis pas que (surtout vu le prix) ce n'est pas utile, ni qu'il n'a pas rendu le service que tu en attendais, juste que le marketing en matière d'ampli est souvent extraordinaire.

Les watts, c'est tout et n'importe quoi (surtout n'importe quoi). Entre les watts musicaux (délirants), les watts efficaces, les watts RMS, les watts donnés sous 2 ohms en pont alors que l'ampli ne tiendrait pas une impédance aussi faible… il y a à boire et à manger.

Le seul qui tient un peu la route, c'est le watt RMS, et encore faut-il regarder sous quelle impédance de HP.

L'ampli cité ne doit pas dépasser 2 x 30W RMS, ce qui peut être suffisant dans bien des circonstances, surtout si les HP ont une grande sensibilité (>90dB/W à 1m).

En bombe contact tout usage, il y a le fameux KF F2 (je ne sais pas si j'ai le droit de citer une marque spécifique sur LinuxFr, donc j'en cite une deuxième pour équilibrer : Kontakt 60).

Il existe des bombes spéciales pour potards, et même spécifiquement pour les potards linéaires (fader des tables de mixage). Est-ce réellement différent du KF F2 ou est-ce juste marketing ? Je vous laisse trancher.

Si le potard est vraiment grippé et crachouille à mort, j'attaque au WD40 (qu'on trouve dans tout magasin de bricolage), et je finis au KF F2.

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.

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.

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.

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