Bien qu’il y ait un évident point commun, quand on parle d’assembleur, il y en a presque autant que d’architectures CPU/micro-contrôleur, non ? Ou bien est-ce qu’il y a quelques « standards » qui s’imposent ?
Je me souviens en avoir fait un peu au lycée, pour programmer un micro-contrôleurs. Pour caricaturer je dirais que ça s’apparente plus à du Brainfuck qu’à un « langage » de programmation digne de ce nom ^^ . Ça me semble plus appartenir au domaine hardware que software. J’ai tort je sais, car il faut bien admettre que c’est incontournable pour le fonctionnement d’un ordinateur, et de tout logiciel un peu plus évolué.
Quand je vois aujourd’hui le projet MenuetOS, qui montre qu’il est possible d’écrire un OS et des applications de « haut niveau » en se limitant à l’assembleur, je ne peux avoir qu’une immense admiration pour les gens qui s’emploient à cela. Il doit falloir une sacrée motivation et les compétences qui vont bien.
C’est dommage que MenuetOS ne soit plus libre depuis sa version 64bits (la version 32bits l’est), je me souviens l’avoir testé il y a pas mal d’années sur un PC, et effectivement la rapidité d’exécution était impressionnante. Ça me fait plaisir de voir qu’un projet comme celui-ci est toujours actif, j’espère qu’un jour il sera libre à nouveau. Je me demande quels sont ses domaines d’application, je suppose qu’il doit y avoir quelques « niches », ce qui explique que le projet survive.
C’est dur à lire, dur à maintenir, super casse gueule, et les compétences court pas foule.
Que ce soit plus dur à lire et plus casse gueule que Python je peux l’admettre sans problème, mais pour ce qui est des compétences… Dans la structure dans laquelle je bosse il y a nettement plus de gens qui ont des rudiments de shell (Bash/KSH) que de gens qui connaissent Python.Je suis ptetre dans une structure exceptionnelle(ment retardée), chacun jugera.
qui viennent avec un eco système aussi gros
Alors cet argument il me fera toujours autant marrer… Le shell, par exemple Bash, vient avec un « éco système » qui n’a rien à envier à celui de Perl ou celui de Python : il est composé de binaires tels que "curl", "bc", etc…. Et note bien que cet « éco-système », mais tu veux peut-être dire « environnement » (?) est déjà disponible par défaut sur tout système Unix-like, pas besoin d’aborder des installations additionnelles qui viennent avec leur lot de subtilités telles que "Virtualenv", "CPAN", ou autre joyeuseté de ce type. Donc celui qui a le plus gros c’est sans conteste le shell !
J’irai pas coder une suite bureautique WYSIWYG ou un simulateur de vol en Bash on est d’accord, maintenant, pour la plupart des besoins de devops, voire tout ce qui est informatique de gestion, c’est souvent le meilleur choix.
Ceci dit, je kiffe Python, j’en ai écrit pas mal, j’aime bien. Mais quand je vois des outils écrits en Python il y a quelques années qui nécessitent cinq ou six libs Python à des versions bien précises pour fonctionner (bonjour la procédure de déploiement du bignou…), et que je compare à un script shell qu’on peut juste copier d’une RHEL 7 à une RHEL 8 (c’est un exemple) et roule ma poule, sans te prendre plus la tête, bah perso les pièges du shell (et ils sont vicieux !) je me les coltine sans trop de remord.
La CI, c’est la base de la base.
Ah ah ha… si tu as la chance de bosser dans une structure qui applique sans exceptions les principes de la CI, du gitops, etc, systématiquement, bah tant mieux pour toi…
Les shells « POSIXoïde » oserais-je dire, sont aussi obsolètes de nos jours que le langage C pourrait l’être dans le domaine des langages compilés, soit : absolument pas. Même si d’autres langages les surpassent sur certains points, pour certaines applications.
Merci pour ce journal, c’est du bon son je trouve. Un peu convenu et sans beaucoup de prise de risque mais un bon son quand même. (ouai je suis assez difficile comme public)
C’est clair que quand il s’agit de musique numérique le point fondamental c’est comment « humaniser » cette musique, et le piano est clairement un dispositif (aka : device) adapté. Il explique ça très bien dans la vidéo.
Rien que le fait que le clavier de piano/clavecin ait été directement considéré comme l’interface de facto pour le MIDI (Musical Interface Digital Instrument), et les différents synthétiseurs, est déjà un signe de son aspect universel pour ce qui est de la gamme diatonique. Gamme diatonique qu’il est possible de « dévier/tuner » à l’infini en jouant simplement sur la tension de chaque corde. Sans parler des modifications de timbre possibles par ailleurs.
Mais les instruments tels que les violons (plus largement tout instrument à corde sans frète), ou les cuivres tels que les trombones, qui offrent une continuité en terme de fréquences reproductibles ont aussi leur mot à dire !
IMO, best music nowadays is based on the two pillars which are numeric and analog technologies.
Ton commentaire et mon expérience récente avec un logiciel en PHP m’incite à te poser la question suivante : Dans le cas où tu connais bien-sûr, même de réputation seulement, as-tu un avis sur le framework PHP nommé Symfony ?
Le choix d’une solution « tournée vers le futur et prenant en compte des besoins non encore exprimés mais qui à coup sûr ne manqueront pas de survenir, tout en minimisant le risque de créer de la dette technique » plutôt qu’une solution « ad-hoc, minimale et sans la moindre de nouveauté par rapport aux solutions déjà mises en œuvre par ailleurs » me laisse toujours songeur quant aux attentes de ses promoteurs.
Pour prendre un exemple (à peine fictif) que je trouve représentatif : un besoin qui pourrait être adressé à l’aide d’un simple script shell/Perl qui fait deux requêtes SQL et trois appels API, va sembler à certains être une bonne occasion de mettre en œuvre un flux de messages (parce qu’ajouter un SPOF est toujours bon è prendre ?), choisir d’implémenter cela en Go (parce qu’en 202X le shell/Perl est obsolète ?) quand bien même il sait parfaitement que bien que le Go puisse être plus facile à maintenir que le shell dans l’absolue, il n’est dans le contexte maîtrisé que par deux personnes dont une part à la retraite dans un an. Sans oublier de mettre en place une chaîne de CI exprès pour ce « projet », en prétextant qu’elle pourra servir pour les futurs outils qu’enfin grâce à lui auront un pied dans l’avenir au lieu de reposer sur des technologies « obsolètes » puisque dépréciées par Google ou Amazon il y a déjà six long mois ! Le fait que telle ou telle brique logiciel n’existe qu’en version 0.X et ait deux chances sur trois d’être abandonnée au profit du nouvel outil « qui fait l’unanimité chez les spécialistes et rend caduc l’intégralité des méthodes mises en œuvre ces cinquante dernières années » n’est pas une source de questionnement mais au contraire le signe indiscutable de la pertinence de leur choix. sans oublier pour finir de déployer ça sur une une plateforme Kubernetes, pas qu’un besoin identifié l’exige, mais parce, mais parce qu’ « Aujourd’hui Kubernetes rend toutes les solutions actuelles obsolètes.
Je peux admettre que je suis probablement touché par un excès inverse, et que je suis amené de ce fait à négliger des solutions réellement avantageuses pour tous à moyen terme. Mais je constate régulièrement que les promoteurs des solutions que j’évoque semblent considérer que la « modernité » elle-même est un argument indiscutable qui valide leur choix en rendant tous les autres choix caducs par principe.
Jeune j’étais persuadé que les « vieux cons » pouvaient parfois avoir raison, maintenant que j’ai ce rôle je suis au moins heureux de découvrir que j’aurais eût tort de penser autrement à l’époque.
Je suis bien de ton avis, si ça devient obligatoire ce sera une bonne nouvelle, ça voudra dire que la civilisation a survécu au changement climatique et opéré une transition énergétique vers des sources renouvelables… Nous tous ici seront morts depuis longtemps, le noyau Linux à la version 34.1.5…
Le seul site pour lequel j’ai du m’identifier officiellement, avec communication de la carte d’identité française, c’était à l’époque où je jouais au poker en ligne. L’ARJEL et la législation associée ont été mises en place juste pour me faire chier moi je pense, pile au moment où je m’y mettais… Coïncidence ? Je ne crois pas !
Une telle obligation pour Facebook et compagnie je n’y crois pas un instant. Déjà du fait que s’il y a un domaine qui le justifierait en dehors des jeux en ligne, et même davantage que les jeux en ligne d’après moi, c’est la pornographie industrielle en ligne. Or même pour ce contenu (reposant en partie sur la traite d’être humain (surtout humaine…) et le viol, au potentiel addictif au moins aussi élevé que les jeux d’argent, et aux conséquences psychologiques nettement plus profondes (sans jeu de mot) que la désinformation classique) ça n’a jamais été mis en place, pas plus en France que, à ma connaissance, dans un autre pays de l’UE. Même dans le pays ayant interdit de donner des fessés aux enfants (la Suède ?) je ne suis même pas sûr qu’ils aient tenté de le faire réellement, mais je peux me tromper.
Je suis tombé dessus par hasard en cherchant complètement autre chose et j’ai directement repensé à ce journal :
Homepage: https://sourceforge.net/projects/zint/
Download-Size: 38,2 kB
APT-Manual-Installed: yes
APT-Sources: http://deb.debian.org/debian bookworm/main amd64 Packages
Description: utilitaire en ligne de commande pour transformer des données en code-barre
Zint est une bibliothèque d’encodage et de création d’image de code-barre.
Elle gère actuellement plus de 50 représentations symboliques dont les
codes 4-state de la poste australienne (redirect, reply-paid, routing,
standard customer), les codes Aztec (ISO 24778), Aztec Runes, Channel,
Codabar, Code 11, Code 128 (ISO 15417), Code 16k, Code 2 of 5 (Data Logic,
IATA, Industrial, Interleaved, Matrix), Code 32 (Pharmacode italien),
Code 39 (ISO 16388), Code 39 Extended, Code 49, Code 93, Code One, Databar
(Expanded, Expanded Stacked, Limited, Stacked Omnidirectional), Data
Matrix (ISO 16022), poste allemande (Identicode, Leitcode), poste
néerlandaise KIX, EAN-14, European Article Number (EAN), Facing
Identification Mark (FIM), Flattermarken, Grid Matrix, ITF-14,
International Standard Book Number (ISBN), codes-barres des postes
japonaise et coréenne, LOGMARS, Maxicode (ISO 16023), MicroPDF417
(ISO 24728), Micro QR Code, MSI Plessey, NVE-18, PDF417 (ISO 15438),
Pharmacode (2-track, Zentralnummer (PZN)), PLANET, Postnet, QR Code
(ISO 18004), code-barre 4-state Royal Mail, Telepen, Telepen Numeric,
UK Plessey, Universal Product Code (UPC-A, UPC-E), USPS Intelligent Mail
ainsi que HIBC.
.
Sont aussi incluses les traductions en Unicode pour les représentations
qui gèrent les jeux de caractères Latin-1 et Kanji, la prise en charge des
données GS1 incluant la vérification et l’insertion automatique des
caractères FNC1 et la prise en charge de l’encodage des données binaires y
compris les caractères NULL (ASCII 0).
.
Ce paquet fournit le générateur de code-barre Zint (utilitaire en ligne de
commande).
Plutôt complet l’outil. J’ai testé vite fait. Assez simple à prendre en main. QR code, PDF417, et bien d’autres (du carrément exotique même je dirais ^^), gestion de la couleur, de la rotation, etc… pas mal d’options.
C’est pour PC, il ne doit pas exister sous Android ceci dit.
On peut utiliser un lecteur spécifique (je pense qu’on parle des lecteur laser ?) mais il est très certainement possible de le lire avec la technique « photo numérique + logiciel », ça ce fait d’après-toi ? Il semblerait que ça n’ait pas grand intérêt. Inversement il existe à priori ce type de lecteur qui lisent aussi les QR code, tu confirmes ?
Pour le PDF417 aussi j’imagine que plus la résolution augmente et plus la lecteur devient exigeante.
En fait ce que tu dit c’est qu’avec du PDF 417 et un lecteur laser on peut obtenir mieux qu’avec un QR code et un scan par APN ? Je comprends mieux mais du coup. mais si on se limite au scan par APN le QR code reste plus avantageux de ce que je comprends, surtout qu’ici la tolérance à une altération physique du code n’est d’aucune utilité.
QR code […] et PDF 417 sont tous deux « 2D barcode » ;)
Alors je chipote peut-être mais le PDF 417 me semble être une sorte d’encodage 2D « du pauvre », un peu à l’image de ce qu’est la perspective cavalière comparée à la perspective réaliste… C’est du moins ce que je comprends de :
PDF417 is a barcode with several linear rows of stacked codewords. It can be read from left to right in linear order with a simple linear scan. However, QR codes and DataMatrix codes are 2D matrix barcodes; you should use a 2D imaging scanner to read them.
Alors tu me diras, qu’est-ce qu’un carré sinon un empilement de lignes ? Je note aussi, qu’en plus de la tolérance aux erreurs que tu cites, PDF 417 a aussi l’avantage d’être lisible par un lecteur classique de code-barres, sans recours à un dispositif tel qu’un APN ou scanner. J’ignore cependant si ça présente encore un véritable avantage pour certains usages de nos jours.
Le fait que ton message soit moinssé m’a interpelé. Tu es sûr de toi sur cette histoire de limite ?
D’après ce que je lis ici c’est bien le QR code qui semble le plus adapté.
Si en plus, sur un smartphone, la lecture du QR code est native mais pas celle du PDF 417, alors il y a vraiment très peu d’intérêt, pour ne pas dire aucun, à supporter ce format pour cette apllication.
D’après ce que je comprends le PDF 417 n’est pas « en 2D », il est semblable aux différents codes-barres classiques, mais on empile les lignes, c’est peut-être ainsi qu’on peut éventuellement coder plus d’information ? On peut empiler un nombre illimité de lignes ?
et là je m’adresse aux plus paranos d’entre-vous […]
De l’intérêt de f-droid ou de compiler soi-même à la source…
Compiler pour Android je ne sais malheureusement pas faire et pas la motivation d’apprendre.
Sans oublier le fait qu’on a déjà vu des projets libres avec une backdoor, j’ai en tête deux exemples : irssi un client IRC dont les auteurs voulaient monter que personne ne lisait jamais le code source (la backdoor était dans le fichier de configuration du build), je ne sais plus combien de temps ça a pris pour que quelqu’un s’en rende compte mais il y a eu des discussions assez énervées suite à cette découverte. Et Tor, dont un des contributeur fût un membre du FBI qui a sciemment introduit un code exploitable pour chopper je ne sais plus quel criminel qui utilisait Tor. La faille a été comblé assez vite, avant que le FBI ne l’exploite pour le chopper, ils ont eu bien de la chance que le malfaisant n’avait pas pris le soin de mettre à jour son Tor Bundle… à méditer !
J’aurais du mal à dire entre Google Store et F-Droid lequel présente le plus de risques (risque au sens large). Peut-être que F-Droid a une procédure béton pour éviter de distribuer du malware ? J’ai installé plusieurs apps depuis F-Droid.(j’y connais rien à Android). Mais effectivement pour l’app du clavier dont je parle je n’ai pas eu le réflexe de regarder (c’est p-e tout simplement pour ça que je la retrouvais pas ^^)
C’est bien utile dans certains cas que l’on puisse utiliser un clavier physique avec Android. Mais le but d’une terminal mobile c’est de l’avoir avec soi quand on se déplace et pouvoir l’utiliser rapidement. Sinon autant avoir un desktop voire un transportable/portable, non ?
Vous travaillez à un poste fixe avec une tablette ou un smartphone ou bien vous vous déplacer avec un clavier physique ?
J’ai du mal à voir l’usage concret. Pour du développement destiné à Android peut-être ?
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.
Posté par Marotte ⛧ .
En réponse au journal CPU Ex0215 Café bricole.
Évalué à 2.
Dernière modification le 26 octobre 2023 à 00:30.
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_
Posté par Marotte ⛧ .
En réponse au journal CPU Ex0215 Café bricole.
Évalué à 0.
Dernière modification le 25 octobre 2023 à 19:56.
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.
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()
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 !
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).
[^] # Re: la fin du site central…
Posté par Marotte ⛧ . En réponse au journal Le sophisme du meilleur outil. Évalué à 3.
Bien qu’il y ait un évident point commun, quand on parle d’assembleur, il y en a presque autant que d’architectures CPU/micro-contrôleur, non ? Ou bien est-ce qu’il y a quelques « standards » qui s’imposent ?
Je me souviens en avoir fait un peu au lycée, pour programmer un micro-contrôleurs. Pour caricaturer je dirais que ça s’apparente plus à du Brainfuck qu’à un « langage » de programmation digne de ce nom ^^ . Ça me semble plus appartenir au domaine hardware que software. J’ai tort je sais, car il faut bien admettre que c’est incontournable pour le fonctionnement d’un ordinateur, et de tout logiciel un peu plus évolué.
Quand je vois aujourd’hui le projet MenuetOS, qui montre qu’il est possible d’écrire un OS et des applications de « haut niveau » en se limitant à l’assembleur, je ne peux avoir qu’une immense admiration pour les gens qui s’emploient à cela. Il doit falloir une sacrée motivation et les compétences qui vont bien.
C’est dommage que MenuetOS ne soit plus libre depuis sa version 64bits (la version 32bits l’est), je me souviens l’avoir testé il y a pas mal d’années sur un PC, et effectivement la rapidité d’exécution était impressionnante. Ça me fait plaisir de voir qu’un projet comme celui-ci est toujours actif, j’espère qu’un jour il sera libre à nouveau. Je me demande quels sont ses domaines d’application, je suppose qu’il doit y avoir quelques « niches », ce qui explique que le projet survive.
[^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs
Posté par Marotte ⛧ . En réponse au journal Le sophisme du meilleur outil. Évalué à 5.
Que ce soit plus dur à lire et plus casse gueule que Python je peux l’admettre sans problème, mais pour ce qui est des compétences… Dans la structure dans laquelle je bosse il y a nettement plus de gens qui ont des rudiments de shell (Bash/KSH) que de gens qui connaissent Python.Je suis ptetre dans une structure exceptionnelle(ment retardée), chacun jugera.
Alors cet argument il me fera toujours autant marrer… Le shell, par exemple Bash, vient avec un « éco système » qui n’a rien à envier à celui de Perl ou celui de Python : il est composé de binaires tels que "curl", "bc", etc…. Et note bien que cet « éco-système », mais tu veux peut-être dire « environnement » (?) est déjà disponible par défaut sur tout système Unix-like, pas besoin d’aborder des installations additionnelles qui viennent avec leur lot de subtilités telles que "Virtualenv", "CPAN", ou autre joyeuseté de ce type. Donc celui qui a le plus gros c’est sans conteste le shell !
J’irai pas coder une suite bureautique WYSIWYG ou un simulateur de vol en Bash on est d’accord, maintenant, pour la plupart des besoins de devops, voire tout ce qui est informatique de gestion, c’est souvent le meilleur choix.
Ceci dit, je kiffe Python, j’en ai écrit pas mal, j’aime bien. Mais quand je vois des outils écrits en Python il y a quelques années qui nécessitent cinq ou six libs Python à des versions bien précises pour fonctionner (bonjour la procédure de déploiement du bignou…), et que je compare à un script shell qu’on peut juste copier d’une RHEL 7 à une RHEL 8 (c’est un exemple) et roule ma poule, sans te prendre plus la tête, bah perso les pièges du shell (et ils sont vicieux !) je me les coltine sans trop de remord.
Ah ah ha… si tu as la chance de bosser dans une structure qui applique sans exceptions les principes de la CI, du gitops, etc, systématiquement, bah tant mieux pour toi…
Les shells « POSIXoïde » oserais-je dire, sont aussi obsolètes de nos jours que le langage C pourrait l’être dans le domaine des langages compilés, soit : absolument pas. Même si d’autres langages les surpassent sur certains points, pour certaines applications.
# De la musique avec un grand A
Posté par Marotte ⛧ . En réponse au journal Grandbrothers. Évalué à 3.
Merci pour ce journal, c’est du bon son je trouve. Un peu convenu et sans beaucoup de prise de risque mais un bon son quand même. (ouai je suis assez difficile comme public)
C’est clair que quand il s’agit de musique numérique le point fondamental c’est comment « humaniser » cette musique, et le piano est clairement un dispositif (aka : device) adapté. Il explique ça très bien dans la vidéo.
Rien que le fait que le clavier de piano/clavecin ait été directement considéré comme l’interface de facto pour le MIDI (Musical Interface Digital Instrument), et les différents synthétiseurs, est déjà un signe de son aspect universel pour ce qui est de la gamme diatonique. Gamme diatonique qu’il est possible de « dévier/tuner » à l’infini en jouant simplement sur la tension de chaque corde. Sans parler des modifications de timbre possibles par ailleurs.
Mais les instruments tels que les violons (plus largement tout instrument à corde sans frète), ou les cuivres tels que les trombones, qui offrent une continuité en terme de fréquences reproductibles ont aussi leur mot à dire !
IMO, best music nowadays is based on the two pillars which are numeric and analog technologies.
[^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs
Posté par Marotte ⛧ . En réponse au journal Le sophisme du meilleur outil. Évalué à 4. Dernière modification le 13 novembre 2023 à 13:44.
Ton commentaire et mon expérience récente avec un logiciel en PHP m’incite à te poser la question suivante : Dans le cas où tu connais bien-sûr, même de réputation seulement, as-tu un avis sur le framework PHP nommé Symfony ?
# De la pertinence du KISS et d l’anticipation des besoins futurs
Posté par Marotte ⛧ . En réponse au journal Le sophisme du meilleur outil. Évalué à 10.
Je ne suis pas développeur mais devops.
Le choix d’une solution « tournée vers le futur et prenant en compte des besoins non encore exprimés mais qui à coup sûr ne manqueront pas de survenir, tout en minimisant le risque de créer de la dette technique » plutôt qu’une solution « ad-hoc, minimale et sans la moindre de nouveauté par rapport aux solutions déjà mises en œuvre par ailleurs » me laisse toujours songeur quant aux attentes de ses promoteurs.
Pour prendre un exemple (à peine fictif) que je trouve représentatif : un besoin qui pourrait être adressé à l’aide d’un simple script shell/Perl qui fait deux requêtes SQL et trois appels API, va sembler à certains être une bonne occasion de mettre en œuvre un flux de messages (parce qu’ajouter un SPOF est toujours bon è prendre ?), choisir d’implémenter cela en Go (parce qu’en 202X le shell/Perl est obsolète ?) quand bien même il sait parfaitement que bien que le Go puisse être plus facile à maintenir que le shell dans l’absolue, il n’est dans le contexte maîtrisé que par deux personnes dont une part à la retraite dans un an. Sans oublier de mettre en place une chaîne de CI exprès pour ce « projet », en prétextant qu’elle pourra servir pour les futurs outils qu’enfin grâce à lui auront un pied dans l’avenir au lieu de reposer sur des technologies « obsolètes » puisque dépréciées par Google ou Amazon il y a déjà six long mois ! Le fait que telle ou telle brique logiciel n’existe qu’en version 0.X et ait deux chances sur trois d’être abandonnée au profit du nouvel outil « qui fait l’unanimité chez les spécialistes et rend caduc l’intégralité des méthodes mises en œuvre ces cinquante dernières années » n’est pas une source de questionnement mais au contraire le signe indiscutable de la pertinence de leur choix. sans oublier pour finir de déployer ça sur une une plateforme Kubernetes, pas qu’un besoin identifié l’exige, mais parce, mais parce qu’ « Aujourd’hui Kubernetes rend toutes les solutions actuelles obsolètes.
Je peux admettre que je suis probablement touché par un excès inverse, et que je suis amené de ce fait à négliger des solutions réellement avantageuses pour tous à moyen terme. Mais je constate régulièrement que les promoteurs des solutions que j’évoque semblent considérer que la « modernité » elle-même est un argument indiscutable qui valide leur choix en rendant tous les autres choix caducs par principe.
Jeune j’étais persuadé que les « vieux cons » pouvaient parfois avoir raison, maintenant que j’ai ce rôle je suis au moins heureux de découvrir que j’aurais eût tort de penser autrement à l’époque.
[^] # Re: pas obligatoire pour les utilisateurs.
Posté par Marotte ⛧ . En réponse au journal La carte d'identité européenne eIDAS bientôt requise pour utiliser les grandes plateformes?. Évalué à 5. Dernière modification le 11 novembre 2023 à 09:11.
Je suis bien de ton avis, si ça devient obligatoire ce sera une bonne nouvelle, ça voudra dire que la civilisation a survécu au changement climatique et opéré une transition énergétique vers des sources renouvelables… Nous tous ici seront morts depuis longtemps, le noyau Linux à la version 34.1.5…
Le seul site pour lequel j’ai du m’identifier officiellement, avec communication de la carte d’identité française, c’était à l’époque où je jouais au poker en ligne. L’ARJEL et la législation associée ont été mises en place juste pour me faire chier moi je pense, pile au moment où je m’y mettais… Coïncidence ? Je ne crois pas !
Une telle obligation pour Facebook et compagnie je n’y crois pas un instant. Déjà du fait que s’il y a un domaine qui le justifierait en dehors des jeux en ligne, et même davantage que les jeux en ligne d’après moi, c’est la pornographie industrielle en ligne. Or même pour ce contenu (reposant en partie sur la traite d’être humain (surtout humaine…) et le viol, au potentiel addictif au moins aussi élevé que les jeux d’argent, et aux conséquences psychologiques nettement plus profondes (sans jeu de mot) que la désinformation classique) ça n’a jamais été mis en place, pas plus en France que, à ma connaissance, dans un autre pays de l’UE. Même dans le pays ayant interdit de donner des fessés aux enfants (la Suède ?) je ne suis même pas sûr qu’ils aient tenté de le faire réellement, mais je peux me tromper.
# Un autre outil intéressant
Posté par Marotte ⛧ . En réponse au journal QRNote pour copier coller du texte de son ordinateur au téléphone. Évalué à 5.
Je suis tombé dessus par hasard en cherchant complètement autre chose et j’ai directement repensé à ce journal :
Plutôt complet l’outil. J’ai testé vite fait. Assez simple à prendre en main. QR code, PDF417, et bien d’autres (du carrément exotique même je dirais ^^), gestion de la couleur, de la rotation, etc… pas mal d’options.
C’est pour PC, il ne doit pas exister sous Android ceci dit.
[^] # Re: suggestion d'améliration
Posté par Marotte ⛧ . En réponse au journal QRNote pour copier coller du texte de son ordinateur au téléphone. Évalué à 3. Dernière modification le 01 novembre 2023 à 18:36.
On peut utiliser un lecteur spécifique (je pense qu’on parle des lecteur laser ?) mais il est très certainement possible de le lire avec la technique « photo numérique + logiciel », ça ce fait d’après-toi ? Il semblerait que ça n’ait pas grand intérêt. Inversement il existe à priori ce type de lecteur qui lisent aussi les QR code, tu confirmes ?
Pour le PDF417 aussi j’imagine que plus la résolution augmente et plus la lecteur devient exigeante.
En fait ce que tu dit c’est qu’avec du PDF 417 et un lecteur laser on peut obtenir mieux qu’avec un QR code et un scan par APN ? Je comprends mieux mais du coup. mais si on se limite au scan par APN le QR code reste plus avantageux de ce que je comprends, surtout qu’ici la tolérance à une altération physique du code n’est d’aucune utilité.
[^] # Re: suggestion d'améliration
Posté par Marotte ⛧ . En réponse au journal QRNote pour copier coller du texte de son ordinateur au téléphone. Évalué à 3.
Bien vu pour le +0-0 je n’ai pas fait attention.
Alors je chipote peut-être mais le PDF 417 me semble être une sorte d’encodage 2D « du pauvre », un peu à l’image de ce qu’est la perspective cavalière comparée à la perspective réaliste… C’est du moins ce que je comprends de :
Alors tu me diras, qu’est-ce qu’un carré sinon un empilement de lignes ? Je note aussi, qu’en plus de la tolérance aux erreurs que tu cites, PDF 417 a aussi l’avantage d’être lisible par un lecteur classique de code-barres, sans recours à un dispositif tel qu’un APN ou scanner. J’ignore cependant si ça présente encore un véritable avantage pour certains usages de nos jours.
[^] # Re: suggestion d'améliration
Posté par Marotte ⛧ . En réponse au journal QRNote pour copier coller du texte de son ordinateur au téléphone. Évalué à 4.
Le fait que ton message soit moinssé m’a interpelé. Tu es sûr de toi sur cette histoire de limite ?
D’après ce que je lis ici c’est bien le QR code qui semble le plus adapté.
Si en plus, sur un smartphone, la lecture du QR code est native mais pas celle du PDF 417, alors il y a vraiment très peu d’intérêt, pour ne pas dire aucun, à supporter ce format pour cette apllication.
D’après ce que je comprends le PDF 417 n’est pas « en 2D », il est semblable aux différents codes-barres classiques, mais on empile les lignes, c’est peut-être ainsi qu’on peut éventuellement coder plus d’information ? On peut empiler un nombre illimité de lignes ?
[^] # Re: tapeu tapeu tap
Posté par Marotte ⛧ . En réponse au journal QRNote pour copier coller du texte de son ordinateur au téléphone. Évalué à 3. Dernière modification le 29 octobre 2023 à 06:50.
Compiler pour Android je ne sais malheureusement pas faire et pas la motivation d’apprendre.
Sans oublier le fait qu’on a déjà vu des projets libres avec une backdoor, j’ai en tête deux exemples : irssi un client IRC dont les auteurs voulaient monter que personne ne lisait jamais le code source (la backdoor était dans le fichier de configuration du build), je ne sais plus combien de temps ça a pris pour que quelqu’un s’en rende compte mais il y a eu des discussions assez énervées suite à cette découverte. Et Tor, dont un des contributeur fût un membre du FBI qui a sciemment introduit un code exploitable pour chopper je ne sais plus quel criminel qui utilisait Tor. La faille a été comblé assez vite, avant que le FBI ne l’exploite pour le chopper, ils ont eu bien de la chance que le malfaisant n’avait pas pris le soin de mettre à jour son Tor Bundle… à méditer !
J’aurais du mal à dire entre Google Store et F-Droid lequel présente le plus de risques (risque au sens large). Peut-être que F-Droid a une procédure béton pour éviter de distribuer du malware ? J’ai installé plusieurs apps depuis F-Droid.(j’y connais rien à Android). Mais effectivement pour l’app du clavier dont je parle je n’ai pas eu le réflexe de regarder (c’est p-e tout simplement pour ça que je la retrouvais pas ^^)
[^] # Re: Mode HID non plus
Posté par Marotte ⛧ . En réponse au journal QRNote pour copier coller du texte de son ordinateur au téléphone. Évalué à 4.
C’est bien utile dans certains cas que l’on puisse utiliser un clavier physique avec Android. Mais le but d’une terminal mobile c’est de l’avoir avec soi quand on se déplace et pouvoir l’utiliser rapidement. Sinon autant avoir un desktop voire un transportable/portable, non ?
Vous travaillez à un poste fixe avec une tablette ou un smartphone ou bien vous vous déplacer avec un clavier physique ?
J’ai du mal à voir l’usage concret. Pour du développement destiné à Android peut-être ?
# tapeu tapeu tap
Posté par Marotte ⛧ . En réponse au journal QRNote pour copier coller du texte de son ordinateur au téléphone. Évalué à 5.
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.
[^] # Re: Obsolescence programmée
Posté par Marotte ⛧ . En réponse au journal CPU Ex0215 Café bricole. Évalué à 2. Dernière modification le 26 octobre 2023 à 00:30.
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é.
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é » ?
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_
[^] # Re: Obsolescence programmée
Posté par Marotte ⛧ . En réponse au journal CPU Ex0215 Café bricole. Évalué à 0. Dernière modification le 25 octobre 2023 à 19:56.
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.
[^] # Re: Obsolescence programmée
Posté par Marotte ⛧ . En réponse au journal CPU Ex0215 Café bricole. Évalué à 3.
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 ?
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.
[^] # Re: Obsolescence programmée
Posté par Marotte ⛧ . En réponse au journal CPU Ex0215 Café bricole. Évalué à 3.
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 ! ;)
# Obsolescence programmée
Posté par Marotte ⛧ . En réponse au journal CPU Ex0215 Café bricole. Évalué à 1.
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 !
[^] # Re: Shell
Posté par Marotte ⛧ . En réponse au journal La plus belle ligne de code. Évalué à 4.
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à.
[^] # Re: Shell
Posté par Marotte ⛧ . En réponse au journal La plus belle ligne de code. Évalué à 4.
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.
[^] # Re: Shell
Posté par Marotte ⛧ . En réponse au journal La plus belle ligne de code. Évalué à 5.
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 ^^
[^] # Re: continue
Posté par Marotte ⛧ . En réponse au journal La plus belle ligne de code. Évalué à 3.
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 :)
[^] # Re: Shell
Posté par Marotte ⛧ . En réponse au journal La plus belle ligne de code. Évalué à 4.
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’unif(et desthenetfisans 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 … fiQu’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
Posté par Marotte ⛧ . En réponse au journal La plus belle ligne de code. Évalué à 8.
continueest bien pratique aussi, pour passer à l’itération suivante en zappant le fin de la boucle pour l’itération en cours.[^] # Re: Remarques
Posté par Marotte ⛧ . En réponse au message Wrapper for ALSA recording of playback device. Évalué à 3.
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).