Marotte ⛧ a écrit 8705 commentaires

il y a une petite hype pour réécrire tout en Rust.

Je ne suis pas bien au fait de l’état de la hype chez les développeurs systèmes mais il me paraît plus vraisemblable qu’il s’agissent d’utiliser Rust pour les nouveaux développements, mais sûrement pas de « tout réécrire » en Rust. Que ce soit pour Linux ou pour d’autres logiciels écrits actuellement en C.

Ce que je vais dire est à prendre avec des pincettes et tous les dispositifs de protection intellectuelle nécessaires, parce qu’encore une fois, mon expérience en la matière est insignifiante, mais c’est comme ça que je vois les choses, ce que je peux en dire en ma qualité de méta-expert de renommée inter-régionale.

Rust, de par sa conception plus récente que C (et pas qu’un peu !), présente sans aucun doute des caractéristiques avantageuses par rapport au C, qui traîne une « dette » (notez qu’on dit "legacy" si on veut rester hype) faramineuse, inévitable à son âge vénérable. Mais ce dernier reste une référence absolue pour les langages de « haut-niveau » compilés. C++ n’a rien à voir (aucun jugement de valeur mais l’approche est pour ainsi dire à l’opposé du C), et si Rust semble pouvoir éventuellement se revendiquer digne successeur de C, c’est assez récent. Ce n’est ni Java/Scala, ni Go, ni à ma connaissance aucun autre langage qui peut se targuer d’être au même niveau de justesse en terme d’équilibre entre « langage de haut-niveau », et « langage au plus proche du matériel et sans fioriture telle qu’un ramasse-miette, orientation object ou autre paradigme d’une complexité excessive ». Nonobstant les avantages que chacun d’entre eux peut posséder par ailleurs. C, un langage qui fait peu (tout ce qu’il faut mais pas plus), et qui le fait bien. Un langage exigeant qui ne fait aucun concession sur la performance pour disposer de fonctionnalités destinées à éviter au développeur de se fourvoyer.

Je pense que l’article ci-dessous, datant d’il y a trois mois, bien qu’assurément entaché d’inexactitudes qu’il m’est malheureusement impossible de préciser, dresse un état des lieux relativement représentatif. État des lieux que je résumerai de façon tout aussi relativement inexacte : « Rust dans Linux, on peut dire que ça a dépassé le statut d’idée à discuter, mais pas encore atteint celui d’une évidence indiscutable. »

https://www.zdnet.com/article/rust-in-linux-where-we-are-and-where-were-going-next/

L'entropie est de 44 bits si l'attaquant sait que cette méthode est utilisée, qu'il connaît la liste de mots initiale et le nombre de mots choisis.

Tu as sûrement raison, j’avoue ne pas comprendre d’où viennent les chiffres de 2²⁸ (dans le premier cas) et 2⁴⁴ (dans le second). En tous cas une chose est sûre, me semble-t-il, c’est que dans les deux cas l’entropie est plus faible qu’un mot de passe de la même longueur utilisant le même ensemble de caractères et qui serait vraiment aléatoire. Si on prend par exemple erotic flower stapled ouragan, qu’on fait l’hypothèse que sont utilisé 26 lettres minuscules + espace, qu’il y a comme ici 29 caractères, disons entre 20 et 40, si on sait qu’il s’agit de trois, quatre ou cinq mots de la langue anglaise séparés par des espaces, en terme d’entropie on est bien de deçà de ce qu’on peut atteindre avec les seuls éléments "longueur" et "nombre de figures" si on ne se fixe pas une règle de ce genre, on peut éventuellement avoir un 'xmafhxdgv hcpmmbc f fgsiegnxqw'. Idem pour le premier exemple si on s’abstient de partir d’un mot existant: c0qui!!4g3 vs. vv59yd!c4j. Mais bien sûr c’est là le point du XKCD, on est dans le compromis entre "entropie" et "mémorisabilité".

On devrait peut-être enseigner les méthodes de choix d’un mot de passe vers le CE2-CM1. C’est sûrement aussi, voire plus utile comme compétence que de savoir poser une division ou distinguer un complément d’objet d’un attribut du sujet…

