Marotte ⛧ a écrit 8797 commentaires

Tu as probablement déjà essayé… mais au cas où, je me permets d’évoquer cette idée, comme personne ne l’a fait jusqu’ici dans les commentaires.

Est-ce qu’avec un clavier virtuel muni de plus grosses touches que le clavier d’origine ça ne va pas mieux ? Je n’arrive pas à retrouver d’entrée dans le store pour celui que j’utilise depuis longtemps sur mon téléphone Android, pourtant il me semble bien qu’il se met régulièrement à jour, bizarre… bref… Peu importe, il y a une foultitude d’applis pour remplacer le clavier d’origine avec quelque chose de plus ergonomique.

Parce que moi aussi franchement le clavier par défaut j’avais beaucoup de mal. Alors qu’avec ce "Big Buttons Keyboard Deluxe 4.0.5" même sous l’emprise d’un état alcoolique caractérisé ça passe !

En cherchant dans le store pour voir si je pouvais t’indiquer précisément l’appli en question j’ai vu qu’il y a en avait un édité par "Simple Apps", j’utilise déjà quelque unes de leurs applis, notamment leur agenda, et je dois dire qu’elles sont plutôt bien foutues. Je vais tester leur clavier, on verra si je change ou pas.

Alors oui, et là je m’adresse aux plus paranos d’entre-vous : utiliser une telle application implique de l’autoriser à capter le texte saisi de manière privilégiée, forcément… Donc je recommande d’éviter l’installer les applis les plus exotiques dans le genre, juste pour tester, parce qu’elles sont potentiellement le vecteur idéal pour un saleté de keylogger destiné à vous voler mots de passe et autres informations personnelles croustillantes.

Le filament de tungstène se sublime à l'usage. Pour augmenter sa durée de vie, il faut l'épaissir.

Déjà je doute que le filament soit 100% pure tungstène, donc déjà à ce niveau là, au niveau de l’alliage, il y a un levier d’action sur la durabilité.

Entre une lampe avec un filament très fin, pas chère, qui ne durera pas mais consommera peu et l'inverse

Tu réalise que de nos jours, et depuis un moment, les filaments sont conçus en 3D ? Et qu’en plus les ampoules modernes n’ont même plus de filament ?

La LED est manifestement clairement la technologie la plus intéressante en terme d’efficacité. Le principe de la LED existant depuis bon nombre de décennies, tu crois vraiment que ce n’est que récemment qu’une sorte de mini-saut technologique a permis de faire des ampoules exploitant cette technologie ? Ou peux-tu concevoir que les financiers qui finances toutes ces avancées technologiques successives en matière d’éclairage électrique exigent une période de rentabilisation de leur investissement ? Et que le progrès technologique se doive, soumis à leur vision purement comptable, d’être parfois « temporisé » ?

« premier prix » c'est l'électronique qui lâchait, pas la puce luminescente.

Oui et en terme de composant électronique il existe plusieurs normes, civil/militaire pour commencer, et rien que pour le civil la qualité de fabrication du composant jouera grandement sur sa durée de vie. Ajoute la qualité de l’assemblage, la qualité du contrôle qualité, etc…

1000h est une norme grandement arbitraire. (on ne va pas faire des ampoules de 1h ou 1 siècle non plus évidement…)

Je suis sûr que dans les bureaux d’études, vu qu’il peuvent plus se compétiter sur la durée, ils se tirent la bourre sur l’incertitude : ah nous on est à 1000h±12,3333h ! ON EST LES MEILLEURS ! _o_

Et vous vous basez sur quoi pour dire qu’on ne peut pas faire une ampoule qui dure plus de 1000 heures avec un rendement ou un rapport qualité/prix équivalent ? Sur quel principe physique, sur quel impondérable industriel exactement (je dis bien « industriel », pas économique ou financier) ?

Vous suggérez que ça n’est pas possible juste parce que ça ne se trouve pas dans le commerce ?

Je n’ai pas fait de mesure précise sur le sujet mais ayant connu le remplacement des ampoules à incandescences par les ampoules modernes, dites « basse-consommation », j’ai pu observer de manière empirique qu’au début de la transition, en plus de la consommation électrique moindre à luminosité équivalente ces ampoules présentaient clairement une durée de vie supérieure aux incandescentes. Ce que j’observe aujourd’hui c’est une durée de vie raccourcie, revenue peu ou prou à la durée de vie qu’avaient les ampoules incandescentes que j’ai connues jadis. À croire que les industriels ont mis un temps un peu le pied sur une obsolescence programmée aggressive pour accélérer la transition.

