Marotte ⛧ a écrit 8719 commentaires

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 ?

Non, il suffit de trouver une cabine téléphonique !

Les FAI sont déjà interconnectés avec les forces de l'ordre (écoutes judiciaires), la justice (blocages DNS), les renseignements (loi de programmation militaire de 2015), Hadopi, etc.

Je me souviens qu’un moment on a imposé aux FAI de conserver trois ans minimum de meta-données. Afin de pouvoir, sur trois ans d’historique, savoir que telle IP avait été attribuée à l’abonnement de untel à telle heure tel jour. Et ça c’était il y a un paquet d’années. Ça se trouve aujourd’hui la loi les oblige à conserver bien plus que ça et encore plus longtemps.

On est également en train d'étudier la possibilité de faire une muraille de Chine numérique (comme d'autres pays, évidement).

C’était un peu le sens de mon propos. si on veut vraiment censurer l’utilisation d’Internet il faut mettre en place les dispositifs techniques adéquats. Un gouvernement ne peut pas simplement demander à telle ou telle plateforme de faire le nécessaire.

(sauf peut-être toi, t'as ptetre des trucs à cacher ?).

Ça fait longtemps que je m’intéresse à Internet et à la législation le concernant. Et ça fait notamment bon nombre d’années que j’ai pris conscience que l’argument : « Aucun problème à ce que je sois surveillé vu que je n’ai rien à cacher » est parfaitement naïf. Je vais prendre un exemple volontairement caricatural pour expliquer : imagine que tu sois collectionneur de timbre, et qu’un jour, l’état décrète que collectionner les timbres est dorénavant illégal. Seras-tu prêt à cesser toute activité philatélique, juste pour « ne rien avoir à cacher » ?

« Je n’ai rien à cacher » signifie plus précisément : « je n’ai rien à cacher aujourd’hui à l’état actuel ». Personne ne peut prétendre qu’il n’aura jamais rien à cacher à quiconque.

je pourrais faire par virement mais il faut envoyer un courriel

Pourquoi un courrier ?

Pour permettre un virement il suffirait d’indiquer un IBAN. L’association n’a pas de compte propre ou bien il y a une problématique que j’ignore ?

Parce qu’un IBAN (qui pourrait être celui du trésorier s’il n’y en a pas d’autre) ça permet seulement de recevoir de l’argent, ça peut à ma connaissance être une information publique, contrairement aux détails d’une carte bancaire, qui eux peuvent être détournés pour plein de trucs.

De nombreux organismes et vendeurs indiquent leur IBAN sur leur site, c’est quand même hyper simple, même si ça exige encore parfois un délai de quelques jours pour être effectif.