Marotte ⛧ a écrit 8714 commentaires

je vois trop de gens pensaer que eu, élèvent six moins

Typiquement, le bug ci-dessus ne peut pas être imputé à Ubuntu/Debian. C’est l’amertume provoqué par l’acceptation du constat tellement implacable de la relative faible pénétration de Linux sur le desktop qui m’a fait, un instant, douter de l’utilité de terminer mon poste.

Utilisez Linux où je risque de faire une connerie (une au minimum), vous aurez je ne sais pas quoi, mais un truc bien traumatisant sur la conscience, si vous continuez d’utiliser Windows après l’expérience que vous venez de vivre !

quand on voit qu'une biblio municipale d'uen très grande ville en france, a son banc de pc publics accessibles à tous, qui tourne depuis des années sous debian…

Sans parler des gendarmeries de notre si belle contrée qui utilisent Ubuntu depuis quelques années maintenant. Des collèges, des lycées

Ce qui m’attriste c’est que je vois trop de gens pensaer que eu, élèvent six moins
:

Red Hat (ou ses dérivés gratuites)

Une précision extrêmement importante à apporter quand on parle de « dérivées gratuites de RedHat » (plus précisément, RHEL : RedHat Entreprise Linux), qui s’avère d’autant plus nécessaire suite à cette décision proprement dégueulasse de RedHat de profiter du capital de notoriété de la distribution CentOS, acquise au fil des années, et en se reposant clairement sur la confusion que leur décision engendrerait inévitablement. Je vais essayer de faire le plus clair possible pour que tout le monde puisse comprendre de quoi on parle. On va évoquer trois distributions : CentOS, ALMA Linux et Rocky Linux

CentOS existe depuis très longtemps, probablement depuis autant de temps que RHEL. Ce n’est pas une distribution « dérivée » de RHEL, c’était (jusqu’à la version 7) une distribution dite « downstream » de RHEL. Pour faire simple, RHEL repose sur du logiciel libre, cependant, c’est bien uniquement le code qui est libre. Leur logo, le nom même de RedHat, ainsi que tout ce qui ne repose pas directement sur le code (par exemple une documentation additionnelle) tout ça n’est pas libre. C’est ça, il ya maintenant de nombreuses années qui a poussé certaines personnes à créer « CentOS », une distribution dite « binairement compatible » avec RHEL. Soit une RHEL « dé-brandé » comme ont dit en français (le logiciel c’est le même mais on vire tout logo, charte graphique, composants non libre, etc…

Pendant des décennies ça a bien arrangé RedHat : les clients testaient la faisabilité de leur projet avec CentOS, une fois le truc validé ils venaient voir RedHat : « bon on va vous prendre le support parce que le truc on va le faire tourner en prod’ Donc une RHEL, pas le choix.

Puis, et là il me semble important de préciser que je m’écarte de pur factuel pour vous faire part de mon ressenti, de l’explication que j’ai de cette manœuvre de RedHat :

À un moment donné RH s’est rendu compte qu’un certains nombre d’entités (déjà client ou client potentiel) montaient leur truc sur du CentOS, mais qu’une fois le truc validé, il y avait un financier pour suggérer que le risque de ne pas avoir de support était sensiblement inférieur au risque de migrer le truc. Que ça marchait plutôt bien. Et là ! L’idée, mais alors L’IDÉE!! de RH, on va transformer CentOS en une sorte de « preview » de notre next version ! }

Cela aura donc aboutit à la création de (au moins) quelques distribs reprenant ce principe, notamment par les créateurs eux-mêmes de CentOS : Rocky Linux, et ALMA Linux

Qui ne sont donc pas des dérivées de RHEL, mais, et c’est clair que c’est pas compréhensible de manière évidente… J’espère avoir participé à une meilleure compréhension avec ce message.

Je répondrai sûrement quand aux autres distributions mais le cas RHEL/CentOS est tellement stupéfiant que c’est dur de vivre, même d’aller se pieuter, sans y aller de sa bavance, de son questionnement … oparationnel