il est possible aussi que ce soit une tambouille du clavier par dessus le système

Je pensais plutôt à ça, avec quelques condensateurs pour que le réglage persiste un moment. Côté driver je n’ai rien de spécial me semble-t-il, mais je ne suis pas très sûr (je suis même passablement largué je dois dire…). C’est "usbhid, hid_generic, hid" qui gère ça non ?

Mais faudrait que je check, tu as p-e raison.

Qu’importe le clavier (même ceux même pas à dix balles), ça fait pas bon ménage avec : les poils d’animaux, la fumette (ça permet de générer autant de dégâts que de la poussière sur dix à cent fois plus de temps), les miettes diverses (inévitables même quand on pense manger proprement devant son matériel) et les liquides (parfois quelques gouttes dans le tissus nettoyant)

je sais bien mais je n’avais jamais observé ce genre de problème avec ceux à membrane. Ceci dit c’est peut-être juste une question que je m’habitue. Le toucher est vraiment différent. Et nettement plus agréable et confortable malgré ces « ratés ».

(longueur d’activation, butée, etc.)

Oui j’ai vu ça, il y a même un code couleur pour les mécanismes et ces paramètres je crois. C’est un domaine très riche, dont la disposition, par exemple n’est qu’un des aspect. Le clavier reste encore l’interface par excellence pour interagir avec un ordinateur. En attendant un moyen de connecter directement l’activité électrique du cerveau. ^^ La voix par exemple ce n’est pas inintéressant mais sûrement pas encore ni assez fiable ni assez versatile. Les dispositifs de pointage aussi bien sûr complètent utilement le clavier (l’infographie au clavier c’est pas ouf par exemple).

Sur AZERTY je crois que le plus surprenant c’est la touche pour ù, lettre utilisée dans un seul mot du français (un mot très important certes, mais bon…) !

Excellente remarque, au temps pour moi !

/dev/sdX et pas se gourer de X !

Assurez-vous d’abord que le BIOS soit à jour.

C’est clairement pas idiot comme conseil mais mettre à jour un BIOS ça peut être encore plus touchy (et risqué par ailleurs). Je ne suis pas sûr que ce soit le meilleur conseil dans son cas. Même si son BIOS n’est pas à jour il devrait quand même pouvoir démarrer sur une clé USB.

rufus/balena, etc

Comment as-tu créé ta clé ? Je ne connais pas Mate mais généralement les images ISO d’installation de distribution sont dites « hybrides », et le plus simple (c’est comme ça que je fais pour ma part), plutôt que d’utiliser un utilitaire particulier, c’est d’utiliser la commande dd.

Évidemment il te faut un OS Linux fonctionnel pour procéder ainsi (quoi que Cygwin entre autre doit le permettre mais là on va faire que s’embrouiller…), mais au moins tu es sûr que l’image est copié « telle que » sur la clé, aucun utilitaire pour venir faire la moindre tambouille.

dd if=le_fichier_dinstallation.iso of=/dev/sdN

Bien sûr attention à quel chiffre tu mets pour "N", sois sûr que ce soit ta clé, et pas ton disque dur ou autre chose, ça ne pardonnerait pas.

Notebook Upgrade Bay
Notebook Hard Drive
Notebook Ethernet

Si tu ne vois pas "USB" dans ce menu, p-e aller voir dans le BIOS si tu n’aurais pas un réglage à faire, si ton image sur la clé est foireuse il devrait quand même pouvoir essayer de booter dessus pour seulement ensuite te dire (en substance) : « Pas d’OS sur le machin. Appuyer la touche n’importe. »

Au pire si tu as moyen de prendre une photo de là où tu es bloqué p-e que quelqu’un pourra t’aider.

Et si tu as la possibilité d’essayer avec une autre clé, fais-le, on sait jamais.

Merci pour l’info, mais à quel moment c’est utile de « smallcaser » ou « uppercaser » une valeur ? C’était ça ma question.

Dans le cas d’une saisie utilisateur ? Autre ? Note que je ne remets pas en doute l’utilité, juste que je l’ignore et ça m’agace ;)