Et là je parle bien des ampoules les plus courantes. Parce que j’ai aussi le cas, à moins d’un mètre de moi à l’heure où j’écris ces lignes, d’une lampe de bureau à ampoule halogène qui en une trentaine d’années en est à sa seconde ampoule…

Nier l’existence du concept d’obsolescence programmée, quand on voit la foultitude d’exemples autres en dehors des ampoules, faut quand même pouvoir se munir d’une sacrée paire d’œillères. Même si je suis reconnaît que la décennie actuelle n’est pas forcément la pire en la matière.

Est-ce que le choix des 1000 h des ampoules a été fait pour optimiser l'intérêt du client ou les revenus des constructeur

Vraiment ? Si on peut créer pour un coût identique et un prix de vente équivalent une ampoule qui dure 10000 heures au lieu de 1000 on ne le fait pas par intérêt pour le consommateur ?

je pense que cela aurai été fait dasn un marché malgré tout concurrentiel.

Tu n’as pas saisi le fond même du propos : la concurrence a été faussée par intérêt, et pas celui des consommateurs, mais celui des leaders du marché, qui ainsi économisaient ainsi leurs forces, sinon perdues à devoir se concurrencer les uns les autres.

Plus récemment, l’entente des opérateurs de téléphonie mobile en est un autre exemple tout à fait avéré. La justice ayant mis au jour ce « complot » et condamné ses auteurs.

Question sérieuse : est-ce que de mon commentaire tu déduis que je pense ou prétends que ça puisse être une légende urbaine ?

Sache que je peux tourner en dérision la vérité comme le mensonge ! ;)

Pas eu le temps de regarder mais j’avais regardé il y a longtemps, au siècle dernier disons le, un documentaire sur l’affaire des ampoules. C’est clairement un cas d’obsolescence programmé dont l’unique but était de conserver une rente, du moins de la maintenir au niveau où elle était, alors que l’avancée technologique menaçait de la réduire drastiquement. Et une limitation arbitraire et concertée sur la durée de vie d’une ampoule est toujours d’actualité me semble-t-il !

Imagine… Ferme les yeux et lis ce qui suit avec attention.

Imagine que tu vends des ampoules depuis dix ans, tu nourries ta famille grâce à cette activité lucrative, et tu participes à faire vivre la famille d’un artisan ébéniste, d’un négociant de gratte-dos en ivoire et plein d’autres commerçants, artistes et autres aventuriers interlopes, toi tout comme la poignée d’autres vendeurs d’ampoules à travers le vaste monde.

Un matin, à la fin du mois de mars, un des binoclards de ton bureau d’études frappe à la porte de ton bureau, c’est celui dont tu n’arrives jamais à retenir le nom, celui qui est déjà chauve malgré son physique de puceau et ses manières d’autiste que tu n’as jamais pu supporter. Il semble excité comme un gamin à Noël qui aurait absorbé trop de sucre.

Étant donné que déjà, faire la différence entre jovialité et anxiété n’est pas toujours chose aisée, la méfiance instinctive te pousse à montrer ton œil le plus noir à cet énergumène de subalterne, qui a l’outrecuidance de venir troubler ta lecture quotidienne de la presse économique. Sûrement pour une futilité inintelligible ou pour demander une augmentation de salaire penses-tu sans le moindre doute. Loin d’imaginer la terrible affliction qui s’apprête à te frapper ce jour là.

Ce petit génie d’ingénieur te parle, le souffle court et presque en trépignant, de température, d’intensité, de collaboration avec le laboratoire Luminex, et de quelques autres concepts savants, qui sont pour toi aussi familiers que vagues.

Mais d’un coup tu décryptes son jargon scientifique, tu réalises, tu blêmis : il a mis au point une ampoule plus fiable, plus solide et surtout, qui fonctionne mille fois plus longtemps, « au minimum patron » ose-t-il ajouter. Son ignorance de la science économique l’empêche de faire preuve du minimum de correction exigé lors d’évènements aussi tragiques. Mais toi, qui porte avec tant d’abnégation le fardeau de ce puissant don de voir le futur, tu es glacé d’effroi, mordu dans ta chair par le spectre de l’ignominieuse perte financière. Les conséquences d’une telle diablerie viennent se bousculer dans ton esprit. Le prestige diminué, l’ébène qui devient cerisier, les gratte-dos en ivoire qui s’évaporent. Le ruisseau qui menace d’être le théâtre des prochains accouchements de ta femme. Un aperçu l’enfer, voire d’une réalité bien pire encore !