Grosso modo je suis d’accord avec toi. Je mettrai tout de même quelques bémols.

Bien entendu qu’une distrib’ que tu connais c’est mieux, mais le but c’est quand même que la personne devienne autonome le plus rapidement possible.

Debian reste Debian

Autant que « Le ski alpin reste le ski alpin »… Toutes les distributions permettent d’utiliser tous les bureaux (au moins les principaux) et Debian comme les autres a un bureau par défaut qui est automatiquement choisi si tu fais l’installation en mode simple, c’est Gnome (?).

sauf pour les puristes (qui a dit integriste), y a longtemps qu'il n'y en a plus vraiment besoin.

c’est effectivement très rare qu’il y en ait besoin absolument pour une utilisation basique d’un PC sous GNU/Linux. Mais ça reste très utile pour un tas de chose, et je ne trouve pas judicieux de vouloir absolument éviter à l’utilisateur d’y être confronté.

c'est une "utilisatrice", une fois isntallé y a pas de raison qu'elle aille modifier des truc à droite à gauche.

Alors là, le rapport avec l’outil informatique, les besoins et les capacités de l’utilisatrice « lambda », ça recouvre quand même un spectre assez large.

Je ne pourrai pas assurer de support technique après l'installation, il faudrait donc qu'elle puisse se débrouiller par elle-même par la suite.

Moi-même utilisateur de Debian, les personnes à qui j’ai installé une distribution c’était Ubuntu, car :

• si je dois faire un peu de support, comme elle basée sur Debian ce sera pas plus dur que si c’était Debian

• elle est quand même un poil plus adaptée au débutant, sur plein de petites choses, par exemple, je ne sais pas si c’est toujours le cas mais avec une installation par défaut de Debian, le dépôt "non-free" n’est pas configuré, et de base je ne crois pas qu’une interface graphique qui permette de la faire soit installée. Ubuntu est sciemment orienté vers le débutant (ce qui pour autant ne la réserve pas qu’aux débutant). Le seul inconvénient, par rapport à la demande initiale ce serait p-e une légère incitation à consommer un peu de proprio. Mais pour autant la facilité qu’a un utilisateur sans compétence particulière pour chercher et installer un logiciel en autonomie est plus intuitive que sous Debian (même si tu lui a activé le non-free et installé le gestionnaire de packages), qui reste un poil moins orienté « débutant complet ».

À mon avis, l’idéal (qui est presque indispensable pour Debian, un peu pour Ubuntu) c’est de pouvoir prendre le temps de faire l’installation en montrant à l’utilisateur. Il ne faut surtout pas le noyer d’info mais ça permet de démystifier et de collecter quelques besoins. Selon moi c’est mieux que lui préparer la machine et lui livrer en lui disant : tu vas voir ça marche tout seule c’est ultra-intuitif.

Je l’ai fait pour un ami, en lui expliquant le principe des distributions, avec des explications que j’ai pris soin de faire le moins technique sachant que l’utilisateur en question, tout en étant loin d’être con, ne brille pas par ses capacités intellectuelle et a un intérêt limité pour tout de qu’il peut juger » compliqué et inutile pour lui.

L’ayant revu quelques semaines après lui avoir installé Ubuntu et l’ayant laissé dans un état d’esprit du genre : « Ouai on va voir, ça a pas l’air très simple mais je t’appellerais au pire si j’ai un souci ». Je lui ai dit que bien sûr il pouvait m’appeler. Donc, quand je l’ai revu quelques semaine après, non seulement il ne m’avait pas appelé un seule fois mais il avait remplacé la Ubuntu par une Mint qu’il avait installé tout seul, et ma expliqué que « Linux ça marchait trop bien pour la crypto, il était super content que je lui ai fait découvrir « Linux ». Je dois dire que j’étais agréablement surpris. Encore plus que les deux autres personnes à qui j’avais fait découvrir ce système en ayant une petite crainte d’être sollicité tous les trois jours.