TIL, merci.

Je sais pas plus ce que c’est qu’est un geoguesser qu’un wordle _o_

ROFL

plop June VII V Pepsi again belleck dbfen 4 FY777

Rule 11 j’abandonne :)

C’est exactement pour ce genre de possible galère que je pense qu’il vaut mieux rallonger le mot de passe que mettre un caractère « exotique ». J’ai eu le soucis assez régulièrement par le passé, je sais maintenant où sont le w, le m, le z, et quelques diacritiques, ou que les chiffres nécessitent pas de Shift, avec une dispo qwerty.

Il me serait jamais venu à l’idée d’utiliser un qwerty (en tant que français), les français qui font ça, c’est une question d’habitude ? Les premiers PC vendus en France avaient des claviers qwerty ? Ou bien vous utilisez une disposition qwerty sur un clavier qui est « physiquement » azerty par snobisme pour une bonne raison ?

À ça peut s’ajouter encore un sur-couche de problème… Il y a quelques temps j’ai acquis un clavier à touches mécaniques, pour voir ce que ça donnait. Il se trouve qu’en plus d’avoir des touches mécaniques elles ont des loupiottes, ça aucun problème, mais c’est un clavier dit « de gamer », on peut donc, par exemple échanger les touches qzsd avec les flèches. Je l’ai appris par hasard suite à un appuis involontaire sur la « bascule » qui active ce réglage, bah je me suis trouvé con. Surtout que débrancher le clavier un moment (le temps de brancher un bon vieux clavier de merde avec des touches « caoutchouc » pour finir mon taf) et bien ça ne remet pas la configuration à zéro (oui c’est sûr c’est plutôt une feature je dis pas ^^). J’ai fini par trouver mais ce fût un peu laborieux.

Au sujet des touches mécaniques : ya pas à dire le toucher est plus agréable, par contre j’ai certaines touches qui parfois ne s’activent pas. J’en ai déjà remplacé quelques une (le clavier était livré avec quelques mécanismes de remplacement…) mais c’est le genre de truc qui ne m’étais jamais arrivé avec des claviers normaux à 10 balles… Ceci dit je ne suis pas capable de dire pourquoi ça déconne précisément, vu qu’il y a un tas de raisons possible, alors je suppose que c’est une conjonction de toutes :

• C’est pas le premier prix mais quand je vois les prix qu’atteignent les claviers mécaniques je sais que j’ai pas le top

• Je suis un bourrin et les touches prennent cher, ces bêtes là sont probablement plus délicates que les claviers classiques

• Les poils d’animaux ont tout l’espace nécessaire pour aller se foutre où il ne faut pas (j’ai déjà ôté toutes les touches (enfin les « capuchons », les mécanismes c’est assez relou à sortir…) pour dégager les poils, mais je vais pas faire ça tout le temps.

• N’ayant jamais eu une motricité fine très développée et le temps passant, mes doigts ne frappent plus forcément là où mon cerveau s’attend à ce qu’ils frappent avec une précision suffisante. ^^

Pour les plus jeunes (ou les très vieux) : https://www.youtube.com/watch?v=zGvmL21pv6c

:p

Ah si, une remarque quand même. C’est quelque chose que je faisais aussi, en préfixant pour éviter tout risque de collisions mais de ce que j’ai compris, par convention les identifiants (ie: non de variable) en majuscule sont à réserver aux variables d’environnement.

Mais bon… je note que tu préfixes par _ par prudence, je crois pas que ce soit très grave comme façon de faire, perso je ne vais pas réécrire tous les scripts que j’ai fait avec des variables en majuscules pour les passer en minuscules ! :) Le plus souvent je me contentais de les préfixer toutes par une chaîne dériver du script. par exemple un script "UltimateTrucWrapper" je préfixais par UTW_. Avec ça je pense être assez tranquille. Mais maintenant j’ai changé j’en ai plus rien à branler j’utilise des minuscules avec un nom le plus descriptif possible, exemple : lobby_carpet_color_RVB :)

    _AXM_ARGS_FILE=$(mktemp -t ${__AXM_FILE_PREFIX}-auxilium_args.XXXXXX)
    _AXM_ARGS_VALUE=$(mktemp -t ${__AXM_FILE_PREFIX}-auxilium_value.XXXXXX)
    _AXM_LIST_ARGS=$(mktemp -t ${__AXM_FILE_PREFIX}-auxilium_list_args.XXXXXX)
    _AXM_LIST_OPT=$(mktemp -t ${__AXM_FILE_PREFIX}-auxilium_list_opt.XXXXXX)