Il ne te faut qu’une seconde pour retrouver ta lucidité de rapace menaçant. Tu intimes l’ordre formel et impérieux à l’oiseau de mauvais augure de garder sa découverte secrète sous peine de mort violente pour lui et sa famille. Ainsi que la destruction immédiate de tout le matériel lié à cette calamité. « Tout le matériel du laboratoire » te corriges-tu. Personne n’avait jamais vu ton regard aussi noir que cet ingénieur qui sort de ton bureau ce jour là. Avec ses yeux à lui levés vers le ciel ! Tu lui feras payer son insolence plus tard. Pour l’heure il te faut agir, et agir bien. Tu fais mentalement la liste de ces sacripants de concurrents sur le juteux marché de l’ampoule électrique tandis que tu enfiles ton pardessus et te diriges au pas de course en direction de l’échoppe du télé-graphiste. « Pourvu que René McMoney de chez Luminex ait les bons réflexes ! » penses-tu. Pourvu que tu arrives à t’entendre avec lui, ainsi qu’avec ces deux charognards, les dirigeants de Luximax Corp. et Edison Inc.… Il faut couvrir d’une chape de plomb cette découverte diabolique à tout prix ! Le stress réveille tes brûlures d’estomac au moment où tu hèles le cocher avec le cœur qui bat la chamade.

Et vous connaissez la suite, sinon allez voir le lien du journal sur le sujet !

Pour les bas en nylon ça ne s’est pas du tout passé comme ça, rapport au domaine industriel différent je suppose, mais je crois que le résultat est le même. Il aura fallu une certaine quantité de jus de cerveau pour obtenir un bas qui ne file pas trop vite, mais pas trop lentement non plus.

Il paraît qu’il y a des cas d’obsolescence programmée justifiée par une optimisation utile de la maintenance, mais je ne suis pas loin (deux doigts, pas plus) de penser qu’il s’agit d’une légende urbaine !

Sur ce point, Perl (le “Pathologically Eclectic Rubbish Lister” selon la page man ^^) est de loin le champion. L’intro de la documentation ($ perldoc perl) le dit explicitement : “The Perl motto is "There's more than one way to do it.””.

C’est un langage que j’ai très peu utilisé (j’ai pas du en faire depuis deux ou trois ans, au moins), et dont je connais seulement le très très basique. Il y a deux particularités que j’ai retenues en commençant son apprentissage, c’est l’utilisation du principe des pointeurs, comme en C, c’est une gymnastique intellectuelle particulière je trouve, mais on s’y fait, et l’application à l’extrême du principe d’implicite. De mémoire il me semble qu’on peut écrire des trucs du genre for list print, ce qui permet d’écrire un code qu’on trouve soit d’une perfection ultime, soit d’une horreur absolue, mais qui ne laisse pas indifférent. :)

Mais il permet aussi d’écrire un code atteignant un équilibre entre concision et clarté, et c’est ça qui en fait un excellent langage de script àmha.

C’est strictement le contraire de Python, qui bien qu’il permette de faire la même chose de plusieurs manières, dans une moindre mesure que Perl c’est certain, considère qu’une seule syntaxe est « Pythonique », dans l’esprit du langage en quelque sorte, et qu’elle est donc la syntaxe fortement recommandée pour ceci ou cela. C’est logique étant donné que le but du langage est d’être facile à apprendre, à écrire et à relire. Il cherche l’homogénéité syntaxique pour favoriser la collaboration.

Ceci dit il me semble que c’est avec Python (3) mais pas avec de Perl (5), qu’on peut utiliser n’importe quels caractères Unicode pour nommer les variables/fonctions/class/etc… ce qui peut probablement produire un code avec un fort aspect artistique et une lisibilité très relative ! ^^

Perl est Python sont vraiment antagonistes à ce niveau là.

Je suis entièrement d’accord. Le post de Benoît Sibaud illustre très bien ton propos, c’est proprement illisible. Le genre de code qui te fait maudire le développement, ainsi que le développeur qui a écrit ça ainsi que ses parents sur au moins dix générations.

Je cherchais juste à vérifier le caractère strictement indispensable ou pas du if. J’ai bien écrit « pouvait «, pas « devait ». ;)

wismerhill semble confirmer avec son exemple, on a bien un résultat différent de l’équivalent utilisant les opérateurs booléens donné par Benoît. En toute humilité je n’affirmerai pas qu’il n’est absolument pas possible de faire un équivalent avec des opérateurs logiques, je continuerai juste à continuer penser que c’est effectivement le cas (que c’est impossible).

Par ailleurs, le if then else ne serait que sucre syntaxique, je pense qu’il serait toujours présent dans les langages de programmation, pour la raison que tu donnes.