Bref, tout ça pour dire que, à l’évidence il faut passer un peu de temps au début pour montrer les bases et répondre aux premières questions qui viennent quand ils sont mis devant cette nouvelle interface, mais l’idéal c’est de prendre en plus au préalable le temps de faire .

Pour finir, sur Debian, je trouve que le mode d’installation "expert" est absolument mal nommé. Il ne demande strictement pas plus d’expertise que le mode "simple" par défaut à partir du moment où tu as réussi à faire comprendre au débutant que s’il ne comprend pas une question ou ne se sait pas quoi répondre il ’a juste que laissé le choix par défaut (qui ait toujours le choix qui aurait été fait avec le mode simple, qui ne t’aurait juste pas posé la question).

doit tenir dans 4KBytes. Idem pour les demos 64KB

Ah oui, avec ce genre de contrainte en effet, peu importe la puissance du matériel dans ce cas. Ça me fait penser au Code golf dans le même genre, sauf que là c’est la taille du code source qu’il s’agit de minimiser.

Je suis absolument admiratif des personnes capables de ce genre d’exploit.

En tous cas merci pour vos réponses j’ai une idée plus clair de ce qu’est la demo scene et content de constater qu’elle existe toujours bel et bien.

Donc on ne peut pas dire par exemple que certains logiciel de « visualization » de musique qui affichent des espèces de formes psychédélique (ou pas) qui suivent la musique peuvent être issus de la scene demo ?

C’est donc un domaine plutôt distinct, qui n’a pas trop de rapport avec le VJing ? Malgré que des demos puissent être drivées par de la musique. L’aspect optimisation du code étant central dans le délire.

C’est vrai qu’aujourd’hui, sur du matos moderne, qu’est-ce que tu pourrais afficher qui témoignerait d’une optimisation astucieuse des capacités du matériel… ^^

Tu donnerais quelle définition de "scene demo", de la scene demo actuelle si le terme a pris un cens différent ?

J’en ai une certaine idée depuis longtemps et je n’ai pas encore souhaiter demander à Google. Et comme tu emplois le terme j’espère avoir les moyens de te faire parler.

J’ai écrit un seul script « pour de vrai » en Perl et ce n’était pas pour une autre raison (ie: ce choix de Perl plutôt que Bash ou Python) que m’initier à ce langage dont je sais à sa réputation que c’est un langage qui compte. Je ne savais pas que Perl ne faisait « aucun fork » (sauf j’imagine dans le cas où tu veux avoir du parallélisme, et comme tu l’indiques, pour appeler un autre programme évidemment), je note cet aspect.

tu n'es pas sûr que [ soit un builtin, ça peut très bien utiliser /usr/bin/[.