Il servent à quoi les .XXXXXX finaux ?

Si tu veux que le nom soit propre à l’exécution (au cas peu probable où on exécuterait ton script 2+ fois en parallèle (dans un framework plus large qui l’inclurait par exemple…)), tu devrais p-e utiliser $$ en lieu et place de .XXXXXX ?

Après lecture rapide de ton script je dois dire que je n’ai pas le volonté de vraiment étudier le truc. Mais je le garde dans mes bookmark et le testerai p-e à l’occasion.

Et j’apprends l’existence de /usr/bin/tabs, l’aide parle de COBOL, FORTRAN et S/370, entre autre, je t’avoue que je suis trop intimidé pour essayer de comprendre à quoi ça sert ! ^^

Je ne connaissais pas ${X,,} ni ${X^^} (c’est dans la « cheat sheet » à laquelle je me réfère mais je n’ai pas pris le temps de tout lire (parce qu’il m’est illusoire de tout retenir de toute façon…)).

J’ai vu que declare permettait effectivement de faire ça. Cependant je ne vois pas quels sont les cas d’usage. Vous auriez des exemples ?

si tu n'utilise pas un autre langage que tu donne à manger à un compilateur ou un interpréteur

Alors je mets de côté les langages compilés qui ont indéniablement des avantages sur les interprétés. Mais je ne vois pas ce que tu veux dire si tu parles d’interpréteur. Bash est au même titre que Perl et Python un langage interprété. Le fait que Python expose l’étape intermédiaire du bytecode ne change pas grand chose.

En d’autres termes, en quoi Perl et Python seraient de véritables langages interprétés et pas Bash ?

Les « exécutables de ma distribution » ils ont cet avantage sur les bibliothèques Python d’être nettement plus stabilisés en terme d’API… Sans parler de la quasi trivialité de la mise en place de « l’environnement d’exécution », qui s’il n’est pas très complexe dans le cas de Python, encore moins de Perl, n’est pas aussi trivial que les binaires qui constituent l’environnement d’exécution d’un script Bash.

Ça fait combien de temps que pip/pip3 ne permet même plus de faire un "search" ?

il n'est pas limitant (va dessiner des Qrcode en shell)

Je pense qu’on touche là à un point central, qu’est-ce que "le shell" désigne si on parle programmation ?

Est-ce uniquement Bash (ou zsh, etc…) ou bien est-ce qu’on n’y inclus l’ensemble des binaires disponibles ? Bash et les autre shells sont des langages que je qualifierais de « glue », sans binaires comme curl ou grep ou find etc… on ferait pas grand chose.

Les « bibliothèques » du shell ce sont les « standalone » que tout bonne bibliothèque fournie systématiquement.

En interactif ils peuvent être très pratiques

Oui, en interactif je ne réécris pas toute ma commande si je veux la relancer avec un grep dessus… Donc j’UUOC sans honte comme tout le monde, comme tu dis c’est très pratique.

Les UUOC ne sont que des problèmes de puristes, ils ne posent de véritables problèmes que d'un point de vue esthétique.

Là par-contre je m’inscris en faux. C’est d’abord un problème si ton script, ou ta fonction dans ton script, est amenée a être exécutée « plein de fois ». Une instruction qui prend 15ms au lieu de 2ms ça change rien si tu l’exécutes une seule fois. Si c’est quelques millions, ou même quelques milliers de fois, ça commence à avoir son importance.

Donc clairement, ce n’est pas une question purement esthétique.

toute une série d’instructions/lignes entre le changement de IFS et son rétablissement.

Oui en effet. Je ne vois pas de cas d’usage mais ça ne veut clairement pas dire qu’il n’y en a pas.