La construction try() … catch … est prévue pour gérer les exceptions, des trucs censés survenir exceptionnellement, en d’autres termes : ne jamais survenir si tout se passe bien. Ce dont je parle c’est le fait d’exploiter ce mécanisme pour des cas prévisibles et attendus. Mais c’est vrai qu’un exemple parlant serait le bienvenue. J’ai pas trop le temps là… Mais tentons toujours :

Ce serait par exemple le fait de faire (pseudo code), au lieu d’un :

if isint(userinput): then int_var=userinput; else tell_user_he_is_dumb()

ceci :

try: int_var=userinput; catch 'TypeMismatch': tell_user_he_is_dumb()

Mais je sais pas si c’est plus clair ^^

C’est bien possible qu’en Python ce soit considérer comme “non pythonic” et que les fonctions que tu site soit recommandée (ça reste à vérifier).

Quand j’ai découvert map() ma vie a changé je dois l’avouer :)

Pour ce qui concerne les shells « classiques » (ie: pour simplifier de manière inexacte : sh, bash et ksh, voire zsh…) J’ai lu une fois qu’on pouvait toujours utiliser || ou && (avec les accolades qui vont bien si nécessaires) pour remplacer, de manière fort élégante je trouve aussi, l’utilisation d’un if (et des then et fi sans lequel il n’est rien qu’une erreur de syntaxe !). Il semblerait donc que ce soit toujours possible sauf dans le cas (pur ce que serait le plus simple qui ne soit pas faisable avec les deux opérateurs logiques && et ||) d’un :

if … then … elif … then … else … fi

Qu’en penses-tu ?

Je n’ai jamais cherché à vérifier de peur de me faire de vilains nœuds indéboulonnables au cerveau droit, que ce soit en cherchant sur le web ou en essayant de réfléchir au problème.

Sinon en dehors de ça, pour ce qui est est des constructions programmatique contre-intuitives mais souvent pratiques et concises, il y a l’utilisation du mécanisme de gestion des exceptions pour implémenter la logique du programme, c’est manifestement une chose souvent bien vue, en Python notamment, bien que ce langage se présente comme le plus « évident », le moins piégeux. Le try() … catch … n’a pourtant pas été créé comme une construction usuelle à la base !

continue est bien pratique aussi, pour passer à l’itération suivante en zappant le fin de la boucle pour l’itération en cours.

mon refus des implicites

Ne t’essaie pas à Perl alors, je crois que c’est le langage champion en terme d’implicites (même si on conserve la possibilité d’expliciter dans tous les cas).

Sympa l’option -s. J’ai pour habitude, pour faire cela, d’utiliser sed -e 's/\s\s*/ /g', qui est à mon avis moins lisible.

Je ne sais pas à quel moment ça devient plus rentable de sortir sed

En tous cas pour simplement « squeezer » les espaces/tabulations multiples tr doit être plus rentable que sed. Parce que le programme fait un peu moins de la moitié de sed en taille, donc j’imagine en temps de chargement (?), et faisant moins de choses je suppose également qu’il est plus simple et s’exécute donc plus vite. Ça doit commencer à s’inverser si tu utilises sed pour faire d’autres transformations, des transformations qu’il faudrait sinon réaliser par de multiples pipes recourant à différents programmes simples tels que tr.

Extrait du man test :

CHAÎNE équivalent à -n CHAÎNE

Mais je note que cela peut potentiellement être déstabilisant.

Je n’ai pas compris cela, et si c’était l’intention bah c’est faux : il y a une valeur par défaut, la tabulation, quand on n’indique pas de délimiteur. No magic, RTFM.

Oui je me suis mal exprimé.

J’ai tendance à sortir systématiquement awk au lieu de cut (et c’est une mauvaise habitude je reconnais) du fait que parfois les données à traiter ont des champs séparées par un nombre variables d’espaces (du moins plusieurs), et cut, si on lui indique l’espace comme séparateur, considère alors qu’il s’agit de plusieurs champs vides. Comportement qui a sûrement une bonne raison d’être, mais que je ne saisi pas. Alors que awk considère les espaces multiples comme un seul séparateur.

cut -d $'\t' […] c’est le délimiteur par défaut, pas besoin de s’embêter…

Je n’avais effectivement pas en tête que la tabulation était le délimiteur par défaut (en plus d’avoir assumé qu’il s’agissait d’espaces multiples sans même vérifer). Je suis pétri de honte, je vais recopier cent fois le manuel de bash pour expier ma faute.

Ça reste intéressant à connaître, on peut par exemple faire :

$ echo -e "plop\0toto" | cut -d $'\0' -f2
toto


Idem. Mais je me demande si le réglage du moniteur ne pourrait pas jouer aussi.