D’où la recommandation d’utiliser systématiquement [[. Ou c’est pour une autre raison ? je ne sais plus, peut-être pour une autre raison mais sauf erreur c’est recommandé d’utiliser [[ systématiquement.
Par ailleurs en Bash (je ne sais pas pour ksh et zsh mais il y des chance qu’il en soit de même) tu peux t’assurer que [ et test appellent bien les built-in avec la commande enable.

Vraiment si le coût du fork t'es insupportable, rend-toi service, apprend perl.

Comme je te disais je m’y suis initié, je connais les grands principes et si je dois faire du Perl ça ne me pose aucun problème, c’est un beau langage. C’est pas comme si je me retrouvais obligé de faire du PowerShell par exemple (et ça m’est arrivé, je ne dis pas ça gratuitement selon un bête préjugé). Maintenant, je préfère le paradigme "tout fichier" de Bash à la manipulation de pointeurs et je ne peux de toute manière pas explorer à fond les deux langages (surtout qu’il me faut du temps pour explorer le Chuck, qui est encore d’un type bien différent, et que j’ai très peu de chance de mettre en œuvre dans un contexte devops ^^ (mais qui sait…)).

Sans être insupportable, si on peut faire en Bash un traitement en 1 seconde (et que c’est un temps acceptable dans le contexte) au lieu de 10 (et qui serait un temps tout aussi acceptable dans le même contexte) en évitant des forks inutiles, le fait qu’on puisse faire ce traitement en 0,1 s en Perl, et que même à 10 secondes tout le monde est content, ce n’est pas une raison ni pour passer à Perl ni pour se foutre que son script Bash en prenne 10. Et j’ai bien conscience du caractère légèrement maniaque de cette philosophie. Tout comme des problèmes que peut poser un souci d’optimisation précoce.

Pour tout te dire, je suis en train de développer un programme, en Bash, sans cahier des charges très précis (c’est pas pour le boulot, c’est expérimental et a clairement le caractère d’un loisir) dont je sais, sans pratiquement aucun doute, que si j’arrive à un truc qui ressemble à l’idée flou que j’ai en tête, je devrais me heurter aux limitations de la vitesse d’exécution de Bash (pas réputé comme le plus rapide parmi les shells par ailleurs). Je verrai bien ce que ça donne mais je me dis que si à ce moment là je veux dépasser cette limitation, ce sera une excellente occasion de refaire du C, ou m’initier à un autre langage compilé (Rust par exemple, mais je pense que je partirai plus sur du C). Parce que si j’ai un programme en Bash qui fonctionne, j’aurais tout de même un prototype pour savoir où je veux aller avec mon programme en C. Et quitte à devoir manipuler des pointeurs… :)

Tout à fait. Ici en l’occurrence « laissons-nous aller » est aussi une invitation, mais qui n’a pas le même sens que “Let’s go”, vraiment pas. La traduction la plus évidente, et certainement la plus courante, de loin, c’est « Allons-y », voire ensuite, un peu moins courante : “Allons-nous en”. Qui du coup, traduit mot-à-mot dans l’autre sens donnerait (?) “Go there”, ou “Go we in” (ou “Go we at”, etc… on a le choix ici si on fait du mot à mot), là encore : valide grammaticalement avec un tout autre sens, ou n’importe quoi.

Et merci pour la correction sur le fait que le ’s est ici le s de “us”.

C’est pour ça que :

« À travers la traduction mot-à-mot, on accède à une meilleure compréhension du texte source »

Même pas au conditionnel ! On lit rarement une affirmation aussi fausse sur ce site. Et pourtant je commente beaucoup.

Rassurez-moi, je suis encore passé à côté du caractère deuxième degré d’un commentaire c’est ça ?

Je sais plus.

Je sais pas si ça vous fait la même chose

Je sais pas non plus.

J’éprouve déjà des difficultés à me souvenir de ce que je fais.

Ah ouf ! Là je viens de me rappeler que j’écrivais un message pertinent !

Probable que pour les passionnés de ce site, ce qui est le plus important, plus important que Doom (aussi incroyable que cela puisse paraître), c’est que TapTempo tourne avec un framerate correct sur la tondeuse.

Je savais bien qu’il était impossible que les chiffres soient aléatoire ! ^^. Merci pour cette explication, dont les exactitudes potentielles me semblent incontestables

C’est bien le genre de méthode d’évaluation approximative de l’entropie qui devrait être la référence incontournale l’objet d’une section et quelque dans la définition de la norme pifométrique. La définition de granularité pas mal, voire la définition avec des grumeaux.

Un point important des 2 méthodes, c'est que les choix doivent tous être des choix au hasard (donc pas l'utilisateur qui sort de sa tête un mot). Sinon, l'entropie diminue fortement.

On peut sortir de sa tête un mot au pseudo-hasard. Cependant, en effet, comme tu le dis pas trop vaguement, on doit alors se questionner sur l’entropie de son subconscient et mener une auto-analyse orientée vers son expérience de l’école primaire.

Pour être un peu moins sérieux, MFA oui, mais ce n’est pas toujours disponible, le mot-de-passe reste un fondamental. D’ailleurs je ne connais pas de système MFA dont l’un des facteurs n’es pas un mot de passe. Ça reste fondamentale. Mais ta remarque est je vais le faire inclure dès le débu du CM1.

Comme si ça pouvait mettre en échec un gars ou une garce assez maligne et motivée à usurper de l’identité…

b/ vérification de ton numéro par sms, qu'elle va renseigner dans le profil nouvellement créée (ya plusieurs sms de validation à confirmer pendant la procédure, dont un à garder précieusement, comme "clé de mdp perdu")

Et parfois noté au stylo à bille sur un cahier à spirale pour le saisir plus tard dans le logiciel parce que là ça bueugue ! ^^

À travers la traduction mot-à-mot, on accède à une meilleure compréhension du texte source

Alors celle-là elle me laisse sur le cul. Avec une traduction littérale on peut déjà faire des contresens mais « mot-à-mot »…

Tu traduis comment (de l’anglais) : Let’s go ? Laissons aller ?

Cette fois le temps était à l’orage → This time the time was at the thunderstorm ?

Et mes exemples sont vraiment pourris. On peut trouver bien pire. (And my examples are really rotten. We* can find good worst) …

* à moins que ce soit "it" ? S’il y avait une bijection entre les vocabulaires de deux langues ça se saurait. C’est absolument pas le cas

C’est sûrement assez courant mais je ne crois pas avoir déjà vu le cas.

Je vois les avantages à avoir le projet hébergé à la fois sur Github et sur Gitlab (merci Git !) mais j’ai du mal à voir comment tu organises ça en pratique ? Par exemple pour gérer les issues qui sont manifestement possible des deux côtés (et sans même une recommendation dans le README), etc…

Il y a un service de synchro proposé par l’une ou l’autre des plateforme ? Non mais tu as déjà un peu réfléchi au problème ? Je me pose trop de questions ?

délire emplit d’un cynisme acerbe

Ce qui n’étonnera pas ceux qui me lisent depuis longtemps ^^

Ta lettre est très bien.

Sincère, bien écrite, probablement peu courante, et je suis pas spécialiste RH mais je ne serai pas étonné que des responsables de services informatiques, ou de formations, ou autres, recherchent justement un profil comme le tiens, sinon pour changer radicalement l’entreprise pour laquelle ils travaillent, pour apporter un équilibre dans leur « ressource humaine », et ne pas avoir que des clones dociles qui n’ont pas besoin de chausse-pied pour rentrer dans n’importe quel moule…

En lisant l’introduction je m’attendais à un délire emplit d’un cynisme acerbe alors que c’est une lettre parfaitement adaptée comme lettre de motivation.

J’avais espoir que ce + ne soit que marcanto-cosmétique, zut :(

Quand je parle d’illectronisme de la France sans les GAFAM j’exagère. Mais j’ai du mal à dire à quel point j’exagère…

Les universitaires français ont fait beaucoup pour le développement d’Internet, et font encore pas mal, on a aussi des entreprises dans quelques secteurs clés lié à l’internet mais c’est surtout dans des secteurs qu’on peut qualifier de « destiné au grand public », mais pas dans le sens où on l’entends habituellement. Le grand public est concerné mais pas vraiment en tant qu’utilisateurs…

YouTube était une startup française à la base, aujourd’hui c’est devenu pour 99,999% des citoyens français ce qui constitue une très partie de ce qu’est concrètement le Web (même Internet on peut dire, il y a bien qu’ici qu’on fait la différence). Et c’est pas un jugement de valeur, enfin si, mais comme j’en fait partie des vendus aux GAFAM, c’est un jugement qui est absolument dénué du moindre mépris, donc ça va.

Mais tout de même. Hier j’ai fait un achat sur CDiscount, j’ai senti vibrer ma fibre patriotique. Je recours aux services de OVH et SFR. Oui, malgré tout je résiste à l’impérialisme digital des maîtres du monde, vous pouvez tous le faire ! \o/

Il faut que j’encourage tous mes contact à ne pas perdre espoir et résister, à mes amis sur Facebook et sur Twitter. Je m’y mets dès que j’ai pu m’occuper de ma boîte Gmail et de mes notif’ Github. ^^

activer FrnceConnect+ via un employé, j'ai tenté dans un bureau, le déni total, un mur d'incompréhension

Ça me rappelle quand la Banque Postale a mis en place la 2FA, elle a prévenu avant, via l’espace oueb que j’utilisais pour consulter mes comptes et faire mes opérations courante. Il y avait au moins de mois que le message était présent, et ça devait devenir obligatoire quelques mois plus tard. Et, un peu pareil que pour le sujet de ce journal, la manière dont c’était tourné laisse clairement supposer que sans smartphone on pouvait rien faire (aucune info pour faire sans indiquée). Je n’avais pas de smartphone à l’époque et aucune envie d’en acquérir un, surtout forcé et contraire, qui plus est par une banque.

À l’occasion d’une visite dans leur locaux (dépôt de chèque ou dépôt/retrait de colis je ne sais plus), j’ai fait la queue pour demander au guichet : pas au courant, mais très avenant⋅e, patienter un peu là bas je vais faire venir un conseiller, je patiente, un temps assez court pour cette institution, une dizaine de minute, le conseil arrive, me fait m’installer dans son « bureau » (une espèce de guichet++ quoi, avec une chaise, je lui réexplique mon inquiétude, « Ah bon ?! Non je ne suis pas au courant de ça », pour me rassurer il me dit que lui-même serait vraiment surpris qu’on ne puisse plus accéder à ses comptes sur Internet si on n’a pas de smartphone. Mais bon, j’ai eu envie de lui dire : « D’accord mec mais t’es même pas courant du truc alors ton avis je ne sais pas trop quel crédit je peux lui apporter, vous êtes vraiment des branques ici, c’est un peu l’hallu ! » Mais comme il me faisait plutôt pitié qu’autre chose, et que je n’avais pas que ça à foutre de tenter de faire sortir son N+1, voir encore au-dessus, de son bureau, et qu’en plus il y avait encore moins de raison qu’il soit au courant voire comprenne même pas de quoi je parle. Je suis retourné vaquer à mes occupations.

Je n’ai jamais su le fin mot de l’histoire car comme ça faisait déjà un moment que je me disais que je devrais me barrer de cette banque de merde dont je n’étais pas tout à fait satisfait, pour plusieurs raison, j’ai pu dépasser mon immobilisme pathologique et faire le nécessaire pour changer de crémerie. C’était il y a environ cinq ans, p-e même plus. Et pour la première fois de ma vie je suis dans une banque dans laquelle je n’ai eu que deux problèmes absolument mineurs, et qui me coûte une bonne vingtaine de fois moins cher que toutes les banques que j’ai connu auparavant, et encore, c’est parce que j’ai tendance à être pas mal à découvert (bien plus que dans les banques précédente), sinon elle me coûterait strictement rien…

Quand on voit que chez certaines banques historiques ils t’inventent le concept absolument énorme de « frais de tenue de compte »… (si vous ne voyez pas l’énormité du libellé vous devriez réfléchir au concept originel d’une banque, à leur « business-model » premier…). Il doivent bien se marrer les banquiers quand ils se font une bouffe à l’hôtel des Trois Faisans en racontant ce qu’ils mettent aux clients à leur potes notaires !

C’est plus le fork lié au pipe lié à l’utilisation de cat dans ce cas.

une très précieuse milliseconde à se lancer

« Se lancer » regroupe plusieurs étapes mais je ne vais pas détaillr. Un fork est un fork et c’est ça qu’il est important de limiter, car il a un coût, c’est peut-être même inférieur à la milliseconde mais ça ne change strictement rien à ce que je dis : 500µs * 10000000 = 50s

tu peux passer -l comme argument à grep pour éviter de lire tout le fichier s’il trouve ta correspondance à la deuxième ligne.

C’est une très bonne remarque, mais d’une : le « plus d’économie » il dépend de la taille du fichier, vu qu’on ne l’affiche pas, s’il fait 4k et qu’il est en RAM la différence avec le fork nécessaire est pas si évidente que ça. Par ailleurs comme très justement signalé plus bas, le fait d’utiliser -q (sans le -c) fait que le fichier ne sera lu que jusqu’à la première occurrence, le -l est superflu. Utiliser le -q sans le -c n’est donc pas seulement avantageux en terme de lisibilité du code comme je l’affirmait à tort.

en conditions réelles.

Une fois de plus, si les conditions réelles sont de traiter 10 fichiers de 1M lignes et de faire ça 48 fois par jour, ça fait une différence significative.

Je finis sur deux points car je sais qu’on peut/va me les opposer :

1) Si le traitement doit être lancé aussi souvent sur de tels volumes alors on gagnera davantage à écrire le traitement dans un langage compilé. Sur cette remarque qui paraît à beaucoup relever du bon sens même, j’ai deux choses à faire remarquer :

• Le développement, le déploiement et la maintenance d’un langage compilé a une complexité supérieure dans bien des cas et demande une charge de travail plus importante et des compétences différentes, compétences qui sont à ma connaissance plus rares en terme de ressource humaine, plus coûteuses, et potentiellement utilisables (et utilisées) sur des travaux qui ont souvent une plus forte valeur ajoutée pour l’entreprise.
  
• Si c’est pour pondre un code C aussi mal optimisé que le script Bash qu’il remplace, le gain peut même être inférieur à celui qu’une bonne optimisation du Bash existant (si c’est par exemple l’algorithme qu’on aurait pu optimiser, où l’ajout d’un cache, etc…)

Tout ça pour dire que passer d’un langage de script très connu à un langage compilé pour uniquement résoudre un problème de performance qu’on peut résoudre simplement en corrigeant l’écriture imparfaite d’une script shell existant (ie: en l’optimisant) je doute que ce soit pertinent très souvent, et clairement pas une évidence.

2) Tout ce que je dis sur les UUOC et autres constructions non optimales dans un script Bash c’est évidemment préférable de les éviter dès le départ. Mais, premièrement on ne les évitera pas toute, donc une phase d’optimisation final une fois l’aspect fonctionnel du script terminé est toujours la bienvenue. De ce fait, une trop grande attention portée à l’optimisation et temps passé sur le sujet dans les phases initiales du développement est contre-productive. Et ça ça ne concerne pas que les langages interprétés.

Tout en évitant de partir sur une architecture logiciel qui arrivera immanquablement à un programme trop lent car inadaptée. Il faut mieux un programme qui répond au cahier des charges sur les fonctionnalités malgré qu’il soit trop lent, et ainsi pouvoir se concentrer sur son optimisation en ayant une vue d’ensemble. Que d’étudier dans le détail la meilleure manière d’écrire telle fonction bas-niveau alors qu’on a fait genre à peine 20% des fonctions de plus haut niveau… C’est un travers assez courant chez tout développeur (sauf ce pour qui l’optimisation n’est même pas une pré-occupation à un seul instant, évidemment ^^), moi le premier, mais dont il s’agit de chercher à réduire l’importance.

J’ai oublié la conclusion importante :

Malgré le seul défaut hautement capillotracté que j’ai cité, je vais très probablement user de yb si mes tests sont concluant que et que j’ai un truc non trivial à faire sur du JSON plutôt, que me faire chier avec jq et sa syntaxe merdique trop exigeante. C’est très probablement un excellent outil que j’espère packagé d’office un jour dans toutes les bonnes distrib’ !

OK merci. Donc question syntaxe c’est kifkif, la différence de yq par rapport à jq c’est le support de plus de format que seulement le YAML, mais moins de fonctionnalités (qui sont prévues si je me fie au README), et le langage dans lequel il est implémenté (Go vs. C pour jq).

Tout ça pour dire que yb m’intéresse fortement. Le seul inconvénient (pas négligeable d’après-moi), en rapport avec la discussion que nous avions sur Bash, c’est que yb n’est forcément packagé forcément par les ditributions (il l’est pas sur Bookworm en tous cas). Est-ce que le fait qu’il soit natif (ie: en Bash) ne résout pas forcément tout les problèmes de « de simplification de l’environnementdontt til a besoin ».

• si on le copie dans son propre projet il faut suivre ses mises à jour. Ce qui est plutôt simple avec les sous modules git, ça déporte toujours la gestion de l’environnement pour son propre au projet lui-même au lieu de se reposer sur les distributions qui font tourner son projet, et qui gèrent toutes les mises à jour de jq.

• pour l’installation, si Ansible (ou autre outil de ce type) peut aussi bien gérer l’installation d’un RPM/DEB que le déploiement d’un script ça nécessite quand même toujours de considérer le premier point.

<block type=spam category=biography interest=0.0032 >
Clairement, je chipote grave et c’est peut-être moi qui ne travaille pas de la bonne manière (surtout que je dois parfois me résoudre à travailler de manières que je sais plus nulles que les miennes). Je ne suis pas chef et j’ai un certain nombre de collègue, ingénieurs comme moi (et pas des anciens à un ou deux ans de la retraite…), ingénieurs d’exploitation, des opérationnels donc, qui assument sans réserve, de ne pas savoir utiliser git/Github et de tenir à une gestion des opérations basée sur des documents Word, comme ils font depuis des dizaines d’année. Ils n’ont pas le temps de se former à git/Github vu leur charge de travail quotidien. Ajoutant qu’il faut également du temps pour étudier que la pertinence de passer de leur mode de gestion actuel à git/Github est vraiment réelle. Quand tu as un management qui a pas la volonté et la capacité à imposer ce genre de changement. Et bien… tu fais du devops/gitops surtout sur le papier et ça reste à l’état de projet. Mois qui suis fataliste et assez versatile (je ne fais rien vraiment bien mais rien non plus vraiment mal ) je me fais une raison. Mais quand je vois un collègue qui lui s’impose à lui même, et pousse pour, une gestion devops/gitops à la pointe de la discipline (ce qu’on ne peut pas lui reprocher, à moins d’un manque flagrant de pragmatisme sur un point, ce qui est très rare), je suis sûr que ça participe pas à sa satisfaction dans son travail.
</block>

yb offre une API beaucoup plus simple et intuitive que d'autres solutions de parsing YAML

Tu fais référence à jq ? Je le trouve assez imbitable. perso.

Vous avez p-e raison mais comment ça se passe si on perd son appareil ?

Mais de toute façon quelque chose m’échappe, j’utilisais FranceConnect avant d’avoir un smartphone, et depuis que j’ai un smartphone je ne m’en suis jamais servi sur celui-ci. (le FC+ serait différent et plus relou que le FC tout court ?)

Je ne sais plus exactement comment j’avais fait mais c’était sur un PC sous Linux et c’était pour les impôts et la sécu.

Bref, je vois qu’au pire on peut envoyer une bonne vieille lettre comme aux temps zancien-pré-digitaux, faut prévoir un bon mois (annoncé, donc deux à vue de nez) et c’est moins sécurisé, comme avant quoi… Faudrait pas faire comme si on découvrait seulement en 2024 que la France serait dans l’illectronisme presque total sans Google et Apple (et quelques autres). On peut le regretter certes mais bon…

Et https://www.france-services.gouv.fr/, ce serait pas une solution ?