le shell utilise IFS quasiment partout

Tu veux dire des commandes du shell comme ls, xargs ou autre qui pourraient avoir leur comportement modifié à cause de la modification de IFS ? Ça m’étonnerait (ou plutôt j’espère que non ^^). Je pense que tu parles du reste du code du script, voire de script externes appelés par celui-ci ?

Et heureusement la modification ne se propage bien-sûr pas au « sur-shell » qui a lancé le script.

$ printf "%q\n" "$IFS"; echo -e 'IFS=4\nprintf "IFS vaut : %q\\n" "$IFS"; exit 4\n' > script; bash -f script; printf "%q" "$IFS"

$' \t\n'
IFS vaut : 4
$' \t\n'

(je sais c’est moche, mais c’est représentatif)

Et c’est un bon exemple de cas « àlakon » où un double échappement se justifie, encore que, c’est juste pour que le fichier "script" généré ait pas la gueule de travers :)

utiliser perl/python/ruby.

Il y a clairement des avantages, mais qui viennent bien sûr avec quelques inconvénient. Dans les avantages je pense d’abord au fait de la cohérence du langage, surtout pour Python, mais Perl est aussi exemplaire sur ce point (bien que les deux soient absolument différent, et à condition de ne pas recourir excessivement à la puissance d’abstraction de Perl ^^). Par rapport au shell(s) Unix c’est le jour et la nuit.

Par contre pour « qui doit durer », je pense que ça dépend de si on parle de « qui doit être étendu souvent, par de nombreuses personnes » ou « qui doit être laissé dans un coin et voir passer les upgrades systèmes sans demander la moindre attention ». Dans le second cas Python est pas ouf, d’expérience, à partir du moment où on utilise quelques lib externes ça explose fréquemment à la version d’OS N+1. Pas le shell.

Je trouve que la taille du code joue beaucoup aussi, la programmation objet de Python, dès que le programme devient relativement complexe, ça aide énormément, en plus de la syntaxe et du paradigme beaucoup plus cohérent auquel je faisais allusion précédemment.

Pour ma part, en tout cas dans le cas où un test est nécessaire. Généralement c’est pour conditionner l’exécution d’une autre commande ou d’une fonction. Alors à moins d’être dans le cas d’une « conditionnalité complexe » (ie: un if … elif … else … fi), je fais :

grep -q truc fichier || action

Le || pour coller à ton exemple avec -ne 0, mais si c’est au contraire -eq 0 (ie: on fait l’action si la condition est "success"), alors la même chose avec &&.

Je fais parfois même des condition || { action1; && action2; } (ou l’inverse…) mais j’avoue que là ça devient assez illisible et il vaut mieux recourir à un if même si on peut faire sans.

Flemme de vérifier (et pas sûr que ça change quoi que ce soit à l’exécution…) mais si c’est la condition “ya des lignes ou pas ?” qui t’intéresse, le -c de grep n’est même pas nécessaire :) Et l’intérêt à ne pas le mettre dans ce cas ce serait qu’à la simple lecture du début de la ligne, juste les options du grep, tu sais qu’on ne s’intéresse pas aux nombres de lignes qui matchent mais juste s’il y en a ou pas.

Si je pouvais bosser qu’avec des gens doués comme vous ! ^^

L’exemple que j’ai donné c’est ce qu j’ai pu voir, assez souvent même, dans un cadre professionnel. C’est des trucs que j’ai très sûrement fait moi-même en maternelle de shell. On dirait les exemples qu’on enseigne. Typiquement tu expliques cat, puis | et introduit grep et pour illustrer tu montres cat fichier | grep truc, après tu expliques wc, et pour montrer toute la puissance de la notion de pipe, qu’on peut chaîner, tu montres cat fichier | grep truc | wc -l. Etc… etc…

Donc j’ai l’impression que bien des gens se sont arrêtés là… Mais loin de moi l’idée de les blâmer, enfin pas trop et pas tous ^^. Tout le monde n’a pas le goût de la programmation et on peut sûrement concevoir les métiers de l’informatique autrement, avec une vision plus clickodrome que ligne de code du bousin. Ça n’implique pas d’être débile pour autant, chacun ses forces et ses faiblesses, et surtout, sa vision des choses…