Oui mais est-ce que ce n’est pas « dommage » d’effectuer une affectation de variable inutile ? Je pense notamment au cas d’une fonction, qui pourrait être appelée de manière intensive (ce qui n’est pas le cas ici mais je parle dans le cas général). Après je ne sais pas, c’est peut-être négligeable.

Pour 6, on ne peut pas faire un cut -d"\n", on peut faire un cut en mettant une tabulation (en utilisant Ctrl+v), mais dans un script je trouve ça pas terrible. Et je crois que j’ai bêtement crû que c’était une suite d’espaces…

Tu m’apprends qu’on n’a pas besoin d’indiquer un délimiteur. Et que cut se débrouille. Merci !

Je me pencherai sûrement sur les autres remarque un de ces quatre mais pour ce soir, c’est mort. ^^

Je ne me suis pas encore penché sur Pipewire, je croyais que c’était un bête "drop-in replacement" de Pulseaudio, mais à priori c’est un projet de serveur audio visant à remplacer Jack et Pulseaudio, une solution universelle pour mettre tout le monde d’accord !?

Oui moi, mais quelle usine !

Tu m’étonnes ! Clairement pas adapté à l’utilisateur final. C’est pour ça que je suis surpris qu’il y ai pas une belle GUI pour générer un asound.conf qui va bien pour tel ou tel usage.

Et Jack parlons-en, en réalité il n’y a pas Jack, il y a Jack 1 et Jack 2, chacun ayant des fonctionnalités que l’autre n’a pas.

perso je me suis fait avoir.

C’est ça tout le charme du shell, c’est rempli de pièges tous plus saugrenus les uns que les autres ! ^^

Il est vrai que j’ai pris l’habitude (mais je ne l’ai pas fait ici, à tort) ds systématiquement mettre un commentaire au tout début du corps de la fonction du genre:

#1: ça
#2: ceci
#3: cela

ça aide…

Le dernier piège dans lequel je suis tombé il y quelques temps : un nombre qui commence par 0 est de l’octal. Si tu utilises le format +V% de date pour récupérer le numéro de la semaine tu as un bug qui survient uniquement pour un mois sur douze, pour septembre ! :)

Ah OK ! Donc le warning dont je parlais est une conséquence du fait de ne pas passer l’argument pourtant prévu (le warning que tu indiques, que j’avais aussi mais dont je n’ai pas jugé bon de parler vu que je le comprenais).

Un grand merci à toi.

Yes je connais. Une appli très astucieuse.

Jack, moins simple que ALSA.

Quelque part Jack permet de faire des choses de manière plus simple qu’ALSA, et sans devoir arrêter la reproduction du flux audio pour recharger une nouvelle configuration. Parce qu’ALSA, rien que pour permettre d’avoir ce « playback device », c’est franchement cryptique comme configuration à mettre en place. Je me demande d’ailleurs pourquoi il n’existe pas une appli pour configurer ALSA de manière plus intuitive que l’édition directe du fichier de configuration.

Évidemment le confort apporté par Jack a un coût en terme d’utilisation CPU. Je l’utilise parfois, mais quand je travaille sur un logiciel « monolithique » comme LMMS, j’apprécie de ne pas avoir Jack qui me prend une partie de la ressource CPU.

Si ça intéresse quelqu’un : la configuration d’ALSA qui permet d’enregistrer le son qui est envoyé à la carte son. Autant j’ai appris à utiliser Jack de façon intuitive, autant pour faire ça avec ALSA je n’y serais sûrement jamais arrivé sans le lien ci-dessus.

Je ne fais pas vraiment de gestion du temps. Une fois l’enregistrement démarré, il se poursuit indéfiniment jusqu’à interruption par un Ctrl+C. La fonction a_period_passed elle me sert juste à afficher à intervalle régulier à quelle durée on est rendu, avec la taille du fichier atteinte jusqu’ici.

Mais merci pour la commande timeout, je ne la connaissais pas (ou plus probablement oublié son existence). Mais comme dit plus bas, arecord prévoit déjà qu’on puisse enregistrer seulement pour une période donnée avec l’option -d.

Je devrais d’ailleurs peut-être l’utiliser pour définir une période maximum, de sécurité, parce que sinon, même si la source audio cesse, si on oublie d’arrêter le processus il doit se poursuivre jusqu’à saturation de l’espace disque.

Mais je suppose que « la voix », ce qui n’est pas « données mobiles », peut aussi passer par la 4G non ? J’y connais vraiment rien j’avoue.

En d’autres termes : la 4G peut faire ce que peut faire la 2G ou la 3G ? Non ?