J’ai toujours pas compris comment quelqu’un a pu trouver que c’était une bonne idée, et comment ça a pu être validé jusqu’à la mise en production.

Suggérer l’idée que curl et wget c’est en fait la même chose, que cette soi-disant richesse, cette variété des logiciels libres était bien une légende. Oui Madame, nous le disions ! Une sorte de cancer, oui, appelons un chat un chat. C’était une fake-news écœurante, probablement entretenue par des trolls sales et mal rasés comme on s’est évertué à vous le dire depuis Windows 95. Donner deux noms différents à un même programme c’est assurément le signe d’une condition psychiatrique particulière et qu’il est de notre devoir le plus absolu d’offrir à l’humanité (pour un prix raisonnable) les logiciels qu’elle mérite, les seuls logiciels dignes de dépenser de l’argent et concéder une perte de sa liberté, pour le meilleur !

DISCLAIMER : Je ne vis pas dans le slip du Bill Gates de 2002, mais dans le mien. Je n’ai aucun élément factuel étayant le propos ci-dessus. Toute survenu d’idée chez le lecteur de nature à provoquer un avis quelconque est indépendante de ma volonté et pure coïncidence. Ce contenu vous est fourni… Aziz ! Si ya un problème c’est pour toi !

if [ "$(basename $0)" = "auxilium" ]; then
    echo "You can't use this script directly"
    echo "You can view an example by call /usr/bin/auxilium-test"
    exit
fi

Si j’ai pu critiquer les echo sur plusieurs lignes dans un autre post j’espère que tu ne te remettras pas en question sur ce point, car ça a le mérite d’être nettement plus lisible que la manière dont je m’y prends moi et finalement je ne vois pas ce qui me permet de critiquer cette façon de faire.

J’allais dire autre chose mais je vais fermer ma gueule parce que j’avais juste oublié que ton script se devait d’être POSIX et je ne peux donc pas te donner de solution à l’éventuel et très hypothétique problème que je vois… Or « Pas de solution, pas de problème. »

Par contre pour les deux fonctions suivantes :

_to_lower(){
    echo $(echo $1 |tr -s '[:upper:]' '[:lower:]')
}

_to_upper(){
    echo $(echo $1 |tr -s '[:lower:]' '[:upper:]')
}

Tu ne pourrais pas faire simplement :

_to_lower(){
    echo "$1" |tr -s '[:upper:]' '[:lower:]'
}

_to_upper(){
    echo "$1" |tr -s '[:lower:]' '[:upper:]'
}

?

L’absence de quote dans le cas de echo pose rarement des soucis mais s’il y a un * dans ton argument ça va quand même faire des trucs potentiellement ennuyeux et assurément indésirables.

Mais surtout, je ne vois pas pourquoi tu fais un « echo d’un echo », ça ne fait pas la même chose effectivement, dans ton cas tu appelles un sous-shell, mais en l’occurrence je ne vois pas en quoi c’est utile. (Note que je n’ai bien sûr pas lu tout le script avant de commenter, c’est ma spécialité ! ;) Je pense toujours pouvoir le faire, mais là j’ai plus le temps ce « soir ».

Je les renseigne dans une cartouche de commentaire en début

Je l’ai fait aussi sinon ce serait même pas la peine… Et c’est le fait de devoir faire des head -n20 avant de lancer le script qui me rappelle que ça devient critique. :) (je sais que le "n" pour la commande head n’est obligatoire, mais comme il l’est quand il y a d’autres options je le mets systématiquement…)

j’essaie de prévoir un mode interactif

Alors ça c’est le truc qui me vient jamais à l’esprit et que j’ai du mal à envisager, mais sans aucune bonne raison.

getop pour bash

Faut vraiment que j’aille voir pourquoi j’avais décidé de ne plus utiliser ce truc. Vu que c’est grosso modo la même époque où j’ai jugé que le strict mode c’était bof, il y a des chances que ma décision ait été tout aussi conne concernant getopt. :)